Important Considerations for Site Consolidation in Mixed Mode

Important Considerations for Site C...

Exchange Server 2003

Topic Last Modified: 2006-08-16

Before you consider consolidating remote Microsoft® Exchange sites, you should be familiar with the following recommendations and prerequisites for consolidating sites, as well as the issues that can occur both during and after site consolidation:

Upgrade client computers to Microsoft Office Outlook® 2003 Before you consolidate sites, upgrade client computers in the remote site to Outlook 2003 and turn on Cached Exchange Mode. Cached Exchange Mode is an important component of site consolidation because remote users can work from their local cache with or without a network connection. Upgrading Outlook on client computers and turning on Cached Exchange Mode creates a local copy of a user's mailbox. By creating the local copy before you move mailboxes, you avoid the heavy download traffic that results from waiting until after you move mailboxes out of the local site. This strategy is particularly useful in cases where the network bandwidth between the remote site and the central site is limited. Although client computers with earlier versions of Outlook and other e-mail applications are supported, these client computers cannot take advantage of Cached Exchange Mode. Also, to help minimize support issues, you should plan to incorporate Outlook 2003 end-user training and preparation into the upgrade process.
Upgrade ADC to Exchange 2003 SP1 Use the Exchange 2003 SP1 version of Active Directory Connector (ADC), which contains new functionality that cleans up objects and distribution lists after site consolidation. When you move mailboxes across sites, ADC updates user objects and all of the distribution groups to which the users belong; as a result, changes are replicated between directories and users can continue to receive mail.

Consolidate Microsoft Windows® domains if possible To avoid problems with setting delegates, publishing Key Management Service certificates, and updating groups through Outlook, it is recommended that you consolidate the remote Windows domains and the Exchange mailboxes simultaneously. The Microsoft Active Directory® directory service requires that Outlook use a global catalog server that is located in the same domain as the object that Outlook is attempting to update. In the example of delegating mailbox access, if a user whose user object is located in the remote domain logs onto Outlook in the central domain, the user cannot set delegates. This is because Outlook is directed to the central domain, but the user objects are located in the remote domain. The global catalog server in the central domain contains a read-only copy of directory objects residing in other domains. If you cannot consolidate Exchange and Windows domains simultaneously, you can configure the following registry key on the Outlook client to use a global catalog server in the central domain where the directory objects are located:

Location:	HKEY_CURRENT_USER\Software\Microsoft\Exchange \Exchange Provider
Name:	DS Server
Type:	REG_SZ (string)
Value:	<fully qualified domain name of the global catalog server>

Apply the Directory Service/Information Store (DS/IS) consistency adjuster hotfix and use the adjuster to retain access to Exchange 5.5 public folders If you move users and groups to the central site before you move Exchange 5.5 public folders, the public folder access control lists (ACLs) will be incorrect and users will not be able to access public folders. There are two options for avoiding this problem:

Option 1: After you move users and groups you can run the DS/IS consistency adjuster to update the public folder ACLs with the new user and group information.

Option 2: You can replicate public folders to the central site first, and then move users and groups. Also, make sure that public folder referrals are enabled across the connectors.

Note:
Before you begin consolidating Exchange 5.5 sites, apply the hotfix for the Exchange 5.5 DS/IS consistency adjuster (available at http://go.microsoft.com/fwlink/?linkid=3052&kbid=836489) to all of your Exchange 5.5 public folder servers. This hotfix ensures that, after a cross-site move, public folder ACLs are updated properly so users and groups have continued access to public folders.

Plan for a full offline address book download Before you move multiple mailboxes across sites, you should determine whether you have enough bandwidth to support a full download of the offline address book for all Outlook client computers at all remote sites. For more information about why a full download of the offline address book occurs, see "Offline Address Book Download" later in this topic.
Update Outlook profiles after moving mailboxes After you move mailboxes across administrative groups, you must update Outlook profiles so that users can log onto the relocated mailboxes. The Exchange Profile Update tool (Exprofre.exe) is a command-line tool that you run on client computers to update users' Outlook profiles automatically. Exprofre.exe modifies the default Outlook profile so users can successfully log onto their mailboxes after the move. This tool is available from the Exchange Server 2003 Tools and Updates Web site (http://go.microsoft.com/fwlink/?linkid=21316).

Offline Address Book Download

Outlook client computers that use Cached Exchange Mode require an offline address book to resolve e-mail addresses. The offline address book is stored on a public folder server. A full download of the offline address book occurs in the following situations:

When you consolidate a site, all users at that site who use Cached Exchange Mode and whose mailboxes have moved will receive a full download of the offline address book. This download occurs the first time these users start Outlook after the mailbox move.
When a significant number of directory changes occur (for example, when you move large numbers of mailboxes across sites or when you make changes to the Exchange topology), all users at all sites who use Cached Exchange Mode receive a full download of the offline address book.

For more information about the impact of full offline address book downloads and the situations in which they occur, see Microsoft Knowledge Base article 839826 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839826).

