Object Rehome first runs in scan mode on the Exchange 5.5 source site. It searches AD (because the site-based objects are already replicated to AD), not the Exchange 5.5 Directory Service (DS). In scan mode, Object Rehome creates a list of custom recipients and DLs that are homed in the site, then writes the list to an .xml file (ToBeMoved.xml, which is located in the ExProfre log file directory by default) that you can review and edit. (Always be careful when editing raw XML data. Any errors you make will have unexpected consequences, which I discuss later.) Web Figure 2 shows the Exchange Server Deployment (ExDeploy) toolset executing the Object Rehome tool in scan mode and finding four objects that need to be rehomed. (The new crosssite.dll file, which was in the directory listing before the command was executed, contains a lot of the logic that performs crossadministrative group updates for custom recipients, DLs, and mailboxes.)
Next, Object Rehome runs in update mode, during which time it sequentially processes the entries that are specified in the ToBeMoved.xml file. For each file entry, the corresponding AD object is updated and the original legacyExchangeDN value is replaced with a value that's appropriate for the new administrative group. Similarly, if the object is a DL and you specified a DL expansion server, the value will be replaced with a specified expansion server in the target administrative group. Figure 1 shows the contents of a ToBeMoved.xml file.
The Object Rehome syntax is
Exdeploy.exe /M:<objectype>
/MA:<moveaction>
/SS:<sourcesite>
/TS:<targetsite>
/ES:<expansionserver>
/p:<filename>
with the following command-line qualifiers:
- /M--directs a crossadministrative group move to take place. You need to specify the object types to be scanned, either C for custom recipients, D for DLs, or CD for both. This qualifier is mandatory.
- /MA--the action type, either S for scan mode or U for update mode. Both can be specified at the same time to complete the process in one command. If this qualifier is omitted, a scan action is performed by default.
- /SS--the source site's name. This qualifier is mandatory.
- /TS--the name of the target administrative group, which has to be different from the source site and can't be a pure Exchange 5.5 site. This qualifier is mandatory in update mode only.
- /ES--the DL expansion server that you assigned to the DL objects you're moving. This value has to be an Exchange server in the target administrative group. This qualifier is mandatory if DLs are being rehomed.
- /p--the file to be processed in update mode. This qualifier can't be used in scan mode.
As Object Rehome processes each file entry, it performs several tests. It verifies the Distinguished Name (DN) of each object to ensure that the object is a valid AD object and verifies the object class to make sure that the object class is the same as the corresponding object in the AD. Object Rehome compares the entry's legacyExchangeDN value with the AD object's legacyExchangeDN value and compares the expansion server attribute with the msExchExpansionServer attribute of the corresponding AD object. (These attributes can have mismatching values if you made incorrect changes to the ToBeMoved.xml file.) Finally, Object Rehome ensures that the homeMDB attribute of the corresponding AD object is null. If it isn't, the object that's being processed could be a mailbox--not a custom recipient or a DL. Only when all the tests are successfully finished does Object Rehome modify the settings on the AD object and rehome the custom recipients and DLs.
Object Rehome also processes custom recipients and DLs and makes several changes to the existing Exchange 5.5 object. First, Object Rehome hides the object from the Exchange 5.5 Global Address List (GAL) and disconnects the object from its ADC-created partner by modifying the ADCGlobalNames attribute to set the NM_MOVED_CROSS_SITE bit. The alias is then set to a globally unique identifier (GUID) value, and the existing proxy addresses are replaced with two new values: X500:ADCDoNotReplicate and X500:ADCDeleteWhenUnlinked. As a result, if the corresponding ADC-created objects change, those changes won't propagate back to the original Exchange 5.5 objects. Instead, Object Rehome will create new objects in the Exchange 5.5 DS, ensuring that the legacy object isn't deleted from any other DLs before the ADC has an opportunity to synchronize the modified AD object with the Exchange 5.5 DS by using the new legacyExchangeDN information and the original legacyExchangeDN as an alias.
Similarly, on the AD side, the ADCGlobalNames attribute of each rehomed object is modified to signal that it's been moved across administrative groups (i.e., the NM_MOVED_CROSS_SITE bit is set), a new legacyExchangeDN is set to reflect the new administrative group in which it's now homed, the old legacyExchangeDN is set as an X.500 proxy address, and the object's member-of attribute is enumerated to determine the groups of which the object is a member. For each of these groups, the group's replicatedObjectVersion attribute is incremented to ensure that it back-replicates to Exchange 5.5 with the updated membership.
When Object Rehome performs an update operation, it tries to discover a Site Replication Service (SRS) in the source Exchange 5.5 site so that it can write the above changes to the Exchange 5.5 DS objects. If no such SRS exists, you have to specify an explicit Exchange 5.5 server on which you've enabled Lightweight Directory Access Protocol (LDAP) access. Next, add the ExDeploy command-line option
/s:<Exchange 5.5 server>:<LDAP port>
where Exchange 5.5 server is the name of an Exchange 5.5 server in the source site and LDAP port is the optional port number for LDAP access on that server. If you don't specify a port, Object Rehome uses the default port number 389.
You could optionally specify a GC server for the scan and update modes by using the ExDeploy command-line option
/gc:<GC server>
where GC server is the name of the GC server that you want to specify. Web Figure 3 shows Object Rehome running in combination scan and update mode with the Exchange 5.5 server explicitly specified and a successful rehoming of the custom recipients and DLs.
You need to run the ADC connection agreements (CAs) frequently (to do so, set the schedule to Always) so that the rehomed objects are processed quickly and the hidden legacy objects are deleted as soon as possible. Cleanup processing can take as long as 12 hours unless you stop and start the ADC service shortly after the rehome operation finishes and the initial ADC back-synchronization has taken place.
Preparation Is Crucial
Moving mailboxes from an Exchange 5.5 server in one site to a new Exchange 2003 SP1 server in another administrative group is relatively straightforward, but a lot of activity takes place behind the scenes to ensure a smooth operation and data integrity. Although the process is primarily automatic, you do need to make adjustments to the client, especially when it comes to processing OAB and OST files. Although client disruption might seem minimal, you'll probably end up with a surge of network traffic as new OAB and OST files are downloaded to the newly moved clients, especially if you move from ANSI mode to Unicode mode. For these reasons, planning and scheduling are crucial to your success when you contemplate crossadministrative group mailbox moves.
End of Article
Prev. page
1
2
[3]
next page -->
