Administration Features in Exchange Server 2003

 

Microsoft® Exchange Server 2003 includes several new features that make Exchange administration easier and more efficient. From new recipient management features to an improved Queue Viewer, Exchange 2003 offers significant improvements over earlier versions of Exchange.

The following table lists the Exchange 2003 feature enhancements discussed in the following topics.

Exchange 2003 administration - feature enhancements

Feature	Description
Recipient management	Two new mail-enabled objects in recipient management—InetOrgPerson and Query-based Distribution groups. Exchange Features tab of the user Properties includes Wireless Services and Protocols features. You can now run multiple instances of the Exchange Task Wizard simultaneously in a single console. You can use the Exchange Task Wizard in Exchange System Manager to move mailboxes. New in SP2: A feature has been added that allows you to disable and enable MAPI access for individual users.
Mobile client management	New in SP2: Support added for mobile client synchronization by using direct push technology. When direct push is enabled, new e-mail items are automatically pushed from the server to the mobile device without requiring SMS notification messages. New in SP2: Features have been added to allow administrators to manage security-related policy settings for mobile clients. New in SP2: A feature has been added to allow administrators to provision a mobile device and to wipe a mobile device remotely. New in SP2: Mobile device users can now view contact properties for individuals in the global address list (GAL). New in SP2: Support has been added for certificate-based authentication and S/MIME.
Queue Viewer	Improved Queue Viewer functionality provides visibility to more message queues. You can view both SMTP and X.400 queues from Queue Viewer instead of from their separate nodes. You can disable outbound mail from all SMTP queues. You can set the refresh rate for queues. Improved Find Messages option to search for messages within a queue. You can use the Additional queue information pane to view additional information about a particular queue. Hidden queues exposed, such as Failed message retry queue and display in Queue Viewer.
Public Folders	New and improved public folder administration interface such as the Status tab and the Replication tab. Improved search capability to search all public folders. You can create a list of specific servers among which public folder referrals are allowed. Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new Microsoft Windows script file (.wfs) that allows you to create replicas of your system folders and public folders on the new Exchange 2003 server. New in SP2: You can now track the deletion of public folders. New in SP2: You can now manually stop and resume public folder replication. New in SP2: You can now use the Manage Public Folders Settings Wizard to modify client permissions, modify lists of replica servers, and overwrite public folder settings. New in SP2: You can now more easily move all public folder content from a public store to a different server.
Mailbox Recovery Center	Using the new Mailbox Recovery Center, you can perform recovery or export operations on multiple disconnected mailboxes at one time.
Message Tracking Center	You have greater control in Exchange System Manager over your message tracking log files. You can now track messages after categorization.
Exchdump.exe utility	Exchdump.exe is a command line utility that collects and reports Exchange configuration information from various sources such as Microsoft Active Directory® directory service, the registry, and so on.

New Mail-Enabled Objects for Managing Recipients

Recipients are Active Directory objects. Users can either be mailbox-enabled or mail-enabled. Contacts, groups, and public folders can only be mail-enabled. These designations determine what tasks users can perform in Exchange. Exchange 2003 introduces two new recipient objects—InetOrgPerson and Query-based Distribution Group.

InetOrgPerson

The InetOrgPerson object is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization. Support for InetOrgPerson in Exchange 2003 makes migrations from other LDAP directories to Active Directory more efficient. InetOrgPerson objects in Active Directory can be either mailbox-enabled or mail-enabled. For detailed instructions, see How to Create an InetOrgPerson.

The InetOrgPerson object in Active Directory is derived from the user class; it functions like a user object and conforms to the LDAP standard. Furthermore, InetOrgPerson can be used as a security principal, just like the user class. Active Directory now includes InetOrgPerson in queries for users. Active Directory provides support for the InetOrgPerson object class, as well as its associated attributes, which are defined in RFC 2798. For more information about RFC 2798, see https://www.ietf.org/.

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 these groups work, and how to create them.

What Is a Query-Based Distribution Group?

A query-based distribution group provides the same functionality as a standard distribution group; however, instead of specifying static user memberships, a query-based distribution group allows you to use an LDAP query to dynamically build membership in the distribution group (for example "All full-time employees in my company"). Using query-based distribution groups allows for a much lower administrative cost, given the dynamic nature of the distribution group. However, query-based distribution groups require higher performance cost for queries that produce a large number of results. This cost is equated with server resources (such as high CPU and increased working set) 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.

