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:
Publication date: August 14, 2012
Product version: Lync Server 2010
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.
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).
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.
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.
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.
Figure 3. Route between Mobility Service and Front End service.
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.
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.
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.
- Are changes to my reverse proxy certificate required if I use CNAME records for the Lync Server 2010 Autodiscover Service?
- Why is it necessary to define SIP listening ports for the Lync Server 2010 Mobility Service in my topology?
- Why is an internal user forced to make an external connection to the Mobility Service?
- Why is cookie-based affinity required for load balanced connections to Lync web services?
- Why doesn't my presence state change when I receive a cellular call on my mobile phone?
Publication date: August 14, 2012
Product version: Lync Server 2010
Are Changes to my Reverse Proxy Certificate Required if I use DNS CNAME Records for the Lync Server 2010 Autodiscover Service?
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 | Target Address |
| CNAME | lyncdiscover.contoso.com | lyncweb01.contoso.com |
| A / HOST | lyncweb01.contoso.com | 65.55.12.249 |
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).
- DNS lookup finds that lyncdiscover.contoso.com is actually a CNAME of lyncweb01.contoso.com.
- DNS lookup finds that lyncweb01.contoso.com resolves to the IP address 65.55.12.249.
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.
Why is it Necessary to Define SIP Listening Ports for the Mobility Service in my Topology?
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 Autodiscover Service is used by internal or external mobile clients to locate various web services such as the Mobility Service.
- The Mobility Service is used by internal or external mobile clients to sign in to a Lync Server 2010, Enterprise pool or Lync Server 2010, Standard Edition.
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.
- Set-CSWebServer –McxSipPrimaryListeningPort 5086 (defines TCP/5086 as the SIP listening port for the internal Mcx virtual directory)
- Set-CSWebServer –McxSipExternalListeningPort 5087 (defines TCP /5087 as the SIP listening port for the external Mcx virtual directory)
Figure 3. Route between Mobility Service and Front End service.
Why is an Internal User Forced to Make an External Connection to the Mobility 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.
Why is a Cookie-Based Affinity Required for Load Balanced Connections to Lync Web Services?
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.
| 9:22 A.M. | Launch Lync app (new Mobility session) |
| 9:23-9:27 A.M. | Participate in IM conversation |
| 9:28 A.M. | Background Lync app (put phone in pocket) |
| ... | |
| 11:43 A.M. | Launch Lync app (resume Mobility session) |
| 11:44 A.M. | Fail to sign in (Mobility session not found) |
For more information, please see Hardware Load Balancer Requirements for Lync Server 2010.
Why Doesn't my Presence State Change when I Receive a Cellular Call on my Mobile Phone?
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.
- In this scenario, the Lync Server is not involved in the call flow.
- When the call arrives, the Lync application is moved to the background.
- When the call is answered, the Lync user presence state remains unchanged.
- When the call is disconnected, the Lync application is not automatically re-launched.
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.
- In this scenario, the Lync Server is involved in the call flow.
- When the call arrives, the Lync application is moved to the background.
- When the call is answered, the presence state for the user is changed to In a Call.
- When the call is disconnected, the Lync application is automatically re-launched.
- The presence state of the user is changed back after a momentary delay.
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.
- Colleagues will see In a Call.
- External Contacts (federated users) will see Busy.
- Your presence state is set to Away.
- You receive an inbound Lync call or a PSTN call to your Enterprise Voice number.
- Your cell phone begins to ring simultaneously (based on your call forwarding settings).
- Your cell phone diverts to voice mail, which then answers the inbound call.
- Your presence state is changed automatically to In a Call.
- The caller decides to leave a lengthy voice mail message.
- Ater they hang up, and the call is disconnected.
- Your presence state changes back to Away.
No comments:
Post a Comment