Skype for Business Blog

15 MIN READ

Lync Server 2010 - Mobility Deep Dive – Autodiscover Service

Brass Contributor

May 20, 2019

First published on TECHNET on Apr 25, 2012

Microsoft Lync Server 2010 Autodiscover Service--not to be confused with Exchange Autodiscover Service--is a new Lync Server service introduced in the Lync Mobility feature update that was released in Cumulative Update for Lync Server 2010: November 2011 . This article provides more depth about Lync Autodiscover, its purpose, and how mobile clients utilize its functionality.

Author : Greg Anthony

Publication date : April 25, 2012

Product version : Cumulative Update for Lync Server 2010: November 2011

Introduction

The Lync Autodiscover Service is a component that the Lync Mobile client queries to find a user's home pool URLs for the various Lync Server Web Services, such as Autodiscover, Mobility, Reach (Lync Web Access), Meet, Address Book Service, and Distribution List Expansion. In a nutshell, Autodiscover provides information to a Lync Mobile client so that the client can connect, authenticate to the user's home pool, and access Lync provided resources.

While Lync SIP clients currently use DNS service locator records (SRVs), this service provides a process for the Lync Mobile application to utilize over HTTP and HTTPS.

Architecture

Lync Autodiscover Service is installed as part of Lync Web Services as shown in Figure 1.

Figure 1. Lync Autodiscover

It is installed on both the Lync Server external and internal web sites.

To initiate discovery, the client takes the domain portion of the entered user's SIP URI and composes a DNS lookup request for lyncdiscoverinternal with an appended domain. For example username@contoso.com returns lyncdiscoverinternal.contoso.com . If the DNS query fails to return a result, the client repeats the process using lyncdiscover. The lyncdiscoverinternal record, as the name implies, is expected to be defined in the internal DNS as either a DNS A record or CNAME record. The DNS record points to a Lync Server that has Autodiscover installed in IIS, such as a Director, or Lync Front End Server. Lyncdiscover is expected to be defined in external DNS and be resolvable from the Internet.

Lync Autodiscover, when installed as part of Lync Web Services, listens on ports 80 and 443 on the Lync Server internal web site and ports 8080 and 4443 on the Lync Server external web site. Because 80 and 443 are well known ports for HTTP and HTTPS traffic, the client does not need to specify a port number when connecting to Autodiscover internally. Lync Server external web site ports are bridged externally from the external port 80 and port 443 to their internally defined port 8080 and port 4443 by the reverse proxy, using appropriate web publishing rules. DNS SRV records are not used because they are not supported by some browsers and mobile platforms. Some corporate firewalls have configurations that block DNS SRV externally, which would block DNS lookup for hosted environments like Lync Online or Lync Server 2010 Hosting Pack.

When a successful result is returned from a DNS query, the client issues an HTTP request and HTTPS request asynchronously to the Autodiscover Service. The client makes requests in the following order:

If DNS lookup for lyncdiscoverinternal.contoso.com succeeds:

1. GET http://lyncdiscoverinternal.contoso.com/

2. GET https://lyncdiscoverinternal.contoso.com/

If DNS lookup for lyncdiscover.contoso.com succeeds:

1. GET http://lyncdiscover.contoso.com

2. GET https://lyncdiscover.contoso.com

If both lyncdiscoverinternal and lyncdiscover succeed, the client uses the response from lyndiscoverinternal.

HTTP is used as an entry point because it is not feasible, in hosted Lync Server 2010 online deployments, to update external facing certificates subject alternate names (SANs) for each hosted tenant's domain. Using HTTPS would quickly exceed the max size of a certificate or the allowed limit of a client/server handshake message, when negotiating a secure connection.

For on-premise deployments of Lync Server 2010 it is highly recommended to request and assign certificates with the SANs updated to include lyncdiscover.<SIP domain> or lyncdiscoverintenal.<SIP domain>.

Because Lync discover DNS records can be created as either CNAME records or Host A records, CNAME records could be entered with domains that do not match the domain or zone of the Autodiscover Service or reverse proxy certificate configuration. Therefore when the client sends a HTTPS request and is redirected to a different zone (non-matching domain), the certificate presented by that zone will not match what the client expects and is blocked. When the request is made using HTTP, there is no certificate mismatch on a zone change because this is an unsecure connection and the request passes through to the Autodiscover Service. Autodiscover supplies a secure URL in response to the client, as shown in Figure 2.

Figure 2. Autodiscover http redirect to secure URL

