planning, deploying, and monitoring mobility

Planning, Deploying, and Monitoring Mobility

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

Deployment Process for Mobility ............................................................................................ 12

Deploying Mobility ...................................................................................................................... 14

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

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

Setting Internal Server Ports for Mobility ................................................................................ 19

Installing the Mobility and Autodiscover Services ................................................................... 20

Install Dynamic Content Compression in IIS ....................................................................... 21

Install Hotfix for ASP.NET for IIS 7.0 ................................................................................... 22

Install Mobility Service and Autodiscover Service ............................................................... 22

Change ASP.NET Settings and Restart IIS for IIS 7.0 ........................................................ 23

Modifying Certificates for Mobility ........................................................................................... 24

Configuring the Reverse Proxy for Mobility ............................................................................ 26

Verifying Your Mobility Deployment ........................................................................................ 29

Configuring for Push Notifications .......................................................................................... 30

Configuring Mobility Policy ...................................................................................................... 32

Monitoring Mobility for Performance .......................................................................................... 34

Monitoring for Server Memory Capacity Limits ....................................................................... 35

Monitoring Mobility Service Usage ......................................................................................... 36

Monitoring IIS Request Tracing Log Files .............................................................................. 36

Configuring Mobility Service for High Performance ................................................................ 36

Mobility Performance Counters .............................................................................................. 38

1

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

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


2

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


3

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:

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.


4

When you use automatic discovery, mobile devices use Domain Name System (DNS) to locate

resources. During the DNS lookup, first a connection is attempted to the fully qualified domain

name (FQDN) that is associated with the internal DNS record (lyncdiscoverinternal.<sipdomain>).

If a connection cannot be made by using the internal DNS record, a connection is attempted by

using the external DNS record (lyncdiscover.<sipdomain>). A mobile device that is internal to the

network connects to the internal Autodiscover Service URL, and a mobile device that is external

to the network connects to the external Autodiscover Service URL. External requests go through

the reverse proxy. The Microsoft Lync Server 2010 Autodiscover Service returns all the Web

Services URLs for the user's home pool, including the Mobility Service URLs. However, both the

internal Mobility Service URL and the external Mobility Service URL are associated with the

external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or

external to the network, the device always connects to the Microsoft Lync Server 2010 Mobility

Service externally through the reverse proxy.

Note:

Although mobile applications can also connect to other Lync Server services, such as

Address Book Service, this requirement to send all mobile application web requests to

the same external web FQDN applies only to the Mobility Service. Other services do not

require this configuration.

The following diagram illustrates the flow of mobile application web requests for Mobility Service

and Autodiscover Service.

Flow of mobile application requests for Mobility Service and Autodiscover Service


5

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

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.


6

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


CNAME lyncdiscover.<sipdomain> External Web Services

FQDN for your Director

pool, if you have one, or for

your Front End pool if you


7


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

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

http://support.apple.com/kb/TS1629

http://developer.apple.com/library/ios/


8

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


Internal Autodiscover Service URL SAN=lyncdiscoverinternal.<sipdomain>


9



Note:

Alternatively, you can use SAN=*.<sipdomain>

Reverse Proxy (Public CA) Certificate Requirements



Note:

You assign this certificate to the SSL Listener on the reverse proxy.

Internet Information Services (IIS) Requirements

We recommend that you use IIS 7.5 for mobility. The Mobility Service installer sets some

ASP.NET flags to improve performance. IIS 7.5 is installed by default on Windows Server 2008

R2, and the Mobility Service installer automatically changes the ASP.NET settings. If you use IIS

7.0 on Windows Server 2008, you need to manually change these settings. For details, see

Installing the Mobility and Autodiscover Services.

Hardware Load Balancer Requirements

If your environment includes a Front End pool, the external Web Services virtual IPs (VIPs) on the

hardware load balancer used for Web Services traffic must be configured for cookie-based

persistence. Cookie-based persistence ensures that multiple connections from a single client are

sent to one server to maintain session state. The cookies must meet specific requirements. For

details about cookie requirements, see Load Balancing Requirements.

If you plan to support Lync mobile clients only over your internal Wi-Fi network, you should

configure the internal Web Services VIPS for cookie-based persistence as described for external

Web Services VIPs. In this situation, you should not use source_addr persistence for the internal

Web Services VIPs on the hardware load balancer. For details, see Load Balancing

Requirements.

Reverse Proxy Requirements

If you support automatic discovery for Lync mobile clients, you need to create a new web

publishing rule as follows:

If you decide to update the subject alternative names lists on the reverse proxy certificates

and use HTTPS for the initial Autodiscover Service request, you need to create a new web

publishing rule for lyncdiscover.<sipdomain>. You also need to ensure that a web publishing

rule exists for the external Web Services URL on the Front End pool.


10

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


11

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


12

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


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

Local administrator Modifying

Certificates for

Mobility


13


documentation

mobile users:

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.

Configure a new web

publishing rule for the external


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

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

RtcUniversalServerAdmins Configuring

for Push

Notifications


14


documentation

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

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


15

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


16

5. Verify that a host A record exists for your Front End pool as follows:


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


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


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.

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:


17

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


4. Verify that a host A record exists for your Director pool as follows:


Services FQDN for your Director pool (for example, lyncwebdir01.contoso.local).


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:


Services FQDN for your Front End pool (for example, lyncwebpool01.contoso.local).


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


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


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


18

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.



9. Stop Lync Server services again to catch Global Assembly Cache (GAC) –d assemblies.

At the command line, type:

http://go.microsoft.com/fwlink/?LinkID=208564


