Lync client sign-in and DNS records recommendations

Ståle Hansen 9 Comments

This article was last updated 23.12.14

The Lync 2013 clients uses lyncdiscover to find the pools and url’s they need to sign in to. I have spent a couple of days trying to figure out the most restrictive way to DNS records where all clients work and here is my recommendation regarding internal DNS records and where the clients should sign in from. I will start with the conclusion, and then continue with some background information and finish with some test results. This article does not talk much about external DNS records since they are the same as for Lync 2010, mostly.

Conclusion

General advice

  • This applies to split-brain DNS scenarios where you have the same domain internally and externally
    • Like sipdomain.com internally and sipdomain.com externally
    • Recommendation is to use public sertificates on internal servers
    • It is more expensive because you need more SAN names in the certificate, but unmanaged clients with the Lync desktop client, Windows Store App and the Windows Phone Lync mobile clients will just work
  • This applies to disparate scenarios where youhave a different domain internally than externally
    • Like sipdomain.local internally and sipdomain.com externally
    • Recommendation is to use public certificates on internal servers, unless you have a .local type domain, then you must use internal PKI to issue the certificates
  • However, the mobile clients does not need to trust your internal CA, they will get their external sign in location without certificate issues

Internal DNS

  • Front End Server nameorpoolnamefqdn
    • lyncpool.sipdomain.com -> Internal Front End server IP address or servers if it is a DNS LB Enterprise Pool
  • Consolidated simpleurlfor meet,dialin, scheduling and admin
    • lync.sipdomain.com -> STD edition server IP or HLB HTTPS IP if it is Enterprise Edition
  • Internallyncdiscover record forautodiscover of Lync services
    • lyncdiscoverinternal.sipdomain.com -> STD edition server IP or HLB HTTPS IP if it is Enterprise Edition
    • Note: Will not work for Lync mobile one WP8, you need to publish lyncdiscover.sipdomain.com -> external IP address fo the external web services published by a reverse proxy
  • External web servicesFQDN
    • webext.sipdomain.com -> external IP address fo the external web services published by a reverse proxy
    • Why add webext in the internal DNS? Mobile clients will always sign in externally from the external web services
  • Legacy record for Lync desktop client and someUCMA applications that require to resolve this record
    • sip.sipdomain.com ->  Internal Front End server IP address or servers if it is a DNS LB Enterprise Pool
  • LegacySRV record, to be sure desktop client works always
    • _sipinternaltls._tcp.sipdomain.com
  • Remember Exchange Web services and autodiscover for the full integration. I recommend using A record for each mail\sipdomain in your deployment. Also remember to specify internal urls on Exchange
    • autodiscover.sipdomain.com
    • SRV records are supported, but I do not recommend using them, historically, if something breaks it’s always the SRV records, I have therefore found that A records are more robust

DNS entries example:

dns2

Lync mobile and media flow

The mobile client will do media internally only if it can do direct connectivity to other clients or the servers

path1

If there is no direct connectivity the mobile client will send media via AV Edge because it is always an external client and this is normal external behavior

path2

I did a talk on this subject at TechEd Europe 2014, check 10 minutes in to the recording at channel9

Front End server certificate entries

  • Subject Name
    • STD edition FQDN or Enterprise Edition pool FQDN
  • Subject Alternate Name
    • Enterprise Editon Front End server FQDN
    • SimpleURLFQDN
      • Lync.sipdomain.com
    • Lyncdiscoverinternal.sipdomain.com
      • One for each sipdomain so you wont get a redirect message in the clients
    • Sip.sipdomain.com
      • One for each sipdomain so you wont get a redirect message in the client

The challenge is Bring Your Own Device (BYOD)

Lync 2013 timeframe introduced Enterprise grade communication with voice, video and application sharing on mobile devices, tablets and slates.

  • These devices are not joined to the domain
  • They do not trust the internal PKI root CA
  • They are connected wireless
  • The users does not accept not being able to use Lync from their devices
  • The users does not accept performance issues when using voice, video and appsharing

That is why this topic is important, make sure that the BYOD devices are treated as first class citizens internally in your network. That is why it is important that as much of the traffic is internal against the internal Lync topology and that media traffic is optimized. I also believe that the wireless BYOD devices should be treated as external clients, but reach the internal resources they need for succeeding with voice, video and application sharing. Remember to OPTIMIZE your wireless network and redesign it with end to end QoS and fast handover between access points. Watch this cool video by Aruba and think that all of these devices are also going to run Lync and Skype

Background

With Lync Server 2013 the Lync team introduced Lyncdiscover as the default method for automatically finding the best registrar for all clients.To understand Lyncdiscover I recommend reading these posts by MVP Jeff Schertz