The client verifies the domains of the URLs received in the response, match the requested domains. If they do not match or if any domain included in the client trust model, like online.lync.com or onmicrosoft.com, the client prompts the user to confirm trust before continuing.

IIS URL Rewrite rules map Autodiscover requests with no virtual directory to the root entity. Rewrite rules can be viewed in the IIS Manager console as shown in Figure 3. For more information on URL Rewrite Module see URL Rewrite .

Figure 3. URL Rewrite Rules

Authentication

Lync Autodiscover Service provides two resources that are visible to clients. These resources are <FQDN>/Autodiscover/AutodiscoverService.svc/root/ domain and <FQDN>/Autodiscover/AutodiscoverService.svc/root / user .

The root/ domain is accessed anonymously to provide general topology information for the current location like the FQDN of the pool. It can also be used as a resource in troubleshooting, and can be queried using a browser to verify that the Lync Autodiscover Service is installed, operating, and returning the expected URLs.

The root/ user URL interface requires authenticated access and is used by the client to discover URLs for the user's home pool services. Client requests with invalid credentials or no web-ticket present in the header, receive an HTTP/1.1 401 Unauthorized response with the X-MS-Web TicketURL in the response header (that is X-MS-WebTicketURL: https://<lyncfrontendserver>.contoso.com/WebTicket/WebTicketService.svc).

Interrelationships

Lync Servers with the Standard Edition or Enterprise Edition role installed are Registrars. Registrars maintain user information in a database. Lync Autodiscover is installed on each server hosting the Registrar role. While users are not homed on Directors, Autodiscover Service is installed on them, as they provide a registrar lookup service. The Autodiscover Service queries the Registrar database to look up the user's home pool information from the Registrar database and redirects the user to the Autodiscover Service on their home pool so the client has up-to-date information on the available web services in their pool.

All web URLs for a Lync pool are published to the Central Management Store using Lync Server Topology Builder or Lync Server Management Shell cmdlets. Lync Autodiscover retrieves the web component URL information from the Central Management Store.

Lync Autodiscover Scenario

In the following sample scenario, the topology consists of a reverse proxy, Lync Director, and Lync Front End server. The Director and Lync Front End Servers have been configured for Lync Mobility.

Note: If there is no Director in the topology, requests are sent to a Front End Server that performs the function of the Director, such as looking up the referenced user’s home pool an d returning that information when requested.

Figure 4 depicts a typical Lync Mobile client sign in interaction and call flow with the Lync Autodiscover Service up to the point of connecting to the Mobility Service and completing sign in.

1. DNS query: lyncdiscoverinternal.contoso.com resolves to IP address of director.contoso.com.

2. Client constructs URL and sends an HTTP GET request to director.contoso.com/?sipuri=user@contoso.com.

Client receives two links in the response. One link is for the https://director.contoso.com/Autodiscover/AutodiscoverService.svc/root/domain resource and the other link is for the https://director.contoso.com/Autodiscover/AutodiscoverService.svc/root/user resource.

3. Client constructs URL and sends an HTTPS GET request to director.contoso.com/?sipuri=user@contoso.com

4. Based on which request succeeds from step 2 or 3 and is received first, the client uses that response to make a request to the https://director.contoso.com/Autodiscover/Autodiscover.svc/root/user to retrieve specific user home pool information .

Client receives 401 Unauthorized response with Web Ticket Service (WTS) location in the header.

5. Client submits a request to the Web Ticket Service to retrieve the metadata exchange document (MEX).

6. Client submits a Request Security Token to Web Ticket Service and supplies credentials.

7. Web Ticket is returned to the client. (There are two POST and two 401 Unauthorized as part of the Web Ticket Service authentication negotiation not shown here.)

8. Client makes request again to the https://director.contoso.com/Autodiscover/Autodiscover.svc/root/user to retrieve specific user home pool information and provides the web ticket.

Lync Autodiscover service obtains user’s Uri from web ticket.

Lync Autodiscover retrieves user info from registrar database and retrieves the user’s home pool.

9. Lync Autodiscover sends “Redirect” with location in xml to user’s home pool <Link token="Redirect" href="https://pool.contoso.com/Autodiscover/AutodiscoverService.svc/root?sipuri=sip:user@contoso.com" />

10. Client repeats steps 4 through 8 against their home server.

11. Lync Autodiscover responds with the internal and external Lync services URLs for the user's home pool.

<?xml version="1.0" encoding="utf-8"?>

<User>

</User>

</AutodiscoverResponse>

The client then continues to connect to the Mobility Service and sign in.

