Lync Mobility DNS Records

The DNS records required for Lync mobility can be a little confusing due to the fact that mobile clients will always connect to the external web services FQDN. In Lync 2010 the URL’s returned by the Lync Discover service for internal and external are the same external web services URL. In Lync 2013 the client is hard coded to look for a a single purpose built URL which is also the external web services URL.

Here is how I would recommend that DNS is configured:

Internal DNS
The internal DNS records cause the most confusion, and are often the reason internally connected mobile devices fail to connect.

lyncdiscoverinternal.sipdomain.com
A record or CNAME pointing to the Front End pool.

This requires that devices have installed the internal CA certificate, or a public certificate has been used that is already trusted by the device.

lyncdiscover.sipdomain.com
A record pointing to the external web services IP address. Using this record internally is not the recommend configuration.

In Lync 2010 you can actually get away with not including lyncdiscoverinternal.sipdomain.com in internal DNS; instead you just create lyncdiscover.sipdomain.com (a record that would normally only be included in external DNS) and resolve it to the external web services IP address. By doing this you get around the need to install the internal CA certificate. In Lync 2013 all clients now use the Lync Discover service, so it is not advisable to use this workaround. The reason being that you don’t want all Lync clients on your internal network connecting to the external Lync Discover service.

Using this configuration requires that traffic can hairpin out the firewall and back in again, which is also a requirement of the next mentioned and required DNS record. One trick that can be applied to both these records, is rather than pointing them to the external ISA interface, you point them to the internal interface, and enable the “local host” interface on the web listener associated to the Lync external web services rule. This enables ISA to receive the inbound request and process it locally, applying the rule and sending it back via the internal interface.

lync-web-external.domain.com
A record pointing to the external web services IP address.
This one confuses a lot of people because it doesn’t normally make sense to point an internal DNS record, to a services external IP address when that service is local. Regardless of whether you have used lyncdiscoverinternal or lyncdisover, the fact remains that this service will still always return the external web services URL, and it is for this reason we need to include the external IP address in internal DNS. If you don’t, because your internal DNS is authoritative for your domain, it will not return an IP address to internally connected mobile devices. I still don’t really understand Microsoft’s logic here but this is the recommended configuration.

External DNS
External DNS is much more clear cut and doesn’t require a heck of a lot of explaining.

lyncdiscover.sipdomain.com
A record pointing to external the external web services IP address.

This will normally be the external ISA server interface.

lync-web-external.domain.com
A record pointing to the external web services IP address. This will normally be the external ISA server interface.
For more information about LyncDiscover URL’s see this post.

 

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

Allow Microsoft Teams Auto Attendants and Calls Queues to make external calls

This helper script will help you check and configure Microsoft Teams Auto Attendants and Call Queues to make external calls. View on GitHub here. https://github.com/ucgeek/Microsoft-Teams-AA-and-Queue-Voice-Policy-Helper  

Azure Virtual Desktop vs Windows 365

Azure Virtual Desktop and Windows 365 are both cloud-based virtual desktop technologies provided by Microsoft. In this article we'll look at some of the key Azure Virtual Desktop vs Windows 365 differences.

Phishing Awareness Training for Office 365

Phishing Awareness Training for Office 365 is available in Microsoft Defender. It can test your user's awareness of this common scamming technique and provide learning tools to help them upskill.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

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

Allow Microsoft Teams Auto Attendants and Calls Queues to make external calls

This helper script will help you check and configure Microsoft Teams Auto Attendants and Call Queues to make external calls. View on GitHub here. https://github.com/ucgeek/Microsoft-Teams-AA-and-Queue-Voice-Policy-Helper  

Azure Virtual Desktop vs Windows 365

Azure Virtual Desktop and Windows 365 are both cloud-based virtual desktop technologies provided by Microsoft. In this article we'll look at some of the key Azure Virtual Desktop vs Windows 365 differences.

Phishing Awareness Training for Office 365

Phishing Awareness Training for Office 365 is available in Microsoft Defender. It can test your user's awareness of this common scamming technique and provide learning tools to help them upskill.

Azure Virtual Desktop & Windows 365 Licencing Requirements

This article details the Microsoft Azure Virtual Desktop and Windows 365 licencing requirements.

Azure Virtual Desktop Review

This Azure Virtual Desktop review reveals a virtual desktop solution ready for the modern workplace. It's modern, fast, and scalable.