Planning, Deploying, and Monitoring Mobility

・ Planning, Deploying, and Monitoring Mobility

・ Microsoft Lync Server 2010

Published: December 2011

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

Capacity Planning for Mobility........................................................................................ 11

Deployment Process for Mobility.................................................................................... 16

Deploying Mobility............................................................................................................ 18

Creating DNS Records for the Autodiscover Service........................................................ 19

Installing Cumulative Update for Lync Server 2010: November 2011.................................. 22

Setting Internal Server Ports for Mobility.......................................................................... 23

Installing the Mobility and Autodiscover Services............................................................. 24

Modifying Certificates for Mobility.................................................................................. 26

Configuring the Reverse Proxy for Mobility...................................................................... 28

Verifying Your Mobility Deployment................................................................................ 31

Configuring for Push Notifications.................................................................................. 32

Configuring Mobility Policy............................................................................................. 34

Monitoring Mobility for Performance................................................................................... 36

Monitoring for Server Memory Capacity Limits................................................................. 37

Monitoring Mobility Service Usage.................................................................................. 38

Monitoring IIS Request Tracing Log Files......................................................................... 38

Configuring Mobility Service for High Performance.......................................................... 38

Mobility Performance Counters....................................................................................... 39

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

Note:

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.

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.

Note:

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

Note:

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:

In some configurations, the Mobility Service is not supported on dual-homed Front End Servers that are collocated with a Mediation Server. Specifically, you cannot use this topology with Mobility Service if you define a Primary IP address and a public switched telephone network (PSTN) IP address in Topology Builder and register only the Primary IP address in Domain Name System (DNS).

・ 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 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

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.

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

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>

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>

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

・ 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, 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 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.

Note:

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.

・ Capacity Planning for Mobility

Determining the amount of capacity that you need for mobility is an iterative process of estimating your mobility usage, measuring your current capacity, planning for additional capacity, and monitoring key indicators for performance. The following figure illustrates the phases involved in capacity planning and the factors involved in each phase.

Mobility Capacity Planning Workflow

This section describes the factors you need to consider as you estimate your mobility usage and provides guidelines for determining the sizing you need to deploy mobility.

For details about monitoring usage and performance indicators, see the following:

・ For details about monitoring server memory, see Monitoring for Server Memory Capacity Limits.

・ For details about monitoring mobility usage, see Monitoring Mobility Service Usage.

・ For details about monitoring IIS tracing log files, see Monitoring IIS Request Tracing Log Files.

・ For details about performance counters you can use to monitor mobility, see Mobility Performance Counters.

For details about configuring Mobility Service for high performance, see Configuring Mobility Service for High Performance.

・ Factors Influencing Capacity

Three factors influence your capacity planning for Front End Servers running the Microsoft Lync Server 2010 Mobility Service:

・ User model

・ Mobile device characteristics

・ Available RAM

・ User Model

The user model described in this section provides the basis for the capacity planning measurements and recommendations for mobility.

Average Number of Contacts per User

Category of contacts	Average number per user
All contacts	80
Enterprise contacts	64
Federated contacts	8
PIC contacts	6
Distribution groups	2
Most frequently used contacts	15
Most recently used contacts	10

Daily Activity per User

Daily activity	Number during working hours	Number outside working hours
Sign-ins to mobile application	10	2
Phone calls (number)	10	2
Phone calls (duration)	2 minutes per call	2 minutes per call
Conferences	1 per week	0
Participants per conference	<10	0
Status note changes	1	0
Views of contact card	6	1
Views of Contacts list	9	1
Scrolls through Contacts list	3	0
Global address list (GAL) searches	5*	-
Manual presence updates	0.5	0
Total presence updates per contact	6	0
Call forwarding	0.5	0
Instant messaging (IM) sessions (number)	3	1
IM sessions (duration)	6 minutes per session; 1 message per 30 seconds	6 minutes per session; 1 message per 30 seconds
Calendar lookups (connections to Exchange Web Services)	11	3

* Number of GAL searches = 1 manual search per day + automatic searches on half of outgoing instant messages and calls. That is, 1 + 2 (instant messages) + 2 (calls) =5.

・ Mobile Device Characteristics

The mobile devices supported for mobility run a variety of operating systems. The way in which an operating system manages applications when a user switches to a different application influences capacity planning. Operating systems can be divided into the following two categories for capacity planning:

・ Background enabled   When a user switches to a different mobile application on Apple and Windows Phone mobile devices, the Lync 2010 mobile application goes to the background and loses the connection to Lync Server 2010. The mobile application is reactivated by a push notification or when the user manually brings the application to the foreground.

・ Always connected   When a user switches to a different mobile application on Android and Nokia mobile devices, the Lync 2010 mobile application maintains the connection to Lync Server 2010 as long as the user stays signed in.

Android and Nokia mobile devices create a bigger load on servers because they maintain the connection to the server even when the user is not actively using the mobile application.

・ Available Memory

