Migration Manager for Exchange (QMM/EX) – version 8.10 is available with full Exchange 2013 support

Posted on by rkmigblog

Migration Manager for Exchange 8.10 is available for download via the Dell/Quest support website along with CPUU 5.2. Remarkable is the support for single-hop Exchange 2003 to Exchange 2013 migration scenarios and public folder migration coexistence to Exchange 2013 public folder mailbox technology.
Together with Exchange 2013 as target mailbox system, wave 15 of Office 365 is also officially supported.

According to the release notes, QMM Exchange 8.10 provides the following features:

  • Migrate Microsoft Exchange 2000–2010 mailboxes to Microsoft Exchange 2013 without locking users out of their mailboxes.
  • Benefit from direct one-step migration from legacy Microsoft Exchange 2000–2010 servers to Microsoft Exchange 2013.
  • Migrate your public folders from Microsoft Exchange 2000–2010 to Microsoft Exchange 2013 with co-existence enabled.
  • Benefit from full two-way calendar (free/busy) synchronization between Microsoft Exchange 2000-2010 and Microsoft Exchange 2013 organizations during the migration.
  • Migrate Microsoft Exchange 2000–2010 mailboxes to Microsoft Office 365 Wave 15 without locking users out of their mailboxes and without extra pre-migration steps. Set up full two-way calendar (free/busy) synchronization during the migration process.
  • Consolidate your multiple source forests into the single Office 365 cloud.
  • Migrate your Microsoft Exchange organization to an existing hybrid environment with single sign-on enabled.
  • Use Migration Manager for Active Directory to create mail-enabled user accounts, and benefit from using the native move job for your Microsoft Exchange 2003–2010 to Microsoft Exchange 2003–2010 migrations (an Exchange 2010 CAS server in the source or target organization is required).

Client Profile Updating Utility 5.2 (aka EMWProf):

  • Client Profile Updating Utility (CPUU): Support switching Microsoft Outlook 2013 user profiles from source to target Exchange server
  • Client Profile Updating Utility (CPUU): Support for Windows 8 as an end-user platform
  • Client Profile Updating Utility (CPUU): Support for Microsoft Exchange Server 2013 as a target.

(Source: “Release Notes for Quest Migration Manager for Exchange, April 30th”)

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

Posted on by rkmigblog

In one of our previous posts [http://wp.me/p300CJ-15] 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:

cal_sync_instances

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.

instances

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:

cal_sync_instances_d

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® and Exchange 2010 Calendar Repair Assistant (CRA) – there can be only one!

Posted on by rkmigblog

The CRA

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:

http://blogs.technet.com/b/exchange/archive/2013/01/17/exchange-2010-calendar-repair-assistant.aspx

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

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

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

https://support.quest.com/SolutionDetail.aspx?id=SOL102260&pr=Migration 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>@delete.me)

  – 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) – Support for single hop Exchange 2003 -> 2013 migration

Posted on by rkmigblog

Updated:

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:

http://redmondmag.com/articles/2013/04/24/updated-migration-manager-for-exchange.aspx

 

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.

(Source: http://communities.quest.com/message/73072#73072)

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

Posted on by rkmigblog

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:

https://support.quest.com/productinformation.aspx?pr=268440338&pv=4294952030&t=s_plc

For Migration Manager for Active Directory check here:

https://support.quest.com/productinformation.aspx?pr=268440337&pv=4294952032&syn=Migration+Manager+for+Active+Directory&t=s_plc

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:

https://support.quest.com/SolutionDetail.aspx?id=SOL77417

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:

https://support.quest.com/RSS/ProductFeed.aspx?Product=Migration%20Manager%20for%20Exchange

For Migration Manager for Active Directory use this xml file:

https://support.quest.com/RSS/ProductFeed.aspx?Product=Migration%20Manager%20for%20AD

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.