How Does a Query-Based Distribution Group Work?

When a message is submitted to a query-based distribution group, Exchange handles the message in a slightly different manner than messages that are destined for other recipients. A query-based distribution group flows through Exchange to the proper recipients in the following manner:

1. An e-mail message is submitted to the submission queue through the Exchange store driver or through SMTP.

2. The categorizer, a transport component 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 executes the query and returns the set of addresses that match the query.

5. After receiving the complete set of addresses matching the query, the categorizer generates a recipient list containing all the users.

   Note

   The categorizer must have the complete set of recipients before it can submit the 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 the e-mail message is delivered to the users' mailboxes.

If a dedicated expansion server (a single server responsible only for expanding distribution groups) is used for query-based distribution groups, the process is slightly different. In this case, rather than sending a query to the global catalog server for expansion (as in Step 4), the message is first routed to the dedicated expansion server. After the message arrives at the expansion server, the expansion takes place, and the delivery follows the same process described above.

Creating Query-Based Distribution Groups

Query-based distribution works reliably in a pure Exchange 2003 deployment or in a native Exchange 2000 and Exchange 2003 deployment in which all Exchange 2000 servers are running Service Pack 3 (SP3) with Windows Server 2003 global catalog servers. If your global catalog servers are running Windows® 2000 Server, you can modify a registry key on your Exchange 2000 SP3 servers to achieve greater reliability. You do not need to add this registry key to your Exchange 2003 servers, because, by default, Exchange 2003 expands query-based distribution groups reliably with Windows 2000 and Windows Server 2003 global catalog servers. If you are running versions of Exchange earlier than Exchange 2000 SP3 in your organization, 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 organizations where query-based distribution groups will be expanded with Windows 2000 global catalogs. For detailed instructions, see "How to modify your Exchange 2000 SP3 Servers for Use with Windows 2000 Global Catalog Servers" in the Exchange Server 2003 Administration Guide.

Creating a Query-Based Distribution Group

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. For detailed instructions on creating a query-based distribution group, see "How to Create a Query-Based Distribution Group" in the Exchange Server 2003 Administration Guide.

Active Directory Users and Computers provides an easy way to format the LDAP query with 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 the organizational unit that exist on a particular server.

Additionally, after you construct a query, the Preview tab in the query's Properties provides the information necessary to ensure that your query functions properly. As mentioned earlier, you can ensure that all attributes selected for the query are available on the global catalog server. You can also use the Preview tab to learn how long a query takes to execute and, based on this time, you can break up the query into smaller queries for better performance and faster delivery times.

Guidelines for Creating Query-Based Distribution Groups

Use the following guidelines when creating query-based distribution groups:

• You can only use query-based distribution groups in a pure Exchange 2003 environment or in a native mode environment with Exchange 2000 and Exchange 2003, where all Exchange 2000 servers are running Service Pack 3.

• When creating distribution groups that span domains, use universal groups in multi-domain environments. Although you can add query-based distribution groups to global distribution groups, domain local and global security groups and can contain any of these groups; membership in these types of groups is not replicated to global catalog servers in other domains. Use universal distribution groups in situations where distribution spans a multi-domain environment.

  • When combining 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 building query-based distribution groups, you should only include universal groups if you want the membership to be available in all domains in a multi-domain environment.

• Index the attributes used in the query. Indexing greatly improves the performance of the query and reduces the time required to expand the distribution group and deliver the e-mail message to the intended recipients.

• If the filter string contains bad formatting or incorrect LDAP syntax, then the global catalog server will not execute the query. Use Active Directory Users and Computers to create your query, which can help prevent you from constructing an incorrect query. You can also use the Preview tab in the query's Properties to view the result of the query; this will confirm the validity and desired results of the query. If you create a query-based distribution group based on an incorrect LDAP query, a user who sends a message to the query-based distribution group will receive a non-delivery report (NDR) with the code 5.2.4; furthermore, if categorizer logging is enabled, one of two events are logged with event identifiers of 6024 or 6025.

• Always use the Preview tab to ensure that the attributes you include in your query are available on the global catalog server.

