Technical Requirements for Mobility
Topic Last Modified: 2013-03-05
Mobile users encounter various mobile application scenarios that require special planning. For example, a user might start using a mobile application while away from work by connecting through the 3G network, then switch to the corporate Wi-Fi network when arriving at work, and then switch back to 3G when leaving the building. You need to plan your environment to support such network transitions and guarantee a consistent user experience. This section describes the infrastructure requirements you need to meet to support mobile applications and automatic discovery of mobility resources.
When you use automatic discovery, mobile devices use Domain Name System (DNS) to locate resources. During the DNS lookup, first a connection is attempted to the fully qualified domain name (FQDN) that is associated with the internal DNS record (lyncdiscoverinternal.<sipdomain>). If a connection cannot be made by using the internal DNS record, a connection is attempted by using the external DNS record (lyncdiscover.<sipdomain>). A mobile device that is internal to the network connects to the internal Autodiscover Service URL, and a mobile device that is external to the network connects to the external Autodiscover Service URL. External requests go through the reverse proxy. The Microsoft Lync Server 2010 Autodiscover Service returns all the Web Services URLs for the user's home pool, including the Mobility Service URLs. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Microsoft Lync Server 2010 Mobility Service externally through the reverse proxy.
Note
Although mobile applications can also connect to other Lync Server services, such as Address Book Service, this requirement to send all mobile application web requests to the same external web FQDN applies only to the Mobility Service. Other services do not require this configuration.
The following diagram illustrates the flow of mobile application web requests for Mobility Service and Autodiscover Service.
Flow of mobile application requests for Mobility Service and Autodiscover Service
.jpg "cdb96424-96f2-4abf-88d7-1d32d1010ffd")
To support mobile users from both inside and outside the corporate network, your internal and external web FQDNs must meet some prerequisites. In addition, you may need to meet other requirements, depending on the features you choose to implement:
New DNS CNAME or A records, for automatic discovery
DNS SRV record, for federation with the Push Notification Clearing House
New ports for internal servers
New firewall rule, if you want to support push notifications through your Wi-Fi network
Subject alternative names on internal server certificates and reverse proxy certificates, for automatic discovery
Front End Server hardware load balancer configuration changes for cookie-based persistence
New web publishing rules on the reverse proxy, for automatic discovery
Website Requirements
Your topology must meet the following requirements to support Mobility Service and Autodiscover Service:
The Front End pool internal web FQDN must be distinct from the Front End pool external web FQDN.
The internal web FQDN must only resolve to and be accessible from inside the corporate network.
The external web FQDN (except for the Mobility Service URL, which is addressed by both internal and external user requests) must only resolve to and be accessible from the Internet.
For a user who is inside the corporate network, the Mobility Service URL must be addressed to the external web FQDN. This requirement is for the Mobility Service and applies only to this URL.
For a user who is outside the corporate network, the request must go to the external web FQDN of the Front End pool or Director.
If you have a split-brain DNS environment and mobile device clients will connect wirelessly, you need to configure the external web FQDN in the internal DNS with the public IP address.
DNS Requirements
Your topology must meet the DNS requirements outlined in the following sections to support Mobility Service and Autodiscover Service.
Mobility Service URL Requirement
In a default configuration, a user who is connected to the internal network via Wi-Fi will always be returned the external Mobility Service URL for his/her home pool. The user’s device must be able to query the internal DNS zone and resolve the external Lync Web Services FQDN to the IP address of the external interface of the reverse proxy. The user will then make an outbound, hair-pinned connection to the Mobility Service through the reverse proxy.
Automatic Discovery and Push Notification Requirements
If you support automatic discovery, you need to create the following DNS records for each SIP domain:
An internal DNS record to support mobile users who connect from within your organization's network
An external, or public, DNS record to support mobile users who connect from the Internet
An external, or public, DNS record to support Push Notification
The internal automatic discovery URL should not be addressable from outside your network. The external automatic discovery URL should not be addressable from within your network. However, if you cannot meet this requirement for the external URL, mobile client functionally should not be affected, because the internal URL is always tried first.
The DNS records can be either CNAME records or A (host) records.
You need to create the following internal DNS record:
Internal DNS Records
| Record type | Host name | Resolves to |
|---|---|---|
A (host) |
lyncweb.contoso.com (example external web services URL) |
Record located on the internal DNS that resolves to the external IP address of the URL of the external web services, for example https://lyncweb.contoso.com |
And, one of the following additional internal DNS records:
| Record type | Host name | Resolves to |
|---|---|---|
CNAME |
lyncdiscoverinternal.<sipdomain> |
Internal Web Services FQDN for your Director pool, if you have one, or for your Front End pool if you do not have a Director |
A (host) |
lyncdiscoverinternal.<sipdomain> |
Internal Web Services IP address (virtual IP (VIP) address if you use a load balancer) of your Director pool, if you have one, or of your Front End pool if you do not have a Director |
You need to create one of the following external DNS records:
External DNS Records
| Record type | Host name | Resolves to |
|---|---|---|
CNAME |
lyncdiscover.<sipdomain> |
External Web Services FQDN for your Director pool, if you have one, or for your Front End pool if you do not have a Director |
A (host) |
lyncdiscover.<sipdomain> |
External or public IP address of the reverse proxy |
Note
External traffic goes through the reverse proxy.
Note
Mobile device clients do not support multiple Secure Sockets Layer (SSL) certificates from different domains. Therefore, CNAME redirection to different domains is not supported over HTTPS. For example, a DNS CNAME record for lyncdiscover.contoso.com that redirects to an address of director.contoso.net is not supported over HTTPS. In such a topology, a mobile device client needs to use HTTP for the first request, so that the CNAME redirection is resolved over HTTP. Subsequent requests then use HTTPS. To support this scenario, you need to configure your reverse proxy with a web publishing rule for port 80 (HTTP). For details, see "To create a web publishing rule for port 80" in Configuring the Reverse Proxy for Mobility.
CNAME redirection to the same domain is supported over HTTPS. In this case the destination domain's certificate covers the originating domain.
| Record Type | Definition | Resolves to |
|---|---|---|
SRV |
_sipfederationtls._tcp.<SIP domain name> to Host A record of Access Edge service |
for example _sipfedrationtls._tcp.contoso.com with defined port of TCP 5061 to sip.contoso.com Important The SRV record must point to an A in the same SIP domain |
Port and Firewall Requirements
Mobility Service requires the following two Web Services listening ports on Front End Servers or Standard Edition servers. You manually set these ports during the deployment process by using the Set-CsWebServer cmdlet. For details, see Setting Internal Server Ports for Mobility.
You also must create an allow rule for TCP 5061 for federation with the online provider for Push Notification. For details, see the Reference Architecture.
Port 5086, used to listen for mobility requests from inside the corporate network. This is a SIP port used by the Mobility Service internal process.
Port 5087, used to listen for mobility requests from the Internet. This is a SIP port used by the Mobility Service external process.
If you support push notifications and want Apple mobile devices to receive push notifications over your Wi-Fi network, you also need to open port 5223 on your enterprise Wi-Fi network. Port 5223 is an outbound TCP port used by the Apple Push Notification Service (APNS). The mobile device or the notification service can initiate the connection, requiring outbound port availability on the enterprise WiFi network. For details, see http://support.apple.com/kb/TS1629 and http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
Certificate Requirements
If you support automatic discovery for Lync mobile clients, you need to modify the subject alternative name lists on certificates to support secure connections from the mobile clients. You need to request and assign new certificates, adding the subject alternative name entries described in this section, for each Front End Server and Director that runs the Autodiscover Service. The recommended approach is to also modify the subject alternative names lists on certificates for your reverse proxies. You need to add subject alternative name entries for every SIP domain in your organization.
Reissuing certificates by using an internal certificate authority is typically a simple process, but adding multiple subject alternative name entries to public certificates used by the reverse proxy can be expensive. If you have many SIP domains, making the addition of subject alternative names very expensive, you can configure the reverse proxy to make the initial Autodiscover Service request over port 80 using HTTP, instead of port 443 using HTTPS (the default configuration). The request is then redirected to port 8080 on the Director or Front End pool. When you publish the initial Autodiscover Service request on port 80, you do not need to change certificates for the reverse proxy, because the request uses HTTP rather than HTTPS. This approach is supported but not recommended.
Note
For more details about using port 80 for the initial request, see "Initial Autodiscover Process Using Port 80" in Autodiscover Service Requirements in the Planning for External Users documentation.
Note
If your Lync Server 2010 infrastructure uses internal certificates that are issued from an internal certification authority (CA) and you plan to support mobile devices connecting wirelessly, either the root certificate chain from the internal CA must be installed on the mobile devices or you must change to a public certificate on your Lync Server infrastructure.
This section describes the subject alternative names required for the following certificates:
Edge Server or Edge Server pool
Director or Director pool
Front End Server or Front End pool
Reverse proxy
Description |
Subject alternative name entry |
Access Edge service |
SAN=sip.<sipdomain> |
Director Pool Certificate Requirements
| Description | Subject alternative name entry |
|---|---|
Internal Autodiscover Service URL |
SAN=lyncdiscoverinternal.<sipdomain> |
External Autodiscover Service URL |
SAN=lyncdiscover.<sipdomain> |
Note
Alternatively, you can use SAN=*.<sipdomain> for the Autodiscover (lyncdiscover and lyncdicoverinternal) records only.
Front End Pool Certificate Requirements
| Description | Subject alternative name entry |
|---|---|
Internal Autodiscover Service URL |
SAN=lyncdiscoverinternal.<sipdomain> |
External Autodiscover Service URL |
SAN=lyncdiscover.<sipdomain> |
Note
Alternatively, you can use SAN=*.<sipdomain> for the Autodiscover (lyncdiscover and lyncdicoverinternal) records only.
Reverse Proxy (Public CA) Certificate Requirements
| Description | Subject alternative name entry |
|---|---|
External Autodiscover Service URL |
SAN=lyncdiscover.<sipdomain> |
Note
You assign this certificate to the SSL Listener on the reverse proxy.
Internet Information Services (IIS) Requirements
We recommend that you use IIS 7.5 for mobility. The Mobility Service installer sets some ASP.NET flags to improve performance. IIS 7.5 is installed by default on Windows Server 2008 R2, and the Mobility Service installer automatically changes the ASP.NET settings. If you use IIS 7.0 on Windows Server 2008, you need to manually change these settings. For details, see Installing the Mobility and Autodiscover Services.
Hardware Load Balancer Requirements
If your environment includes a Front End pool, the external Web Services virtual IPs (VIPs) on the hardware load balancer used for Web Services traffic must be configured for cookie-based persistence. Cookie-based persistence ensures that multiple connections from a single client are sent to one server to maintain session state. The cookies must meet specific requirements. For details about cookie requirements, see Load Balancing Requirements.
If you plan to support Lync mobile clients only over your internal Wi-Fi network, you should configure the internal Web Services VIPS for cookie-based persistence as described for external Web Services VIPs. In this situation, you should not use source_addr persistence for the internal Web Services VIPs on the hardware load balancer. For details, see Load Balancing Requirements.
Reverse Proxy Requirements
If you support automatic discovery for Lync mobile clients, you need to create a new web publishing rule as follows:
If you decide to update the subject alternative names lists on the reverse proxy certificates and use HTTPS for the initial Autodiscover Service request, you need to create a new web publishing rule for lyncdiscover.<sipdomain>. You also need to ensure that a web publishing rule exists for the external Web Services URL on the Front End pool.
If you decide to use HTTP for the initial Autodiscover Service request so that you do not need to update the subject alternative names list on the reverse proxy certificates, you need to create a new web publishing rule for port 80 (HTTP).