A recent NextHop article explains in some detail the fact that the new Windows Store Lync client only supports the newer Lync Autodiscovery method for locating a Lync registrar to sign-in to the environment.

This article shows how to verify and test the automatic sign-in behavior of various Lync clients in an environment by showing the different client behavior and comparing the Windows client to the Windows Store app.  Changes to guidance and deployment practices surrounding the Autodiscover service are also discussed.

Behavior

In order to observe this behavior simply run a network capture on a workstation running the Lync 2013 client and then attempt to sign-in using a bogus SIP domain name.  As each autodiscover step fails to receive a suitable response the process will advance to the next logical step.

The following test scenario uses Wireshark but the same process can be used with other network packet capture utilities.

Lync 2013 Windows Client

• Sign out of the Windows Lync 2013 client on the test workstation and then launch Wireshark.
• Start a live capture in Wireshark and then enter the text ‘dns’ in the Filter field to only display DNS related traffic entering and leaving the workstation.

• Switch to the Lync 2013 client and enter a fake SIP Address (e.g. jeff@notasipdomain.com) and click Sign-In.

• Monitor the Wireshark window while the Lync client is attempting to sign-in and notice each type of DNS record which is resolved and the resulting failure.

• As long as the test domain name selected is in fact fake and not actually configured for Lync then the entire process should fail, resulting in the following error.

• Stop the trace in Wireshark and take note of the Destination IP address for each DNS resolution query (not the query response).  This IP address should be that of the primary DNS server assigned to the workstation.  Use the following query in the Wireshark filter field to display only the DNS queries themselves, hiding all other traffic from the capture window.

dns and ip.dst==192.168.1.254

• The resulting display should show the exact records and order that the Lync 2013 client attempted to query in order to perform autodiscovery of the Lync registration server.

The results above clearly show that the new order of preference for the Lync 2013 Windows client is to leverage the Lync Discover service which was first introduced in Lync Server 2010 CU4 for supporting the Mobility clients.

1. The lyncdiscoverinternal.<sipdoimain> Host (A) record is tried first.  This record should only be available to hosts with acesss to the internal DNS servers, so external clients (not connected via VPN) should typically receive no response for this query and then move on to the next.
2. The lyncdiscover.<sipdomain> Host (A) record is then attempted and would be the preferred first resolution for external clients.

If neither of these records are resolvable then the legacy DNS Service Locator Record (SRV) and Host Record (A) fall-back process is used.  The Lync 2013 Windows Store app actually stops here (as shown in the next section) and does not advance further, hence the requirement for deploying the Lync Discover service correctly even if mobility client are not planned for support in an environment.

1. The sipinternal.<sipdomain> Host (A) record is then queried and would normally be resolvable only against internal DNS zones, in the same fashion that lyncdiscoverinternal would have been (if it existed).
2. The sip.<sipdomain> Host (A) record is tried next and is often used for both internal and external resolution.
3. In the event that none of the records above successfully return a query the last attempt is to sipexternal.<sipdomain> which should only ever be populated in an external DNS zone.  (This record is rarely used in real world deployments).

Lync 2013 Windows Store App

• Restart the Wireshark capture, using either the same filter or less specific ‘dns’ filter and sign in to the Lync 2013 Windows Store app instead.

• The sign-in attempt should fail much quicker than in the previous example.

• Stop the Wireshark capture and review the results.

In this capture the only DNS queries performed by the MX client were for the pair of lyncdiscover and lyncdiscoverinternal host records.  There are no attempts to resolve the legacy SRV and A records which are used by the normal Windows clients.

Previous Guidance

When the Mobility clients were launched late last year for Lync Server 2010 the new Autodiscover service was initially perplexing.  The solution seemed like a lot of work just to support a unique set of clients, both for the product team to develop and for customers to understand and deploy correctly.  These new solution seemed to foreshadow additional changes in future clients as well.

Now that Lync Server 2013 is available and there are at least two new clients now which also leverage this service it is becoming more clear that the new autodiscover approach will be the primary, and eventually maybe the only approach for Lync clients to locate servers to connect to.