• If the filter string is well formatted but no results are produced, then the sender will not receive an NDR. This is the same behavior that results when a message is sent to an empty distribution group. As mentioned earlier, use the Preview tab in Active Directory Users and Computer to confirm the result of your query.

• Use Exchange System Manager in a security context that has the same permissions for reading objects in Active Directory as the Exchange server. It is important to note that Exchange System Manager runs in the security context of the user who is currently logged in. If an administrator is running Exchange System Manager and has lower security privileges than the Exchange server, it is possible that the query will show a subset of the actual results on the Preview tab. The preview pane only shows the Active Directory objects that the administrator has permission to read. When a message is sent to the query-based distribution group, however, the categorizer runs with the Exchange server permissions. Assuming that the Exchange server has permissions for all the objects in the query, the query returns the correct results.

• Issues arise 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 a query-based distribution group's base distinguished name container is deleted, the categorizer cannot execute 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, suppose you created a Sales container within the Users container for all Sales employees and then used the Sales container to build a query-based distribution group. If you deleted the Sales container, the query would no longer work.

Combining Multiple Query-Based Distribution Groups

In Exchange System Manager, you can create query-based distribution groups based on the AND operator. This means you can create a query using two attribute values; the query includes results that meet both of the specified conditions. For example, if you create a query that includes users on mailbox store 1 and users located in Seattle, the results include only users who are on mailbox store 1 and also located in Seattle. 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. For example, if you want to include users who are on mailbox store 1 or located in Seattle, you would need to create on query-based distribution group for users in Seattle and a second query-based distribution group for users residing on mailbox store 1. Then you would create a standard distribution group and include these two query-based distribution groups as members.

For example, assume you want to create a query-based distribution group that includes all Marketing employees or all employees located in the Paris office. If you create a query-based distribution group with an LDAP query that contains all Marketing employees and all Paris employees, the query only returns users who are in both groups—any user who is not a member of both groups is excluded. To achieve OR functionality (thereby including members of either group), you must create two query-based distribution groups, one for Marketing employees and one for Paris employees; then you must combine the two groups to create a new distribution group (not a query-based distribution group) that contains the two groups as members. To do this, you would perform the following steps:

1. Create a query-based distribution group called Marketing for all Marketing employees.

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

3. Create a distribution group and add the query-based distribution groups—Marketing and Paris employees—as members of this group.

   Important

   You cannot add query-based distribution groups as members of a distribution group the same way you add users to a group. You must right-click the distribution group, and then click Add Exchange Query-based Distribution Groups.

For detailed instructions about adding query-based distribution groups as members of a standard distribution group, see "How to add query-based distribution groups as members of a distribution group" in the Exchange Server 2003 Administration Guide.

Deployment Recommendations for Query-Based Distribution Groups

The following factors influence the amount of time it takes to expand and execute a query-based distribution group:

• Hardware

  The categorizer can require up to 2 KB of memory for each recipient. Use this conservative metric 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 MB of RAM just to expand the query-based distribution group. Similarly, if you send 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 the time it takes to deliver the messages after the expansion.

• Global catalog availability

  If you send a message to a query-based distribution group and all global catalog servers are unavailable, the message is placed in retry mode in the categorizer. This means that the complete expansion will restart after one hour.

  The general recommendation is to separate large query-based distribution groups into combinations of standard distribution groups, and then assign different expansion servers for each large distribution group. When expanding distribution groups, consider one of the following three options for designating and configuring expansion servers and global catalog servers:

  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 server. Assigning 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, if you wanted 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, name them Server1 Full Time and Server2 Full Time, and then create a standard distribution group called AllFullTime that is comprised of the two server-based groups.

  Note

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

  Option 3

  Instead of using a single large query-based distribution group, create smaller query-based distribution groups and combine them in a standard distribution group.

  Suppose you want to create a query-based distribution group called All employees with one hundred thousand users. Divide the group into the following smaller query-based distribution groups, and then combine 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 scenario All Full-Time is 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 the interns reside on one Exchange server, you may want to have the same server as expansion server for All Interns. Overall, this approach performs much better than a single query-based distribution group with 100,000 recipients.

Improved Ability to Restrict Submissions to Users and Distribution Lists (Restricted Distribution Lists)