The sizing guidelines described later in this section will help you define the amount of memory you need for mobility. To determine the amount of physical memory that is available on your servers, use the Memory, Available Mbytes performance counter. This performance counter indicates the amount of physical memory in megabytes that is available for running processes. If the amount of memory available for running processes is less than five percent (5%) of the total physical memory, the server has insufficient memory, which can increase paging.

・ Sizing Guidelines

The Mobility Service uses additional memory, processor resources, and network resources on Front End Servers. When you plan for capacity, you need to understand the impact of the mobility load on the Front End pool and decide whether you need additional hardware for the mobility load. Use the sizing examples in the table that follows to help determine whether, and how much, additional hardware you need.

The examples in the table are based on some formulas and assumptions. The formulas and assumptions use the following definitions:

・ AC stands for the number of mobile applications that are always connected in the user model.

・ BE stands for the number of mobile applications that are enabled for the background in the user model.

The formulas and assumptions are as follows:

・ Target memory (TM) in Mbytes = 164 + (AC * 534 + BE * 400) / 1024.

TM is the minimum required memory.

・ With the user model described previously, the number of connections to the Front End pool is AC * 2 + BE * .20.

・ Measured memory may be higher (up to 1 MB per endpoint) when there is no memory pressure on the server. Target memory can be higher if your user model is more aggressive, such as when there are more audio/video (A/V) calls or contacts, and so forth.

・ The number of connections created per second is less than or equal to 30/second per 1,000 users. This number depends on connection pooling settings on the hardware load balancer and on keep-alive settings.

The following table shows examples of sizing for 50% always-connected users in the user model.

Sizing Examples

Number of users	Memory (MB)	Average CPU	Maximum CPU
1,000	620.05	1%	2.5%
2,000	1076.11	6%	8%
3,000	1532.16	14%	18%
4,000	1988.22	14%	18%
5,000	2444.27	14%	18%

・ Scenario Examples

The following examples show how the sizing guidelines apply to a fictional large enterprise and a Front End pool that includes two servers.

Large enterprise

Contoso has deployed 75,000 users across three pools with four Front End Servers in each pool. Contoso plans to enable mobility services to 30,000 users.

During the planning phase, Contoso administrators capture the following data:

・ Each Front End Server has 3 GB of available memory.

・ CPU utilization is less than 60%.

・ All users have either an iPhone or a Windows Phone mobile device.

・ The user model for Contoso is similar to the capacity planning user model described earlier in this section.

The minimum required memory for each server is 164 + 2500 * 400 / 1024 = 1133 MB. When there is memory available, more memory may be allocated to the mobile applications because memory is freed up as needed, up to 2.7 GB. In either situation, Contoso does not need to upgrade the Front End Server hardware.

Note:

The goal for mobility CPU utilization is an average of 10%. Contoso needs to monitor the CPU processor time as it gets close to the server limit of 70%.

Front End pool with two servers

Contoso has deployed 8,000 users in a Front End pool with two servers. Contoso plans to enable mobility services to all users.

During the planning phase, Contoso administrators capture the following data:

・ Each Front End Server has 2.5 GB of available memory.

・ CPU utilization is less than 60%.

・ All users have either a Nokia or an Android mobile device.

・ The user model for Contoso is similar to the capacity planning user model described earlier in this section.

The minimum required memory for each server is 164 + 4000 * 534 / 1024 = 2242 MB. In theory a server could support the load. However, a server will not support the load if a failover occurs between the two servers. Additionally, the mobility CPU utilization will be above 10% and the server 70% CPU limit will be reached.

In this scenario, the recommendation is to add a server to the pool. The new load distribution is 2667 (that is, 8000/3) users per Front End Server. The additional mobility cost is 2667 * 534 / 1024 = 1390 MB.

With the addition of a server, in the event of a server failure, each of the three servers in the pool will accept 1,300 more users and the increase in load will be 600 MB. With the new load distribution, the CPU utilization will also remain below the 70% server limit.

・ 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
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: ・ Director certificate ・ Front End pool certificate ・ Reverse proxy certificate	Local administrator	Modifying Certificates for Mobility
Configure the reverse proxy	・ Assign certificates updated with subject alternative names to the Secure Sockets Layer (SSL) Listener. ・ 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 End pool. Or ・ 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.	Local administrator	Configuring the Reverse Proxy for Mobility
Test your mobility deployment	Run Test-CsMcsP2PIM 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. ・ 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 for TCP port 5223. ・ Use the Set-CsPushNotificationConfiguration 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.	RtcUniversalServerAdmins	Configuring for Push Notifications
Configure mobility policy	Use the Set-CsMobilityPolicy cmdlet to allow or disallow user access to mobility features and to enable or disable Call via Work. These features are enabled by default.	CsAdministrator	Configuring 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.