The impact of this phased change will mean a few best practices will need to be updated and the reliance on reverse proxy solutions for external web services publishing may become nearly a requirement versus a recommendation in some scenarios.  Clearly for Lync 2013 support a combination of both discovery scenarios will be ideal, but the writing may be on the wall for the next release of Lync to completely ditch the legacy SRV/A record approach and rely solely on the Lyncdiscover approach.

The most immediate impact is to previous guidance for the Autodiscover service configuration which was originally designed specifically for mobility clients.  The inherent problem seen during these initial deployments is that the large majority of environments utilize a private CA for certificates issued directly to internal Lync servers but now a large amount of unmanaged Lync clients were connecting to Lync directly from internal networks: personal mobile devices connected to internal Wi-Fi networks.  Previously the majority of clients which would typically connect via an internal network would be domain-joined Windows workstations which would already have the private CA certificate chain provided via Group Policy (when an Enterprise Windows CA was paired with the Active Directory environment).  Additionally any internal Lync Phone Edition client device would be able to automatically download the same private CA certificates by leveraging LDAP or DHCP information provided to the endpoints to locate the Lync Certificate Provisioning service.

But the mobility clients do not automatically download certificates so if the certificate presented by the Front End or Director servers is not trusted then the clients are unable to establish a TLS connection preventing their use.  The resolutions provided for this issue were either to deploy the needed certificates to all devices (a potential device management headache) or to instead redirect the internal lookup requests from these devices out to the externally published Lync services which would traditionally contain a third-party public certificate which these devices would already trust by default.

The latter approach is what became more common as it was easier to manage and only impacted the mobile clients.  All other Lync clients would still leverage the existing SRV and/or Host records to locate the proper Lync server.  Internal clients (and those on VPN in some cases) would be directed to internal servers and clients on the Internet would be directed to the external servers.

But when using the Lync 2013 Windows client it is clear that the first DNS resolution attempts are placed to the Lyncdiscoverinternal and Lyncdiscover FQDNs.  In the scenario above this would mean that internal Lync 2013 clients would be redirected out to the reverse proxy and treated like external clients which is not a desired behavior.  Thus the autodiscover DNS records would need to be realigned to their proper locations with Lyncdiscoverinternal existing only in the internal DNS zones and pointing to the internal Front end or Director, while the Lyncdiscover record would on;ly be published in external DNS zones and be pointed to a Reverse Proxy server.

Updated Guidance

As these changes are new and there are still a very limited number of Lync Server 2013 deployments in production to date it is not realistic to define a new best practice at this point in time.  Instead alternative configurations can be investigated and over time one or more of these scenarios may take root in the field as best practices.  Additionally Microsoft may release updated documentation or articles with an official stance on what is recommended.  But for now the existing TechNet documentation does not provide any real solution for these potential problems.

Split-Brain DNS

The first solution would be to simply start issuing public certificates to the internal Lync servers but this approach may not work for all environments as many third party certificate authorities will not allow certificate requests which contain internal-only domain names.  In networks were Split-Brain DNS is employed then this should not be an issues as all namespaces in use (both for servers and SIP domains) are publically resolvable and can be verified by the CA as owned by the requestor.

In these organizations the simplest approach would be to configure the lyncdiscoverinternal record in the internal DNS zone, pointing to internal Lync servers. Then publish the lyncdiscover record in the external DNS zone, pointing to a reverse proxy or other web publishing solution.

Disparate Namespaces

Editor’s Note:  In light of new details the guidance in this section is no longer valid.  I’m leaving it intact in the article as a reference (the configuration examples may be handy for other unrelated topics) but there is a major design flaw in this approach which will at minimum prevent the WebTicket service from functioning, among other web services.  In short the Server or Pool FQDN must also exist on the Web Services certificate, so although this configuration would work for the Mobility clients it would end up breaking all SIP clients!

Please take a look at the follow-up article Lync Server ‘Certificate Cliff’ for a full explanation of the limitations and the impact on future guidance for Lync Server deployments. -J.S.

But for networks were different namespaces are in use and the Lync server’s FQDN uses an internal-only namespace (e.g. lync.schertz.local) which can never be published to public DNS zones then this creates a problem.  A single public certificate can not be used on the internal Lync server.