In Exchange 2003, you can restrict who can send e-mail messages to an individual user or a distribution list. Submissions can be restricted to a limited number of security principles though the standard Windows discretionary access control list (DACL). Restricting submissions on a distribution list prevents non-trusted senders, such as unauthorized Internet users, from sending mail to an internal-only distribution list. For example, an All Employees distribution list should not be available to anyone outside the company (by spoofing or otherwise).

For detailed instructions about setting submission restrictions on users, see "How to set restrictions on a user" in the Exchange Server 2003 Transport and Routing Guide. For detailed instructions about setting submission restrictions on distribution lists, see " How to set restrictions on a distribution group" in the Exchange Server 2003 Transport and Routing Guide.

Enhanced Exchange Features on User Properties

The Exchange Features tab in the user Properties now includes the Mobile Services and Protocols features. These Exchange features provide added functionality for your mailbox-enabled users. You can enable or disable the user's Mobile Services options (such as Microsoft Outlook® Mobile Access), or Protocols (such as Outlook Web Access). For detailed steps, see the following procedures:

• How to Enable or Disable Exchange Features for a Single User

• How to Enable or Disable Exchange Features for Multiple Users

Moving Mailboxes in Exchange System Manager

Exchange Task Wizard provides an improved method for moving mailboxes. You can now select as many mailboxes as you want and then, using the task scheduler, schedule the move to occur at some point in the future. You can also use the scheduler to cancel any unfinished moves at a selected time. For example, you can schedule a large move to start at midnight on Friday and automatically terminate at 6:00 A.M. on Monday, thereby ensuring that your server's resources are not being tapped during regular business hours. Using the wizard's multithreaded capabilities, you can move up to four mailboxes simultaneously.

For detailed instructions on how to move mailboxes from Exchange System Manager, see "How to move mailboxes from one Exchange Virtual Server to another server" in the Exchange Server 2003 Administration Guide. You can also move mailboxes from Active Directory Users and Computers.

New in SP2: Enabling or Disabling MAPI Access for a Specific User

In Exchange Server 2003 SP2, you can disable MAPI access for a given user. You can also grant access to a user who has configured Microsoft Office Outlook to run in cached mode, but deny access otherwise. This functionality is valuable in a variety of scenarios. For example, if you provide hosting services, you can require that your hosted users connect to Exchange Server with Outlook Web Access, but not with Outlook.

The ProtocolSettings attribute on the user object in the Active Directory® directory service stores client access settings. This attribute is a multi-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

MAPI§<Bool1>§<Bool2>§§§§§§

The eight § separators define exactly nine fields. The fields have the following meanings.

MAPI	Specifies that this string contains settings that apply to the MAPI protocol.
Bool1	0 to block all MAPI access; 1 to determine MAPI access based on Bool2.
Bool2	0 for noop; 1 to deny access to non-cached mode Outlook clients.
Remaining 6 fields	Currently not used.

If ProtocolSettings does not contain a MAPI string, all MAPI clients are allowed.

The access restrictions specified above do not apply in the following cases:

• MAPI access restrictions do not affect Exchange Server tasks. For example, user mailboxes can still be moved regardless of the MAPI access settings for the given mailbox.

• MAPI access restrictions that have been applied to a specific user do not apply to that user's delegate access to another user's mailbox.

New in SP2: Enabling Direct Push Technology

In Exchange Server 2003 SP2, support has been added for mobile client synchronization by using direct push technology. Direct push maintains an open connection between the mobile device and the server. When direct push is enabled, new mail items are automatically pushed from the Exchange server to the mobile device without requiring SMS notification messages.

For information about how to enable direct push technology for all your users, see "Enable Exchange ActiveSync for All Users" in the Exchange Server 2003 SP2 online Help.

New in SP2: Managing Security Settings for Mobile Clients

In Exchange Server 2003 SP2, support has been added to allow you to manage security policy settings for mobile clients. Security policy settings allow you to establish and then enforce security policies for your mobile device users.

You can configure the following options.

• Password requirements   You can specify the required length of the user's device password. The default setting is 4 characters. You can specify a password length of 4 to 18 characters. You can also require that users choose a password with both numbers and letters. The setting to require numbers and letters is not selected by default.

• Logon requirements after periods of inactivity   You can specify if you want your users to log on to their devices after a specified number of minutes of inactivity. This setting is not selected by default. If selected, the default setting is 5 minutes.

