Demystifying Exchange 2003 Mailbox Moves

Exchange Server 2003 Service Pack 1 (SP1) introduces new site-consolidation functionality that uses the Move Mailbox Wizard to move (or migrate) mailboxes between Exchange servers that are located on different sites or administrative group/routing group pairs while the Exchange organization is in mixed mode. Although this functionality is new, Exchange 2003 and Exchange 2000 Server support mailbox moves between servers in different administrative groups if the Exchange organization is in native mode.

This site-consolidation feature might seem like a minor enhancement, albeit of great use and importance during consolidation and migration exercises, but don't underestimate its complexity. Let's look at the prerequisites, processes, and behind-the-scenes activity associated with cross-administrative group mailbox moves. In the interests of brevity, I'll deal exclusively with mailbox migrations and their effect on distribution lists (DLs) in cross- administrative group scenarios. In a future article, I'll discuss the considerations for moving DLs, Contacts, and Outlook client profiles.

Mailbox-Move Requirements
Before you can perform cross-administrative group mailbox migrations, you need to perform several steps, either manually or by following the guidelines defined in the new Exchange 2003 SP1 Exchange Server Deployment Tools (ExDeploy), which Figure 1 shows. (You can download the most recent version of ExDeploy from http://www.microsoft.com/exchange/downloads/2003.asp, or you can find the tools on the Exchange 2003 CD-ROM.) ExDeploy is a set of compiled Help files that guides you through the Exchange 2003 installation and migration process. First, you need to deploy at least one Exchange 2003 server in the organization, which you can do by using the Deploy the first Exchange 2003 server ExDeploy option. You need to deploy this Exchange 2003 server before you select the Consolidate Sites in Exchange Mixed Mode ExDeploy option.

When you move Exchange Server 5.5 mailboxes across administrative group boundaries, the target server must be running Exchange 2003 SP1 because other versions of Exchange don't support this scenario. However, other Exchange versions can exist in the target administrative group as long as you don't try to move mailboxes onto those servers. You can relocate mailboxes from the target Exchange 2003 SP1 server to any other server in the same administrative group at a later time. You don't need specific Exchange versions later than Exchange 5.5 SP3 in the source administrative groups.

You also need to upgrade Exchange 2003 Active Directory Connector (ADC) servers to use the ADC that ships with Exchange 2003 SP1 before attempting any cross-administrative group mailbox moves. If you don't, the Microsoft Management Console (MMC) Exchange System Manager (ESM) snap-in prevents any such moves. I discuss this particular requirement in more detail later.

As with any migration, two-way connection agreements (CAs) must exist for every Exchange 5.5 site; this requirement is especially important for cross-administrative group mailbox moves. After you move a mailbox between administrative groups, the ADC performs cleanup processing to adjust the DL contents and old stub (hidden) mailboxes. Stub mailboxes are retained in the source administrative group until you purge all references to them throughout the organization. I'll discuss this cleanup process in more detail later.

If your Exchange organization is in mixed mode but you don't have any Exchange 5.5 servers in the organization, any attempt to perform a cross-administrative group mailbox move will fail and you'll be instructed to switch your Exchange organization to native mode to perform a more conventional mailbox move. Native-mode moves are more straightforward than mixed-mode moves because problems with the legacyExchangeDN attribute don't arise in native-mode moves.

You need to apply a hotfix for the Directory Service/Information Store (DS/IS) consistency adjuster on all Exchange 5.5 public folder servers in the Exchange organization before you can migrate mailboxes or DLs between administrative groups. The hotfix is required because ACLs on a public folder can become invalid following a cross-administrative group mailbox-move operation since the distinguished name (DN) associated with the mailbox changes during such a move. If the hotfix isn't applied, the DS/IS consistency adjuster removes entries in the ACL that don't correspond to a valid mailbox. However, after the hotfix is applied, the DS/IS consistency adjuster also checks the X.500 proxy addresses of objects in the Exchange 5.5 DS for a match, which maintains the integrity of the ACL because a cross-administrative group mailbox move adds an X.500 proxy that matches the previous DN of the Exchange 5.5 object. (For more information about this hotfix, see the Microsoft article "An update is required for mixed-mode site consolidation with Exchange Server 5.5" at http://support.microsoft.com/?kbid=836489.)

After you install the hotfix, wait a few minutes so that replication can occur before you try to move any mailboxes. I tried to perform a cross-administrative group mailbox move immediately after installing the hotfix, and I received the error message that Figure 2 shows. As a best practice, apply the hotfix several days in advance of your first planned cross- administrative group mailbox move, especially for Exchange organizations that are distributed across a wide area.

Mailbox-Move Required Permissions
Certain administrative permissions are required for the account that you use to perform cross-administrative group mailbox moves. When the wizard moves a mailbox, it needs to create the target mailbox, log on to the source mailbox, and copy messages from the source to the target. To modify user Active Directory (AD) attributes to indicate that the mailbox has been moved, you must ensure that the administrative account has the following permissions:

• Account Operator permissions
• Exchange Administrator permissions for source and target administrative groups or, if the source server is in an Exchange 5.5-only site, Administrator permissions on the Exchange 5.5 site
• Member permissions for the administrators group on the local system to create a temporary Messaging API (MAPI) profile
• Exchange 5.5 Directory Administrator permissions in the source Exchange 5.5 site to update objects in the Exchange 5.5 DS
• Read permissions for the source Exchange 5.5 DS to make sure that the DS/IS consistency adjuster patch is installed on all Exchange 5.5 public folder servers

Mailbox-Move Preparation
Before you start any mailbox migrations, consider the possibility that a significant amount of directory replication might take place as you move mailboxes between sites and administrative groups. Various mailbox attributes will change (I discuss these changes later), which causes Exchange 5.5 intersite replication as well as replication across the ADC. You need to address three best-practices areas when you perform such mailbox migrations. First, perform the migrations after office hours and make sure that you have a sufficient maintenance window for the subsequent replication that will follow the actual mailbox-content move. Second, modify the replication schedule on your Exchange 5.5 directory replication connectors (DRCs) and ADC CAs to a frequent replication setting (or, preferably, Always). This modification reduces latency and means that modified mailbox information that reflects the mailbox migrations is quickly replicated throughout the entire organization. Third, make sure that you have sufficient free space on the source and target database disk volumes, especially the transaction log volumes, because they can quickly fill up as many hundreds of megabytes of user data are written to the data store. Database volumes are less prone to exceed disk space unless you move many large mailboxes. Backing up your servers and purging the log files before starting a large mailbox move is always a good idea, especially when you haven't recently performed a backup.

Another best practice is to replicate public folders from the Exchange 5.5 environment to an Exchange 2003 (or at least an Exchange 2000) server to ensure that users who are migrated from Exchange 5.5 via cross-administrative group moves can access ACL-secured public folders. Exchange 5.5 public folder ACLs use the DN of an Exchange 5.5 mailbox, but this DN changes as users are moved between administrative groups; the legacy
ExchangeDN attribute is based on the new administrative group, not the old site. However, an Exchange 2003 or Exchange 2000 public folder ACL will reestablish access to native Exchange 2003 or Exchange 2000 public folders because old DN values are added as X.500 proxy addresses; Exchange 5.5 public folders can't reestablish this relationship.

The Migration Process Under the Hood
To perform cross-administrative group mailbox moves, you need to use an account (with suitable permissions as I stated earlier) and the Exchange 2003 SP1 ESM snap-in or MMC Active Directory Users and Computers snap-in from a system on which you've installed at least the Exchange 2003 SP1 administrative tools. You can't use an earlier version of the snap-ins if you want to perform a cross-administrative group mailbox move. The initial Move Mailbox Wizard interface that Figure 3 shows lets you perform cross- administrative group mailbox moves.

The options and features associated with cross-administrative group mailbox moves are the same as those associated with the conventional use of the same-administrative group Move Mailbox Wizard: multiuser selection, as many as four processing threads per Move Mailbox Wizard instance, scheduling, and error handling. (For more information about the wizard, see "The Exchange 2003 Move Mailbox Wizard," February 2004, InstantDoc ID 41023.) When the cross-administrative group mailbox-move operation begins, the wizard performs the following steps:

• creates a new mailbox in the target administrative group and moves the mailbox contents from the source mailbox to the target mailbox
• updates the source mailbox in the following ways:
• deletes the source mailbox from the Exchange 5.5 Information Store (IS) but retains the entry for the source mailbox in the Exchange 5.5 DS as the stub mailbox, which is then hidden from the Exchange 5.5 DS
• updates the Exchange 5.5 mailbox Home-MDB and Home-MTA attributes so that they point to the new Exchange 2003 SP1 mailbox
• updates the ADCGlobalNames attribute on the Exchange 5.5 object; the NT5 value changes as the NM_MOVED_CROSS_SITE bit is set
• updates the alias attribute from its original value to a new unique value based on a globally unique identifier (GUID); in my test environment, the alias attribute became \{5DF645FF-D38F-4CD5-99D9-BD973F11DE2A\}
• removes and regenerates all existing proxy addresses based on the new alias value
• adds two additional X.500 proxy addresses--X500:ADCDoNotReplicate and X500:ADCDeleteWhenUnlinked--to the stub mailbox

At this point, the old source Exchange 5.5 DS entry must remain in place but is hidden from view. If the stub mailbox is deleted now, immediately after the cross-administrative group move Exchange will update any Exchange 5.5 DLs of which the stub mailbox was a member and the membership will be lost on the Exchange 5.5 side. Keeping the stub mailbox in place means that Exchange can deliver to the new mailbox mail sent to any such DLs because the stub mailbox DN is still valid in the DL membership list and the mailbox's Home-MDB and Home-MTA attributes now point to the correct location.

Before any cross-administrative group mailbox migration, the ADC will associate the source Exchange 5.5 mailbox with an object in the AD, probably just before the first Exchange 2003 server is installed in the organization. During the cross- administrative group mailbox move, the new Move Mailbox Wizard disassociates the stub Exchange 5.5 mailbox from its AD counterpart. This action has two parts. I've already described what happens to the stub mailbox: Its ADCGlobalNames attribute is updated with a new bitmask that's applied to the NT5 value. Figure 4 shows how the two values differ before and after the cross-administrative group move.

Exchange also updates the corresponding ADC-created object's msExchADCGlobalNames attribute; in this case, Exchange updates the EX5 value with the value NM_MOVED_CROSS_SITE bit set. This disassociation means that you can delete the stub mailbox later in the process without deleting the corresponding AD object.

When the ADCGlobalNames attribute is updated on the stub mailbox, the new Exchange 2003 SP1 ADC ignores this stub mailbox during subsequent processing, so you don't have to worry about the stub mailbox replicating in AD and creating a duplicate object. Unfortunately, the ADCGlobalNames attribute doesn't replicate between Exchange 5.5 sites; thus a CA with an endpoint in another Exchange 5.5 site might come upon the stub mailbox and attempt to replicate it to AD, causing a duplicate AD object. To counter this action, the ADC writes the ADCDoNotReplicate value to the stub mailbox as a proxy address. The ADC replicates the Proxy-Addresses attribute to Exchange 5.5 sites, and new functionality in the Exchange 2003 SP1 ADC detects this proxy address value and ignores the stub mailbox.

Another scenario might arise. When the ADC deletes the stub mailbox and a CA in another site picks up the deletion without the ADCDoNotReplicate flag, the CA might try to delete the corresponding AD object. If the CA endpoint specified an AD domain controller (DC) that wasn't yet updated with the new msExchADCGlobalNames bitmask value of NM_MOVED_CROSS_SITE, the CA would consider these two objects to still be associated and would delete the AD object. Again, the replication of the ADCDoNotReplicate value prevents this deletion. Figure 5 shows the updated values on the Proxy-Addresses attribute. The Move Mailbox wizard makes the following modifications to the ADC-created object:

• updates the msExchADCGlobalNames attribute and applies the NM_MOVED_CROSS_SITE bitmask to the EX5 value
• updates the legacyExchangeDN attribute with a new value based on the new administrative group in which the mailbox now resides
• updates the msExchHomeServerName, homeMDB, and homeMTA attributes to reflect the new location of the mailbox
• adds the previous value of the legacyExchangeDN attribute as an X.500 proxy address
• examines the memberOf attribute to identify any Universal Distribution Groups (UDGs) of which the mailbox is a member and for every identified UDG, increments the UDG's replicatedObjectVersion attribute, causing the UDG to be replicated back to Exchange 5.5 DS

When the cross-administrative group mailbox move is finished, a short period follows when the ADC hides the stub mailbox and a new Exchange 5.5 DS object doesn't exist in the Exchange 5.5 site to point to the Exchange 2003 server onto which the mailbox has moved. Only when the CA associated with this destination site runs does the ADC create a new object in the Exchange 5.5 DS to represent the new Exchange 2003 mailbox. However, at no time does the AD object disappear.

Dealing with DL Updates
After cross-site moves, the ADC must ensure that any affected Distribution Groups (DGs) contain the correct membership. The membership integrity of a UDG in the AD is unaffected by a cross-administrative group mailbox move because UDG membership is maintained with a DN value that's associated with the ADC-created object in the AD. The DN of this ADC-created object never changes with a cross- administrative group move. Exchange 5.5 DLs, on the other hand, also maintain their memberships with Exchange 5.5 DNs, but because these DNs reference the Exchange 5.5 site in which the object is located and the DN changes when a mailbox is moved via a cross-administrative group move, the DL's integrity is compromised if the stub mailbox is deleted--a step that must ultimately take place.

For the ADC to delete the stub mailbox, it needs to update the Exchange 5.5 DL and replace the stub mailbox DNs with the new DNs that are associated with the new mailbox object in the target Exchange 5.5 site. This update happens the first time the ADC runs after a cross-administrative group mailbox move. Because the Move Mailbox Wizard incremented the replicatedObjectVersion attribute of all relevant UDGs during the move operation, the ADC rereplicates these UDGs back to Exchange 5.5. New code in the Exchange 2003 SP1 ADC checks the membership of existing Exchange 5.5 DLs and replaces any stub mailbox Exchange 5.5 DNs with the new Exchange 5.5 DN that's associated with the newly created Exchange 5.5 mailbox object. The ADC can easily determine the replacement DN value because the AD user object has the old Exchange 5.5 DN as an X.500 proxy address and the new replacement DN is defined in the legacyExchangeDN attribute.

As Exchange updates the Exchange 5.5 DL with the new DNs, the ADC updates the AD record of the stub mailbox to remove the DL's DN from its memberOf attribute. When a stub mailbox has no further entries in the memberOf attribute, the ADC removes the stub mailbox from the source Exchange 5.5 site.

DL and stub-mailbox cleanup takes place by default every 12 hours. You can accelerate the process by stopping and restarting the ADC process from Start\Programs\Administrative Tools\Services.

A Sophisticated Process
On the surface, cross-administrative group mailbox moves seem straightforward, but the process is actually quite sophisticated. Under most circumstances, you shouldn't need to be concerned with the internal process, although knowing how and when it happens is useful information. The ADC operation is crucial, and minimizing latency in terms of Exchange 5.5 intersite replication and ADC replication is key to maintaining a painless migration or consolidation process. In a future article, I'll discuss some aspects of cross-administrative group moves that are related to DLs and custom recipients.