The Autodiscover response provides a hint to the client for example AccessLocation="Internal" as highlighted in Figure 4. The response is either the internal Lync web services or external Lync web services and as determined by the Autodiscover Service.

In the final Autodiscover response, both internal and external URLs are provided. These URLs are cached by the client. In the event of connectivity failure to one set of URLs, for example when moving between wireless connectivity and cellular coverage, the client attempts to use the other set of URLs. If both sets of URLs fail, they are flushed from cache and the client repeats the Lync discovery process.

In Figure 4, step 9 illustrates a redirect from the Director Autodiscover service to the user's pool Autodiscover Service. The client detects redirect loops and does not allow more than 10 redirects. This client functionality prevents endless redirects if a problem in the redirect logic exists that might cause an infinite loop.

Figure 4. Typical Autodiscover Flow

Diagnosing Lync Autodiscover Issues

Client DNS Resolution

The client has a dependency on being able to query and resolve DNS records for the Lync Autodiscover Service. The primary DNS records required are lyncdiscoverinternal.<yoursipdomain> and lyncdiscover.<yoursipdomain> which point to a Lync Pool (or to a Director if one is deployed). If multiple pools are enabled for Mobility, the DNS records for the Lync web services for each pool must also be published in DNS. This enables clients to resolve redirects from Autodiscover on the Director, to Autodiscover on the user’s home pool. If the client is external, appropriate web publishing rules need to be created or updated on the reverse proxy. For Microsoft Office 365 Lync Online, a re-delegated domain only needs a DNS CNAME record lookup for lyncdiscover.<your_domain> pointing to webdir.online.lync.com. All clients are external to Office 365. For additional information see You cannot sign in to Lync Online by using a domain that is configured for full redelegation .

Other considerations with DNS resolution are that mobile devices receive DNS lookups from the mobile carrier, the Wi-Fi connection, or both. You can use NSLookup against public DNS servers to check for proper entry and use a site like http://www.whatsmydns.net to check propagation. If you are using a wireless network to connect to your internal network, and are using a split-DNS configuration where your internal DNS domain and forward lookup zone is the same as your public domain, then your internal DNS server will normally be authoritative for any DNS queries to that domain. The external records published in external DNS for the external web FQDNs for your pools; need to be published in the internal DNS so clients connected over the wireless network can resolve the records internally.

There may be mobile apps available in the market place that can display the mobile carrier DNS settings on your device. Otherwise, you can contact your carrier. For Wi-Fi connections, you can normally view this in the wireless settings of your device.

The client logs provide clues about successful DNS lookups. For information on collecting logs on mobile clients see Technical Considerations for Mobile Clients.

Figure 5 provides sample client logs that fail to complete discovery for lyncdiscoverinternal. All three devices were connected over 3G, not Wi-Fi, so failure on lyncdiscoverinternal.contoso.com is expected. The sections in the individual device logs showing the failure are highlighted.

Figure 5. Lync for Windows Phone Log

Figure 6. Lync for iPhone log

Figure 7. Lync for Android log

The above logs would be similar for lyncdiscover.contoso.com if a device was connected to your corporate wireless network. The logs shown here are abbreviated for space and may not contain all information such as the parallel request for https://lyncdiscoverinternal.contoso.com that would also fail discovery because it is the same DNS record.

Failure to resolve both lyncdiscoverinternal and lyncdiscover DNS records will result in client UI error message: Cannot connect to the server. It might be unavailable. Also please check the network connection, sign-in address and server addresses .

If you have not configured automatic discovery for the mobile client, you can override auto-detect in the client application by deselecting the auto-detect server check box. Deselecting the check box reveals the manual settings where the user can input the internal and external discovery addresses. This is useful for troubleshooting scenarios.

https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access

https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access

The advantage of manual settings is that you do not have to request new certificates with lyncdiscover.<sipdomain> and lyncdiscoverinternal.<sipdomain> added to the certificate(s) subject alternative name field, for the reverse proxy web publishing rules, and the Lync Server Web Services sites.

The disadvantage of manual settings is you must provide users with the URLs that they need to manually enter. Manual entries increase the chance for typographical errors, which in turn increases support desk calls. You also need to notify users of the URL changes they need to make, if you make changes to the Lync topology that affect sign on. You can still point to the Director web FQDNs and Autodiscover Service to issue a redirect to the user's pool FQDN.