• Wipe memory of device after a specified number of failed logon attempts   You can specify if you want the device memory wiped after multiple failed logon attempts. This setting is not selected by default. If selected, the default setting is 8 attempts.

• Interval that mobile device policy settings are sent to a device   You can specify how often you want to send a provision request to devices. This setting is not selected by default. If selected, the default setting is every 24 hours.

You have the following options when you determine how to enforce your security policies:

• You can allow only devices that support mobile device security policy features to synchronize their devices. When this setting is selected, only users with devices that are running Windows Mobile 5.0 and the Microsoft Messaging and Security Feature Pack for Windows Mobile 5.0 and later will be able to synchronize their devices.

• You can allow mobile devices that do not fully support mobile device security policy features. Specifically, users with devices that are running versions earlier than Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0 will be able to synchronize their devices. However, it is important to note that when you use this option, only users with devices that are running Windows Mobile 5.0 and the Messaging and Security Feature Pack for Windows Mobile 5.0 and later will be subject to mobile device security policy settings.

• You can specify specific users who are exempt from device security settings. This option allows you to specify the user names of specific, trusted users of whom you do not need to require device security settings.

For information about configuring device security settings, see "Configure Security Settings for Mobile Devices" in Exchange Server 2003 SP2 online Help.

New in SP2: Remote Wiping of Mobile Devices

In Exchange Server 2003 SP2, a feature called remote wipe has been added to allow you to remotely erase sensitive data from a mobile device. This feature is useful if you need to remotely erase sensitive data from a lost or stolen mobile device. After you use this command and successfully erase sensitive data from a mobile device, you will receive a message acknowledging that the device has been successfully wiped.

New in SP2: Global Address List Search for Mobile Clients

In Exchange Server 2003 SP2, global address list (GAL) lookup enables mobile device users to receive contact information for users in the global address list on their mobile device. This feature lets a user quickly search for a person, based on name, company, and so on.

New to SP2: Certificate-Based Authentication and S/MIME on Mobile Devices

In Exchange Server 2003 SP2, the following support has been added:

• Support for certificate-based authentication

• Use of S/MIME to sign and encrypt mail

Enhancements to Queue Viewer

In Exchange 2003, Queue Viewer is enhanced to improve the monitoring of message queues. For example, you can now view X.400 and STMP queues in Queue Viewer, rather than from their respective protocol nodes. Other enhancements include:

• Disabling outbound mail   Queue Viewer includes a new option called Disable Outbound Mail, which allows you to disable outbound mail from all SMTP queues. For detailed instructions, see How to Disable Outbound Mail for All SMTP Queues.

• Setting the refresh rate   You can use the Settings option to set the refresh rate of the queues. For detailed instructions, see How to Modify Queue Viewer Refresh Rate Settings.

• Finding messages   You can search for messages based on the sender, recipient, and message state using Find Messages. For detailed instructions, see How to Find Messages.

• Viewing additional information   You can click a specific queue to view additional information about that queue. For detailed instructions, see How to View Additional Information About a 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.

The following figure illustrates the new and improved Queue Viewer.

Queue Viewer

Viewing Previously Hidden Queues

Several queues that were hidden in Exchange 2000 are now visible in Exchange System Manager.

The following table lists the new queues, their descriptions, and possible reasons for message accumulation in each queue.

New queues in Exchange 2003

Queue Name	Description	Causes for Message Accumulation
DSN messages pending submission	Contains delivery status notifications (DSN), also known as non-delivery reports, that are ready to be delivered by Exchange. Note   The following operations are unavailable for this queue: Delete All Messages (no NDR) Delete All Messages (NDR)	Messages can accumulate in this queue if the Microsoft Exchange Information Store service is unavailable or not running, or if problems exist with IMAIL Exchange store component, which is the component that performs message conversion. Check the event log for possible errors with the Microsoft Exchange Information Store service.
Failed message retry queue	Contains messages that failed some sort of queue submission, often before any other processing has taken place. By default, messages in this queue are reprocessed in 60 minutes.	Possible causes for failed messages are: Corrupted messages. Third-party programs or event sinks may be interfering with message queuing or fidelity. Low system resources causing the system to respond slowly or indicates performances issues. Restarting IIS temporarily may temporarily improve resource issues, but the root cause should be determined.
Messages queued for deferred delivery	Contains messages that are queued for delivery at a later time, including messages that were sent by older versions of Microsoft Office Outlook. (You can set this option on Outlook client computers.) Previous versions of Outlook depend on the message transfer agent (MTA) for message delivery. Now, SMTP, not the MTA, handles message delivery. Therefore, messages sent by older versions of Outlook treat deferred delivery differently. These messages remain in this queue until their scheduled delivery time.	Possible causes for message accumulation are: If a message is sent to a user's mailbox while the mailbox is being moved, messages can be queued here. When the user does not yet have a mailbox and no master account Security ID (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." The message may be corrupted or the recipient may not be valid. To determine if a message is corrupted, check its properties. If some messages are not accessible, this can indicate a corrupted message. You can also check that the recipient is valid.