Note:
Depending on the address book size and the available bandwidth and latency of connections to remote sites, full offline address book downloads can be a limiting factor for your organization.

This substantial download could cause performance issues for both your network and for Outlook. When determining the duration of the offline address book download, consider the bandwidth of network connections to all remote sites, the amount of data that must be transferred, and the latency of the network connection. You can estimate the amount of data to be transferred by multiplying the size of the offline address book by the number of users in the remote site.

Note:
Example: If the offline address book is 20 MB and there are twenty-five Outlook users using Cached Exchange Mode, the estimated amount of data that needs to be replicated is 500 MB: (20 MB offline address book × 25 users = 500 MB).

Network latency is the amount of time it takes for data to transfer from one point to another in the network. Latency is a factor in determining how quickly the network connection becomes saturated. With long latency, the rate of data transfer is slower, which means it takes longer for the network connection to become saturated. Conversely, a shorter latency means that data flows more quickly, thereby increasing the likelihood that the connection will become saturated if many clients are downloading the offline address book simultaneously.

Before you move multiple mailboxes across sites, you should determine whether you have enough bandwidth to support a full download of the offline address book for all Outlook users at the remote site. You should also assess the impact of the download on your network by factoring in the amount of data to be moved and the network latency.

Free and Busy Functionality

When your organization is in mixed mode, and you use the Move Mailbox Wizard to move mailboxes across sites, the Move Mailbox Wizard updates the corresponding user objects with the new legacyExchangeDN attribute. Because the wizard updates the legacyExchangeDN attribute, you do not need to move free and busy system folders. Users' free and busy data is republished using the new legacyExchangeDN attribute after the user logs onto the new mailbox.

Note:
Free and busy data is not transferred to the new server immediately after you move mailboxes across sites. Instead, the data is posted to the new server fifteen minutes after the user logs onto the mailbox or performs a calendar action (such as creating or accepting a meeting request).

Known Limitations with the Site Consolidation Process

This section describes known limitations for site consolidation. The site consolidation process is affected by a variety of factors, such as the order in which you perform steps, the time it takes for directory information to replicate, and the time it takes for Exchange data to replicate between sites. In addition, other mail features can be affected by moving mailboxes and users between sites. You should familiarize yourself with all of the known issues listed here before you begin planning for site consolidation.

Network traffic will increase when moving mailboxes When moving mailboxes across sites, you should plan for additional network traffic between the sites. The additional traffic is equal to the combined sizes of the mailboxes you plan to move.
Directory replication traffic will increase When moving mailboxes from Exchange 5.5 sites to a central Exchange site, you can expect increased directory replication traffic while ADC updates users and distribution groups and removes old objects in the remote site. The duration of this process depends on the size of your environment, the replication speed among your Exchange 5.5 sites, and the replication speed between Exchange 5.5 and Active Directory. By default, directory cleanup runs every twelve hours. In small environments, directory cleanup may complete during the next automatic replication session; however, large environments may require more than one session.