19

Stop-CsWindowsService

10. Restart the World Wide Web service. At the command line, type:

net start w3svc



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:

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.



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


20

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

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.

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.


21

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.

To install IIS Dynamic Content Compression

1. Log on to the computer as a user who is a member of the CsAdministrator group.



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.


22

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.

Note:

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.

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

http://go.microsoft.com/fwlink/?linkid=3052&kbid=2290617

http://go.microsoft.com/fwlink/?LinkID=230577


23

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.

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"

7. Save the applicationHost.config file.

8. Use command prompts to stop IIS and save the configuration changes in IIS. At the

command prompt, type the following:


24

Net stop iisadmin /y

Make note of each service that depends on the IISAdmin service so that you can restart

each one in the next step.

Note:

You can also use the Services snap-in to stop the services. We do not

recommend that you use IISReset to stop and restart IIS. If IISReset needs to

force stop services, your configuration changes may not be saved correctly. For

details, see Microsoft Knowledge Base article 286196, "IISReset May Not Save

IIS Configuration Changes" at

http://go.microsoft.com/fwlink/?linkid=3052&kbid=286196.

9. Restart the services. At the command line, type the following:

Net start w3svc

Net start <short name for each service that was listed when you

stopped IISAdmin>

Note:

The IISAdmin service starts automatically when the services dependent upon it

are restarted.

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



25

To update certificates with new subject alternative names

1. Log on to the computer using an account that has local administrator rights and

permissions.



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 –Type <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 –Type

Default,WebServicesInternal,WebServicesExternal –Thumbprint

<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 –Type Default –Thumbprint <Certificate

Thumbprint>

Set-CsCertificate –Type WebServicesInternal –Thumbprint


Set-CsCertificate –Type WebServicesExternal –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 –New –Type WebServicesInternal –Ca

dc\myca –AllSipDomain –verbose


26

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 –New –Type WebServicesInternal –Ca

dc\myca –DomainName “LyncdiscoverInternal.contoso.com,

LyncdiscoverInternal.contoso.net” -verbose

For a missing external Autodiscover subject alternative name, at the command line,

type:

Request-CsCertificate –New –Type WebServicesExternal –Ca

dc\myca –AllSipDomain –verbose

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 –New –Type WebServicesExternal –Ca

dc\myca –DomainName “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.


27

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.

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 SSL port, and type 4443 for the port number.


28

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.


29

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.



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> –v

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 –v


30

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.



3. Add a Lync Server online hosting provider. At the command line, type:

New-CsHostingProvider –Identity <unique identifier for Lync

Online hosting provider> –Enabled $True –ProxyFqdn <FQDN for the

Access Server used by the hosting provider> –VerificationLevel

UseSourceVerification

For example:

New-CsHostingProvider –Identity "LyncOnline" –Enabled $True –

ProxyFqdn "sipfed.online.lync.com" –VerificationLevel

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


31

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 –Identity "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


as a member of the CsAdministrator role.



3. Enable push notifications. At the command line, type:

Set-CsPushNotificationConfiguration –

EnableApplePushNotificationService $True –

EnableMicrosoftPushNotificationService $True

4. Enable federation. At the command line, type:

Set-CsAccessEdgeConfiguration -AllowFederatedUsers $True

To test federation and push notifications





3.

Note:

The Test-CsFederatedPartner synthetic transaction provides a means to test and


32

confirm that the configured federation is working in an expected manner. The

following examples show how to execute the Test-CsFederatedPartner for a

Lync Server 2010 Edge Server and an Office Communications Server 2007

R2 Edge Server.

Test the federation configuration for Lync Server 2010 Edge Server. At the command

line, type:

Test-CsFederatedPartner –TargetFqdn <internal interface FQDN of

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 –TargetFqdn internaledge.contoso.com –

Domain push.lync.com –ProxyFqdn sipfed.online.lync.com

4. Test the federation configuration for Office Communications Server 2007 R2 Edge

Server. At the command line, type:

Test-CsFederatedPartner –TargetFqdn <internal interface FQDN of

Edge server used for federated SIP traffic> -Domain <FQDN of

federated domain>

For example:

Test-CsFederatedPartner –TargetFqdn internaledge.contoso.com –

Domain push.lync.com

5. Test push notifications. At the command line, type:

Test-CsMcxPushNotification –AccessEdgeFqdn <Access Edge service

FQDN>

For example:

Test-CsMcxPushNotification –AccessEdgeFqdn

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.


33

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

prerequisites:

Users must be enabled for Lync Server 2010.

Users must be enabled for Enterprise Voice.

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

Note:

In Lync Server 2010, Remote User is not a requirement for users.

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




3. Turn off access to mobility and Call via Work globally. At the command line, type:

Set-CsMobilityPolicy –EnableMobility $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 site





34


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 –Identity site:<site identifier> –

EnableMobility $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





3. Create user level mobility policies and turn off mobility and Call via Work by user. At the

command line, type:

New-CsMobilityPolicy –Identity <policy name> -EnableMobility

$False -EnableOutsideVoice $False

Grant-CsMobilityPolicy –Identity <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" –

EnableOutsideVoice $False

Grant-CsMobilityPolicy –Identity –[email protected] –

PolicyName 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


35

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 – 00 – 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 – Currently Active Session Count with Active Presence Subscriptions)


36

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

http://go.microsoft.com/fwlink/?LinkId=234927


37

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="<#>"

maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>

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


http://go.microsoft.com/fwlink/?LinkId=234537


38


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.


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


39

Counter Description

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

planning, deploying, and monitoring mobility

Documents