Switching a mailbox means that all new mail comes to the target Exchange mailbox. A mailbox should be switched once all data from the source mailbox is migrated to the target mailbox. You can switch mailboxes automatically or manually, as follows:
NOTE: When Mail Source Agent automatically switches a mailbox, it checks whether the PRV file with 'ready to switch' flag is already processed by the Mail Target Agent - this is used to minimize the risk of not all data yet present in the target mailbox at the instant that the mailbox is switched. This default behavior, however, requires additional logon to target mailbox, which may decrease the performance if the logon is performed slowly.
To switch this additional logon to target mailbox OFF, set LastPSTAppliedSwitch=0 for Mail Source Agent.
As the MTA inserts the mail into the target mailbox, and this is run independently of the MSA, in this case you may want to run the MTA continuously to minimize the time that the data does not exist in the target after the switch.
In addition, run the agents during off hours so that the MTA will run before the users run EMWProf and connect to their target Exchange mailboxes.
CAUTION: Manual switch is not available for the mailboxes of Remote Users Collections. These mailboxes can only be switched automatically by the Mail Source Agent.
Profile update usually happens during user logon. If users remain logged on during the mailbox switching, use Migration Manager for Exchange to send them an e-mail message (switch notification message) instructing them to log off and back on so that their profiles will be updated. You can customize the message sent to the users for each source Exchange server. For more details on switch notification capabilities, refer to the Quest Migration Manager for Exchange—User Guide.
The EMWProf utility can also be configured to send a notification message when it finishes processing the Outlook profile on a client workstation. You can specify the administrator’s mailbox to which the messages will be sent. The notification message that the EMWProf sends includes the update status (succeeded or failed), the computer name on which the EMWProf was executed, and the EMWProf log file. You can filter these messages by their status and take action for those with the failed status as soon as you receive them. For more details on EMWProf's notification capabilities, refer to the Client Profiles Updating Utility documentation.
Exchange Migration Wizard
If Exchange Migration Wizard is used to migrate from Exchange 5.5 in parallel with Migration Manager for Exchange to migrate from Exchange to the same target Exchange environment, the following restrictions apply:
Additional planning should also be done to coordinate Exchange 5.5 and Exchange 2000/2003/2007 migration activities, especially if separate migration teams are responsible for each migration.
It is required that you always specify the preferred domain controller and the preferred Global Catalog server for each Directory Synchronization Agent, and that these be located in the same site as the agent. In addition, we recommend that you set the Directory Synchronization Agent to always use the same domain controller and Global Catalog in the domain.
This ensures, first of all, that the agents will not work with domain controllers and Global Catalog servers located in remote sites across WAN links.
Second, the Directory Synchronization Agent uses Microsoft’s Dirsync control to query for directory changes, and Dirsync’s behavior is not consistent when different domain controllers are used to query for changed objects. This issue with Dirsync may have an undesired effect on the Directory Synchronization Agent performing delta sync: if a domain controller from which the agent used to retrieve information about the objects modified since the last session becomes unavailable and no preferred domain controller is set, the agent will be automatically redirected to another domain controller. The new domain controller may return many more objects (or even all objects from the directory) as modified, causing the agent to perform unnecessary jobs.
Microsoft describes the issue as follows:
For incremental searches, the best practice is to bind to the same domain controller (DC) used in the previous search, that is, the DC that generated the cookie. If the same DC is unavailable, either wait until it is, or bind to a new DC and perform a full synchronization. Store the DNS name of the DC in the secondary storage with the cookie.
You can pass a cookie generated by one DC to a different DC hosting a replica of the same directory partition. There is no chance that a client will miss changes by using a cookie from one DC on another DC. However, it is possible that the search results from the new DC may include reported changes by the old DC; in some cases, the new DC may return all objects and attributes, as with a full synchronization. (http://msdn2.microsoft.com/en-us/library/ms677626.aspx)
Refer to the Quest Migration Manager for Active Directory—User Guide for procedures on how to configure the preferred settings for the agent.