Defining Your Mobility Requirements
Topic Last Modified: 2012-10-09
During the planning phase for the Lync Server 2010 mobility feature, you need to make some decisions that determine your deployment steps.
You need to make the following decisions:
Do you want to use automatic discovery for Lync mobile clients?
If you want to support automatic discovery, you need to create new internal and external Domain Name System (DNS) records, add subject alternative names to certificates on the Front End Servers, Directors, and reverse proxy, and create new web publishing rules on the reverse proxy. For details, see Technical Requirements for Mobility. With automatic discovery, users can automatically locate Lync Server Web Services from anywhere inside or outside the corporate network without entering URLs in their mobile device settings.
If you use manual settings instead of automatic discovery, mobile users need to manually enter the following URLs in their mobile device:
https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access
https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access
We strongly recommend using automatic discovery. The primary use of manual settings is for troubleshooting.
If you decide to support automatic discovery, are you willing to update certificates on the reverse proxy with subject alternative names for each SIP domain?
If you have many SIP domains, updating public certificates on the reverse proxy can become very expensive. If this is the case, you can choose to implement automatic discovery such that the initial Autodiscover Service request uses HTTP on port 80, instead of using HTTPS on port 443. This approach is not the recommended approach. If you select this alternative, you do not need to update the certificates on the reverse proxy, but you need to create a web publishing rule for HTTP on port 80. For more details, see Technical Requirements for Mobility and Autodiscover Service Requirements.
Do you want to support Lync mobile clients both internal and external to the corporate network, or support clients only inside the corporate network?
If you want to support mobile clients internal and external to your network, mobile devices can access mobility features from any location. The default configuration is to support clients both internal and external to the corporate network.
Although the default configuration enables mobile client traffic to go through the external site, you can restrict mobile client traffic to the internal corporate network. When you restrict the traffic to the internal network, users can use Lync mobile applications on their mobile devices only when they are inside the network. To support this configuration, you need to run the Set-CsMcxConfiguration cmdlet. You also need to configure the internal Web Services virtual IPs (VIPs) on your Front End Server and Director hardware load balancers for cookie-based persistence. For details about hardware load balancer requirements, see Load Balancing Requirements. For details about using Set-CsMcxConfiguration to restrict mobile client traffic to the internal network, see Installing the Mobility and Autodiscover Services.
Do you want to support push notifications for Apple iOS devices and Windows Phones?
If you support push notifications, supported Apple iOS devices and Windows Phones receive a notification of events that occur when the mobile application is inactive. You need to configure your Edge Server to have a federation relationship with the cloud-based Lync Server 2010 Push Notification Service, which is located in the Lync Online datacenter, and run a cmdlet to enable push notifications.
If you want to support push notifications over your Wi-Fi network, in addition to supporting push notifications over the mobile device providers' 3G or data networks, you need to open port 5223 outbound on your enterprise Wi-Fi network. Supporting push notifications over the Wi-Fi network supports mobile devices that use only Wi-Fi and mobile devices that have poor indoor reception.
If you do not want to support push notifications, users of Apple mobile devices and Windows Phones will not find out about events, such as instant message invitations or missed messages, that occur when the mobile application is inactive.
Do you want all users to have access to mobility features or do you want to be able to specify which users have access to these features?
By default, the global mobility policy enables access to mobility and Call via Work to all users. If you want to define who can use Lync mobile applications or the Call via Work feature by site or by user, you need to create new site or user scope mobility policies.
Do you want users who are not enabled for Enterprise Voice to be able to use Click to Join to join conferences?
For users to have access to mobility features and Call via Work, they must be enabled for Enterprise Voice. However, users who are not enabled for Enterprise Voice can join conferences by clicking the link on their mobile device if they have an appropriate voice policy assigned to them. You can either assign a specific voice policy to these users or make sure that a global or site level policy exists that applies to them. The voice policy you assign must have public switched telephone network (PSTN) usage records and routes that define the areas to which users can dial out to join a conference. For details about setting voice policy, PSTN usage records, and routes, see Configuring Voice Policies, PSTN Usage Records, and Voice Routes.
Mobile users who want to use Click to Join require a voice policy, along with the related PSTN usage records and voice routes, because clicking the link on the mobile device results in an outbound call from Lync Server 2010.