Tag Archives: Autodiscover

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.

Export-AutodiscoverConfig

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

Summary

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

 

SSL Certificate warning during or after Exchange server setup

When installing a new Exchange server (2013/2016/2019) in an existing environment, Microsoft recommends installing this new Exchange server in a separate Active Directory site, configure the server there and then move the server to its production Active Directory site.

The reason for this is Outlook and the Service Connection Point (SCP) in Active Directory. Somewhere during the installation process a new SCP is created in Active Directory, but when created it is not configured and points to the FQDN of the Exchange server instead of the more general Autodiscover.contoso.com/Autodiscover/Autodiscover.xml URL. When an Outlook client accidentally discovers this unconfigured SCP it will try to connect to the new server instead of the Autodiscover FQDN which will result in a certificate warning message similar to the following:

image404

To avoid this, the SCP should be configured as soon as it is created in Active Directory (and this is during setup itself).

Tony Murray, also an MVP, has written a PowerShell script (Set-AutodiscoverSCPValue.ps1) that will check the existence of the Exchange server object in Active Directory, and when it is created by the Exchange setup application, it immediately sets the correct Autodiscover value in its SCP.

When you run the script it will check every 5 seconds (time is configurable) for the newly created server object, and when it finds it, it will set the correct value as shown in the following screenshot:

set-AutodiscoverSCPValue

From this moment on Outlook client can safely discover this SCP record, and it will be automatically connected to the correct Autodiscover URL and therefore the SSL Certificate warning will not appear (assuming the original servers are configured correctly of course).

More information and download – https://gallery.technet.microsoft.com/office/set-autodiscoverserviceinte-3930e163

Improve autodiscover performance

Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.

The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:

  • Service Connection Point (SCP) in Active Directory. This is used by domain clients.
  • Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
  • Autodiscover.contoso.com (standard autodiscover mechanism)
  • Autodiscover redirect to autodiscover site (often used by hosting companies)
  • Autodiscover SRV records in DNS (sometimes used by hosting companies)
  • Autodiscover redirect to Office 365 (outlook.com)

If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:

image

Continue reading Improve autodiscover performance

Autodiscover in a hybrid scenario

In the previous articles I showed you how to implement DirSync, create an Exchange hybrid environment with a migration endpoint and how to migrate Mailboxes from Exchange on-premises to Exchange Online. Not a single word on autodiscover though, and even when autodiscover is pointing to your on-premises Exchange environment, it continues to work for Mailboxes that have been migrated to Exchange Online. This is one of the advantages of an Exchange hybrid scenario.

This is what happens: when you move a Mailbox from Exchange on-premises to Exchange Online, the Mailbox on-premises is converted to a Mail-Enabled User (Remote Mailbox) and a target address is set to Exchange Online (i.e. user@tenantname.mail.onmicrosoft.com).

When an Outlook client does an Autodiscover request to the Exchange environment it detects the user is a Mail-Enabled User, and that a target address is set. Based on this target address a new Autodiscover request is initiated. So, Outlook does a request for a user called kim@exchangelabs.nl, Autodiscover returns a Mail-Enabled User with target address kima@exchangelabsnl.mail.onmicrosoft.com. Next, Outlook wil try an Autodiscover request for this SMTP address.

Continue reading Autodiscover in a hybrid scenario

Creating an Exchange 2013 Hybrid environment

Updated: November 11, 2015

In a series of blog posts we will create an Exchange hybrid environment, where the on-premises environment consists of Exchange 2013 multi-role servers. Creating such an environment consists of several steps:

  • Implementing Directory Synchronization.
  • Running the Hybrid Configuration Wizard.
  • Creating Migration Endpoints.
  • Moving Mailboxes to Exchange Online.

Current Infrastructure

The current infrastructure consists of two Exchange 2013 multi-role servers and two Exchange 2013 Edge Transport servers, all of which are fully patched and running the latest version of Exchange 2013 (i.e. Exchange 2013 CU8). An Office Web Apps 2013 servers is also involved for rendering attachments in Outlook Web App.

A Kemp LM3600 LoadMaster is used for distributing incoming client requests from the Internet across both servers. SMTP is directed to two Exchange 2013 Edge Transport servers, which are subscribed to the internal Exchange 2013 servers, as shown in Figure 1.

image

Figure 1. The starting point when creating a new Hybrid environment.

In Office 365 we have are using a tenant called ExchangeLabsNL, for Exchange Online the tenant name is not important, but for SharePoint Online it is important. The corresponding SharePoint Online environment is accessible via Exchangelabs.nl.sharepoint.com, so the tenant name is important after all.

Note. The tenant name cannot be changed later on, so don’t choose any silly names for your tenant. One day you will regret this.

Directory Synchronization Server

In our on-premises environment we are going to install a dedicated Directory Synchronization server. This is not really a hard requirement since DirSync can be installed on a Domain Controller as well. Personally I prefer to use a dedicated DirSync server and keep all Domain Controllers identical.

Exchange Hybrid Server

There’s a lot of confusion about the Exchange Hybrid server when creating an Exchange Hybrid environment and to be honest, it took quite some time for me as well to get rid of the confusion.

A true hybrid server does not exist, but in Microsoft terminology, the hybrid server is the Exchange server where the Hybrid Configuration Wizard (or HCW) is run to configure a Hybrid Configuration. And the Hybrid Configuration is nothing more than some information written in Active Directory so it can be easily found and used by all Exchange servers in the organization. In Figure 1, the hybrid server can be either server EXCH01 or server EXCH02.

An additional Exchange 2013 server can be added as a hybrid server. You can even use a dedicated FQDN like hybrid.contoso.com for this to separate SMTP and migration traffic from/to Office 365 form regular client traffic accessing the normal Exchange servers EXCH01 and EXCH02.

Free/busy information in this scenario for example is not using the dedicated hybrid server, since it is not possible to designate this kind of traffic to dedicated servers. When users in Exchange Online are creating new meetings with users in Exchange on-premises, the free/busy information is found using the normal Exchange EWS virtual directory. This information in turn is found using normal Autodiscover requests.

So, before you start building your Exchange Hybrid environment you have to make absolutely sure your starting point is working flawlessly, internally and externally. If you run into issues with AutoDiscover, free/busy, out-of-office or Certificate errors you have to fix these first before continuing with the hybrid configuration. One great tool to test your existing environment is the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) and of course your own Outlook clients Glimlach 

Note. If you are running Exchange 2010 you can also use the existing Exchange 2010 servers to create a hybrid environment without adding Exchange 2013 servers (although you have to be absolutely sure about this, Exchange 2010 is no longer in mainstream support). If you want to use Exchange 2013 in your existing Exchange 2010 environment you have to start a coexistence project first. When this is fully functioning (without error of course) you can continue with the DirSync and hybrid configuration.

When all is running fine you can continue with implementing the DirSync solution, as outlined in the following blogpost: https://jaapwesselius.com/2015/05/13/implementing-directory-synchronization/