In "Demystifying Exchange 2003 Mailbox Moves," September 2004, InstantDoc ID 43146, I discuss moving mailboxes and the impact of crossadministrative group moves on distribution lists (DLs). These moves are the specialty of Exchange Server 2003 Service Pack 1 (SP1), but other important considerations exist. You also need to learn how to deal with Microsoft Office Outlook 2003 Messaging API (MAPI) profiles and how Exchange 2003 handles custom recipients and DLs that are homed in an Exchange Server 5.5 site that you want to decommission. Let's take a look at these other important aspects of crossadministrative group mailbox moves.
Outlook MAPI profiles provide important configuration information that lets Outlook connect to specific Exchange servers and access user mailboxes. MAPI profile information is bound to a specific Exchange server in a particular site or administrative group. If the Exchange organization is in mixed mode when you move a mailbox from one Exchange server to another and if both servers reside in the same site or administrative group, Exchange automatically updates the MAPI profile. First, the Outlook client connects to the old Exchange server, which updates the MAPI profile to permanently redirect the Outlook client to the new target server. If your Exchange organization is in mixed mode and you move a mailbox from an Exchange server in one site or administrative group to an Exchange server in another site or administrative group, this MAPI profile redirection doesn't work. However, if your Exchange 2003 organization is in native mode, you can move mailboxes across administrative groups without a problem.
Nevertheless, when your organization is in mixed mode and you need to perform a cross-site mailbox move, you still need to update the MAPI profile to reflect the target server in the new site. To do so, you must either manually create a target MAPI user profile or, more typically, use the command-line Exchange Profile Redirector (ExProfre--aka Exchange Profile Update) tool to update the existing profile. ExProfre modifies the existing default profile only; you can't use it to create new MAPI profiles. But you can use ExProfre if you've performed an interorganization mailbox move and want to update existing profiles rather than create new profiles.
Using the ExProfre Tool
ExProfre is supported only on Windows Server 2003, Windows XP, and Windows 2000 version 5.0.2195 and later. The tool is supported on all Outlook releases earlier than and including Outlook 2003. You can download ExProfre at http://www.microsoft.com/exchange/downloads/2003.asp.
You can use ExProfre to update users' Outlook MAPI profiles. Although typical Outlook functionality might seem to be available without running the tool, if you don't use ExProfre you'll end up with an unsupported configuration, and certain features, such as Calendar, task delegation, and public folder access, might not operate correctly.
Running ExProfre against a MAPI profile is a straightforward process that you need to execute on the client computer on which the MAPI profile resides. So if you're moving a large number of users from an Exchange 5.5 server in one site to an Exchange 2003 SP1 server in another administrative group, you need to update the MAPI profiles for each user you move. When you're dealing with large numbers of users, you might want to execute ExProfre from a logon script or implement it by using Group Policy Objects (GPOs). Make sure that Outlook isn't running when you execute ExProfre.
ExProfre performs several actions. First, it backs up the original MAPI profile and appends the exprofre value to the end of the profile name (e.g., McCorry becomes McCorry.exprofre). Backing up the existing MAPI profile is an important safety measure because if ExProfre fails, you can revert back to the old profile. Next, ExProfre requires that you specify a target Global Catalog (GC) server. Then ExProfre checks the Active Directory (AD) user object for the user who's associated with the MAPI profile; it should find an X.500 mail alias that shows that the mailbox has been moved to the new administrative group. The AD user object also contains important information that defines the new Exchange 2003 SP1 server: namely, the new legacyExchangeDN value and the new Exchange server name from the homeMDB attribute.
By default, ExProfre deletes the AD user object's associated current Offline Address Book (OAB), Outlook Favorites, and Outlook Nicknames files. (ExProfre adds .exprofre extensions to the latter two files.) When you use ExProfre to update a MAPI profile after performing a crossadministrative group mailbox move, leave the OAB, Favorites, and Nicknames files intact; you can use command-line options to do so. (ExProfre deletes these files to facilitate interorganizational mailbox moves when existing Favorites, OAB, and Nicknames files would be of little use in a new Exchange organization. For simple intraorganizational crossadministrative group mailbox moves, a lot of the information stored on the client computer is still valuable and should be retained.) I discuss how to handle Offline Store (OST) files later.
The ExProfre syntax is
Exprofre.exe /targetgc=<gcname> /logfile=<logfilename> /v /f /a /r /o /n /q /s /p=<frontendservername>
where gcname is the name of the GC server, which must be specified in the target forest that contains the user object that corresponds to the MAPI profile you're updating, and logfilename specifies the path and filename of the client PC's log file, which by default is exprofre.log in the TMP directory. The /targetgc command-line qualifier is mandatory; all other qualifiers are optional.
The optional command-line qualifiers include the following:
- /v--indicates verbose mode.
- /f--directs the Favorites file (favorites.xml in Outlook 2003 or favorites.fav in earlier Outlook releases) to remain intact rather than be renamed favorites.exprofre.
- /a--directs the OAB files to be retained; without this qualifier in the syntax, the OAB files will be deleted and Outlook will request a new set of OAB files the next time it connects to Exchange.
- /r--directs ExProfre to run in read-only mode.
- /o--directs the OST file to be retained; otherwise, the .ost file extension will be renamed .exprofre (Outlook 2003 always retains the OST file).
- /n--directs the Nickname file (.nk2 or .nick) to be deleted.
- /q--directs the operation to run in Quiet mode and to disallow pop-up messages.
- /s--directs the profile to be based on a server name change rather than a change in the legacyExchangeDN attribute.
- /p--directs a Remote Procedure Call (RPC) over HTTP connection to be used to connect the client to the Exchange infrastructure (and, importantly, to the GC); frontendservername is the name of the RPC/HTTP proxy server (also known as the RPC over HTTP front-end server).
If you want usage information about a command, you can use the /? parameter to execute ExProfre. Web Figure 1 (http://www.windowsitpro.com/microsoftexchangeoutlook, InstantDoc ID 43603) provides sample output that shows that ExProfre didn't update the MAPI profiles because the mailbox wasn't moved across administrative groups and the AD user object didn't detect any X.500 aliases that represented the original site.
ExProfre and OST Files
Microsoft recommends that you deploy Outlook 2003 to all client PCs before you perform crossadministrative group mailbox moves and that you enable cached mode on the client PCs. When you do so, ExProfre checks the PC's Outlook client version; if it detects Outlook 2003 running in cached mode, the OST files (essentially the local cache) remain intact. This useful function significantly reduces network traffic the next time Outlook connects to the newly moved mailbox because ExProfre won't need to rebuild the OST files. However, Outlook releases earlier than Outlook 2003 delete the OST files unless when you run ExProfre, you employ the /o command-line qualifier.
Deploying Outlook 2003 in cached mode before you perform crossadministrative group mailbox moves seems a logical thing to do. However, when Outlook creates OST files on an Exchange 5.5 server, the files are automatically ANSI-mode OST files. With the combination of Outlook 2003 and Exchange 2003, however, Outlook creates Unicode-mode OST files. You can't convert ANSI-mode OST files to Unicode-mode OST files. But if you want Unicode-mode OST files, you must delete existing ANSI-mode OST files and create new Unicode files after the crossadministrative group move occurs. You can operate Outlook 2003 with ANSI-mode OST files on an Exchange 2003 SP1 server without losing much functionality. However, if you want the advantages of Unicode--better interoperability for your organization's multilingual users and better facilitation of large OST files--you can download mailbox contents to OST files.
You can use Group Policy to control how Outlook 2003 handles OST format on individual PCs by editing the HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\EMSP registry subkey's Ignore OSTFormat value (of type REG_DWORD). You have a choice of three values:
- 0--leaves OST as is
- 1--forces new Unicode-mode OST download at first Outlook start-up
- 2--prompts to download new Unicode-mode OST at first Outlook start-up
Mailbox Moves and OAB Files
Whichever Outlook version you use, running ExProfre without the /a command-line qualifier deletes the OAB files on the client PC and requests a new set of OAB files from the Exchange 2003 SP1 server. This function is desirable if you're performing an interorganizational migration in which you don't need the old OAB files. However, in the case of crossadministrative group mailbox moves, you might choose to specify the /a command-line qualifier so that you can retain the OAB files, which can be used with the new Exchange server. Like OST files, these OAB files remain in ANSI mode because Exchange 5.5 can create only ANSI-mode OAB files. If you want to upgrade the OAB files to Unicode mode, you must delete the ANSI-mode OAB files from the client PC and download Unicode-mode files from the Exchange 2003 SP1 server.
If your users need Unicode-mode OAB files, you can retain the ANSI-mode OAB files for a short time and gradually move users to Unicode-mode OAB files by phasing in OAB-delete and Unicode-file downloads so that you don't overload the network. The alternative is to run ExProfre without using the /a command-line qualifier and incur peaks in network load as the newly moved users connect to the Exchange 2003 SP1 server for the first time.
Using the Object Rehome Tool
In "Demystifying Exchange 2003 Mailbox Moves," I discuss moving mailboxes between administrative groups. This process generally results in the decommissioning of a remote Exchange 5.5 server or site. But what about custom recipients and DLs that are located (homed) on these sites? Such objects are already represented in AD, courtesy of the Active Directory Connector (ADC). So instead of moving them to a central Exchange 2003 SP1 server, you want to rehome them to the central administrative group. Otherwise, they'll be lost when you decommission the source site.
You can use the Object Rehome (aka LegacyDN) tool to carry out this process, specifying the source site in which the objects are located and the target administrative group to which you're relocating them. Object Rehome is just a function of the ExProfre tool that runs from the command line and performs several actions.
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
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.