Notes from the Field

I have been onsite working on remediating a partially completed Exchange 2007 to Exchange 2010 migration. This environment was then configured for Exchange Online Hybrid using ADFS 2.0 and Dirsync.

After reviewing the Autodiscover configuration, I discovered that something wasn’t right. In addition to this, I had received the following issues list from the customer.

Symptoms

1. Outlook for Office 365 mailboxes is not able to be configured using Autodiscover. This occurred on both domain and non-domain joined machines.
2. Outlook on domain joined machines is intermittently unable to be configured using Autodiscover
3. Outlook on domain joined machines is intermittently very slow

These symptoms combined told me that there was likely more than one issue in effect here due to the fact that both domain joined and non-domain joined machines were affected.

Topology

The network architecture had multiple Active Directory sites across all regions with Client Access Servers located in all regions but not all sites.

Resolution

1. Office 365 mailboxes unable to be configured using autodiscover

Upon investigating where the internal DNS record for autodiscover.domain.com pointed to, I discovered that this record was being pointed to one of the Exchange 2007 Client Access Servers. As part of the Hybrid Configuration for Office 365, Autodiscover records are required to be updated to point to the Exchange 2010 hybrid servers.

After updating the internal DNS record, Autodiscover began working correctly for non-domain joined machines. For domain joined machines, this process began working intermittently however another piece of the puzzle was required in order to fix this issue.

2. Outlook on domain joined machines is intermittently unable to be configured using Autodiscover

and

3. Outlook on domain joined machines is intermittently very slow

Knowing that Active Directory SCP records will be in effect here, I began looking into the configuration of two attributes assigned to the various SCP records.

• serviceBindingInformation – This attribute returns what is effectively the Autodiscover url to the domain joined machine
  
• keywords – This attribute returns a variety of values depending on configuration, but in this case, the value we are interested in is Site=
  

In this case, all SCP records, except for the 2 Exchange 2007 Client Access Servers were configured with a Site= keyword.

This value however only contained the site name for the location where the Client Access Server was installed.

When SCP lookup is conducted, AD is queried for the site name of the Client. The lookup then tries to match this with a site= value in the keyword attribute of the SCP record.

Considering this, a site name will nearly never be matched, as 90% of the Client Access Servers are located in datacentres in this environment.

The fall back behaviour of SCP when no match is found, is that where the SCP URL record contains at least one keyword that starts with Site= but none of these keywords read Site=siteName.

So what does this all mean? This means that in effect, any SCP record with a value of Site=Anyvalue could be returned to the client. My testing showed that this is in fact what was occurring. The first SCP record in the list by alphabetical order was being returned to the client. It just turned out that this server was located in a datacentre in the UK.

Armed with all of this information, I recalled a set-clientaccessserver setting called autodiscoversitescope. This setting allows us to bind Active Directory site names to specific client access servers. In effect, what this does on the back end is populate the keywords attribute with site= values for all sites that are defined in the autodiscoversitescope.

Once all of the Active Directory Sites were assigned to the autodiscoversitescope attribute on the appropriate regional Client Access Servers, all clients were now redirected to the local servers for connection.

This configuration resolved both of the identified issues above as SCP lookups were now being completed locally on the Client Access Servers.