The solution here could be to start using a combination of both private and public certificates on the internal Lync Servers.  Thus far the accepted best practice has been to use a single certificate assigned to all three usages on a Lync Front End or Director server, meaning that the same certificate is applied to the Server default, Web services internal, and Web services external usages.

But there is no requirement that the same certificate must be used on all three usages, this is just the simplest and (in the past) best approach for most deployments.  Thus it would be possible to use an internal certificate authority for the certificate assigned to the Server default usage, containing FQDNs in the internal namespace, while issuing a public certificate to both of the Web services usages.  This configuration separates the internal and external FQDNs in to separate private and public certificates.

The following table depicts how the certificate configuration may look for a basic Standard Edition deployment, separating the internal namespace of schertz.local from the external namespace mslync.net.  The server default certificate request would be issued to a Windows Enterprise CA or some other supported internal CA, and the web services certificate would be requested against a commonly trusted public CA like DigiCert, Entrust, Verisign, etc.

For an Enterprise Edition Pool the same approach can be used to support the additional internal FQDNs.

Based on this type of configuration it would also be viable to simply use the same exact certificate for both the internal Lync server’s web services and the Reverse Proxy server’s web listener.  This would reduce cost by not requiring a second separate public certificate to be purchased.  In this case make sure to omit the ‘admin’, ‘lyncdiscoverinternal’ and ‘lyncwebint’ hostnames from any reverse proxy rules so that if any external requests for those FQDNs are sent to the reverse proxy they will be dropped.  Exposing these FQDNs in the external certificate is not really any risk, as the internal namespace is still protected and the reverse proxy would not allow connections to these sites anyway.

There is one complication with this overall split certificate approach though as the configuration on the Lync Server must be updated to use different FQDNs for TLS/MTLS connections and HTTP/HTTPS connections.

For Enterprise Edition server pools this same configuration can be defined in a similar fashion using cmdlets or the Topology Builder can instead be used to set this Override FQDN.

The Lync Topology Builder has no option to change the web service FQDN of a Standard Edition server though.  But this behavior can be modified for a Standard Edition pool after all, by utilizing PowerShell cmdlets as shown below.

• Using the Lync Server Management Shell issue the following Get-CsService cmdlet to view the currently defined InternalFQDN of the desired Front End server (e.g. lync.schertz.local), which should be null by default for a Standard Edition server.

Get-CsService -WebServer -PoolFqdn lync.schertz.local | fl *internalFQDN*

• Then issue the following Set-CsWebServer cmdlet to define a new internal web services FQDN (e.g. lyncwebint.mslync.net) to the desired Front End server.

Set-CsWebServer -Identity “Webserver:lync.schertz.local” -InternalFqdn “lyncwebint.mslync.net”

• To verify the change re-run the same Get-CsService cmdlet as before and the InternalFQDN should now be assigned to the desired parameter.

Get-CsService -WebServer -PoolFqdn lync.schertz.local | fl *internalFQDN*

After this type of configuration change it is necessary to re-run the Lync Server Deployment Wizard on each Front end server in the pool to update the web services FQDN properly.

Clarification

It is important to understand that this split certificate approach will only help with supporting the Lync Mobility client as it is not a SIP client and registers to the MCX web service only.  So as long as the web services certificate is trusted by any Windows Phone, Android, or iOS device then both autodiscover and registration attempts will be supported.  But the Windows Store App is a SIP client just like the standard Windows Lync client, thus it must also support the certificate assigned to the server usage.

As long as these clients are running on Windows 8 workstations which are domain-joined then the same certificate authority trust relationship needed by the standard Windows client is applicable.  So when devices like the Microsoft Surface start to become more common in corporate networks as unmanaged personal mobile devices then there are really only two available options to support all the different client use cases: either move to using a commonly trusted public certificate for all Lync server roles inside and out, or just deal with the management tasks of importing the internal root CA certificates to these devices.  Both approaches have their inherent benefits and drawbacks, but the ideal approach may be one or the other depending on the desired balance between ease of deployment versus overall deployment costs and security.