To create DNS CNAME 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). Note: 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). Note: 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 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.[A1] Note: 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). Note: 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). Note: 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. Note: 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). Note: 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. 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. Note: 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) �Cd 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 �CUpdate �CConfiguredDatabases �CSqlServerFqdn <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 �CUpdate �CConfiguredDatabases �CSqlServerFqdn iws-db.iwstech.com -ExcludeCollocatedStores ・ For Standard Edition, type the following: Install-CsDatabase �CUpdate -LocalDatabases 13. Restart the Lync Server services. At the command line, type: Start-CsWindowsService

・ 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 �CIdentity <name of pool> �CMcxSipPrimaryListeningPort 5086 For example: Set-CsWebServer �CIdentity pool01.contoso.com �CMcxSipPrimaryListeningPort 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 �CIdentity <name of pool> �CMcxSipExternalListeningPort 5087 For example: Set-CsWebServer �CIdentity pool01.contoso.com �C McxSipExternalListeningPort 5087 Where pool01.contoso.com is the pool where the Mobility Service will be installed Note: 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.

Important:

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.

You need to run the 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.

Note:

When you restrict mobility traffic to the internal network, you must configure the internal Web Services virtual IPs (VIPs) for cookie-based persistence on your hardware load balancer. For details, see Load Balancing Requirements.

If you use Internet Information Services (IIS) 7.0, you need to perform extra steps to change some ASP.NET settings. If you use IIS 7.5, the installer automatically changes these settings for you.

The Mobility Service installation 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 running McxStandalone.msi.

Note:

The Dynamic Content Compression module is not required for the Autodiscover Service. You do not need to install this module on Directors where only the Autodiscover Service is installed.

To install IIS module

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 �CInstall Web-Dyn-Compression

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. 3. Search for the following: <Add name="CSExtMcxAppPool" 4. At the end of the line, before the ending angle bracket (>), type the following: CLRConfigFile="C:\Program Files\Microsoft Lync Server 2010\Web Components\Mcx\Ext\Aspnet_mcx.config" 5. Search for the following: <Add name="CSIntMcxAppPool" 6. At the end of the line, before the ending angle bracket (>), type the following: CLRConfigFile="C:\Program Files\Microsoft Lync Server 2010\Web Components\Mcx\Int\Aspnet_mcx.config"

To install Mobility Service and Autodiscover Service

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. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell. 5. Run C:\Program Files\Microsoft Lync Server 2010\Deployment\Bootstrapper.exe. 6. If you want to restrict mobility services to the internal corporate network, at the command line, type the following: Set-CsMcxConfiguration �CExposedWebUrl Internal

[A2]

・ Modifying Certificates for Mobility

The certificates for your cumulative update for Lync Server 2010: November 2011 Director pool, Front End pool, and reverse proxy require additional subject alternative name entries to support secure connections with mobile clients. For details about certificate requirements for mobility, see Technical Requirements for Mobility.

Update the certificates after you install the new Microsoft Lync Server 2010 Mobility Service or after you run the Set-CsWebServer cmdlet to set ports for the Mobility Service.

The Set-CsCertificate cmdlet validates subject alternative names and returns a warning if a subject alternative name for the internal Microsoft Lync Server 2010 Autodiscover Service fully qualified domain name (FQDN) or external Autodiscover Service FQDN is missing. If the cmdlet finds a missing subject alternative name, you need to run the Request-CsCertificate cmdlet. To run this cmdlet locally, you must be a local administrator and have rights to the specified certification authority.

Important:

One exception is when the external Domain Name System (DNS) record is an A (host) record. If the external DNS record is an A (host) record and you run the Set-CsCertificate cmdlet on a Director, the cmdlet does not return a warning about a missing subject alternative name for the external Autodiscover Service (lyncdiscover.<sipdomain>).

To update certificates with new subject alternative names