Improved Public Folder Referral

In Exchange 2000 Server, you could specify whether or not to allow public folder referrals among routing groups. Exchange 2003 provides a richer interface, which you can use to create a list of specific servers among which referrals are allowed.

When a user connects to a public folder store that does not contain a copy of the content the user is looking for, the user is redirected to another store that has a copy of the content. You can use public folder referrals to control this redirect traffic (this is similar to public folder affinity in Exchange 5.5).

Using the default configuration, Exchange attempts to redirect the user to a server within the local routing group. If none of those servers has the required content, Exchange follows the organization's routing group structure to search for an appropriate server.

In Exchange Server 2003, you can create a list of specific servers among which referrals are allowed. For example, you can limit referrals to a single routing group, or only allow referrals between certain servers in each routing group. For detailed instructions on creating a custom list of referrals, see "How to Specify a Custom List for Public Folder Referrals" in the Exchange Server 2003 Administration Guide.

You can also assign "costs" to prioritize the servers in your referral list. Use costs to prioritize servers in the referral list. Higher-cost servers are used only if lower-cost servers are not available. For detailed instructions on assigning "costs" to prioritize the servers in your referral list, see "How to Assign Costs on the Public Folder Referrals List" in the Exchange Server 2003 Administration Guide.

Improved Public Folder Interfaces

To make public folders easier to manage, Exchange 2003 includes several new public folder interfaces. To view these new interfaces, in Exchange System Manager, expand Folders and then select a public folder (or in some cases, a public folder hierarchy). The following new tabs are displayed in the details pane.

• Content tab

  Use this tab to view the contents of a public folder in Exchange System Manager. You no longer have to open a separate client application to view public folder content. For detailed instructions, see How to View the Content of a Public Folder Using Exchange System Manager.

• Find tab

  Use this tab to search for public folders within the selected public folder or public folder hierarchy. You can specify a variety of search criteria, such as the folder name or age. For detailed instructions, see How to Search for a Public Folder.

  Note

  The Find tab is available at the top-level hierarchy level as well as the folder level.

• Status tab

  Use this tab to view the status of a public folder, including information about servers that have a replica of the folder and the number of items in the folder. For detailed instructions, see "How to Check Public Folder Replication Status" in Working with the Exchange Server 2003 Store.

• Replication tab

  Use this tab to view replication information about the folder. For detailed instructions, see "How to Configure Public Folder Replicas" in Working with the Exchange Server 2003 Store.

New tabs available for viewing public folder information

Manually Starting Replication

If you want to ensure that public folders replicate without waiting for the normal replication interval, you can start replication manually. Using the Send Contents or Send Hierarchy commands on a public folder, you can replicate changes from one specified server to another. The range of changes to replicate starts the specified number of days in the past and ends at the last replication cycle. For example, you can replicate all changes made over the past two days except for any changes made since the last replication cycle.

For detailed instructions on manually replicating public folder content, see "How to Replicate Public Folder Data Manually" in Working with the Exchange Server 2003 Store.

Microsoft Exchange Public Folder Migration Tool

Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new Windows Installation script (.wfs) that allows you to create replicas of your system folders and public folders on new Exchange 2003 servers. After the system folders and public folders have replicated, you can use the pfMigrate tool to remove replicas from the source server. Unlike Microsoft Exchange Server version 5.5, you do not need to set a home server for a public folder in Exchange 2003. Any replica acts as the primary replica of the data it holds, and any public folder server can be removed from the replica list. To determine how many folders must be replicated, you can use the pfMigrate tool to generate a report before you replicate folders. To determine whether the folders replicated successfully, you can generate the same report after you replicate folders.

