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.
Hi Rhoderick,Thanks for the Excellent Post!!!Based on the above customer scenario, Per you description post you added the Autodiscover.domain.com DNS entry , did the AutodiscoverInernalURI which was set to use the Loadbalancer FQDN changed to the autodiscover.domain.com, if so then shall we point the Autodiscover.domain.com DNS entry to the same Loadbalaner IP and when we do this do we achieve the same experience as it was before for the client connection to get loadbalanced as the SCP is getting updated to use the autodiscover.domain.com and this eventually points the LB and the client experience is same and with this change we also full fill the Lync requirement to work better with Exchange.Review and correct me if the above said configurations are correct or any changes needed for my better understanding.
Hi Shakthi In my customer's case they were using a different namespace for Autodiscover in each of the many AD sites. For example:NA-Mail.contoso.comEUR-Mail.contoso.comAPAC-Mail.contoso.comAll of those names were on the relevant certificate. Since Autodiscover.contoso.com was not on the cert, they had to re-issue the cert with that additional name and enable that on the LB device.As to pointing to the same LB VIP or to use a separate one that is going to depend on the LB that you have. Are there any issues/challenges with doing that. I don't know, that's up to the LB.We continued to have the same client experience, as domain joined Outlook clients on the internal network look for SCP first. Only if the SCP lookups fail will they drop to DNS.Cheers,Rhoderick
Hi Rhoderick,Is there a technical reason why Lync cannot use SCP? It would be good to have the option at least, in the case where the DNS zone for the primary email is not something easy to update, and the customer domain is all internal with domain joined devices.Cheers,David
Hi David,I think about the simplest denominator -- simple phones and other UC devices. They are not domain joined and resort to using DNS to locate AutoD.If customer has internal only DNS zone, that would be a challenge for internet located devices. What sort of situations do you encounter where you are unable to update the zone for the primary SMTP namespace? That sounds interesting - anything you can share on that?Cheers,Rhoderick
Thanks for the update!!!I have a small query i have multiple SCP records in my environment and have set autodiscover internal uri to all them as https://autodiscover.domain.com/autodiscover/autodiscover.xml and also have DNS entry created for autodiscover.domain.com which points to a LB device and has all the CAS servers added to the LB and set the site scope accordingly and mine is a Hybrid Exchange environment and with respect to onpremise environment the client selects one SCP and makes the connection without issues but for the outlook client with a cloud user who are domain joined I can see multiple SCP lookup performed and failed ( as it would) with each of the available SCP in the site before it makes appropriate connection to cloud and my concern is why there are many scp lookup performed can't it pickup just one SCP and once its get to know it fails and fall back to the DNS and then do the rest of the redirection . I need to know is this the default behavior of the domain joined cloud user outlook. I do have a similar requirement for Lync like the above customer and also need to know will these SCP failures cause any issues with Lync EWS or its just the DNS entry which Lync requires to talk to Exchange via EWS which I already made available for my environment and pointed to the LB which contains the CAS servers. Kindly clarify on the same