Via this blog we have discussed the fundamentals of Exchange Autodiscover, and also issues around the Set-AutodiscoverVirtualDirectory cmdlet.

At this point the message should be out there with regards to how Outlook functions internally and externally to locate Autodiscover and the difference that having the workstation domain joined makes.   Lync on the other hand is a different beastie!

Both the Outlook Client and the Lync client want to get to the Exchange Autodiscover endpoint, but they differ in how to get to Sesame Street. **

Same But Different

At one of my recent engagements the customer experienced a situation around Lync 2010 and Exchange 2010 integration.  Exchange was successfully upgraded to Exchange 2010, and OCS was still in use.  When piloting Lync 2010 and the Lync 2010 client they noted errors in the Lync client.  There were a couple of reasons for this.  The required configuration on the load balancer was not in place, and the device’s firmware was not at the required build level.

When we investigated what Lync and Exchange Autodiscover were doing, we noted that Lync was not locating the Exchange Autodiscover endpoint.  Hmm.  That’s a  bit strange, innit? Outlook was running perfectly, and all the domain joined clients were always able to located Autodiscover by querying for the SCP.  The Lync client on the other hand does not leverage SCP when locating Exchange Autodiscover.

Dave Howe’s whitepaper Understanding and Troubleshooting Microsoft Exchange Server Integration discusses this in more detail and is a great read!  The one line that distils the important message is:

Unlike Outlook, which uses an SCP object to locate the Autodiscover URL, UC clients and devices will only use the DNS-based discovery method.

There is also a flow diagram in the whitepaper showing the DNS records used.

Note that nowhere in Dave’s article does he change or view the properties of the Autodiscover virtual directory.  The same is also true in Prerequisites for Integrating Microsoft Lync Server 2013 and Microsoft Exchange Server 2013.

There are some differences between Exchange 2007 and 2010 with regards to how the requests get serviced.  Exchange 2007 only does POX  (Plain Old Xml) whereas newer Exchange does SOAP (Simple Object Access Protocol) in addition.  Lync can leverage SOAP, Outlook kicks it old School with POX.

Letting Lync Play Nicely With Exchange Autodiscover

The customer above had deployed Exchange, but had not created any internal DNS records for Autodiscover.domain.com.  Technically this was not needed for their Exchange + Outlook design, as they have an environment with HA load balancers and multiple CAS servers behind each load balancer.  Their Autodiscover namespace had been set as the load balancer FQDN.  As such the FQDN Autodoscover.domain.com was not on any of the Exchange CAS Certificates.  And as mentioned in the busting Autodiscover myth post on Set-AutodiscoverVirtualDirectory their Autodiscover URI was previously configured by running:

Set-ClientAccessServer  –AutoDiscoverServiceInternalUri “https://lb.contoso.com/Autodiscover/Autodiscover.xml”

In order to change this they:

1. Request and install new certificates that included the Autodiscover.domain.com namespace
2. Update the service bindings on Exchange to use the new certificate
3. Update the configuration on the load balancers
4. Create internal DNS entries for the Autodiscover.domain.com namespace
5. Test
6. Update build documentation
7. Update DR documentation

Cheers,

Rhoderick

** - That 8 foot tall yellow bird still freaks me out!!