Early use of MAPI
Historically, Quest Migration Manager for Exchange had relied upon the use of MAPI connections to MS Exchange to extract and migrate mail content. This agent architecture built using MAPI as its connection to Exchange (known as the legacy agent) had worked well and was responsible for migrating millions of mailboxes dating back to the Exchange 5.5 days. Several agents, hosts, and resources were required depending on the specific deployment or need. The agents operated independent of each other, thus there was no single point of failure. MAPI connections presented both flexibility but also limitations. They required an installation of the MAPI CDO, and wide range of network ports (RPC) to be open, making it challenging in high security/firewalled networks to even allow such connections. Exchange Web Services (EWS) was first introduced in Exchange 2007 as an alternative to MAPI. EWS allowed for a direct connection to Exchange via http/https.
Transitioning to using MAPI/EWS
In the wake of the release of Exchange 2013 and Office 365, Quest offered a newer re-design of the Migration agent architecture known as MAgE (Migration agent for Exchange). This new architecture consolidated the agent from three components to deploy to one, for Mailbox and Calendar. Also, utilized EWS as its connection method to Exchange versions 2013 & Office 365. Operating over a well-known web port, we broke some barriers allowing the solution to work in cloud based (Target) environments, whereas Legacy could not. Further improvements simplified the agent deployment and moving agent database storage from a local MS Access database to a single SQL database. This made changes to configurations and reporting much faster and flexible. One caveat is, that Public Folders still required MAPI connections/agents.
Still, many companies are running legacy versions of Exchange. While Exchange 2003/2007 deployments have diminished, Exchange 2010 deployments still exist. Unfortunately, when migrating to Exchange 2010 the MAPI based Legacy agents were still required. When migrating From, the source platform the MAgE agent still required a MAPI connection, while connecting via EWS to Exchange 2013/2016 or Office 365. So, while the product was connecting via EWS with the newer platforms, we were still limited by the inherent MAPI requirements for source. That is, until recently!!!
Transition to EWS
Beginning in Migration Manager for Exchange 8.13, the Migration Agent for Exchange (MAgE) uses Exchange Web Services (EWS) for communication to the Source environments (2010/2013) by default. However, the initial release did not allow for an EWS connection to Exchange 2010 as a target. In early Dec 2016, the product team released a hotfix for the new version Migration Mgr 8.13 and CPUU ver 5.6.5 which now fully supports target EWS connections for Exchange 2010. Now, the MAgE agent can be used to connect to Exchange 2010 via EWS as a Source and/or a Target. This eliminates the need for a MAPI based connection for Source AND Target platforms. We expect overall improvements to migration performance when migrating under this new configuration.
Other benefits are:
- Decreased resource usage on agent host servers and source Exchange servers.
- Lowered network traffic between MAgE and source Exchange organization during mailbox and calendar sync.
FAQs
What if I’ve already started a Migration (Exchange 2010 to 2010) using Legacy agents? Can I upgrade and use MAgE & EWS?
Yes, you can upgrade, however, for mailboxes already in process, it is recommended to complete those due to the differences in architecture. To use the MAgE Agent/EWS, you would need to clear the target mailbox and re-migrate. Otherwise, there would be duplicate content as we were unable to retain the existing content.
How do I tell the MAgE agent to connect via EWS? Do I need to turn it on?
No, if you upgrade or deploy a new project, it will be on by default. If the MAgE agent cannot connect via EWS, it will switch back to MAPI.
You can configure the option via PowerShell command. Set the ‘UseEwsProtocolForSourceIfAvailable’ parameter to True/False using the Set-DMMExProjectOptions cmdlet.
What else should I be aware of?
An EWS connection requires a valid autodiscover url. This also can be set via powershell. Be sure to upgrade to the latest hotfix and current version of CPUU. Note that Public Folder migration is still performed via MAPI, as well as Migrations from Exchange 2003/2007. The installation of the Mapi cdo is still required to support legacy and Public Folder migrations.
For information on using the Migration Manager PowerShell commandlets, see the Migration Manager Exchange User Guide
Happy Migrating!