Key Takeaways from these excellent blog posts

  • The discovery process for all clients is will hit the following records in this order
    • lyncdiscoverinternal.domain.com (A record)
    • lyncdiscover.domain.com (A record)
  • The Lync 2013 desktop client is the only client that will fall back to legacy recordsiflyncdiscover is not present
    • _sipinternaltls._tcp.domain.com (SRV record)
    • _sip._tls.domain.com (SRV record)
    • sipinternal.domain.com (A record)
    • sip.domain.com (A record)
    • sipexternal.domain.com (A record)
  • When the mobile clients queries lyncdiscover and internal and external web service URL is returned
    • They will in fact only use an external UCWA URL pointing to external web services
    • That’s why you need to add the external web service A record in your internal DNS server
  • When Lync 2013 desktop client and the Windows 8 App queries lyncdiscover, the internal and external registrar FQDN’s are returned
    • That is why the Windows 8 App behaves differently than the mobile clients, it will sign in the same way as the desktop client
    • The Windows 8 app will not try the legacy records if lyncdiscover is not present

I spent some days validating the conclusion at the top of this post

Here is what I found

Sign in experience with the July 2013 Cumulative release of the clients

  • None of the clients trusted the internal CA
  • iPad
    • Signed in with directly, no warnings, no delay
  • iPhone
    • Signed in with directly, no warnings, no delay
  • Android
    • Gave a redirect warning on the certificatebecauselyncdiscoverinternal was not the subject name of the certificate
      • Was able to continue out of there
      • The certificate warning never popped up again
      • This is a one time pop-up
  • WP8
    • Was unable to connect to the server
    • No configuration setting helped
    • Could see in the log that it resolved the webext entry, but timed out after that
    • Maybe this will be fixed in the future
    • This is why you should just use lyncdiscover and point it at the external web services IP if you want to support WP8 devices at the time of writing
  • Lync 2013 desktop client
    • Could sign in as soon as the Root CA certificate was added to the trusted root certificates store on the client
  • Lync Windows 8 App
    • Could sign in as soon as the Root CA certificate was added to the trusted root certificates store on the client
  • Lync Phone Edition
    • Will use DHCP to find the registrar and download the root certificate on its own and sign in successfully

Meeting join experience when simple URL’s where pointing to the Front End server

  • None of the clients trusted the internal CA
  • iPad
    • Logged straight in, no warnings, all modalities accessible
  • iPhone
    • Logged straight in, no warnings, all modalities accessible
  • Android
  • WP8
    • Somehow I was able to sign in once with the WP8 client, not sure how, may have logged on over 3g externally
    • All modalities accessible, traffic was internal over the wifi connection
    • After removing the cached credentials I never could log on again
  • Lync 2013 desktop client
    • Meeting join as expected with internal clients when they trust the root CA
  • Lync Windows 8 App
    • Meeting join as expected with internal clients when they trust the root CA

Picture of all the clients in the same conference internally

Media flow

  • None of the clients trusted the internal CA
  • The mobile clients will behave just like normal clients in terms of media flow, internal when they are internal and external when they are external and so on
  • iPad
    • Internal IP, media went with direct connectivity, verified in the SIP log
  • iPhone
    • Internal IP, media went with direct connectivity, verified in the SIP log
  • Android
    • Internal IP, media went with direct connectivity, verified in the SIP log
  • WP8
    • Internal IP, media went with direct connectivity, verified in the SIP log
  • Lync 2013 desktop client
    • Internal IP, media went with direct connectivity, verified in the SIP log
  • Lync Windows 8 App
    • Internal IP, media went with direct connectivity, verified in the SIP log

9 thoughts on “Lync client sign-in and DNS records recommendations”

  7. For the internal DNS, you mention that lyncdiscoverinternal will not work for Lync mobile one WP8, you need to publish lyncdiscover.sipdomain.com -> external IP address fo the external web services published by a reverse proxy. This is not correct. Windows Phone 8 clients query DNS for lyncdiscoverinternal AND lyncdiscover. The latter should NEVER exist on your internal DNS. Its a huge mistake and instead of doing that I would even prefer to not support WP8 clients.

    Reply

    • Hi, Michael and thanks for commenting. I think you missunderstood what i meant. Lyncdiscoverinternal is ofcourse part of all Lync 2013 client discovery process. The reason for me suggesting using the external lyncdiscover record internally is in the scenario where you have internal PKI on your Lync FE servers. Since WP8 is the only one reacting to not trusting the lyncdiscover certificate my recommendation was to point it externally. All Lync Mobile clients log on to the external web services anyway, so how big a difference is having the mobile clients getting lyncdiscover as well from the externa web services? This will also support a BYOD strategy with Lync.

      If you use public certificates on the internal servers, then I recommend pointing lyncdiscover internally, just make sure you use a certificate root trusted by all mobile devices.

      Reply

      • Hi Ståle, thanks for your reply. Again, in a scenario where internal CA-signed certificates are in use, why not install the CA certificate on the devices? Windows Phone supports root, CA, and client certificate to be configured via MDM so it’s easy in corporate environments. I follow the rule that having lyncdiscover record in the internal DNS will make clients falsely assume inside status is false. Anyway, your approach will of course work and is another way of doing things :) Regards, Michael

        Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.