Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
In this article, we explore five frequently asked questions about Lync Server 2010 Mobility Service. Because Mobility Service was released only ten months ago, there are still some misconceptions about the service and how to properly configure your Lync Server 2010 environment. We hope this article helps you efficiently integrate Mobility Service into your Lync Server 2010 deployment. Here are the five questions:
Author: Dave Howe, Microsoft Senior Support Escalation Engineer
Publication date: August 14, 2012
Product version: Lync Server 2010
If you plan to use HTTPS for the initial Lync Autodiscover request from mobile clients, the answer is yes. You must add the Lync Autodiscover URL as an additional subject alternative name entry on your reverse proxy certificate.
It is a common misconception that this certificate requirement can be mitigated by using a DNS CNAME record to redirect secure Lync Autodiscover requests to a different address.
A CNAME record provides redirection for a client request, but it does not rewrite the content of the client request.
In the scenario shown in Table 1, Contoso uses a DNS CNAME record to support external Lync Autodiscover requests from mobile clients.
DNS Record Type
Fully Qualified Domain Name
A / HOST
Table 1. DNS CNAME record.
The Lync mobile client constructs a Lync Autodiscover request using a URL comprised of a hardcoded host name value (lyncdiscover) and the SIP domain of the user (contoso.com).
The Lync mobile client then sends a pair of Lync Autodiscover requests (http://lyncdiscover.contoso.com and https://lyncdiscover.contoso.com) to the reverse proxy at IP address 126.96.36.199.
Note: Although a CNAME record is used to redirect the request to a different address, the Lync Autodiscover URL contained in the request from the mobile client remains unchanged.
If HTTPS is used for the initial Lync Autodiscover request, the certificate offered by the reverse proxy must contain a matching FQDN value in its list of subject alternative name entries.
Unlike Lync rich clients that communicate natively over SIP, Lync mobile clients communicate strictly over the HTTPS, XML, and JSON protocols.
A solution is required to bridge communication gap between the Lync mobile clients and the Lync Front End service. This solution is Microsoft Lync Server 2010 Lync Mobility Service.
After deploying Mobility Service, you will find that two new services have been added to your Lync environment.
The Mobility Service is essentially an HTTP gateway that communicates with mobile clients over HTTPS, XML, and JSON and with the Lync Server 2010, Front End service over SIP/TLS.
Figure 1. Lync Mobility communication protocols.
To support both internal and external connections from Lync mobile clients, a new virtual directory is created for each service under the Lync Server Internal and External Web Sites in IIS see Figure 2.
Figure 2. Folder file tree showing Autodiscover and Mcx virtual directories in IIS.
The Lync Server 2010, Front End service listens for incoming requests over TCP/5061. Since this port is automatically defined in the topology, the Mobility Service can reach the Front End service.
However, the SIP listening ports for the Mobility Service are not automatically defined in the topology. As a result, the Front End service has no way of knowing how to contact the Mobility Service.
The SIP listening ports for the Mobility Service must be manually added to the topology using the Set-CSWebServer cmdlet.
After defining the SIP listening ports for the Mobility Service, internal SIP communication should route successfully between the Mobility Service (Mcx Internal and Mcx External) and the Front End service as shown in Figure 3.
Figure 3. Route between Mobility Service and Front End service.
Mobile devices commonly move between Wi-Fi and cellular networks several times throughout the course of a normal work day. Providing a consistent experience for Lync mobile users depends upon the ability to resume an existing mobility session or to establish a new mobile session from any network.
Although you can find an instance of the Mobility Service in IIS under both the internal and external Lync Server web sites, these virtual directories do not share session state information. This means that mobile users who are connected to the Lync environment from their internal Wi-Fi network are unable to resume their previous mobility session after transitioning to an external Wi-Fi or cellular network.
By forcing internally connected clients to make hair pinned connections to the external instance of the Lync Mobility Service, all requests from mobile clients are handled by a single instance of Mobility Service. This design provides a consistent session experience – regardless of whether you are connected from an internal Wi-Fi network or from an external 3G/Data/Wi-Fi network. And as long as the cookie-based affinity is correctly configured on your load balancer, your Lync mobile client should be able to resume an existing session, even though you may transition frequently between internal and external networks.
For Enterprise pools containing more than one Lync Server 2010, Front End Server, the Mobility Service instance running on LyncFE01 is unaware of any of the existing sessions established with the Mobility instance running on LyncFE02, and vice versa. Interactions with the Mobility Service from a mobile client are often brief, however the Mobility session itself can last for days if the Lync application is frequently used. Alternatively, the Lync application can be moved to a background state on Microsoft and Apple devices, and the associated Mobility session will remain active on the server to deliver push notifications for up to 72 hours (if enabled). The longevity of a Mobility session lifetime means that a mobile client must always connect to the same Mobility instance whenever it is resumed from a backgrounded state.
Prior to the release of the cumulative update for Lync Server 2010 November 2011 (when Mobility Service was added), our guidance stated that source IP affinity should be used for connections to external Lync web services, with a garbage collection interval of 30 minutes for stale TCP sessions. While this value works great for the Lync desktop application which periodically sends out white space events to keep TCP sessions active, this affinity setting does not work very well for the Lync mobile application.
Consider the following scenario, where source IP affinity is used to load balance Mobility sessions.
Because the Lync mobile application does not send white space events while in a backgrounded state, the existing Mobility session is automatically garbage collected by the load balancer around 9:58am. This is the reason load balancers must be configured with cookie-based affinity for connections to external Lync web services with no session lifetime defined for automatic garbage collection. By configuring the load balancer to use cookie-based affinity for load balanced connections to external Lync web services, mobile clients should always hit the same Mobility instance when resuming an existing session (that is, as long as their Mobility session has not expired).
For more information, please see Hardware Load Balancer Requirements for Lync Server 2010.
Basically, presence state on a mobile device is adjusted only if the Lync Server is involved in the call flow.
Figure 4 represents the simplified signaling path for a typical mobile call.
Figure 4. Simplified signaling path for a mobile call without Lync Server.
Figure 5 represents the simplified signaling path for a typical Lync Mobility call.
Figure 5. Simplified signaling path for a typical Lync Mobility call.
Remember, your contacts will see only what is allowed by your relationship privacy settings.
There is one call scenario where your presence state can change even though you are away.
We hope this article assists you to deploy Lync Server 2010 Mobility Service. We welcome your comments and questions.