1. Log on to the computer using an account that has local administrator rights and permissions. 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. Find out what certificates have been assigned to the server and for which type of use. You need this information in the next step to assign the updated certificate. At the command line, type: Get-CsCertificate 4. Look in the output from the previous step to see whether a single certificate is assigned for multiple uses or whether a different certificate is assigned for each use. Look in the Use parameter to find out how a certificate is used. Compare the Thumbprint parameter for the displayed certificates to see if the same certificate has multiple uses. 5. Update the certificate. At the command line, type: Set-CsCertificate �CType <type of certificate as displayed in the Use parameter> -Thumbprint <unique identifier> For example, if the Get-CsCertificate cmdlet displayed a certificate with Use of Default, another with a Use of WebServicesInternal, and another with a Use of WebServicesExternal, and they all had the same Thumbprint value, at the command line, type: Set-CsCertificate �CType Default,WebServicesInternal,WebServicesExternal �CThumbprint <Certificate Thumbprint> Important: If a separate certificate is assigned for each use (the Thumbprint value is different for each certificate), it is important that you do not run the Set-CsCertificate cmdlet with multiple types. In this case, run the Set-CsCertificate cmdlet separately for each use. For example: Set-CsCertificate �CType Default �CThumbprint <Certificate Thumbprint> Set-CsCertificate �CType WebServicesInternal �CThumbprint <Certificate Thumbprint> Set-CsCertificate �CType WebServicesExternal �CThumbprint <Certificate Thumbprint> 6. If an Autodiscover Service subject alternative name is missing, do the following: ・ For a missing internal Autodiscover subject alternative name, at the command line, type: Request-CsCertificate �CNew �CType WebServicesInternal �CCa dc\myca �CAllSipDomain �Cverbose If you have many SIP domains, you cannot use the new AllSipDomain parameter. Instead, you must use DomainName parameter. When you use the DomainName parameter, you must use an appropriate prefix for the SIP domain FQDN. For example: Request-CsCertificate �CNew �CType WebServicesInternal �CCa dc\myca �CDomainName “LyncdiscoverInternal.contoso.com, LyncdiscoverInternal.contoso.net” -verbose ・ For a missing external Autodiscover subject alternative name, at the command line, type: Request-CsCertificate �CNew �CType WebServicesExternal �CCa dc\myca �CAllSipDomain �Cverbose If you have many SIP domains, you cannot use the new AllSipDomain parameter. Instead, you must use DomainName parameter. When you use the DomainName parameter, you must use an appropriate prefix for the SIP domain FQDN. For example: Request-CsCertificate �CNew �CType WebServicesExternal �CCa dc\myca �CDomainName “Lyncdiscover.contoso.com, Lyncdiscover.contoso.net” -verbose

・ Configuring the Reverse Proxy for Mobility

If you want to use automatic discovery for mobile device clients, you need to create a new web publishing rule for the reverse proxy whether or not you update the subject alternative name lists on the reverse proxy certificates.

If you decide to use HTTPS for initial Microsoft Lync Server 2010 Autodiscover Service requests and update the subject alternative names lists on the reverse proxy certificates, you need to assign the updated public certificate to the Secure Sockets Layer (SSL) Listener on your reverse proxy. For details about the required subject alternative name entries, see Technical Requirements for Mobility. Then you need to create a new web publishing rule for the external Autodiscover Service URL. If you do not already have a web publishing rule for the external Lync Server Web Services URL for your Front End pool, you also need to publish a rule for that.

If you decide to use HTTP for initial Autodiscover Service requests so that you do not need to update subject alternative names for the reverse proxy, you need to create a new web publishing rule for port 80.

The procedures in this section describe how to create the new web publishing rules in Microsoft Forefront Threat Management Gateway 2010 for automatic discovery.

Note:

These procedures assume that you have installed the Standard Edition of Forefront Threat Management Gateway (TMG) 2010.

To create a web publishing rule for the external Autodiscover URL

