Chat now with support
Chat with Support

Reference Materials for Migration 8.15 - Tips and Tricks

Introduction Environment Assessment, Planning, and Testing Basic Migration Steps Considerations for Active Directory Migration and Resource Update Considerations for Exchange Migration Preferred Settings for the Directory Synchronization Agent Directory Synchronization Agent Placement Indexing Service Attributes Full Directory Resynchronization Conclusion Environment Preparation Checklist Exchange Migration without Trusts Active Directory Migration without Trusts

Mailbox Switch

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:

  • Mailboxes can be switched automatically (which is recommended) by the Mail Source Agent when the mailbox is in sync. If you want to control when mailboxes are switched automatically, specify the Start switching mailboxes date and time in the collection properties. The agent will start switching mailboxes that are in sync (or almost in sync) only after the date and time you specify.

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.

  • You can switch particular mailboxes manually from the Migration Manager for Exchange interface. Note that no further synchronization will occur after you switch a mailbox manually.

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.

Client Profile Update

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.

Interoperability with Other Quest Products

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:

  • Different computers must be used to install Exchange Migration Wizard and Migration Manager for Exchange Console.
  • Different target Exchange servers must be used to migrate data from the source environments by Exchange Migration Wizard and Migration Manager for Exchange. That is, the Exchange agents (such as mail, public folder, calendar, and free/busy synchronization agents) from different products must not be installed and run on the same target Exchange servers.
  • Different custom attribute sets must be used as the service attributes by the two products.
  • Different SMTP address templates must be used for redirection purposes by the products.

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.

Preferred Settings for the Directory Synchronization Agent

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

Refer to the Quest Migration Manager for Active Directory—User Guide for procedures on how to configure the preferred settings for the agent.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating