Quest Migration Manager for Exchange® and Exchange 2010 Calendar Repair Assistant (CRA) – there can be only one!


Microsoft Exchange 2010 ships with a very helpful utility that helps to check the consistent state of meeting invitations and responses and can repair broken relationships – the Exchange 2010 Calendar Repair Assistant (CRA). For example: John organizes a meeting and sends meeting invitations by Outlook. Jack accepts the meeting, which is registered in John’s mailbox calendar (as meeting acceptance) and in Jack’s mailbox calendar as appointment. Maybe somehow Jack did a misconfiguration with his handheld and lots of appointments are missing. The CRA would detect, that Jack is listed as participant of John’s meeting and would create the missing item appointment in Jack’s mailbox calendar to bring back the proper meeting organizer – participant relationship.

You can find a deep-dive explanation of Exchange 2010 CRA here:

The Problem

Although the CRA is a pretty helpful tool and saves many people from missing meetings because of missing reminders of calendar items, we cannot recommend to use it during an Inter Org Exchange Migration with a running Quest Calendar Synchronization (either uni-directional or bi-directional). We have seen various cases where calendar items in the target mailbox have been duplicated while the duplicates did not exist in the source mailbox. Checking the items’ creator, one can see that one item was created by the calendar sync agent, the other one by the service account of the RCA.

How come? Let’s think of the following example:

Exchange Inter-Org migration from Exchange 2007 to Exchange 2010 SP2 by using Quest Migration Manager for Exchange. For all user to migrate, we have a source mailbox in 2007 and a target mailbox in 2010. The Quest mail and calendar synchronization synchronizes mail content and calendar data between the corresponding mailbox pairs.

John is a user who was already migrated and switched to Exchange 2010 environment. Jack is a user who is still active on his Exchange 2007 mailbox – nevertheless his Exchange 2010 mailbox is already present and filled by the Quest mail and calendar sync.

John creates a meeting in Outlook, invites Jack to the meeting and sends a meeting request. The meeting request is send as an Outlook message into the Exchange 2010 system. Since the Exchange 2010 mailbox of Jack is present but not active, the targetaddress redirection in the Active Directory object of Jack in the target domain will redirect the message to the Exchange 2007 mailbox of Jack. Jack recognizes the meeting invitation mail in his Outlook Inbox and accepts. A system message is now sent back to John who will see now Jack as confirmed meeting participant. In the same step a new appointment is created in Jack’s calendar to reflect the scheduled meeting. So far business as usual. Please note, that at this time, the calendar of John in Exchange 2010 shows that Jack has accepted, the calendar of Jack in 2007 shows the meeting as appointment, but the calendar of Jack in Exchange 2010 is “empty” due to the “nature” of calendar synchronization latency.

Taking a look onto the Exchange 2010 system only at this moment – we will find an inconsistent state between meeting organizer and participant’s calendar data.

The Race CSA vs. CRA

And now it’s like 2 fire brigades trying to fight the fire at same time – the race begins. Quest calendar synchronization Agent (CSA) detected a change in the source Exchange 2007 mailbox of Jack, picks up the change and transfers to the new mailbox which takes time depending on number of mailboxes, synchronization interval etc. At the same time the CRA running in Exchange 2010 environment for good reasons detects the described inconsistency and tries to correct it by creating the “missing” item from scratch. Whenever the CRA is faster we will see most probably duplicates. The CRA is always running per mailbox server while the Quest Calendar Sync can be tuned to run with multiple instances per mailbox server.


RECOMMENDATION: Disable the MS Exchange CRA for the duration of migration.

Dell/Quest support is reporting the issue in their Knowledge Base in brief: Manager for Exchange

They also list some possibilities to fix the duplicates:

Workaround 1 (for switched mailboxes)

 1. Export the problematic calendar to a PST file with the “Do not export duplicate items” option.

 2. Delete all calendar items.

 3. Re-import the calendar items from the PST.

 Workaround 2 (for non-switched mailboxes)

 1. Disconnect the problematic target mailbox.

 2. Purge it from the mailbox database (to prevent tombstone issues).

 3. Run a full AD re-sync to recreate the target mailbox. Alternatively, perform a “Proxy Toggle” (no need for a full re-sync):

  – Add a dummy address to the source mailbox (ex. <alias>

  – Let DSA sync the change during a normal delta sync cycle, which should recreate the mailbox

  – Remove the dummy address from the source mailbox

 4. Run a calendar sync

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.

Quest Migration Manager for Exchange(R) – Support for single hop Exchange 2003 -> 2013 migration


On Redmond Magazine, an article was launched that announces the new Version of QMM (QMM 8.10). The Software is not yet available for download (actual by May, 12th 2013), but promises the single-hop Migration from Exchange 2003 to Exchange 2013 which can make a difference for many large IT customers when comparing with Microsoft native approaches.

Due to the Redmond Magazine article:

“One of the exciting things we can do with this product…is  the ability to migrate in a direct single-step migration from Exchange 2003 or Exchange  2000 into the new version of Office 365 or Exchange 2013,” said Ron Robbins,  a product manager at Dell, in a phone interview. “It’s one thing that Microsoft  is not able to support, given the fact that they don’t support legacy platforms  that long and the fact that their native migration solutions don’t migrate  directly from those platforms any longer.”

See the full article here:


With the actual version of Quest Migration Manager for Exchange®, migrating mailboxes from Exchange 2003 to Exchange 2013 will require a 2 hop migration process. You have to install an Exchange 2010 transition server into your existing Exchange 2003 environment. You will then perform a 1st hop as an Intra-Org Exchange migration to move the mailboxes to the Exchange 2010 server. The 2nd hop will be an Inter-Org Exchange migration to the target Exchange 2013 organization.

 2hop migration Exchange 2003 to 2013

Although there is special software from Quest available to support the 1st hop, Migration Manager for Exchange Intra-Org Edition, the procedure is still a bit long winded.

Good news:

The plans of Dell/Quest Software are that the next version of Quest Migration Manager for Exchange will support a single hop migration from Exchange 2003 to Exchange 2013 in Inter-Org Exchange migration scenarios directly without the requirement of a transition server.

The new version is awaited for Q2/2013.


Quest Client Profile Updating Utility (CPUU) & multiple Exchange Accounts

Outlook 2010 introduced the feature to access and manage multiple exchange accounts within a single Outlook profile. Users with full mailbox permissions can use this feature to manage additional mailboxes in the same way they manage the personal mailbox without switching between different profiles.


Known Limitation with Quest Client Profile Updating Utility (CPUU)

CPUU is unable to update Outlook mail profiles with multiple exchange accounts.

For all limitations of CPUU 5.1 check here:  


Remove the additional exchange accounts and run CPUU again. Add the additional exchange account after the profile update.

Quest Migration Manager(R) – Best practices for supportability, patching and upgrading – Part 1

Product Support Policy and Product Lifecycle Tables

Over the time of a long running Active Directory or Exchange migration project, Dell/Quest Software will usually publish various hotfixes to keep the most current versions of Quest Migration Manager up to date.  The purpose of the hotfixes can be:

  • supporting a new version, release, service pack of Windows server OS, Windows client OS, Exchange or Outlook
  • fixing program code in the components of Migration Manager for Active Directory or Migration Manager for Exchange

By default, the 2 most recent releases of Migration Manager are part of the ongoing patch management process. [Statement from Quest Support Website: “Quest Software’s usual support policy is to provide support on both the current (n) and prior (n-1) versions of our products.” 2013-01-02].

For each Quest Software product, you can find a product lifecycle table, which provides information whether the release of your product is in “Full Support”, “Limited Support” or “Discontinued” mode.

For Migration Manager for Exchange check here:

For Migration Manager for Active Directory check here:

RECOMMENDATION: If you expect Dell/Quest support to provide custom code changes, enhancement requests and “on time” Hotfixes, make sure that your installed product release is covered by “Full Support” mode. For a long running migration Project, check in advance by using the product LifeCycle table and plan a maintenance window for upgrade activities.


How to get up to date information regarding new updates and hotfixes

Our most favorite way of getting a quick overview which hotfixes and upgrades are available is to check the hotfix summary page for Quest Migration Manager which is published here:

This excellent summary provides both, most recent and historical information, which makes it easy to assess the patch level situation of the own Migration Manager infrastructure.

Another fancy way to get the latest information regarding hotfixes, product releases and KB articles is to read the RSS feed provided by Dell/Quest support. You can directly import the links below into your RSS reader:

For Migration Manager for Exchange use this xml file:

For Migration Manager for Active Directory use this xml file:

REMARK: Although you can see all the hotfix information on the public facing part of the Quest support site, you only will be able to access the software when you are having a running support contract.

No matter which method you will use to get the updated code, you still have to make the decision for yourself whether you are going to implement a specific upgrade or hotfix or not. We will provide some consideration regarding this question in Part 2 of this thread.