Tag Archives: Migration

Autodiscover in an Exchange interorg migration with Quest QMM

Outlook clients get their configuration information using the Autodiscover protocol from the Exchange server where their mailbox resides and the underlying Active Directory. This works fine, until you are in an interorg migration scenario using the Quest Migration Manager (QMM) for Exchange.

When using Microsoft tools (ADMT, Prepare-MoveRequest.ps1 and New-MoveRequest) the source Mailbox in Exchange is converted to a Mail-Enabled user at the moment of migration finalization. At the same moment the Mail-Enabled User property targetAddress is stamped with the SMTP address of the Mailbox in the new forest. SMTP works fine now, and also Autodiscover will follow the SMTP domain that’s in the targetAddress property. This is true for an interorg migration on-premises, but it is also true when moving Mailboxes from Exchange on-premises to Exchange Online in a hybrid scenario.

When using Quest tooling things are a bit different. The source Mailbox is not converted to a Mail-Enabled User, but it continues to exist at a regular Mailbox. The Outlook profile on the desktop is converted using the CPUU tool using local Autodiscover.xml files so that the Outlook client no longer connects to the old Mailbox but to the new Mailbox.

This works fine for the existing client, but when a user gets a new laptop, or has to configure the Outlook profile again, Outlook will use the Autodiscover process and thus connect to the old Mailbox. Since this isn’t converted to a Mail-Enabled User, Outlook will find the (old) Mailbox, it will stop searching (and thus will not follow the targetAddress property) and return the configuration information for the old Mailbox.

To fix this, we have to export the Autodiscover information from the new Exchange organization to the old organization. I found an old blogpost written by Andread Kapteina (Senior Consultant at Microsoft) in the Google cache (since his blogs no longer exist at the Microsoft Technet Site) about this scenario in an interorg Exchange 2007 to Exchange 2010 migration, but I found that it is also valid in an interorg Exchange 2013 to Exchange 2016 migration. And it should be valid in every interorg Exchange migration from Exchange 2007 and higher.


To export the Autodiscover configuration from the new Exchange 2016 to the old Exchange 2013 organization, execute the following commands on the Exchange 2016 server:

$OldCred = Get-Credential OldForest\administrator
Export-AutodiscoverConfig -DomainController <NewForestFQDN> -TargetForestDomainController <OldForestFQDN> -TargetForestCredential $OldCred -MultipleExchangeDeployments $true

The -MultiplExchangeDeployments options should be set to $true since both forests contain an Exchange organization.

The Exchange Management Shell does not report anything back, so no need to show it here 😊

When we look in the AD Configuration container we can now see two SCP records:

  • One record can be found under CN=Services, CN=Microsoft Exchange, CN=<Organization>, CN=Administrative Groups, CN=Exchange Adminstrative Groups (FYDIBOHF23SPDLT), CN=Servers, CN=<ServerName>, CN=Protocols, CN=Autodiscover, CN=<ServerName>. This will contain the regular SCP information that Outlook needs to connect to the existing Exchange organization to retrieve its information.
  • The second record can be found under CN=Services, CN=Microsoft Exchange Autodiscover, CN=<FQDN of new Forest>. This will contain information regarding the target (i.e. new Exchange 2016) forest that the Outlook needs for migrated Mailboxes.
    This second record can be seen in the following screenshot:

CN=Microsoft Exchange Autodiscover

The keywords property of the SCP record contains the Accepted Domains of the new Exchange 2016 organization, like Exchangefun.nl, Corporate.Exchangefun.nl and target.qmm (the Quest target domain). This means when a new Accepted Domain is added to Exchange 2016, the Export-AutodiscoverConfig command needs to be run again.

The serviceBindingInformation property contain an LDAP link to the Exchange 2016 forest where Outlook clients can find information from the migrated Mailboxes.

Granting permissions

To avoid issues with Outlook clients of not migrated Mailboxes (that need to retrieve information from the old Exchange 2013 organization) we have to hide the exported SCP for these users. At the same time, we have to hide the original SCP record in Exchange 2013 for Mailboxes that have been migrated to Exchange 2016 (and where Outlook should NEVER receive old Exchange 2013 information).

To achieve this, create a Universal Security Group with a name like “Migrated_Users”, remove the Authenticated Users group from the exported SCP and grant the Migrated_Users Security Group Read permissions on this object as shown in the following screen shot:

Remove Authenticated Users

At the same time we have to grant an explicit deny Read permission to the Migrated_Users Security Group on the original SCP record as shown in the following screenshot:

Explicit Deny


Now when a Mailbox is migrated using QMM and the CPUU tool, add the user to the Migrated_Users Security Group. At this moment its Outlook client will no longer find the original (Exchange 2013) SCP record but the exported SCP record. Outlook will then connect to the target Active Directory forest with Exchange 2016 and retrieve the correct information.

Note. It took us quite some time when testing this scenario with different versions of Outlook (2010, 2013 and 2016) but the scenario explained here turned out to be working fine with these versions. But please test in your own test environment with various clients as well.

More information


Moving Mailboxes in a Hybrid Configuration – Part I

In three earlier blog posts I explained how to implement directory synchronization and how to create an Exchange hybrid configuration:

These steps will create a hybrid configuration between your on-premises Exchange 2013 environment an Exchange Online, but to move mailboxes from Exchange on-premises to Exchange online (or vice versa) you need to create an endpoint. This an on-premises Exchange 2013 server (but it can be more) where the Mailbox Replication Service (MRS) is running, used to move mailbox data from one server to another. The process is similar to an on-premises mailbox move where the MRS is responsible.

Create a migration endpoint

To create an endpoint you have to go to the Exchange Admin Center in Office 365 and login as an Office 365 tenant administrator. You can get there via the Microsoft Online Portal, select Admin | Exchange, or navigate directory to the Exchange Admin Center, and login as an Office 365 tenant administrator.

In the Exchange Admin Center dashboard, under Recipients select migration. At this point an empty screen will be shown:


Continue reading Moving Mailboxes in a Hybrid Configuration – Part I

Login failed because the mailbox you tried to access is being moved

In preparation of a migration from Exchange 2007 to Exchange 2013 (interorg, so new Active Directory and new Exchange deployment) I had to clean up the Exchange 2007 environment. There was one user that had a 4.5GB Mailbox with over 50,000 items in.

Continue reading Login failed because the mailbox you tried to access is being moved

Unable to delete Lync 2010 Front End Pool after migrating to Lync 2013

After a (successful) migration from Lync 2010 to Lync 2013 I wanted to decommission the old Lync 2010 servers. In my previous blog post I already explained why the CMS didn’t want to move, but the next issue was challenging as well.

Before removing the last Lync front-end server you have to remove all Lync 2010 objects from this front-end server. Well known issue for example is the conference directory that for some reason always stays at the front-end server.

Continue reading Unable to delete Lync 2010 Front End Pool after migrating to Lync 2013

Migrationwiz – Exchange migration in the cloud

When migrating one Exchange organization to another organization you have to do quite some work. The traditional methods include a lot of scripting, or a 3rd party tool like Quest or BinaryTree to migrate one Exchange environment to another.

Migrationwiz is a product that can perform the migration from the cloud, they offer E-mail migrations as a service. This migration can be from any messaging platform to any messaging platform, but for this blog I’ll focus on a migration from one Exchange platform to another Exchange platform (in different datacenters).


Continue reading Migrationwiz – Exchange migration in the cloud