Exchange Server 2003 Administration Guide

 

 

 

 

Valid Until:                           May 1, 2004

Product Version:              Exchange Server 2003

Reviewed By:                   Exchange Product Development

Latest Content:                 www.microsoft.com/exchange/library

Author:                             Exchange Documentation Team

 

 

 


                                                                                                                                                       

 

 

Exchange Server 2003 Administration Guide

 

 

 

 

 

 

 

 

 

 

Jyoti Kulkarni

Patricia Anderson

 

 

 

 

 

 

 

 

 

 

 

 

 


Copyright

 

 

 


Table of Contents

Introduction

Overview.. 1

What Will You Learn from This Book?. 1

Who Should Read This Book?. 2

Terminology. 2

How is This Book Structured?. 3

What Are the Requirements to Complete the Procedures In This Book?. 5

 

Chapter 1

Preparing to Administer Exchange Server 2003. 7

Understanding Exchange Administration Architecture. 8

Interacting with Active Directory. 9

Selecting the Right Management Tools. 11

Working with Exchange System Manager 12

Working with Active Directory Users and Computers. 14

Creating Recipients. 16

Performing Exchange Tasks. 17

Managing Exchange in Multiple Domains. 18

Deciding Where to Manage Exchange. 18

Setting Up a Management Station. 19

Using Custom Consoles. 22

Creating Custom Consoles. 24

Automating Administrative Tasks. 25

 


Chapter 2

Managing an Exchange Organization. 27

Promoting an Exchange Organization from Mixed Mode to Native Mode. 28

Applying Global Settings. 30

Associating File Name Extensions with MIME. 30

Using SMTP Policies to Control Outbound Mail Formatting
and Automatic Responses. 32

Selecting Message Delivery and Message Filtering Options. 36

Creating and Managing Administrative Groups. 44

Understanding the Types of Administrative Models. 45

Displaying Administrative Groups. 50

Creating Administrative Groups. 51

Moving Objects Between Administrative Groups. 51

Deleting Administrative Groups. 52

Using System Policies. 52

Understanding How System Policies Affect Individual Settings. 54

Creating a Server Policy. 55

Adding Servers to a Server Policy. 57

Viewing the Objects Controlled by a System Policy. 57

Copying System Policies Between Administrative Groups. 58

Modifying or Removing a Policy. 59

Managing Permissions. 60

Understanding Exchange Objects and Exchange System Manager 60

 

Chapter 3

Configuring Exchange Server Settings. 67

Configuring Server-Specific Settings. 68

Viewing Messages in Message Tracking Center 69

Enabling Message Tracking. 69

Managing Message Tracking Log Files. 70

Designating a Front-End Server 71

Sending Error Information to Microsoft 72

Configuring Language Settings. 73

Scheduling Mailbox Manager Processes. 74

Defining a Schedule. 76

Setting Reporting Options. 76

Configuring Diagnostics Logging on a Server 77


Customizing Public Folder Referrals. 80

Assigning Costs on the Public Folder Referrals List 82

Understanding Directory Access Options. 83

Automatically Constructing a Topology for Directory Access. 85

Manually Constructing a Topology for Directory Access. 86

Viewing System Policies Applied to the Server 87

Setting Server-Specific Permissions. 89

Configuring System Resource Usage During Full-Text Indexing. 90

 

Chapter 4

Managing Recipients and Recipient Policies. 93

Understanding Recipients. 93

Understanding Recipient Policies. 96

Managing E-Mail Addresses. 97

Managing Mailboxes Using Mailbox Manager 99

Creating Recipients. 101

Mailbox-Enabled and Mail-Enabled Recipients. 102

Mail-Enabled Groups. 104

Understanding Query-Based Distribution Groups. 107

Query-Based Distribution Groups Described. 107

Modifying Exchange 2000 SP3 Servers for Use with Windows 2000 Global
Catalog Servers. 108

How Query-Based Distribution Groups Work. 109

Deployment Recommendations for Query-Based Distribution Groups. 109

Guidelines for Creating Query-Based Distribution Groups. 111

Creating Query-Based Distribution Groups. 112

Combining Multiple Query-Based Distribution Groups. 114

Managing Recipients. 115

Notes for Exchange 5.5 Administrators. 115

Managing Recipients with Recipient Policies. 116

Managing Recipient Settings. 120

Configuring Message Settings for Mailbox-Enabled Recipients. 121

Exchange Advanced Settings for Mailbox-Enabled Recipients. 123

Configuring Message Settings for Mail-Enabled Recipients. 127

Distribution Groups. 128


Understanding Address Lists. 129

Address Lists Described. 130

Creating Address Lists. 131

Offline Address Lists. 134

Customizing the Details Templates. 136

Recipient Update Service. 138

 

Chapter 5

Understanding and Configuring Message Routing and Transport. 141

Configuring Routing for Internal Mail Flow.. 141

Understanding Routing Groups. 142

Creating Routing Groups. 146

Moving Servers Between Routing Groups. 148

Renaming a Routing Group. 148

Deleting a Routing Group. 149

Connecting Routing Groups. 150

Connecting to the Internet 154

Defining SMTP Dependencies. 155

Configuring SMTP. 157

Using a Wizard to Configure Internet Mail 158

Manually Configuring the Sending of Internet Mail 161

Manually Configuring the Receipt of Internet Mail 173

Enabling Filtering to Control Junk E-Mail Messages. 178

Connecting to Exchange 5.5 Servers and Other X.400 Systems. 180

Customizing the X.400 Protocol 181

Understanding X.400 Connectors. 182

Disabling or Removing Connectors. 192

Using Queue Viewer to Manage Messages. 193

Disabling Outbound Mail 194

Finding Messages. 195

Using SMTP Queues to Troubleshoot Message Flow.. 196

Using X.400 (MTA) Queues to Troubleshoot Message Flow.. 200

Configuring Diagnostic Logging for SMTP. 201

Modifying Logging Settings. 201

Enabling Debugging Level Logging. 202

Configuring Diagnostic Logging for the X.400 Service (MSExchangeMTA) 203

 


Chapter 6

Managing Client Access to Exchange. 205

Preparing to Manage Client Access. 206

Choosing a Topology. 207

Configuring Security for Client Access. 208

Choosing Client Access Model and Protocols. 208

Configuring Clients and Devices. 209

Managing Protocols. 209

Enabling a Virtual Server 210

Assigning Ports and an IP Address to a Virtual Server 211

Setting Connection Limits. 212

Starting, Stopping, or Pausing a Virtual Server 213

Terminating Connected Users. 214

Managing Calendaring Options for the POP3 and IMAP4 Virtual Servers. 214

Managing the HTTP Virtual Server 215

Working with IMAP4-Specific Settings. 217

Configuring NNTP Posting Limits and Moderation Settings. 218

Managing Outlook 2003.. 220

Configuring Cached Exchange Mode. 220

Managing Outlook Web Access. 221

Enabling and Disabling Outlook Web Access for Internal Clients Only. 222

Using Browser Language. 223

Setting Up a Logon Page. 224

Enabling Outlook Web Access Compression. 227

Blocking Web Beacons. 228

Blocking Attachments. 229

Filtering Junk E-Mail Messages. 230

Simplifying the Outlook Web Access URL. 231

Managing Exchange ActiveSync. 232

Enabling Exchange ActiveSync for Your Organization. 232

Enabling Up-to-Date Notifications for Your Organization. 234

Managing Outlook Mobile Access. 236

Configuring Exchange to Use Outlook Mobile Access. 236

Enabling Outlook Mobile Access for Your Organization. 237

 


Chapter 7

Managing Mailbox Stores and Public Folder Stores. 239

Working with Permissions for Public Folders and Mailboxes. 240

Using Exchange Administrative Roles with Exchange Store Components. 241

Understanding the Types of Permissions That Control Access to Mailboxes and Public Folders  243

Using Mailbox Permissions. 244

Using Public Folder Permissions. 246

Maintaining the Minimum Permissions Required for Mailbox Stores and Public Folder Stores  254

Managing Storage Groups and Stores. 256

Configuring Transaction Logs for a Storage Group. 258

Overwriting Deleted Data During Backup. 261

Adding a Storage Group. 261

Mounting or Dismounting Stores. 262

Moving Store Files to a New Directory. 262

Configuring Store Maintenance and Backup Options. 263

Configuring Mailbox Stores. 265

Configuring Public Folder Stores. 273

Managing Mailboxes. 285

Creating a Mailbox. 285

Deleting a Mailbox. 286

Recovering a Mailbox. 287

Moving a Mailbox Within an Administrative Group. 288

Managing Public Folders. 288

Understanding Types of Public Folders. 288

Understanding Public Folder Referrals. 295

Configuring Public Folders. 301

Maintaining Public Folders. 315

 

Chapter 8

Managing Exchange Clusters. 323

Reviewing Exchange Clusters. 324

Reviewing the Exchange Resources Associated with Exchange Clusters. 324

Understanding How Failover Works in an Exchange Cluster 326

Using Cluster Administrator to Manage Exchange Clusters. 328


Customizing Your Exchange Cluster Configuration. 329

Configuring Exchange Virtual Server Settings. 329

Configuring Exchange Cluster Resources. 336

Taking Exchange Virtual Servers or Exchange Resources Offline. 345

Adding IMAP4 and POP3 Resources. 347

Adding a Node. 349

Adding an Exchange Virtual Server 349

Removing an Exchange Virtual Server 350

Moving All Mailboxes and Public Folder Content 352

Taking the Exchange System Attendant Resource Offline. 353

Using Cluster Administrator to Remove the Exchange Virtual Server 353

Deleting the Remaining Cluster Resources. 354

Removing Exchange 2003 from a Cluster Node. 354

Migrating an Exchange Cluster Node to a Stand-Alone (Non-Clustered) Server 356

Monitoring Performance of an Exchange Cluster 356

Monitoring Active/Passive Clusters. 356

Monitoring Active/Active Clusters. 357

Monitoring Virtual Memory in a Cluster 357

Enabling Exchange Logging. 360

Tuning Servers in a Cluster 362

Removing Exchange 2000 Tuning Parameters. 362

Setting the /3GB Switch. 363

Configuring /Userva and SystemPages. 363

Troubleshooting Your Exchange Clusters. 363

Identifying the Cause of a Failure. 364

Performing Disaster Recovery on Your Exchange Clusters. 365

 

Appendix A

Tools Used with Exchange. 369

 

Appendix B

Services Used by Exchange. 383

 

Appendix C

Configuration Settings for a Four-Node Cluster. 389

 


Appendix D

Identifying and Accessing Exchange Store Components. 391

 

Appendix E

Controlling Public Folder Replication. 395

How Replication Works. 396

The Basic Hierarchy and Content Replication Process. 399

Status and Backfill Messages. 401

Configuring the Default Replication Schedule. 407

Configuring Replicas. 408

Adding or Removing Content Replicas. 409

Setting a Folder-Specific Replication Schedule. 409

Setting Replication Message Priority. 409

Checking Replication Status. 410

Replicating Data Manually. 412

Special Considerations for Mixed-Mode Topologies. 413

Connection Agreements and Public Folder Replication. 413

Avoiding Common Replication Problems in Mixed Mode. 418

Managing Inter-Organization Replication. 420

 

Appendix F

Using Full-Text Indexing. 423

Verifying Recommended Hardware Configurations. 423

Preparing Your Exchange 2003 Organization. 424

Deploying Full-Text Indexing. 424

Creating a Full-Text Index. 425

Optimizing Full-Text Indexing. 425

Performing a Full Population. 432

Setting a Schedule for Incremental Populations. 434

Enabling Full-Text Indexing Queries. 436

Notifying and Educating Users. 436

Managing Full-Text Indexing. 436

 


Appendix G

Troubleshooting and Repairing Store Problems. 439

Problems with Full-Text Indexing. 439

Safe Event Viewer Messages. 440

Population Process Is Slow.. 441

Population Process Is Found in a Paused State. 442

Deleted Message Is Still Visible in Search Results. 442

Wrong Location Is Displayed After Moving the Index. 442

Using Gather Log Entries to Identify Problems. 443

Language Settings Problems. 443

Queries Fail During Server Startup. 446

Restoring Missing Performance Counters. 446

Avoiding Disk Bottlenecks. 447

High Paging. 447

Problems with Permissions in a Mixed Exchange 5.5-Exchange 2003 Environment 447

Determine What is Preventing a User from Seeing the Public Folder in Outlook. 448

View Access Control Lists in Exchange System Manager 448

Monitor Permissions Events in Event Viewer 449

Problems with Public Folder Replication. 453

Replication Messages Not Being Received. 453

Backfill Takes a Long Time. 454

Server Does Not Appear to Backfill 454

Other Problems. 454

Unable to Access Permissions on a Public Folder (Invalid Windows Handle Error) 455

One or More Users Could Not Be Added to the Folder Access List 456

Mail Messages to Public Folder Were Not Delivered. 456

Outlook Web Access Cannot View a Public Folder After the Tree Has Been
Renamed. 457

Message "Operation Failed" When Attempting to Access a Tree Using Exchange System Manager 457

Exchange 5.5 Servers See Multiple Public Folder Stores on an Exchange 2003 Server 457

In a Mixed Exchange 5.5-Exchange 2003 Environment, Users Cannot Access a Public Folder Using Outlook Web Access  458

Attachment Exceeds Storage Limit on Public Folder 459

 


Appendix H

Additional Resources. 461

Web Sites. 461

Exchange Server 2003 Books. 461

Exchange 2000 Server Books. 462

Technical Articles. 462

Tools. 462

Resource Kits. 463

Microsoft Knowledge Base Articles. 463

 

Glossary. 465

 


Introduction

Overview

Building on the solid foundation of Microsoft® Exchange 2000 Server, Microsoft Exchange Server 2003 offers new features and improvements in reliability, manageability, and security. This book will help you make the most of these improvements by explaining the core concepts of Exchange administration.

Within each chapter of this book, there is a discussion about particular Exchange features, how these features work within the Exchange architecture, and how to configure and manage these features for optimal results. The features and related tasks that are covered in this book range from configuring global settings at an organization level to managing individual servers to handling specific configuration needs such as Exchange clients and clustering. After reading this book you should have a solid understanding of what it takes to configure and manage your Exchange 2003 organization.

What Will You Learn from This Book?

Essentially, this document provides detailed answers to the following questions:

·         What information do I need to know to prepare myself to administer Exchange 2003? (Chapter 1)

·         How do I configure settings at both the organization level and the server level to achieve specific Exchange 2003 goals? (Chapter 2 and Chapter 3)

·         What do I need to know about recipients, messaging, the Exchange store, e-mail clients, and Exchange clusters to manage these aspects of Exchange effectively? (Chapters 4–8)

·         How do I manage e-mail recipients in my organization effectively? (Chapter 4)

·         What do I need to understand about routing groups, Simple Mail Transfer Protocol (SMTP), and Internet connectivity to enable message flow in my organization? (Chapter 5)

·         How do I provide and support e-mail clients for my users? (Chapter 6)

·         How do mailbox stores and public folder stores work in Exchange 2003? What do I need to know to administer them effectively? (Chapter 7)

·         How do I effectively administer clusters to achieve maximum reliability and availability? (Chapter 8)

·         What tools and services are available for managing Exchange 2003? (Appendix A and B)

·         What is the recommended configuration for a four-node Exchange 2003 cluster? (Appendix C)

·         How do internal components interact in the Exchange store, and what I should know about these components? (Appendix D)

·         What do I need to know about public folder replication and the replication process? (Appendix E)

·         What is full-text indexing, and how can I effectively use full-text indexing in my organization? (Appendix F)

·         What tools and processes can I use to troubleshoot and remedy mailbox and public folder store problems? (Appendix G)

 

Who Should Read This Book?

Although practically anyone with a technical background can benefit from reading this book, it is designed to produce maximum benefits for the following professionals:

Enterprise Exchange Administrators

Those individuals who are responsible for installation, maintenance, and administration of software in the enterprise.

Exchange User Account Managers

Those individuals who are responsible for setting up individual e-mail accounts and modifying individual Exchange accounts in the Microsoft Active Directory® directory service.

Terminology

Before reading this book, familiarize yourself with the following terms:

A record

An address resource record in DNS; specifically, a DNS record that associates a host name with an IP address.


bridgehead server

A computer that connects servers using the same communications protocol so that information can be passed from one server to another. In Exchange 2003 and Exchange 2000, a bridgehead server is a connection point from a routing group to another routing group, remote system, or other external system.

connector

A component that enables information to flow between two systems. For example, connectors support message transfer, directory synchronization, and calendar querying between Exchange and other messaging systems. When connectors are in place, the basic user experience is maintained on both messaging systems. The exchange of mail and other information between Exchange and other messaging systems is transparent to the user, even if the two systems function differently.

mail-enabled

A recipient that can receive e-mail but does not have a mailbox in your Exchange organization. Mail-enabled recipients do not use your Exchange organization to send e-mail.

mailbox-enabled

A recipient that can both send and receive e-mail, and has a mailbox in your Exchange organization where e-mail and other items can be stored.

recipient

Any Active Directory object that can receive e-mail. Users, InetOrgPerson objects, Groups, Contacts, and Public Folders can all be recipients.

How is This Book Structured?

This document is divided into eight chapters, eight appendixes, and a glossary:

Chapter 1, "Preparing to Administer Exchange Server 2003"

This chapter explains the dependency of Exchange on Active Directory, introduces the two primary tools used to administer Exchange, gives examples of how to efficiently use those tools, and briefly discusses the automation of administrative tasks using the Exchange Software Development Kit (SDK).

Chapter 2, "Managing an Exchange Organization"

This chapter covers the administrative tasks that affect an entire Exchange organization. Among the topics that are covered are promoting an organization from mixed mode to native mode, applying global settings, working with administrative groups, using system policies, and working with permissions.

Chapter 3, "Configuring Exchange Server Settings"

This chapter covers the administrative tasks that affect individual Exchange servers. Among the topics that are covered are configuring basic server settings, using language settings to support different languages, cleaning mailboxes, setting up diagnostic logging for specific components, using public folder referrals, configuring Directory Access options, using security settings on a server, and configuring full-text indexing settings.

Chapter 4, "Managing Recipients and Recipient Policies"

This chapter explains what recipients and recipient policies are, how to create and manage recipients, how to manage address lists, and how to use the new query-based distribution list feature in Exchange 2003.

Chapter 5, "Understanding and Configuring Message Routing and Transport"

This chapter explains how messages are sent within an organization, how to connect to the Internet, how to connect to Microsoft Exchange Server version 5.5 or X.400 systems, how to manage messages, and how to configure diagnostic logging for SMTP and the X.400 service.

Chapter 6, "Managing Client Access to Exchange"

This chapter looks at client access in the context of a front-end and back-end server architecture. The first part of this chapter explains what is meant by a front-end/back-end architecture, and what the dependencies are in selecting this architecture. The chapter then focuses on configuring individual clients for Exchange.

Chapter 7, "Managing Mailbox Stores and Public Folder Stores"

This chapter describes the permissions that protect the Exchange store, as well as how to work with different elements of the Exchange store, including managing mailboxes and public folders.

Chapter 8, "Managing Exchange Clusters"

This chapter begins with a brief review of what Exchange clusters are. It then covers the various administrative tasks that are associated with clusters, including customizing your cluster configuration; adding resources, a node, or an Exchange Virtual Server; removing either an Exchange Virtual Server or Exchange 2003 from a cluster; and monitoring cluster performance.

Appendix A, "Tools Used with Exchange"

This appendix lists a variety of tools that you can use to manage and troubleshoot your Exchange organization.

Appendix B, "Services Used by Exchange"

This appendix lists the various services that run on an Exchange server.

Appendix C, "Configuration Settings for a Four-Node Cluster"

This appendix describes the recommended configuration settings for a four-node cluster that contains three active nodes and one passive node.

Appendix D, "Identifying and Accessing Exchange Store Components"

This appendix lists the various components of the Exchange store, and how to work with them.

Appendix E, "Controlling Public Folder Replication"

This appendix includes procedures for configuring replication. It also describes how replication works, and what aspects of your Exchange topology affect the replication process.

Appendix F, "Using Full-Text Indexing"

This appendix describes how to set up full-text indexes, and how to optimize and maintain the indexes.

Appendix G, "Troubleshooting and Repairing Store Problems"

This appendix describes the common problems, events, and messages that are related to managing mailbox and public folder stores. It also includes information about what causes the problems and possible solutions.

Appendix H, "Additional Resources"

This appendix contains links to additional resources that are available to help you maximize your understanding of how to administer Exchange 2003.

Glossary

This appendix provides comprehensive definitions for the terms used within this book.

What Are the Requirements to Complete the Procedures In This Book?

To successfully complete all of the procedures that are covered in this book, ensure that you have fulfilled the following requirements. Keep in mind that these lists provide an overview of the maximum requirements for performing these procedures.

Security-specific Hardware Requirements

The following hardware is required to perform the procedures that are covered in this book. This list does not include your general Exchange servers, storage hardware, and so on. It only includes security-specific hardware requirements:

·         2 firewalls (or routers)

·         RSA SecurID PIN generators (for each mobile client)

·         Minimum of 1 front-end server running Microsoft Internet Security and Acceleration Server

 

Software Requirements

The following software is required to perform the procedures that are covered in this book:

·         Microsoft Exchange Server 2003 Enterprise Edition

·         Microsoft Internet Security and Acceleration Server

·         Microsoft Windows 2000 Advanced Server

·         RSA SecurID Server version 1.x

 

 


Chapter 1

Preparing to Administer Exchange Server 2003

Before you start managing Microsoft® Exchange Server 2003, it is useful to understand the administration architecture that Exchange uses and how this architecture influences the tools that you use to manage Exchange. Exchange 2003 interacts with and depends upon data in the Microsoft Active Directory® directory service. It also stores and retrieves data from other places, including the mailbox store, the Microsoft Windows® registry, and the Exadmin virtual directory. To access and manage Exchange data, there are two Microsoft Management Console (MMC) snap-ins—Exchange System Manager and Active Directory Users and Computers—where you will spend the majority of your time as an administrator.

After understanding Exchange administration architecture and the tools that you use to interact with Exchange, the next step is to determine how to efficiently use those tools. You may decide to set up a dedicated management station from which to manage multiple servers in the organization. You may also decide to create a customized management console that combines separate MMC snap-ins into one console. You may even want to automate additional administrative tasks using the Exchange Software Development Kit (SDK). You will find information about these choices in the latter portion of this chapter.


Understanding Exchange Administration Architecture

Exchange 2003 uses Active Directory to store and share information with Windows. Thus, all of the directory information that you create and maintain in Windows, such as organizational unit structure and groups, can also be used from Exchange.

The Active Directory schema can be extended to include custom attributes and object types to centralize and minimize data administration, as well as to make data available to applications that can access Active Directory information. In fact, when you install your first Exchange server, Exchange 2003 extends the Active Directory schema to include Exchange-specific information. Extending the schema affects the entire forest and, depending on the size of Active Directory, may take a considerable amount of time to complete.

Because Active Directory serves as a single-source directory for all of the objects in your organization, Exchange uses this information to reduce administrative overhead. With Active Directory, you can store and organize information about users, such as names, e-mail addresses, and phone numbers. This information is stored as attributes of the user object. Exchange and other applications can use this information. For example, the address lists to which a recipient belongs are written as values to the ShowInAddressBook attribute in that recipient's Active Directory object. To create address lists, Exchange performs Lightweight Directory Access Protocol (LDAP) queries on each of these objects and retrieves the information stored in the ShowInAddressBook attributes.

Note   
Because Exchange 2003 relies on Active Directory, it is important that you be familiar and comfortable with Active Directory terminology, structure, and navigation. For a comprehensive overview of Active Directory, review the documentation that came with your copy of Windows. For more information about Exchange integration with Active Directory, see the books Planning an Exchange 2003 Messaging System and Exchange Server 2003 Deployment Guide (www.microsoft.com/exchange/library).

Microsoft Exchange Server version 5.5 and earlier do not use Active Directory. If your messaging topology is in mixed mode (contains both Exchange 2003 and Exchange 5.5 or earlier), you can still use Active Directory by using Active Directory Connector (ADC) to replicate directory information between the Exchange 5.5 directory and Active Directory. For more information about ADC, see the book Exchange Server 2003 Deployment Guide (www.microsoft.com/exchange/library).

 


Interacting with Active Directory

When you make changes to your Exchange organization or to an individual user account, you often interact with data in Active Directory. This interaction occurs through one of two MMC snap-ins, Exchange System Manager or Active Directory Users and Computers. Figure 1.1 shows how these two tools interact with Active Directory.

Note   
In addition to Exchange System Manager and Active Directory Users and Computers, there are other tools that are useful for Exchange administration. For more information, see Appendix A, "Tools Used with Exchange."

 

Figure 1.1   Where Exchange System Manager and Active Directory Users and Computers get information

 


As shown in Figure 1.1, all of the information that you see (read) and manipulate (write) using Active Directory Users and Computers is stored in Active Directory. Most, but not all, of the information that Exchange System Manager reads and writes also comes from Active Directory. However, in addition to data in Active Directory, Exchange System Manager draws information from other sources, such as:

·         MAPI   Exchange System Manager uses MAPI to gather data from the Exchange store to display mailboxes (see Figure 1.2).

Figure 1.2   Mailbox data gathered using MAPI and displayed in Exchange System Manager

 

·         Windows Management Instrumentation (WMI)   Exchange System Manager uses the data supplied by WMI to display cached directory information (DSAccess, a cache of directory information that reduces the number of calls to your global catalog server) and queue information.

·         Web Distributed Authoring and Versioning (WebDAV)   Exchange System Manager uses the data supplied by WebDAV to display public folders using the Exadmin virtual directory.

 

Note   
The location of the Exadmin virtual directory is in Internet Information Services (IIS) under the default Web site. If the default Web site service is stopped, you will not be able to display public folder information in Exchange System Manager.

 


Selecting the Right Management Tools

Although both Exchange System Manager and Active Directory Users and Computers provide access to Exchange-related data in Active Directory, typically you do not use them interchangeably. Generally speaking, you:

·         Use Exchange System Manager for configuration data for the server and organization.

·         Use Active Directory Users and Computers for recipient data.

 

To further highlight these usage differences, Table 1.1 provides specific examples of when you use Exchange System Manager, and when you use Active Directory Users and Computers.

Table 1.1   Comparing Exchange System Manager and Active Directory Users and Computers

Use Exchange System Manager to

Use Active Directory Users and Computers to

Manage your Exchange organization.

Manage Active Directory objects (recipients).

Manage servers.

Manage users.

Move all mailboxes from one server to another server.

Move an individual's mailbox from one server to another server.

Create public folders.

Create distribution groups.

 

As Table 1.1 shows, some tasks can be performed using either Exchange System Manager or Active Directory Users and Computers. For instance, you could move mailboxes using either Exchange System Manager or Active Directory Users and Computers. The difference between the two approaches is whether you want to find all of the users on a server or only a selected subset. When you want to quickly find all of the users on a server, Exchange System Manager is the better choice. When you want to select users based on specific criteria, use Active Directory Users and Computers because this snap-in allows you to create custom LDAP filters that can filter using virtually any criteria.

Tip   
In newsgroups or conversations with other Exchange administrators, some people refer to Exchange System Manager as ESM. Active Directory Users and Computers may be referred to as ADU&C or DSA (Directory Server Agent).

 

Building on the preceding overview of how Exchange System Manager and Active Directory Users and Computers work within the Exchange administration architecture, the next two sections explain Exchange System Manager and Active Directory Users and Computers in more detail. If you are already confident about using these tools, you can move ahead to the section, "Deciding Where to Manage Exchange," for information about whether to use these tools through Remote Desktop, Terminal Server, or a dedicated management station.


Working with Exchange System Manager

Exchange System Manager (Exchange System Manager.msc) is a specialized MMC console that helps you manage your Exchange organization. When you perform a typical installation of Exchange 2003 onto a server, the installation wizard automatically installs the Exchange System Management Tools onto that server as well.

Exchange System Manager provides a consistent administrative experience for administrators who deal with all facets of Exchange server management, including public folders, servers, routing, and policies.

Exchange System Manager is available on the Start menu of the Microsoft Exchange program group, as described in the following procedure.

To open Exchange System Manager

·         On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

Figure 1.3 shows how Exchange System Manager appears on the screen.

Figure 1.3   Exchange System Manager hierarchy

 


As shown in Figure 1.3, the left pane of Exchange System Manager is the console tree. The top node of this tree is the root organization node that contains all of the Exchange containers. Each of these containers gives you access to specific administrative features in Exchange. Table 1.2 describes what you can do with each of these containers.

Table 1.2   Exchange System Manager containers

Container

Description

Global Settings

Includes features to configure system-wide settings. These settings apply to all servers and recipients in an Exchange organization.

Recipients

Includes features to manage objects and settings for recipients in your organization. You can manage address lists, offline address lists, recipient update services, recipient policies, mailbox management settings, details templates, and address templates.

Administrative Groups

Includes features to manage administrative groups. Each group is a collection of Active Directory objects that are grouped together for the purpose of permissions management. Each administrative group can contain policies, routing groups, public folder hierarchies, and servers.

Note   
This container only appears if you have created administrative groups for your organization.

 

Servers

Holds server-specific configuration objects, such as Queues, Mailbox stores, Public Folder stores, and Protocols information.

System Policies

Contains policies that affect the system's configuration settings. Policies are collections of configuration settings that are applied to one or more Exchange objects in Active Directory.

Routing Groups

Defines the physical network topology of Exchange servers. An Exchange mail system, or organization, consists of one or more servers on which Exchange is installed. Unless you are planning a small Exchange installation, you will probably have more than one Exchange server. Within some organizations, these servers are connected by reliable, permanent connections. Groups of servers that are linked together in this way should be organized into the same routing group.

Note   
This container only appears if you have created routing groups for your organization.

 

 


 

Container

Description


Folders

Displays public folder hierarchies. A public folder stores messages or information that can be shared with all designated users in your organization. Public folders can contain different types of information, from simple messages to multimedia clips and custom forms.

Tools

Contains tools that help you to monitor your Exchange organization, track messages, and recover mailboxes.

 

Using Exchange System Manager and its containers, you can:

·         Use Properties of the root node to configure Exchange 2003 to display or not display routing groups and administrative groups in the console tree.

·         Manage your Exchange organization by setting properties on different containers under the root node in the console tree. For example, you can delegate administrative permissions at the organization level in Exchange System Manager, or at an administrative group level using the Exchange Delegation Wizard.

·         Set permissions on a specific server by modifying the permissions settings in the server's Properties dialog box.

 

To find detailed explanations of how to perform these tasks, as well as other organization-level or server-level tasks, refer to the appropriate chapter within this book.

Working with Active Directory Users and Computers

You use Active Directory Users and Computers to manage recipients. Active Directory Users and Computers is an MMC snap-in that is a standard part of Microsoft Windows Server™ operating systems. However, when you install Exchange 2003, the setup wizard automatically extends the functionality of Active Directory Users and Computers to include Exchange-specific tasks.

Note   
If the Active Directory Users and Computers snap-in is installed on a computer that does not have Exchange or the Exchange management tools installed, you will not be able to perform Exchange tasks from that computer.

 

You launch Active Directory Users and Computers from either an Exchange server or from a workstation that has the Exchange System Management Tools installed.


To open Active Directory Users and Computers

1.        On the Start menu, click Run.

2.        In the Open box, type dsa.msc, and then click OK.

—or—

·         On the Start menu, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.

 

Figure 1.4 shows how Active Directory Users and Computers appears on the screen.

Figure 1.4   Active Directory Users and Computers hierarchy

 

The left pane of Active Directory Users and Computers is the console tree that shows your fully qualified domain name at the root level. Click the + (plus) sign to expand the root container. Under the root container are several default containers:

·         Builtin   Container for built-in user accounts.

·         Computers   Default container for computer objects.

·         Domain Controllers   Default container for domain controllers.

·         ForeignSecurityPrincipals   Container for security principals from trusted external domains. Administrators should not manually alter the contents of this container.

·         Users   Default container for user objects.

 

In addition to the default containers, you can organize directory objects into logical units by creating containers called organizational units. For example, you could create an organizational unit for your marketing group that holds all of the directory objects associated with your company's marketing department. Organizational units are useful for applying group policy and for organizing objects in a meaningful way. For more information about organizational units, see the Windows documentation.

After you have organized the containers within Active Directory Users and Computers, you can then use those containers to:

·         Create recipients.

·         Perform Exchange-specific tasks.

·         Manage multiple Exchange domains.

 

Creating Recipients

After Exchange has extended Active Directory Users and Computers, you can mail-enable or mailbox-enable an object, and thereby turn the Active Directory object into a recipient. However, not all objects can be mail-enabled or mailbox-enabled. For example, you can create a mailbox for a user object or a mail-enabled group object, but you cannot do either for a computer object. Thus, the Active Directory objects that are of most interest to you as an Exchange administrator are:

·         Users

·         InetOrgPerson objects

·         Contacts

·         Groups

·         Query-based distribution groups

 

For more information about creating recipients, see Chapter 4, "Managing Recipients and Recipient Policies."


Performing Exchange Tasks

In Active Directory Users and Computers, you can select a user or a group object, and then use the Exchange Task Wizard to perform a variety of tasks that are specific to that object. These tasks depend on the type of object that you select and its current attributes. For example, the Exchange Task Wizard will not allow you to create a mailbox for a contact because contacts can only be mail-enabled, not mailbox-enabled. Likewise, selecting a user who already has a mailbox means that the Exchange Task Wizard allows you to the delete the user's mailbox, but not to create another mailbox.

Here is the complete list of Exchange-specific tasks that Exchange Task Wizard can perform:

·         Creation of mailboxes

·         Moving of mailboxes

·         Deletion of mailboxes

·         Designation of an e-mail address

·         Configuring of Exchange features

·         Removing Exchange attributes

·         Deleting e-mail addresses

·         Hiding group membership

·         Associating external accounts

 

To use Exchange Task Wizard to perform one of these tasks, use the following procedure.

To perform an Exchange-specific task

·         In Active Directory Users and Computers, right-click a user or group object, and then click Exchange Tasks.

 


Managing Exchange in Multiple Domains

You can use Active Directory Users and Computers to manage Exchange in more than one domain in a forest. To do this, you need to connect to the desired domain using the following procedure.

To manage Exchange in a another domain

·         In Active Directory Users and Computers, right-click the root object in the console tree, and then select Connect to Domain.

 

Note   
You must have the appropriate permissions for the target domain.

 

Deciding Where to Manage Exchange

Knowing the basics of how to use Exchange System Manager and Active Directory Users and Computers is just the beginning of managing Exchange 2003. The next step is to decide where is the best location from which to use these tools within your Exchange environment.

During a typical installation of an Exchange 2003 server, the setup wizard installs Exchange System Manager and extends Active Directory Users and Computers directly on the server. To use these tools, you log on to the server itself. However, it is advisable to limit direct interaction with the server to avoid exposure to unwanted practices. For example, it may be necessary to directly log on to a server to move log files, but in doing so, you may accidentally delete system files or inadvertently introduce viruses.

To minimize directly logging on to the server, you can use Remote Desktop, Terminal Server, or a dedicated management station. Table 1.3 outlines some of the inherent advantages and disadvantages of these various approaches to Exchange management.


Table 1.3   Administration scenarios

Management scenario

Advantages

Disadvantages

Logging directly on to the server
(Console session)

·         No extra setup required.

·         No extra hardware required.

·         Increased risk. Administrators can inadvertently delete files or introduce viruses.

Using Remote Desktop or Terminal Server

·         No extra setup required.

·         Can manage from outside of the data center.

·         Administrators can perform most tasks without leaving their desks.

·         Increased risk. Administrators can inadvertently delete files or introduce viruses.

·         Number of remote connections is limited to the number of Terminal Server licenses purchased.

Using a dedicated management station

·         Decreased risk.

·         Can place management station in convenient location.

·         Extra setup required.

·         Extra hardware required.

 

Of the three approaches listed in Table 1.3, the only approach that is discussed further in this chapter is the dedicated management station. Directly logging on to the server requires no special setup. If you decide to use Remote Desktop or Terminal Server, the best source for setup information is the documentation that came with your copy of Windows.

Setting Up a Management Station

By installing Exchange System Manager and Active Directory Users and Computers on a dedicated management workstation, you can avoid some of the risks outlined in Table 1.3. The following checklist briefly lists the steps to set up a management station.

Management Station Setup Checklist

c

Install Microsoft Windows XP Professional with Service Pack 1 (or later) on the workstation.

c

Join the workstation to the domain with Exchange.

c

Install the Windows Administrative Tools Pack on the workstation.

c

Install the Simple Mail Transfer Protocol (SMTP) service on the workstation.

c

Install the Exchange System Management Tools on the workstation.

c

Shut down the SMTP service on the workstation.

 

For more information about installing Windows XP and adding the workstation to the domain, see your Windows documentation. For the remaining steps in the checklist, use the following procedures.

Note   
To manage Exchange, the workstation must be joined to the same forest as your Exchange servers. You cannot manage domains in another forest.

 

Installing the Windows Administrative Tools Pack

After you have installed Windows XP with Service Pack 1 onto the workstation, you need to install the Windows Administrative Tools Pack. Installing this tools pack enables you to use the workstation to remotely manage servers running Windows.

To install the Windows Administrative Tools Pack

·         On the dedicated management workstation, browse to the Microsoft Knowledge Base Article 324745, "HOW TO: Install the Active Directory Administrative Tools to Windows XP Professional in Windows Server 2003" (http://support.microsoft.com/?kbid=324745), and follow the instructions.

 

Installing the SMTP Service

After installing the Windows Administrative Tools Pack, you need to install the SMTP service on the workstation. Installing the SMTP service allows you to install the Exchange System Management Tools.

To install the SMTP service

1.        On the dedicated management workstation, open Add or Remove Programs, and then click Add/Remove Windows Components.

2.        Select Internet Information Services (IIS), and then click Details.

3.        Select the SMTP Service component check box.

4.        Click OK, click Next, and then click Finish.

 


Installing the Exchange System Management Tools

After completing the previous steps, you are ready to run Exchange setup.

To install the Exchange System Management Tools

1.        On the dedicated management workstation, insert the Exchange 2003 Setup compact disc into the workstation's CD drive, and then navigate to <drive>: \setup\i386\setup.exe.

2.        On the Component Selection page, do the following:

·         Under Component Name, locate Microsoft Exchange. In the corresponding Action column, select Custom.

·         Under Component Name, locate Microsoft Exchange System Management Tools. In the corresponding Action column, select Install (see Figure 1.5).

Figure 1.5   Microsoft Exchange System Management Tools installation option

 

3.        Click Next, and continue with the wizard.

 


Shutting Down the SMTP Service

After installing the Exchange System Management Tools, you should disable the SMTP service because you only need this service to install the Exchange System Management Tools. In general, it is a good security practice to shut down any unneeded services.

Using Custom Consoles

MMC provides a framework for management tools (that is, snap-ins). Although MMC is not a tool itself, snap-in tools cannot be run independent of it. Opening a snap-in from the command prompt or the Start menu automatically results in the snap-in opening into its own MMC window.

As an alternative to opening an MMC snap-in in its own window, you can create a custom console. This custom console is a single instance of MMC that houses all of the snap-in tools that you use regularly. As an Exchange administrator, you may want to create a custom console that consolidates Exchange System Manager and Active Directory Users and Computers. For example, Figure 1.6 shows a custom console that houses Exchange System Manager, Active Directory Users and Computers, and Event Viewer.

Note   
You can use a custom console regardless of where you decide to manage Exchange—by directly logging onto the server, by using Remote Desktop or Terminal Server, or by using a dedicated management workstation.

 


Figure 1.6   A custom console that contains Exchange System Manager, Active Directory Users and Computers, and Event Viewer

 

As shown in Figure 1.6, the user interface (UI) of a custom console is the same as that of the individual snap-ins. In the left pane is the console tree, which shows a hierarchical view of the different containers of the various snap-ins. On the right is the details pane, where you can manage the different objects in the containers by right-clicking an object and selecting an appropriate command for that object.


Creating Custom Consoles

In addition to creating a custom console to help you manage Exchange, you can create custom consoles for different administrators or different tasks.

To create a custom MMC console, there are two steps. First, you create a new instance of MMC, and then you add the desired snap-ins to that instance.

To create a new instance of MMC

1.        On the Start menu, click Run.

2.        In the Open box, type MMC, and then click OK.

This opens a blank MMC window (see Figure 1.7). The next step is to add the snap-ins that you want to use.

Figure 1.7   A new instance of MMC

 


To add snap-ins to MMC

1.        In MMC, on the File menu, click Add/Remove Snap-in.

2.        Click Add to open the Add Standalone Snap-in window.

3.        Select the snap-in that you want to add from the list, and then click Add.

For example, you can select Active Directory Users and Computers or Exchange System Manager.

4.        Repeat Step 3 until you have added the desired snap-ins.

5.        Click Close, and then click OK.

 

Automating Administrative Tasks

In addition to Exchange System Manager, Active Directory Users and Computers, and the other tools described in this book, Exchange Server 2003 provides technologies for accomplishing most administrative tasks programmatically. These technologies include Collaboration Data Objects for Exchange (CDOEX), CDO for Exchange Management (CDOEXM), and a large set of WMI providers.

The Exchange SDK contains complete information about writing applications to manage, control, and extend Exchange, including numerous reusable code samples. You can download the Exchange SDK, or view it online from the Exchange developer center (http://msdn.microsoft.com/exchange).


Chapter 2

Managing an Exchange Organization

When you install Exchange, you can join an existing organization or create a new organization, if one does not already exist. An Exchange organization defines your messaging environment. An organization includes all of the Exchange servers, domain controllers, global catalog servers, users, and other Microsoft® Active Directory® directory service objects that function together as a single entity. Exchange organizations can include multiple Active Directory domains, but they cannot span multiple Active Directory forests.

Note   
You cannot change the organization name after it is created.

 

The configuration settings that you apply to an Exchange organization have the potential to affect all components within the organization. This chapter explains the basic administrative tasks that you use to manage your Exchange organization. Use this chapter to understand what it means to promote an Exchange organization to native mode, how to apply global settings to control message formatting and Simple Mail Transfer Protocol (SMTP) message filtering, how to manage your organization and servers using administrative groups and system policies, and how permissions and standardized security roles work in Exchange.

 


Promoting an Exchange Organization from Mixed Mode to Native Mode

Microsoft Exchange Server 2003 and Exchange 2000 Server both take advantage of Active Directory, and therefore coexist in what is called a native mode organization. However, Exchange Server version 5.5 (and earlier) does not rely on Active Directory. This difference means that, when servers running either Exchange 2003 or Exchange 2000 coexist with servers running Exchange 5.5 (or earlier), the organization must run in what is called mixed mode. Some newer features and functionality in Exchange are unavailable when running in mixed mode. For example, routing groups function differently in mixed and native modes.

Note   
For more information about routing groups, see Chapter 5, "Understanding and Configuring Message Routing and Transport."

 

By default, a new Exchange 2003 organization runs in mixed mode until it is promoted to native mode. You can only promote an Exchange organization to native mode if there are no servers running Exchange 5.5 (or earlier), and if no instances of Site Replication Service (SRS) are running. Ensure that you have properly upgraded all servers and any connectors before you switch to native mode. After you switch an organization to native mode, it can never return to mixed mode. This means you cannot add an Exchange 5.5 server to a native mode topology.


To switch from mixed mode to native mode

1.        In Exchange System Manager, right-click your Exchange organization, and then click Properties.

2.        On the General tab (see Figure 2.1), click Change Mode.

Figure 2.1   Change Mode option on the General tab

 

For more information about native and mixed modes, see the books Exchange Server 2003 Deployment Guide and Planning an Exchange 2003 Messaging System (http://www.microsoft.com/exchange/library).


Applying Global Settings

Using global settings, you can configure system-wide settings in your Exchange organization. These settings can apply to all servers and recipients in an Exchange organization.

This section focuses on using global settings to configure the following:

·         How SMTP converts MAPI messages to Multipurpose Internet Mail Extensions (MIME).

·         How policies for SMTP domains control the formatting of messages that are destined for a domain and the types of automatic responses that can be sent to the domains.

·         How Exchange delivers messages organization-wide.

 

Global settings are also available for Exchange ActiveSync® and Microsoft Outlook® Mobile Access. For more information about Mobile Services and Outlook Mobile Access, see Chapter 6, "Managing Client Access to Exchange."

Associating File Name Extensions with MIME

Internet message formats are used when messages are sent to or received from an Internet client. When a user sends mail from a MAPI client, such as Microsoft Outlook®, to an Internet client, such as Outlook Express, SMTP converts the message from Microsoft rich text format (RTF) to MIME. The file name extensions that you define for each MIME type enable clients to recognize mail attachments and open them. By default, several content types are associated with file name extensions. Generally, the default associations are sufficient for content conversion.


To manage associations for file name extensions

1.        In Exchange System Manager, expand Global Settings, right-click Internet Message Formats, and then click Properties.

2.        On the General tab (see Figure 2.2), use the following options:

·         To associate a new file name extension with a MIME type, click Add.

·         To prioritize the associated extension that Exchange uses with each MIME type, click Move Up to move the extension up the list or Move Down to move the extension down the list. If two associated extensions exist for a single MIME type, Exchange uses the extension that appears higher on the list.

Figure 2.2   List of MIME content types on the General tab

 


Using SMTP Policies to Control Outbound Mail Formatting and Automatic Responses

You can use Internet message formats to define SMTP policies that control the format of messages that are sent to the Internet, or to specific external SMTP domains. These policies also control what types of automatic responses, such as out-of-office notifications, can be sent to Internet domains from users in your organization.

For each domain that is defined in Internet Message Formats, you can set the following properties:

·         Message formatting options that determine how messages sent to this domain are encoded, and which language character set is used to display these messages.

·         Advanced options that determine when messages are sent in Exchange RTF, how text is formatted, and what types of automatic responses, such as non-delivery reports (NDRs) or out-of-office notifications, are sent to this domain.

 

Important   
Do not send mail exclusively in RTF because many non-Microsoft mail servers cannot read rich-text messages. Servers that cannot read rich-text messages provide their users with e-mail messages that include a Winmail.dat file attachment. To avoid this problem, ensure that your message settings do not use Exchange RTF exclusively.

 

The following sections explain the default policy, and how to create new policies for specific domains.


Understanding the Default Policy

By default, an SMTP policy exists for the domain *, which encompasses all messages that are destined for the Internet. All messages that Exchange sends to the Internet use the settings on this policy. You can view this policy in the details pane when you select Internet Message Formats in Exchange System Manager, as shown in Figure 2.3.

Figure 2.3   Default SMTP policy for all Internet domains

 

A policy must exist for the * domain. This policy controls how messages are sent to all external domains. If necessary, you can modify the properties on this policy.

Creating a Policy for a New SMTP Domain

In addition to modifying the policy for the * domain, you can create other policies for specific SMTP domains. For example, you want to communicate with a business partner who has an SMTP domain named contoso.com, and you want to allow out-of-office replies to be sent to this domain, but not to other external domains. You can create a new policy for the contoso.com domain that does exactly that. Because Exchange uses the SMTP policy that most closely matches the SMTP domain, all messages sent to Contoso users use the policy for the Contoso domain, but messages sent to any other SMTP domain use the default policy for the * domain.


To create a new policy

1.        In Exchange System Manager, expand Global Settings, right-click Internet Message Formats, point to New, and then click Domain.

2.        On the General tab (see Figure 2.4), enter a policy name and the SMTP domain.

Figure 2.4   Entering a policy name and an associated SMTP domain

 

Setting Message Formatting Options for a Policy

You can control how Exchange formats the messages that are sent to the domain or domains on a particular policy. You can have Exchange format these messages in either MIME or uuencode, so that non-MAPI clients can read these messages. Additionally, you can specify the character set that Exchange uses for outgoing messages. By default, all messages use the Western European (ISO-8859-1) character set.


To set the message formats for a policy

1.        In Exchange System Manager, right-click the policy, and then click Properties.

2.        On the Message Format tab (see Figure 2.5), select the message encoding and character sets that you want to use with this policy.

Figure 2.5   Message Format tab for the Contoso policy

 

Controlling Automatic Replies and Advanced Formatting for a Policy

Beyond specifying the message encoding and character sets to be used with a policy, you can also specify the following options:

·         When the policy uses Exchange rich-text format.

·         Whether messages sent using the policy allow message text wordwrapping.

·         What types of auto-responses can be sent to users in the domain or domains on the policy. For security purposes, you can prevent automatic responses to external domains. For example, you may want to prevent out-of-office responses.

 


To set advanced properties for a policy

1.        In Exchange System Manager, right-click the policy, and then click Properties.

2.        On the Advanced tab (see Figure 2.6), select the appropriate options.

Note   
As stated earlier, do not select Always use under Exchange rich-text format, unless you are configuring a policy for a domain whose users always use MAPI clients.

 

Figure 2.6   Advanced tab for the Contoso policy

 

Selecting Message Delivery and Message Filtering Options

You can use the Message Delivery Properties dialog box to configure the following message delivery options:

·         Default message delivery options, including message size restrictions for sending and receiving messages, and the maximum number of recipients that a message can have.

·         SMTP message filtering to control unsolicited commercial e-mail (also known as spam), using sender, connection, and recipient filtering.

 

To access the Message Delivery Properties dialog box

·         In Exchange System Manager, expand Global Settings, right-click Message Delivery, and then click Properties.

 

Configuring Default Message Size and Recipient Limits

The Defaults tab in the Message Delivery Properties dialog box (see Figure 2.7) is where you configure the default restrictions for the following message delivery options:

·         The maximum message size that can be sent by users   This is the Sending message size option, and it defaults to No limit (users can send a message of any size). Based on your available network bandwidth and your user requirements, you may want to limit the maximum message size that is allowed in your organization. If a user attempts to send a message that exceeds the specified size limit, the user receives a non-delivery report (NDR) and Exchange will not send the message.

·         The maximum message size that can be received by users   This is the Receiving message size option, and it defaults to No limit (users can receive a message of any size). Again, based on network bandwidth and user requirements, you may want to limit the message size. Senders within your organization receive an NDR if they attempt to send a message to a user that exceeds the specified size limit. Depending on the NDR settings that you configure in Internet Message Formats, external senders may or may not receive an NDR.

Note   
For more information about Internet Message Formats, see "Using SMTP Policies to Control Outbound Mail Formatting and Automatic Responses" earlier in this chapter.

 

·         The maximum number of recipients to which a single message can be sent   This is the Recipient limits option, and it defaults to 5000 recipients. Recipients include all users on the To, Cc, and Bcc lines, as well as expanded distribution lists. Select No limit to allow users to send and receive messages regardless of how many recipients to which the messages are addressed.

 

Exchange applies the settings for these options globally to all users. However, you can override these settings on a per-user basis in Active Directory Users and Computers. For information about how to override these settings, see Chapter 4, "Managing Recipients and Recipient Policies."


To change the default message delivery options

·         In the Message Delivery Properties dialog box, on the Defaults tab (see Figure 2.7), select the appropriate options.

Figure 2.7   Defaults tab in the Message Delivery Properties dialog box

 

Configuring SMTP Message Filters

Although you configure SMTP message filtering options in the Message Delivery Properties dialog box, you must enable the filtering options on the individual SMTP virtual servers where you want to apply the filtering. Exchange applies these filters during the SMTP session when a remote SMTP server connects to the SMTP virtual server.

In Exchange 2003, you can configure sender filtering, connection filtering, and recipient filtering. Enabling filtering on an SMTP virtual server results in the virtual server checking the enabled filters when another SMTP server attempts to send mail into the organization.

Note   
Exchange applies SMTP message filters only to messages sent from external SMTP servers. Exchange does not apply SMTP message filters when servers send messages between themselves within an Exchange organization. This is because Exchange servers automatically authenticate with each other and filter only mail that is submitted anonymously.

 


Configuring Sender Filtering

Sender filtering allows you to block messages sent by specific senders. This is useful if you receive unsolicited commercial e-mail from particular domains or sender addresses. You can block these messages by enabling sender filtering.

To enable sender filtering

1.        On the Sender Filtering tab of the Message Delivery Properties dialog box (see Figure 2.8), click Add to add the SMTP address of a user or a particular domain from whom you want to block messages.

You can block an individual sender, an entire domain, or a display name (by entering the display name in quotes).

Figure 2.8   Sender Filtering tab in the Message Delivery Properties dialog box

 

2.        To have Exchange save any messages that sender filtering blocks to an archive folder (instead of automatically deleting these filtered messages), select Archive filtered messages.

The archive folder is in the <drive>: \Program Files\Exchsrvr\Mailroot\vsi n\archive folder, where n is the virtual server instance of the SMTP virtual server where sender filtering is enabled.

3.        To block messages with a blank sender address (a technique that some senders of unsolicited commercial e-mail messages use), select Filter messages with blank sender.

4.        To end the SMTP session when a sender matches an address on the sender filter, select Drop connection if address matches filter.

5.        To accept messages from senders on the block list without sending notification to the sender that mail was not delivered, select Accept messages without notifying sender of filtering.

 

Configuring Connection Filtering

Connection filtering blocks messages based on the Internet Protocol (IP) address of the connecting SMTP server. With regard to connection filtering, you can configure connection filtering rules, configure exceptions, and configure global accept and deny lists.

Note   
For detailed information about connection filtering and how it works, see "Connection Filtering," in Chapter 6, "Transport and Message Flow Features," in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).

 

Configuring Connection Filtering Rules

You can subscribe to a third-party block list provider and configure a connection filtering rule that checks against the provider's list of specific IP addresses.

Note   
Specific configuration of connection filtering rules is dependent upon the block list provider.

 


To configure a connection filtering rule

·         On the Connection Filtering tab (see Figure 2.9) of the Message Delivery Properties dialog box, under Block List Service Configuration, click Add.

Figure 2.9   Connection Filtering tab in the Message Delivery Properties dialog box

 

Configuring Exceptions

You can specify whether specific SMTP addresses within your organization are allowed to receive messages from blocked IP addresses. For example, a connection filtering rule blocks a legitimate organization from sending mail to your organization. By entering your postmaster address as an exception to this connection filtering rule, an administrator from the legitimate organization can send an e-mail message to the postmaster in your organization to find out why his or her organization is blocked from sending mail.

To create a list of exceptions to connection filtering rules

·         On the Connection Filtering tab (see Figure 2.9) of the Message Delivery Properties dialog box, click Exception.

 


Configuring Global Accept and Deny Lists

If there are IP addresses from which you either always want to accept mail or reject mail, you can configure a global accept or deny list.

Global accept list

This list contains all of the IP addresses from which you always want to accept mail. Exchange checks this list before checking any other filters. If the connecting server's IP address appears on the global accept list, Exchange automatically accepts the mail and does not check any additional filters.

Global deny list

This list contains all of the IP addresses from which you always want to reject mail. Exchange checks this list immediately after checking the global accept list. If an IP address appears on the global deny list, Exchange automatically rejects the mail and does not check any additional filters.

 

To create either a global accept or deny list

·         On the Connection Filtering tab (see Figure 2.9) of the Message Delivery Properties dialog box, click Accept to add an IP address to the global accept list or click Deny to add an IP address to the global deny list.

 

Configuring Recipient Filtering

Exchange 2003 also supports recipient filtering, so you can filter e-mail messages that are addressed to users who are not in Active Directory, or e-mail messages that are addressed to recipients who are commonly targeted by distributors of unsolicited commercial e-mail messages.

You can use recipient filtering to filter messages that a sender sends to any e-mail address, valid or invalid, within your organization. If a message is sent to any of the specified recipients, Exchange returns a 500-level error during the SMTP session.

By default, Exchange accepts mail addressed to any recipient (invalid or valid), and then Exchange sends NDRs for all invalid recipients. Usually, unsolicited commercial e-mail is sent from invalid addresses, so Exchange retries delivery of NDRs to non-existent senders and thereby wastes more resources. Enabling recipient filtering prevents Exchange from wasting resources in this way because you can filter e-mail that is sent to invalid recipients.


You can use recipient filtering to reject mail that a sender sends to invalid recipients (recipients that do not exist in Active Directory). However, doing so potentially allows malicious senders to discover valid e-mail addresses. The SMTP virtual server issues different responses for valid and invalid recipients. By comparing the responses issued by the SMTP virtual server for valid and invalid recipients, malicious users can identify valid e-mail addresses in your organization.

Note   
Recipient filtering rules apply only to anonymous connections. Authenticated users and Exchange servers bypass these validations.

 

For more information about configuring and enabling filtering, see "Connection Filtering" in Chapter 6, "Transport and Message Flow Features," in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).

To add a recipient to the recipient filtering list

·         On the Recipient Filtering tab (see Figure 2.10) of the Message Delivery Properties dialog box, click Add.

Figure 2.10   Recipient Filtering tab in the Message Delivery Properties dialog box

 


Creating and Managing Administrative Groups

In Exchange 5.5 (and earlier), a site defined both the administrative boundary and the physical routing topology for a group of servers. Exchange 2000 (and later) split the concept of a site into physical and logical components, as follows:

·         Routing groups define the physical network topology of your Exchange servers.

·         Administrative groups define a logical grouping of servers and other objects for the purpose of administration.

 

For more information about routing groups, see Chapter 5, "Understanding and Configuring Message Routing and Transport." This section focuses solely on administrative groups.

An administrative group can contain any of the following Exchange objects:

·         Servers

·         Policies

·         Routing groups

·         Public folder trees

 

Administrative groups allow you to delegate specific administrative permissions, and define system policies for the administrative groups and the objects within the group. You can create system policies that control the administration of servers, mailbox stores, and public folder stores within an administrative group. Permissions and system policies are discussed in more detail later in this chapter.


The remainder of this section focuses on the following topics:

·         Understanding the types of administrative models

·         Displaying administrative groups

·         Creating administrative groups

·         Creating a system policy

·         Moving objects between administrative groups

·         Deleting administrative groups

 

Note   
You should use the Exchange Administration Delegation Wizard to assign a specific group permission to manage an administrative group. For more information about the Exchange Administration Delegation Wizard, see "Managing Permissions" later in this chapter.

 

Understanding the Types of Administrative Models

Because administrative groups are logical, you can create administrative groups based on locations, departments, or functions. For example, a global company with branches in different countries could create administrative groups to delegate functional tasks. In a native-mode organization, you could create a single administrative group that contains servers only and use this specialized server administration group to create policies for all of the servers in your organization. You could then create another administrative group solely for the purpose of public folder administration, and then have a specialized team administer all public folders trees using this administrative group.

However, before creating these various functional administrative groups, you should understand your organization's administrative model, as dictated by your organizational structure and your security policy. When you understand your organization's administrative model, you can then implement administrative groups to accurately reflect this model.


This section presents the types of administrative models, and how these models affect your implementation of administrative groups. The administrative models discussed in this section are:

·         Decentralized administrative model

·         Centralized administrative model

·         Mixed administrative model

 

To illustrate these administrative models, the following sections show how to apply each of these models to a fictitious company called Contoso, Ltd. This fictitious company has global branches in North America, Europe, and Asia, as shown in Figure 2.11.

Figure 2.11   Branches in Contoso, Ltd

 

Note   
In a mixed-mode organization, each site becomes a single administrative group, and you cannot use the administrative models discussed in this section.

 


Using a Decentralized Administrative Model

In a decentralized administrative model, complete control over management of the Exchange system is distributed among the company's geographical regions or divisions. In this type of model, each region or division controls its own assets and performs its own system administration.

This type of organization probably has at least one administrative group in each division or group. Each location has its own team of Exchange administrators, who have full administrative control over objects within its administrative group.

Many companies implement a decentralized model to enable each company branch to function autonomously. For example, Contoso's global branches in the United States, Europe, and Asia each have control over an administrative group, a routing group, policies, servers, public folder trees, and other objects that are specific to that branch (see Figure 2.12).

Figure 2.12   Decentralized administrative model

 


Using a Centralized Administrative Model

In a centralized model, one or a few controlled administrative groups maintain complete control of the Exchange system. For example, Figure 2.13 shows how Contoso's administrative group in Seattle has complete control over the Exchange system of the company.

Figure 2.13   Centralized administrative model

 

This administrative model is similar to a data center where all administration tasks are performed by a single information technology group. This administrative model is typical in small-sized or medium-sized organizations, but can also be used in larger organizations that have high-bandwidth connectivity to all regional offices.

Using a Mixed Administrative Model

In a mixed model, administrative groups reflect both functional and geographic distribution. You create specialized administrative groups to restrict the management of certain functions to specific people, and create other groups to delegate administration along geographical lines. To illustrate this type of model, here are some sample administrative groups that you might want to create:

·         To restrict who can create and maintain policies, you can create an administrative group solely for the purpose of managing policies, which is a functional task.

·         To manage public folders in a specific region, you can create an administrative group solely for the purpose of managing a region's public folders, which is a geographical consideration.

 

You typically use the mixed administrative model in larger organizations that have many divisions or offices in many geographical locations. The mixed model can also apply when one company acquires another company.

Figure 2.14 shows how Contoso applies a mixed administrative model to its organization. To centrally administer public folders and policies, Contoso created one central administrative group for administering public folders and another for administering policies. The remaining administrative groups are regional and allow regional control of other functions, such as routing groups.

Figure 2.14   Mixed administrative model

 


Displaying Administrative Groups

After installing Exchange in an Exchange 2003 or Exchange 2000 organization, Exchange System Manager does not automatically display administrative groups and routing groups. You must configure your Exchange organization to display administrative groups. After you have configured this setting, you can view the Administrative Groups container and create additional administrative groups for your organization.

Note   
If you install Exchange 2000 (or later) in an Exchange 5.5 site, Exchange enables administrative and routing groups by default. In this case, every Exchange 5.5 site appears as an administrative group.

 

To display administrative groups

1.        In Exchange System Manager, right-click your Exchange organization, and then click Properties.

2.        On the General tab (see Figure 2.15), select Display Administrative groups.

Figure 2.15   Displaying administrative groups

 

3.        Restart Exchange System Manager for the changes to apply.

 

Creating Administrative Groups

In the default configuration of an Exchange organization, only one administrative group exists. You can either install all servers into this single administrative group, which is useful in a centralized administrative model, or you can create additional administrative groups and install servers into the appropriate administrative groups, based on your administrative model.

By default, Exchange installs all servers into the First Administrative Group in the Server container. You can rename First Administrative Group, and add new system containers, but you cannot remove servers from the Server container in this group.

Note   
In a mixed-mode organization, each Exchange 5.5 site becomes its own administrative group, and the administrative group name matches the site name.

 

You can add servers to an administrative group only during installation. Ideally, you should create the necessary administrative groups on the first Exchange server in your organization, and then install additional servers into the appropriate administrative groups. You can never move servers between administrative groups.

To create a new administrative group

·         In Exchange System Manager, right-click Administrative Groups, point to New, and then click Administrative Group.

 

Moving Objects Between Administrative Groups

You can move some of the objects in an administrative group to a different group. However, there are other objects that cannot be moved.

Objects that you can move between administrative groups are as follows:

·         System policies

·         Public folders

·         Routing group member servers (native mode only)

 

Objects that you cannot move between administrative groups are as follows:

·         Servers

·         Containers

 

You can move objects only between containers of the same type. For example, you can move a system policy from one system policy container to another system policy container in a different administrative group, but you cannot move a system policy into a public folder container. This type of action is blocked by default.

To move system policies or public folders between administrative groups

·         Cut the system policy or public folder from the source container, and paste it into the target container.

—or—

·         Drag the system policy or public folder from the source container to the target container.

Note   
When you are moving or copying objects between administrative groups, click Refresh to see the object in the new container.

 

Deleting Administrative Groups

You can delete only administrative groups that contain no objects. After you have removed all of the objects within an administrative group, you can delete it.

To delete an administrative group

·         In Exchange System Manager, expand Administrative Groups, right-click the administrative group that you want to delete, and then click Delete.

 

Using System Policies

A system policy is a collection of configuration settings that you apply to one or more servers, mailbox stores, or public folder stores. For example, to enable message tracking across multiple servers, you can define a single policy, rather than performing the lengthy task of setting individual policies to enable message tracking on each server. After defining and implementing the policies, you can change the configuration of all of the servers within the organization by editing the policies and applying the changes.

The system policies that you create for an administrative group typically apply to objects within that group. However, a system policy can apply to objects outside of its own administrative group. For example, you can implement consistent message tracking options for all servers by creating a server policy in a central administrative group and applying it to all servers in your organization.


Policies appear in the System Policies container under an administrative group (see Figure 2.16).

Figure 2.16   System Policies container

 

There are three types of system policies:

·         Public folder store policies   Allow you to configure settings across public folder stores.

·         Mailbox store policies   Allow you to configure settings across mailbox stores.

·         Server policies   Allow you to enable message tracking options on servers.

 

Of the three types of system policies, this section discusses only server policies in more detail. For information about configuring public folder store policies or mailbox store policies, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores."


Understanding How System Policies Affect Individual Settings

System policies use an apply-time implementation to affect configuration changes. You can create a policy, define settings for that policy, associate that policy with one or more servers or public folder stores, and then apply the policy. After you apply the policy, the corresponding settings that are specific to that individual object become unavailable and appear dimmed. This is because the policy, not the individual object, now controls those settings. For example, if you create a policy that enables message tracking and apply the policy to an Exchange server, the message tracking options for the server are unavailable (see Figure 2.17). This configuration enables administrators to prevent further changes from being made to settings on individual objects that a policy controls.

Figure 2.17   Message tracking options disabled on a server

 


Creating a Server Policy

You use a server policy for message tracking and maintenance settings for message tracking log files. When you enable message tracking to track messages, Exchange stores messages in the message tracking log file. By enabling subject logging and display, you store message subjects in Message Tracking Center, through which you can view the messages. Message tracking and subject logging are explained in more detail in Chapter 3, "Configuring Exchange Server Settings."

Before you can create a server policy (or, for that matter, any other system policy) within an administrative group, you must add a system policy container. After you have created the system policy container, you can then create a server policy.

To create a system policy container

·         In Exchange System Manager, expand Administrative Groups, right-click the administrative group, point to New, and then click System Policy Container.

 

To create a server policy

1.        In Exchange System Manager, expand Administrative Groups, expand the appropriate administrative group, right-click System Policies, point to New, and then click Server policy.

2.        On the General (Policy) tab (see Figure 2.18), select the following options:

·         To log the message subject and make this subject visible when messages are tracked, select Enable subject logging and display.

·         To track all messages that flow to and from the server, select Enable message tracking.

Figure 2.18   Message tracking options on a server policy

 

Handling Policy Conflicts

If you create a new policy that conflicts with settings in an existing policy, Exchange displays a dialog box that notifies you of the conflict. By default, the newer policy replaces an older policy. For example, you create a server policy with specified configurations, and you want to add the policy to a particular server. However, if the server is already under the control of another policy, a dialog box prompts you to verify whether you want to remove the server from the control of the other policy. You can choose to remove the server from the control of the previous policy, or apply the new policy you just created. If you do not resolve the policy conflict, the following message appears:

The objectname (for example, Server1) could not be associated with policy policyname (ServerPolicy) because you refused to remove the object from the control of conflicting policies.


Adding Servers to a Server Policy

After you create a server policy, you need to add servers to the policy.

To add servers to a server policy

1.        In Exchange System Manager, expand Administrative Groups, expand the administrative group that contains the server policy to which you want to add servers, expand System Policies, right-click the server policy, and then click Add server.

2.        In the Select the items to place under the control of this policy dialog box (see Figure 2.19), type the server name, and then click OK.

Figure 2.19   Selecting items for a server policy

 

Note   
Figure 2.19 shows the dialog box that appears when you run Exchange 2003 on Microsoft Windows Server™ 2003. If you run Exchange on Windows® 2000 Server, this dialog box offers the same functionality but appears slightly different.

Viewing the Objects Controlled by a System Policy

Using Exchange System Manager, you can view either the objects that the system policy controls or the policies that Exchange applies to an object:

·         To view the objects that a policy controls, click a policy in the System Policies container. The objects appear in the details pane under Policy Applied To.

·         To view the policies that Exchange applies to a particular object, click the Policies tab in the server's Properties dialog box.

 

Copying System Policies Between Administrative Groups

In Exchange 2003, policies can be copied or moved between policy containers that are in different administrative groups. Copying policies allows you to delegate administrative control while maintaining consistent or similar settings in policies across various administrative groups. For example, you could create the server policy once, and then copy it to the system policy container in each of the other desired administrative groups. Then, the administrator of each individual administrative group could customize policies (from this template) to manage objects that are associated with his or her administrative group.

Note   
Remember that you can copy only individual policies between administrative groups. You cannot copy the system policy container from one administrative group to another.

 

To copy policy objects between administrative groups

1.        In Exchange System Manager, right-click the policy, click Copy, and then paste the policy in your target container.

2.        Right-click the target container, and then click Refresh to view the policy in the container.

After you copy a policy, you need to apply it to the individual servers, mailbox stores, or public folder stores in the administrative group where you copied the policy.

 


Modifying or Removing a Policy

You can modify a policy that is applied to one or more objects to change the properties on all of the objects.

To modify a policy

1.        In Exchange System Manager, right-click the policy that you want to modify, click Properties, and then use the tabs to modify the policy.

2.        After you have made the necessary modifications, right-click the policy, and then click Apply now to apply the changes.

 

To change the properties on all of the objects individually, you can also remove an object from the control of a policy or delete the policy itself.

To remove an object from the control of a policy

1.        In Exchange System Manager, expand System Policies, and then click the appropriate system policy.

2.        In the Policy Applied To column, right-click the object, point to All Tasks, and then click Remove from policy.

 

To delete a policy

·         In Exchange System Manager, right-click the policy that you want to delete, and then click Delete.

 

After a policy has been applied, settings associated with that policy remain intact on associated objects, even after an object has been removed from policy control or a policy itself has been deleted. If you want to change the settings that a policy applies, you must change them on the individual server, mailbox store, or public folder store.


Managing Permissions

As you manage your Exchange organization, some of your most important security tasks will involve permissions. The correct management of permissions in Exchange 2003 ensures that users and administrators can successfully complete those tasks that they need to perform, while preventing users and administrators from intentionally or inadvertently performing inappropriate tasks.

In Exchange 2003, there are three sets of permissions that you can manage:

·       Permissions for Exchange objects. These settings are stored in Active Directory and the Microsoft Internet Information Services (IIS) metabase.

·       Store permissions.

·       File permissions on NTFS volumes.

 

Together, these permissions provide the means to implement security on all elements in an Exchange 2003 installation.

This section focuses on using Exchange System Manager to manage permissions on Exchange objects in Active Directory and the IIS metabase. For detailed information about managing store permissions, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores." For detailed information about understanding and managing NTFS permissions, see the Windows documentation and resource kits.

Important   
You should only use Exchange System Manager to set permissions on Exchange objects.

 

Understanding Exchange Objects and Exchange System Manager

Almost every element in an Exchange installation is represented by an object. For example, the server itself, an SMTP virtual server, and a mailbox store are all represented as objects. Controlling each of these objects is a set of security permissions. Permissions on objects in Exchange 2003 build on permissions that the Windows operating system makes available through Active Directory and IIS. Exchange 2003 uses both Active Directory and the IIS metabase to store permissions information about Exchange objects.

To accommodate the fact that information regarding Exchange objects is in two places, you manage these objects using Exchange System Manager. This tool seamlessly presents objects that are stored in Active Directory and the IIS metabase. Thus, you are able to administer objects stored in two places through a single interface.

The permissions model that Exchange System Manager exposes builds on the Windows security model—an object-oriented security model, based on the concept of discretionary access control. This means that each Exchange object has its own discrete permissions that govern access to the object, and that these permissions can be administered by anyone who has the appropriate permission level. This security model makes it possible to implement delegated security models in which certain roles are assigned varying permissions based on the functional tasks performed by these roles in those environments whose security policy requires that capability.

However, the profusion of objects and permissions that enables Exchange to support complex security requirements can also make it seem complex to administer. Fortunately, Exchange System Manager simplifies managing permissions with the following:

·         Support for inheritance

·         Standardized security roles

·         Exchange Administration Delegation Wizard

 

Together, these features simplify the management of permissions so that most Exchange implementations can implement their security requirements without having to set permissions on individual attributes on individual objects.

Benefiting from Support for Inheritance

In Windows, inheritance describes the process by which the creation of an object results in the object assuming, by default, the permissions of its parent object.

Inheritance simplifies the task of managing permissions in your Exchange system as follows:

·         It eliminates the need to manually apply permissions to child objects as they are created.

·         It ensures that the permissions attached to a parent object are applied consistently to all child objects.

·         When permissions on all objects within a container must be modified, you change the permissions on the container only once. The objects inside the container inherit the changes automatically.

 

For some Exchange objects, you can customize this inheritance. These objects are public folder trees, address lists, and mailbox stores. For these objects, you can specify that the child does not inherit permissions. Or, you can specify that only the following containers or subcontainers inherit permissions:

·         This container only

·         This container and all subcontainers

·         Subcontainers only

 


Inheritance makes it possible for permissions to be applied consistently within an object hierarchy. In itself, inheritance is an important tool for simplifying the application of permissions.

Benefiting from Standardized Security Roles in Exchange

To help simplify the process of managing permissions, Exchange 2003 provides three predefined security roles that are available in the Exchange Administrative Delegation Wizard. These roles are a collection of standardized permissions that can be applied at either the organization or the administrative group level.

Note   
For information about administrative groups, see "Creating and Managing Administrative Groups" earlier in this chapter.

 

When these roles are applied, the accounts or groups against which they are applied are immediately granted a set of standardized permissions on the object in question. Roles rely strongly on permission inheritance to ensure that permissions are applied consistently. When a role is applied, the standard permissions associated with that role are applied down the object hierarchy using inheritance.

Because the roles have been designed to meet the security requirements that are commonly found in an Exchange deployment, you should try to use these roles as much as possible.

The standard security roles that Exchange 2003 provides are:

·         Exchange Full Administrator   This role can fully administer Exchange system information and modify permissions. This role is appropriate for those who need to be able to modify permissions, and view and administer Exchange configuration information.

·         Exchange Administrator   This role can fully administer Exchange system information. This role differs from the Exchange Full Administrator primarily in that it cannot modify permissions. This role is appropriate for those who need to be able to view and administer Exchange configuration information without being able to modify permissions.

·         Exchange View Only Administrator   This role can view but cannot administer Exchange configuration information. This role is appropriate for those who need to be able to view Exchange configuration information without being able to change that configuration information. As with the Exchange Administrator role, this role cannot modify permissions.

Note   
The Exchange security roles should not be confused with security groups in Active Directory. The roles are a collection of standardized permissions that are applied to users or groups within Active Directory. The roles can best be thought of as a template, rather than as a security group.

 


Because these roles are a set of standardized permissions, unlike security groups, roles inherently supersede one other. Therefore it is not necessary to apply both a higher and a lower privileged role. It is enough to apply the higher privileged role. Roles differ slightly, depending on whether they are applied to an organization or an administrative group. Consequently, the effective permissions that result when a role is applied can differ slightly.

Tables 2.1 to 2.3 list the effective permissions, based on the role applied and where it has been applied. These tables help explain how roles supersede each other, and the impact of differences at the organization level and administrative level.

Note   
There is no table that shows the effective role at the organization level from roles applied at the administrative group level. This is because roles applied at the administrative group level apply only to the local administrative group. Because administrative groups are underneath the organization level in the hierarchy, the administrative group can inherit permissions from the organization, but not vice versa.

 

Table 2.1   Effective roles at the administrative group level from roles applied at the administrative group level

Granted Exchange Administrator role

Effective Exchange Administrator role

View Only

Administrator

Full Administrator

Exchange View Only Administrator

Yes

No

No

Exchange Administrator

Yes

Yes

No

Exchange Full Administrator

Yes

Yes

Yes

 

Table 2.2   Effective roles at the administrative group level from roles applied at the organization level

Granted Exchange Administrator role

Effective Exchange Administrator role

View Only

Administrator

Full Administrator

Exchange View Only Administrator

Yes

No

No

Exchange Administrator

Yes

Yes

No

Exchange Full Administrator

Yes

Yes

Yes

 


Table 2.3   Effective roles at the organization level from roles applied at the organization level

Granted Exchange Administrator role

Effective Exchange Administrator role

View Only

Administrator

Full Administrator

Exchange View Only Administrator

Yes

No

No

Exchange Administrator

Yes

Yes

No

Exchange Full Administrator

Yes

Yes

Yes

 

Benefiting from Exchange Administration Delegation Wizard

The Exchange Administration Delegation Wizard applies the standardized security roles at either the organization level or the administrative group level within Exchange System Manager.

It is important to remember that the Exchange Administration Delegation Wizard applies well-tested permissions in a consistent manner against objects in the Exchange hierarchy. Because of this consistency in application of permissions, the wizard is the recommended and preferred method of managing permissions in your Exchange environment. You should only apply customized permissions to individual objects when it is required by your security policy, and after thorough testing. Manually creating customized permissions increases the likelihood of problems, due to human error. It also increases the likelihood of creating inappropriate permissions, due to a misunderstanding of how permissions work. In addition, customized security settings will require increased maintenance because they must be documented, and the customized settings must be verified. Although there are instances where customized security is appropriate, the risks and costs should be weighed carefully.

You can launch the Exchange Administration Delegation Wizard from either the organization level or the administrative group level. As noted in "Benefiting from Standardized Security Roles in Exchange" earlier in this chapter, the permissions associated with the role will then be applied down the hierarchy from the object from which you started the wizard. For example, if you start the wizard at the organization level, the permissions associated with the role will be applied to all objects underneath the organization in the hierarchy, including all administrative groups. Alternately, if you start the wizard at an administrative group, the permissions associated with the role will be applied only to the objects within the administrative group.


When you start the Exchange Administration Delegation Wizard, it prompts you to specify the users and groups to which you want to apply the security role. Generally, it is recommended that you place your users into security groups, and then use the wizard to apply roles against those groups. Applying permissions to individual users can quickly become difficult to manage.

After the wizard is finished, Exchange System Manager applies permissions to the group or the user selected within the hierarchy that the wizard was started from. The permissions are propagated down the hierarchy through inheritance. By using the wizard, it is possible to set all of the permissions on the Exchange objects in both Active Directory and the IIS metabase with only a few clicks.

Note   
For more information about managing store permissions, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores."

 


Chapter 3

Configuring Exchange Server Settings

Chapter 2, "Managing an Exchange Organization," focused on how to apply settings globally within your organization, how to use and manage administrative groups, and how to use system policies to administer groups of servers consistently.

This chapter shifts the focus from the organization-specific settings to server-specific settings. It provides you with information about how to configure settings on individual Exchange servers in your organization. Individual server settings that you can configure include enabling message tracking, configuring language support for clients, scheduling Mailbox Management processes, troubleshooting specific issues with diagnostic logging, using public folder referrals and Directory Access options, and other settings that are important to managing your Exchange server.

Although this chapter does not cover them, you can also manage protocol settings, services, and backup and restore processes on an individual server basis. For more information about:

·         Configuring protocols, see Chapter 5, "Understanding and Configuring Message Routing and Transport," and Chapter 6, "Managing Client Access to Exchange."

·         Exchange services, see Appendix B, "Services Used by Exchange."

·         Backup and restore practices, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores."


Configuring Server-Specific Settings

When you configure server-specific settings, you use the Properties dialog box (see Figure 3.1) that is associated with each server.

To open a server's Properties dialog box

·         In Exchange System Manager, right-click an Exchange server, and then select Properties.

Figure 3.1   The Properties dialog box for SERVER01

 

Of the eleven tabs in the Properties dialog box, this chapter focuses on those tasks associated with the following tabs: General, Locales, Mailbox Management, Directory Access, Policies, Security, Full-Text Indexing, Diagnostic Logging, and Public Folder Referrals.

Viewing Messages in Message Tracking Center

Message Tracking Center tracks messages across servers in both mixed- and native-mode Exchange organizations. Message Tracking Center can also track messages that are destined to or arriving from another messaging system, such as Lotus Notes. Through Message Tracking Center, you can search for all types of messages, including system messages (alerts that are displayed when problems occur), public folder messages, and e-mail messages.

Note   
To search for a specific system message in Message Tracking Center, search for the Message ID. If you do not know the Message ID, you can find system messages manually by reviewing the message tracking logs. Exchange automatically creates these logs if you have message tracking enabled on a server. To search for other types of messages, you can search by sender, recipient, or server.

 

Before enabling a server's messages to appear in Message Tracking Center, you must enable subject logging on the Exchange server. However, enabling this type of logging results in the subject lines of messages in Simple Mail Transfer Protocol (SMTP) and MAPI queues to be displayed in the Subject column of Queue Viewer. By default, the Subject column is left empty to preserve confidentiality. (For example, some Exchange organizations prefer to keep low-level administrators from viewing message subjects.) Therefore, verify your organization's policy about revealing subject line information prior to enabling subject logging.

To enable a server's messages to appear in Message Tracking Center

·         On the General tab in the server's Properties dialog box, select the Enable subject logging and display check box.

Note   
If the Enable subject logging and display check box is unavailable (or appears dimmed), there is a server policy object applied to this server. You must either enable subject logging and display on the policy, or remove the server from this policy. To view which policies are applied to this server, look at the Policies tab. For more information about server policies, see Chapter 2, "Managing an Exchange Organization."

 

Enabling Message Tracking

You can create a server policy to control the message tracking options of a group of servers in an administrative group. However, you can also enable message tracking on an individual server basis. For example, if you do not track messages on all of your servers, but users on a specific Exchange server are experiencing mail flow problems, you may want to enable message tracking on the server that is experiencing mail flow problems. Alternatively, you may want to track messages only on your Internet gateway servers.

When you enable message tracking on an individual server, messages routed through the server are added to the message tracking logs. These logs are text files that you can review to monitor and troubleshoot message flow. The Exchange System Attendant service on each server maintains these log files.

To enable message tracking

·         On the General tab in the server's Properties dialog box, select the Enable message tracking check box.

Note   
If the Enable message tracking check box is unavailable (or appears dimmed), there is a server policy object applied to this server. You must either enable message tracking on the policy, or remove the server from this policy. To view which policies are applied to this server, look at the Policies tab. For more information about server policies, see Chapter 2, "Managing an Exchange Organization."

 

Managing Message Tracking Log Files

If you enable message tracking, you may want to customize how Exchange manages the resulting log files. By default, Exchange stores the message tracking log files in the C:\Program Files\Exchsrvr folder and removes these log files on a seven-day interval. These default settings may or may not fit the needs of your Exchange environment.

Selecting a Location for the Log Files

To specify a path and folder for message tracking log files, you use the Log file directory text box on the General tab of the server's Properties dialog box. When you change the path of the log file directory, Exchange saves future log files to the new path. However, Exchange does not move existing log files to the new location. You must do this manually.

Removing Log Files

If you allow log files to accumulate on the server, they can consume a large portion of disk space and may affect performance. You should review and remove log files periodically. However, make sure to leave log files on the server long enough for you to review files if a problem occurs with the message flow. As an additional step, you can move log files to another disk that has the bandwidth to accommodate larger log files.

To specify how often log files are removed

1.        On the General tab in the server's Properties dialog box, select Remove log files.

2.        In the Remove files older than (days) text box, type the number of days that you want the files to remain on the server before being deleted.

 


Designating a Front-End Server

When you configure a server to be a front-end server, you are usually dedicating the server to receive requests from messaging clients, such as HTTP, Internet Message Access Protocol version 4 (IMAP4), and Post Office Protocol version 3 (POP3), and to relay client requests to the appropriate back-end server.

The services that an Exchange front-end server requires depend on the protocols that you use on the server, and whether you will be making configuration changes after the initial setup. Table 3.1 lists which Exchange services are required for each protocol or tool that an Exchange front-end server uses.

Table 3.1   Services required on an Exchange front-end server

Protocol/tool on server

Services required

POP3

Exchange POP3 (POP3Svc)

Microsoft Exchange System Attendant (MSExchangeSA)

IMAP4

Exchange IMAP4 (IMAP4Svc)

MSExchangeSA

SMTP

Microsoft Exchange Information Store (MSExchangeIS)

MSExchangeSA

Exchange System Manager

MSExchangeSA

Routing Engine

Microsoft Exchange Routing Engine (RESvc)

Note   
The routing engine must be running on all Exchange servers, both front-end and back-end servers.

 

NNTP

Network News Transfer Protocol (NNTP) must be enabled on a server during upgrades.

Note   
You can disable this protocol if you are not offering it to your users.

 

 

To designate a front-end server

·         On the General tab in the server's Properties dialog box, select the This is a front-end server check box.


After designating a server as a front-end server, you should remove any unnecessary components or disable any unnecessary services on the server. Removing these components or disabling these services allows the front-end server to relay client requests more efficiently and improves security by reducing the number of services or components that are vulnerable to attack. In particular, you can remove public folder stores and storage groups from an Exchange front-end server. Also, if your front-end users are not sending mail using SMTP, you can remove mailbox stores from the front-end server.

Important   
To stop or disable services, use the Services snap-in in Microsoft Management Console (MMC).

 

For more information about using a front-end and back-end topology, see Chapter 6, "Managing Client Access to Exchange."

Sending Error Information to Microsoft

Microsoft personnel monitor error reports to identify and correct common problems that customers encounter. If you do not enable the automatic error reporting option, a dialog box appears that prompts you to manually send the fatal error report.

Important   
It is recommended that you send fatal error reports to Microsoft. When you send these reports, Microsoft personnel can respond to you with any available fixes for your reported issue. However, before sending information regarding any fatal service error to Microsoft, you should confirm that sending this information is permitted under your organization's security policy.

 

To send error information to Microsoft

·         On the General tab in the server's Properties dialog box, select the Automatically send fatal service error information to Microsoft check box.

 

When you send error reports to Microsoft, they are sent over Secure HTTP (HTTPS), which is a more secure connection than HTTP.

Note   
To send reports, the server must have HTTP access to the Internet.

 

For more information about automatic error reporting, see the "Microsoft Online Crash Analysis" Web site (http://go.microsoft.com/fwlink/?LinkId=18428).


Configuring Language Settings

Different countries and regions have differing conventions regarding the formatting and presentation of information such as date, time, and currency. To accommodate these differences, you use the Locales tab to define how to display date, currency, and time values, and to define how to control other international settings, such as sorting order.

For each locale listed on the Locales tab, the server is able to supply clients with data sorted and formatted according to the conventions used in that locale. For example, if Hindi appears in the list, Hindi language clients that connect to the server see information sorted and formatted in Hindi.

To add a locale to the server

1.        On the Locales tab in the server's Properties dialog box, click Add (see Figure 3.2).

Figure 3.2   Locales tab

 


2.        In the Add Locale dialog box (see Figure 3.3), select a language, and then click OK.

Figure 3.3   Add Locale dialog box

 

Note   
You can also remove locales by selecting a locale on the Locales tab and then clicking Remove.

 

Scheduling Mailbox Manager Processes

Exchange Mailbox Manager policies set age and size limits for messages. After you create and configure a recipient policy for Mailbox Manager settings, you must schedule when the Mailbox Manager process runs on a server and whether the process generates a report. When a policy runs, the policy processes messages that exceed its defined limits. For more information about Mailbox Manager and recipient policies, see Chapter 4, "Managing Recipients and Recipient Policies."

Important   
Mailbox Manager works only on local mailboxes on an individual Exchange server. You cannot configure Mailbox Manager on one server to process mailboxes on a different server.

 


To schedule when the Mailbox Manager process runs and whether the process generates a report, you use the Mailbox Management tab (see Figure 3.4) in the server's Properties dialog box.

Figure 3.4   Mailbox Management tab

 


Defining a Schedule

In the Start mailbox management process drop-down list, you select when you want the Mailbox Management process to start (on that particular server) according to the rules defined by associated recipient policies. The recipient policies that are associated with the server determine which mailbox or mailboxes that Mailbox Manager cleans.

To define a schedule

·         On the Mailbox Management tab in the server's Properties dialog box, in the Start mailbox management process list, select a schedule, and then click OK.

Tip   
You can manually start Mailbox Manager at any time by right-clicking the server object and then selecting Start Mailbox Management Process. If you use this command, Mailbox Manager still runs at its next scheduled interval.

 

You can also customize the mailbox management schedule to suit your organizational needs. For example, you could create a custom schedule that runs Mailbox Manager on Saturday at midnight.

To define a custom schedule

·         On the Mailbox Management tab in the server's Properties dialog box, in the Start mailbox management process list, select Use custom schedule, click Customize, and then enter the schedule information.

Setting Reporting Options

When you schedule Mailbox Manager, you can designate a mailbox that receives Mailbox Manager reports. You can also select the type of report to be generated. The report can include different types of information, such as when Mailbox Manager ran, which mailbox recipient policies were applied, which mailboxes were processed, which folders were processed, the number of messages that were moved or deleted, and the size of messages that were moved or deleted.


To set reporting options

1.        On the Mailbox Management tab in the server's Properties dialog box, in the Reporting drop-down list, select the type of report that you want created whenever mailboxes are processed:

·         A summary report that contains basic information, including the total size of all messages that Mailbox Manager moved or deleted.

·         A detailed report that includes the specific policies that Mailbox Manager ran, the specific mailboxes that were processed, and the specific folders within each mailbox that were processed each time Mailbox Manager runs.

2.        In the Administrator text box, click Browse, and then select a mailbox in your organization to receive these reports.

 

Configuring Diagnostics Logging on a Server

Diagnostics logging levels determine which additional Exchange events are written to the Application event log in Event Viewer, a Microsoft Windows Server™ 2003 component that you can use to monitor hardware and software activities. You can use diagnostics logging to record significant events that are related to authentication, connections, and user actions.

The first step in configuring diagnostics logging is to decide which services on an Exchange server should be enabled for diagnostics logging (see Table 3.2).

Note   
You configure diagnostics logging separately for each service on each server. For example, if you enable protocol logging on an individual virtual server, it is the setting on the Exchange server on which the virtual server runs that determines the logging capabilities for the protocol.

 


Table 3.2   Diagnostics logging services

Service

Description

IMAP4Svc

Allows users to access mailboxes and public folders through Internet Message Access Protocol version 4 (IMAP4).

MSADC

Runs connection agreements if Active Directory Connector is installed.

MSExchangeAL

Logs events when the Recipient Update Service updates address lists and e-mail addresses in the Microsoft® Active Directory® directory service.

MSExchangeDSAccess

Allows Exchange access to Active Directory.

MSExchangeIS

Allows access to the Exchange store.

MSExchangeMTA

Allows X.400 connectors to verify whether the message transfer agent (MTA) is being used.

MSExchangeMU

Replicates Exchange configuration information changes to the Internet Information Services (IIS) metabase.

MSExchangeSA

Handles many core Exchange tasks, such as mailbox management, e-mail proxy generation, offline address list generation, and monitoring.

Note   
This service is also known as Microsoft Exchange System Attendant.

 

MSExchangeSRS

Replicates computers running Microsoft Exchange 2000 Server (or later) with computers running Microsoft Exchange Server version 5.5.

Note   
This service is also known as Site Replication Service (SRS).

 

MSExchangeTransport

Controls message routing and transport functions in Exchange. If you experience mail flow problems, set diagnostics logging for this service.

POP3Svc

Controls the operation of POP3.

 


After selecting a service, the next step is to set the logging levels for those services. There are four logging levels of detail (see Table 3.3). When Exchange generates an event less than or equal to the logging level, the event is logged. Events range from significant events (such as application failures) to moderately important events (such as the receipt of messages across a gateway) to events that are relevant only to debugging. Usually, you log only critical events. However, when problems occur, diagnostics logging enables you to change the logging levels to capture more events in greater detail.

Table 3.3   Logging levels

Logging levels

Description

None

Only critical events, error events, and events with a logging level of zero are logged.

Note   
This is the default level for all services on Exchange servers.

 

Minimum

Events with a logging level of 1 or lower are logged.

Medium

Events with a logging level of 3 or lower are logged.

Maximum

Events with a logging level of 5 or lower are logged.

 

After selecting a logging level, logging begins automatically whenever you start Exchange. You can view the log entries in Event Viewer.

To configure diagnostics logging

1.        On the Diagnostics Logging tab in the server's Properties dialog box, in the Services list, select an Exchange 2003 service (see Table 3.2) on which you want to set category logging levels.

2.        In the Categories list, select the categories and logging levels (see Table 3.3) that you want to configure.

 


Customizing Public Folder Referrals

When a user connects to a public folder store that does not contain a copy of the public folder content that the user is looking for, Exchange redirects or refers the user to another public folder store that does have a copy of the content. By default, Exchange attempts to redirect the user to a server within the local routing group. If those servers do not have the required content, Exchange follows the organization's routing group topology to find an appropriate server. Exchange finds an appropriate server based on the most efficient routing path, using costs of connectors between routing groups.

Note   
For additional information about public folder referrals, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores." For more information about routing in Exchange, see Chapter 5, "Understanding and Configuring Message Routing and Transport."

 

Because Exchange keeps track of available connections between routing groups and uses the most efficient route possible, it is recommended that you use routing groups (the default) to determine how Exchange refers a user to another public folder. However, if you need to troubleshoot a specific server, or if you are performing maintenance on part of your network and want to designate specific servers that are available during this maintenance, you can create a custom list of servers for public folder referrals.

Note   
A custom list for public folder referrals is new in Exchange 2003. In Exchange 2000, you could only specify whether or not to allow public folder referrals among routing groups.

 

To create a custom list of servers for public folder referrals, you use the Public Folder Referrals tab (see Figure 3.5). When you create a custom list of servers, you also assign costs to prioritize the servers in your referral list.


To specify a custom list for public folder referrals

1.        On the Public Folder Referrals tab in the server's Properties dialog box (see Figure 3.5), in the Public folder referral options list, select Use Custom List.

Figure 3.5   Public Folder Referrals tab

 

2.        Click Add to add the appropriate servers.

 


Assigning Costs on the Public Folder Referrals List

Costs are a method of prioritizing servers in the public folder referral list. You define costs for each connector within your organization using network connectivity and available bandwidth as criteria. You then assign the lowest cost to the connectors that have the best network connectivity and the most available bandwidth. Exchange uses higher-cost servers only if lower-cost servers are not available.

When you select the Use Custom List option and create a list of servers that are available for referrals, the Public Folder Referrals tab displays both the name of each server in the list and any costs that are associated with those servers. If you want to prioritize the order in which Exchange uses the listed servers, you need to change the costs associated with each server, assigning lower costs to those servers that you want Exchange to use first.

To change a server's priority in a custom public folder referrals list

1.        On the Public Folder Referrals tab in the server's Properties dialog box, select a server in the list, and then click Modify.

2.        In the Modify Referral Cost dialog box (see Figure 3.6), specify a cost for that server.

Figure 3.6   Modify Referral Cost dialog box

 


Understanding Directory Access Options

As discussed in Chapter 1, "Preparing to Administer Exchange Server 2003," and Chapter 2, "Managing an Exchange Organization," Exchange is tightly integrated with Active Directory. This integration requires that the core components of Exchange 2003 access directory information in Active Directory. The shared component called Directory Access (DSAccess) controls how most components (see Table 3.4) in Exchange interact with Active Directory.

Table 3.4   Exchange components dependent on DSAccess

Component

Dependency on DSAccess

Exchange Metabase Update (DS2MB)

Directory changes tracked by update sequence number (USN)

Exchange Routing Engine (RESVC)

User and configuration lookups

SMTP Categorizer (SMTP CAT)

List of global catalog servers in the topology

Directory Service Proxy (DSProxy)

List of global catalog servers in the topology

Exchange Information Store

User and configuration lookups

WebDAV

User and configuration lookups

Message transfer agent (MTA)

User and configuration lookups

 


In Exchange 2003, DSAccess is the centralized mechanism that determines the Active Directory topology, opens the appropriate Lightweight Directory Access Protocol (LDAP) connections, and works around server failures. DSAccess is responsible for the following functions:

·         Retrieving and writing information from Active Directory, such as configuration data and recipients.

·         Caching information from Active Directory for better performance when querying Active Directory. DSAccess caches configuration and recipient data locally so that this information is available for subsequent queries from other Exchange servers. Caching information locally has the additional benefit of preventing the network traffic that is caused by additional queries to Active Directory.

·         Constructing a list of available domain controllers and global catalog servers that other Exchange components can query. For example:

·         The MTA routes LDAP queries through the DSAccess layer to Active Directory.

·         To connect to databases, the store process uses DSAccess to obtain configuration information from Active Directory.

·         To route messages, the transport process uses DSAccess to obtain information about the connector arrangement.

 

Of the previously listed functions, the only function that you can control on a server is the one that deals with constructing a list of available domain controllers and global catalog servers. You can have this list constructed automatically by DSAccess, or you can manually create this list for DSAccess to use.


Automatically Constructing a Topology for Directory Access

By default, on each Exchange server, DSAccess automatically detects the appropriate domain controllers and global catalog servers in Active Directory for the Exchange server to query. The setting that controls this default behavior is the Automatically discover servers check box near the bottom of the Directory Access tab in the server's Properties dialog box (see Figure 3.7).

Figure 3.7   Directory Access tab

 


Selecting the Automatically discover servers check box enables DSAccess components to automatically discover the following servers in an Exchange organization:

·         Configuration domain controller   The single domain controller that reads and writes information in the configuration naming context in Active Directory. DSAccess chooses a domain controller or global catalog server to act as the configuration domain controller. All configuration data is written and read by this configuration domain controller.

·         Working domain controllers   As many as ten domain controllers that perform Active Directory lookups for objects in the local domain. These domain controllers are primarily used to update objects within the local domain or read non-configuration data that is not replicated to global catalog servers.

·         Working global catalog servers   As many as ten global catalog servers that perform forest-wide queries. All user data is looked up on the global catalog servers.

 

To discover these servers, Directory Access locates domain controllers and global catalog servers that run Microsoft Windows Server 2003, or Microsoft Windows® 2000 Server Service Pack 3 (SP3) or higher. Directory Access then tests these servers and chooses suitable servers for Exchange services to use to perform Active Directory queries.

Note   
Because manually constructed topologies do not update automatically, it is strongly recommended that you use the Automatically discover servers setting.

 

Manually Constructing a Topology for Directory Access

To troubleshoot problems with a specific global catalog server or domain controller, you may want to override the automatic discovery of servers by clearing the Automatically discover servers check box. For example, to determine whether queries to a global catalog server are working correctly, you can manually set this server as the only available global catalog server.


When you manually create a topology for DSAccess, you no longer have the advantages of automatic failover and load balancing that you have when DSAccess automatically discovers the topology. If a server that you set manually becomes unavailable, the list does not update and Exchange still attempts to use the unavailable server, thereby causing Exchange to fail.

If you manually set a domain controller or global catalog server on the Directory Access tab in the Properties dialog box of a server that is not running Windows 2000 Server SP3 or later, Exchange will not use the domain controller or global catalog server, and Exchange logs an Event 2116.

To manually create a topology for Directory Access

1.        On the Directory Access tab in the server's Properties dialog box, in the Show list, select the type of servers that you want to view.

Note   
You cannot clear the Automatically discover servers check box if you select All Domain Controllers in the Show list.

 

2.        Clear the Automatically discover servers check box.

This clears the current list of servers.

Warning   
By default, DSAccess automatically discovers servers. It is strongly recommended that you keep this setting.

 

3.        Click Add to add servers to or click Remove to remove servers from the topology.

 

Viewing System Policies Applied to the Server

System policies facilitate flexible administration of large numbers of Exchange services. A system policy defines settings that you apply to one or more Exchange servers. For example, you can use a system policy to create a consistent method of tracking messages across a group of servers.


Because policies affect a group of servers, you can only view the policies that have been applied to a server on the Policies tab (see Figure 3.8) in the server's Properties dialog box. You cannot modify or remove those policies using this tab. To modify or remove a system policy that has been applied to a particular server, you must change the policy itself. For more information about system policies, see Chapter 2, "Managing an Exchange Organization."

Figure 3.8   Policies tab

 


Setting Server-Specific Permissions

Permissions control access to Exchange objects. You can set permissions on some Exchange objects individually. These objects include public folder trees, address lists, mailbox stores, protocols, and servers. For these objects, Exchange uses and extends Active Directory permissions. Examples of Active Directory permissions are Read, Write, and List contents. Examples of extended Exchange permissions are Create public folder and View Information Store status. When you look at an object's permissions, Active Directory permissions appear first in the list, followed by Exchange extended permissions.

Permissions in Exchange are inherited by default. For example, the permissions that you apply to a particular server are inherited by the objects that the server contains, such as the public folder and mailbox stores on that server. Inherited permissions are convenient because you do not have to set the permissions for every object in your Exchange organization manually.

Important   
When setting permissions on Exchange objects, use Exchange System Manager. Do not set permissions on Exchange objects using Windows Server 2003 MMC snap-ins, such as the Active Directory Sites and Services or Active Directory Users and Computers.

 

You can set permissions using the Exchange Delegation Wizard and apply these settings to an entire Exchange organization or to a specific administrative group. Because permissions are inherited, these permissions control who can view or modify settings at the server level. By default, these permissions are configured to support the standard Exchange administrator types (Exchange View Only Administrator, Exchange Administrator, and Exchange Full Administrator). You are strongly advised to use the standard Exchange administrator types and only change the settings if more granular settings are required by your organization's security policy.

Note   
For more information about the Exchange Delegation Wizard, see Chapter 2, "Managing an Exchange Organization."

 


To modify permissions on a specific server

1.        On the Security tab (see Figure 3.9) in the server's Properties dialog box, in the Group or user names list, select the group or user name for which you want to modify permissions.

Figure 3.9   Security tab

 

2.        In the Permissions for <selected entry> list, select the appropriate permissions.

 

Configuring System Resource Usage During Full-Text Indexing

Exchange can create and manage indexes for fast searches and lookups. With full-text indexing, Exchange indexes every word in a database, making faster searching possible. Full-text indexing is a feature that you can configure for individual stores on a server, and optimize on a server-by-server basis across your Exchange organization. For more information about how to configure full-text indexing to support your Exchange organization, see Chapter 4, "Managing Recipients and Recipient Policies" and Appendix F, "Using Full-Text Indexing."

Full-text indexing allows IMAP4 clients and MAPI clients, such as Microsoft Office Outlook®, to conduct full-text searches. For Outlook users, the version of Outlook determines what search options the user has:

·         In Outlook 2002, both the Find and Advanced Find options on the Tools menu initiate a full-text search.

·         In Outlook 2000, only the Advanced Find option initiates a full-text search. The Find option initiates a character-based search.

 

Indexing is a resource-intensive feature that requires considerable CPU cycles. Indexing gigabytes of data can take hours or days. You should schedule indexing at times when the server is not under usage load.

To control server performance during indexing

·         On the Full-Text Indexing tab (see Figure 3.10) in the server's Properties dialog box, in the System resource usage list, select a usage level: Minimum, Low, High, or Maximum.

Note   
To limit the CPU resources that the indexing service occupies, set the server usage level to a lower value (Minimum or Low).

 

Figure 3.10   Full-Text Indexing tab

 


Chapter 4

Managing Recipients and Recipient Policies

This chapter explains what recipients and recipient policies are, and how to create and manage recipients. The chapter also includes information about address lists and the Recipient Update Service. Basic concepts about recipients are explained in the beginning of this chapter. The remainder of the chapter focuses on creating and managing recipients, recipient policies, and address lists. This chapter also includes detailed information about a new feature in Microsoft® Exchange Server 2003—the query-based distribution list.

Understanding Recipients

Central to any messaging system are the people and resources that receive messages. An individual may receive a message from a coworker, or a public folder may receive a message from a participant in a particular discussion.

Although messages are received by people, the term recipients refers to Microsoft Active Directory® directory service objects, not people. Recipients are Active Directory objects that have messaging capabilities. However, the object itself does not receive messages. The messages are not stored in Active Directory. Instead, they can reside in a mailbox on an Exchange server, in a public folder, or in another messaging system.

People access messages that are sent to them by using a client application. Examples of client applications include Microsoft Outlook®, Outlook Web Access, and Outlook Mobile Access. Each of these clients receives notification when a new message arrives and receives pointers to the location of the message, so that the message can be opened and read.


The following scenario explains the distinction between the person who receives e-mail messages and Active Directory objects. Carole, a member of the marketing team, has a user account that allows her to type her user name and password to log on to her computer and her company's network. After logging on, she has access to several network resources, one of which is her Exchange mailbox. Carole accesses her mailbox with an e-mail client, Outlook 2002. Outlook queries her Exchange mailbox and presents Carole a list of messages in her Outlook Inbox. When Carole opens one of these messages, Outlook retrieves the contents of the message from the message store on the Exchange server that houses her mailbox.

As shown in Figure 4.1, there is a recipient that is an Active Directory user object named carole. Mail that is addressed to carole is stored in an associated mailbox on an Exchange server. When the proper credentials are sent to the domain controller for user object carole, the contents of the mailbox become available to the e-mail client.

Figure 4.1   Users authenticate to Active Directory and then use mail clients to access the contents of their Exchange mailbox

 

So, in Exchange, the term recipient refers to an Active Directory object that is mailbox-enabled or mail-enabled. Mailbox-enabled recipients can send, receive, and store messages. Mail-enabled recipients can only receive messages.

Table 4.1 describes the Active Directory objects that can be Exchange recipients.


Table 4.1   Exchange recipient objects

Active Directory object

Type of recipient

Description

Users

Mailbox-enabled

Mail-enabled

Users can log on to networks and access domain resources. Users can be added to groups and appear in the global address list (GAL).

Mailbox-enabled users can send and receive messages and store messages on their Exchange server.

Mail-enabled users can receive messages at an external e-mail address only. They cannot send or store messages on Exchange.

InetOrgPerson

Mailbox-enabled

Mail-enabled

A user object that has had its properties extended to improve compatibility with directory services that use the InetOrgPerson object. As a recipient, InetOrgPerson has the same characteristics as a user object.

To mail-enable or mailbox-enable an InetOrgPerson object, you must have a Microsoft Windows Server™ 2003 domain controller and an Exchange 2003-only environment (no servers running Exchange 2000 Server or Exchange Server version 5.5).

Note   
For more information about the Lightweight Directory Access Protocol (LDAP) inetOrgPerson object class, see RFC 2798, "Definition of the inetOrgPersonLDAP Object Class" (http://go.microsoft.com/fwlink/?LinkId=18610).

 

Contacts

Mail-enabled

Contacts are objects that contain information about people or organizations outside of the Exchange organization. Mail-enabled contacts can receive e-mail messages at an external e-mail address. They can be added to distribution lists and appear in the GAL. Contacts cannot access network resources.

Groups

Mail-enabled

A group is an object that can contain users, InetOrgPerson objects, contacts, public folders, and other groups.


 

Active Directory object

Type of recipient

Description

Query-based distribution groups

Mail-enabled

Query-based distribution groups are similar to standard distribution groups, except that they use an LDAP query to dynamically build the group membership. The query is run when a message is sent to the query-based distribution group. When you create a query-based distribution group, you select the criteria for the query.

Public folders

Mail-enabled

Public folders are repositories for messages and other files that can be accessed by users on the network.

 

Note   
Although public folders are recipients, they are different from the other recipient types mentioned here. For more information about public folders, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores."

 

Understanding Recipient Policies

To receive letters and packages, a person must have a mailing address to give to senders. This mailing address could be a business address, the physical address of his or her home, or a post office box. Likewise, for a recipient to receive messages in an Exchange mailbox, the recipient must have an e-mail address.

To generate e-mail addresses for each recipient in an organization, you use recipient policies. This section focuses on how recipient policies manage these e-mail addresses, as well as how recipient policies manage mailboxes using the Mailbox Manager.

Note   
Recipient policies also establish the mail domain for which Exchange accepts incoming mail. For more information, see Chapter 5, "Understanding and Configuring Message Routing and Transport."

 


Managing E-Mail Addresses

A recipient policy that manages e-mail addresses has the following characteristics:

·         It applies to a selected group of recipients.

·         It always contains information about the address types that are to be applied to those recipients.

·         It is given a priority, so that administrators can control which address is applied as the primary address to a recipient that may appear in more than one policy.

 

Example Scenario

The Exchange administrator for Fourth Coffee wants to create three e-mail addresses for recipients in the organization. The first is for the board of directors, the second is for the employees of the company who work in New York, and the third is for the remainder of the employees at the home office. He creates three recipient policies, as shown in Table 4.2.

Table 4.2   Policies and their priorities

Policy

Priority

SMTP address

Board of Directors

1

@board.fourthcoffee.com

New York Employees

2

@newyork.fourthcoffee.com

Default

lowest

@fourthcoffee.com

 


Table 4.3 shows information for three different users.

Table 4.3   User information for Fourth Coffee personnel

Name

Office

Board

Jonathan Haas

New York

Yes

Yale Li

New York

No

Britta Simon

Portland

No

 

The first recipient policy, Board of Directors, runs and finds Jonathan Haas in the list of board members. His address is set to <alias>@board.fourthcoffee.com. The next policy, New York Employees, runs. It finds Jonathan Haas again. However, because a policy with a higher priority has already been applied to him, no action is taken. The policy continues running and finds Yale Li. No previous policy has applied to Yale, and Yale Li's address becomes <alias>@newyork.fourthcoffee.com. Finally, the default policy runs. Because no previous policy has applied to Britta Simon, her address becomes the default address, <alias>@fourthcoffee.com.

You may want to apply more than one address to a group of recipients. In the preceding example, if everyone in the company should receive e-mail messages at <alias>@fourthcoffee.com, that address must be included in all three recipient policies. When you have more than one address in a recipient policy, only one address is considered the primary address per address type. This means that you can only have one primary Simple Mail Transfer Protocol (SMTP) address and one primary X.400 address. You could have 10 SMTP addresses for one recipient, but only one of those can be the primary SMTP address.

The difference between primary and secondary addresses is that the primary address serves as the return e-mail address. When mail is received from a recipient, the primary address determines which address the mail appears to have come from. Recipients can receive mail sent to any of the addresses associated with them. Table 4.4 shows the primary and secondary e-mail addresses of the three people in the scenario.


Table 4.4   Primary and secondary e-mail addresses

Name (alias)

Receive mail sent to

Send mail from (primary e-mail
address only)

Jonathan Haas (Jon)

Jon@board.fourthcoffee.com

Jon@fourthcoffee.com

Jon@board.fourthcoffee.com

Yale Li (Yale)

Yale@newyork.fourthcoffee.com

Yale@fourthcoffee.com

Yale@newyork.fourthcoffee.com

Britta Simon (Britta)

Britta@fourthcoffee.com

Britta@fourthcoffee.com

 

Notice that Jonathan Haas is in the New York office, yet does not have the <alias>@newyork.fourthcoffee.com address. To have this secondary address, it would be necessary to include it in the recipient policy that applies to him. However, the policy with the highest priority that applies to Jonathan is the Board of Directors policy. Because the members of the board of directors all work in different states, the policy does not include <alias>@newyork.fourthcoffee.com. To add <alias>@newyork.fourthcoffee.com to Jonathan, you can manually add a secondary address in Active Directory Users and Computers, or you can programmatically add <alias>@newyork.fourthcoffee.com as a secondary address to all employees in the New York office.

Note   
This example scenario shows how recipient policies are applied. The behavior of recipient policies differs when co-existing with Exchange Server 5.5.

 

Managing Mailboxes Using Mailbox Manager

In addition to generating and assigning addresses to recipients, recipient policies can be used to manage mailboxes using Exchange Mailbox Manager. Mailbox Manager sets age and size limits for messages, and then it finds and processes messages that exceed those limits.

There is no default policy that enforces age or size limits for messages. When you create the first such policy, the default limits of 30 days and 1,024 kilobytes (KB) are applied to every folder in a mailbox. A message must exceed both limits before Mailbox Manager will process it. Under the default settings, a 500-KB message will never be processed, no matter how old it is.


Before Mailbox Manager will run, you must start the mailbox management process on the server object in Exchange System Manager. To start the mailbox management process, you use the Mailbox Management tab of the Properties dialog box for the server object (see Figure 4.2). For more information, see "Scheduling Mailbox Manager Processes" in Chapter 3, "Configuring Exchange Server Settings."

Figure 4.2   Starting the mailbox management process

 

What happens when Mailbox Manager processes a message depends on the setting that you choose when creating the policy. By default, only a report is generated. No further action is taken. In addition to the default setting, there are three other options for how Mailbox Manager processes messages that exceed the specified limits. Table 4.5 describes all four of these Mailbox Manager options.


Table 4.5   Mailbox Manager options

Option

Description

Generate report only
(default)

No messages are moved or deleted, but an administrator report is generated that indicates which mailboxes contain items that exceed the limits defined by the mailbox recipient policy.

Move to Deleted Items folder

Messages are moved to the Deleted Items folder in each client mailbox. Messages are handled as if deleted by the client. Users can remove them from the Deleted Items folder if they want to.

Move to System Cleanup folders

A partial replica of the folder hierarchy of the mailbox is created under a root folder called System Cleanup. Affected messages are moved into the appropriate subfolder of the System Cleanup folder. This feature gives users a way to recover recently deleted items, without losing information about the original folder location of the items.

Delete immediately

Messages are immediately deleted from client view without being moved to either the Deleted Items or System Cleanup folder.

 

You can use the same limits for every folder that the mailbox recipient policy applies to, or set custom limits on a folder-by-folder basis. Each folder must be configured individually if its limits differ from the default limits.

Creating Recipients

Recipients can either be created manually using Active Directory Users and Computers or programmatically using APIs. This section focuses on manually creating mailbox-enabled and mail-enabled objects, including distribution groups. For information about public folder creation, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores." For information about programmatically creating recipients, download the Exchange Software Development Kit (SDK) or view it online from the Exchange developer center (http://msdn.microsoft.com/exchange).


Mailbox-Enabled and Mail-Enabled Recipients

This section focuses on creating mail-enabled objects with the following notes and exceptions:

·         Public folders are mail-enabled recipients that differ significantly from other recipients. For more information about public folders, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores."

·         InetOrgPerson objects can be mail-enabled only if you have a Windows Server 2003 domain controller and have only Exchange 2003 servers in your organization.

·         Mail-enabled groups are covered in their own section that follows.

·         Some Active Directory objects, such as computers and printers, cannot be made into recipients.

 

To create a new Active Directory object that can be mail-enabled or mailbox-enabled, use Active Directory Users and Computers, as shown in Figure 4.3.

Figure 4.3   Creating a recipient using Active Directory Users and Computers

 

When you create a recipient object on a network where Exchange is already installed, the recipient will be mailbox-enabled or mail-enabled by default. Clear the Create an Exchange mailbox check box (as shown in Figure 4.4) if you do not want to mail-enable or mailbox-enable the Active Directory object.

Note   
To see the options that are specific to Exchange, you must have the Exchange system tools installed on the computer that is being used to create users in Active Directory Users and Computers. Users created on computers without Exchange system tools installed will not have mailboxes created by default.

 

Figure 4.4   Clear the check box for the object not to be a recipient

 


To make an existing Active Directory object a recipient

1.        In Active Directory Users and Computers, right-click the object, and then select Exchange Tasks.

2.        On the Available Tasks page (see Figure 4.5) in the Exchange Task Wizard, select Create Mailbox or Establish E-mail Address.

Figure 4.5   Using Exchange Task Wizard to mail-enable or mailbox-enable an existing user object

 

Note   
If Create Mailbox is not available, the object cannot be mailbox-enabled. However, if Delete Mailbox is listed instead, the object already has a mailbox associated with it. Each recipient can have only one Exchange mailbox.

 

Mail-Enabled Groups

Groups are used to assemble Active Directory objects under one name. This reduces the overhead required to manage users, especially those with similar needs. For example, you may have a network resource, such as a public folder, that everyone on your marketing team needs to access. You could give each individual on the team permissions to that folder, or you could create a security group called "marketing" and add each member of the marketing team to that group. Then, you can give the group permission to the folder. After a group has been established, you can give that group access to other resources, such as additional public folders, without having to locate every member of the marketing team each time.

There are two main types of groups: security and distribution. Security groups are security principals in Active Directory. This means that security groups can be set in the access control list (ACL) of a resource, such as a network share or public folder. Distribution groups exist for sending e-mail messages to collections of users. In a Microsoft Windows® environment without Exchange, there are limited uses for distribution groups. Both security and distribution groups can be mail-enabled. They cannot be mailbox-enabled because they represent a collection of users.

Creating Mail-Enabled Groups

A mail-enabled group represents a collection of recipient objects. Its purpose is to expedite the distribution of messages to multiple e-mail addresses. Create a group as you would any other recipient object. Notice, however, that Create an Exchange e-mail address is not selected by default for groups. To enable the group for mail, select Create an Exchange e-mail address during the process of creating the group (see Figure 4.6).

Figure 4.6   Creating a group that is enabled for mail

 


To enable an existing group for mail

1.        In Active Directory Users and Computers, right-click the group, and then click Exchange tasks.

2.        On the Available Tasks page (see Figure 4.7) in the Exchange Task Wizard, select Establish E-mail Address on Groups.

Figure 4.7   Using Exchange Task Wizard to enable an existing group for mail

 

Expanding Mail-Enabled Groups

When mail is sent to a mail-enabled group, the group is first expanded, and then mail is sent to each of the recipients in the group. Unless an expansion server (a server that is responsible for expanding distribution groups) is specified, the group will be expanded on the first Exchange server that handles the message.

Expansion of large groups can tax system resources on an Exchange server. For large distribution groups, you may want to designate a dedicated expansion server to alleviate the workload of the other production servers. Mail sent to large distribution groups will not slow the Exchange servers that your users use to access their mailboxes.

There is a drawback to setting a specific server as the expansion server for a group: If that server is unavailable, no member of the distribution group receives the message. However, if you leave the default setting, Any Server in the Organization, most of the users receive their messages if one server fails. Also, if all members of a distribution group are on well-connected servers, setting a specific expansion server may be unnecessary.

For information about setting specific expansion servers, see "Managing Recipient Settings" later in this chapter.

Using Mail-Enabled Groups in Multi-Domain Environments

To expand distribution lists into individual recipients, Exchange contacts a global catalog server. The global catalog server has a copy of all global and universal groups in its domain and a copy of universal groups from other domains, but it does not have a copy of global groups from other domains. This becomes important in multi-domain environments because if a message is destined for a global distribution group in a domain that is separate from the global catalog server, Exchange cannot expand the distribution group on that message. Because the global catalog server does not have copies of the membership of global groups for domains outside of its own, it does not contain any information about the distribution list. Therefore, the categorizer cannot expand the distribution list. To avoid this problem, you should always use universal distribution groups in multi-domain environments. Use global groups within single domains only.

Understanding Query-Based Distribution Groups

A query-based distribution group is a new type of distribution group introduced in Exchange 2003. This section explains what a query-based distribution group is, how it works, and how to create one.

Query-Based Distribution Groups Described

A query-based distribution group provides the same functionality as a standard distribution group. However, instead of specifying static user memberships, you can use an LDAP query (for example, "All full-time employees in my company") to dynamically build membership in a query-based distribution group. This results in much lower administrative costs because of the dynamic nature of the distribution group. However, query-based distribution groups have a higher performance cost for queries whose outcome produces a large number of results. This cost is in terms of server resources, such as high CPU usage and increased memory usage. This increased usage occurs because every time an e-mail message is sent to a query-based distribution group, an LDAP query is executed against Active Directory to determine its membership.

Important   
You cannot view the membership of a query-based distribution group in the GAL because it is dynamically generated each time mail is sent.

 

Query-based distribution groups work reliably in the following topologies:

·         Exchange 2003-only environment (no Exchange servers prior to Exchange 2003) running in native mode.

·         Exchange 2000 Service Pack 3 (SP3) and Exchange 2003 in native mode. If you have Windows 2000 global catalog servers in this scenario, you can modify a registry key on the Exchange 2000 SP3 servers to increase reliability. This modification is covered in the next section.

 

If you are running versions of Exchange prior to Exchange 2000 SP3 in your environment, query-based distribution groups will not work reliably.

Modifying Exchange 2000 SP3 Servers for Use with Windows 2000 Global Catalog Servers

Use the following procedure to configure an Exchange 2000 SP3 server for improved reliability in environments where query-based distribution groups will be expanded with Windows 2000 global catalog servers.

Warning   
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

 

To modify your Exchange 2000 SP3 server

1.        Start Registry Editor.

2.        In Registry Editor, locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC
\Parameters

3.        In the details pane, right-click, point to New, and then click DWORD Value.

4.        Type DynamicDLPageSize for the name.

5.        Right-click DynamicDLPageSize, and then click Modify.

6.        Under Base, click Decimal, and then click OK.

7.        In Edit DWORD Value, under Value Data, type 31.

Note   
You need only do this for Exchange 2000 servers that use Windows 2000 global catalog servers.

 


How Query-Based Distribution Groups Work

When a message is submitted to a query-based distribution group, Exchange handles the message slightly differently from messages destined for other recipients. A query-based distribution group flows through Exchange to the proper recipients as follows:

1.        E-mail messages are submitted through the Exchange store driver or SMTP to the submission queue.

2.        The categorizer, a transport component that is responsible for address resolution, determines that the recipient is a query-based distribution group.

3.        The categorizer sends the LDAP query request to the global catalog server.

4.        The global catalog server runs the query and returns the set of addresses that match the query.

5.        After receiving the complete set of addresses that match the query, the categorizer generates a recipient list containing all of the users. The categorizer must have the complete set of recipients before it can submit the e-mail message to routing. Therefore, if an error occurs during the expansion of the query-based distribution group to its individual recipients, the categorizer must restart the process.

6.        After the categorizer sends the complete, expanded list of recipients to routing, the standard message delivery process continues, and e-mail messages are delivered to the mailboxes of the recipients.

 

The process differs if a dedicated expansion server is used for query-based distribution groups. In this case, rather than sending a query to the global catalog server for expansion as discussed in Step 3, the e-mail message is first routed to the dedicated expansion server. After the message arrives at the expansion server, the expansion occurs, and the delivery follows the same process as described earlier. The expansion server must be an Exchange 2000 SP3 server or later.

Deployment Recommendations for Query-Based Distribution Groups

The time that Exchange requires to expand a query-based distribution group and run the query depends on several factors, as follows:

·         Type of hardware deployed in your organization   The categorizer can require up to 2 KB of memory for each recipient. This is a conservative metric that you can use as a baseline. Using this baseline, if you send an e-mail message to a query-based distribution group of 6,000 users (meaning that the query returns 6,000 records), the categorizer requires 12 megabytes (MB) of RAM solely to expand the query-based distribution group. Although this use of memory is temporary, it does occur every time the group is expanded. Similarly, sending an e-mail message to a larger query-based distribution group of 100,000 users, the categorizer requires approximately 200 MB of RAM. The processor speed and amount of available physical memory affects how long it will take to deliver the e-mail messages after the expansion.

·         Global catalog or expansion server availability affects the expansion and delivery of e-mail messages that users send to query-based distribution groups   If all global catalog servers are unavailable, the message is placed in retry mode in the categorizer, which means that the complete expansion restarts after one hour.

The general recommendation is to divide large query-based distribution groups into combinations of standard distribution groups, and assign different expansion servers for each large distribution group. The following options describe three approaches to doing this.

Option 1   Designate an Exchange 2003 server with no mailboxes, such as a public folder replica server or a bridgehead server, as the expansion server for a large query-based distribution group. Because this server has more bandwidth and resources to expand the query-based distribution group, expansion and delivery are more efficient.

Option 2   Create a query-based distribution group for every Exchange server, and limit each query-based distribution group to the mailboxes on that Exchange server. Designating this same server as the expansion server optimizes mail delivery. Then, use aggregate standard distribution groups that contain these query-based distribution groups as members. For example, to create a query-based distribution group for all full-time employees, you could create a query-based distribution group on each server for full-time employees, and name them "Server1 Full Time" and "Server2 Full Time." Then, create a distribution group composed of these server-based groups called "AllFullTime."

Note   
The distribution group that you use to combine the query-based distribution groups cannot itself be a query-based distribution group.

 

Option 3   The following example illustrates a third approach for improved handling of large query-based distribution groups.

You want to create a query-based distribution group called "All employees" with 100,000 users. Consider dividing the group into the following smaller query-based distribution groups and combining these groups into a single standard distribution group:

·         "All Temps"  10,000 users

·         "All Vendors"  5,000 users

·         "All Full-Time"  65,000 users

·         "All Interns"  2,000 users

·         "All Contractors"  18,000 users

 

In this case "All Full-Time" would be a large distribution group, so you may want to assign a specific expansion server to it. The other query-based distribution groups can be assigned an expansion server based on how the users are distributed across your Exchange servers. For example, if all of the interns reside on one Exchange server, you may want to designate the same server as the expansion server for "All Interns." Overall, this proposed approach will perform much better than a single query-based distribution group with 100,000 recipients.

Guidelines for Creating Query-Based Distribution Groups

Use the following guidelines when you create query-based distribution groups:

·         Use query-based distribution groups in an Exchange 2003-only environment, or a native mode environment with Exchange 2003 and Exchange 2000 in which all Exchange 2000 servers are running Service Pack 3 or later.

·         Use universal groups in multi-domain environments when you create distribution groups that span domains. Although query-based distribution groups can be added to global distribution groups, domain local groups, and global security groups, and can contain any of these groups, membership in these types of groups is not replicated to global catalog severs in other domains. Universal distribution groups should be used in situations where distribution will span a multi-domain environment.

·         When you combine query-based distribution groups into an aggregate group, combine them in a universal group. Only universal groups are available on global catalog servers across domains.

·         When you build query-based distribution groups, include only universal groups if the membership is to be available in all of the domains in a multi-domain environment.

 

·         Index the attributes that you use in the query. Indexing greatly improves the performance of the query, and it reduces the time that Exchange requires to expand the distribution group and deliver the e-mail message to the intended recipients. For more information about indexing attributes, see Microsoft Knowledge Base Article 313992, "How To Add an Attribute to the Global Catalog in Windows 2000" (http://support.microsoft.com/?kbid=313992).

·         If the filter string contains incorrect formatting or incorrect LDAP syntax, the global catalog server will not run the query. Using Active Directory Users and Computers to create your query can help prevent you from constructing an incorrect query. You can also use the Preview button to view the result of the query. This will confirm the validity and expected results of the query. If you create a query-based distribution group based on an incorrect LDAP query, when a user sends mail to the query-based distribution group, the user receives a non-delivery report (NDR) with the code 5.2.4. If you enable categorizer logging, Exchange logs one of two events with event identifiers of 6024 or 6025.

·         If the filter string is well-formatted, but produces no results, the sender will not get an NDR. This is the same outcome that occurs if you send to an empty distribution group. As previously stated, use the Preview button in Active Directory Users and Computers to confirm the expected results of your query.

·         Use Exchange System Manager in a security context where its permissions for reading objects in Active Directory are the same as those of the Exchange server. Exchange System Manager runs in the security context of the user that is currently logged on. If an administrator is running with lower security privileges than the Exchange server, it is possible that the query will show a subset of the actual results in the preview pane. The preview pane will show only those Active Directory objects that the administrator has permissions to read. When mail is sent to the query-based distribution groups, however, the categorizer will run with the Exchange server permissions. Assuming the Exchange server has permissions for all the objects in the query, the query will return the correct results.

 

There will be issues when a base distinguished name is deleted. Query-based distribution expansion relies on its base distinguished name referring to a valid container in the directory. If the base distinguished name container for a query-based distribution group is deleted, the categorizer cannot run the query, and the sender receives an NDR with the code 5.2.4. If categorizer logging is enabled, an event ID of 6024 or 6025 is logged. For example, you create a sales container within the users container for all sales employees and build a query-based distribution group using the sales container. If you delete the sales container, the query will no longer work.

Creating Query-Based Distribution Groups

To create a query-based distribution group, you must use the Exchange 2003 version of Exchange System Manager and Active Directory Users and Computers. You cannot create query-based distribution groups without upgrading your administration console.

Note   
It is recommended that you upgrade all of your administrative consoles to Exchange 2003 before you deploy query-based distribution groups in your environment.

 

When creating a query-based distribution group, Active Directory Users and Computers provides a way to format the LDAP query using standard attributes, without requiring specific knowledge of LDAP. For example, you can select all mailboxes under the organizational unit, or even customize the query to select all mailboxes under an organizational unit that exist on a particular server.

After you create a query-based distribution group, you can ensure that your query works the way that you intended it to work by using the preview feature. This feature is useful not only for query validation, but also to determine how long it takes a query to run. Based on this time, you can decide whether or not to divide the query into smaller queries for better performance and faster delivery times.

To create a query-based distribution group

1.        In Active Directory Users and Computers, in the console tree, right-click the container where you want to create the query-based distribution group, point to New, and then click Query-based Distribution Group.

2.        In Query-based Distribution Group name, type a name for the query-based distribution group, and then click Next.

3.        Under Apply filter to recipients in and below, verify that the parent container shown is the one that you want the query-based distribution group to be run against. If this is not the correct container, click Change to select another container.

Note   
The query returns only recipients in the selected container and its child containers. To achieve the results that you want, you may need to select a parent container or create multiple queries.

 

4.        Under Filter, select one of the following options:

·         To filter the query based on a set of predefined criteria, click Include in this query-based distribution group, and then select from the following criteria:

·         Users with Exchange mailboxes

·         Users with external e-mail addresses

·         Groups that are mail-enabled

·         Contacts with external e-mail addresses

·         Public folders that are mail-enabled

 

·         To create your own criteria for the query, click Customize filter, and then click Customize.

 

5.        Click Next to see a summary of the query-based distribution group that you are about to create.

6.        Click Finish to create the query-based distribution group.

The new query-based distribution group appears underneath the container that you selected in Step 3.

To verify that a query-based distribution group works correctly

1.        In Active Directory Users and Computers, right-click the query-based distribution group that you just created, and then click Properties.

2.        Select the Preview tab to view the query results, and verify that the correct recipients are included in the distribution group.

Note   
The results that are displayed in the preview pane may vary from the actual results when the query is run, depending on permissions settings.

Combining Multiple Query-Based Distribution Groups

In Exchange System Manager, you can create query-based distribution groups based on the AND operator. To create distribution groups based on the OR operator using query-based distribution groups, create multiple query-based distribution groups and combine them in a single distribution group.

Consider the following example, in which you want to create a query-based distribution group that includes all employees in the marketing department or all employees in the Paris office. If you create a query-based distribution group using an LDAP query that contains all marketing users and all Paris employees, this query returns only those users who are in both groups. Anyone who is not a member of both groups is excluded. To achieve OR functionality, and thereby include members of either group, you need to do the following:

1.        Create a query-based distribution group for all employees in the marketing department, called Marketing.

2.        Create a query-based distribution group for all employees in the Paris office, called Paris employees.

3.        Create a distribution group (not a query-based distribution group, however) and add the query-based distribution groups, Marketing and Paris employees, as members of this group.

When you add query-based distribution groups as members of a distribution group, you cannot do so in the same way that you add users to a group. You must right-click the group, and then select Add Exchange query-based distribution group. The following procedure describes in detail the process of adding query-based distribution groups as members of a standard distribution group.

To add query-based distribution groups as members of a distribution group

1.        In Active Directory Users and Computers, in the console tree, navigate to the container where the distribution group resides, right-click the distribution list, and then click Add Exchange Query-based Distribution Groups.

2.        In Select Exchange Query-based Distribution Groups, under Enter the object names to select, enter the name of the query-based distribution group that you want to add as a member of this group.


3.        Click Check Names to verify the entry.

4.        Click OK.

5.        Repeat Steps 1 through 4 for each query-based distribution group to be added as a member of this distribution group.

 

Managing Recipients

Managing recipients involves assigning e-mail addresses to recipients with recipient policies, and managing settings for recipient objects with Active Directory Users and Computers.

Notes for Exchange 5.5 Administrators

If you have servers running Exchange 5.5 in your Exchange 2003 organization (that is, your organization is in mixed mode), it is still possible to manage recipients using the Exchange 5.5 Administrator Program, and it is recommended that you do so, with the exception of moving mailboxes. When you move mailboxes, use Exchange 2003 System Manager or Active Directory Users and Computers, where Exchange 2003 System Management tools have been installed.

Note   
Before you use Active Directory Users and Computers to move recipients from Exchange 5.5, you must first create a connection agreement between each Exchange 5.5 site and Active Directory. It is strongly recommended that all objects in your Exchange 5.5 directory be represented in Active Directory before you deploy your first Exchange 2003 or Exchange 2000 server. This greatly reduces the risk of future problems. For more information about planning connection agreements, see Chapter 4, "Migrating from Exchange Server 5.5," in the book Exchange Server 2003 Deployment Guide (http:www.microsoft.com/exchange/library).

 

Exchange objects in Exchange 2003 are different from the Exchange objects in Exchange 5.5. It is important to understand how these objects have changed. Table 4.6 associates the Exchange objects in Exchange 5.5 with their equivalents in Exchange 2003.


Table 4.6   Terminology differences between Exchange 5.5 and Exchange 2003


Exchange 5.5 term

Exchange 2003 equivalent term

Mailbox

Mailbox-enabled user

When a user is mailbox-enabled, the user has an e-mail address and a corresponding mailbox. Mailbox-enabled users can send, receive, and store e-mail messages within an Exchange organization.

Custom recipient

Mail-enabled user

When a user is mail-enabled, they have an associated e-mail address external to the Exchange organization, but they do not have an associated Exchange mailbox. Mail-enabled users can receive messages at a specified external address, but they cannot store messages on Exchange servers in your organization.

—or—

Mail-enabled contact

A mail-enabled contact does not have a Windows logon account or a mailbox. A contact can represent someone outside of the Exchange organization, such as a customer or a business partner.

Distribution list

Mail-enabled group

E-mail messages that are sent to a group are routed to the
e-mail address of each group member.

 

Managing Recipients with Recipient Policies

When Exchange is installed, a default recipient policy is created that applies SMTP and X.400 addresses to all recipients in your Exchange organization. You can modify the default policy or create new policies. However, you cannot delete the default policy. All recipients in an Exchange organization must have both SMTP and X.400 addresses.


The default policy is always set to the lowest priority. Priority determines the order in which policies are applied to the recipients specified in the policy. Priority 1 represents the first policy to be applied. In mixed mode, where servers running Exchange 2003 or Exchange 2000 coexist with servers running Exchange 5.5, the Site policy has a priority of highest and is the only policy that Exchange applies, regardless of any other policies that you create. You can reorder recipient policies at any time, with the exception of the default policy, which is always set to lowest.

Note   
The default policy is special in the sense that every user in the organization must be stamped with the same proxy address, so that users can take advantage of features like Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync®.

 

Creating a Recipient Policy

To begin the process of creating a recipient policy, right-click the Recipient Policies container in Exchange System Manager, point to New, and then click Recipient Policy (see Figure 4.8).

Figure 4.8   Creating a new recipient policy

 


After you click Recipient Policy, you then begin the process of completing the steps that are outlined in the following checklist and described in the following sections.

Recipient Policy Checklist

c

Select the property sheets (e-mail address or Mailbox Manager settings).

c

Name the new policy.

c

Create a filter.

c

Configure the settings.

c

Set the priority of the policy.

c

Apply the policy.

 

Select the Property Sheets

The first step in creating a recipient policy is to choose the type of policy to create. A single recipient policy can contain an address policy, a Mailbox Manager policy, or both (see Figure 4.9). Selecting both will add property pages for both address and Mailbox Manager features to one recipient policy.

Figure 4.9   Selecting property pages for a new policy

 


Name the New Policy

After you select the property pages, give the new policy a name. To help you identify the recipients to which the policy applies, give the policy a descriptive name.

Create a Filter

Initially, there are no filter rules applied to the policy (see Figure 4.10). If you do not create a filter, the policy will not be applied to any recipients. To create the filter using an LDAP query, click Modify on the General tab.

Figure 4.10   Policy does not apply to anyone because no filter rules are set

 


Configure the Settings

To customize the recipient policy, switch to either the E-Mail Addresses (Policy) tab or the Mailbox Manager Settings (Policy) tab in the policy's Properties dialog box. Use the settings on these tabs to configure the recipient policy to meet the needs of the associated recipients. After configuring the settings, click OK to create the policy.

Set the Priority and Apply the Policy

After you create a new recipient policy, the policy and its assigned priority appear in Exchange System Manager. If you want to change the priority of a recipient policy, right-click the policy, select All Tasks, and then move the policy up or down the list of recipient policies shown in Exchange System Manager.

After you create a new recipient policy, you also need to apply the policy by right-clicking the policy in Exchange System Manager, and then clicking Apply Policy Now.

Managing Recipient Settings

Some recipient settings are configured in Exchange System Manager, so that they are applied to all recipients in an organization or to large groups of recipients. Examples include mailbox size (which can be set on a per-store basis), global send and receive limits, and limits on the maximum number of recipients to which users can send. You can configure exceptions to these settings for individual recipients in Active Directory Users and Computers. For example, you may have a user who needs a larger mailbox, or one who needs to be able to send large messages.

For information about using Exchange System Manager to set message settings for an entire organization, see Chapter 2, "Managing an Exchange Organization." For information about setting mailbox size limits on mailbox stores, see Chapter 7, "Managing Mailbox Stores and Public Folder Stores."

The following sections explain three of the four Exchange-specific tabs that you see in Active Directory Users and Computers, where Exchange system tools have been installed. The fourth tab, Exchange Features, is discussed in Chapter 6, "Managing Client Access to Exchange."


Configuring Message Settings for Mailbox-Enabled Recipients

To set individual message settings for mailbox-enabled recipients, start by navigating to the Exchange General tab (see Figure 4.11).

Figure 4.11   Exchange General tab

 

To navigate to the Exchange General tab

1.        In Active Directory Users and Computers, right-click the object to be modified, and then click Properties.

2.        Click the Exchange General tab.

 


Delivery Restrictions

To maintain system performance and to prevent users from wasting valuable system resources by sending large files through your e-mail infrastructure, message size limits are set at the global level in Exchange System Manager, as explained in Chapter 2, "Managing an Exchange Organization." In most cases, e-mail messages for legitimate business purposes can be sent under the threshold set at the global level. Use the Delivery Restrictions dialog box to override the global setting for those users who have special requirements and need to send larger files than the global limit allows.

Tip   
Consider setting up users who need to transfer large files with an FTP account, instead of trying to use your Exchange server as though it were an FTP server.

 

In addition to setting message size limits, you can use the Delivery Restrictions dialog box to specify to whom users can send messages and from whom they can receive messages (see Figure 4.12). This is similar to the global setting.

Important   
When you make these changes for individuals, you can only set restrictions that reference other Active Directory objects. Blocking mail from a specific Internet mail source or IP address must be done at the global level.

 

Figure 4.12   Delivery Restrictions dialog box

 

You can further restrict delivery of messages to recipients by selecting the From authenticated users only check box. This prevents anyone who is not authenticated by your Windows network from sending mail to this recipient. Selecting this check box effectively stops all Internet mail to this recipient. After selecting this check box, select how messages will further be restricted by choosing to allow messages from everyone (all authenticated users), only from users in the restricted list at the bottom of the Delivery Restrictions dialog box, or from everyone except users in the restricted list. To add users to the restricted list, use the Add button.

Delivery Options

One delivery option is the use of delegates. In many organizations, delegates are given permission to send mail on behalf of someone else. For example, an administrative assistant may send a meeting request on behalf of a manager. You can assign delegates to a mailbox-enabled user in the Delivery Options dialog box.

Another delivery option is address forwarding, wherein mail sent to the user is forwarded to another address in the organization. You can also choose to have copies of the message sent to both the forwarding address and the user's mailbox. In this case, deleting one copy of the message does not delete the other. You may want to use forwarding to protect the identity of the actual recipient, or for administrative assistants who help sort e-mail messages for others.

Recipient limits control the number of recipients to which a user can send a single message. By default, there is no set limit.

Storage Limits

Individuals in your organization may need more storage space on their Exchange servers than the threshold for the mailbox store allows. You can set storage limits for individual users in the Storage Limits dialog box. Users can be warned as they approach the limit, subsequently denied the ability to send, and then denied the ability to send and receive mail.

Also, you can override the setting for deleted item retention that is set on the mailbox store. When a user deletes an item, it appears deleted to the user. However, a copy is kept in the user's mailbox store for a specified amount of time, allowing the item to be recovered if it was unintentionally deleted. Some users in your organization may need extra recovery protection, and you can override the setting in the Storage Limits dialog box. If you choose to override the limit set on the mailbox store, you will also have the choice to not permanently delete an item until the store is backed up, adding even greater recovery opportunities for that user.

Exchange Advanced Settings for Mailbox-Enabled Recipients

Navigate to the Exchange Advanced tab to change advanced settings for mailbox-enabled recipients.


To navigate to the Exchange Advanced tab

1.        In Active Directory Users and Computers, right-click the object that you want to modify, and then click Properties.

2.        On the Exchange Advanced tab (see Figure 4.13), select the following options:

·         In Simple display name, set a display name that will be used by systems that cannot interpret all of the characters in the normal display name.

This situation may occur when more than one language version of Exchange System Manager is used to manage an Exchange organization. For example, the English version of Exchange System Manager cannot display all of the characters in the Kanji character set. Because the simple display name takes ASCII characters only, all versions of Exchange System Manager are able to display the simple display name.

·         To prevent the recipient from being displayed in address lists, select Hide from Exchange address lists.

·         To prevent the recipient from sending mail that is marked high priority to an X.400 mail system, select Downgrade high priority mail bound for X.400.

Figure 4.13   Exchange Advanced tab

 


Setting Custom Attributes

Using the Custom Attributes button on the Exchange Advanced tab, you can assign up to 15 custom values for a recipient. By default, recipients have attributes such as phone number, office number, or manager. If there is information that you would like to display in the GAL that does not fit in any of the existing attributes, you can create up to 15 other entries. For example, you may want to include an attribute for the divisions or cost centers of your company.

Assigning Mailbox Rights

Using the Mailbox Rights button on the Exchange Advanced tab, you can assign rights to the mailbox of a recipient to users or to groups, add users to the list, and then allow or deny them the following rights:

·         Delete mailbox storage   The mailbox from the mailbox store can be deleted. By default, only administrators have permission to do this. Users cannot delete their own mailboxes.

·         Read permissions   The specified user can read the contents of a mailbox.

·         Change permissions   The user can modify or delete items in the mailbox.

·         Take ownership   The user is granted ownership of a mailbox.

·         Full mailbox access   The delegated user has the same access rights as the owner.

·         Associated external account   This option is used when a user's Windows account resides in a different forest than the Exchange mailbox.

Note   
Each Exchange mailbox must be associated with an Active Directory object, such as a user, in the same forest as the mailbox. If the intended user account resides outside of the forest where Exchange is, Exchange first associates the mailbox with an account in its same Active Directory forest. That account is disabled. Then, the mailbox is associated with the external account.

 

·         Special permissions   Click Advanced to work more granularly with permissions, including changing inheritance.

 


You assign these rights on the Mailbox Rights tab in the user's Permissions dialog box (see Figure 4.14).

Figure 4.14   Assigning rights to read another user's mailbox

 


Configuring Message Settings for Mail-Enabled Recipients

When you need to set individual message settings for mail-enabled recipients, start by navigating to the Exchange General tab for that recipient (see Figure 4.15).

Figure 4.15   Exchange General tab for mail-enabled recipients

 


The Exchange General tab for mail-enabled recipients is slightly different than that for mailbox-enabled recipients. It has fewer features, omitting those features that apply only to mailbox-enabled users. For more information, see "Configuring Message Settings for Mailbox-Enabled Recipients" earlier in this chapter.

The Exchange Advanced tab adds one option that is not included for mailbox-enabled users, Use MAPI Rich Text Format (RTF). When you select this option, mail sent to this recipient will be sent using MAPI RTF, overriding the settings configured in Internet Message Formats in Exchange System Manager. Select this option only if you are sure that the recipient can view MAPI-rich text.

Distribution Groups

Distribution groups are similar to other mail-enabled recipients, but they have the following unique features on the Exchange Advanced tab (see Figure 4.16):

·         Expansion server   Use the Expansion server drop-down list to select the server where the group is expanded. If this is set to any server in the organization, the group is expanded on the first Exchange server in your organization that receives the message. For more information about expansion servers, see "Expanding Mail-Enabled Groups" earlier in this chapter.

·         Hide group from Exchange address lists   Select this check box to prevent this distribution group from appearing in the GAL or any other address list. You may want to do this for groups that you do not want everyone in the company to know about. For example, you may have a team of auditors who are investigating unethical business practices. You may not want to show that such a group exists.

·         Send out-of-office messages to originator   When someone sends a message to a group, by default, out-of-office messages are not sent to the sender. Select this check box to enable out-of-office replies from group members. For large groups, out-of-office replies may be unnecessary. For example, if the chief security officer of a company sends mail describing new security policies to a group called All Fulltime Employees, out-of-office replies are not needed.

·         Delivery reports for groups   Delivery reports warn about delayed or failed delivery of messages. Choose to send delivery reports to either the owner of the group, the sender of the message, or not at all.

Figure 4.16   Exchange Advanced tab for mail-enabled groups

 

Understanding Address Lists

When users connect to Exchange with a client, such as Outlook 2003, they expect to communicate with other people in the organization easily. Users need to do more than simply compose e-mail messages with their messaging client. Whether they want to send an e-mail message, call a coworker, look up an office number, or schedule a meeting, they need to find information about another recipient quickly. Address lists help you to organize this type of information in a meaningful way.


Address Lists Described

An address list organizes recipients so that they can be easily found by users who want to contact them.

The most familiar address list is the global address list (GAL). By default, the GAL contains all recipients within an Exchange organization. In other words, any mailbox-enabled or mail-enabled object in an Active Directory forest where Exchange 2003 is installed is listed in the GAL. To look up the e-mail address or phone number of a recipient, the user can use the GAL to locate this information. The GAL is organized by name, rather than e-mail addresses, for ease of use.

Client applications, such as Outlook 2003, display the available address lists that Exchange provides (see Figure 4.17). Users choose from the available address lists when they search for information. Several address lists, such as the GAL, are created by default. Address lists reside in Active Directory, so mobile users who disconnect from the network are also disconnected from these (server-side) address lists. However, offline address lists can be created for use in a disconnected environment. These offline lists can be downloaded to a user's hard drive. Often, to conserve resources, the offline lists are subsets of the information in the actual address lists that reside on your servers.

Figure 4.17   Address lists displayed in Outlook 2003

 

An Exchange organization can contain thousands of recipients. Compiling all of your users, contacts, mail-enabled groups, and other recipients can result in many entries. As an administrator, you can create address lists to help users in your organization find what they are looking for more easily.

For example, consider a company that has two large divisions and one Exchange organization. One division, called Fourth Coffee, imports and sells coffee beans while the other, Contoso, Ltd, underwrites insurance policies. For most day-to-day activities, the workers in the coffee division have little to do with those in the insurance division. To make it easier for people to find each other, you create two new address lists—one for Fourth Coffee and one for Contoso. Users can now choose to use the smaller address lists when looking up people in a certain division, or they can always use the GAL, if they are not sure which division a coworker is part of.

Address lists can be sorted by any attribute that is associated with a recipient. City, title, company, office building, or any other attribute that you can filter recipients with can be the basis for a new address list.

You can also create subcategories of address lists. For example, you could create an address list for everyone in Manchester and another for everyone in Stuttgart. You could then create an address list under Manchester for everyone who works in research and development. Because the research and development list is under the Manchester list, the research and development list contains only those recipients who are in research and development and in Manchester.

Address lists are created dynamically. When new users are added to your organization, they are automatically added to all of the appropriate address lists. These updates are one of the primary responsibilities of both the Recipient Update Service and Exchange System Attendant.

Creating Address Lists

Address lists can be useful tools for users, but poorly planned address lists can be frustrating. Before you create address lists, make sure that they will make sense to users. Avoid creating so many address lists that users are unsure where to go to find a recipient. If possible, consider surveying users to find out how they would interpret your proposed address lists. Finally, be sure to name your address lists in such a way that when users glance at them, they know immediately whom they can expect to find. When in doubt, have fewer address lists, and remind users that they can find anyone in your organization by using the global address list.


When you are planning your address lists, consider whether to use subcategories. For example, you may want address lists for both city and state, with city being a subcategory of state (see Figure 4.18). Notice that both New York and Washington have cities named Auburn. When the query for Auburn, New York runs, it first finds all recipients with the state attribute New York, and then queries the result list (all recipients in New York) for all recipients in Auburn. In this way, you get different lists for Auburn, New York and Auburn, Washington.

Figure 4.18   Address lists with subcategories

 


To further simplify the user experience and help organize your lists, you may want to create an empty address list. Because no query has been created for an empty address list, it returns no recipients, and serves strictly as a parent container that organizes other lists. In the preceding example, you may create an empty address list called States (see Figure 4.19).

Figure 4.19   Adding an empty address list

 


To create an address list

1.        In Exchange System Manager, expand the Recipients container.

2.        Expand All Address Lists, right-click the node that the new list belongs in, point to New, and then click Address List.

3.        On the Create Exchange Address List page (see Figure 4.20), name your new address list, and then modify the filter rules appropriately.

Figure 4.20   Creating an Exchange address list

 

You can move address lists to create a new hierarchy, using a drag-and-drop operation. As explained in "Managing Recipient Settings" earlier in this chapter, you can hide recipients from address lists using Active Directory Users and Computers.

Offline Address Lists

MAPI clients such as Outlook 2003 can download offline address lists, so users can compose e-mail messages even when they are disconnected from their Exchange server. For clients to download these address lists, they must first be created on the server.

By default, there is an offline address list called the Default Offline Address List, which contains the global address list. If necessary, you can populate this list with any other address list that you have created. You can also create multiple offline address lists that can be individually associated with each mailbox store in your organization. If the users on your different mailbox stores share something in common, such as all being part of the same division, providing different offline address lists for each mailbox store may make sense.

At any time, you can set any offline address list in your Exchange organization as the default offline address list. This new default list is then associated with all newly created mailbox stores. There can be only one default list at a time in your Exchange organization. If you delete the current default list, Exchange does not automatically assign another list as the default. If you want to use a default list after you delete the existing default list, you must manually designate another offline address list as the default.

To populate the default offline address list

1.        In Exchange System Manager, click the Offline Address Lists container, and then right-click Default Offline Address List.

2.        In the Default Offline Address List Properties dialog box (see Figure 4.21), click Add to add any address list that you have created. You can add as many address lists as you require. Click OK.

Figure 4.21   Default Offline Address List Properties dialog box

 

Offline address lists use system public folders to contain the necessary address list information. Their associated public folders are created during the public store maintenance interval, and the content of the public folder is updated according to the Update interval that you specify on the Properties dialog box of each offline address list. The Offline Address List (System) public folders are hidden from users by default.

To see the System public folders

1.        In Exchange System Manager, expand the administrative group, and then expand the folders container.

2.        Right-click the Public Folders container, and then click View System Folders.

 

In a mixed environment where some users connect to Exchange 2003 or Exchange 2000 servers, and others connect to Exchange 5.5 servers, you need multiple address lists. Those users who connect to Exchange 5.5 need to use the offline address book that is generated by that version of Exchange.

Customizing the Details Templates

Details templates control the appearance of object properties that are accessed by using address lists in both MS-DOS 16-bit and MAPI 32-bit client applications. When a user opens an address list in Outlook, for example, the properties of a particular object are presented as defined by the details template in the Exchange organization. You can use the default details template shown in Figure 4.22, or you can customize the template to better suit the needs of your users.

Figure 4.22   Default details template as viewed from Outlook 2003

 

To customize the details template

1.        In Exchange System Manager, expand the Recipients container, and then select the language for the template that you want to modify.

For example, the English language has been selected in Figure 4.23.

Figure 4.23   Selecting English

 

The following languages are supported:

Arabic, Basque, Brazilian, Bulgarian, Catalan, Chinese Simplified, Chinese Traditional, Croatian, Czech, Danish, Dutch, German, Greek, English, Estonian, Finnish, French, Hebrew, Hungarian, Italian, Japanese, Korean, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovenian, Spanish, Swedish, Thai, Turkish, and Ukrainian.

Other languages may be supported by the client, but they will not be able to display the Properties pages.

2.        In the list of templates displayed in the right-pane, right-click the template to be changed, and then click Properties.

3.        On the Templates tab, resize fields, add or remove fields, add and remove tabs, and rearrange the order of the fields (see Figure 4.24).

Figure 4.24   Modifying the user details template

 

4.        To see how the changes you made affect the template, click Test. To revert to the original template, click Original.

 

Recipient Update Service

Exchange uses the Recipient Update Service primarily to generate and update default and customized address lists, and to process changes made to recipient policies. This service ensures that when new recipient policies or address lists are created, their content is applied to the appropriate recipients in the organization. The Recipient Update Service also applies existing policies to new recipients that are created after the policy or address list has already been established. In this way, information is kept current with minimal administrative overhead.

You must have at least one Recipient Update Service for each domain in your organization, and it must be run from an Exchange 2003 or Exchange 2000 server. For domains that do not have these Exchange servers, the Recipient Update Service must be run from an Exchange server outside of the domain. You can set up more than one Recipient Update Service for a domain, if there are multiple domain controllers. Each Recipient Update Service must read from and write to a unique domain controller.

Note   
If you do not have a Recipient Update Service for a domain, you cannot create recipients in that domain.

 

In situations where you have high network latency within a domain, set up the Recipient Update Service at the local sites. For example, if you have one domain that has sites in Seattle and in Beijing, there could be a long delay before a mailbox that an administrator creates in Beijing is processed by the Recipient Update Service in Seattle. In this case, having a Recipient Update Service on the local domain controller in Beijing will decrease the time the user has to wait to be able to access the mailbox after it has been created.

To create a new Recipient Update Service

1.        In Exchange System Manager, expand the Recipients container.

2.        Right-click the Recipient Update Service container, point to New, and then click Recipient Update Service.

The Recipient Update Service Wizard starts and guides you through the creation process. Figure 4.25 shows the final step in the creation process.

Figure 4.25   The final step in creating a Recipient Update Service

 

Note   
If all of the domain controllers are currently associated with a Recipient Update Service, you receive an error when you try to create the next Recipient Update Service. You can have only one Recipient Update Service per domain controller.

 

You can choose to have the Recipient Update Service run at customized intervals. By default, the Recipient Update Service is set to Always Run, and when it runs, only necessary changes are made. Changes are necessary when a recipient, recipient policy, or address list is changed or created. Any changes that have occurred since the last time the Recipient Update Service ran are applied.

To change the update interval

·         Right-click the Recipient Update Service to be modified, click Properties, and then change the Update interval option.


Chapter 5

Understanding and Configuring Message Routing and Transport

Together, message routing and transport are responsible for message delivery internally and externally. Message routing is the way that messages flow between servers within the organization and to other servers outside of the organization. Your routing topology, based on the routing groups and connectors you define, dictates the path these messages take to reach their final destination. Transport determines the way that messages are delivered.

Simple Mail Transfer Protocol (SMTP) is the transport protocol that Exchange servers use to communicate with each other and send messages using the routing topology. SMTP is part of the Microsoft® Windows Server™ 2003 or Microsoft Windows® 2000 Server operating system. When you install Microsoft Exchange on a server running Windows Server 2003 or Windows 2000 Server, Exchange extends SMTP to support additional SMTP commands for additional functionality. This functionality includes the ability to communicate the link state status, available messaging routes status, and other Exchange functionality.

Configuring Routing for Internal Mail Flow

Because routing is the path messages travel from a sender to a recipient, a well-planned routing topology is essential for efficient mail flow within your Exchange organization. You should carefully evaluate your existing network infrastructure, before you plan your routing topology.

Note   
Although this section focuses on the components of your routing topology and how they affect message flow within your organization, it does not discuss all of the planning considerations and various routing topologies in detail. For information about planning your routing topology, see the book Planning an Exchange 2003 Messaging System (http://www.microsoft.com/exchange/library).

 

In its default state, Exchange Server 2003, like Exchange 2000 Server, functions as though all servers in an organization are part of a single, large routing group. That is, any Exchange server can send mail directly to any other Exchange server within the organization. However, in environments with varying network connectivity and geographical distribution, you can increase message flow efficiency by creating routing groups and routing group connectors in accordance with your network infrastructure. By creating routing groups and routing group connectors, servers within a routing group still send messages directly to each other, but they use the routing group connector on those servers with the best network connectivity to communicate with servers in another group.

This section discusses what routing groups are, as well as how to create and configure routing groups and routing group connectors to manage internal mail flow. Then, because network topologies and environments change, this section also covers how to make adjustments to your routing topology, such as moving servers between routing groups, renaming routing groups, and deleting routing groups.

Note   
If you are operating Exchange on a single server, most of the topics about routing groups do not apply to your organization. However, you may find these topics useful if you are planning to expand your messaging system to support multiple servers.

 

Understanding Routing Groups

A routing group is a collection of servers connected by high-bandwidth, reliable network connections, such as a local area network (LAN). Within a routing group, all servers communicate and transfer messages directly to one another, as follows:

1.        A user in your Exchange organization uses a mail client to send mail to another user.

2.        Using SMTP, the sender's client submits this mail to the SMTP virtual server on the Exchange server on which the client's mailbox resides.

3.        The Exchange server looks up the recipient of the mail message to determine which server the recipient's mailbox resides on.

4.        One of two things happens:

·         If the recipient's mailbox is on the same Exchange server, Exchange delivers the message to the recipient's mailbox.

·         If the recipient's mailbox is on another Exchange server, the first Exchange server sends the message to the recipient's home mailbox server, and it is the recipient's home mailbox server that delivers the message to the recipient's mailbox.

 

Although all servers communicate with each other directly within a routing group, this is not the case when a server in one routing group needs to communicate with a server in another routing group. To allow servers to communicate with servers in other routing groups, you need to create a routing group connector. Although you can use an X.400 connector or an SMTP connector to connect routing groups, the routing group connector is specifically designed for this purpose and is the preferred method of connecting routing groups.

By default, all servers within a routing group can send mail over the routing group connector. Servers that are capable of sending mail over a routing group connector are bridgehead servers. These bridgehead servers are each a combination of an SMTP virtual server and an Exchange server responsible for delivering all messages through a connector.

When creating a routing group connector, you have the option of keeping all the servers as bridgehead servers for that connector or of specifying that only a selected set of servers act as bridgehead servers for that connector. Table 5.1 compares the advantages of each approach.

Table 5.1   Number of bridgehead servers in a routing group

Number of bridgehead servers

Advantages

All servers in a routing group

·         Provides more efficient message flow because all of the servers in the routing group can directly deliver messages to other routing groups.

·         Capitalizes on those configurations where all of the servers in a routing group have the same network connectivity to the servers in other routing groups.

Only a select few servers in a routing group

·         Makes troubleshooting message flow easier because there are limited points of contact between routing groups.

·         Distributes messaging if you anticipate heavy message flow between routing groups.

·         Makes mail flow more reliable and efficient in those configurations where some servers have better network connectivity than others.

 

Figure 5.1 illustrates the basic components of routing discussed thus far. Figure 5.1 shows message flow between servers within a routing group and between routing groups. It also illustrates a topology that uses only a single bridgehead server in each routing group.

Figure 5.1   Communication within and between routing groups

 

When a topology is as simple as that shown in Figure 5.1, you do not have to consider how to best route messages between routing groups. As topologies become more complex, with large numbers of routing groups spread over varying geographical distances, message routing among groups becomes critical. You configure routing among routing groups by assigning costs to the routing group connectors used by these groups. When a user on a server in one routing group sends mail to a user on a server in another routing group, Exchange uses these costs (part of the link state information maintained by Exchange) to determine the most efficient route. Exchange always uses the route with the lowest cost unless a connector or server in that route is unavailable. So that every routing group knows what the various costs are for each connector and the status of those connectors, each routing group has a routing group master that updates and coordinates this information with all of the other servers in a routing group.

Understanding Link State Information

Exchange 2003, like Exchange 2000, uses link state information to determine the most effective route for delivering messages. The link state table contains information about the routing topology and whether each connector within the topology is available or unavailable. Additionally, the link state table contains costs associated with each available connector. Exchange uses this information to determine the route with the lowest cost. If a connector along the lowest cost route is unavailable, Exchange determines the best alternate route, based on cost and connector availability.

To understand how link state information and connector costs work, consider the routing topology shown in Figure 5.2, in which four routing groups exist: Seattle, Brussels, London, and Tokyo. The connectors exist between each routing group and are assigned costs based on the network speed and available bandwidth.

Figure 5.2   Routing topology and costs

 

If all connections between the routing groups are available, a server in the Seattle routing group always sends a message to the Brussels routing group by sending the message first through the London routing group. This route has a cost of 20, the lowest cost route available. But, if the bridgehead server in London is unavailable, messages originating in Seattle and destined for Brussels travel over the higher cost route, the one that goes through the Tokyo routing group.

Understanding Routing Group Masters

When you create a routing group, the first server in that routing group is assigned the role of routing group master. The routing group master keeps track of the link state information and propagates it to the other servers within the routing group, and other servers communicate back any changes in link state. For example, if a member server tries to contact another server over a connector, and this link is unavailable, the member server immediately notifies the routing group master. Likewise, when a non-master receives new link state information, it immediately transfers the link state information to the master, so that other servers can receive the information about the routing change.

Within a routing group, the routing group master and the other Exchange servers communicate link state information over TCP/IP port 691 using SMTP. However, communication of link state information between routing groups is different. If the routing group master is not a bridgehead server for the routing group, the routing group master sends the link state information to the group's bridgehead server over TCP/IP port 691. The bridgehead server then forwards this information (over TCP/IP port 25 using SMTP) to the bridgehead servers of other routing groups.

If you do not want the first server installed in the routing group to be the routing group master (the default setting), you can change the routing group master to another server using the following procedure.

To change which server is the routing group master

·         In Exchange System Manager, expand the routing group, click Members, right-click the server, and then select Set as Master.

Important   
There is no automatic failover for routing group masters. If a routing group master fails, you must manually configure a new routing group master in Exchange System Manager. If a routing group master fails, the other servers in the routing group use the last known link state information until a routing group master becomes available or another routing group master is designated.

 

Using Routing Groups in Native and Mixed Modes

In Exchange 2003 and Exchange 2000, the administrative and routing functions are split into different units:

·         Administrative groups define the logical administrative boundary for Exchange servers.

·         Routing groups define the physical routes that messages travel over the network.

 

If your Exchange organization is in native mode, where all servers are running Exchange 2000 or later, this split between administrative groups and routing groups enables you to create routing groups that span administrative groups, and move servers between routing groups that exist in different administrative groups. This functionality also allows you to separate routing and administrative functions. For example, you can administer servers in two central administrative groups, placing servers from each administrative group in different routing groups, based on your network topology.

However, the functionality of routing groups in mixed mode, where some servers are running Exchange 2003 or Exchange 2000 while others are running Exchange 5.5, is different than in native mode. In mixed mode, you:

·         Cannot have a routing group that spans multiple administrative groups.

·         Cannot move servers between routing groups that exist in different administrative groups.

 

This is because the routing topology in Exchange 5.5 is defined by sites—logical combinations of servers connected by a high-bandwidth reliable network. Sites provide the functionality of both the administrative group and routing group in Exchange 2003 and Exchange 2000. This difference in routing topology limits routing groups in mixed mode.

Note   
For more information about native and mixed mode Exchange organizations, see Chapter 2, "Managing an Exchange Organization."

 

Creating Routing Groups

By design, Exchange functions as though all servers are connected by high-speed reliable networks. When your servers do not share this type of network connectivity, you can group servers with reliable network connectivity into routing groups to enable Exchange to maximize message flow efficiency.

By default, all servers in a native-mode Exchange organization are placed in a single routing group, called First Routing Group, and these servers communicate directly with one another. In mixed mode (where some servers are running Exchange 5.5 or earlier), each Exchange 5.5 site becomes a routing group.

Note   
To understand the difference between routing groups in mixed and native mode, see "Using Routing Groups in Native and Mixed Modes" earlier in this chapter.

 

After installation, you can create additional routing groups in your Exchange organization. When you install additional Exchange servers into an existing organization, you can then designate the appropriate routing groups where these servers belong. After installation, you can also move servers between routing groups.


When you create a routing group, two containers display beneath the routing group:

·         Connectors   Displays any connectors installed on the servers within the routing group. This list includes any connectors to third-party mail systems, such as the Lotus Notes or Novell GroupWise connector, as well as any routing group connectors, X.400 connectors, and SMTP connectors that you configure.

·         Members   Displays the servers within this routing group. By default, the routing group master is the first server added to a routing group.

Note   
Before you can create routing groups, you must configure your Exchange organization to display routing groups. In Exchange System Manager, right-click your Exchange organization, click Properties, and then select the Display routing groups check box.

 

To create a routing group

1.        In Exchange System Manager, right-click Routing Groups, point to New, and then select Routing Group.

2.        On the General tab (see Figure 5.3), in the Name box, enter a name for the routing group, and then click OK.

Figure 5.3   General tab for routing group

 


Moving Servers Between Routing Groups

As discussed earlier, you can only add a server to a routing group during installation. However, you can move servers between routing groups at any time. The capability to move servers between routing groups is useful if your network topology changes, and you need to combine servers with reliable connections into different routing groups. You may also need to move servers between routing groups if you are consolidating your physical sites and moving more servers into a central location.

In native mode, you can move servers between routing groups that exist in different administrative groups. In mixed mode, you can only move servers between routing groups within the same administrative group.

Note   
You cannot move a server that is configured as the bridgehead server for any connectors. You must first designate a new bridgehead server, or remove the connectors before you can move the server.

 

To move servers between routing groups

1.        In Exchange System Manager, expand the routing group that currently has the server to be moved, and then expand the Members folder within that routing group.

2.        Expand the routing group that will be the new location for the server, and then expand the Members folder within that routing group.

3.        In the Members folder of the routing group that currently has the server to be moved, do one of the following:

·         Select the server and drag it to the Members folder of the routing group that will be the new location for the server.

—or—

·         Right-click the server, and then click Cut. In the Members folder of the routing group that will be the new location for the server, right-click, and then click Paste.

 

Renaming a Routing Group

If necessary, you can rename a routing group after it is created. You may need to rename a routing group if you are consolidating routing groups or expanding a routing group to include more regions, and want to change the name to reflect the new membership.


If any servers in a routing group are bridgehead servers for an X.400 connector, ensure that no messages are in the Exchange message transfer agent (MTA) queue. (Messages are submitted to this queue if they are destined for an X.400 system or an Exchange 5.5 server.) If messages are in the Exchange MTA queue when you rename a routing group, wait 15 minutes for Exchange to apply these changes, and then restart the Microsoft Exchange MTA Stacks service.

You can use Queue Viewer to verify that no messages are in the Exchange MTA queue. Figure 5.4 shows the Exchange MTA queue with no messages.

Note   
Messages in other queues are not affected when you rename a routing group.

 

Figure 5.4   Exchange MTA queue in Queue Viewer

 

To rename a routing group

·         In Exchange System Manager, right-click the routing group, click Rename, and then type a new name for the group.

 

Deleting a Routing Group

Before you can delete a routing group, you must move all member servers to another routing group. After you remove the servers from the routing group, you can delete the group.

To delete a routing group

·         Right-click the routing group, and then click Delete.

 


Connecting Routing Groups

When you create a routing group, you designate a group of servers that can communicate directly with one another. As discussed earlier, for servers in different routing groups to communicate with each other, you need to connect the routing groups.

It is possible to connect routing groups with an SMTP connector or an X.400 connector. However, using these types of connectors is generally not recommended. The preferred connection method is a routing group connector because this connector is designed and intended specifically for connecting routing groups.

Routing group connectors are one-way routes for outgoing messages, which means messages travel outbound to the connected routing group. For two routing groups to communicate, a routing group connector must exist in each routing group to send messages outbound to the other routing group. When you create a connector to a routing group, Exchange displays a message asking if you want to create a routing group connector in the remote routing group so you can send messages from the remote routing group to the routing group where you are creating the first connector.

Before you create and configure a routing group connector, you should think about the following questions:

·         To which routing group does this connector deliver messages?   This information is critical. Identifying the routing group to which the connector delivers messages establishes the relationship between the sending and receiving routing groups and the rest of your topology. You need to know how the sending and receiving routing groups fit into your topology in order to intelligently assign a cost for the associated connector.

·         What cost should this connector have?   Cost is the variable Exchange uses to determine the most efficient messaging route. Exchange considers the lowest cost route the most efficient. Exchange uses a more expensive route only if a server or connector is unavailable on the route with the lowest cost. You should assign the lowest costs to the routes with the highest available network bandwidth.


·         Which servers in the routing group can act as bridgehead servers?   Only designated bridgehead servers can send messages across the connector to the connected routing group. The default and preferred setting is to have any of the servers in the local routing group send mail using this connector. Use this default option when all servers in the routing group can connect directly over the network to the remote bridgehead server. Connecting directly to the remote bridgehead servers provides more efficient message flow.

However, you may have better direct network connectivity between specific servers in the local routing group and the designated remote bridgehead server. For example, Server A has a direct connection of 56 kilobits per second (Kbps) to a remote bridgehead server, while Server B and Server C each have a direct connection of 10 megabits per second (Mbps) to the same remote bridgehead server. In this case, you would want to specify the servers that have the better direct network connectivity (that is, Server B and Server C) as the bridgehead servers, and you would add those specific servers to a list of allowable bridgehead servers.

·         Should users access public folders that are not available locally using this connector?   By default, public folder referrals are enabled across connectors connecting routing groups. However, network traffic increases when users access a public folder in a remote routing group. If your routing groups are connected by slow network connectivity or if your network may not be able to handle the additional traffic, disable public folder referrals. For more information about public folder referrals, see "Understanding Public Folder Referrals" in Chapter 7, "Managing Mailbox Stores and Public Folder Stores."

·         What are the remote bridgehead servers to which this connector can send messages?   The remote bridgehead servers are the servers in the connected routing group that receive all messages destined for this routing group. The remote bridgehead servers also send link state information to the bridgehead servers for the connector.

 

After considering these questions, you answer the first four by setting the configurations options on the General tab in the Routing Group Connector Properties dialog box. You can answer the last question by specifying remote bridgehead servers on the Remote Bridgehead tab.


To configure the options for a routing group connector

1.        In Exchange System Manager, expand the routing group, right-click Connectors, point to New, and then click Routing Group Connector.

2.        On the General tab (see Figure 5.5), select from the following options:

·         For the name of the routing group connector, it is a common practice to use the two routing groups it connects. For example, you could use the name ParisToSeattle to define a connector connecting your Paris routing group to your Seattle routing group.

·         In Connects this routing group with, select the routing groups to which you want to connect.

·         In Cost, assign a cost for the connector.

·         To have all servers within the local routing group function as bridgehead servers, select Any local server can send mail over this connector.

·         To specify which servers within the local routing group can function as bridgehead servers for this connector, select These servers can send mail over this connector, and then click Add to add the appropriate servers to the list.

·         To prohibit users from accessing public folders that are not available locally using this connector, select Do not allow public folder referrals.

Figure 5.5   General tab of the Routing Group Connector Properties dialog box

 

To specify a remote bridgehead server for a routing group connector

1.        In the Routing Group Connector Properties dialog box, on the Remote Bridgehead tab (see Figure 5.6), click Add, and then select the remote bridgehead server from the list of servers in the routing group to which you are connecting.

Note   
You must specify a remote bridgehead server. For redundancy, you should specify more than one remote bridgehead server, if possible.

 

Figure 5.6   Remote Bridgehead tab in the Routing Group Connector Properties dialog box

 

2.        If you are creating a routing group connector between routing groups that includes Exchange 5.5 servers, in Override connection credentials for Exchange 5.x, click Modify, and then enter the Exchange 5.5 service account credentials for the Exchange 5.5 server to which you are connecting.

3.        Click Apply to create the connector.


4.        When a message appears that asks if you want to create a routing group connector in the remote routing group, click Yes.

After clicking Yes, Exchange creates a routing group connector in the remote routing group. This new routing group connector allows the remote routing group to send messages to the local routing group. When creating this new routing group connector, Exchange does the following:

·         Exchange designates the bridgehead servers for the remote routing group connector as those servers listed on the Remote Bridgehead tab of the local routing group connector.

Note   
When Exchange designates servers in this way, only those servers listed on the Remote Bridgehead tab become bridgehead servers for the new connector. If you would rather have all of the servers in the remote routing group (not just those listed) function as bridgehead servers for the new connector, you must manually select the Any local server can send mail over this connector option on the General tab of the new connector.

 

·         Exchange designates the remote bridgehead servers for the remote routing group connector as those servers listed as bridgehead servers on the General tab of the local routing group.

 

Connecting to the Internet

Internet connectivity depends on SMTP and Domain Name System (DNS), as well as some other components. As stated earlier, SMTP is the protocol used by Exchange to deliver mail internally and to the Internet. To enable Internet mail delivery in your Exchange organization, you manage the SMTP protocol by configuring SMTP virtual servers and connectors. Additionally, you must ensure that DNS is properly configured because DNS is responsible for locating mail servers outside of the organization, so that SMTP can deliver mail to them.

Note   
Before connecting to the Internet, you should configure your Exchange server in accordance with your company's security policy.

 

After you install Exchange, you can send and receive mail using the default configuration of an SMTP virtual server on an Exchange server if the following conditions exist:

·         You have a direct connection to the Internet.

Note   
Dial-up connectivity requires some additional configuration. For more information, see Configuring SMTP in Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=15084).

 

·         You have DNS configured correctly to resolve Internet names and to send mail to your Exchange server. Specific DNS settings are discussed later in this section.

 

This section describes how to configure Internet mail delivery. It includes:

·         Understanding SMTP dependencies and how to configure SMTP   Exchange relies on SMTP to deliver mail internally and externally. Because of this reliance, you need to understand on which components SMTP depends and how to properly configure them to support SMTP. After you have set up these components properly, you need to know how to control the configuration of SMTP.

·         Using a wizard to configure Internet mail delivery   Internet Mail Wizard is intended primarily for small and medium companies with less complex environments than large or enterprise companies.

·         Manually configuring Internet mail delivery   In large or enterprise environments, you may need to manually configure Internet mail delivery, in accordance with your organization's policies. When manually configuring Internet mail, there is a separate set of tasks associated with configuring Exchange to send Internet mail and to receive Internet mail.

·         Controlling junk mail using filters   Exchange supports connection, recipient, and sender filtering. Using these various filtering options helps you control the amount of junk mail your users receive.

Note   
For detailed information about large or enterprise environments and common deployment scenarios for those environments, see Configuring SMTP in Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=15084).

 

Defining SMTP Dependencies

As discussed earlier in this chapter, Exchange relies on SMTP to deliver mail internally and externally. This means that, for Internet mail delivery, Exchange depends on SMTP. However, before configuring Exchange for Internet mail delivery, you need to understand the components on which SMTP depends:

Internet Information Services (IIS)

As mentioned earlier, the SMTP service is installed as part of the Windows Server 2003 or Windows 2000 Server operating system. SMTP is a component of IIS and runs under a process called Inetinfo.exe. If you remove IIS from a server running Exchange, mail flow stops working.

IIS provides a framework process for Internet services such as HTTP, SMTP, and Network News Transfer Protocol (NNTP). IIS should not be confused with HTTP because several other services, such as SMTP, depend on IIS to function. After you install Exchange, the management of SMTP virtual servers moves to Exchange System Manager, even though the service itself continues to run within IIS. Because of this integration between Exchange and IIS, both the IIS component and the SMTP service that runs in IIS are required for Exchange and SMTP to function properly.

Active Directory

Exchange Server 2003 is tightly integrated with the Microsoft Active Directory® directory service. Exchange stores all of its configuration information in Active Directory, including information about recipient policies, SMTP virtual server configuration, and user mailboxes. However, SMTP reads its settings from the IIS metabase. Therefore, to supply IIS with the information it needs for SMTP functionality, Exchange System Attendant, using a component called DS2MB (directory service to metabase), replicates the configuration information from Active Directory to the IIS metabase.

DNS

SMTP depends on DNS to determine the Internet protocol (IP) address of its next internal or external destination server. Generally, internal DNS names are not published on the Internet. Therefore, SMTP must be able to contact a DNS server that can resolve external DNS names to send Internet mail, as well as a DNS server that can resolve internal DNS names for delivery within the organization.

Additionally, for your Exchange servers to receive Internet mail, your DNS server must contain a mail exchange (MX) resource record that points to the A record with the IP address of the SMTP virtual server on your Exchange server that receives Internet mail for your organization. If you are supporting multiple domains, an MX record must exist for each of these domains for DNS to accept mail for the domain.

Recipient Policies

Recipient policies establish the default e-mail addresses that use a specific protocol (such as SMTP) for a set of users. E-mail addresses define the valid formats for addressing inbound e-mail messages to the Exchange system. The default recipient policy sets the mail domain for which the virtual server accepts incoming e-mail messages. It specifies the default SMTP and X.400 addresses for all Exchange-based mailbox-enabled objects. You can also create additional recipient policies if your organization receives mail for multiple domains, or if your default domain is used strictly for internal purposes and you use a different external mail domain.

Any SMTP domain specified in the recipient policies is replicated into the IIS metabase and set as authoritative local domains. Setting these domains as authoritative local domains means that SMTP accepts inbound mail for these domains and is responsible for sending all non-delivery reports for this domain. The only time an SMTP address is not considered local is when you add the address to the recipient policy because you clear the This Exchange Organization is responsible for all mail delivery to this address check box in the SMTP Address Properties dialog box.

 

Installing and correctly configuring the previous components ensures that SMTP functions properly with Exchange. With SMTP functioning properly, you can focus on configuring SMTP to meet your organization's needs.


Configuring SMTP

In Exchange, you use SMTP virtual servers and SMTP connectors to control the configuration of SMTP.

SMTP virtual servers

Essentially, an SMTP virtual server is an SMTP stack (a process or server that both receives e-mail messages and acts as a client for sending e-mail). Each SMTP virtual server represents an instance of the SMTP service on a server. Consequently, a single physical server can host many virtual servers.

An SMTP virtual server is defined by a unique combination of an IP address and port number. The IP address is the address on which the SMTP virtual server listens for incoming SMTP connections. The default IP address is All Unassigned, which means that the SMTP virtual server listens on any of the available IP addresses. The port number is the port through which the SMTP virtual server receives communications. The default port number for inbound connections to an SMTP virtual server is port 25.

You use Exchange System Manager to control most of the SMTP settings. The property settings of the SMTP virtual server control inbound mail and, to a lesser degree, outbound mail settings.

SMTP connectors

An SMTP connector designates an isolated route for mail. You can use SMTP connectors to establish a gateway for Internet mail or to connect to a specific domain or mail system. Connectors allow you to define specific options for the designated mail route.

 

Although you can send and receive Internet mail using an SMTP virtual server, most companies configure an SMTP connector to route Internet mail. Using an SMTP connector is recommended because it provides an isolated route for mail destined to the Internet. Additionally, more configuration options are available on an SMTP connector than on the SMTP virtual server. Because of the benefits of an SMTP connector, the following sections that describe both the Internet Mail Wizard and the manual procedure for configuring Exchange to send Internet mail include information about creating and configuring an SMTP connector to route Internet mail.


Using a Wizard to Configure Internet Mail

Exchange Server 2003 implements a new version of Internet Mail Wizard that helps you configure Internet mail connectivity with Exchange Server 2003 or Exchange 2000 Server. Using Internet Mail Wizard, you can configure an Exchange server to send Internet mail, receive Internet mail, or send and receive Internet mail. Furthermore, using Internet Mail Wizard means that you do not have to configure the SMTP connector and SMTP virtual server manually. Internet Mail Wizard automatically creates the necessary SMTP connector for outgoing Internet mail and configures your SMTP virtual server to accept incoming mail.

Note   
If you have already set up SMTP connectors, modified the IP address or port number of your default SMTP server, or created additional SMTP virtual servers on your Exchange server, you cannot run Internet Mail Wizard. However, if you reset your server configuration to its default state, you can then run Internet Mail Wizard.

Important   
Internet Mail Wizard is intended primarily for small and medium companies with less complex environments than large enterprise companies. If you have a complex or enterprise messaging environment, you should manually configure Exchange for Internet mail delivery.

 

To start Internet Mail Wizard

1.        In Exchange System Manager, right-click your Exchange organization, and then click Internet Mail Wizard.

Note   
To run Internet Mail Wizard, you must use the version of Exchange System Manager that comes with Exchange Server 2003.

 

2.        Follow the instructions in the wizard to perform the configuration tasks (see Tables 5.2 and 5.3) necessary to configure Internet mail delivery.


Table 5.2   Using Internet Mail Wizard to configure the sending of mail

Task

Description

Select an Exchange server within your organization that will send Internet mail

As mentioned earlier, you cannot run the wizard on a server on which you have already set up SMTP connectors or created additional SMTP virtual servers. You can only use the wizard to designate Exchange 2000 or later servers.

Designate a bridgehead server

This is both the Exchange server and the SMTP virtual server on this server. The wizard creates an SMTP connector on the selected SMTP virtual server and Exchange server. The outbound bridgehead server handles all mail sent through this connector.

Configure an SMTP connector to send Internet mail

Internet Mail Wizard guides you through the process of configuring your SMTP connector.

·         You can allow Internet mail delivery to all external domains, or you can restrict Internet mail delivery to specific domains.

·         You can specify whether the SMTP connector sends outbound mail using DNS to resolve external domain names, or whether it uses a smart host that assumes responsibility for resolving external names and delivering mail.

Verify that your SMTP virtual server is not open for relaying

With open relaying, external users can use your server to send unsolicited commercial e-mail, which may result in other legitimate servers blocking mail from your Exchange server. If your server is secured for relay, only authenticated users can send mail to the Internet using your server.

 


Table 5.3   Using Internet Mail Wizard to configure the receiving of mail

Task

Description

Select an Exchange server within your organization that will receive Internet mail

As mentioned earlier, you cannot run the wizard on a server on which you have already set up SMTP connectors or created additional SMTP virtual servers. You can only use the wizard to designate Exchange 2000 or later servers.

Configure your SMTP server to receive Internet mail

To receive incoming Internet e-mail messages, the server must have only one SMTP virtual server, and that virtual server must have a default IP address of All Unassigned and an assigned TCP port of 25. If more than one SMTP virtual server exists on the Exchange server, or if the IP address or the port assignment is different than the default settings, the wizard will not continue. You can then either restore the Exchange server to its default configuration and rerun the wizard, or you can use Exchange System Manager to configure Exchange manually.

Verify that your SMTP virtual server allows anonymous access

Other servers on the Internet expect to connect anonymously to your SMTP virtual server. Therefore, anonymous access must be permitted on your SMTP virtual server. If anonymous access is not configured, the wizard guides you through enabling anonymous access.

Configure your recipient policies with the SMTP domains for which you want to receive inbound mail

The SMTP domains for which you want to receive Internet mail are configured in Exchange System Manager in Recipient Policies. You must have a recipient policy configured for every SMTP domain for which you want to accept Internet mail, and Exchange must be authoritative for this domain. If your default recipient policy contains the correct mail domain for your organization, use this policy.

If you have created multiple recipient policies in Exchange System Manager, you cannot use the wizard to create additional recipient policies. In this case, to add or modify your recipient policies, you must use Exchange System Manager. To configure recipient policies manually, see "Configuring Recipient Policies" later in this chapter.

You must configure MX records in DNS for all mail domains. If you do not have an MX record for your mail domain, DNS cannot accept messages for your domain.

 


Configuring a Dual-Homed Server Using the Wizard

When you use Internet Mail Wizard to configure Internet mail delivery on a dual-homed server (a server configured with two or more network addresses, usually with two network interface cards), the wizard performs the necessary configuration steps described in Tables 5.2 and 5.3.

The wizard also creates an additional SMTP virtual server on the Exchange server. It configures Internet mail delivery in the following ways:

·         To configure a server to send Internet mail, the wizard guides you through the process of assigning the intranet IP address to the default SMTP virtual server on which it creates the SMTP connector to send outbound mail. You assign the intranet IP address to this virtual server so that only internal users on your intranet can send outbound mail.

·         To configure a server to receive Internet mail, the wizard guides you through the process of assigning the Internet IP address to the Internet SMTP virtual server. You assign an Internet IP address to this virtual server because external servers need to be able to connect to this SMTP virtual server to send Internet mail. Additionally, you must have an MX record on your DNS server that references this server and the IP address of the Internet SMTP virtual server.

Important   
To increase the security on a dual-homed server, use Internet Protocol security (IPSec) policies to filter ports on the Internet network interface card and strictly limit the users that you allow to log on to this server. For more information about IPSec, see your Windows documentation.

 

Manually Configuring the Sending of Internet Mail

If your messaging environment is large or complex, you cannot use Internet Mail Wizard to configure Exchange to send Internet mail. Instead, you must manually configure Exchange to handle outbound messaging over the Internet.

Configuring Exchange to send Internet mail involves:

·         Verifying that your SMTP virtual server uses the standard port for SMTP (port 25).

·         Configuring an SMTP connector through which Internet mail is routed.

·         Verifying that your DNS server can resolve external names, so that SMTP can deliver messages.

 

This section explains how to configure these settings on an Exchange server.


Verifying Outbound Settings on SMTP Virtual Servers

As discussed earlier, you configure most of the outbound settings that SMTP uses on the SMTP connector. However, you cannot configure the SMTP connector to control the ports and IP addresses through which Exchange sends outbound mail. To control these ports and IP addresses, you need to configure the SMTP virtual server. SMTP connectors configured on the virtual server inherit these settings.

Two of the SMTP virtual server properties relate directly to configuring Exchange to send Internet mail:

·         The outbound TCP port   You need to ensure that the outbound port is set to port 25 (the default setting). Of the two settings related to sending Internet mail, this is the setting that you must verify.

Note   
Changing the default settings on your default SMTP virtual server can cause mail flow problems.

 

·         The use of an external DNS server   To send Internet mail, the DNS server Exchange uses must be able to resolve external (Internet) names. Two common methods for configuring DNS to resolve external names include:

·         Configuring Exchange to point to an internal DNS server that uses forwarders to an external DNS server (this is the easiest and most common method).

·         Configuring Exchange to point to an internal DNS server that does not have a forwarder to an external DNS server, and then configuring an external DNS server on the SMTP virtual server that is responsible for sending external mail.

 

The following procedures describe how to verify that the outbound TCP port is set to 25, and how to specify an external DNS server.


To verify that the outbound port used to deliver mail is set to 25

1.        In Exchange System Manager, expand Servers, expand <server_name>, expand Protocols, expand SMTP, right-click Default SMTP Virtual Server, and then click Properties.

2.        On the Delivery tab, click Outbound connections.

3.        In the Outbound Connections dialog box (see Figure 5.7), verify that the TCP port is set to 25.

Figure 5.7   Outbound Connections dialog box

 

Note   
Remote servers on the Internet expect your server to use TCP port 25. Changing this setting is not recommended because other SMTP servers generally accept connections on port 25 only.

 


To specify an external DNS server used by the SMTP virtual server

1.        In the Default SMTP Virtual Server Properties dialog box, on the Delivery tab, click Advanced.

2.        In the Advanced Delivery dialog box, click Configure.

3.        In the Configure dialog box (see Figure 5.8), click Add to enter the IP address of an external DNS server. If you are using more than one external DNS server, use the Move Up and Move Down buttons to set the order of preference for the DNS servers.

Figure 5.8  Configure dialog box for external DNS servers

 

Configuring an SMTP Connector

The primary uses of an SMTP connector are to connect to the Internet or to other mail systems, and to define additional options on an SMTP Internet gateway. Because an SMTP connector creates an isolated route for Internet mail, it eases administration and troubleshooting if you encounter mail flow problems.

This section focuses on the connector's use as a connection method to deliver Internet mail. To configure an SMTP connector to deliver Internet mail, you first need to consider the following configuration requirements:


How to route mail for outbound delivery?

When you configure a connector, you can either use DNS to route all outgoing mail through the connector, or you can specify a smart host to which the connector routes all mail.

Using DNS to route all outgoing mail through the connector   If you use DNS to route outgoing mail, the SMTP connector uses DNS to resolve the IP address of the remote SMTP server, then it delivers the mail.

If you select this routing method, verify the following information:

·         Verify that your DNS server can successfully resolve names on the Internet.

·         If you use an external DNS server to resolve names, and this server is configured at the SMTP virtual server level (that is, using a different DNS server than the one specified on your network connection), ensure that this external DNS server can resolve names on the Internet.

 

Specifying a smart host   The smart host handles DNS resolution and delivers the mail. Although you can specify a smart host on an SMTP virtual server, you should set the smart host on the connector itself. The smart host setting on the SMTP connector overrides any smart hosts configured on the SMTP virtual server.

If you select this routing method, you specify an IP address or name for the smart host. The IP address and name for the smart host must meet the following requirements:

·         If you specify an IP address for the smart host   Enclose the IP address in brackets (for example, [10.0.0.1]), and ensure that the IP address is not the IP address of the Exchange server.

·         If you specify a name for the smart host   Ensure that the name is a fully qualified domain name (FQDN). (For example, "Server Name" is not an FQDN. However, servername.contoso.com is an FQDN.) Also, ensure that the name is not the FQDN of the Exchange server.

 

If you do not have a smart host within your network, contact your Internet service provider (ISP) to find out what IP address or FQDN to use for the smart host. After you have the IP address or FQDN, make sure that the IP address or FQDN meets the previous requirements.

Which servers to use as local bridgehead servers?

An SMTP virtual server hosts a connector. When you create a connector, you designate at least one Exchange server and one SMTP virtual server as bridgehead servers. The connector inherits size restrictions and other settings from the SMTP virtual server. However, you can override these settings on the connector. You can also designate multiple bridgehead servers for load balancing, performance, and redundancy.


To send outbound mail, the connector uses the outbound port configured on the SMTP virtual server. If your organization sends a large amount of mail externally, you should designate dedicated Exchange servers and SMTP virtual servers as gateway servers or bridgehead servers receiving Internet mail. Using dedicated servers as gateway servers means that other mailbox servers do not have to assume the additional overhead of a gateway server.

Which domains should be included in the address space?

The address space defines the mail addresses or domains for the e-mail messages that you want routed through a connector. For example, an address space of * (asterisk) encompasses all external domains. A connector with this address space is capable of routing all external e-mail messages.

Exchange routes messages through a connector based on the closest match to an address space. If you had a connector with the * address space and then created a second connector with an address space of *.net, Exchange would route all mail sent to a domain with a .net extension through the second connector. This routing difference occurs because Exchange selects the connector that has the most similar address space to the outbound mail.

On connectors with an identical address space, costs work the same way as they do on routing group connectors. For example, you create two SMTP connectors to the Internet, Connector1 and Connector2, and each has the address space of *. Because Connector1 has better network connectivity, you always want to use this connector (unless it becomes unavailable) to send mail to the Internet, and you give Connector1 a cost of 1. Then, you give Connector2 a cost of 2. As long as Connector1 is operating properly, Exchange always sends messages through that connector because it has the lowest cost. If Connector1 becomes unavailable, Exchange uses the connector with the next lowest cost, Connector2.

Important   
Do not list your inbound domains on an SMTP address space for a connector. Your inbound domains are listed in your recipient policies. (For more information, see "Configuring Recipient Policies" later in this chapter.) If you list some or all of your inbound domains in the SMTP address space, you may receive non-delivery reports (NDRs) that indicate a mail loop. (These NDRs may have the diagnostic code 5.3.5.) By specifying domains on the Address Space tab in the connector's Properties dialog box, you can configure these domains as routable domains.

 

What is appropriate scope for the connector?

You can select either an entire organization or a routing group for the connector's scope. For example, you have two routing groups and each routing group has a server that has an SMTP connector to send mail to the Internet. For this configuration, you may choose to specify a routing group scope for each of the connectors. Specifying a routing group scope forces the servers in each routing group to use the connector in that routing group. However, a routing group scope also means that, if the group's SMTP connector becomes unavailable, messages queue in the routing group until the connector becomes available again. Given the restrictions imposed by a routing group scope, you would most likely set an SMTP connector to this scope if it is acceptable to have messages queuing when a connector becomes unavailable, or if the network cannot accommodate the extra traffic from one routing group sending Internet mail through an SMTP connector of another routing group. Otherwise, you must assign the connector an organization-wide scope and allow users in your entire organization to use any acceptable SMTP connector.

Creating an SMTP Connector

After you have thought about the configuration requirements for the SMTP connector and know what your configuration decisions are, you are ready to create and configure an SMTP connector. The first step is to configure the settings on which you have decided. Then you need to enable anonymous access for outbound connections because other servers on the Internet expect your SMTP server to connect anonymously.

After creating and configuring the connector using the following procedures, your SMTP connector is ready to send mail to the Internet. However, these procedures do not cover all the configuration settings for the connector. There are additional configuration settings that control how the connector delivers mail to the Internet. For more information about configuring these additional settings, see "Customizing Mail Delivery" later in this chapter.

To configure a connector for Internet mail delivery

1.        In Exchange System Manager, expand the routing group, right-click Connectors, point to New, and then click SMTP Connector.

The Properties dialog box (see Figure 5.9) for the new connector appears.

Figure 5.9   Properties dialog box for a newly created SMTP connector

2.        On the General tab, select one of the following options:

·         To use the DNS settings configured on the SMTP virtual server that is hosting the connector, select Use DNS to route to each address space on this connector.

The SMTP connector uses DNS to resolve the IP address of the remote SMTP server, and then it delivers the mail.

·         To route mail to a Windows SMTP server or another server in your perimeter network (also known as a DMZ or demilitarized zone, and screened subnet), select Forward all mail through this connector to the following smart hosts.

The SMTP connector then routes mail to the selected server, which handles DNS resolution and delivers the mail.

3.        On the General tab, click Add, and add at least one bridgehead server and one SMTP virtual server.

The servers that you add appear in the Local bridgeheads list on the General tab.

4.        Click the Address Space tab.

5.        On the Address Space tab, click Add.

6.        In the Add Address Space dialog box (see Figure 5.10), in the Select an address type list, click SMTP, and then click OK.

Figure 5.10   Add Address Space dialog box

 


7.        In the Internet Address Space Properties dialog box (see Figure 5.11), select the following options:

·         In the E-mail domain box, type an e-mail domain for the connector.

Important   
In the E-mail domain box, there is a default value of * that represents all addresses. At least one connector in your organization should have this address space to ensure that all external domains are routed to the Internet.

 

·         In the Cost box, assign an appropriate cost. By default, the cost is 1.

Figure 5.11   Internet Address Space Properties dialog box

 


8.        Click OK to return to the Address Space tab (see Figure 5.12).

Figure 5.12   Address Space tab

 


9.        On the Address Space tab, under Connector scope, select one of the following options:

·         To allow all servers in your Exchange organization to use this connector, select Entire organization.

·         To allow only servers in the routing group to use this connector to send Internet mail, select Routing group.

Note   
If you select Routing group, ensure that you have another way for servers in different routing groups to send Internet mail.

 

To enable anonymous access

1.        In the Properties dialog box for your SMTP connector, on the Advanced tab, click Outbound Security.

2.        In the Outbound Security dialog box (see Figure 5.13), select Anonymous access.

Figure 5.13   Outbound Security dialog box

 


Customizing Mail Delivery

As discussed earlier in this chapter, one advantage to using an SMTP connector for outbound mail, rather than using an SMTP virtual server, is that you can specify additional configuration settings to affect how mail is delivered (see Table 5.4). Whether you need to adjust the default values for these settings depends on how you want your SMTP connector to deliver mail.

Table 5.4   Additional configuration settings for an SMTP connector

Settings

Description

Delivery restrictions

Restricts who can send mail through a connector. By default, the connector accepts mail from everyone.

You configure these settings on the Delivery Restrictions tab of the SMTP connector's Properties dialog box.

Content restrictions

Specifies what types of messages are delivered through a connector.

You configure these settings on the Content Restrictions tab of the SMTP connector's Properties dialog box.

Delivery options

If you connect to a network service provider to retrieve your mail, configure a connector to run on a specified schedule, and implement advanced queuing and dequeuing features.

You configure these settings on the Delivery Options tab of the SMTP connector's Properties dialog box.

SMTP communication

Controls how the connector uses SMTP to communicate with other SMTP servers. Specifically, you can specify whether the connector uses SMTP or Extended Simple Mail Transfer Protocol (ESMTP) commands to initiate a conversation with another server and control the use of the ERTN and TURN commands. (These commands request that another SMTP server sends the e-mail messages that it has.)

You configure these settings on the Advanced tab of the SMTP connector's Properties dialog box.

Outbound security

Ensures that any mail flowing through the connector is authenticated. This setting is useful if you want to establish a more secure route for communicating with a partner company. With this setting, you can establish an authentication method and require Transport Layer Security (TLS) encryption.

You configure these settings on the Advanced tab of the SMTP connector's Properties dialog box.

 


Verifying DNS Setup for Outbound Mail

To send Internet mail using DNS rather than forwarding mail to a smart host, the Exchange server resolves the receiving domain and IP address of the recipient's SMTP server. The server then uses SMTP over TCP port 25 to establish a conversation with the recipient's SMTP server, and deliver the mail.

When you use DNS, the most important thing to remember is that all DNS servers that an Exchange server uses must be able to resolve external domains (also referred to as Internet domains).

There are two methods that you can use to configure DNS for outbound mail:

·         Method 1   You can configure Exchange to rely on your internal DNS servers. These servers resolve external names on their own or use a forwarder to an external DNS server.

·         Method 2   You can configure Exchange to use a dedicated external DNS server. (For more information about external DNS servers, see "To specify an external DNS server used by the SMTP virtual server" in the section "Verifying Outbound Settings on SMTP Virtual Servers" earlier in this chapter.)

 

For more information about how to configure and verify your DNS configuration, see Configuring SMTP in Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=15084) and your Windows documentation.

Manually Configuring the Receipt of Internet Mail

Manually configuring Exchange to receive Internet mail involves:

·         Creating the proper recipient policies, so that your Exchange server receives mail for all e-mail domains that are used by your company.

·         Configuring inbound SMTP virtual server settings to allow anonymous access, so that other SMTP servers can connect and send mail to your SMTP virtual server.

·         Verifying that the correct MX records exist in DNS, so that other servers on the Internet can locate your server to deliver mail.

 

This section explains how to configure these settings on your Exchange server.


Configuring Recipient Policies

Exchange uses recipient policies to determine which messages should be accepted and internally routed to mailboxes in your organization. Recipient policies that are configured improperly can disrupt message flow for some or all recipients in your messaging system. Recipient policies are configured in Exchange System Manager under the Recipients container in Recipient Policies.

To ensure that your recipient policies are configured properly, verify the following:

·         That recipient policies do not contain an SMTP address that matches the fully qualified domain name (FQDN) of any Exchange server in your organization. For example, if you have an Exchange server with an FQDN of server01.contoso.com and you also have this same FQDN (@server01.contoso.com) listed as an SMTP address and as a domain name on any recipient policy, this entry prevents mail from routing to other servers in the routing group.

·         That the domain for which you want to receive SMTP mail is listed on a recipient policy—either on the default policy or another recipient policy. By verifying this information, you ensure that your users can receive mail from other SMTP domains.

·         That you configured the necessary SMTP e-mail addresses to receive e-mail messages for additional domains. If you are not receiving e-mail messages for all of your SMTP domains, you may need to configure additional SMTP addresses for your recipients. For example, some of your users may currently receive e-mail messages addressed to contoso.com, but you also want them to receive e-mail messages addressed to adatum.com. In this situation, the SMTP address of @adatum.com and the SMTP address of @contoso.com must exist on a recipient policy for your Exchange organization.

 

For more information about recipient policies, see Chapter 4, "Managing Recipients and Recipient Policies."

Configuring Inbound SMTP Virtual Server Settings

To configure your SMTP virtual server to receive Internet mail, you must perform the following tasks:

·         Configure the inbound port as 25 and specify the IP address   Other servers on the Internet expect to connect to your SMTP virtual server on port 25. By default, all SMTP virtual servers use this port.


·         Verify that your SMTP virtual server allows anonymous access   To receive Internet mail, your SMTP virtual server must permit anonymous access. Other servers on the Internet expect to communicate anonymously with your SMTP virtual server to send Internet mail to your users.

·         Verify that default relay restrictions are configured on your SMTP virtual server   By default, the SMTP virtual server allows only authenticated users to relay e-mail messages. This setting prevents unauthorized users from using your Exchange server to send e-mail messages to external domains.

 

The following procedures describe how to perform each of these tasks.

To configure or verify the inbound port and IP address

·         In Exchange System Manager, in the Properties dialog box of the SMTP virtual server, on the General tab, click Advanced.

The Advanced dialog box appears (see Figure 5.14). By default, your SMTP virtual server uses an IP address of All Unassigned, which means that the virtual server listens for requests on all available IP addresses. You can keep the default IP address, or click Edit to change the address. By default, your SMTP virtual server uses TCP port 25. It is recommended that you do not modify the default port assignment.

Figure 5.14   Advanced dialog box

 


To verify that your SMTP virtual server is configured to allow anonymous access

1.        In Exchange System Manager, in the Properties dialog box of the SMTP virtual server, on the Access tab, click Authentication.

2.        In the Authentication dialog box (see Figure 5.15), select the Anonymous access check box (if it is not already selected).

Figure 5.15   Authentication dialog box

 


To verify that your SMTP virtual server is not set to open relay

1.        In Exchange System Manager, in the Properties dialog box of the SMTP virtual server, on the Access tab, click Relay.

2.        In the Relay Restrictions dialog box (see Figure 5.16), select Only the list below (if it is not already selected), click Add, and follow the instructions to add only those hosts that you want to allow to relay mail to the list.

Note   
If you select All except the list below, your server may be used by unauthorized users to distribute unsolicited e-mail messages on the Internet.

 

Figure 5.16   Relay Restrictions dialog box

 

3.        Select Allow all computers which successfully authenticate to relay, regardless of the list above (if it is not already selected).

This setting allows you to deny relay permissions to all users who do not authenticate. Any remote Internet Message Access Protocol version 4 (IMAP4) and Post Office Protocol version 3 (POP3) users who access this server will authenticate to send mail. If you do not have users who access this server through IMAP4 or POP3, you can clear this check box to prevent relaying entirely, thereby increasing security. You can also designate a specific server for IMAP4 and POP3 users, and then clear this check box on all other Internet gateway servers.

 


Verifying DNS Setup for Inbound Mail

To receive Internet mail, the following DNS settings are necessary:

·         Your DNS server must be configured correctly.

·         Your external DNS servers must have an MX record pointing to an A record with the IP address of your mail server. The IP address must match the IP address configured on your SMTP virtual server that receives Internet mail.

·         For external DNS servers to resolve your mail server's MX record and contact your mail server, your mail server must be accessible from the Internet.

·         Your Exchange server must be configured to use a DNS server that can resolve external DNS names.

 

To ensure that your MX records are configured correctly, you can use the Nslookup utility. To verify that your server is accessible on port 25 to other servers on the Internet, you can use Telnet.

Note   
For more information about how to configure and verify your DNS configuration, see Configuring SMTP in Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=15084) and your Windows documentation.

 

Enabling Filtering to Control Junk E-Mail Messages

Exchange Server 2003 supports three types of filters: connection filtering, recipient filtering, and sender filtering. These filters are useful in reducing the amount of junk e-mail messages your users receive.


You configure filtering in Message Delivery Properties under Global Settings. However, you must enable these filters on each SMTP virtual server to which you want to apply the filters. Generally, you should enable filtering on your Internet gateway servers because filtering is applied only to mail submitted from external users. On Exchange servers designated for internal mail, you do not need to enable filtering.

To enable filtering

1.        On the General tab of the SMTP virtual Properties dialog box, click Advanced.

2.        Select an IP address, and then click Edit.

3.        In the Identification dialog box (see Figure 5.17), enable the filters that you want applied on this virtual server.

Figure 5.17 shows a virtual server with sender, recipient, and connection filtering enabled.

Figure 5.17   Identification dialog box

 


Connecting to Exchange 5.5 Servers and Other X.400 Systems

This section focuses on using the X.400 protocol and X.400 connectors to connect to Exchange 5.5 servers or other third-party X.400 mail systems. The X.400 connector relies on the X.400 protocol and its accompanying transport stack to provide the underlying transport functionality.

Three components control the behavior of the X.400 protocol on an Exchange server:

·         X.400 protocol   An X.400 node appears under the Protocols container in Exchange System Manager on an Exchange server. Properties that are configured on the X.400 protocol determine how the protocol works on an individual server.

·         X.400 transport stacks   An X.400 transport stack contains configuration information about network software, such as TCP/IP network services, and information about hardware, such as an X.25 port adapter or dial-up connection on the computer running Exchange. Each X.400 connector requires a transport stack on which to run and communicates using the configuration information within that stack. You can create either an X.400 TCP transport stack or an X.400 X.25 transport stack.

·         X.400 connectors   X.400 connectors provide a mechanism for connecting Exchange servers with other X.400 systems or Exchange 5.5 servers outside of the Exchange organization. An Exchange 2003 server can then send messages using the X.400 protocol over this connector.

Important   
X.400 connectors are only available in Exchange Server 2003 Enterprise Edition.

 


Customizing the X.400 Protocol

The X.400 protocol provides the underlying functionality used by X.400 connectors and protocol stacks. The X.400 service message transfer agent (MTA) stack, located in the Protocols container under your Exchange server in Exchange System Manager, provides addressing and routing information for sending messages from one server to another. Use the X.400 Properties dialog box (see Figure 5.18) to configure basic settings and messaging defaults used by the X.400 protocol on your server. Any X.400 transport stacks and X.400 connectors that you create on this server inherit these settings by default, although you can override this configuration on individual connectors.

Figure 5.18   The General tab on the X.400 Properties dialog box

 


The following general properties can be set on the X.400 protocol.

·         The entry in the LocalX.400 name box identifies the X.400 account that Exchange uses when it connects to the remote system. This name identifies the MTA to other mail systems. By default, this name is the name of the server where the X.400 service is installed. You can change the local X.400 name by using the Modify button. You can also set a local X.400 password. Third-party systems use this password when connecting to the X.400 service.

·         The Expand remote distribution lists locally option makes a remote distribution list available to users in your organization. When this option is selected and a user sends a message to a remote distribution list, the distribution list expands locally (on the server to which the user is currently connected). Exchange finds the best routing for the message, based on the location of recipients in the list. This method ensures the most efficient message handling. However, note that processing large distribution lists can affect server performance.

·         The Convert incoming messages to Exchange contents option changes the address and contents of incoming messages to a format compatible with MAPI clients, such as Microsoft Outlook® and Exchange. Do not select this option if your users do not use a MAPI client.

·         The Modify button in Message queue directory allows you to change the location of the X.400 message queue directory.

Note   
When you modify the location of the queue directory, you are modifying only the MTA database path and moving only the database (.dat) files. You are not moving any of the run files or the run directory. The database files are the core files that are required for starting the MTA, queue files, and message files.

 

Understanding X.400 Connectors

Generally, you use X.400 connectors in the following situations:

·         If your environment has an existing X.25 network.

·         If you are connecting to an X.400 system or an Exchange 5.5 server outside of your organization.

Note   
Although you can use X.400 connectors to connect routing groups within Exchange, the routing group connector is recommended.

 


You can create two types of connectors on Exchange Server 2003 Enterprise Edition: TCP X.400 connectors and X.25 X.400 connectors. The TCP connector enables connectivity over a TCP/IP network, and the X.25 connector enables connectivity using X.25.

To configure an X.400 connector, you perform the following steps:

1.        Create an X.400 protocol stack.

2.        Create an X.400 connector.

 

The following sections detail these steps.

Creating an X.400 Protocol Stack

Before you create an X.400 connector, you must create a protocol stack on the Exchange server that will host the connector. The protocol (or transport) stack is created on individual Exchange servers and provides the underlying functionality for the connector to transport messages. The server on which you create the protocol stack processes all messages that are sent by connectors that use this stack.

You create a transport stack using TCP or X.25, based on your network and the system to which you are connecting. Creating a transport stack involves the same steps for either protocol.

To create a transport stack

1.        In Exchange System Manager, expand Protocols, right-click X.400, point to New, and then select either TCP/IP X.400 Service Transport Stack or X.25 X.400 Service Transport Stack.

2.        On the General tab, type a name for this transport stack.

The following names are the default names:

·         X.25 <server name>

·         TCP <server name>

 


3.        (Optional) Under OSI address information, select the character set and the selector information if other applications use this transport stack.

Figure 5.19 shows the General tab of the Properties dialog box for a TCP/IP X.400 transport stack. On this tab, you can configure the transport stack. Any connectors that you configure to use this transport stack appear on the Connectors tab.

Note   
When you first create the connector, the Connectors tab does not list any connectors.

 

Figure 5.19   General tab of the Properties dialog box for a TCP/IP X.400 transport stack

 


4.        (Optional) On the General tab of an X.25 transport stack (see Figure 5.20), set the following X.25-specific configuration options:

·         Based on the information supplied by your X.400 service provider, type in the appropriate values for Call user data, Facilities data, and the X.121 address of the remote X.25 provider.

·         For I/O port, type in the port number used by the X.25 adaptor. (If you have multiple X.25 X.400 transport stacks on a single server, each stack must use a different port number.)

Figure 5.20   General tab of the Properties dialog box for an X.25 protocol stack

 


Creating an X.400 Connector

After you create a TCP X.400 or X.25 X.400 transport stack, you can create an X.400 connector to connect to another X.400 system. Remember that connectors send mail in only one direction, so the X.400 connector enables mail to flow from your system to the remote system or routing group. If you are connecting to a remote system, the administrator of that system must also create a connector to send mail to your organization.

Table 5.5 lists the configuration settings that are available for an X.400 connector. These settings are available in the Properties dialog box for an X.400 connector (see Figure 5.21).

Table 5.5   Configuration settings for an X.400 connector

Settings

Description

Remote X.400 name

When you configure an X.400 connector, you need to specify a valid account and password for the remote X.400 system to which you are connecting.

You configure these settings on the General tab of the X.400 connector's Properties dialog box.

Address space

The address space defines the mail addresses or domains for the e-mail messages that you want routed through a connector. You can specify the X.400 address of a third-party X.400 system or an Exchange 5.5 server to which you are connecting, so that all mail destined to the specified X.400 system is routed through this connector.

You configure these settings on the Address Space tab of the X.400 connector's Properties dialog box.

Transport address information for the remote system

You must specify transport address information for the remote X.400 system to which you are connecting.

You configure these settings on the Stack tab of the X.400 connector's Properties dialog box.


 

Settings

Description

Content restrictions

You can specify what types of messages are delivered through a connector.

You configure these settings on the Content Restrictions tab of the X.400 connector's Properties dialog box.

Scope

You can select either an entire organization or a routing group for the connector's scope. For example, if you create an X.400 connector to send mail to an X.400 system on a server in one routing group, and an X.400 connector exists on a server in another routing group, you may choose to specify a routing group scope for these connectors so that servers in each routing group are forced to use the connector. If an X.400 connector that is set to a routing group scope becomes unavailable, messages queue in the routing group until the connector becomes available. If your user requirements permit this, you could implement the connectors with a routing group scope.

You configure these settings on the Address Space tab of the X.400 connector's Properties dialog box.

Override options

By default, the X.400 connector inherits the settings that are configured on the X.400 protocol.

To override these settings, you use the Override tab of the X.400 connector's Properties dialog box.

Delivery restrictions

You can restrict who can send mail through a connector. By default, mail is accepted from everyone.

You configure these settings on the Delivery Restrictions tab of the X.400 connector's Properties dialog box.

 


To create an X.400 connector

1.        In Exchange System Manager, right-click Connectors, point to New, and then click X.25 X.400 Connector or TCP X.400 Connector.

2.        On the General tab (see Figure 5.21), in the Name box, type the connector name.

Figure 5.21   General tab of the Properties dialog box for an X.400 connector

 

3.        On the General tab, under Remote X.400 name, click Modify.

4.        In Remote Connection Credentials, in Remote X.400 name, type the name of the remote X.400 connector on the remote server. (The remote connector name defaults to the remote server name.) In the Password box, type the password for the remote X.400 connector. In the Confirm password box, type the password again.


5.        Select one of the following options:

·         On the Address Space tab, click Add, select an address type, and then, in the Address Properties box, type all necessary information, including cost.

·         On the Connected Routing Groups tab, click New. On the General tab, in the Organization box, type the name of the organization that contains the routing group to which you want to connect, and then in the Routing Group box, type the name of the routing group to which you want to connect.

Note   
The organization must exist on an Exchange server so that the naming conventions are known. Optionally, you can type address space information and cost on the Routing Address tab. By default, the address space is created from the organization and routing group names, and the cost is 1.

 

6.        If the remote system is not an Exchange server, on the Advanced tab, clear the Allow Exchange contents check box.

If you do not clear the check box, addresses on messages are in domain name form and not in X.400 form, and replies are not possible.

7.        On the Stack tab for an X.25 X.400 connector, in the X.121 address box, type the X.121 address of the remote server as specified in the X.25 network service setup.

—or—

On the Stack tab for a TCP X.400 connector, choose one of the following options:

·         Select Remote host name, and then, in the Address box, type the fully qualified domain name (FQDN).

·         Select IP Address, and then, in the Address box, type the remote server's IP address.

 

Configuring Additional Options on the X.400 Connector

You can also use the General tab of the X.400 connector (see Figure 5.21) to configure public folder referrals and specify how messages are delivered by this connector. These additional options include:

·         The Message text word-wrap option controls whether or not text wraps at a specific column in a message.

·         The Remote clients support MAPI option results in Exchange sending messages through the connector in rich text format. Do not select this option if clients do not support MAPI because it can cause problems with message formatting on non-MAPI clients.

·         The Do not allow public folder referrals option prevents public folder referrals when you connect to another routing group. Public folder referrals enable users in a connected routing group or a remote system to access public folders through this connector.

 


Overriding X.400 Properties

By default, each X.400 connector inherits the settings that are configured on the X.400 protocol. You can use the Override tab (see Figure 5.22) on the X.400 connector to override the options that are set on the X.400 protocol.

Figure 5.22   Override tab

 

The configuration options that are available on the Override tab are as follows:

·         The name entered in the Local X.400 Service name box overrides the local X.400 name of the X.400 transport stack. Some X.400 systems do not support certain characters. If your local X.400 name contains characters that are not supported by the remote system to which you are connecting, use this option to connect to the remote X.400 service using a name that it can support.

·         The Maximum open retries option sets the maximum number of times that the system tries to open a connection before it sends a non-delivery report (NDR). The default is 144.

·         The Maximum transfer retries option sets the maximum number of times that the system tries to transfer a message across an open connection. The default is 2.


·         The Open interval (sec) option sets the number of seconds that the system waits after a message transfer fails. The default is 600.

·         The Transfer interval (sec) option sets the number of seconds the system waits after a message transfer fails before resending a message across an open connection. The default is 120.

 

Tip   
To restore Exchange default values, click Reset Default Value.

 

To set additional override values, you use the Additional Values dialog box (see Figure 5.23). To open this dialog box, click the Additional Values button on the Override tab in the X.400 connector's Properties dialog box.

Figure 5.23   Additional Values dialog box

 


In the Additional Values dialog box, you can set these options:

·         The options under RTS values set the Reliable Transfers Service (RTS) values. RTS values determine message reliability parameters, such as the checkpoints to include in data and the amount of unacknowledged data that can be sent. You can use the options on an X.400 connectors' Override tab to override the default X.400 service attributes, such as RTS values.

·         The options under Association parameters determine the number and duration of connections to the remote system. Each X.400 connector uses the association parameters that are configured on the X.400 protocol, but you can configure association parameters on each individual connector to override the settings.

·         The options under Transfer timeouts determine how long the X.400 connector waits before sending an NDR for urgent, normal, and not urgent messages. Each X.400 connector uses the transfer timeout values that are configured on the X.400 MTA, but you can configure specific transfer timeout values on each individual connector that override these settings.

Disabling or Removing Connectors

If necessary, you can disable or remove existing connectors in your organization.

You can disable a connector that you do not want Exchange to use by setting the connection schedule to Never. Disabling a connector rather than deleting it allows you to retain the configuration settings if you want to enable it again in the future.

To disable a connector

1.        In Exchange System Manager, right-click a connector, and then click Properties.

2.        Select one of the following options:

·         For an X.400 connector, click the Schedule tab, and then click Never.

·         For an SMTP connector or a routing group connector, click the Delivery Options tab. Under Specify when messages are sent through this connector, in Connection time, select Never run from the drop-down list.

 

You can remove a connector that you no longer use by deleting it. You can remove a connector at any time. When you remove a connector, you are not warned of the connections you are breaking. (For example, you may be breaking an established connection between two routing groups.) However, you are prompted to verify that you want to remove the connector.

To remove a connector

·         In Exchange System Manager, right-click the connector that you want to remove, and then click Delete.

 


Using Queue Viewer to Manage Messages

Queue Viewer is a feature in Exchange System Manager that allows you to monitor your organization's messaging queues, as well as the messages that are contained within those queues. Queue Viewer works at a server level. In Exchange System Manager, you expand the server and then click Queues to open Queue Viewer and display the messaging queues associated with the server (see Figure 5.24).

Figure 5.24   Queue Viewer in Exchange 2003

 

In Exchange Server 2003, Queue Viewer is enhanced to improve the monitoring of message queues. In Exchange 2003, you can view all of the messaging queues for a specific server from the Queues node under each server. This is an improvement over Exchange 2000, where each protocol virtual server has its own Queues node, and you cannot view all queues on a server from a central location. For example, using Exchange 2003, you can now use Queue Viewer to view both the X.400 and SMTP queues on a server (as in Figure 5.24), rather than having to view each of these queues separately in each of their respective protocol nodes.


Other enhancements to Queue Viewer in Exchange 2003 include:

·         Disabling outbound mail   You can use a new option called Disable Outbound Mail to disable outbound mail from all SMTP queues.

·         Setting the refresh rate   You can use the Settings option to set the refresh rate of Queue Viewer.

·         Finding messages   You can use Find Messages to search for messages based on the sender, recipient, and message state. This option is similar to enumerating messages in Queue Viewer in Exchange 2000.

·         Viewing additional information   You can click a specific queue to view additional information about that queue.

·         Viewing previously hidden queues   Queue Viewer in Exchange 2003 exposes three queues that were not visible in Exchange 2000: DSN messages pending submission, Failed message retry queue, and Messages queued for deferred delivery. (For descriptions of these queues, see Table 5.9.)

 

The remainder of this section highlights two of these new enhancements, disabling outbound mail and finding messages, as well as provides guidelines for how to use the SMTP and X.400 queues shown in Queue Viewer to troubleshoot message flow.

Disabling Outbound Mail

Using the Disable Outbound Mail option, you can disable outbound mail from all SMTP queues. For example, disabling outbound mail can be useful if a virus is active in your organization.

To disable outbound mail

·         In Queue Viewer, click Disable Outbound Mail.

 

Note   
The Disable Outbound Mail option does not disable the MTA or system queues. System queues are default queues for each protocol that hold messages only while certain essential routing tasks are performed, such as content conversion and address resolution. If you find messages in your system queues for extended periods, it means that one or more basic routing functions are failing somewhere in your Exchange organization. For more information about working with message accumulation in queues, see the sections "Using SMTP Queues to Troubleshoot Message Flow" and "Using X.400 (MTA) Queues to Troubleshoot Message Flow" later in this chapter.

 

If you want to prevent outbound mail from a particular remote queue, instead of disabling all SMTP queues, you can freeze the messages in that particular queue.


To freeze all of the messages in a particular queue

·         In Queue Viewer, right-click the queue, and then click Freeze.

 

To unfreeze a queue

·         In Queue Viewer, right-click the queue, and then click Unfreeze.

Finding Messages

You can use the Find Messages option to search for messages by specifying search criteria (such as the sender or recipient) or the message state (such as frozen). You can also specify the number of messages that you want your search to return. Using Find Messages in Exchange Server 2003 is similar to the Enumerate messages option in Exchange 2000.

To search for messages by a particular sender (or recipient)

·         In Queue Viewer, click Find Messages, click Sender (or Recipient), and then search by typing the name or using the search criteria.

 

To specify the number of messages that you want returned by a search

·         In Queue Viewer, click Find Messages, click the Number of messages to be listed in the search list, and select the number of messages (for example, 500) that you want listed in the search.

 

To search for messages in a particular state

1.        In Queue Viewer, click Find Messages, click the Show messages whose state is list, and select from the following options:

·         All Messages   This option shows all of the messages in the list regardless of the state that they are in.

·         Frozen   This option shows the messages that are in a frozen state. Besides freezing all messages in a specific queue, a single message can also be frozen. If a single message or a few messages in a queue are frozen, other messages can still flow into or out of this queue. The entire queue is not frozen.

·         Retry   This option shows the messages that are awaiting another delivery attempt. Messages in the retry state have failed one or more delivery attempts.

 

2.        After you have specified your search criteria, click Find Now to begin the search.

The results of the search appear under Search Results.

 

Using SMTP Queues to Troubleshoot Message Flow

During message categorization and delivery, all mail is sent through the SMTP queues of an SMTP virtual server. If there is a problem delivering the message at any point in the process, the message remains in the queue where the problem occurred until the problem is remedied.

Use the SMTP queues to isolate possible causes of mail flow issues. If a queue is in a Retry status, in Queue Viewer, select the queue and check the properties of the queue to determine the cause. For example, if the queue properties display a message similar to "An SMTP error has occurred," you should review your server's event logs to locate any SMTP errors. If there are no events in the log, you should increase the SMTP logging level, by right-clicking the Exchange server, clicking Properties, clicking the Diagnostics Logging tab, and then selecting MSExchangeTransport.

Table 5.6 lists the SMTP queues, their descriptions, and troubleshooting information for message accumulation in each queue.

Table 5.6   SMTP queues

Queue name

Description

Causes of message accumulation

DSN messages pending submission

Contains delivery status notifications, also known as non-delivery reports (NDRs), that are ready to be delivered by Exchange.

Note   
The following operations are unavailable for this queue: Delete All Messages (no NDR) and Delete All Messages (NDR).

 

Messages can accumulate in this queue if the store service is unavailable or not running, or if problems exist with the IMAIL Exchange store component, which is the store component that performs message conversion.

Check the event log for possible errors with the store service.

Failed message retry queue

Contains messages that Exchange has failed to deliver, but that the server will attempt to send again.

Note   
The following operations are unavailable for this queue: Delete All Messages (no NDR) and Delete All Messages (NDR).

 

Messages can accumulate in this queue if a problem exists with DNS or SMTP.

Check the event log to determine whether an SMTP problem exists. Verify your DNS configuration using NSlookup or another utility.

On rare occasions, a corrupted message can remain in this queue. To determine whether a message is corrupted, try to look at its properties. If some properties are not accessible, this can indicate message corruption.

Messages queued for deferred delivery

Contains messages queued for delivery at a later time, including messages sent by earlier versions of Outlook clients. (You can set this option in Outlook clients.)

Messages sent by earlier versions of Outlook treat deferred delivery slightly differently. Previous versions of Outlook depend on the MTA for message delivery because SMTP, not the MTA, now handles message delivery.

These messages remain in this queue until their scheduled delivery time.

Possible causes of message accumulation include:

·         Messages are sent to a user's mailbox while the mailbox is being moved.

·         The user does not yet have a mailbox created, and no master account security identifier (SID) exists for the user. For more information, see Microsoft Knowledge Base Article 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts" (http://support.microsoft.com/?kbid=316047).

·         The message may be corrupted, or the recipient may not be valid.

To determine if a message is corrupted, check its properties. If some properties are not accessible, this can indicate a corrupted message. Also check that the recipient is valid.

Local delivery

Contains messages that are queued on the Exchange server for local delivery to an Exchange mailbox.

Messages can accumulate in this queue if the Exchange server is not accepting messages for local delivery. Slow or sporadic message delivery can indicate a looping message or a performance problem.

This queue is affected by the Exchange store. Increase diagnostic logging for the Exchange store as described in "Configuring Diagnostic Logging for SMTP" later in this chapter.


 

Queue name

Description

Causes of message accumulation

Messages awaiting directory lookup

Contains messages addressed to recipients who have not yet been resolved against Active Directory. Messages are also held here while distribution lists are expanded.

Generally, messages accumulate in this queue because the advanced queuing engine is unable to categorize the message. The advanced queuing engine may not be able to access the global catalog servers and access recipient information, or the global catalog servers are unreachable or performing slowly.

The categorizer affects this queue. Increase diagnostic logging for the categorizer as described in "Configuring Diagnostic Logging for SMTP" later in this chapter.

Messages waiting to be routed

Holds messages until their next-destination server is determined, and then moves them to their respective link queues.

Messages accumulate in this queue if Exchange routing problems exist. Message routing may be experiencing problems.

Increase diagnostic logging for routing as described in "Configuring Diagnostic Logging for SMTP" later in this chapter.

[Connector name | Server name | Remote domain]

Holds messages destined for a remote delivery. The name of the queue matches the remote delivery destination, which may be a connector, a server, or a domain.

If messages accumulate in this queue, you must first identify the status of the queue. If the queue status is Retry, check the queue properties to determine the reason that it is in this state. For DNS issues, use Nslookup and Telnet to troubleshoot. If the host is unreachable, use Telnet to ensure that the remote server is responding.


 

Queue name

Description

Causes of message accumulation

Final destination currently unreachable

Contains messages for which the final destination server cannot be reached. For example, Exchange cannot determine a network path to the final destination.

Messages can accumulate in this queue if no route exists for delivery. Additionally, any time a connector or a remote delivery queue is unavailable or in Retry for a period of time, and no alternate route exists to the connector or remote destination, new messages queue here. Messages can remain in this queue until an administrator fixes the problem or defines an alternate route. To get new messages to flow to their remote destination queue, allowing you to force a connection and get a Network Monitor (NetMon) trace, restart the SMTP virtual server.

Pre-submission

Holds messages that have been acknowledged and accepted by the SMTP service. The processing of these messages has not begun.

Messages that are accumulating constantly may indicate a performance problem. Occasional peaks in performance can cause messages to appear in this queue intermittently.

Message accumulation in this queue can also indicate problems with a custom event sink or a third-party event sink.

 


Using X.400 (MTA) Queues to Troubleshoot Message Flow

Exchange Server 2003 uses the X.400 queues to submit mail to and receive mail from Exchange 5.5 servers and to send mail through connectors to other mail servers. If you experience mail flow problems when you are sending mail to an Exchange 5.5 or earlier server, or to another mail system to which you are connecting using X.400, check the X.400 queues on the Exchange server. If you experience mail flow problems when sending mail to servers that are running Exchange 5.5 or earlier, you should also check the MTA queues on those servers.

Table 5.7 lists the X.400 queues, their descriptions, and troubleshooting information for message accumulation in each queue.

Table 5.7   X.400 queues

Queue name

Description

Causes of message accumulation

PendingRerouteQ

Contains messages that are waiting to be rerouted after a temporary link outage.

Messages can accumulate in this queue if a route to a connector, to a different mail system, or to an Exchange 5.5 server is unavailable.

Next hop MTA

Contains messages destined to one of the following:

·         Another gateway, such as a connector for Lotus Notes or Novell GroupWise.

·         An X.400 link to an Exchange 5.5 site or a destination outside of the organization.

·         An Exchange MTA over the LAN—for example, destined to an Exchange 5.5 server in a mixed-mode environment.

Messages can accumulate in this queue when Exchange 2003 experiences problems sending to another mail system, to an Exchange 5.5 server, or through an X.400 link.

Increase diagnostic logging for the X.400 service as described in "Configuring Diagnostic Logging for the X.400 Service (MSExchangeMTA)" later in this chapter.

 


Configuring Diagnostic Logging for SMTP

To help you determine the cause of a transport issue, you can view events that relate to MSExchangeTransport. If you experience problems with Exchange message flow, immediately increase the logging levels relating to MSExchangeTransport. Logging levels control the amount of data that is logged in the application log. The more events that are logged, the more transport-related events that you can view in the application log. Therefore, you have a better chance of determining the cause of the message flow problem. The SMTP log file is located in the Exchsrvr\Server_name.log folder.

As discussed in "Using SMTP Queues to Troubleshoot Message Flow" and "Using X.400 (MTA) Queues to Troubleshoot Message Flow" earlier in this chapter, issues with specific routing and transport components can cause messages to accumulate in a queue. If you are having problems with a specific queue, increase the logging level for the component that is affecting the queue.

Modifying Logging Settings

The following procedure explains how to modify diagnostic logging related to MSExchangeTransport.

To modify logging settings for MSExchangeTransport

1.        In the console tree, expand Servers, right-click <server name>, and then click Properties.

2.        Click the Diagnostics Logging tab.

3.        Under Services, click MSExchangeTransport.

4.        Under Categories, click the category for which you want to configure the logging level:

·         To troubleshoot routing issues, select Routing Engine/Service. Increase the logging level for this component if messages are accumulating in the Messages waiting to be routed SMTP queue.

·         To troubleshoot problems with address resolution in Active Directory, distribution list expansion, and other categorizer issues, select Categorizer. Increase the logging level for this component if messages are accumulating in the Messages waiting to be routed SMTP queue.

·         To troubleshoot issues with dial-up and virtual private network connectivity through Connection Manager, select Connection Manager.

·         To troubleshoot problems with the queuing engine, select Queuing Engine. Increase the logging level for this component if you are experiencing mail flow problems, and mail is not accumulating in any of the queues.

·         To troubleshoot issues with the Exchange store driver, select Exchange Store Driver. Increase the logging level for this component if messages are accumulating in the local delivery SMTP queue, the X.400 queues, or if you have problems receiving mail from Exchange 5.x servers or other mail systems.

·         To troubleshoot general SMTP issues, select SMTP Protocol. Increase the logging level for this component if messages are accumulating in the Remote delivery SMTP queue to determine if SMTP errors are causing the bottleneck.

·         To troubleshoot issues with the NTFS store driver, select NTFS Store Driver. Increase the logging level for this category if messages are accumulating in the local delivery SMTP queue.

5.        Under Logging level, click None, Minimum, Medium, or Maximum.

Click Maximum for troubleshooting purposes.

Caution   
If you increase the logging levels for Exchange services, you will experience some performance degradation. It is recommended that you increase the size of the application log to contain all of the data produced. If you do not increase the size of the application log, you will receive frequent reminders that the application log is full.

 

Enabling Debugging Level Logging

If you are experiencing mail flow issues and want to view all events, you can modify a registry key to set logging to the debugging level, which is the highest level (level 7).

Caution   
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

 

To enable logging at the debugging level

1.        Start Registry Editor.

2.        In Registry Editor, locate and click the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
MSExchangeTransport\Diagnostics\SMTP Protocol

3.        Set the value to 7, and then click OK.

 


Configuring Diagnostic Logging for the X.400 Service (MSExchangeMTA)

This section explains how to configure diagnostic logging for the X.400 service (MSExchangeMTA) on Exchange Server 2003. If you have to troubleshoot mail flow problems for servers running Exchange 5.5 and earlier, for other mail systems, or for X.400 connectors, it is useful to increase the logging level for MSExchangeMTA.

To configure logging for MSExchangeMTA

1.        In the console tree, expand Servers, right-click <server name>, and then click Properties.

2.        Click the Diagnostics Logging tab.

3.        Under Services, click MSExchangeMTA.

4.        Under Categories, click X.400 Service to troubleshoot delivery problems to servers running Exchange 5.5 and earlier, and other systems.

5.        Under Logging level, click None, Minimum, Medium, or Maximum.

Click Maximum for troubleshooting purposes.

 

 


Chapter 6

Managing Client Access to Exchange

This chapter reviews basic client access concepts, and how you manage the protocols used by the individual clients that access Exchange and the front-end and back-end server architecture.

This chapter also explains how to administer Microsoft® Exchange Server 2003 for client access in the context of a front-end/back-end server architecture. If you use more than one server, it is recommended that you use the front-end and back-end server architecture to handle the various messaging needs for the clients that you support.

The first part of this chapter provides an overview of the front-end and back-end server architecture. The second part of this chapter explains the configuration settings for the individual clients for Exchange. Use this chapter to configure your Exchange server for client access.

Note   
To properly manage client access to Exchange Server 2003, you must first understand how Microsoft Windows® technologies, such as Internet Information Services (IIS) and the Microsoft Active Directory® directory service, interact with Exchange. You must also understand protocols such as HTTP and MAPI, and how client applications such as Exchange ActiveSync® and Microsoft Office Outlook® 2003 use these respective protocols to interact with Exchange.

 


Preparing to Manage Client Access

Before you configure the settings on your Exchange server for the protocols and clients that you will support, make sure that you have properly configured Exchange for your particular client access needs.

In general, to configure Exchange for client access, you must complete the following steps:

1.        Choose your topology.

2.        Secure your messaging infrastructure.

3.        Choose your client access model and protocols.

4.        Enable protocols that you will support. (optional)

5.        Configure clients and devices.

 

The following sections briefly discuss each of these steps, giving you an overview of what each step involves and what to consider in making decisions related to that step. For more detailed information regarding the first three steps—topology, messaging infrastructure, and client access model, refer to the cross-references located in each of the following overview sections. For more detailed information about enabling protocols and configuring clients, see the appropriate sections later in this chapter.


Choosing a Topology

If you have more than one Exchange server, and if you plan to allow external access to Exchange from the Internet, you must understand the recommended Exchange front-end and back-end server architecture. This server architecture simplifies the client access model for organizations with multiple Exchange servers by using a single Exchange server to handle all requests from clients. The front-end server is responsible for proxying requests from clients and passing these requests to the Exchange back-end servers that have mailboxes on them. Front-end and back-end server architectures vary from simple to complex. Figure 6.1 shows the recommended front-end and back-end server architecture with the various clients that Exchange supports.

Figure 6.1   The recommended Exchange front-end and back-end server architecture

 


Understanding this server architecture helps you to better manage the types of clients that you plan to support in your messaging infrastructure. For more information about the front-end and back-end server architecture and choosing a topology for your Exchange deployment, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library). For the complete steps related to configuring the Exchange front-end and back-end server architecture, see "Post Installation Procedures," in the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

Note   
You are no longer required to use Enterprise Server 2003 Enterprise Edition as your front-end server. You can run Exchange Server 2003 Standard Edition on your front-end server.

 

Configuring Security for Client Access

Before you deploy Exchange, prepare your organization for the client access methods that you will support by securing your messaging infrastructure. This involves the following steps:

1.        Updating your server software.

2.        Securing the Exchange messaging environment.

3.        Securing communications.

 

For complete details about securing your messaging infrastructure, see the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

Choosing Client Access Model and Protocols

Although Simple Mail Transfer Protocol (SMTP) is the primary messaging protocol of Exchange, clients that communicate with Exchange often use protocols other than SMTP. Clients communicate using Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), HTTP, or Network News Transfer Protocol (NNTP). Some clients support all of these protocols; others do not. To accommodate these differences in protocol usage, Exchange supports all of these protocols. This comprehensive support means that you do not have to limit yourself when choosing a client access model. You decide what client access model best fits your users' needs, and then you select the protocols in Exchange that support this model.

Note   
These services, as well as SMTP, are part of the Microsoft Windows Server™ 2003 operating system and run in IIS under the Inetinfo.exe process.

 

For more information about choosing a client access model and protocols, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library). After you select your client access model and supported protocols, you then enable and manage those protocols as described in "Managing Protocols" later in this chapter.


Configuring Clients and Devices

Part of planning an Exchange deployment involves determining which clients are necessary for the users in your organization. Exchange 2003 provides support for clients that use MAPI, IMAP4, POP3, HTTP, SMTP, and NNTP.

Clients often are able to support multiple protocols. For instance, client applications, such as Outlook 2003, can use MAPI, IMAP4, POP3, and SMTP. However, Microsoft Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync clients use HTTP.

Note   
Depending on the clients that you choose to support, you use Exchange System Manager or the IIS Microsoft Management Console (MMC) snap-in to manage the protocols used by the client applications.

 

If your users use any of the client applications that are included with Exchange—Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync—there are specific requirements related to each of these clients:

·         Outlook Web Access requires a supported Web browser on the users' computers. For complete details about which Web browsers are supported for Exchange, see Chapter 2, "Client Connection Features," in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).

·         Outlook Mobile Access requires a compatible mobile device such as a cHTML (Compact HTML) device.

·         Exchange ActiveSync requires a Microsoft Windows Mobile™–based device.

 

After you select your clients and configure Exchange for client access, Exchange provides a high level of flexibility for how you administer access to your messaging infrastructure. Later in this chapter are sections that describe the client applications that Microsoft supports for client access, and how to manage these applications. Read these sections to learn how to administer the clients that you use with Exchange.

Managing Protocols

In your Exchange messaging deployment configuration, you use Exchange System Manager to manage the protocols that you have decided to support. When you use Exchange System Manager to manage protocols, you manipulate settings on the individual virtual servers for the protocol that is to be configured. The virtual servers that are associated with the various protocols, such as the Exchange Virtual Server and the IMAP4 virtual server, contain settings based on the capabilities and use of the specific protocol. For example, the Exchange Virtual Server, which manages HTTP access to Exchange, provides settings for Outlook Web Access, such as gzip compression support.

For the most part, managing the virtual server for one protocol is identical to managing a virtual server for a different protocol. The common management tasks include enabling a virtual server, assigning ports, setting connection limits, starting or stopping a virtual server, and terminating connected users. However, there are some server-specific management tasks. The following sections describe both the common tasks for all virtual servers associated with protocols and the server-specific tasks for the Exchange Virtual Server, IMAP4 virtual server, and the NNTP virtual server.

Note   
To manage individual Exchange client access settings, use Active Directory Users and Computers.

 

Enabling a Virtual Server

When you install Exchange, the services that are necessary to support clients such as Outlook 2003, Outlook Web Access, and Exchange ActiveSync are enabled by default. For example, Exchange enables the SMTP service because it is the underlying protocol used to route messages both internally within an Exchange organization and externally to messaging systems outside of an Exchange organization. Similarly, Exchange enables HTTP because it is the underlying protocol for all Internet communication.

Note   
Although Outlook Mobile Access uses the HTTP protocol, Outlook Mobile Access is disabled by default and must be enabled using Exchange System Manager.

 

However, Exchange installs, but does not enable services for POP3, IMAP4, and NNTP. If your client access model relies on communications that use POP3, IMAP4, or NTTP, then you must manually enable them.

To enable either the POP3 or IMAP4 service, you use the Services snap-in to set the service to automatically start. Then, you start the service using Exchange System Manager. To enable NNTP, you first use the Services snap-in to set the Network News Transfer Protocol service to start automatically, and then use Exchange System Manager to start the service.

To enable a POP3 or IMAP4 virtual server to start automatically

1.        In the Services snap-in, in the console tree, click Services (Local).

2.        In the details pane, right-click Microsoft Exchange POP3 or Microsoft Exchange IMAP4, and then click Properties.

3.        On the General tab, under Startup type, select Automatic, and then click Apply.

4.        Under Service status, click Start, and then click OK.

5.        Repeat this procedure on all nodes that will be running the POP3 or IMAP4 virtual server.

 


To enable an NNTP virtual server

1.        In the Services snap-in, in the console tree, click Services (Local).

2.        In the details pane, right-click Network News Transfer Protocol (NNTP), and then click Properties.

3.        On the General tab in Startup type, select Automatic. Click OK.

 

To start a POP3, IMAP4, or NTTP virtual server

·         In Exchange System Manager, expand Protocols, expand the appropriate protocol (POP3, IMAP4, or NNTP), right-click the appropriate default virtual server (Default POP3 Virtual Server, , and Default NTTP Virtual Server) and then click Start.

 

Assigning Ports and an IP Address to a Virtual Server

When you create a virtual server for a protocol, you have the option of using the default port assignments and Internet Protocol (IP) address for the server. Table 6.1 shows the default port assignments associated with the various protocols. The default IP address is (All Unassigned), which means that a specific IP address has not been assigned and the virtual server will use the IP address of the Exchange server that is currently hosting the virtual server. These default values provide a virtual server with automatic discovery—the server is able to immediately receive incoming connections using the default IP address and ports.

Table 6.1   Default port assignments

Protocols

TCP port

Secure Sockets Layer (SSL) port

SMTP

25

Not available

IMAP4

143

993

POP3

110

995

NNTP

119

563

 

Important   
If you do not use the recommended port assignments, some clients may be unable to connect. You may also have to reconfigure your client software manually to connect to the new port assignments.

Note   
To fully enable SSL on the POP3 virtual server, you need to request and install a certificate. You need to do this even if you leave the default SSL port set at 995 on the POP3 virtual server. For more information about installing certificates, see "Securing Communications" in Chapter 7, "Configuring Exchange Server 2003 for Client Access" in the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

 

Although it is highly recommended that you use the default port assignments, you do not have to use the default IP address. You can use the IP address from any available network card as the IP address for the virtual server.

If you plan to create multiple virtual servers, each virtual server must have a unique combination of ports and IP address. Because the port settings are standard and should not be changed, you will need to provide each virtual server with its own unique IP address.

Besides creating a unique combination of ports and IP address for each virtual server, you can also configure multiple identities for your virtual server. Multiple identities enable you to associate multiple host or domain names with a single virtual server.

Use the following procedure to either assign a unique IP address to a virtual server or to assign multiple identities to a virtual server.

To assign an IP address or an identity to a virtual server

1.        On your Exchange server on which the virtual server is running, log on with the Exchange administrator account that has local administrative rights and Exchange full administrator permissions.

2.        In Exchange System Manager, expand Protocols, right-click the protocol that is to be assigned a new IP address or to which you want to add a new identity, and then click Properties.

3.        On the General tab, click Advanced.

4.        In the Advanced dialog box, click Edit to change the IP address to a unique value, or click Add to add a new identity (that is, a new IP address and port combination).

 

Setting Connection Limits

A virtual server can accept an unlimited number of inbound connections and is limited only by the resources of the computer on which the virtual server is running. To prevent a computer from becoming overloaded, you can limit the number of connections that can be made to the virtual server at one time. By default, Exchange does not limit the number of incoming connections.

After users are connected, you can also limit the length of time that idle connections remain logged on to the server. By default, Exchange disconnects idle sessions after 10 minutes.

In topologies that contain Exchange front-end and back-end servers, the connection time-out setting varies based on server role. On back-end servers, the connection time-out setting limits the length of time clients can be connected to the server without performing any activity. However, on front-end servers, the connection time-out setting limits the total length of the client session, regardless of client activity. Therefore, in front-end and back-end server environments, you should configure the time-out value on your front-end servers high enough so that users can download the maximum message size that is permitted over the slowest connection speed that you want to support. Setting this value high enough ensures that clients are not disconnected while they are downloading messages. For details about configuring your Exchange front-end and back-end server architecture, see the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

Warning   
Setting the connection time-out setting too low can cause clients to be unexpectedly disconnected from the server and possibly receive error messages. Thirty minutes is the lowest recommended connection time-out setting.

 

To set connection limits

1.        On your Exchange server that is running the virtual server, log on with the Exchange administrator account that has local administrative rights and Exchange full administrator permissions.

2.        In Exchange System Manager, expand Protocols, right-click the protocol for which you want to change connection limits, and then click Properties.

3.        On the General tab, set the appropriate connection limits.

 

Starting, Stopping, or Pausing a Virtual Server

Managing virtual servers often requires you to start, stop, or pause Exchange services. You manage Exchange services through the Computer Management console and Exchange System Manager.

To start, stop, or pause a virtual server

·         In Exchange System Manager, right-click the virtual directory that you want to manage, and do one of the following:

·         To start the service, click Start.

·         To either change the server status to paused, or to restart a server that has previously been paused, click Pause.

Note   
When a server is paused, an icon indicating that the server is paused appears next to the server name in the console tree.

 

·         To change the server status to stopped, click Stop.

Note   
When a server is stopped, an icon indicating that the server is stopped appears next to the server name in the console tree.

 


Terminating Connected Users

You can immediately disconnect a single user or all users if they are accessing the virtual server without permission.

To terminate connected users

1.        In Exchange System Manager, expand SMTP, IMAP4, or POP3, and then double-click the virtual server on which you want to terminate connected users.

2.        To terminate users from the Current Sessions node under the virtual server, do one of the following:

·         To disconnect a single user, click Terminate.

·         To disconnect all users, click Terminate all.

 

Managing Calendaring Options for the POP3 and IMAP4 Virtual Servers

You can configure a URL for access to calendaring information for your POP3 and IMAP4 messaging clients. This functionality allows you to use a POP3 or IMAP4 messaging client and Outlook Web Access to manage your calendar. The options that you select for this feature control the format of the URL.

Note   
In topologies that contain Exchange front-end and back-end servers, you configure the URL that is used to access calendaring information on the back-end server. Exchange does not recognize any URL settings that you configure on the front-end servers.

 

When downloading meeting requests through POP3 and IMAP4, a URL to the meeting request in Outlook Web Access is added to the plain text/HTML portion of the message. Users click the URL to access the meeting request, and then accept or decline the request. (Some IMAP4 and POP3 messaging clients include a graphical user interface that allows those clients to accept or decline meetings without having to click the URL.) If users accept the request, Exchange automatically adds it to their calendar.

Note   
The URL to the meeting request does not work for POP3 clients that are configured to download messages from the server. This situation occurs because the message is downloaded to the client. As a result, the URL points to a message that is no longer on the server.

 

To configure the calendaring options for a POP3 or IMAP4 virtual server

1.        In Exchange System Manager, expand the First Administrative Group, expand the Servers node, and then expand the Exchange server for which you want to manage POP3 or IMAP4 calendaring options.

2.        Expand the Protocols node, and then right-click the POP3 or IMAP4 protocol and select Properties.

3.        On the Calendaring tab, select the server from which recipients download meeting requests:

·         To designate the recipient's home server as the server from which the recipient download meeting requests, select Use recipient's server.

This is the default setting. If you select this option, the URL has the following format:

http://<HomeServerName>/Exchange/Username/Inbox/Team%20Meeting.eml

 

·         To designate a front-end server as the server from which recipients download meeting requests, select Use front-end server.

This option is useful if you have configured your Outlook Web Access users to access their mailboxes through a front-end server. If you select this option, the URL has the following format:

http://<FQDomainName>/Exchange/Username/Inbox/Team%20Meeting.eml

 

4.        To use SSL to connect to the Exchange servers, select Use SSL connections.

Note   
If you select this option, the URL syntax includes https:// instead of http://.

 

5.        Click OK to save your settings.

 

Managing the HTTP Virtual Server

Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync rely on the HTTP protocol to access Exchange information. These clients also use the WebDAV protocol, a set of rules that enable computers to exchange information, to execute instructions through the Exchange front-end server, as well as retrieve and manipulate information in the Exchange store. By supporting both HTTP and WebDAV, Exchange 2003 is able to provide more data access functionality to users. For example, users of Outlook Web Access are able to perform calendar request operations and can store Microsoft Office files, such as Word Documents, in the Exchange store.

Exchange provides support for both HTTP and WebDAV through the HTTP virtual server. When you install Exchange, Exchange automatically installs and configures an HTTP virtual server. You administer this default server only from IIS.

However, to provide for a number of different collaboration scenarios and to supplement the access to folders that is provided by the default Web site in IIS, you can create new HTTP virtual servers in Exchange System Manager. As with any virtual server, each new HTTP virtual server that you create requires a unique combination of IP address, TCP port, SSL port, and host name. Furthermore, for each virtual server that you create, you must define one virtual directory as the root directory of the server for publishing content.

Note   
The folder contents displayed by the HTTP virtual server are converted to Web pages and sent to a user's browser by IIS.

 

To create a new HTTP virtual server

1.        In Exchange System Manager, expand the First Administrative Group, expand the Servers node, and then expand the Exchange server on which you want to create a new HTTP virtual directory.

2.        Expand the Protocols node, and then right-click the HTTP protocol and select New HTTP Virtual Server.

3.        In the Properties dialog box for the new HTTP virtual server, configure the settings for your new Exchange virtual directory.

 

Managing the Exchange Virtual Server

The Exchange Virtual Server contains the virtual directories that provide access to Exchange for the various HTTP clients that Exchange supports, such as Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync. Although you enable settings for Outlook Web Access, including forms-based authentication and gzip compression, using the Exchange Virtual Server, you manage most settings for the Exchange virtual directories in the IIS snap-in.

Specifically, in Exchange 2003, if you need to configure authentication settings to your Exchange virtual directories, use the IIS snap-in. If you need to configure access control for the \Exchange, \Public, and \Exadmin virtual directories, use Exchange System Manager instead.


Working with IMAP4-Specific Settings

The IMAP4 virtual server has two protocol-specific settings:

·         Include all public folders when a folder is requested   Unlike POP3, which allows clients to access only mail messages, IMAP4 clients have access to folders other than the Inbox folder. However, this ability to access other folders needs to be enabled on the virtual server.

·         Enable fast message retrieval   Fast message retrieval improves performance by approximating message size, as opposed to actually calculating the message size. Performance improves because less processor work is needed.

 

You select these settings on the General tab for the Default IMAP4 Virtual Server Properties dialog box (see Figure 6.2).

Figure 6.2   General tab in the Default IMAP Virtual Server Properties dialog box

 


Configuring NNTP Posting Limits and Moderation Settings

Exchange Server 2003 uses NNTP to enable users to participate in newsgroup discussions. Exchange also enables users who are running client applications that support NNTP to access newsgroup public folders on computers running Exchange. Users can read and post items, such as messages and documents, to NNTP newsgroups that are represented in Exchange as public folders. For example, users can share information by posting messages to a newsgroup public folder in their area of interest. Other users can read and respond to items in the newsgroup. Items in newsgroups can be replicated to Usenet host computers through newsfeeds.

A newsfeed is the flow of items from one Usenet site to another. Newsfeeds enable users of different news sites to read and post articles to newsgroups as though they are using one news site. A news site is a collection of related newsgroups. An article posted to one news site is sent to other news sites where it can be read. You need to create a newsfeed to each remote server to which you want to distribute news articles.

Because the reason for using newsgroups is to post and share information, you will likely need to manage the size of these postings in relation to the resources available on the NNTP virtual server. Accepting articles that are too large or accepting too much data during one connection can cause increased traffic, overload your network, and quickly fill your hard disk. Be sure to set a size limit that matches your server's capabilities.

To configure posting limits and moderation settings for an NNTP virtual server

1.        On your Exchange server that is running the virtual server, log on with the Exchange administrator account that has local administrative rights and Exchange full administrator permissions.

2.        In Exchange System Manager, expand Protocols, right-click the protocol for which you want to change connection limits, and then click Properties.


3.        On the Settings tab (see Figure 6.3), select from the following options:

·         To allow clients to post articles to newsgroups on this NNTP virtual server, select Allow client posting. This option permits users to post and read articles in newsgroups that they can access, unless the newsgroup is set to read-only. You can also limit the size of the article that clients post as well as the size of the connection.

·         To allow clients to post articles to newsfeeds on the NNTP virtual server, select Allow feed posting. You can limit the size of articles that are posted by using the Limit post size check box. You can limit the amount of data that is sent to a newsfeed during a single connection by using the Limit connection size check box.

Figure 6.3   Settings tab of the Default NNTP Virtual Server Properties dialog box

 

Note   
For more information about configuring NTTP, see the Exchange Server 2003 Help.

 


Managing Outlook 2003

Exchange Server 2003 and Outlook 2003 build on previous versions of Exchange and Outlook and include several improvements for client messaging:

·         Exchange and Outlook now require less information to be passed from the client to the server, resulting in increased performance and a better end-user experience on slow networks.

·         Exchange and Outlook now support the use of the Windows RPC over HTTP feature, allowing Outlook 2003 clients to connect directly to the internal network using HTTPS or HTTP. For more information about configuring RPC over HTTP, see "Configuring Exchange Server 2003 for Client Access," in the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

·         Exchange and Outlook now include the Cached Exchange Mode feature, allowing for true offline access using Outlook.

Note   
For more information about the other new features in Outlook 2003, see Chapter 2, "Client Features," in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library/).

 

Of all the new features in Outlook 2003, Cached Exchange Mode is one of great interest to many organizations, and it is discussed in detail in this section.

Configuring Cached Exchange Mode

Cached Exchange Mode makes it possible for users to use a local copy of their mailbox on their computer to allow for a true offline experience with Outlook 2003. This means that, if network connectivity is lost between the Outlook 2003 client and Exchange 2003, users are able to continue working with the cached information and do not see a pop-up message stating that Outlook is requesting information from the Exchange server.

By default, new installations of Outlook 2003 use Cached Exchange Mode. If you are upgrading from previous versions of Outlook to Outlook 2003 and you want your users to be able to use Cached Exchange Mode, you must manually configure the Outlook client to use Cached Exchange Mode. To do this, you modify a user's profile to use the local copy of the user's Exchange mailbox.


To manually enable Cached Exchange Mode for Outlook 2003 upgrades

1.        In Control Panel on the computer running Outlook 2003, perform one of the following tasks:

·         If you are using Category View, in the left pane, under See Also, click Other Control Panel Options, and then click Mail.

·         If you are using Classic View, double-click Mail.

 

2.        In Mail Setup, click E-mail Accounts.

3.        In the E-mail Accounts Wizard, click View or change existing e-mail accounts, and then click Next.

4.        On the E-mail Accounts page, highlight the account that you want to modify, and then click Change.

5.        On the Exchange Server Settings page, select the Use Cached Exchange Mode check box.

6.        Click Next, and then click Finish to save the changes to your local profile.

 

Managing Outlook Web Access

Outlook Web Access for Exchange Server 2003 includes significant improvements related to both the user interface and administration. For information about the user experience improvements in Outlook Web Access, see Chapter 2, "Client Features," in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library/).

When it comes to managing Outlook Web Access, you use both Exchange System Manager and the IIS snap-in. Use:

·         Exchange System Manager to modify settings for access control to Outlook Web Access.

·         The IIS snap-in to control the Authentication settings for the virtual directories for Outlook Web Access, including \Exchange, \Exchweb, and \Public.

·         The IIS snap-in to enable SSL for Outlook Web Access. For information about using SSL with Outlook Web Access, see "Configuring Exchange Server 2003 for Client Access" in the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

 

The following sections show how to use Exchange System Manager and the IIS snap-in to perform a variety of management tasks associated with Outlook Web Access.


Enabling and Disabling Outlook Web Access for Internal Clients Only

You can enable users within your corporate network to access Outlook Web Access, while at the same time denying access to external clients. The key to this approach is a combination of a recipient policy and a special HTTP virtual server. The steps for this approach are as follows:

1.        Create a recipient policy with an SMTP domain name. Users who are connecting to an HTTP virtual server must have an e-mail address with the same SMTP domain as the virtual server. Creation of a recipient policy is an efficient way to apply the same SMTP domain to multiple users.

Note   
Outlook Web Access users do not need to know the name of the SMTP domain.

 

2.        Apply the recipient policy to the user accounts for which you want to enable access.

3.        Then, on the front-end server, create a new HTTP virtual server that specifies the domain that is used in the recipient policy.

 

After you have completed these steps, users whose e-mail addresses do not have the same SMTP domain as the HTTP virtual server will not be able to log on and access Outlook Web Access. Also, as long as you do not use the SMTP domain as the default domain, external users cannot determine what the SMTP domain is because the domain does not appear in the From field when users send e-mail messages outside the organization.

Note   
For more information about users with mailboxes that have an SMTP address that is not related to the address specified in the default recipient policy, see Microsoft Knowledge Base Article 257891, "XWEB: 'The Page Could Not Be Found' Error Message When You Use OWA" (http://support.microsoft.com/?kbid=257891).

 

Besides enabling Outlook Web Access for users within your corporate network, you can also prevent specific internal users from accessing Outlook Web Access. You do this by disabling the HTTP and NNTP protocols for those users.

To prevent an internal user from accessing Outlook Web Access

1.        In Active Directory Users and Computers, open the user's Properties dialog box.

2.        On the Exchange Features tab, clear the settings for HTTP and NNTP.

 


Using Browser Language

When using Microsoft Internet Explorer 5 or later to access Outlook Web Access, new installations of and upgrades to Exchange 2003 use the browser's language settings to determine the character set to use to encode information, such as e-mail messages and meeting requests.

If you upgrade a server running Exchange 2000 Server that was modified to use a browser's language setting, Exchange 2003 continues to function in the same manner. Table 6.2 lists the language groups and respective character sets.

Table 6.2   Outlook Web Access language group and character sets

Language group

Character set

Arabic

Windows 1256

Baltic

iso-8859-4

Chinese (Simplified)

Gb2131

Chinese (Traditional)

Big5

Cyrillic

koi8-r

Eastern European

iso-8859-2

Greek

iso-8859-7

Hebrew

windows-1255

Japanese

iso-2022-jp

Korean  

ks_c_5601-1987

Thai

windows-874

Turkish

iso-8859-9

Vietnamese

windows-1258

Western European

iso-8859-1

 


If you expect Outlook Web Access users in your organization to send mail frequently, you can modify registry settings so that users who are running Internet Explorer 5 or later can use UTF-8 encoded Unicode characters to send mail.

Warning   
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

 

To modify the default language setting for Outlook Web Access

1.        On the Exchange server, log on with the Exchange administrator account, and start Registry Editor (regedit).

2.        In Registry Editor, locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
MSExchangeWEB\OWA\UseRegionalCharset

3.        Create a DWORD value called UseRegionalCharset.

4.        Right-click the UseRegionalCharset DWORD value, and then click Modify.

5.        In Edit DWORD Value, in the Value data box, type 1, and then click OK.

6.        Close Registry Editor to save your changes.

 

Setting Up a Logon Page

You can enable a new logon page for Outlook Web Access that stores the user's name and password in a cookie instead of in the browser. When a user closes a browser, the cookie is cleared. Additionally, after a period of inactivity, the cookie is cleared automatically. The new logon page requires the user to enter a domain, user name, and password, or a full user principal name (UPN) e-mail address and password, to access e-mail.

To enable this logon page, you must first enable forms-based authentication on the server, and then secure the logon page by setting the cookie time-out period and adjusting client-side security settings.


Enabling Forms-based Authentication

To enable the Outlook Web Access logon page, you must enable forms-based authentication on the server.

To enable forms-based authentication

1.        On the Exchange server, log on with the Exchange administrator account, and then start Exchange System Manager.

2.        In the console tree, expand Servers.

3.        Expand the server for which you want to enable forms-based authentication, and then expand Protocols.

4.        Expand HTTP, right-click Exchange Virtual Server, and then click Properties.

5.        In the Exchange Virtual Server Properties dialog box, on the Settings tab, in the Outlook Web Access pane, select the Enable Forms Based Authentication option.

6.        Click Apply, and then click OK.

 

Setting the Cookie Authentication Time-out

In Exchange 2003, Outlook Web Access user credentials are stored in a cookie. When the user logs off from Outlook Web Access, the cookie is cleared and it is no longer valid for authentication. Additionally, by default, if your user is using a public computer, and selects the Public or shared computer option on the Outlook Web Access logon screen, the cookie on this computer expires automatically after 15 minutes of user inactivity.

The automatic time-out is valuable because it helps to protect a user's account from unauthorized access. However, although the automatic time-out greatly reduces the risk of unauthorized access, it does not completely eliminate the possibility that an unauthorized user could access an Outlook Web Access account if a session is left running on a public computer. Therefore, it is important that you educate users about precautions to take to avoid risks.

To match the security needs of your organization, an administrator can configure the inactivity time-out values on the Exchange front-end server. To configure the time-out value, you must modify the registry settings on the server.

Warning   
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

 

To set the Outlook Web Access forms-based authentication public computer cookie time-out value

1.        On the Exchange front-end server, log on with the Exchange administrator account, and then start Registry Editor (regedit).

2.        In Registry Editor, locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
MSExchangeWeb\OWA

3.        From the Edit menu, point to New, and then click DWORD Value.

4.        In the details pane, name the new value PublicClientTimeout.

5.        Right-click the PublicClientTimeout DWORD value, and then click Modify.

6.        In Edit DWORD Value, under Base, click Decimal.

7.        In the Value Data box, type a value (in minutes) between 1 and 432000.

8.        Click OK.

 

To set the Outlook Web Access forms-based authentication trusted computer cookie time-out value

1.        On the Exchange front-end server, log on with the Exchange administrator account, and then start Registry Editor (regedit).

2.        In Registry Editor, locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
MSExchangeWeb\OWA

3.        From the Edit menu, point to New, and then click DWORD Value.

4.        In the details pane, name the new value TrustedClientTimeout.

5.        Right-click the TrustedClientTimeout DWORD value, and then click Modify.

6.        In Edit DWORD Value, under Base, click Decimal.

7.        In the Value Data box, type a value (in minutes) between 1 and 432000.

8.        Click OK.

 


Adjusting Client Security Options for Users

For your Outlook Web Access logon page, you can allow two types of security options for authentication. Depending on their needs, users can select either of these security options on the Outlook Web Access logon page:

·         Public or shared computer    Inform your users to select this option when they access Outlook Web Access from a computer that does not conform to the security setting for your organization (for example, an Internet kiosk computer). This is the default option and provides a short default time-out option of 15 minutes.

·         Private computer   Inform your users to select this option when they are the sole operator of the computer, and the computer adheres to the security settings for your organization. When selected, this option allows for a much longer period of inactivity before automatically ending the session—its internal default value is 24 hours. This option is intended to benefit Outlook Web Access users who are using personal computers in their office or home.

 

Enabling Outlook Web Access Compression

Outlook Web Access supports data compression, which is optimal for slow network connections. Depending on the compression setting that you use, Outlook Web Access compression works by compressing static or dynamic Web pages.

Table 6.3 lists the available compression settings in Exchange Server 2003 for Outlook Web Access.

Table 6.3   Available compression settings for Outlook Web Access

Compression setting

Description

High

Compresses both static and dynamic pages.

Low

Compresses only static pages.

None

No compression is used.

 

Using data compression, users can experience performance increases of up to 50 percent when they are using slower network connections, such as traditional dial-up access.


To use data compression for Outlook Web Access in Exchange 2003, the following prerequisites must be fulfilled:

·         The Exchange server that users authenticate against for Outlook Web Access is running Windows Server 2003.

·         Your users' mailboxes are on Exchange 2003 servers. (If you have a mixed deployment of Exchange mailboxes, you can create a separate virtual server on your Exchange server just for Exchange 2003 users and enable compression on it.)

·         Client computers are running Internet Explorer version 6.0 or later. The computers must also be running Windows XP or Windows 2000, with the security update discussed in Microsoft Knowledge Base Article 328970, "Cumulative Patch for Internet Explorer" (http://support.microsoft.com/?kbid=328970), installed.

Note   
If a user does not have a supported browser for compression, the client will still perform normally.

 

In addition to the previous prerequisites, you may also need to enable HTTP 1.1 support through proxy servers for some dial-up connections. (HTTP 1.1 support is required for compression to function properly.)

To enable data compression

1.        On the Exchange server, log on with the Exchange administrator account, and then start Exchange System Manager.

2.        In the details pane, expand Servers, expand the server on which you want to enable data compression, and then expand Protocols.

3.        Expand HTTP, right-click Exchange Virtual Server, and then click Properties.

4.        In Exchange Virtual Server Properties, on the Settings tab, under Outlook Web Access, use the Compression list to select the compression level that you want (None, Low, or High).

5.        Click Apply, and then click OK.

 

Blocking Web Beacons

In Exchange 2003, Outlook Web Access makes it more difficult for people who send junk e-mail messages to use beacons to retrieve e-mail addresses. Beacons often come in the form of images that are downloaded onto a user's computer when the user opens a junk e-mail item. After the images download, a beacon notification is sent to the sender of the junk e-mail informing the sender that the e-mail address of your user is valid. The end result is that the user will receive junk e-mail more frequently because the junk e-mail sender now knows that the e-mail address is valid.

In Outlook Web Access, an incoming message with any content that could be used as a beacon, regardless of whether the message actually contains a beacon, prompts Outlook Web Access to display the following warning message:

To help protect your privacy, links to images, sounds, or other external content in this message have been blocked. Click here to unblock content.

 

If users know that a message is legitimate, they can click the Click here to unblock content link in the warning message and unblock the content. If your users do not recognize the sender or the message, they can open the message without unblocking the content and then delete the message without triggering beacons. If your organization does not want to use this feature, you can disable the blocking option for Outlook Web Access.

To disable the blocking option

·         On the user's Outlook Web Access Options page, under Privacy and Junk E-mail Prevention, clear the Block external content in HTML e-mail messages check box.

 

Blocking Attachments

With Outlook Web Access, you can block users from opening, sending, or receiving specified attachment types. In particular, you can:

·         Prevent users from accessing certain file type attachments   By default, all new Exchange 2003 installations block attachments of Levels 1 and 2 file types, and Levels 1 and 2 MIME types. This feature is particularly useful in stopping Outlook Web Access users from opening attachments at public Internet terminals, which could potentially compromise corporate security. If an attachment is blocked, a warning message indicating that the user cannot open the attachment appears in the InfoBar of the e-mail message.

Outlook Web Access users who are working in their offices or connected to the corporate network from home can open and read attachments. You can enable full intranet access to attachments by providing the URL to the back-end servers and allowing attachments on the Exchange back-end servers.

·         Prevent users from sending or receiving attachments with specific file extensions that could contain viruses   This feature in Outlook Web Access matches the attachment blocking functionality in Outlook. For received messages, a warning message indicating that an attachment is blocked appears in the InfoBar of the e-mail message. For sent messages, users cannot upload any files with extensions that appear on the block list.

 

To change the attachment blocking settings, you must modify the registry settings on the server.

Warning   
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

 

To modify the attachment blocking settings on an Exchange server

1.        On the Exchange server, log on with the Exchange administrator account, and then start Registry Editor (regedit).

2.        In Registry Editor, locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
MSExchangeWeb\OWA

3.        From the Edit menu, point to New, and then click DWORD Value.

4.        In the details pane, name the new value DisableAttachments.

5.        Right-click DisableAttachments, and then click Modify.

6.        In Edit DWORD Value, under Base, click Decimal.

7.        In the Value data box, type one of the following numbers:

·         To allow all attachments, type 0.

·         To disallow all attachments, type 1.

·         To allow attachments from back-end servers only, type 2.

8.        Click OK.

 

Filtering Junk E-Mail Messages

You can control how Exchange 2003 manages junk e-mail for your organization. To do this, you need to enable filtering, and then configure sender, recipient, and connection filtering. For more information about controlling junk e-mail with Exchange 2003, see "Enabling Filtering to Control Junk E-mail Messages" in Chapter 5, "Understanding and Configuring Message Routing and Transport."


Simplifying the Outlook Web Access URL

The HTTP virtual server that is created by Exchange during installation has the following URLs for user access:

·         http://server_name/public   This URL provides access to public folders.

·         http://server_name/exchange/mailbox_name   This URL provides access to mailboxes.

 

However, users often request that a URL that is simpler than the default URL be made available for accessing their mailboxes. Creating this simple URL makes the URL both easier to remember and easier to enter into a Web browser. For example, http://www.contoso1.com is an easier URL for users to remember than http://contosoexchange01/exchange.

The following procedure provides a method for simplifying the URL that is used to access Outlook Web Access. This procedure configures a request sent to the root directory of the Web server (http://server_name/) to redirect to the Exchange virtual directory. For example, a request to http://server_name/ is directed to http://server_name/exchange/, which then triggers implicit logon.

To simplify the Outlook Web Access URL

1.        Using Internet Services Manager, open the properties for the Default Web Site.

2.        Click the Home Directory tab, and then select A redirection to a URL.

3.        In Redirect to, type /directory name, and then click A directory below URL entered.

For example, if you want to redirect http://mail/ requests to http://mail/exchange, in Redirect to, you would type /exchange.

4.        To require users to use SSL, in Redirect to, type https://mail/directory name, and then click The exact URL above option.

This setting hard codes the name of the server. Therefore, if you redirect client requests to https://mail, the client must be able to resolve the name "mail."

 

For information about another method for redirecting clients to SSL, see Microsoft Knowledge Base Article 279681, "How to Force SSL Encryption for an Outlook Web Access 2000 Client" (http://support.microsoft.com/?kbid=279681).


Managing Exchange ActiveSync

Using Exchange ActiveSync, users with a Windows-powered mobile device with the desktop ActiveSync software can synchronize their devices with their Exchange servers over the Internet. Users connect across the Internet to their Exchange front-end server and request information from their Exchange mailbox server. When you enable access to Exchange using Exchange ActiveSync, you should perform the following steps.

1.        Use the front-end and back-end server architecture to provide a single namespace for users to connect to your network (recommended). For more information, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library).

2.        Install an SSL certificate on the front-end server. For more information, see the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

3.        Inform users how to connect to the Internet from their device and use ActiveSync on their device to connect to their Exchange server. For more information, see the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

 

The following sections provide information about how to manage Exchange ActiveSync for your organization, including how to enable and disable the Exchange ActiveSync application, and how to enable ActiveSync for your users.

Enabling Exchange ActiveSync for Your Organization

By default, Exchange ActiveSync is enabled for all of the users in your organization. If your users have Windows-powered mobile devices, you can inform them how to configure their devices to use Exchange ActiveSync. For information about informing your users how to use Exchange ActiveSync, see "Configuring Exchange Server 2003 for Client Access" in the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

To enable and disable Exchange ActiveSync for your organization, you use Exchange System Manager. However, when you add new users to your organization and you want to enable them to use Exchange ActiveSync to access Exchange with a Windows-powered mobile device, you use Active Directory Users and Computers to modify the settings for a user or groups of users. The following procedures describe how to enable or disable the Exchange ActiveSync application for your organization, and how to modify Exchange ActiveSync settings to accommodate new users.


To enable or disable Exchange ActiveSync for your organization

1.        On the Exchange front-end server that is running Exchange ActiveSync, log on with the Exchange administrator account, and then start Exchange System Manager.

2.        Expand Global Settings, right-click Mobile Services, and then click Properties.

3.        On the Mobile Services Properties page, in the Exchange ActiveSync pane, select or clear the check box next to Enable user initiated synchronization.

4.        Click OK.

 

To modify Exchange ActiveSync settings

1.        On the Exchange server with the user's mailbox, log on with the Exchange administrator account, and then start Active Directory Users and Computers.

2.        Expand the domain, and then open the location for the users that you want to manage.

3.        Right-click the user or users whose Exchange ActiveSync settings you want to modify, and then select Exchange Tasks.

4.        In Exchange Task Wizard, on the Available Tasks page, select Configure Exchange Features, and then click Next.

5.        On the Configure Exchange Features page, select User initiated synchronization, and then select one of the following:

·         To permit users to use Exchange ActiveSync to synchronize their Exchange mailbox with their mobile devices, select Enable.

·         To prevent users from using Exchange ActiveSync, select Disable.

·         To prevent the users' settings from being modified when you have selected more than one user, select Do not modify.

6.        Click Next to apply your changes.

7.        Click Finish.

Note   
If you want to view a detailed report of the settings and the changes you made to users, select View detailed report when this wizard closes.

 


Enabling Up-to-Date Notifications for Your Organization

After you configure your organization to use Exchange ActiveSync, you can configure your Exchange 2003 servers so that users can receive up-to-date notifications to keep their devices up-to-date with the changes that occur when a new item arrives in their Exchange mailbox.

Up-to-date notifications are notifications that are sent to a user's device when a new item arrives in their Exchange mailbox. This notification prompts the user's device to synchronize the device with the Exchange mailbox automatically.

To enable up-to-date notifications for your organization

1.        On the Exchange front-end server running Exchange ActiveSync, log on with the Exchange administrator account, and then start Exchange System Manager.

2.        Expand Global Settings, right-click Mobile Services, and then click Properties.

3.        On the Mobile Services Properties page, in the Exchange ActiveSync pane, select Enable up-to-date notifications.

4.        Click OK.

 

To modify up-to-date notifications settings for your users

1.        On the Exchange server with the user's mailbox, log on with the Exchange administrator account, and then start Active Directory Users and Computers.

2.        Expand the domain, and then open the location for the users whose settings that you want to modify.

3.        Right-click the user or users whose up-to-date notifications settings you want to modify, and then select Exchange Tasks.

4.        In Exchange Task Wizard, on the Available Tasks page, select Configure Exchange Features, and then click Next.

5.        On the Configure Exchange Features page, select Up-to-date notifications, and then select one of the following:

·         To allow users to use up-to-date notifications, select Enable.

·         To prevent users from using up-to-date notifications, select Disable.

·         To prevent the users' settings from being modified when you have selected more than one user, select Do not modify.

 


Allowing Users to Use a Mobile Operator to Receive Notifications

If you enable the Exchange ActiveSync up-to-date notifications feature, your users use a mobile operator to deliver messages from the corporate network to their devices. There are two ways in which you can allow your users to receive notifications:

Option 1: Specify a mobile operator for your users

If you want to specify a mobile operator for your users, you disable the Enable notifications to user specified SMTP addresses on the Exchange server that has the mailboxes for these users. If you choose this option, you need to inform your users how to set their devices to use the mobile operator that you specify for up-to-date notifications.

Option 2: Allow users to use their own mobile operators

If your users have their own Windows-powered mobile devices, you can allow them to use their own mobile operators to deliver notifications to their devices. If you choose this option, you need to inform your users how to set their devices to use the mobile operators that they want to use for up-to-date notifications.

 

The following two procedures describe how to configure these options. The first procedure describes how to set the Enable notifications to user specified SMTP address option, and the second procedure describes how to set the mobile operator on a user's device.

To set the Enable notifications to user specified SMTP address option for your organization

1.        On the Exchange front-end server that is running Exchange ActiveSync, log on with the Exchange administrator account, and then start Exchange System Manager.

2.        Expand Global Settings, right-click Mobile Services, and then click Properties.

3.        On the Mobile Services Properties page, in the Exchange ActiveSync pane, set the Enable notifications to user specified SMTP address option as follows:

·         If you want to specify a mobile operator for your user, clear Enable notifications to user specified SMTP address.

·         If you want to allow your users to specify their own mobile operators, select Enable notifications to user specified SMTP address.

4.        Click OK.

 

To specify a mobile operator for up-to-date notifications on a device

1.        In ActiveSync, on a Windows-powered mobile device, tap Tools, and then tap Options.

2.        On the Server tab, tap Options.

3.        On the Server Synchronization Options screen, tap Device Address.

4.        On the Device Address screen, do one of the following:

·         If your users are using a mobile operator that you specify, select Corporate Service Provider, and then enter the Device Phone Number and Service Provider Name in the fields that are provided.

·         If your users are using their own mobile operators, select Device SMS Address, and then enter the device address in the field provided.

 

Managing Outlook Mobile Access

Using Outlook Mobile Access, users can browse their Exchange mailbox using a device such as a Microsoft Windows-powered Smartphone or a cHTML-capable device. You can also enable users to use devices that are not officially supported by Microsoft, but which are likely to function properly with only minor compatibility issues by enabling unsupported devices to use Outlook Mobile Access.

The following sections provide information about how to manage Outlook Mobile Access for your organization, including how to enable the Outlook Mobile Access application for your organization and how to enable users for Outlook Mobile Access.

Configuring Exchange to Use Outlook Mobile Access

By default, Outlook Mobile Access is disabled when you install Exchange Server 2003. For users to use Outlook Mobile Access, you must first enable it. When you enable access to Exchange using Outlook Mobile Access, you should do the following:

1.        Use the front-end and back-end server architecture to provide a single namespace for users to connect to your network. For more information, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library).

2.        Install an SSL certificate on the front-end server. For more information, see the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

3.        Inform users how to connect to the Internet from their devices, and how to use Outlook Mobile Access to access their Exchange information. For more information, see the book Exchange Server 2003 Deployment Guide (http://www.microsoft.com/exchange/library).

 

Enabling Outlook Mobile Access for Your Organization

To enable Outlook Mobile Access for your organization, you use Exchange System Manager. After you enable Outlook Mobile Access, you can use Active Directory Users and Computers to modify the Outlook Mobile Access settings for users or groups of users.

To enable Outlook Mobile Access for your organization

1.        Log on as an Exchange administrator to the Exchange server with the user's mailbox, and then start Exchange System Manager.

2.        Expand Global Settings, right-click Mobile Services, and then click Properties.

3.        On the Mobile Services Properties page, in the Outlook Mobile Access pane, select Enable Outlook Mobile Access.

4.        To enable users to use unsupported devices, select Enable unsupported devices.

Note   
For information about supported devices for Exchange and planning for mobile device support with Exchange, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library/).

 

5.        Click OK.

 

To modify Outlook Mobile Access settings

1.        Log on as an Exchange administrator to the Exchange server with the user's mailbox, and then start Active Directory Users and Computers.

2.        Expand the domain, and then open the location for the users whose settings that you want to modify.

3.        Right-click the user or users whose Outlook Mobile Access settings you want to modify, and then select Exchange Tasks.

4.        In Exchange Task Wizard, on the Available Tasks page, select Configure Exchange Features, and then click Next.


5.        On the Configure Exchange Features page, select Outlook Mobile Access, and then select one of the following:

·         To allow users to use Outlook Mobile Access, select Enable.

·         To prevent users from using Outlook Mobile Access, select Disable.

·         To prevent the users' settings from being modified when you have selected more than one user, select Do not Modify.

6.        Click Next to apply your changes.

7.        Click Finish.

 


Chapter 7

Managing Mailbox Stores and Public Folder Stores

The Microsoft® Exchange store is a storage platform that provides a single repository for managing multiple types of unstructured information in one infrastructure. Mailbox stores and public folder stores are two of the components that make up the Exchange store. The Exchange store is also known as the Web Storage System.

The first section of this chapter describes the permissions that protect the Exchange store, which in some ways function differently than permissions elsewhere in Exchange.

The next three sections of this chapter describe how to work with the different elements of the Exchange store:

·         Storage groups, mailbox stores, and public folder stores   These components control how information on a specific server is stored and maintained.

·         Storage-related aspects of mailboxes   Mailbox information resides both in mailbox stores and in user objects in the Active Directory® directory service. Most management tasks for mailboxes involve working in Active Directory.

·         Public folders   Public folders can reside on many servers simultaneously (or on none at all), so Exchange treats public folder management tasks as largely server-independent.

 

The following appendixes of this book provide information about store-related administrative tasks that are more detailed and complex than those included in this chapter:

·         Appendix D, "Identifying and Accessing Exchange Store Components"   This appendix describes the components of the Exchange store and identifies the different tools that you can use to manage them.

·         Appendix E, "Controlling Public Folder Replication"   This appendix includes procedures for configuring replication. To help you troubleshoot replication issues, this appendix also describes how replication works and what aspects of your Exchange topology impact the replication process.


·         Appendix F, "Using Full-Text Indexing"   This appendix describes how to set up full-text indexes, and how to optimize and maintain the indexes.

·         Appendix G, "Troubleshooting and Repairing Store Problems"   This appendix describes the common problems, events, and messages that are related to managing mailbox and public folder stores. It also includes information about what causes the problems, and possible solutions.

 

Note   
For detailed information about the internal workings of the stores, and for detailed backup and recovery procedures, see Disaster Recovery for Microsoft Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkID=18350). Although existing recovery functionality has not changed, Microsoft Exchange Server 2003 has new recovery features. For more information about the new features, see the book What's New in Exchange Server 2003 (www.microsoft.com/exchange/library).

 

Working with Permissions for Public Folders and Mailboxes

Managing administrative access to mailbox and public folder stores is similar to managing administrative access to the server itself. This section contains an overview of the permissions that you need to manage public folders and mailboxes. Before you begin management tasks on public folders and mailboxes, be sure to read the sections that pertain to the tasks that you plan to perform:

·         Using Exchange Administrative Roles with Exchange Store Components   This section explains what access the various Exchange administrative roles (Exchange Full Administrator, Exchange Administrator, and Exchange View Only Administrator) provide to mailbox stores, public folder stores, and public folder trees.


·         Understanding the Types of Permissions That Control Access to Mailboxes and Public Folders, Using Mailbox Permissions, and Using Public Folder Permissions   These sections explain how the permissions on store contents—mailboxes, public folders, and the messages they store—are much more complex than permissions used elsewhere in Exchange, and provide basic information about how to use these permissions.

 

Important   
A detailed explanation of how these permissions work is beyond the scope of this chapter. For a full explanation of how store permissions work, see the Exchange technical article, "Working with Store Permissions in Microsoft Exchange 2000 and 2003" (http://go.microsoft.com/fwlink/?LinkId=18612).

If you are doing any troubleshooting with store permissions, or if you need to modify permissions in ways other than the delegation methods described later in this chapter, it is strongly recommended that you study "W Working with Store Permissions in Microsoft Exchange 2000 and 2003" first.

 

·         Maintaining the Minimum Permissions Required for Mailbox Stores and Public Folder Stores   This section explains the minimum permissions that are required for mailbox stores and public folder stores to function correctly.

Using Exchange Administrative Roles with Exchange Store Components

To perform most of the tasks in this chapter, you must have at least Exchange Administrator permissions on the administrative group where you are working. For more information about the Exchange administrative roles and the Exchange Administration Delegation Wizard, see "Managing Permissions" in Chapter 2, "Managing an Exchange Organization."

Use the information in Table 7.1 and Figure 7.1 to identify what permissions are involved, and how the Exchange store objects inherit these permissions. This will help you to recognize situations where you may need a different administrative role or different permissions.

Table 7.1 summarizes the permissions for the three Exchange administrative roles on Exchange store objects.


Table 7.1   Permissions for the Exchange administrative roles on mailbox stores, public folder stores, and public folder trees

Role

Allowed

Denied

Exchange Full Administrator

Full Control

Additional permissions in Active Directory to allow you to work with deleted items and offline address lists

Receive-As

Send-As

Exchange Administrator

All except Change Permissions

Additional permissions in Active Directory to allow you to work with offline address lists

Receive-As

Send-As

Exchange View Only Administrator

Read

List object

List contents

View Information Store Status

None

 

Figure 7.1 summarizes how mailbox stores, public folder stores, and public folder trees inherit permissions.

Figure 7.1   Direction of inheritance of permissions for Exchange Full Administrators, Exchange Administrators, or Exchange View Only Administrators

 


As Figure 7.1 shows, objects in the Exchange store inherit permissions from their administrative group, with the following exceptions:

·         Delegating Exchange administrative roles on an administrative group gives administrators in those roles limited permissions on mailboxes—enough to create or delete mailboxes, and set options such as storage limits.

·         A public folder inherits some administrative permissions from the public folder tree where it resides. It does not inherit permissions from the public folder store.

·         Administrative rights on a public folder include many folder-specific permissions that are not available on the public folder tree. For example, although an Exchange Administrator cannot modify the permissions on a public folder tree, the administrator can modify permissions on a public folder in that tree.

 

Note   
For an administrator to apply a system policy to a store, the administrator must have the appropriate permissions on both the System Policies container and on the target store. If you are using a distributed administration model with multiple administrative groups that have separate administrators, each administrator will be able to interact only with the stores in that administrator's own administrative group.

Important   
Public folder trees and their public folders can only be administered in the administrative group where they were created, even though you can replicate folders in the tree to multiple administrative groups. If you are using a distributed administration model with multiple administrative groups that have separate administrators, each administrator can work with the public folder stores in that administrator's own administrative group, but may not have access to the public folders that those stores support.

 

Understanding the Types of Permissions That Control Access to Mailboxes and Public Folders

The access control lists (ACLs) on public folders, mailboxes, and the messages that they contain use Microsoft Windows® 2000 permissions to control access (with a few additional permissions that are specific to Exchange). This is a change from Microsoft Exchange 5.5, in which the ACLs used MAPI permissions. Exchange 2003 substitutes MAPI permissions for Windows 2000 permissions in the following circumstances:

·         When communicating with MAPI-based client applications, such as Microsoft Outlook®. In this case, Exchange converts the permissions to MAPI permissions when displaying them to the user. If the user modifies the permissions, Exchange converts them back to Windows 2000 permissions to save them.


·         When replicating data to Exchange 5.5 servers in a deployment that contains coexisting servers that run Exchange 5.5 and servers that run Exchange 2003. Because Exchange 5.5 servers only use MAPI permissions, Exchange 2003 replicates permissions to them in the MAPI format. When the permissions replicate back to Exchange 2003 servers, Exchange 2003 converts them to the Windows 2000 format before saving them.

 

Note   
Both of these circumstances apply to mailboxes and to public folders in the Public Folders tree (and all of the folders and messages contained in it). Folders and messages in general-purpose public folder trees cannot be accessed by MAPI-based clients and are not replicated to Exchange 5.5 servers. Therefore, Exchange always uses Windows 2000 permissions with these folders and messages. For more information about the differences between the Public Folders tree and general-purpose public folder trees, see "Configuring Public Folder Stores" later in this chapter.

 

Exchange handles all conversions between Windows 2000 permissions and MAPI permissions automatically. However, as an administrator, be aware that when you use Exchange System Manager to set permissions, you may need to work with either Windows 2000 permissions or MAPI permissions, depending on the type of object you are securing.

Using Mailbox Permissions

When you create a new mailbox, Exchange uses information from the mailbox store to create the default permissions for the new mailbox. The default folders in the new mailbox inherit permissions from the mailbox itself. Users can modify the permissions on folders in their mailbox using Outlook. Outlook uses MAPI permissions, which Exchange automatically converts to Windows 2000 permissions when it is storing the changes.

Although you can use Exchange System Manager to delete or move mailboxes, you cannot use it to access mailbox content or mailbox-related attributes of the user. Use Active Directory Users and Computers to perform administrative tasks on the Exchange-related attributes of user objects. In addition, you must use Active Directory Users and Computers to give users permission to access the mailbox itself, as discussed in the next section.

Designating a User as a Mailbox Delegate

For administration and troubleshooting purposes, there are times when you need to access a user's mailbox. There also may be occasions where it is appropriate for a second user to have access to a mailbox. This second user is referred to as a mailbox delegate.


You can give users delegate permissions for a mailbox by modifying the Active Directory user account that is associated with the mailbox. Use Active Directory Users and Computers for this task. You can give different levels of access to the mailbox:

·         If you give the second user the access level of Full Mailbox Access, Exchange treats that user as the mailbox owner. The second user does not need any other permissions on folders in the mailbox.

Important   
Always use care when modifying permissions. An unscrupulous user with Full Mailbox Access to other users' mailboxes could cause damage to the mailboxes or their contents.

 

·         If you give the second user an access level other than Full Mailbox Access, the original mailbox owner can use Outlook to set permissions for the second user on folders in the mailbox.

To give someone access to another user's mailbox, you must have the appropriate permissions to modify user objects in Active Directory (see the Windows Help for more information about these permissions).

To give a user full access to another user's mailbox

1.        In Active Directory Users and Computers, right-click the organization domain name, point to View, and then click Advanced Features.

2.        Click the Users container or the organizational unit where the user is located.

3.        Right-click the user account, and then click Properties.

4.        Click Exchange Advanced, and then click Mailbox Rights.

5.        Click Add to add a user to the list of users that are allowed to access this mailbox.

6.        In the permissions list, for the Full Mailbox Access permission, select the Allow check box.

 

To give a user the ability to send mail on behalf of another user

1.        In Active Directory Users and Computers, click the Users container or the organizational unit where the user is located.

2.        Right-click the user account, and then click Properties.

3.        Click Exchange General, and then click Delivery Options.

4.        Click Add to specify a user.

Important   
In this situation, the second user does not need permissions on the mailbox itself or items in the mailbox.

 

Using Public Folder Permissions

Controlling access to public folders is more complex than controlling access to mailboxes. This section presents information that will help you understand:

·         The different types of permissions that can be set on public folders.

·         What you need to consider when you work with client permissions. Be sure to read this section before modifying client permissions.

·         What you need to consider when setting public folder permissions in an environment where Exchange 2003 and Exchange 5.5 servers coexist.

·         How to designate a user as a public folder delegate.

·         The minimum permissions that are required for mail-enabled public folders to function correctly.

 

Understanding the Three Types of Public Folder Permissions

You can control access to public folders using the following types of permissions:

·         Client permissions   These settings control who can use client applications to access folders and messages. By default, all users have permissions to read and write content in the public folder. You can change permissions for all users or create different permissions for specific users. The default client permissions do not include the Exchange administrative roles (Exchange Full Administrators, Exchange Administrators, or Exchange View Only Administrators).

Depending on the type of public folder that you are working with, you may see different forms of the client permissions.

·         Folders in the Public Folders tree use MAPI permissions.

·         Folders in general-purpose public folder trees use Windows 2000 permissions.

 

·         Directory rights   These settings are normal Active Directory permissions, and control who can change the e-mail–related attributes of a mail-enabled public folder. Exchange stores these attributes in Active Directory, in the public folder's directory object in the Microsoft Exchange System Objects container. The default directory permissions include extensive permissions for the domain local Administrators group. Normally, any user that you have assigned to one of the Exchange administrative roles is a member of this group.

·         Administrative rights   These settings control who can use Exchange System Manager (or a custom administration program) to change the replication, limits, and other settings for a public folder. Some of these permissions are inherited from the public folder store and include permissions for the Exchange administrative roles. These permissions are Windows 2000 permissions, although they reside only in the public folder store.

 

If you are working with a public folder tree that has multiple levels of public folders, you can modify client permissions or administrative rights for a single folder, and you can use the Propagate Settings command to propagate the changes to all subfolders of that folder. To propagate client permissions, use Propagate Settings with the Folder rights option. To propagate administrative rights, use Propagate Settings with the Administrative rights option.

Special Considerations for Working with Client Permissions

When you use Exchange System Manager to view client permissions for a public folder, the information that you see can depend on what type of folder tree you are working with. You also have access to different views of the same information. The procedures in this section provide information about how to use and how not to use the different views.

Important   
Always use care when modifying permissions. An unscrupulous user with Owner permissions on a public folder could cause damage to the folder or its content, or could run malicious scripts.

 

To view permissions that control client access to a public folder

1.        In Exchange System Manager, right-click the folder that you want to change, and then click Properties.

2.        In the Properties dialog box, click the Permissions tab (see Figure 7.2), and then click Client permissions.

Figure 7.2   The first Permissions tab that is displayed for a mail-enabled public folder

 


After clicking Client Permissions, one of two different dialog boxes appears, depending on the type of public folder tree with which you are working:

·         If you are working with a folder in the Public Folders tree, you see a dialog box that contains MAPI permissions and roles (see Figure 7.3a).

·         If you are working with a folder in a general-purpose public folder tree, you see a dialog box that contains Windows 2000 permissions, users, and groups (see Figure 7.3b).

Figure 7.3a   Client Permissions dialog box for a public folder in the Public Folders tree

 

Figure 7.3b   Permissions dialog box for a public folder in a general-purpose public folder tree

 

You can also use Exchange System Manager to view the Windows 2000 version of the permissions on a folder in the Public Folders tree.

Warning   
Although you can view the Windows 2000 version of the Public Folders tree permissions, do not attempt to edit the permissions in this view. The Windows user interface that displays the permissions formats the ACL in such a way that Exchange will no longer be able to convert the permissions to their MAPI form. If this happens, you will no longer be able to use Outlook or the regular Exchange System Manager dialog boxes to edit the permissions.

 


To view the Windows 2000 version of MAPI permissions

1.        In Exchange System Manager, right-click the folder whose permissions you want to view, and then click Properties.

2.        In the Properties dialog box, click the Permissions tab, and then press and hold the CTRL key and click Client permissions.

The resulting dialog box is shown in Figure 7.4. Note that all of the permissions check boxes are cleared.

Figure 7.4   Windows 2000 Permissions dialog box for a folder in the Public Folders hierarchy

 


3.        To see the actual permissions information, click Advanced. The resulting dialog box is shown in Figure 7.5.

Figure 7.5   Advanced version of the Windows 2000 Permissions dialog box

 


4.        To view detailed permissions information, click a permissions entry and then click View/Edit.

Remember, do not use this dialog box to edit the permissions. As stated earlier, using this interface to modify permissions would save the changes in a form that Exchange could not convert to the MAPI format. Figure 7.6 shows an example of the detailed Windows 2000 permissions information you can view.

Figure 7.6   Detailed view of Windows 2000 permissions

 


Special Considerations for Coexisting Exchange 2003 and Exchange 5.5 Servers

If your deployment includes both Exchange 2003 and Exchange 5.5 servers, you have an additional level of complexity to deal with when managing permissions, especially public folder permissions. Although the information that follows is technical, you must be aware of these details to ensure that your mixed-mode deployment operates smoothly. For a more detailed explanation of how Exchange passes access control information between Exchange 2003 and Exchange 5.5 servers, see the Exchange technical article, Public Folder Permissions in a Mixed-Mode Microsoft Exchange Organization (http://go.microsoft.com/fwlink/?LinkId=10228).

The important points in the article that relate to managing public folder permissions are the following:

·         Before any data can be replicated between Exchange 2003 and Exchange 5.5 servers, any users or groups that have mailboxes on the Exchange 5.5 servers must have accounts in Active Directory.

·         If the user or group account has only an Active Directory account (not a Microsoft Windows NT® 4.0 account), the Active Directory account is an enabled account.

·         If the user or group has a Windows NT 4.0 account, the Active Directory account is a disabled account. This disabled account, created using the Active Directory Migration Tool, is a placeholder that associates an Active Directory security identifier (SID) with the existing Windows NT 4.0 account.

 

Important   
If you plan to maintain user accounts in Windows NT 4.0 for a period of time and then fully migrate those accounts to Active Directory, you need to create disabled accounts that have a SID history. The Active Directory Migration Tool can migrate the Windows NT 4.0 SID into the sidHistory attribute of the newly disabled account in Active Directory. If you enable the accounts at a later date, Exchange can use the SID history information to determine where newly enabled accounts have replaced Windows NT 4.0 accounts in access control entries (ACEs). For more information about this process, see Microsoft Knowledge Base Article 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts" (http://support.microsoft.com/?kbid=316047).

 

·         Exchange 5.5 uses MAPI-based permissions, identifies users and groups by their distinguished names in the Exchange Directory, and uses a property called ptagACLData to store access control information. Exchange 2003 uses two additional properties, ptagNTSD and ptagAdminNTSD, to store access control information.


When Exchange 2003 replicates access control information to an Exchange 5.5 server, it does the following:

a.        Converts the Active Directory security identifiers (SIDs) of users and groups to Exchange Directory distinguished names.

b.       Converts the Windows 2000 permissions to MAPI permissions.

c.        Stores the converted access control information in ptagACLData.

d.       Replicates ptagNTSD, ptagAdminNTSD, and ptagACLData to the Exchange 5.5 server.

 

When an Exchange 2003 server receives data replicated by an Exchange 5.5 server, it does the following:

a.        Discards the incoming values of ptagNTSD and ptagAdminNTSD. This step protects against any changes that may have been made to these properties while they were under the control of Exchange 5.5.

b.       Extracts the user and group distinguished names from ptagACLData and converts them to Active Directory SIDs.

c.        Extracts the permissions from ptagACLData and converts them to Windows 2000 permissions.

d.       Stores the converted access control information in ptagNTSD. (The original value of ptagAdminNTSD remains unaffected.)

e.        Discards the value of ptagACLData, unless a problem occurred during the conversion in Step b or Step c. If a conversion problem occurs, Exchange 2003 keeps the ptagACLData value.

 

·         Exchange 5.5 applies permissions to folders. You cannot assign permissions to individual messages (item-level permissions) explicitly, as you can with Exchange 2003. If you are replicating folders and their contents from Exchange 5.5 to Exchange 2003, do not attempt to set explicit permissions on messages. Exchange 2003 manages permissions so that the messages are secure, but if you attempt to change the message permissions in this situation, the changes will be lost in the next replication cycle.

Designating a User as a Public Folder Delegate

You can configure a mail-enabled public folder so that a user can send mail on the public folder's behalf. For example, if the folder serves as a shared storage location or workspace for a group of users, one user could send notifications to the group. A custom application could also perform such a function, if you created an account for it to use.

To give a user the ability to send mail on behalf of a public folder

1.        In Exchange System Manager, under Folders, right-click the public folder for which you want to give a user the ability to send mail and click Properties.

2.        Click Exchange General, and then click Delivery Options.

3.        Click Add to specify a user.

4.        You may need to make additional modifications if the following conditions apply:

·         The user's mailbox resides in a domain that is different from the public folder's domain.

·         The user's mailbox resides on a server that is located in a site that does not contain any domain controllers for the domain that hosts the public folder.

 

Use one of the following additional steps:

·         Add the Exchange Domain Servers security group of the child domain with Read permissions to the ACL of the Microsoft Exchange System Objects container in the parent domain. This method is the recommended method for working around this problem.

·         Move one domain controller from the parent domain to the user's Exchange 2003 site.

 

Maintaining the Minimum Permissions Required for Mail-Enabled Public Folders

If you modify the default client permissions and roles on a mail-enabled public folder, make sure you maintain the Contributor role for the Anonymous account. Otherwise, mail sent to the public folder will be returned as undeliverable. When the public folder receives e-mail from a user who has no permissions on the folder, it treats the mail as a message posted using the Anonymous account.

Note   
This is a change from Exchange 5.5, where the default role of the Anonymous account was None.

 

Maintaining the Minimum Permissions Required for Mailbox Stores and Public Folder Stores

If you modify the default permissions on Exchange Server 2003 mailbox stores and public folder stores, make sure you maintain the following minimum permissions:

·         Administrators group   Full Control

·         Authenticated Users group   Read and Execute, List Folder Contents, and Read

·         Creator Owner   None

·         Server Operators group   Modify, Read and Execute, List Folder Contents, Read, and Write

·         System account   Full Control

 

You may experience difficulties in mounting the mailbox stores or public folder stores if you do not maintain these permissions for these groups and accounts. The following error messages and events indicate that the accounts and groups in the preceding list do not have the correct permissions:

·         An internal processing error has occurred. Try restarting Exchange System Manager or the Microsoft Exchange Information Store service, or both.

·         MAPI or an unspecified service provider. ID no: 00000476-0000-00000000.

·         Information Store (2520) An attempt to determine the minimum I/O block size for the volume "[drive:\]" containing "[drive:\]Exchsrvr\Mdbdata\" failed with system error 5 (0x00000005): "Access is denied." The operation will fail with error –1032 (0xfffffbf8).

·         Error 0xfffffbf8 starting Storage Group [dn of storage group] on the Microsoft Exchange Information Store.

·         The MAPI call 'OpenMsgStore' failed with the following error: The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000.

 

You may also encounter problems when mounting public folder stores if you have cleared the Allow inheritable permissions from parent to propagate to this object option for the public folder hierarchy. The following error messages indicate that you have cleared this option:

·         The store could not be mounted because the Active Directory information was not replicated yet.

·         The Microsoft Exchange Information Store service could not find the specified object. ID no: c1041722

 

To restore the permissions required by Exchange

1.        In Exchange System Manager, right-click the public folder tree, and then click Properties.

2.        In the Properties dialog box, click the Security tab, click Advanced, and then select Allow inheritable permissions from parent to propagate to this object.

3.        Wait for Active Directory to replicate the change to all of the domain controllers.

4.        Right-click the public folder store and click Mount Store.


Managing Storage Groups and Stores

The Exchange store uses two types of databases:

·         Mailbox stores

·         Public folder stores

 

These databases (or stores) are organized into storage groups. All of the databases in a storage group share a single set of transaction log files, a single backup schedule, and a single set of logging and backup-related settings.

Exchange System Manager lists the storage groups for each server, and the mailbox stores and public folder stores in those storage groups. To view stores and storage groups in Exchange System Manager, expand the server node in the Exchange System Manager console tree. Figure 7.7 shows the mailbox and public folder stores in the First Storage Group of a single server.

Figure 7.7   Store information in Exchange System Manager

 


If you are using Exchange Server 2003 Standard Edition, each Exchange server can have one storage group, which contains one mailbox store and one public folder store. If you are using Exchange Server 2003 Enterprise Edition, each server can have as many as four storage groups, each of which contains as many as five databases (either mailbox stores or public folder stores).

Using either Exchange Server 2003 Standard Edition or Exchange Server 2003 Enterprise Edition, you can create a Recovery Storage Group in addition to your other storage groups. Use this special storage group to recover mailbox data when restoring data from a backup. For more information about how to configure and use a Recovery Storage Group, see "Recovering Mailbox Stores and Mailboxes with a Recovery Storage Group" in the Exchange Server 2003 Help.

You can use multiple mailbox stores to increase the reliability and recoverability of your Exchange organization. If the users are spread across multiple mailbox stores, the loss of a single store impacts only a subset of the users rather than the entire organization. In addition, reducing the number of users per store reduces the time that you need to recover a damaged store from a backup.

Note   
Increasing the number of mailbox stores on a server can increase the server resources consumed relative to the resources consumed for the same number of users in a single store. However, the benefits of using multiple stores usually outweigh the resource costs.

 

You can use multiple public folder stores to spread public folders across multiple servers. You can place multiple replicas of the same folder on several servers, to increase the system's ability to handle user traffic. If you have multiple routing groups, you may want to distribute folders among the routing groups so that users have easy access to the folders that they use most often.

This section includes information about the following:

·         For each storage group, how to configure settings for the transaction logs.

·         For each storage group, how to overwrite deleted data during backups.

·         How to add new storage groups.

·         How to mount or dismount stores.

·         For each store, how to move the database files out of the system directory. This task is the same for mailbox stores and public folder stores.

·         For each store, how to configure maintenance and backup options. These tasks are the same for mailbox stores and public folder stores.

·         How to create and configure mailbox stores. These tasks are specific to the type of store that you are working with.

·         How to create and configure public folder stores. These tasks are specific to the type of store that you are working with.

 


Configuring Transaction Logs for a Storage Group

The most important aspect of a storage group is its transaction logs. Even if you use only the default First Storage Group, you need to consider your transaction log configuration to be sure that you can recover data if the stores are damaged.

In the standard transaction logging that Exchange uses, each store transaction (such as creating or modifying a message) in a storage group is written to a log file and then to the store. When it is written to the log file, each transaction is labeled with an identifier that Exchange uses to associate the transaction with a particular store. In this manner, all of the stores in a storage group share a single set of transaction logs.

This process ensures that records of transactions exist if a store is damaged between backups. In many cases, recovering a damaged store means restoring the store from a backup, replaying any backed-up log files, and then replaying the most recent log files to recover transactions that were made after the last backup.

Note   
For detailed information about how transaction logs work and how to recover store data in a variety of circumstances, see the book Disaster Recovery for Microsoft Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkID=18350). Although existing functionality has not changed, Exchange Server 2003 has new recovery features. For more information about the new recovery features, see the book What's New in Exchange Server 2003 (www.microsoft.com/exchange/library).

 

When a log file reaches 5 megabytes (MB), it is renamed and a new log file is started. As the number of transactions grows, a set of log files is created. The set continues to grow until you run a full backup (also called a normal backup) or an incremental backup. As part of the backup process, old transaction logs are removed and the current log file becomes the first file of a new log file set. You can control the size of the log file set by using a regular schedule of backups. Using the Windows 2000 backup utility or a third-party backup product, any storage group or database can be backed up at any time.

You can perform four types of online backups on the Exchange store:

·         Full backup   A full backup (called a normal backup in Windows Backup) backs up the store and transaction log files. After the backup, transaction log files in which all transactions are complete are deleted.

·         Copy backup   A copy backup backs up the store and transaction log files, but leaves the transaction logs in place.


·         Incremental backup   An incremental backup backs up the transaction logs and removes all transaction logs in which all transactions are completed.

·         Differential backup   A differential backup backs up the transaction logs, but leaves them in place.

 

Important   
You can perform an incremental or differential backup only if you have previously performed a normal backup. If you need to recover a store, you must recover the store itself from the last normal backup, and then you can recover log files from an incremental or differential backup.

 

To configure transaction logs and choose other storage group options

·         In Exchange System Manager, right-click the storage group, and then click Properties.

Figure 7.8 shows the options that are available for configuring a storage group.

Figure 7.8   The storage group Properties dialog box

 


Moving Transaction Log Files to a Separate Drive

When you install Exchange, Setup creates transaction log files and database files on the same drive. You can significantly improve the performance and fault tolerance of an Exchange server by placing its transaction log files and database files on separate drives. Because these files are critical to the operation of a server, the drives should be protected against failure, ideally by hardware mirroring using redundant array of independent disks (RAID). It is recommended that you use RAID 1, RAID 0+1, or RAID 10. Use the NTFS file system for transaction log drives.

For optimum performance, the set of transaction logs for each storage group should be placed on a separate drive. Because each storage group has its own set of transaction logs, the number of dedicated transaction log drives for your server should equal the number of planned storage groups. Although it is possible to place multiple sets of transaction logs on the same drive, if you do so server performance may decline significantly.

Tip   
Distribute your database drives across many Small Computer System Interface (SCSI) channels or controllers, but configure them as a single logical drive to minimize SCSI bus saturation.

 

An example disk configuration is as follows:

·         C:\ System and boot (mirror set)

·         D:\ Pagefile

·         E:\ Transaction logs for storage group 1 (mirror set)

·         F:\ Transaction logs for storage group 2 (mirror set)

·         G:\ Database files for both storage groups (multiple drives configured as hardware stripe set with parity)

 

To configure new locations for the transaction logs

1.        In Exchange System Manager, right-click the storage group and click Properties.

2.        On the General tab, specify a new location for the files.

For example, if the E:\ drive will contain only log files for this storage group, in Transaction log location, click Browse, and then choose the E:\ drive.

 


Using Circular Logging

Circular logging overwrites and reuses a single log file after the data that it contains has been written to the database. Circular logging is disabled by default. By enabling circular logging, you reduce drive storage space requirements. However, you cannot recover anything more recent than the last full (normal) backup, because the transaction logs no longer contain all of the transactions that were completed since the last backup. Therefore, in a normal production environment, circular logging is not recommended.

Warning   
Using the Enable circular logging option prevents you from creating a set of log files, and you can restore only from your last backup. Reserve this option for storage groups that support Network News Transfer Protocol (NNTP) folders (in public folder stores), which do not require log files.

 

Overwriting Deleted Data During Backup

As with most applications, data that Exchange deletes is not actually removed from the disk. Although Exchange treats it as deleted data, it usually remains until it is overwritten by more recent data. If you want to make sure that deleted data is overwritten on a regular basis, use the Zero out deleted database pages option. When this option is enabled, Exchange overwrites chunks of deleted data during the online backup process.

Important   
Enabling the Zero out deleted database pages option can slow backup performance and increase the size of the database files. The option is turned off by default.

 

Adding a Storage Group

A storage group includes between one and five databases (mailbox stores and public folder stores) and one set of transaction log files for those databases. You may want to add a storage group under the following conditions:

·         You want to have more than five databases on a particular server. For example, to improve the backup or recovery time for each mailbox store, you increase the number of mailbox stores and put fewer users in each store.

·         You have databases with different backup or restore requirements. For example, you have one database that you cannot afford to have offline for more than a few hours, even if it must be completely reconstructed.

 


To create a new storage group

1.        In Exchange System Manager, right-click the server where the new storage group will reside, point to New, and click Storage Group.

2.        When prompted, type a name for the storage group.

Exchange fills in default values for Transaction log location and System path location. You can change the defaults, or you can change these values at a later time.

 

Mounting or Dismounting Stores

A mounted store is a store that is operating normally and is available for user and administrator access. If the store is dismounted or offline, no users can access it and you may not be able to view or change all of the store properties. In most cases, Exchange mounts and dismounts stores automatically, if needed. For example, if you move a store's database files to a new directory, the store will be dismounted automatically until the move is complete.

Under certain conditions, you may need to mount or dismount stores manually. For example, you can configure stores so that, if the server restarts, the store must be mounted manually. That way you can check the server for problems before allowing users to access the store again. For more information, see "Configuring Store Maintenance and Backup Options" later in this chapter.

The Mount Store and Dismount Store commands are available in the Action menu for each store that appears in Exchange System Manager.

Note   
If you do not have permissions on a particular store, the store may appear to be dismounted in Exchange System Manager when it is actually running. This may occur if you are using a distributed administration model, with multiple administrative groups with separate administrators. Each administrator will only be able to interact with the stores in that administrator's own administrative group.

 

Moving Store Files to a New Directory

When you install Exchange, Setup creates database files on the same drive as the Exchange program files. To get better performance and more storage space, you can move the Exchange databases (mailbox stores and public folder stores) out of the default drive or directory. The stores are dismounted automatically during the move, and will not be available to users.

Tip   
Distribute your database drives across many SCSI channels or controllers, but configure them as a single logical drive to minimize SCSI bus saturation.

 


When you move a store, remember the following:

·         Use Exchange System Manager on the server on which the stores reside to move the .edb and .stm database files of the stores. Moving these files requires that you specify new file locations on the Database tab of the Properties dialog box (see Figure 7.9 in the next section).

·         You should perform a normal backup when the move is finished. This process backs up and removes existing transaction log files, and simplifies future recovery operations.

For more information about recovery operations and transaction log files, see the book Disaster Recovery for Microsoft Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkID=18350).

 

Configuring Store Maintenance and Backup Options

The maintenance processes and backup options are the same for mailbox stores and public folder stores. You can check and configure these options on the Database tab (see Figure 7.9) of the store that you want to check or configure.

Figure 7.9   The Database tab for a mailbox store


The Database tab for a mailbox store includes the following maintenance and backup options.

·         Maintenance interval   Specifies the schedule for the automatic database maintenance process. This process:

·         Checks that none of the storage limit settings have been exceeded on any mailbox or public folder.

·         Sends mail to the administrator or the mailbox owner if storage limits have been exceeded.

·         Checks for deleted items that have been retained for the amount of time configured for the store.

·         Checks for and deletes expired items in the folders if age limits have been set on any public folders.

Because this process can consume significant server resources, you should schedule it to run during off-peak hours.

 

Note   
For more information about the settings that the maintenance process enforces, see "Configuring the Default Mailbox Limits," "Configuring the Default Public Folder Limits," and "Configuring Limits on a Specific Public Folder Replica" later in this chapter.

 

·         Do not mount this store at start-up   When this option is selected, the mailbox store does not mount automatically when Exchange is started. By default, this check box is cleared.

·         This database can be overwritten by a restore   Do not use this option for normal restore operations. Select this option only if a restore operation fails with an error that indicates the database cannot be overwritten. By default, this option is not selected.


Configuring Mailbox Stores

Mailboxes are the delivery location for all incoming mail messages for a designated owner. A mailbox can contain messages, message attachments, folders, documents, and other files. Information in a user's mailbox is stored in a mailbox store on an Exchange server. Figure 7.10 shows a list of the mailboxes on a single mailbox store.

Figure 7.10   Mailbox store information in Exchange System Manager

 

Mailboxes inherit many of their properties (such as storage limits) from the mailbox store. You can create different mailbox stores for different groups of users. For example, you may place mailboxes for workers in one store and mailboxes for executives in another store, and give the executives double the normal storage limits by configuring the store instead of configuring the individual mailboxes.

This section describes the following:

·         The relationship between a mailbox store and its associated public folder store.

·         Single instance storage of messages (when it applies and when it does not).

·         How to add a mailbox store.

·         How to configure the default mailbox storage limits and the length of time that deleted items and mailboxes will be retained.

·         How to control mailbox store settings with system policies.

·         Interfaces to use for monitoring mailbox store activity.

 

For information about configuring the store for full-text indexing updates, see Appendix F, "Using Full-Text Indexing."

Linking Mailbox Stores and Public Folder Stores

Each mailbox store must be associated with a public folder store. You specify the public folder store when you create a mailbox store. The public folder store that is installed by default on each server supports the Public Folders tree (also called the MAPI public folder tree). You can have only one Public Folders tree in your Exchange organization, and it is associated with each server's default public folder store.

Note   
Using the default public folder store on the same server as the mailbox store may improve performance when users access public folders, and may make it easier to troubleshoot public folder access problems.

 

For more information about public folder trees and the default public folder store, see "Configuring Public Folder Stores" and "Managing Public Folders" later in this chapter.

Understanding Single Instance Message Storage

To help control the size of the mailbox stores, Exchange supports single instance message storage. This means that when a message is sent to more than one mailbox in the same store, only one instance of the message is stored, in one mailbox. The other mailboxes contain pointers to the stored message.

If the message is sent to mailboxes in a different mailbox store, the message is written once to each mailbox store.

Single instance storage may not be maintained when a mailbox that contains a message is moved to a server that contains a mailbox store with the same message.

Tip   
To maximize single instance message storage, place similar users in the same mailbox store, such as users in the same department who use Reply All or users that send large attachments to one another frequently.

 


Adding a Mailbox Store

To create a new mailbox store

1.        In Exchange System Manager, right-click the storage group where the new store will reside, point to New, and click Mailbox Store.

2.        When prompted, type a name for the mailbox store.

Exchange automatically selects a default public store (associated with the Public Folders tree) and offline address book (which users will download for offline use) for your new mailbox store.

You can modify these options now or at a later time (by right-clicking the mailbox store and clicking Properties). Figure 7.11 shows the properties of a mailbox store.

Figure 7.11   The General tab for a mailbox store

 

For more information about creating mailboxes, see "Managing Mailboxes" later in this chapter.


Configuring the Default Mailbox Limits

Using the limits settings in the Limits tab, you can control the maximum size of mailboxes in the mailbox store and control how deleted items are handled. You can access the limits settings on the Limits tab of the mailbox store's Properties dialog box (see Figure 7.12).

Figure 7.12   The Limits tab for a mailbox store

 

Note   
For an individual user, you can override the store's limits settings by using Active Directory Users and Computers to configure limits settings for the user.

 

Table 7.2 describes the possible limits that can be set for a mailbox store. By default, no limits are set.

Table 7.2   Options available on the Limits tab for a mailbox store

Option

Description

Issue warning at (KB)

When a user's mailbox exceeds the specified size limit, the user receives an e-mail alert to delete messages from the mailbox. By default, this option is not selected.


 

Option

Description

Prohibit send at (KB)

When a user's mailbox exceeds the specified size limit, the user receives an e-mail alert to delete messages from the mailbox. In addition, the user is unable to send e-mail messages until the mailbox size is reduced below the specified limit. By default, the option is not selected.

Prohibit send and receive at (KB)

When a user's mailbox exceeds the specified size limit, the user receives an e-mail alert to delete messages from the mailbox. In addition, the user is unable to send e-mail messages until the mailbox size is reduced below the specified limit, and incoming e-mail messages are returned to the sender with a non-delivery report (NDR).

Warning message interval

Use this drop-down list to schedule when warning messages are generated. You can select one of the standard maintenance schedules, or click Customize to set up your own schedule.

This process is CPU-intensive and disk-intensive, and can slow server performance. You should schedule maintenance of this type at off-peak times.

Keep deleted items for (days)

You can designate the number of days that deleted items (such as e-mail messages) remain on the server before they are removed permanently. You can type a number from 0 to 24855. If you type 0, deleted items are removed from the server immediately.

As long as deleted items remain on the server, Outlook users can retrieve them using Outlook's Recover Deleted Items function.

Keep deleted mailboxes for (days)

You can designate the number of days that deleted mailboxes remain on the server before they are removed permanently. After this value is set, you have the specified number of days to recover mailboxes that were deleted by accident.

You can type a number from 0 to 24855. If you type 0, deleted mailboxes are removed from the server immediately.

Do not permanently delete mailboxes and items until the store has been backed up

You can keep deleted mailboxes and items on the server until a backup is performed. After a backup is performed, mailboxes and items are deleted, according to the settings that you specified.

 


Setting Up Mailbox Store Policies

You can create policies to manage mailbox stores in the same way that you create other system policies. For detailed information about all types of system policies, see "Using System Policies" in Chapter 2, "Managing an Exchange Organization."

You can set the following options using policies:

·         General tab

·         Default public store

·         Offline address list

·         Archive all messages sent or received by mailboxes on this store

·         Clients support S/MIME signatures

·         Display plain text messages in a fixed-size font

 

·         Database tab

·         Maintenance interval

 

·         Limits tab

·         Issue warning at (KB)

·         Prohibit send at (KB)

·         Prohibit send and receive at (KB)

·         Warning message interval

·         Keep deleted items for (days)

·         Keep deleted mailboxes for (days)

·         Do not permanently delete mailboxes and items until the store has been backed up

 

·         Full-Text Indexing tab

·         Update interval

 

Use the System Policies node in Exchange System Manager to create and apply policies. After you create a mailbox store policy, you can apply that policy to one or more mailbox stores on any server.

Note   
You can only apply a policy to a store if you have permissions to modify that store. If you are using a distributed administration model, with multiple administrative groups that have separate administrators, each administrator will only be able to interact with the stores in that administrator's own administrative group.

To apply a policy to one or more mailbox stores

1.        In Exchange System Manager, right-click the policy, and click Add Mailbox Store.

2.        Select the appropriate stores.

After you have applied the policy, the options that the policy controls are no longer available in the mailbox store's Properties dialog box. This prevents local settings from overriding the policy. For a list of all of the policies that are applied to a particular mailbox store, go to that mailbox store's Policies tab.

 

Monitoring Mailbox Store Activity

Exchange System Manager provides up-to-date information about items in the mailbox store. You can use this information for troubleshooting system problems, or evaluating whether the system needs tuning or reconfiguring. For example, Figure 7.13 shows the list of mailboxes in a mailbox store, the users that have been accessing those mailboxes, and the size of the mailboxes. Except where noted, Exchange View Only Administrators can access this information.

Figure 7.13   Mailbox store information in Exchange System Manager

 


Table 7.3 lists the status information that is available for each of the nodes under the mailbox store.

To display different columns of information in the right pane, click the node that you want to view. On the View menu, click Add/Remove columns, and then select the types of information that you want to display. For a detailed listing of the available columns, see "Administer a Mailbox Store" in the Exchange Server 2003 Help.

Table 7.3   Status information for a mailbox store

Node

Status Information

Logons

Users that are currently logged on to their mailboxes, and their activities.

Use this information to look for mailbox users that are unusually active or inactive. The Total Ops column is especially useful for this purpose.

You must be at least an Exchange Administrator to view this information.

Mailboxes

Current mailbo