How to start? Register with Quest so you can search the KB and download products!
Download the tool. Get a temp license. Support does not deal with licenses, request a license from licensing department. You can do it from the Quest website or by sending an e-mail to .
There is no difference between evaluation software and “production” software, you will not have to reinstall if you decide to buy the product.
https://support.quest.com/SUPPORT/index?page=solution&id=SOL38920
Always check Quick Start Guide and User Guide first for permissions and software requirements.
Installing on Virtual machines is fine when testing, not smart when doing a real migration.
Use a good and fast machine to install DSA and ADAM. Install DSA on a separate machine from ADAM. Don’t install DSA on the same machine where ADAM has been installed.
If this has been already done – don’t uninstall anything, just install another DSA on another machine and use it. Quest KB might be helpful: https://support.quest.com/SUPPORT/index?page=solution&id=SOL35842
Installing ADAM on computers with dual CPU will not help, process is not multithreaded.
Directory Synchronization Agent Placement (excerpt from QMM Best Practices)
It is not recommended to install the Directory Synchronization Agent on the domain controller, Exchange server, or console machine to avoid possible server and agent performance degradation. The best practice is to install the Directory Synchronization Agent on a dedicated server running Windows XP or 2003 in the network that has good connectivity to both the source and the target domains being synchronized.
First step – create a service account in target. In AD find the container Builtin and find the group Administrators, this is the proper group. Add your service account to this group.
Remove this account form all other groups, leave only the primary Domain Users Group. It is not cool to be Domain Admin anymore, especially when working with trusts. MS KB 893191 explains why.
Grant this account local administrator rights on the computer where QMM or ADAM or DSA will be installed. The computer where you install QMM will be called “console” or QMM console.
From folder re-distributable install ADAM. Install SP for ADAM.
Never change the password for this account. Stick with this account.
Where to place the console?
This question is not as simple as it sounds. No matter where you place the console the account you are going to use will affect it. It does not help very much if you choose a computer from target domain but decide to use a source account; this will mean you will logon to source domain.
Place the console in target domain! Use a target service account!
If console is in source computer migration often fails. See also this article:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL17458
Trust.
Establish a trust. Disable SID filtering. Some Quest KB articles with instructions:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL12892
https://support.quest.com/SUPPORT/index?page=solution&id=SOL14246
Add your TARGET service account to built in administrators group in source. Don’t use group membership, always add the account explicitly.
When doing Exchange migration grant appropriate permissions explicitly on all levels – in the Org and all the way down. Ex 2003 – use the Security tab. Ex 2007 – use ADSI Edit. Quest has excellent KB articles, eg.:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL38171
https://support.quest.com/SUPPORT/index?page=solution&id=SOL33970
Firewalled environment? Need to open ports?
https://support.quest.com/SUPPORT/index?page=solution&id=SOL14735
If console is in target and source is firewalled – place another DSA in source, it often works better and you don’t need to adjust the firewall. Having multiple DSA is an excellent idea.
Migration
Always specify preferred DC and GC:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL14630
Migration does not migrate any Exchange attributes, it migrates only AD attributes (exception is intraforest migration). In order to do Exchange migration and mail enable target accounts you need to configure the directory synchronization. Accounts will get mail enabled only if Exchange options have been configured under dirsync properties.
Index the matching attributes, this will speed up the synchronization enormously.
https://support.quest.com/SUPPORT/index?page=solution&id=SOL17773
Keep in mind that the first (initial) synchronization might take very long time, hours and even days.
Think twice before configuring a two-way sync . You need it mostly when new accounts are being created in target domain and you want them to appear in source GAL.
When migrating users don’t select “add source members to the corresponding target groups”, it will do what it promises and you will end up having target and source users in target groups. For details see User Guide page 53 or SOL45738 .
Not sure how group population works? See User Guide or this article:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL14335
If unsure don’t modify default settings (matching by name, SID history, e-mail).
Matching by e-mail will work only if primary SMTP addresses are the same, QMM cannot match using proxy addresses.
DON’T skip any attributes unless you know what you are doing and unless absolutely needed. There are many KB articles which explain which attributes are vital. Only few really need to be skipped, most of them will anyway not be synced due to design and due to the logic. Ex attributes are not synced so don’t skip them. Proxy addresses will be copied anyway, both ways, this is by design; don’t attempt to skip them, skipping them will not work.
To rename objects during migration see this article:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL16917
Don’t delete any migration sessions. Not when testing and not when in production.
When testing don’t delete target accounts, use the undo migration feature, this will remove the account from target ad, cleanup ADAM, free up license.
Don’t use the same test account when testing migration, especially when processing resources and re-assigning permissions (profile). When you re-migrate the same account many times and delete the target account there are too many entries in internal DB and tool is unable to choose which is the correct entry.
Wizards: ADPW, SQLPW, EPW etc.
When using wizards it is important to select users. Create and safe the wizard and only then you will be able to select users. For instructions see:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL22583
User migration.
If something is not working try to narrow it down, try to determine whether it is caused by DSA or other component. Check the Event Viewer on the computer where DSA is installed, there is a node for DSA.
Keep in mind DSA is doing synchronization and migration. If you have multiple domain pairs the DSA is “serving” them all. Consider installing multiple DSA, eg. one DSA for each domain pair, and if you are going to do sync and big migrations – 2 DSA for each domain pair, one for migration, one for sync.
Most common issues are: credentials are incorrect or name resolution is not working and the computer where DSA is installed cannot connect to ADAM machine or to source or target DC.
RUM. Strong alcoholic beverage J
Rule of thumb: when processing resources use a source account (which is member of domain admins group in source). When migrating computers use target account (which has local admin rights on each computer). Or add the source account to target built in admins. You can use the Batch option to grant permissions (see KB). Avoid using Set Credentials do it properly, eg. when pre-installing agents this will not work.
Don’t populate RUM with too many computers. Delete them all from RUM and add them only in smaller groups eg. via import file.
When using RUM don’t select “Process a s specified in exported INI file (unless you know what you are doing). If something is not working as expected enable extended logging (Tool – options – logging – advanced – trace all operations).
Common misunderstanding: RUM consists of 2 main separate pars, one is for re-permissioning, one is for migrating computers. If you click on Start only one procedure will be performed. Suggestion: first process computers, then migrate (move) them. See SOL35337: https://support.quest.com/SUPPORT/index?page=solution&id=SOL35337
“Set Credentials” works only when processing resources, it does not help when installing Agents or when migrating computers.
If RUM does not respond – use Task Manager and kill the task. Or find and stop the service, there is a service on console called Quest Resource Updating Service. BUT! Don’t stop or start other Quest services directly, always use the GUI. This service is the only exception.
Any questions? Register with Quest, check the KB, take your time, you will find the answer.
If not – open a ticket. It is better to ask in advance than make a mistake and have to fix it.
Exchange Data part – quick overview.
This tool is too complex to try to explain it in 2 words, involving PSO and letting them configure the tool is a good idea, and letting them to design the migration and to explain how it works is wisely spent money.
You should start working with Exchange Data part only after synchronization has been done and target accounts have been mail enabled by QMM. This tool cannot use pre-existing mailboxes:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL10368
Create connectors, source and target should be able to communicate, there is no way around. For instructions see Quick Start Guide. Don’t configure RUS or Exchange to handle the redirection namespaces (eg. source.com, target.com), this is a bad idea and is not needed.
Enumerate the source and target. This tool uses the AD to enumerate the Exchange org so it will be able to enumerate even without properly configured Ex permissions.
Most of all issues in Ex Data part are related to improper permissions. Take your time and verify it twice!
In Ex 2003 – use the Security tab. In Ex 2007 – use ADSI Edit. See KB articles:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL38171
https://support.quest.com/SUPPORT/index?page=solution&id=SOL33970
Model: Mail Source Agent will logon to source mailbox and retrieve all data. The account (service account) needs to be able to logon to all source mailboxes. Agent will compress the data (if configured so) and create a zipped PRV file. As soon as such a file is being created Transmission Agent will transfer (move) this file to target Exchange server. Mail Target Agent (which needs to be able to logon to all target mailboxes) will deliver the data and then delete the file.
MSA is not aware of what MTA is doing and when MSA retrieves all data it considers mailbox as synced and ready to be switched, if you allow automatic switching it will switch the mailbox without verifying if any data arrived on target. It is important to ensure MTA works properly.
Public Folder sync works similarly. Do never delete any Public Folders in target during migration:
https://support.quest.com/SUPPORT/index?page=solution&id=SOL9621
https://support.quest.com/SUPPORT/index?page=solution&id=SOL14266
Calendar sync works differently, there is only one agent, either in source or on target.
FB sync works like Calendar sync, only one agent is involved.
When creating mailbox collections don’t create too many of them. Common practice is to create 2 collections, eg. “sync” and “switch”. Sync collection doesn’t allow automatic switching, after you ensured target mailbox has all the data you move the mailbox to another collection and commit changes, another collection will automatically switch the mailbox. The same mailbox needs to participate in calendar sync, only then all items will be synced and mailbox can be switched.
This tool does not connect to Exchange servers constantly, the settings are stored in the SQL DB.
This means every time you modify something, eg. after you create new mailboxes or move them in source or in target you should expand the org in QMM, find the server, right mouse – refresh. This will re-enumerate the server.
No matter which issue you are experiencing of which error you are facing – check the KB, absolutely all known issues are covered there. It is a good idea not to narrow down the search for QMM only, another product called Exchange Migration Wizard is identical to QMM and there might be an article for EMW.