250 Hello

Random Musings on Exchange and Virtualization

Exchange Autodiscover & Lync

Exchange Autodiscover & Lync

  • Comments 18
  • Likes

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!!

>>>

 

Can You Help Us?  -- Yes !

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!

US

Canada

For all other areas please use the US contact point.





Comments
  • HI

    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 @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

    office.microsoft.com/.../lync-2013-known-issues-HA102919641.aspx

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

    Cheers,

    Rhoderick

  • 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 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?

    Many Thanks

  • 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:

    social.technet.microsoft.com/.../6818.exchange-2010-multi-tenant-autodiscover-service.aspx

    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.

    Cheers,

    Rhoderick

  • 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.com
    EUR-Mail.contoso.com
    APAC-Mail.contoso.com

    All 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

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

  • 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 :(

    Cheers,
    Rhoderick

  • Ronald - is this referring to an A record or SRV please?

    Cheers,
    Rhoderick

  • 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
    Thomas

    http://lyncuc.blogspot.de/2013/01/lync-and-exchange-web-services-ews-and.html

  • 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 'https://ews.domain.name/autodiscover/autodiscover.xml' -InternalURL 'https://ews.domain.name/autodiscover/autodiscover.xml' is also a tad confusing and we do not want customers to confuse the AutoD namespace with the EWS namespace.

    Cheers,
    Rhoderick

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

    Thanks,
    Markus

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Post Comment Fixer