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. **
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.
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:
** - That 8 foot tall yellow bird still freaks me out!!
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.
Where multiple sip domains and associated smtp domains exist does this pose a challenge. For instance exchange 2010 and lync 2010 may support multiple sip and smtp domains like @a.com and @b.com. In this example do you need multiple autodiscover a records for each lync sip domain and multiople virtual directories on exchange along with the other items you mention like certifcate entries etc.
That's my understanding. There is an option to use DNS SRV records, but there is currently a known issue with this for the Lync 2013 client
I haven't check to see a fix for that was checked into the last update bundle.
Thanks for the rapid reply.
I think the EMS powershell set command to set the url and virtual diorectories on exchange only allow you to set one external and internal virtual directory etc - thats my understanding but i could be wrong.
When you mention the alternative using SRV records are you proposing this method to reduce the complexity over using the autodiscover A record method. For instance for each sip domain you have an SRV record in the case of a.com the SRV record _autodiscover._tcp.a.com which has a target of mail.a.com and in the case of b.com the SRV record _autodiscover._tcp.b.com which has a target of mail.a.com. This means that there is an SRV record per domain but it points to the same target mail.a.com thereby reducing the number of virtual directories and SAN names in certificates etc. I am not sure if the SRV standard supports targets outside of its zone but certainly Windows DNS manager allows targets to be set outside of the SRV zone so it may be possible and supported?
That's correct - in Exchange we set a single URL onto the various directories. Using ADSI edit to fnangle and add extral URLs onto them is not supported.
For Exchange we can do this with SRV redirect, but this requires an update to the Lync 2013 client. See link above.
We can target a machine out of the zone, and it would be up to the app to decide if that is OK. For example my fried Ed wrote this post here:
In this example, the Autodiscover service does the following when the client tries to contact the Autodiscover service:
1. Autodiscover posts to testorg1.org/.../Autodiscover.xml. This fails.
2. Autodiscover posts to autodiscover.testorg1.org/.../Autodiscover.xml. This fails.
3. Autodiscover posts to autodiscover.testorg1.org/.../Autodiscover.xml This fails.
4. Autodiscover performs the following redirect check using the looking for SRV record:
5. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.testorg1.com, and then "mail.contoso.com" is returned.
6. Outlook asks permission from the user to continue with Autodiscover to post to mail.contoso.com/.../autodiscover.xml.
7. Autodiscover's POST request is successfully posted to mail.contoso.com/.../autodiscover.xml.