1. Click Start, point to Programs, point to Microsoft Forefront TMG, and then click Forefront TMG Management. 2. In the left pane, expand ServerName, right-click Firewall Policy, point to New, and then click Web Site Publishing Rule. 3. On the Welcome to the New Web Publishing Rule page, type a display name for the new publishing rule (for example, LyncDiscoveryURL). 4. On the Select Rule Action page, select Allow. 5. On the Publishing Type page, select Publish a single Web site or load balancer. 6. On the Server Connection Security page, select Use SSL to connect to the published Web server or server farm. 7. On the Internal Publishing Details page, in Internal Site name, type the fully qualified domain name (FQDN) of your Director pool (for example, lyncdir01.contoso.local). If you are creating a rule for the external Web Services URL on the Front End pool, type the FQDN of the Front End pool (for example, lyncpool01.contoso.local). 8. On the Internal Publishing Details page, in Path (optional), type /* as the path of the folder to be published, and then select Forward the original host header. 9. On the Public Name Details page, do the following: ・ Under Accept Requests for, select This domain name. ・ In Public Name, type lyncdiscover.<sipdomain> (the external Autodiscover Service URL. If you are creating a rule for the external Web Services URL on the Front End pool, type the FQDN for the external Web Services on your Front End pool (for example, lyncwebextpool01.contoso.com). ・ In Path, type /*. 10. On Select Web Listener page, in Web Listener, select your existing SSL Listener with the updated public certificate. 11. On the Authentication Delegation page, select No delegation, but client may authenticate directly. 12. On the User Set page, select All Users. 13. On the Completing the New Web Publishing Rule Wizard page, verify that the web publishing rule settings are correct, and then click Finish. 14. In the Forefront TMG list of web publishing rules, double-click the new rule you just added to open Properties. 15. On the To tab, do the following: ・ Select Forward the original host header instead of the actual one. ・ If your deployment has a Front End pool, select Requests appear to come from the original client. If your deployment has a single Front End Server or Standard Edition server, select Requests appear to come from the Forefront TMG computer. 16. On the Bridging tab, configure the following: ・ Select Web server. ・ Select Redirect requests to HTTP port, and type 8080 for the port number. ・ Select Redirect requests to SSL port, and type 4443 for the port number. 17. Click OK. 18. Click Apply in the details pane to save the changes and update the configuration. 19. Click Test Rule to verify that your new rule is set up correctly.

To create a web publishing rule for port 80

1. Click Start, point to Programs, point to Microsoft Forefront TMG, and then click Forefront TMG Management. 2. In the left pane, expand ServerName, right-click Firewall Policy, point to New, and then click Web Site Publishing Rule. 3. On the Welcome to the New Web Publishing Rule page, type a display name for the new publishing rule (for example, Lync Autodiscover (HTTP)). 4. On the Select Rule Action page, select Allow. 5. On the Publishing Type page, select Publish a single Web site or load balancer. 6. On the Server Connection Security page, select Use non-secured connections to connect to the published Web server or server farm. 7. On the Internal Publishing Details page, in Internal Site name, type the internal Web Services FQDN for your Front End pool (for example, lyncpool01.contoso.local). 8. On the Internal Publishing Details page, in Path (optional), type /* as the path of the folder to be published, and then select Forward the original host header instead of the one specified in the Internal site name field. 9. On the Public Name Details page, do the following: ・ Under Accept Requests for, select This domain name. ・ In Public Name, type lyncdiscover.<sipdomain> (the external Autodiscover Service URL). ・ In Path, type /*. 10. On Select Web Listener page, in Web Listener, select a Web Listener or use the New Web Listener Definition Wizard to create a new one. 11. On the Authentication Delegation page, select No delegation, and client cannot authenticate directly. 12. On the User Set page, select All Users. 13. On the Completing the New Web Publishing Rule Wizard page, verify that the web publishing rule settings are correct, and then click Finish. 14. In the Forefront TMG list of web publishing rules, double-click the new rule you just added to open Properties. 15. On the Bridging tab, configure the following: ・ Select Web server. ・ Select Redirect requests to HTTP port, and type 8080 for the port number. ・ Verify that Redirect requests to SSL port is not selected. 16. Click OK. 17. Click Apply in the details pane to save the changes and update the configuration. 18. Click Test Rule to verify that your new rule is set up correctly. 19. Verify that the external Autodiscover Service URL is not defined on any other web publishing rule.

・ Verifying Your Mobility Deployment

After you deploy the Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service, run a test transaction to verify that your deployment works correctly. You can run Test-CsMcxP2PIM to test sending an instant message between two users. To use this test transaction, you need two actual or test users and their full credentials.

To test person-to-person instant messaging (IM)

1. Log on as a member of the CsAdministrator role on any computer where Lync Server Management Shell and Ocscore are installed. 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. At the command line, type: Test-CsMcxP2PIM -TargetFqdn <FQDN of Front End pool> -SenderSipAddress sip:<SIP address of test user 1> -SenderCredential <test user 1 credentials> -ReceiverSipAddress sip:<SIP address of test user 2> -ReceiverCredential <test user 2 credentials> �Cv You can set credentials in a script and pass them to the test cmdlet. For example: $passwd1 = ConvertTo-SecureString "Password01" -AsPlainText -Force $passwd2 = ConvertTo-SecureString "Password02" -AsPlainText -Force $tuc1 = New-Object Management.Automation.PSCredential("contoso\UserName1", $passwd1) $tuc2 = New-Object Management.Automation.PSCredential("contoso\UserName2", $passwd2) Test-CsMcxP2PIM -TargetFqdn pool01.contoso.com -SenderSipAddress sip:[email protected] -SenderCredential $tuc1 -ReceiverSipAddress sip:[email protected] -ReceiverCredential $tuc2 �Cv

・ Configuring for Push Notifications

Push notifications, in the form of badges, icons, or alerts, can be sent to a mobile device even when the mobile application is inactive. Push notifications notify a user of events such as a new or missed IM invitation, missed calls, and voice mail. The Microsoft Lync Server 2010 Mobility Service sends the notifications to the cloud-based Microsoft Lync Server 2010 Push Notification Service, which then sends the notifications to the Apple Push Notification Service (APNS) or the Microsoft Push Notification Service (MPNS).

Configure your topology to support push notifications by doing the following:

・ If your environment has a Lync Server 2010 Edge Server, you need to add a new hosting provider, Microsoft Lync Online, and then set up hosting provider federation between your organization and Lync Online.

・ If your environment has a Office Communications Server 2007 R2 Edge Server, you need to set up direct SIP federation with push.lync.com.

Note:

Push.lync.com is a Microsoft Office 365 domain for the Lync Server 2010 Push Notification Service.

・ To enable push notifications, you need to run the Set-CsPushNotificationConfiguration cmdlet. By default, push notifications are turned off.

・ Test the federation configuration and push notifications.

To configure for push notifications with Lync Server 2010 Edge Server

1. Log on to a computer where Lync Server Management Shell and Ocscore are installed as 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. Add a Lync Server online hosting provider. At the command line, type: New-CsHostingProvider �CIdentity <unique identifier for Lync Online hosting provider> �CEnabled $True �CProxyFqdn <FQDN for the Access Server used by the hosting provider> �CVerificationLevel UseSourceVerification For example: New-CsHostingProvider �CIdentity "LyncOnline" �CEnabled $True �CProxyFqdn "sipfed.online.lync.com" �CVerificationLevel UseSourceVerification Note: You cannot have more than one federation relationship with a single hosting provider. That is, if you have already set up a hosting provider that has a federation relationship with sipfed.online.lync.com, do not add another hosting provider for it, even if the identity of the hosting provider is something other than LyncOnline. 4. Set up hosting provider federation between your organization and the Push Notification Service at Lync Online. At the command line, type: New-CsAllowedDomain �CIdentity "push.lync.com"

To configure for push notifications with Office Communications Server 2007 R2 Edge Server

1. Log on to the Edge Server as a member of the RtcUniversalServerAdmins group. 2. Click Start, click All Programs, click Administrative Tools, and then click Computer Management. 3. In the console tree, expand Services and Applications, right-click Microsoft Office Communications Server 2007 R2, and then click Properties. 4. On the Allow tab, click Add. 5. In the Add Federated Partner dialog box, do the following: ・ In Federated partner domain name, type push.lync.com. ・ In Federated partner Access Edge Server, type sipfed.online.lync.com. ・ Click OK.

To enable push notifications

1. Log on to a computer where Lync Server Management Shell and Ocscore are installed as a member of the CsAdministrator role. 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. Enable push notifications. At the command line, type: Set-CsPushNotificationConfiguration �CEnableApplePushNotificationService $True �CEnableMicrosoftPushNotificationService $True 4. Enable federation. At the command line, type: Set-AccessEdgeConfiguration -AllowFederatedUsers $True

To test federation and push notifications

1. Log on to a computer where Lync Server Management Shell and Ocscore are installed as a member of the CsAdministrator role. 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. Test the federation configuration. At the command line, type: Test-CsFederatedPartner �CTargetFqdn <FQDN of Access Edge server used for federated SIP traffic> -Domain <FQDN of federated domain> -ProxyFqdn <FQDN of the Access Edge server used by the federated organization> For example: Test-CsFederatedPartner �CTargetFqdn accessprox.contoso.com �CDomain push.lync.com �CProxyFqdn sipfed.online.lync.com 4. Test push notifications. At the command line, type: Test-CsMcxPushNotification �CAccessEdgeFqdn <Access Edge service FQDN> For example: Test-CsMcxPushNotification �CAccessEdgeFqdn Accessproxy.contoso.com

・ Configuring Mobility Policy

Cumulative update for Lync Server 2010: November 2011 introduces a new mobility policy that determines who can use mobility features and who can use the Call via Work feature. Call via Work allows a mobile user to make and receive calls on a mobile phone by using a work phone number instead of the mobile phone number. This feature prevents the called party from seeing the caller's mobile phone number and allows a user to avoid outbound calling charges.

By default, both mobility and Call via Work features are enabled. Administrators can determine who has access to these features by running a cmdlet. You can turn options off globally, by site, or by user.

To be able to use mobility features and Call via Work, users must meet the following two prerequisites:

・ Users must be enabled for Lync Server 2010.

・ Users must be enabled for Enterprise Voice.

For users to be able to use Call via Work, they must meet the following two additional prerequisites:

・ Users must be assigned a voice policy that has the Enable simultaneous ringing of phones option selected.

・ Users must be assigned a mobility policy that has the EnableMobility option set to True.

Note:

Users who are not enabled for Enterprise Voice can use their mobile devices to join conferences by using the Click to Join link on their mobile devices, if you assign those users a voice policy. For details, see Defining Your Mobility Requirements.

For details about enabling users for Lync Server 2010, see Enable or Disable Users for Lync Server 2010. For details about enabling users for Enterprise Voice, see Enable Users for Enterprise Voice. For details about setting voice policy options, see Modify a Voice Policy and Configure PSTN Usage Records.

To modify global mobility policy

1. Log on to any computer where Lync Server Management Shell and Ocscore are installed as a member of the CsAdministrator role. 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. Turn off access to mobility and Call via Work globally. At the command line, type: Set-CsMobilityPolicy �CEnableMobility $False �CEnableOutsideVoice $False Note: You can turn off Call via Work without turning off access to mobility. However, you cannot turn off mobility without also turning off Call via Work.

To modify mobility policy by site

1. Log on to any computer where Lync Server Management Shell and Ocscore are installed as a member of the CsAdministrator role. 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. Create a site level policy, and turn off access to mobility and Call via Work by site. At the command line, type: New-CsMobilityPolicy �CIdentity site:<site identifier> �CEnableMobility $False -EnableOutsideVoice $False Note: You can turn off Call via Work without turning off access to mobility. However, you cannot turn off mobility without also turning off Call via Work.

To modify mobility policy by user

1. Log on to any computer where Lync Server Management Shell and Ocscore are installed as a member of the CsAdministrator role. 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. Create user level mobility policies and turn off mobility and Call via Work by user. At the command line, type: New-CsMobilityPolicy �CIdentity <policy name> -EnableMobility $False -EnableOutsideVoice $False Grant-CsMobilityPolicy �CIdentity <user identifier> -PolicyName <policy name> You can turn off Call via Work without turning off access to mobility. However, you cannot turn off mobility without also turning off Call via Work. For example: New-CsMobilityPolicy "tag:disableOutsideVoice" �CEnableOutsideVoice $False Grant-CsMobilityPolicy �CIdentity �[email protected] �CPolicyName Tag:disableOutsideVoice

・ Monitoring Mobility for Performance

The Microsoft Lync Server 2010 Mobility Service increases the load on Front End Servers and Front End pools. Mobile devices that maintain a connection to the server even when the mobile application is minimized, such as Android and Nokia devices, impose a greater load than devices that terminate their connection to the server when the mobile application is minimized. As your mobility usage increases, you need to monitor mobility performance to determine when you need to increase your capacity.

Several limits influence mobility performance:

・ Available memory

・ Request queue limit

・ Concurrent connections

・ IIS queue length

Other limits on servers that can influence mobility performance are a maximum of twelve concurrent sign-ins, authentications, and session renewals and terminations. These maximums do not need to be modified for most deployments.

・ In This Section

・ Monitoring for Server Memory Capacity Limits

・ Monitoring Mobility Service Usage

・ Configuring Mobility Service for High Performance

・ Monitoring IIS Request Tracing Log Files

・ Mobility Performance Counters

・ Monitoring for Server Memory Capacity Limits

Two mobility performance counters can help you determine your current usage and help you plan capacity for the Microsoft Lync Server 2010 Mobility Service. The two primary Front End Server counters, under the category LS MCX �C 00 �C Mobile Communication Service, are:

・ Currently Active Session Count with Active Presence Subscriptions, which is the current number of endpoints registered through the Mobility Service that have active presence subscriptions (number of always-connected mobile users)

・ Currently Active Session Count, which is the current number of endpoints registered through the Mobility Service

If the difference between Currently Active Session Count with Active Presence Subscriptions and Currently Active Session Count is small over time, it means that most mobile device users have an always-connected device, such as an Android or Nokia mobile device. If Currently Active Session Count is much higher than Currently Active Session Count with Active Presence Subscriptions, it shows that more users are using a background endpoint device, such as an Apple iOS device or Windows Phone.

You should set a limit on the Currently Active Session Count with Active Presence Subscriptions and Currently Active Session Count performance counters based on your expected usage, capacity planning results, and ongoing monitoring of Mobility Service and other Front End Server counters. The limits you set should allow you to evaluate server capacity and raise alerts when capacity is exceeded.

To determine the appropriate limits, you need to first determine how much memory is available on the Front End Server for the Mobility Service. Monitor the counters to determine when you need to plan for extra capacity according to the following formula:

Total memory used by Mobility Service (MB) = 164 + (400 + 134) / 1024 * Currently Active Session Count with Active Presence Subscriptions + 400 / 1024 * (Currently Active Session Count �C Currently Active Session Count with Active Presence Subscriptions)

The Front End Server needs enough available memory to support the Mobility Service in failover situations. You can monitor the current available memory on the Front End Server by using the Memory\Available Mbytes counter, or use the equation mentioned previously to plan for the amount of memory that you expect the Mobility Service to use.

If the amount of memory available on the Front End Server is lower than 1,500 MB when you plan for the expected number of mobility users, you need to add more hardware to support the Mobility Service. For more details, see "Scenario Examples" in Capacity Planning for Mobility.

・ Monitoring Mobility Service Usage

On an ongoing basis, you should monitor the CPU and memory that is used by the Microsoft Lync Server 2010 Mobility Service. To monitor usage, you can use either of the following:

・ The CSIntMcxAppPool and CSExtMcxAppPool worker processes in Internet Information Services (IIS) Manager. In the Worker Processes pane, look at the CPU % and Private Bytes (KB) (memory) columns.

・ The CPU and Processor performance counters.

For most deployments, Mobility Service CPU usage should be below 15% on average. Memory usage should fall within the limits described in Monitoring for Server Memory Capacity Limits.

In addition to CPU and memory usage counters, you can use the following ASP.NET performance counters to help determine when a server is overloaded with requests:

・ ASP.NET v2.0.50727\Requests Current, which indicates the number of pending web requests on the server. When this counter reaches 5,000, subsequent requests will fail with error "503 - Service Unavailable".

・ ASP.NET\Requests Queued (should always be zero)

・ Monitoring IIS Request Tracing Log Files

When you enable Internet Information Services (IIS) request tracing for Microsoft Lync Server 2010 Mobility Service, the log files that are generated can consume up to three gigabytes of disk space per day. IIS trace logging is enabled by default. You should monitor the Front End Servers to make sure that they do not run out of disk space.

By default, IIS stores the log files at %SystemDrive%\inetpub\logs\LogFiles.

To turn off IIS request tracing for an entire server, at the command line, type the following:

%SystemDrive%\Windows\System32\inetsrv\appcmd set config /section:httpLogging /dontLog:True

For details about the httpLogging command, see http://go.microsoft.com/fwlink/?LinkId=234927.

・ Configuring Mobility Service for High Performance

When you install Microsoft Lync Server 2010 Mobility Service on Internet Information Services (IIS) 7.5, the Mobility Service installer configures some performance settings on the Front End Server. We recommend that you use IIS 7.5 for mobility. If you use IIS 7.0 on Windows Server 2008, you need to configure these settings manually. The settings affect the maximum number of concurrent user requests and the maximum number of threads that are allowed for the Mobility Service.

The performance settings are the following:

・ maxConcurrentThreadsPerCPU is set to zero (0).

・ maxConcurrentRequestsPerCPU is set to zero (0).

・ ASP.NET process model is set to AutoConfig (for IIS 7.5 only).

・ HTTP.sys queue limit is set to 1,000 (by default).

If you use IIS 7.0, we recommend that you install the update 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 so that you can apply the changes only for the Mobility Service and not affect other web services.

The following procedure describes how to change the ASP.NET concurrent request and thread maximums on IIS 7.0 if you do not install the update available from Knowledge Base article 2290617. However, even if you do install Knowledge Base article 2290617, you should use the documentation provided by the article to apply the same changes only for the Mobility internal and external IIS application pools. In this case, you use a separate configuration file for the ASP.NET settings.

Important:

If you use the following procedure to change the maximums, the changes affect all IIS application pools.

For details about configuring these settings, see http://go.microsoft.com/fwlink/?LinkId=234537.

To change concurrent request and thread maximums

1. Click Start, and then click Run. 2. In the Run box, type the following: notepad %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\Aspnet.config 3. Click OK. 4. Add or replace the following <system.web> element as a child of the <configuration> element in the Aspnet.config file: <system.web> <applicationPool maxConcurrentRequestsPerCPU="&lt;#>" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/&gt; </system.web> where # is 0 to remove the limit or the new number as described earlier in this section 5. Save the Aspnet.config file and close Notepad.

・ Mobility Performance Counters

The following table lists the names and descriptions of performance counters that you can use to monitor servers running the Microsoft Lync Server 2010 Mobility Service. The category name for the counters in the following table is LS:Mcx - 00 - Mobile Communication Service.

Mobility Performance Counters

Counter	Description
Average Lifetime for a Session in Milliseconds	The average lifetime for a session in milliseconds
Current Push Notification Subscriptions	The current number of push notification subscriptions. This number in conjunction with Currently Active Session Count represents the subset of currently active sessions that are registered for Windows Mobile or iPhone devices.
Currently Active Network Timeout Poll Count	The number of network polls that timed out
Currently Active Poll Count	The number of currently active polls (long-held connections to the server)
Currently Active Session Count	Current number of endpoints registered in the Mobility Service
Currently Active Session Count with Active Presence Subscriptions	The number of currently active sessions with active presence subscriptions
Push Notification Requests Failed/Second	The per second rate of failed push notifications
Push Notification Requests Succeeded/Second	The per second rate of successful push notifications
Push Notification Requests Throttled/Second	The per second rate of throttled push notifications
Push Notification Requests/Second	The per second rate of sent push notifications
Requests Failed/Second	The per second rate of failed requests
Requests Received/Second	The per second rate of received requests
Requests Rejected/Second	The per second rate of rejected requests
Requests Succeeded/Second	The per second rate of successful requests
Succeeded Initiate Session Requests/Second	The per second rate of successful Get Location requests. Requests to initiate a session consume the most CPU on the server. Peak supported load is 12/second. Sustainability depends on other loads on the server. Initiate a session typically means a sign-in for a user that has been signed out for an extended period of time.
Total Declined Inbound Voice Calls	The total number of inbound voice calls that were declined
Total Failed Inbound Voice Calls	The total number of inbound voice calls that failed
Total Failed Outbound Voice Calls	The total number of outbound voice calls that failed
Total number of sessions terminated by user	The total number of sessions terminated by users
Total Push Notification Requests	The total number of push notification requests
Total Push Notification Requests Failed	The total number of push notification requests that failed
Total Push Notification Requests Succeeded	The total number of push notification requests that were successful
Total Push Notification Requests Throttled	The total number of push notification requests that were throttled
Total Requests Failed	The total number of requests that failed
Total Requests received on the Command Channel	The total number of requests received on the command channel
Total Requests Rejected	The total number of requests that were rejected
Total Requests Succeeded	The total number of requests made to the Mobility Service that succeeded
Total Session Initiated Count	The total number of sessions that were initiated since the Mobility Service was started
Total Sessions Terminated Because of User Idle Timeout	The total number of sessions that were terminated because of user idle timeout
Total Successful Inbound Voice Calls	The total number of inbound voice calls that were successful
Total Successful Outbound Voice Calls	The total number of outbound voice calls that were successful

[A1]aaa

[A2]