Lync Discover URL’s Summary

This is a summary of my understanding of the lyncdiscover records and the processes associated to them. Please let me know if you think I have misunderstood anything 🙂

There are 2 records which Lync will query in order:
1. lyncdiscoverinternal.<domain>
2. lyncdiscover.<domain>

NOTE: Some clients also continue on to query other records, however this article focuses only on lyncdiscover URL’s.

lyncdiscoverinternal.<domain> should be a CNAME or A record to the Lync Front End server and only exist on the internal network.

lyncdiscover.<domain> should be an A record pointing to the IP address of the external web services which is normally an ISA reverse proxy. This record should also only exist externally.

It is quite common for the lyncdiscoverinternal.<domain> record to be intentionally and unintentionally omitted from internal DNS records. Many people do not see its worth due to the fact that all mobile client traffic is hair pinned via the external web services whether connected internally or externally. However with Lync 2013 the lyncdiscoverinternal.<domain> is far more important as all clients now attempt to resolve a lyncdiscover record before moving on to older methods such as SRV. By not having a lyncdiscoverinternal.<domain> record, ALL Lync 2013 clients that find a lyncdiscover.<domain> record will effectively be querying external web services – you probably dont want this to happen right?

For more information on the DNS records required for mobility see this post.

Lync Discover Process for Mobile Clients (including Windows Store App)

Internal – lyncdiscoverinternal.<domain> is resolved to the internal Autodiscover web service which returns a list of service URL’s. Because both the internal and external Mobility Service URL’s for Lync 2010, and the UCWA URL for Lync 2013 are all associated to the external Web Services FQDN, mobile traffic is routed externally via the reverse proxy regardless of location.

External – lyncdiscover.<domain> is resolved to the external Autodiscover web service (via the reverse proxy) which returns a list of service URL’s. The mobile client will use this information to connect to the external Web Services FQDN.

Lync Discover Process for Desktop Clients

Internal – lyncdiscoverinternal.<domain> is resolved to the internal Autodiscover web service which returns a list of service URL’s. The client uses this information to connect to the Front End server or pool.

External – lyncdiscover.<domain> is resolved to the external Autodiscover web service (via the reverse proxy) which returns a list of service URL’s. The client uses this information to connect to the Edge servers SIP access interface.

You can use the Lync Connectivity Analyzer to learn more about the service URL’s returned during Lync Discovery.

One of the most helpful articles in my quest to understand the Lync Discover process was by Jeff Schertz, Cheers! – http://blog.schertz.name/2013/07/understanding-lync-2013-mobility/

Andrew Morpeth
Andrew Morpethhttps://ucgeek.co/author/amorpeth/
Andrew is a Modern Workplace Consultant specialising in Microsoft technologies based in Auckland, New Zealand; Andrew is a Director and Professional Services Manager at Lucidity Cloud Services and a Microsoft MVP.

Related Articles

2 COMMENTS

  1. "lyncdiscover. should be an A record pointing to the IP address of the external web services which is normally an ISA reverse proxy. This record should also only exist internally."

    Internally, shouldn't it be external only?

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Andrew Morpeth
Andrew Morpethhttps://ucgeek.co/author/amorpeth/
Andrew is a Modern Workplace Consultant specialising in Microsoft technologies based in Auckland, New Zealand; Andrew is a Director and Professional Services Manager at Lucidity Cloud Services and a Microsoft MVP.

Latest Articles