Lync Client Discovery Process

What happens during the Lync client sign-in process has changed quite a bit in recent years. In the Lync 2010 cumulative update 4 (CU4), Microsoft introduced a new mobility discovery process, which is now included out of the box in Lync 2013. The changes resulting from the inclusion of the mobility discovery process might make some administrators quiver during the troubleshooting process. However, the changes also bring about some advantages. To determine whether the changes make things better or worse, you need to understand what has changed and why. Toward this end, I'll cover:

• The old client sign-in process before the mobility discovery process was introduced
• The new client sign-in process that includes the mobility discovery process
• The new Lync Windows Store app sign-in process for Lync 2013 clients

The Old Client Sign-In Process

Let's begin by looking at the client sign-in process in a Lync 2010 environment in which CU4 isn't installed. To set up the infrastructure for the client sign-in process, you need to create the internal DNS SRV record, _sipinternaltls._tcp.domain (where domain is your domain's name), which allows users to connect automatically. This SRV record accompanies the A record for the server or the virtual IP (VIP) of the load balancer. Together, they allow clients to find and sign into their registered Lync 2010 pool. For example, if the domain is contoso.com, the path for signing in follows this order:

1. _sipinternaltls._tcp.contoso.com (SRV record for internal Transport Layer Security—TLS—connections)
2. _sipinternal._tcp.contoso.com (SRV record for internal TCP connections)
3. _sip._tls.contoso.com (SRV record for external TCP connections)
4. sipinternal.contoso.com (A record for the Front End pool)
5. sip.contoso.com (A record for the Front End pool when the client is on an internal network; A record for the Access Edge Server when the client is external with no VPN access)
6. sipexternal.contoso.com (A record for the Access Edge Server when the client is external with no VPN access)

When the Lync client is internal, it finds the _sipinternaltls._tcp.contoso.com SRV record and proceeds to authenticate to either the Front End pool or the Director Server if one is deployed. When the client is external (i.e., not on the network), it doesn't have option 1 or option 2 available. Thus, it would resolve to option 3 (_sip._tls.contoso.com), which points to the Access Edge Server. This server would then proxy the connection request to the next hop (e.g., a pool or Director Server).

The New Client Sign-In Process

The client sign-in process has changed quite a bit since the introduction of the mobility discovery process. SRV records are used to assist the mobile clients with the sign-in process, no matter whether the mobile clients are inside or outside the organization. For example, if the domain is contoso.com, the path for signing in follows this order:

1. lyncdiscoverinternal.contoso.com (A record for the Autodiscover service for internal connections directed to internal Web services)
2. lyncdiscover.contoso.com (A record for the Autodiscover service for external Web services)
3. _sipinternaltls._tcp.contoso.com (SRV record for internal TLS connections)
4. _sipinternal._tcp.contoso.com (SRV record for internal TCP connections)
5. _sip._tls.contoso.com (SRV record for external TCP connections)
6. sipinternal.contoso.com (A record for the Front End pool)
7. sip.contoso.com (A record for the Front End pool when the client is on the internal network; A record for the Access Edge Server when the client is external with no VPN access)
8. sipexternal.contoso.com (A record for the Access Edge Server when the client is external with no VPN access)

In this new sign-in process, the client's first DNS resolution request is sent to the lyncdiscoverinternal and lyncdiscover Fully Qualified Domain Names (FQDNs). This means that internal Lync clients could potentially be redirected out to the reverse proxy and treated like external clients. This is why the Autodiscover DNS records are a huge part of the deployment picture and need to be realigned to their proper locations. The lyncdiscoverinternal FQDNs should exist only in the internal DNS and point to the internal Front End Servers (or Directors Servers if you have them in place). The lyncdiscover DNS A record should be published only in an external DNS and point to a reverse proxy server. In the event you have an internal DNS A record for lyncdiscover, it should still point to the external IP address that resolves to the reverse proxy server and act in the same manner.

Note that, for all Lync clients during logon, the DNS query process continues until a successful query is returned or the list of possible DNS records is exhausted. If all possible DNS records have been returned to the Lync client and the client wasn't able to sign in, an error is returned. Also note that when Lync 2010 CU4 is installed, Lync 2010 clients will follow the new sign-in process, even if Lync 2013 isn't in use.

The New Lync Windows Store App Sign-In Process

In case you're unfamiliar with the Lync Windows Store app, it's an application built for touchscreen PCs. With it, users can leverage a scaled-down version of the rich Lync 2013 client. Unlike the Lync 2013 rich-client logon process, the Lync Windows Store app follows a different pattern for the discovery process. For starters, there isn't a lengthy sign-in process. The client looks for only two records:

• lyncdiscoverinternal.contoso.com (A record for the Autodiscover service for internal connections directed to internal Web services)
• lyncdiscover.contoso.com (A record for the Autodiscover service for external Web services)

When neither record is published, the Lync Windows Store app will encounter problems logging on to the Lync 2013 infrastructure. However, because the mobility discovery process was introduced in the Lync 2010 CU4 and is available out of the box in Lync 2013, the occasions when these records aren't populated are rare.

New Logon Process a Good Thing

The mobility discovery process is now built into the Lync 2013 logon process, which is a good thing. The ability to logon on from mobile devices greatly enhances the flexibility and range in which users can connect to their Lync environments. Fortunately, it works out of the box as long as the administrators have done their due diligence in setting up the infrastructure, including the DNS A and SRV records. So, in the end, having to set up a couple more DNS records is a small price to pay for happy rich-client and mobile-client users.