JRB - Fotolia
Check your hybrid Outlook Autodiscover performance
IT shops with hybrid Office 365 and on-premises Exchange mailboxes need to know how Outlook Autodiscover works when mailboxes haven't migrated.
Before migrating to Office 365, learn how the Exchange Autodiscover operation executes in a hybrid scenario where mailboxes exist on-premises and in the cloud.
The Outlook Autodiscover service is a critical component of an Exchange deployment. For an organization running an on-premises deployment, the key scenarios of how Autodiscover operates -- internally and externally -- affect a client connection to the corporate network.
When connected to a corporate network, the domain-joined machine that runs Outlook uses a Service Connection Point (SCP) to retrieve the Autodiscover endpoint. Outlook creates an SCP each time an Exchange Client Access Server (CAS) is installed, and the SCP provides the URL used to contact the Exchange Autodiscover service.
When Outlook cannot make a direct connection to an SCP -- such as when connecting externally via an Internet connection -- Outlook attempts to connect to the Autodiscover service via two pre-defined URLs based on the SMTP domain of the user's email address. These URLs must reach the on-premises Exchange CAS running the Autodiscover service.
The TargetAddress attribute
In a hybrid setup, in which not all mailboxes have been migrated to Office 365, Autodiscover points to the on-premises Exchange infrastructure so that it remains functional for on-premises mailboxes.
Active Directory TargetAddress attribute is a key concept in how Exchange Autodiscover functions in a hybrid scenario for mailboxes that are migrated to Office 365. The TargetAddress attribute is populated on an Active Directory object whose corresponding mailbox is on Office 365, and serves to ensure that the Autodiscover request is redirected to the specified target address. It is also used during hybrid routing to direct messages to Office 365.
The target address is based on the <tenant>.mail.onmicrosoft.com coexistence domain -- <tenant> is the unique name chosen when an organization signs up for Office 365. For example, Fabrikam, a fictional Microsoft company, might join Office 365 and choose fabrikam.onmicrosoft.com as its initial Office 365 domain. The coexistence domain is automatically configured using the 'mail' subdomain in the format <tenant>.mail.onmicrosoft.com. In Fabrikam's example, the coexistence domain is fabrikam.mail.onmicrosoft.com.
When configuring an Exchange hybrid deployment, the coexistence domain is added to the on-premises Exchange organization's email address policies. This ensures that all on-premises objects get a secondary SMTP proxy address based on alias@<tenant>.mail.onmicrosoft.com. This new recipient information is then synchronized into Office 365 for Exchange Online.
Outlook autodiscover redirection
Part of migrating a mailbox to Office 365 is configuring the associated on-premises Active Directory user object's TargetAddress attribute with the corresponding alias@<tenant>.mail.onmicrosoft.com address. This is key to how Autodiscover requests are redirected to Office 365 once a mailbox migrates to Exchange Online.
In a hybrid scenario, an Autodiscover request made after a mailbox migration is presented to the on-premises Exchange CAS as normal. However, the presence of the target address attribute value on the associated Active Directory object will cause the on-premises CAS to issue a redirect request to the specified TargetAddress namespace. With Fabrikam, this redirection goes to the fabrikam.mail.onmicrosoft.com namespace, which itself points to Office 365. Office 365 will accept this Autodiscover request and locate the correct recipient -- the alias@<tenant>.mail.onmicrosoft.com value contained in the Autodiscover request was synchronized into Office 365 against the relevant object.
Testing redirection
One way to see this redirection in action is to use the Autodiscover test feature in the Outlook client. To do this, perform the following steps:
- While holding down the control key, right-click the Outlook icon in the system tray and choose the Test E-mail AutoConfiguration option;
- In the resulting window, ensure the correct email address and password are specified for the user account. The Use AutoDiscover option should be the only checkbox selected;
- Click the Test button to start the Autodiscover test;
- Once the test completes, click the Log button to reveal the log output of the Outlook Autodiscover test;
- Scroll through the various Autodiscover connection attempts in the log output and check the Autodiscover URL redirection based on the <tenant>.mail.onmicrosoft.com SMTP domain;
Ultimately, the redirection takes place to the autodiscover-s.outlook.com namespace in Office 365.
If things didn't work as expected, use Outlook to view the Autodiscover redirection for troubleshooting help. The Remote Connectivity Analyzer (RCA) tool performs a more comprehensive Autodiscover test. The RCA tool also completes key Autodiscover test stages, such as DNS host name resolution, TCP port 443 connectivity against the Autodiscover host name and SSL certificate validation. In the Autodiscover redirect scenario, the RCA tool sends an Autodiscover POST request and retrieves an Autodiscover XML response. This XML response is detailed in the tool output and the important response to check for is the <RedirectAddr> response that will look similar to this:
<RedirectAddr>[email protected]</RedirectAddr>
Neil Hobson is a U.K.-based Microsoft consultant with a background in the design, implementation and support of infrastructure systems covering Active Directory, Windows Server, Exchange and Lync. He is currently focused on Office 365 in technologies such as Exchange Online, Lync Online, SharePoint Online, Yammer and Office ProPlus. He is also focused on the associated areas of identity, networking, migration and service integration. Hobson is a member of the Chartered Institute for IT (MBCS) and was also a Microsoft MVP for Exchange Server from 2003 to 2010.