To use the pfMigrate tool, the source server and the target server you specify must be in the same routing group. The pfMigrate tool does not allow you to create replicas of your system folders and public folders across routing groups. This is because, in mixed mode, moving folders across routing groups could prevent e-mail delivery to public folders.

The pfMigrate tool is located in the ExDeploy folder on the Exchange 2003 compact disc (under Support Tools). You can run the tool at the command prompt, either on a server or from the administrative console. For detailed instructions on running the pfMigrate tool, see "How to Run the Public Folder Migration (PFMigrate) Tool" in the Exchange Server 2003 Deployment Guide.

New in SP2: Tracking Public Folder Deletions

In Exchange Server 2003 SP2, you can use diagnostic logging to record events that indicate details associated with the deletion of public folders. The information provided in these events can help you follow up with users or administrators who may be deleting public folders and public folder content that should not be deleted. The logged event includes following information:

• The name of the public folder that was deleted

• The time the public folder was deleted

• The name of the mailbox and Windows user account that deleted the mailbox

By default, events indicating details of public folder deletion are not logged. However, if you set the appropriate logging category to Medium or Maximum, the following event is logged when a public folder is deleted:

• Event Type: Information

• Event Source: MSExchangeIS Public Folder

• Event Category: General

• Event ID: 9682

• Description: Folder <Folder name> with Folder ID <Folder ID> was deleted by <Mailbox name>, <User Account name>.

For information about how to configure Exchange Server to track public folder deletions, see "Track Public Folder Deletions" in the Exchange Server 2003 SP2 online Help.

New in SP2: Manually Stopping and Resuming Public Folder Replication

In Exchange Server 2003 SP2, you can use this feature to stop all public folder content replication in an Exchange Server organization. This feature may be helpful if you need to stop a replication storm. A replication storm occurs when a large amount of data is replicated through the network, typically as a consequence of a change that affects many items or folders. The problem is particularly disruptive when the changes triggering the replication storm are unintended and the network topology includes low bandwidth connections.

When content replication is stopped, you can reconfigure public folder replica lists and replication schedules. After you make changes to minimize the affect of public folder replication, you can restart replication of public folder content. Depending on the size of the public folders that need to replicate and your network infrastructure, you may want to resume public folder replication during non-peak hours.

For information about how to manually stop and resume public folder content replication, see "Manually Stop and Resume Public Folder Content Replication" in the Exchange Server 2003 SP2 online Help.

New in SP2: Synchronizing the Public Folder Hierarchy

In Exchange Server 2003 SP2, you can use the Synchronize Hierarchy command to synchronize the public folder hierarchy in the server you are currently connected to with the rest of the servers in your organization. You may want to synchronize the hierarchy if you notice that the public folder hierarchy on one server looks different from the public folder hierarchy on other servers in your organization.

Synchronizing the hierarchies of your public folder tree does not automatically replicate the contents of the public folders. The replication of content occurs at the intervals you have scheduled. However, you can manually force replication of the content. For information about how to send content from one server to another, see "Send Contents of a Public Folder" in the Exchange Server 2003 SP2 online Help.

For information about how to synchronize the public folder hierarchy, see "Synchronize the Public Folder Hierarchy" in the Exchange Server 2003 SP2 online Help.

New in SP2: Using the Manage Public Folders Settings Wizard

In Exchange Server 2003 SP2, you can use the Manage Public Folders Settings Wizard to manage public folders. The Manage Public Folders Settings Wizard was developed to help Exchange administrators to manage public folder settings. You can perform the following actions with the wizard:

• Modify client permissions   Select this option to make client permissions changes to this folder and all subfolders. For information about adding or removing client permissions for a specific folder only, see "Set Permissions" in the Exchange Server 2003 SP2 online Help.

• Modify lists of replica servers   Select this option to make changes to the list of replica servers. Specifically, you can use this feature to add, remove, or replace replicas for all folders in a public folder subtree. For information about adding or removing an individual replica for a specific folder only, see "Choose Which Folders to Replicate" in the Exchange Server 2003 SP2 online Help.

• Overwrite settings   Select this option to use the settings of the folder that you selected to overwrite the settings of all the folders under it.

For information about how to start the Mange Public Folders Settings Wizard, see "Configure Database Size Limits" in the Exchange Server 2003 SP2 online Help.

