Exchange Autodiscover & Lync

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  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 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 “”

In order to change this they:

  1. Request and install new certificates that included the 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 namespace
  5. Test
  6. Update build documentation
  7. Update DR documentation




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


Comments (20)
  1. anonymouscommenter says:


    Great article.

    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 and 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.

  2. 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…/lync-2013-known-issues-HA102919641.aspx

    I haven't check to see a fix for that was checked into the last update bundle.



  3. anonymouscommenter says:

    Hi Rhoderick

    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 the SRV record  which has a target of and in the case of  the SRV record  which has a target of This means that there is an SRV record per domain but it points to the same target 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?

    Many Thanks

  4. 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…/Autodiscover.xml
    . This fails.

    2. Autodiscover posts to…/Autodiscover.xml
    . This fails.

    3. Autodiscover posts to…/Autodiscover.xml
    This fails.

    4. Autodiscover performs the following redirect check using the looking for SRV record:

    5. Autodiscover uses DNS SRV lookup for, and then "" is returned.

    6. Outlook asks permission from the user to continue with Autodiscover to post to…/autodiscover.xml

    7. Autodiscover’s POST request is successfully posted to…/autodiscover.xml



  5. anonymouscommenter says:

    Hi Rhoderick,

    Thanks for the Excellent Post!!!

    Based on the above customer scenario, Per you description post you added the DNS entry , did the AutodiscoverInernalURI which was set to use the Loadbalancer FQDN changed to the, if so then shall we point the 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 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.

  6. Hi Shakthi

    In my customer’s case they were using a different namespace for Autodiscover in each of the many AD sites. For example:

    All of those names were on the relevant certificate. Since 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.


  7. anonymouscommenter says:

    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.



  8. 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?


  9. anonymouscommenter says:

    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 and also have DNS entry created for 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

  10. anonymouscommenter says:

    is there a reason why lync fails to access DNS after DNS is well configured?

  11. ShakthiRavi — that is a great question and one that I’m digging into for other reasons as well. I do all of this blogging etc. in my own time so I never get to do as much as I really want to 🙁


  12. Ronald – is this referring to an A record or SRV please?


  13. Hi Rohderick,

    well, you are correct. The SCP problem with Lync is that it doesn’t make sense for Lync querying SCP, if e.g. Exchange is not installed. So DNS is enough and DNS is also the choice for Lync finding all required resources.
    I would be happy if you could also check my blog article here, Thanks so much

  14. Hi Thomas,

    I did take a peek – the AutoD URLS are present in the Exchange 2013 schema, and are not listed on Exchange 2013 TechNet page. Your post has that reversed.

    I’d also suggest removing the internal and external URLs from the set-autodiscovervirtualdirectory command. Setting this to -ExternalURL ‘
    -InternalURL ‘‘ is also a tad confusing and we do not want customers to confuse the AutoD namespace with the EWS namespace.


  15. anonymouscommenter says:

    could you please comment if there are still issues with use of Exchange autodiscover DNS SRV records for Lync (client or server)?


  16. Just as a clarification to my previous post: I’m referring to Exchange 2013 and Lync 2013 (server and client) with all available CUs/updates.

  17. Hi Markus,

    Are you past that build?


  18. Thanks, Rhoderick, for he quick pointer to this KB article. This shall help us to verify client installations.


  19. anonymouscommenter says:

    Rhoderick, you said, "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?"

    I work for a subsidiary of a very large corporation, where we all have the same email domain,, and the main corporate office manages the inbound/outbound email flow of 20 or so separate Forests and Exchange environments using AD FS GalSync and
    email aliases like They also control the DNS namespace. We set our SIP address to the email address for simplicity. So when Lync (or non-domain joined Outlook clients) try to find the autodiscover they go to,
    when they really need to go to, or the dns namespace of whatever the child is. So the end result is those clients can never find the right autodiscover FQDN using DNS or srv records because they use the email address to look
    that up, instead of looking at the dns namespace the client host is hitting.


  20. anonymouscommenter says:

    Hi Rhoderick,

    For Exchange we can do this with SRV redirect, but this requires an update to the Lync 2013 client. See link above.

    Where can I find this update?

Comments are closed.

Skip to main content