Resolution
Can I run multiple Exchange Migrator consoles at the same time?
fact
Exchange Migrator 2.2 SP1
fact
Exchange Migrator 2.2 SP1 HF13716
fact
Exchange Migrator 2.2 SP1 HF21235
fix
Yes, Exchange Migrator version 2.2 SP1 and later will allow you to use multiple consoles at the same time. However, you must use a single central database to avoid loss of distribution list memberships and permissions (calendar, delegate etc), and you cannot migrate the same project from different consoles at the same time. The use of a single central database is a requirement. The use of multiple databases is unsupported. Please reference NETIQKB21295 : How can multiple Exchange Migrator consoles be configured to use a central database?
General Information:
Although Exchange Migrator (EM) version 2.2 SP1 and later support the use of multiple EM consoles, it does not support the simultaneous migrations of the same project using multiple consoles. The ability to use multiple consoles was developed because some customers need to install EM consoles at different geographic locations while maintaining a single database.
Why install EM at different geographic locations? The reason is, for most customers, using a separate console machine is more desirable than installing EM on the target production Microsoft Exchange server. By having each EM console in the same geographic location (if possible, on the same LAN) as the designated source and target Exchange servers, migration time can be significantly reduced. Please note that benchmark numbers will vary from environment to environment. Please reference NETIQKB1151 : What is the benchmark performance that can be expected from Exchange Migrator while migrating mailboxes?
It is important to note that mail items actually stream through the EM console. For example, if you had source and target servers in Houston, but the console with the EMA database is located in Dallas, you would now have to contend with your WAN links in addition to your LAN because mail streams through the console in Dallas. Again, the purpose for having the EM consoles local to the source and target is to overcome the latency caused by the WAN. If an EM console were placed in Houston, it would need to contact the database in Dallas, but this communication is minimal. The largest advantage is that the traffic caused by the migration would occur on the LAN. Most customers experience the best migration performance when the Source, Target, and EM console are on the same segment and same switch if at all possible.
All of the EM consoles use the same database for important reasons. The database contains all of the mappings between the source objects and the target objects, memberships to distribution lists, delegate permissions, etc which is why NetIQ requires that you use the single database model. To prevent the corruption of databases, EM 2.2 SP1 and later, creates project locks at the application level locking.
Project locking also prevents you from adding an object to a project when that object exists in another project. For example, if you had Projects A, B, and C on different EM consoles and those projects had completely different mail objects (mailboxes, distribution lists, custom recipients), then it is reasonable to assume that you could run Projects A, B, and C from the seperate consoles to migrate them.
note
Related topics
- NETIQKB18323 : What performance increase can be expected by using multiple consoles?
- NETIQKB21295 : How can multiple Exchange Migrator consoles be configured to use a central database?
- NETIQKB22651 : Failed to acquire lock for the project. [YourExchangeServerName] currently holds the lock [HR=0x80004005]