New in SP2: Moving Public Folder Content to a Different Server

In Exchange Server 2003 SP2, you can use the Move All Replicas command to move all public folder content from a public store to a different server using a single command. This command is helpful if you need to uninstall Exchange Server 2003 from a server; you cannot uninstall Exchange Server 2003 from a server than contains any public folder replicas. For information about how to remove a server running Exchange Server 2003 from your organization, see "Remove a Server" in the Exchange Server 2003 SP2 online Help.

For information about how to move all public folder content from a public folder store, see "Move All Public Folders from a Public Folder Store" in the Exchange Server 2003 SP2 online Help.

Mailbox Recovery Center

Using the new Mailbox Recovery Center, you can simultaneously perform recovery or export operations on multiple disconnected mailboxes. This is a significant improvement over Exchange 2000 Server, where such operations had to be performed individually on each disconnected mailbox (a disconnected mailbox is a mailbox that is not associated with a user in Active Directory, usually because the user has been deleted). Use Mailbox Recovery Center to recover one or more mailboxes on one or more mailbox stores. You can export the mailbox properties, and you can associate the mailboxes with users in Active Directory and reconnect the mailboxes. For detailed instructions, see "How to Recover One or More Mailboxes on One or More Mailbox Stores" in the Exchange Server 2003 Administration Guide.

For detailed instructions, see:

• How to Specify a Mailbox Store to Work with if You Are Running Exchange System Manager on Windows 2000 Server

• How to Specify a Mailbox Store to Work with if You Are Running Exchange System Manager on Windows Server 2003

• How to Specify a Mailbox Store to Remove if You Are Running Exchange System Manager on Windows 2000 Server

• How to Specify a Mailbox Store to Remove if You Are Running Exchange System Manager on Windows Server 2003

Improved Message Tracking

Exchange 2003 enhances message-tracking capabilities in two ways:

• When using Exchange System Manager, you have greater control over your message tracking log files. Exchange 2003 automatically creates a shared directory to the message tracking logs and allows you to change the location of the message tracking logs.

• You can now track messages after categorization (which is the phase where users are located and distribution groups are expanded into individual recipients) and during the routing process.

Enhanced Control of Message Tracking Logs in Exchange System Manager

To provide flexibility when viewing and managing message tracking logs, Exchange 2003 allows you to use Exchange System Manager to change the location of your message tracking logs.

Exchange 2003, like Exchange 2000, uses the format \\<server name>\<server name>.log to automatically create a path to a shared folder for message tracking. The individual message log file names are date specific, using the format YYYYMMDD. For example, 20021022.log is the log file for October 22, 2002. Ensure that any users who you want to monitor the log files have remote access to this share.

In Exchange 2003, you can use Exchange System Manager to move your message tracking logs. You no longer need to use directory modification tools to change the location of your message tracking logs on a server. For detailed instructions on changing the file location of the message tracking logs on an Exchange server, see "How to Select a Location for the Message Tracking Log Files" in the Exchange Server 2003 Administration Guide.

Enhanced Message Tracking Capabilities

In Exchange 2003, you can now track a message beyond the categorization phase. Categorization is the phase during which the recipient address is verified in Active Directory and its route is determined. You can now track the message through post-categorization and during the routing process. For detailed instructions, see How to Track a Message.

Including Bcc Recipients in Archived Messages

When you enable archiving on a mailbox store, a copy of all messages sent or received by mailboxes on this store is sent to the mailbox you specify for archiving. In previous versions of Exchange, any recipients on the Bcc line were not archived. In Exchange Server 2003, you can enable a registry key to configure mailbox store archiving to include Bcc recipients. When you enable archiving to include the Bcc recipients, all message recipients are listed on the Bcc list (not just those on the Bcc line).

To include Bcc recipients in archived messages, perform the following steps:

1. Enable archiving on the mailbox store. For detailed instructions, see "How to Enable Standard Journaling" in Journaling with Exchange Server 2003.

2. Set the registry key on each server for which you want archiving to include Bcc recipients. For detailed instructions, see How to Enable Bcc Recipient Archiving on a Mailbox Store.

3. On each server that you set the registry key, restart the following services. For detailed instructions, see How to Restart the Necessary Services to Enable Bcc Recipients in Archived Messages.