Important:
To expedite directory cleanup, you can initiate replication in Active Directory Connector Manager and the Exchange 5.5 administrator program.
Public folder replication traffic will increase When you use the Exchange Public Folder Migration tool (pfMigrate) to move public folders to the central site, you can expect increased traffic while the public folder hierarchy is updated and public folder content replicates across sites. The pfMigrate tool and the DS/IS consistency adjuster cause increased replication traffic.
Cached offline folder files that are in ANSI format are not automatically re-created in Unicode format after you move Microsoft Exchange Server 5.5 mailboxes Users’ cached offline folder (.ost) files and offline Address Book (.oab) files remain in ANSI format after you move Exchange Server 5.5 mailboxes to a computer that is running Exchange Server 2003 or Microsoft Exchange 2000 Server. A cached offline folder (.ost) file in ANSI format has a 2 GB size limit, and because this file is in ANSI format, the offline Address Book file also uses ANSI format. Additionally, the resolution offered in Knowledge Base article 841207 requires a full download of the offline address book to all of the affected client computers. This download can significantly increase network traffic.
For more information about and a resolution for cached offline folder files being created in ANSI format instead of in Unicode format in Exchange 2003 or in Exchange 2000, see Knowledge Base article 841207 "An Outlook 2003 cached offline folder file is created in ANSI format instead of in Unicode format in Exchange 2003 or in Exchange 2000" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=841207).
For more information about using Unicode with Outlook 2003, see Configuring Unicode Options for Outlook 2003 (http://go.microsoft.com/fwlink/?LinkId=33526).
Delegates may lose access To retain delegate access in Outlook, move managers and their delegates from the remote Exchange 5.5 site to the central site together. If it is not possible to move them together, move the manager before the delegate or re-grant access rights to the delegate after the move.
Journal recipients need to be re-designated A journal recipient is a user who is configured to receive all archived messages for a mailbox store. Before you move the journal recipient across sites, assign the journal recipient designation to a different user. After the move, you can re-designate the user as the journal recipient.
Inbox rules may not function If a user's mailbox does not reside on an Exchange 2003 SP1 server, any Inbox rules based on other users who have moved across sites will not function because the legacyExchangeDN attribute for the users who have moved is changed. However, the user can re-create the rules. If the user's mailbox resides on an Exchange 2003 SP1 server, rules will continue to function. This issue does not affect users whose mailboxes have moved; it only affects users who have rules based on users who have moved. After all users' mailboxes are hosted on Exchange 2003 SP1 servers, rules will function again.
User names may be briefly absent from the Exchange 5.5 GAL In Exchange 5.5, user names that have moved across sites may disappear from the global address list (GAL) for a short period of time until directory replication is complete. During this time, the original Exchange 5.5 object in the remote site is hidden while the new Exchange 5.5 object is replicated to the new site. The Exchange 2003 GAL is unaffected.

Important:
To expedite directory cleanup, you can initiate replication in Active Directory Connector Manager and the Exchange 5.5 administrator program.

Some users may receive non-delivery reports after migration After you move mailboxes from Exchange 5.5 to the central site, if Exchange 5.5 users who have not been moved reply to mail from Exchange 5.5 users who have been moved, they will receive a non-delivery report (NDR). This situation will continue until Exchange 5.5 directory replication is complete. To avoid this situation, you can force replication by selecting Replicate now in ADC Manager. Another option is to redirect Exchange 5.5 mail through an Exchange 2000 or Exchange 2003 bridgehead server because these servers are able to forward mail to the new mailbox.

Note:
To eliminate NDRs, remove site connectors between Exchange 5.5 sites and create connectors to the central site so that all mail is routed through the central site or through an Exchange 2003 server.

An authorized user must perform a calendar action to repost free and busy data for resource mailboxes Free and busy data is not transferred to the new server when you move mailboxes across sites. For users, free and busy data is posted to the new servers fifteen minutes after the user logs onto the mailbox or performs a calendar action (such as creating or accepting a meeting request). However, for resource mailboxes (such as meeting rooms), someone with access to the resource mailbox must open the mailbox and perform a calendar action to repost the free and busy information.
Key Management Service requires export of certificates Key Management Service continues to function after a cross-site move if you are using X.509 v3 certificates, but not if you are using v1 certificates. With v1 certificates, users who were moved across sites can decrypt old mail, but they cannot sign or encrypt new mail. If you are using Key Management Service, before you move users across sites, export your certificates, even if the same Key Management Service server provides service to the central site. After the move, import the certificates to the central site's Key Management Service server. Run the Exchange Profile Update tool (Exprofre.exe) after the move.
Exchange Conferencing Server requires a switch to native mode If you are running Exchange Conferencing Server, you should first switch to Exchange native move and then consolidate sites. Following this path avoids problems with the legacyExchangeDN attributes and ensures continued functionality of Exchange Conferencing Server.