Quest Migration Manager for Exchange® – Pimp your QMM calendar sync power

In one of our previous posts [] we showed how important the calendar synchonization is in your Inter-Org Exchange migration project when using Quest Migration Manager for Exchange. The Quest approach runs 2 mailboxes for every user (1 in source, 1 in target organization) which enables a long coexistence but also requires a fast running calendar synchronization between those mailboxes for actual Free/Busy information. As less mailboxes per calendar sync agent instance as faster your calendar sync will run. That is a simple truth. But it is not the only one.

When we started to design our Quest Mail and Calendar Sync Agent setup in our large scale project, the customer was very generous and spent us 25 virtual machines with 2 processor cores each. We installed 9 calendar sync agent instances (QMM 8.8) on each of the servers. The customer still had some resources left and spent us another 2 cores for each virtual machines. Running this “QMM server farm” we expected to meet and even exceed the customer’s expectation of 20 minutes calendar sync latencies when bringing over a new calendar entry. However, the performance was not like expected.
Investigation on the servers gave us the following insight on processor usage:


You can see that the first 2 cores are heavily used while the other 2 cores are in “idle mode”. Some experts started to create a powershell script to set processor affinity to the QMM calendar sync agent (CSA) processes which you can find here. set_proc_affinity

But sometimes things are simpler than they look at first sight. In every Quest mail or calendar sync agent folder you can find an RCmd.ini file. The RCmd.ini file contains the string “ProcessorIndex” which defines the processor instance to be used by the agent. When we parsed the files we recognized the distribution as shown in red column. Only the cores 0 and 1 were defined in the RCmd.ini, but not 2 and 3.


We modified the RCmd.ini files of all calendar sync agent instances like shown in the green column. A new investigation on the server presented a different picture of a well-balanced processor usage:


With this insight it was a straight-forward task to create a powershell script that parsed through all agent instances on all QMM agent hosts to adjust the ProcessorIndex settings in the RCmd.ini files.

Good to know how things work.

Quest Migration Manager for Exchange(R): Do we need a Free/Busy sync agent when we are migrating from Exchange 2003?

A customer was recently wondering how he should use the Quest Migration Manager for Exchange Free/Busy synchronization when migrating from Exchange 2003 to Exchange 2010 in an Inter-Org Exchange Migration.
The customer Exchange 2010 Environment was in native mode and did not contain System Public Folders to Keep the Free/Busy system messages.
Does that mean, updated Free/Busy data will not be available during the mailbox migration period where we have to maintain mailboxes in 2003 and 2010 in coexistence?
The answer is no.
Free/Busy data is maintained by running the Quest Calendar Synchronization (either uni-directional or bi-directional) between the corresponding mailboxes in source and target Exchange Systems.
Even when we have a target Exchange System with Free/Busy System Folders, we do not have to configure a Job for the Free/Busy Synchronization Agent. The Calendar Sync Agent takes over the Free/Busy publishing. You can find this action reported in the Calendar Sync Agent log (EMWCSA.log). The Free/Busy publishing period can be configured in the config.ini file of the Calendar Sync Agent, a smaller time period speeds up the Calendar Sync performance.

Recommendation: Make sure that you’ve deployed a sufficient number of Calendar Sync Agents to ensure a quick sync cycle. You do not need a dedicated Free/Busy synchronization job then.

Recommendation: If your target Exchange System does not contain Free/Busy System Public Folders, set your Free/Busy Publishing Period in the config.ini file of the Calendar Sync Agent to 0.