Lync Technical Requirements for Mobility

 
I was looking at the document on the web about Planning for Mobility in Lync. I want to point out the technical requirements in this documents as there need to be some changes in your environment to be done before it might work as you espect it to work.
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.

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
· 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 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
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
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 one of the following internal DNS records:
Internal DNS Records

You need to create one of the following external DNS records:
External DNS Records

Note:
External traffic goes through the reverse proxy.
Notes:
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.
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.
· 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 initiates the connection. For details, see http://support.apple.com/kb/TS1629
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:
· Director pool
· Front End pool
· Reverse proxy
Director Pool Certificate Requirements

Note:
Alternatively, you can use SAN=*.<sipdomain>
Front End Pool Certificate Requirements

Note:
Alternatively, you can use SAN=*.<sipdomain>
Reverse Proxy (Public CA) Certificate Requirements

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).