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.