Though supported, it is not recommended to configure a web publishing rule on the reverse proxy that uses HTTP on port 80 that is processed before the HTTPS rules for your Lync web services in order to not request new certificates with the lyncdiscover SAN entries for the reverse proxy

SSL Encryption

HTTPS requests rely on Public Key Infrastructure (PKI). HTTP does not employ data encryption for client and server communication. HTTPS employs data encryption. The Internet Information Server (IIS) running Lync web services, implements Secure Sockets Layer (SSL), using an encryption protocol. SSL implementation accomplishes two things:

The client performs certificate validation on the certificate provided by the server to validate the reverse proxy or Lync web server's identity.

Data is encrypted during transfer between Lync web service and the client.

An SSL connection attempt begins when the client perform an HTTPS request for lyncdiscoverinternal or lyncdiscover.

When the connection is established, the server transmits its certificate to the client.

To authenticate the server, the client uses the following tests to validate the certificate:

Ensures the server certificate chains to a trusted root certification authority (CA).

Ensures that the FQDN name in the certificate's subject or subject alternate name field, matches the FQDN in the HTTPS URL.

Ensures that the server certificate is time-valid.

Ensures that the server certificate has not been revoked.

Failure of any of these tests can be inconclusive as to the actual cause as the client is dependent on the platform on which it is running as to the granularity of the information returned by the platform's application programming interface (API). The sign in error returned could be a generic connection error, SSL error, or SSL certificate expired.

After a successful test, the client extracts the certificate's associated public key.

Next, it creates a pre-master secret, which is a string of randomly created bits whose length is determined by the negotiation between the client and the server.

Then the client encrypts the pre-master secret with the server's public key and sends the encrypted pre-master secret to the server.

The server decrypts the pre-master secret with its private key.

Depending on the cryptographic service provider (CSP) installed on the server, a Diffie-Hellman or a Rivest Shamir Adleman (RSA) negotiation allows the server and client to use the pre-master key to generate a symmetric session key using the same symmetric encryption algorithm.

The server and the client use this symmetric session key to encrypt the data transmitted between them. The session key is used until the client or the server terminates the HTTPS session.

SSL Encryption Issues

Mobile device operating systems come with most of the public trusted root certification authority chains pre-installed. Refer to the mobile device operating systems vendor support sites, the device manufacturer's support site, or the wireless carrier's support site and product documentation for a list of trusted root certificates installed in the device or other information related to managing certificates on a particular device.

Mobile devices do not have the trusted root certification chain installed for certificates issued from internal private certificate authorities. This can cause Autodiscover to fail when connected to corporate networks over a wireless network. Public CA root certificates also expire, change ownership, or one may not have been added to the device when it was originally released. You can verify that the device has the trusted root certification chain installed by opening the HTTPS manual discover FQDN using the web browser installed on the device. The web browser should return a warning similar to the following based on browser and platform;

Security Warning. There are problems with the security certificate for this site. This certificate is not from a trusted authority. (Android)

Cannot Verify Server Identity. (iOS). (Click Details to see if certificate shows as Not Trusted)

We're having trouble with this site's security certificate. It looks like the security certificate wasn't issued by a trusted certificate authority. (Windows Phone 7.5)

In the browser, you can click the appropriate option to View certificate , Get more information , or Details depending on browser and platform to obtain additional information that may be useful in troubleshooting.

One way to install a root certificate on a device is to email it as an attachment, open it, and follow the prompts to install. You can publish the root certificate on a web site and install it by opening it from the device web browser. Apple also has the iPhone configuration utility for enterprise management of their devices. For links to more information on mobile devices and certificates, see the Additional Information section at the end of this article.

If the FQDN of the URL is not in the common name field (aka, subject name) or subject alternate name field of the server certificate, you should see similar security warnings. If you are unable to open the certificate and view in the mobile browser in this scenario, use Internet Explorer on a desktop, browse to the URL, click continue on to the site, and then click on the red X by Certificate. You should get a notification box that opens with Mismatched Address.

Conclusion

This article provides an initial deep dive on Lync Autodiscover, its purpose, and how mobile clients utilize it. This article does not, however, cover reverse proxy web publishing rules, IIS logging, Lync Server logging, or using other tools like Fiddler for troubleshooting the Lync Autodiscover Service. This article helps explain how Autodiscover works, why you need to update certificates, and how to resolve common connectivity issues.

Updated May 20, 2019

Version 2.0

Mobility

NextHop

NextHop_Team

Brass Contributor

Joined May 16, 2019

View Profile

Skype for Business Blog

Follow this blog board to get notified when there's new activity

Blog Post