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. . . .
Register
