Microsoft Lync Server 2010 Published: March 2012
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. Copyright 2011 Microsoft Corporation. All rights reserved.
Contents Planning for Mobility...1 Mobility Features and Capabilities...1 Topologies and Components for Mobility...2 Technical Requirements for Mobility...3 Defining Your Mobility Requirements...9 Deployment Process for Mobility...11 Deploying Mobility...14 Creating DNS Records for the Autodiscover Service...14 Installing Cumulative Update for Lync Server 2010: November 2011...17 Setting Internal Server Ports for Mobility...19 Installing the Mobility and Autodiscover Services...19 Install Dynamic Content Compression in IIS...20 Install Hotfix for ASP.NET for IIS 7.0...21 Install Mobility Service and Autodiscover Service...21 Change ASP.NET Settings and Restart IIS for IIS 7.0...22 Modifying Certificates for Mobility...23 Configuring the Reverse Proxy for Mobility...25 Verifying Your Mobility Deployment...28 Configuring for Push Notifications...29 Configuring Mobility Policy...31 Monitoring Mobility for Performance...33 Monitoring for Server Memory Capacity Limits...34 Monitoring Mobility Service Usage...35 Monitoring IIS Request Tracing Log Files...35 Configuring Mobility Service for High Performance...36 Mobility Performance Counters...37
Planning for Mobility When you deploy cumulative update for Lync Server 2010: November 2011, you can deploy the mobility feature to provide Microsoft Lync 2010 functionality on mobile devices. This section provides details about the mobility feature and how to plan for deploying it. In This Section Mobility Features and Capabilities Topologies and Components for Mobility Technical Requirements for Mobility Defining Your Mobility Requirements Deployment Process for Mobility Mobility Features and Capabilities The mobility feature in Lync Server 2010 supports Lync functionality on mobile devices. When you deploy the Microsoft Lync Server 2010 Mobility Service, users can use supported Apple ios, Android, Windows Phone, or Nokia mobile devices to perform such activities as sending and receiving instant messages, viewing contacts, and viewing presence. In addition, mobile devices support some Enterprise Voice features, such as click to join a conference, Call via Work, single number reach, voice mail, and missed calls. Tip: With single number reach, a user receives calls on a mobile phone that were dialed to the work number. With Call via Work, the user places an outbound call from a mobile phone by using a work phone number instead of the mobile phone number. To use Call via Work, a user can either dial directly from the mobile phone or use dial-out conferencing. With dialout conferencing, the user in effect requests the Mobility Service to make the call for them. The server initiates the call and then calls the user back on the mobile phone. When the user answers, the server completes the call by dialing the other party. By using Call via Work, users can maintain their work identity during a call, which means that the call recipient does not see the caller's mobile number, and the caller avoids incurring outbound calling charges. Not all features work exactly the same on all mobile devices. For details about features supported on mobile devices, see Mobile Client Comparison Tables. For details about supported devices and operating systems, see the requirements topics under Planning for Mobile Clients. When you use the Microsoft Lync Server 2010 Autodiscover Service along with the Mobility Service, mobile applications can automatically locate Lync Server Web Services without requiring users to manually enter the URLs in their device settings. Manually entering URLs in mobile device settings is also supported, primarily for troubleshooting purposes. 1
The mobility feature also supports push notifications for mobile devices that do not support applications running in the background. A push notification is a notification that is sent to a mobile device about an event that occurs while a mobile application is inactive. Examples of events that can result in a push notification are missed instant messaging (IM) invitations or missed calls. The Mobility Service, Autodiscover Service, and support for push notifications are provided in the cumulative update for Lync Server 2010: November 2011. Topologies and Components for Mobility To support Lync mobile applications on mobile devices, the cumulative update for Lync Server 2010: November 2011 provides three new services. This section briefly describes these components and identifies the Lync Server 2010 topologies that support mobility. Mobility Components The new services that support mobility are as follows: Microsoft Lync Server 2010 Mobility Service This new service supports Lync 2010 functionality, such as instant messaging (IM), presence, and contacts, on mobile devices. For a complete list of supported Lync features on mobile devices, see Mobile Client Comparison Tables. The Mobility Service is installed on every Front End Server in each pool that is to support Lync functionality on mobile devices. When you install the Mobility Service, a new virtual directory (Mcx) is created under both the internal website and the external website on your Front End Servers. Microsoft Lync Server 2010 Autodiscover Service This new service identifies the location of the user and enables mobile devices to locate resources, such as the internal and external URLs for Lync Server Web Services and the URL for the new Mobility Service, regardless of network location. Automatic discovery uses hardcoded host names (lyncdiscoverinternal for users inside the network and lyncdiscover for users outside the network) and the SIP domain of the user. It supports client connections using either HTTP or HTTPS. The Autodiscover Service is installed on every Front End Server and on every Director in each pool that is to support Lync functionality on mobile devices. When you install the Autodiscover Service, a new virtual directory (Autodiscover) is created under both the internal website and the external website on both Front End Servers and Directors. Microsoft Lync Server 2010 Push Notification Service This service is a cloud-based service that is located in the Lync Online datacenter. When the Lync mobile application on a supported Apple ios device or Windows Phone is inactive, it cannot respond to new events, such as a new instant messaging (IM) invitation, a missed instant message, a missed call, or voice mail, because these devices do not support mobile applications running in the background. In such a case, a notification, called a push notification, for the new event is sent to the mobile device. The Mobility Service sends the notification to the cloud-based Push Notification Service, which then sends the notification either to the Apple Push Notification 2
Service (APNS) (for supported Apple ios devices) or to the Microsoft Push Notification Service (MPNS) (for Windows Phone), which sends it on to the mobile device. The user can then touch the notification on the mobile device to activate the application. The Lync mobile application can run in the background on Android and Nokia devices, so push notifications are not required for these devices. The following diagram illustrates how the Push Notification Service fits in with a Lync Server 2010 topology. Supported Topologies You can deploy the mobility feature in the following topologies: Lync Server 2010 Standard Edition Lync Server 2010 Enterprise Edition The Edge Server can be a Lync Server 2010 Edge Server, or it can be an Microsoft Office Communicator 2007 R2 Edge Server if you are in the process of migrating to Lync Server 2010. Important: The Mobility Service is not supported on dual-homed Front End Servers that are collocated with the Mediation Server role. Technical Requirements for Mobility 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 3
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. 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 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 4
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 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 W-Fi will always be returned the external Mcx 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 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 5
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 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 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 External traffic goes through the reverse proxy. 6
Notes: Planning, Deploying, and Monitoring Mobility 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 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 7
reverse proxy, because the request uses HTTP rather than HTTPS. This approach is supported but not recommended. 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. 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 Description Internal Autodiscover Service URL External Autodiscover Service URL Subject alternative name entry SAN=lyncdiscoverinternal.<sipdomain> SAN=lyncdiscover.<sipdomain> Alternatively, you can use SAN=*.<sipdomain> Front End Pool Certificate Requirements Description Internal Autodiscover Service URL External Autodiscover Service URL Subject alternative name entry SAN=lyncdiscoverinternal.<sipdomain> SAN=lyncdiscover.<sipdomain> Alternatively, you can use SAN=*.<sipdomain> Reverse Proxy (Public CA) Certificate Requirements Description External Autodiscover Service URL Subject alternative name entry SAN=lyncdiscover.<sipdomain> 8
You assign this certificate to the SSL Listener on the reverse proxy. Planning, Deploying, and Monitoring Mobility 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). Defining Your Mobility Requirements 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, 9
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 inbound and outbound on your enterprise Wi-Fi network. Supporting push notifications over the 10
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. Deployment Process for Mobility This section describes the sequence of steps required to deploy the Lync Server 2010 mobility feature. Mobility Deployment Process Phase Steps Permissions Deployment documentation Create Domain Name System (DNS) records Create an internal DNS CNAME or A (host) record to resolve the internal Autodiscover Service URL. Create an external DNS CNAME or A (host) record to resolve the external Autodiscover Service URL. Domain Admins DnsAdmins Creating DNS Records for the Autodiscover Service 11
Phase Steps Permissions Deployment documentation Install cumulative update for Lync Server 2010: November 2011 Install updates on all server roles in your deployment. CsAdministrator Installing Cumulative Update for Lync Server 2010: November 2011 Set ports for the Front End Server Set internal listening port for the Mobility Service. Set external listening port for the Mobility Service. RTCUniversalServerAdmins Setting Internal Server Ports for Mobility Install Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service Run McsStandalone.msi on each Front End Server to install the Mobility Service and the Autodiscover Service. Run McsStandalone.msi on each Director to install the Autodiscover Service. CsAdministrator Installing the Mobility and Autodiscover Services Modify certificates Add subject alternative name entries to the following certificates to support secure connections for mobile users: Local administrator Modifying Certificates for Mobility Director certificate Front End pool certificate Reverse proxy certificate Configure the reverse proxy Assign certificates updated with subject alternative names to the Secure Sockets Layer (SSL) Listener. Local administrator Configuring the Reverse Proxy for Mobility Configure a new web publishing rule for the external Autodiscover Service URL. Ensure that a web publishing rule exists for the external Lync Server Web Services URL on your Front 12
Phase Steps Permissions Deployment documentation Or End pool. If you choose to use HTTP for the initial Autodiscover request and not update subject alternative name lists on the certificates, configure a new web publishing rule for port 80 HTTP. Test your mobility deployment Run Test-CsMcxP2PIM to test sending an instant message from one person to another. CsAdministrator Verifying Your Mobility Deployment Configure for push notifications For Lync Server 2010 Edge Servers, add a Lync Server online hosting provider and configure hosting provider federation. RtcUniversalServerAdmins Configuring for Push Notifications For Office Communications Server 2007 R2 Edge Servers, add a federated partner. If you want to support push notifications over a Wi-Fi network, configure a firewall rule inbound and outbound for TCP port 5223. Use the Set- CsPushNotificationConfigura tion cmdlet to enable push notifications to the Apple Push Notification Service (APNS) and Microsoft Push Notification Service (MPNS). This feature is disabled by default. Use the Test- CsFederatedPartner cmdlet to test the federation configuration and the Test- CsMCXPushNotification cmdlet to test push notifications. Configure Use the Set-CsMobilityPolicy CsAdministrator Configuring 13
Phase Steps Permissions Deployment documentation mobility policy cmdlet to allow or disallow user access to mobility features and to enable or disable Call via Work. These features are enabled by default. Mobility Policy Deploying Mobility When you deploy the Lync Server 2010 mobility feature, mobile users can use supported mobile devices for Lync functionality such as instant messaging (IM), presence, and contacts. To deploy the mobility feature, you must deploy cumulative update for Lync Server 2010: November 2011. For details about requirements for deploying the mobility feature, see Planning for Mobility. This section guides you through the steps for deploying and verifying the mobility and automatic discovery features available with cumulative update for Lync Server 2010: November 2011. In This Section Creating DNS Records for the Autodiscover Service Installing Cumulative Update for Lync Server 2010: November 2011 Setting Internal Server Ports for Mobility Installing the Mobility and Autodiscover Services Modifying Certificates for Mobility Configuring the Reverse Proxy for Mobility Verifying Your Mobility Deployment Configuring for Push Notifications Configuring Mobility Policy Creating DNS Records for the Autodiscover Service To support autodiscovery for Lync Server 2010 mobile users, you need to create the following Domain Name System (DNS) records: 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 You must create an internal DNS record and an external DNS record for each SIP domain. The DNS records can be either A (host) records or CNAME records. The following procedures describe how to create internal and external DNS records. For more details about the DNS requirements for mobile users, see Technical Requirements for Mobility. 14
To create DNS CNAME records 1. Log on to a DNS server as follows: Planning, Deploying, and Monitoring Mobility To create an internal DNS record, log on to a DNS server in your network as a member of the Domain Admins group or a member of the DnsAdmins group. To create an external DNS record, connect to your public DNS provider. 2. Open the DNS administrative snap-in: Click Start, click Administrative Tools, and then click DNS. 3. Do one of the following: For an internal DNS record, in the console tree of the DNS server, expand Forward Lookup Zones for your Active Directory domain (for example, contoso.local). This domain is the Active Directory domain where your Lync Server Director pool and Front End pool are installed. For an external DNS record, in the console tree of the DNS server, expand Forward Lookup Zones for your SIP domain (for example, contoso.com). 4. Verify that a host A record exists for your Director pool as follows: For an internal DNS record, a host A record should exist for the internal Web Services fully qualified domain name (FQDN) for your Director pool (for example, lyncwebdir01.contoso.local). For an external DNS record, a host A record should exist for the external web services FQDN for your Director pool (for example, lyncwebextdir.contoso.com). 5. Verify that a host A record exists for your Front End pool as follows: For an internal DNS record, a host A record should exist for the internal Web Services FQDN for your Front End pool (for example, lyncwebpool01.contoso.local). For an external DNS record, a host A record should exist for the external Web Services FQDN for your Front End pool (for example, lyncwebextpool01.contoso.com). 6. For an internal DNS record, in the console tree of your DNS server, expand Forward Lookup Zones for your SIP domain (for example, contoso.com). If you are creating an external DNS record, Forward Lookup Zones is already expanded for your SIP domain from step 3. 7. Right-click the SIP domain name, and then click New Alias (CNAME). 8. In Alias name, type one of the following: For an internal DNS record, type lyncdiscoverinternal as the host name for the internal Autodiscover Service URL. For an external DNS record, type lyncdiscover as the host name for the external Autodiscover Service URL. 9. In Fully qualified domain name (FQDN) for target host, do one of the following: For an internal DNS record, type or browse to the internal Web Services FQDN for 15
your Director pool (for example, lyncwebdir01.contoso.local), and then click OK. For an external DNS record, type or browse to the external Web Services FQDN for your Director pool (for example, lyncwebextdir.contoso.com), and then click OK. If you do not use a Director, use the internal and external Web Services FQDN for the Front End pool, or, for a single server, the FQDN for the Front End Server or Standard Edition server. Important: You must create a new Autodiscover CNAME record in the forward lookup zone of each SIP domain that you support in your Lync Server 2010 environment. To create DNS A records 1. Log on to a DNS server as follows: To create an internal DNS record, log on to a DNS server in your network as a member of the Domain Admins group or a member of the DnsAdmins group. To create an external DNS record, connect to your public DNS provider. 2. Open the DNS administrative snap-in: Click Start, click Administrative Tools, and then click DNS. 3. Do one of the following: For an internal DNS record, in the console tree of the DNS server, expand Forward Lookup Zones for your Active Directory domain (for example, contoso.local). This domain is the Active Directory domain where your Lync Server Director pool and Front End pool are installed. For an external DNS record, in the console tree of the DNS server, expand Forward Lookup Zones for your SIP domain (for example, contoso.com). 4. Verify that a host A record exists for your Director pool as follows: For an internal DNS record, a host A record should exist for the internal Web Services FQDN for your Director pool (for example, lyncwebdir01.contoso.local). For an external DNS record, a host A record should exist for the external Web Services FQDN for your Director pool (for example, lyncwebextdir.contoso.com). 5. Verify that a host A record exists for your Front End pool as follows: For an internal DNS record, a host A record should exist for the internal Web Services FQDN for your Front End pool (for example, lyncwebpool01.contoso.local). For an external DNS record, a host A record should exist for the external Web Services FQDN for your Front End pool (for example, lyncwebextpool01.contoso.com). 6. For an internal DNS record, in the console tree of your DNS server, expand Forward Lookup Zones for your SIP domain (for example, contoso.com). 16
If you are creating an external DNS record, Forward Lookup Zones is already expanded for your SIP domain from step 3. 7. Right-click the SIP domain name, and then click New Host (A or AAAA). 8. In Name, type the host name as follows: For an internal DNS record, type lyncdiscoverinternal as the host name for the internal Autodiscover Service URL. For an external DNS record, type lyncdiscover as the host name for the external Autodiscover Service URL. The domain name is assumed from the zone in which the record is defined and, therefore, does not need to be entered as part of the A record. 9. In IP Address, type the IP address as follows: For an internal DNS record, type the internal Web Services IP address of the Director (or, if you use a load balancer, type the virtual IP (VIP) of the Director load balancer). If you do not use a Director, type the IP address of the Front End Server or Standard Edition server, or, if you use a load balancer, type the VIP of the Front End pool load balancer. For an external DNS record, type the external or public IP address of the reverse proxy. 10. Click Add Host, and then click OK. 11. To create an additional A record, repeat steps 8 through 10. Important: You must create a new Autodiscover A record in the forward lookup zone of each SIP domain that you support in your Lync Server 2010 environment. 12. When you are finished creating A records, click Done. Installing Cumulative Update for Lync Server 2010: November 2011 Before you can install the Lync Server 2010 Mobility Service and Lync Server 2010 Autodiscover Service, you need to install cumulative update for Lync Server 2010: November 2011. Install the cumulative update on all server roles in your deployment. You can find the cumulative update for Lync Server 2010: November 2011 installation package in the Microsoft Download Center at http://go.microsoft.com/fwlink/?linkid=208564. To install cumulative update for Lync Server 2010: November 2011 1. Log on to the server you are upgrading as a member of the CsAdministrator role. 17
2. Download the latest installation package from the Microsoft Download Center and extract it to the local hard disk. 3. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 4. Stop Lync Server services. At the command line, type: Stop-CsWindowsService 5. Close all Lync Server Management Shell windows. 6. Stop the World Wide Web service. At the command line, type: net stop w3svc 7. Install the cumulative update for Lync Server 2010: November 2011 by running LyncServerUpdateInstaller.exe. Restart the computer if you are prompted to do so. 8. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 9. Stop Lync Server services again to catch Global Assembly Cache (GAC) d assemblies. At the command line, type: Stop-CsWindowsService 10. Restart the World Wide Web service. At the command line, type: net start w3svc 11. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 12. Apply the changes made by LyncServerUpdateInstaller.exe to the SQL Server databases by doing one of the following: If Enterprise Edition Back End Server databases are not collocated with any other databases, such as Archiving or Monitoring databases, at the command line, type the following: Install-CsDatabase Update ConfiguredDatabases SqlServerFqdn <SQL Server FQDN> If Enterprise Edition Back End Server databases are collocated with other databases, such as Archiving or Monitoring databases, at the command line, type the following: Install-CsDatabase Update ConfiguredDatabases SqlServerFqdn <SQL Server FQDN> -ExcludeCollocatedStores For Standard Edition, type the following: Install-CsDatabase Update -LocalDatabases 13. Restart the Lync Server services. At the command line, type: 18
Start-CsWindowsService Planning, Deploying, and Monitoring Mobility Setting Internal Server Ports for Mobility The Lync Server 2010 Mobility Service requires two new ports on internal servers: one for the internal Web Services and one for the external Web Services. To set ports for internal servers 1. Log on to the computer as a user who is a member of the RTCUniversalServerAdmins group. 2. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 3. Set the port for the internal Web Services. At the command line, type: Set-CsWebServer Identity <name of pool> McxSipPrimaryListeningPort 5086 For example: Set-CsWebServer Identity pool01.contoso.com McxSipPrimaryListeningPort 5086 Where pool01.contoso.com is the pool where the Mobility Service will be installed 4. Set the port for the external Web Services. At the command line, type: Set-CsWebServer Identity <name of pool> McxSipExternalListeningPort 5087 For example: Set-CsWebServer Identity pool01.contoso.com McxSipExternalListeningPort 5087 Where pool01.contoso.com is the pool where the Mobility Service will be installed The Set-CsWebServer cmdlet runs Publish-CsTopology to publish the updated topology. 5. At the command line, type the following: Enable-CsTopology -verbose Installing the Mobility and Autodiscover Services After you install cumulative update for Lync Server 2010: November 2011 and set the ports, you need to install the new Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service. 19
Important: Planning, Deploying, and Monitoring Mobility It is important that before installing the Mobility Service and Autodiscover Service, you first set the ports for the pool that you want to enable for mobility. If you do not set the ports first, the Mobility Service will not be installed. The Mobility Service supports presence, instant messaging (IM), contacts, and dial-out conferencing on mobile devices. It also supports Enterprise Voice features, such as single number reach (receive calls on a mobile device that were dialed to your work number), Call via Work (call from a mobile device using your work identity), voice mail, and missed calls, on supported mobile devices. The Autodiscover Service enables mobile devices to locate resources, such as the URL for Web Services, regardless of network location, without requiring the user to manually enter URLs in the mobile device settings. The Mobility and Autodiscover Services installer requires that the Internet Information Services (IIS) module for Dynamic Content Compression be installed. If this module is not already installed in your deployment, install it before you install the Mobility and Autodiscover Services. For details, see Install Dynamic Content Compression in IIS. If you use IIS 7.5 (recommended), you only need to install the Mobility and Autodiscover Services. The installer automatically changes the required ASP.NET settings for you. For details, see Install Mobility Service and Autodiscover Service. If you use IIS 7.0, you need to perform extra steps to change some ASP.NET settings. Perform the following steps in the specified order: 1. Install the hotfix for ASP.NET settings so that you can configure the CLRConfigFile parameter in the applicationhost.config file. For details, see Install Hotfix for ASP.NET for IIS 7.0. 2. Install Mobility Service and Autodiscover Service. For details, see Install Mobility Service and Autodiscover Service. 3. Change ASP.NET settings and restart IIS. For details, see Change ASP.NET Settings and Restart IIS for IIS 7.0. In This Section Install Dynamic Content Compression in IIS Install Hotfix for ASP.NET for IIS 7.0 Install Mobility Service and Autodiscover Service Change ASP.NET Settings and Restart IIS for IIS 7.0 Install Dynamic Content Compression in IIS The Mobility and Autodiscover Services installer requires the Internet Information Services (IIS) module for Dynamic Content Compression to be installed. If this module is not already installed, you must install it before you install the Mobility and Autodiscover Services. Follow the procedure in this section to install Dynamic Content Compression for IIS. If you already have Dynamic Content Compression installed, you can skip this step. 20
To install IIS Dynamic Content Compression Planning, Deploying, and Monitoring Mobility 1. Log on to the computer as a user who is a member of the CsAdministrator group. 2. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 3. For Windows Server 2008 R2, at the command line, type: Import-Module ServerManager Add-WindowsFeature Web-Server, Web-Dyn-Compression 4. For Windows Server 2008, at the command line, type: ServerManagerCMD.exe Install Web-Dyn-Compression If you use IIS 7.0, go to Install Hotfix for ASP.NET for IIS 7.0. If you use IIS 7.5, go to Install Mobility Service and Autodiscover Service. Install Hotfix for ASP.NET for IIS 7.0 If you use Internet Information Services (IIS) 7.0, you need to install a hotfix that allows you to configure the CLRConfigFile parameter in the applicationhost.config file. You need to install this hotfix on every Front End Server where you plan to install the Mobility Service. The hotfix is available from Microsoft Knowledge Base article 2290617, "FIX: A hotfix is available to enable the configuration of some ASP.NET properties for each application pool in IIS 7.0," at http://go.microsoft.com/fwlink/?linkid=3052&kbid=2290617. If you use IIS 7.5, you can skip this step. For the next step, go to Install Mobility Service and Autodiscover Service. Install Mobility Service and Autodiscover Service You need to run the Mobility and Autodiscover Services installer on each Front End Server and each Director in every Lync Server pool where you want to provide the mobility feature. The installer installs the Mobility Service on Front End Servers and installs the Autodiscover Service on Front End Servers and Directors. The latest installation package is available for download from the Microsoft Download Center at http://go.microsoft.com/fwlink/?linkid=230577. The default configuration enables Mobility Service traffic to go through the external site. However, you can restrict Mobility Service traffic to the internal corporate network. When you restrict the traffic to the internal corporate network, users cannot access mobility services from outside the corporate network. When you restrict mobility traffic to the internal network, you should configure the internal Web Services virtual IPs (VIPs) for cookie-based persistence on your hardware load balancer. For details, see Load Balancing Requirements. 21
To install Mobility Service and Autodiscover Service Planning, Deploying, and Monitoring Mobility 1. Log on to the computer as a user who is a member of the CsAdministrator group. 2. Download the latest installation package from the Microsoft Download Center and extract it to the hard disk. 3. Copy McxStandalone.msi to C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup. 4. Open the command prompt: Click Start, click in the search box, type cmd, and then press ENTER. 5. At the command prompt, run C:\Program Files\Microsoft Lync Server 2010\Deployment\Bootstrapper.exe. Tip: If you run Bootstrapper.exe from Lync Server Management Shell, you must prepend the path with a period (.) and enclose the path in quotation marks ("). For example:."c:\program Files\Microsoft Lync Server 2010\Deployment\Bootstrapper.exe". 6. If you want to restrict mobility services to the internal corporate network, do the following: Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. At the command line, type the following: Set-CsMcxConfiguration ExposedWebUrl Internal If you use IIS 7.0, go to Change ASP.NET Settings and Restart IIS for IIS 7.0. If you use IIS 7.5, go to Modifying Certificates for Mobility. Change ASP.NET Settings and Restart IIS for IIS 7.0 If you use Internet Information Services (IIS) 7.0, you need to manually change some ASP.NET settings for the Mobility Service. If you use IIS 7.5, the installer automatically changes these settings for you, and you can skip this step. Important: You must have installed the hotfix mentioned previously and the Mobility Service before performing this step. For IIS 7.0, perform the following procedure on each Front End Server where you installed the Mobility Service. To change ASP.NET settings in IIS 7.0 1. Log on to the server as a local administrator. 2. Use a text editor such as Notepad to open the applicationhost.config file, located at C:\Windows\System32\inetsrv\config\applicationHost.config. 22