Planning, Deploying, and Monitoring Mobility

quarterceladonΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

254 εμφανίσεις



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


1

Planning for Mobility

When you deploy cumulative updat
e 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 Ser
ver 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 re
ach, 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 eit
her 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. Wh
en 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
Planning, Deploying, and Monitoring Mobility

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
a
pplications 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 mes
saging (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 Component
s

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 Mob
ile 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
i
nternal 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 Se
rvice,
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 eit
her 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 no
t support mobile applications running in the
Planning, Deploying, and Monitoring Mobility

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, w
hich 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 touc
h 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 u
ser experience. This section describes the
Planning, Deploying, and Monitoring Mobility

4

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
re
sources. 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 ext
ernal 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.



Planning, Deploying, and Monitoring Mobility

5

To support mobile users from b
oth 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 c
ertificates, 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 foll
owing 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 corpo
rate
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 Serv
ice 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 wireles
sly,
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 mobi
le 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 a
utomatic 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:

Planning, Deploying, and Monitoring Mobility

6

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 h
ave 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 suppor
t 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 conf
igure
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
Configuri
ng the Reverse Proxy for Mobility
.

Planning, Deploying, and Monitoring Mobility

7

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 We
b 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 op
en 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
cer
tificates 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 alt
ernative 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
Ser
vice 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 n
ot 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 U
sing 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 su
pport mobile devices connecting
wirelessly, either the root certificate chain from the internal CA must be installed on the
Planning, Deploying, and Monitoring Mobility

8

mobile devices or you must change to a public certificate on your Lync Server
infrastructure.

This section describes the subject alt
ernative 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.<sipdoma
in>

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=lyncdiscove
rinternal.<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 Autodiscove
r 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 thes
e settings. For details, see
Installing the Mobility and Autodiscover Services
.

Planning, Deploying, and Monitoring Mobility

9

Hardware Load Balancer Requirements

If your environment inc
ludes 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 clien
t 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 s
hould
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 det
ails, 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 reve
rse 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 mo
bile 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 we
b publishing rules on the
reverse proxy. For details, see
Technical Requirements for Mobility
. With automatic
discovery, users can automatically locate L
ync 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.

Planning, Deploying, and Monitoring Mobility

10



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 d
efault 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 t
heir 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 hardw
are 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 supp
ort 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
S
erver 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 m
obile 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.

I
f 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?

Planning, Deploying, and Monitoring Mobility

11

By default, the global mobility policy enables access to mobility and Call via Work to all users.
If you want to def
ine 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 conf
erences?

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

Determ
ining 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 illust
rates 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 determinin
g the sizing you need to deploy mobility.

Planning, Deploying, and Monitoring Mobility

12

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 counter
s 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 runnin
g 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



Planning, Deploying, and Monitoring Mobility

13

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

Participan
ts 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 opera
ting 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 reactiv
ated by a
push notification or when the user manually brings the application to the foreground.

Planning, Deploying, and Monitoring Mobility

14



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.

Avail
able 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 co
unter. 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 ha
s 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 me
mory (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 e
ndpoint) 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 le
ss 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.

Planning, Deploying, and Monitoring Mobility

15

Sizin
g 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 t
o 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
t
his 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 me
mory.



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.

Planning, Deploying, and Monitoring Mobility

16

The minimum required memory for each serve
r 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.

Deploym
ent 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
In
ternal
Server Ports
for Mobility

Install
Microsoft
Lync Server


Run McsStandalone.msi on
each Front End Server to
install the Mobility Service and
CsAdministrator

Installing the
Mobility and
Autodiscover
Planning, Deploying, and Monitoring Mobility

17

Phase

Steps

Permissions

Deployment
documentation

2010
Mobility
Service and
Microsoft
Lync Server
2010
Autodiscover
Service

the Autodiscover Service.



創渠
䵣sS瑡t摡l潮攮esi
敡c栠hir散瑯爠瑯ti湳瑡ll⁴ e
A畴u摩scov敲eS敲eic攮

S敲eic敳

䵯dify
c敲瑩fic慴as

A摤⁳u扪散琠tl瑥牮t瑩v攠湡m攠
敮瑲i敳⁴漠oh攠e潬lo睩湧⁣敲eific慴as
瑯ts異p潲琠o散畲攠u潮湥c瑩潮s⁦潲o
m潢il攠es敲e:



䑩r散瑯爠t敲瑩fic慴e



Fr潮琠t湤⁰潯l⁣敲瑩fic慴a



剥R敲e攠er潸y⁣敲eific慴a

䱯c慬 慤mi湩s瑲慴ar

䵯difyin朠
䍥C瑩fic慴as⁦潲o
䵯bility

䍯湦i杵re
瑨t⁲e
v敲e攠
灲潸y



Assi杮⁣敲eific慴as⁵ 摡t敤
睩瑨tsu扪散琠tl瑥牮t瑩v攠湡mes
瑯t瑨攠e散畲攠u潣k整e⁌ yer
(SS䰩L䱩s瑥湥r.



䍯湦i杵re⁡ new 睥戠
灵blishi湧⁲畬e⁦潲⁴桥o數t敲湡e
A畴u摩scov敲eS敲eic攠啒䰮



E湳畲攠u桡琠愠we戠b畢lishi湧
r畬攠eis瑳⁦潲⁴桥o數瑥牮a
l Ly湣
S敲e敲eW敢⁓敲eic敳⁕ 䰠潮
yo畲⁆ro湴nE湤 灯ol.





䥦 yo甠u桯潳攠eo⁵ 攠䡔TP⁦潲o
瑨t i湩瑩al A畴潤iscov敲⁲敱略s琠
慮搠湯琠異d慴a⁳u扪散琠
慬瑥牮慴av攠e慭攠eis瑳渠nh攠
c敲瑩fic慴asⰠ,潮fi杵re⁡ new
睥戠p畢lishi湧⁲畬e⁦潲⁰潲o‸
䡔TP.

䱯c慬 慤mi湩
s瑲慴ar

䍯湦i杵ri湧
瑨t⁒敶敲e攠
Pr潸y⁦潲o
䵯bility

T敳琠yo畲u
m潢ility
摥ploym敮t

創渠
Test
-
CsMcsP2PIM

to test
sending an instant message from
one
person to another.

CsAdministrator

Verifying Your
Mobility
Deployment

Configure for


F潲⁌y湣 S敲v敲′〱0

Ed来
剴R啮Uv敲e慬S敲v敲e摭i湳

䍯湦i杵ri湧
Planning, Deploying, and Monitoring Mobility

18

Phase

Steps

Permissions

Deployment
documentation

push
notifications

Servers, add a Lync Server
online hosting provider and
configure hosting provider
federation.



F潲⁏晦ic攠䍯mm畮ic慴a潮s
S敲e敲′e〷⁒2

E摧e⁓敲e敲eⰠ
慤搠愠a敤敲慴敤⁰慲瑮敲a



䥦 yo甠睡湴⁴漠o異灯r琠t畳h
湯瑩fic慴i潮s 潶敲⁡eW
i
-
Fi
湥tw潲oⰠ,潮fi杵r攠e⁦irew慬l
r畬攠e潲⁔䍐⁰ r琠t㈲㌮



啳攠e桥
Set
-
CsPushNotificationConfigura
tion

cmdlet to enable push
notifications to the Apple Push
Notification Service (APNS)
and Microsoft Push Notification
Service (MPNS). This feature
is disab
led by default.



啳攠e桥
Test
-
CsFederatedPartner

cmdlet to
test the federation
configuration and the
Test
-
CsMCXPushNotification

cmdlet to test push
notifications.

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.

Planning, Deploying, and Monitoring Mobility

19

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



Configuri
ng 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 mobi
le 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 exte
rnal 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 do
main (for example, contoso.local).

Planning, Deploying, and Monitoring Mobility

20

Note:

This domain is the Active Directory domain where your Lync Server

Director
pool and Front End pool are installed.



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,渠n桥⁣o湳潬攠er敥 ⁴ 攠䑎匠s敲v敲Ⱐ數p慮d
Forward
Lookup Zones

fo
r your SIP domain (for example, contoso.com).

4.

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



F潲⁡渠i湴nrn慬⁄乓⁲散潲搬⁡ 桯s琠A⁲散潲搠oh潵l搠數is琠t潲⁴桥oi湴敲湡l W敢
S敲eic敳⁦畬lyⁱ畡lifie搠d潭慩渠湡m攠⡆Q䑎D⁦潲oyo畲⁄楲u
c瑯爠t潯l
f潲⁥o慭灬攬e
ly湣睥扤ir〱⹣潮瑯to⹬潣al).



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,⁨潳琠t⁲散潲o⁳桯ul搠數is琠t潲⁴桥o數瑥牮tl 睥戠
s敲eic敳⁆ 䑎⁦潲oyo畲⁄楲散瑯爠灯tl
f潲⁥o慭灬攬elyncwe扥瑤ir⹣潮瑯to⹣潭).



V敲楦y⁴桡琠愠a潳琠t⁲散潲o 數is瑳⁦潲oyo
畲⁆r潮t⁅n搠d潯l 慳⁦潬lows:



F潲⁡渠i湴nrn慬⁄乓⁲散潲搬⁡ 桯s琠A⁲散潲搠oh潵l搠數is琠t潲⁴桥oi湴敲湡l W敢
S敲eic敳⁆ 䑎⁦潲oyo畲⁆r潮琠E湤 灯ol
f潲⁥o慭灬攬elyncwe扰o潬0ㄮ1潮瑯t漮l潣慬).



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,⁨潳琠t⁲散潲o⁳桯ul搠數is琠t潲⁴
桥⁥ 瑥牮tl W敢
S敲eic敳⁆ 䑎⁦潲oyo畲⁆r潮琠E湤 灯ol
f潲⁥o慭灬攬e
ly湣睥扥t灯ol0ㄮ1潮t潳漮com).



F潲⁡渠i湴nrn慬⁄乓⁲散潲搬⁩渠n桥⁣o湳潬e⁴牥攠潦 y潵r 䑎匠s敲v敲Ⱐ數p慮d
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:



F潲⁡渠i湴nrn慬⁄乓⁲散潲搬⁴yp攠ey湣disc潶敲楮t敲湡l⁡s⁴ 攠e潳琠t慭攠e潲⁴桥o
i湴nrn慬 Au瑯tisc潶敲⁓ervic攠啒䰮



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,yp攠ly湣摩sc潶敲⁡e⁴ 攠e潳琠t慭攠e潲⁴桥o數瑥牮tl
A畴u摩scov敲eS敲eic攠啒䰮



䥮I
Fully qualified domain nam
e (FQDN) for target host
, do one of the following:



F潲⁡渠i湴nrn慬⁄乓⁲散潲搬⁴yp攠er⁢ ows攠eo⁴ e⁩n瑥t湡l W敢⁓敲eic敳⁆ 䑎⁦潲o
yo畲⁄ir散瑯爠灯ol
f潲⁥o慭灬攬ely湣睥扤ir〱⹣潮瑯t漮o潣al)Ⱐ,湤⁴桥n⁣lick
OK
.



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,yp攠er 扲b
ws攠e漠oh攠e瑥r湡l W敢⁓敲eic敳⁆ 䑎⁦潲o
yo畲⁄ir散瑯爠灯ol
f潲⁥o慭灬攬ely湣睥扥t摩r⹣潮瑯t漮o潭)Ⱐ,湤⁴ 敮⁣lick
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:

Planning, Deploying, and Monitoring Mobility

21

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.

Lo
g 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 doma
in (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, lyncwebd
ir01.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 fo
r 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 DN
S 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.

Planning, Deploying, and Monitoring Mobility

22



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,yp攠ly湣摩sc潶敲⁡e⁴ 攠e潳琠t慭攠e潲⁴桥o數瑥牮tl
A畴u摩scov敲eS敲eic攠啒䰮

Note:

The domain name is assum
ed 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:



F潲⁡渠i湴nrn慬⁄乓⁲散潲搬⁴yp攠eh攠e湴nrn慬 W敢⁓敲eic敳⁉ 慤摲敳s ⁴ e⁄ r散瑯爠
(
潲Ⱐof y潵⁵ 攠eo慤 扡l慮c敲Ⱐeyp攠eh攠eir瑵慬⁉P
V䥐) ⁴ 攠eir散瑯爠t潡搠扡l慮c敲e.

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
Fron
t End pool load balancer.



F潲⁡渠ot敲湡l⁄ S⁲散潲oⰠ,yp攠eh攠et敲湡e爠 畢lic⁉ ⁡摤r敳s ⁴ 攠牥v敲e攠
灲潸y.

㄰1

䍬ick
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 t
he 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 Se
rver 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
Ly
nc 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 2
011

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
St
art
, 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

Planning, Deploying, and Monitoring Mobility

23

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 Manag
ement 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)

搠慳s敭扬i敳⸠
A琠瑨攠e潭m慮搠din攬etyp攺

Stop
-
CsWindowsSer
vice

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 th
e changes made by LyncServerUpdateInstaller.exe to the SQL Server databases
by doing one of the following:



䥦⁅湴nr灲楳攠Editi潮 B慣k⁅湤⁓敲e敲⁤慴慢慳敳 慲攠a潴oc潬l潣慴敤 睩瑨t慮y 桥r
摡瑡扡s敳Ⱐ,畣栠hs Arc桩vi湧爠䵯ni瑯ti湧 摡t慢慳敳Ⱐ,琠瑨攠e潭m
慮搠din攬etype⁴ 攠
f潬lo睩湧:

Install
-
CsDatabase

Update

ConfiguredDatabases

SqlServerFqdn
<SQL Server FQDN>



䥦⁅湴nr灲楳攠Editi潮 B慣k⁅湤⁓敲e敲⁤慴慢慳敳 慲攠a潬l潣慴a搠wi瑨to瑨tr 摡瑡扡s敳Ⱐ
s畣栠hs⁁rc桩vi湧 潲⁍o湩t潲楮朠摡t慢慳敳Ⱐ慴at桥⁣omm慮d

lin攬etyp攠eh攠e潬lo睩湧:

Install
-
CsDatabase

Update

ConfiguredDatabases

SqlServerFqdn
<SQL Server FQDN>
-
ExcludeCollocatedStores




F潲⁓oa湤慲a⁅diti潮Ⱐ,y灥 t桥⁦潬lowi湧:

Install
-
CsDatabase

Update
-
LocalDatabases

13.

Restart the Lync Server servi
ces. 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.

Planning, Deploying, and Monitoring Mobility

24

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 S
erver Management Shell
.

3.

Set the port for the internal Web Services. At the command line, type:

Set
-
CsWebServer

Identity <name of pool>

McxSipPrimaryListeningPort 5086

For example:

Set
-
CsWebServer

Identity pool01.contoso.com

McxSipPrimaryListeningPor
t 5086

Where pool01.contoso.com is the pool where the Mobility Service will be installed

4.

Set the port for the external Web Services. At the command line, type:

Set
-
CsWebServer

Identity <name of pool>

McxSipExternalListeningPort 5087

For example:

Set
-
C
sWebServer

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 t
he 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
numbe
r reach (receive calls on a mobile device that were dialed to your work number), Call via
Planning, Deploying, and Monitoring Mobility

25

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 S
erver
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 re
strict 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 per
form 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 Compressio
n 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

Install Web
-
Dyn
-
Compression

Planning, Deploying, and Monitoring Mobility

26

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
\
inetsr
v
\
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.con
fig"

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

ExposedWebUrl Internal


Modifyin
g 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 clien
ts. For details about certificate requirements for mobility, see
Technical Requirements for Mobility
.

Update the certificates after you install the new M
icrosoft 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 inter
nal Microsoft Lync Server 2010 Autodiscover Service fully
Planning, Deploying, and Monitoring Mobility

27

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 c
mdlet 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) reco
rd 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 s
tep 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 certifica
tes 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
-
CsCertifica
te

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,WebServi
cesInternal,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 wi
th
multiple types. In this case, run the
Set
-
CsCertificate

cmdlet separately for each use.
For example:

Set
-
CsCertificate

Type Default

Thumbprint <Certificate
Planning, Deploying, and Monitoring Mobility

28

Thumbprint>

Set
-
CsCertificate

Type WebServicesInternal

Thumbprint
<Certificate Thumbprint>

Set
-
CsCertificate

Type WebServicesExternal

Thumbprint
<Certificate Thumbprint>

6.

If an Autodiscover Service subject alternative name is missing, do the following:



F潲⁡issi湧⁩湴敲湡l⁁畴u摩sc潶敲⁳畢j散琠tl瑥牮慴ave m攬e慴a瑨t⁣潭m慮搠din攬e
typ攺

Request
-
CsCertificate

New

Type WebServicesInternal

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 WebServicesInternal

Ca
dc
\
myca

DomainName “LyncdiscoverInternal.
contoso.com,
LyncdiscoverInternal.contoso.net”
-
verbose



F潲⁡issi湧⁥ 瑥牮tl A畴u摩sc潶敲⁳畢j散琠tl瑥牮慴ave m攬e慴a瑨t⁣潭m慮搠din攬e
typ攺

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.c
om,
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 a
lternative 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 t
he 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
Planning, Deploying, and Monitoring Mobility

29

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
Thr
eat 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
, righ
t
-
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, selec
t
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
Inte
rnal 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 Delegat
ion

page, select
No delegation, but client may
authenticate directly
.

Planning, Deploying, and Monitoring Mobility

30

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

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:



S敬散琠
Forward the original host header instead of the actual one
.



䥦 yo畲⁤u灬oym敮琠t慳 愠䙲潮琠E湤 灯olⰠ,el散琠
Requests appear to come from the
original client
. If your deployment has a single Front End Server or Standard Edition
server, select
Req
uests appear to come from the Forefront TMG computer
.

16.

On the
Bridging

tab, configure the following:



S敬散琠
Web server
.



S敬散琠
Redirect requests to HTTP port
, and type
8080

for the port number.



S敬散琠
Redirect requests to SSL port
, and type
4443

f
or 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
, poin
t 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 Publishin
g 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 Conne
ction 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, lync
pool01.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 t
he
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).

Planning, Deploying, and Monitoring Mobility

31



䥮I
Path
, type
/*
.

10.

On
Select Web Listener

page, in
Web Listener
, select a Web Listener or use the New
Web Li
stener 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

pa
ge, 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:



S敬散琠
Web server
.



S敬散琠
Redirect requests to HTTP port
, and type
8080

for the port number.



V敲楦y⁴桡琠
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 2
010 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 com
puter 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:

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

Planning, Deploying, and Monitoring Mobility

32

You can s
et 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.PSCre
dential("contoso
\
UserName1", $passwd1)

$tuc2 = New
-
Object
Management.Automation.PSCredential("contoso
\
UserName2", $passwd2)

Test
-
CsMcxP2PIM
-
TargetFqdn pool01.contoso.com
-
SenderSipAddress
sip:UserName1@contoso.com
-
SenderCredential $tuc1
-
ReceiverSipAdd
ress sip:UserName2@contoso.com
-
ReceiverCredential
$tuc2

v



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 t
he 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 Communication
s 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
-
Cs
PushNotificationConfiguration

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 Serve
r 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
Planning, Deploying, and Monitoring Mobility

33

Lync Server 2010
, and then click
Lync Server Management Shell
.

3.

Ad
d 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
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 Serve
r 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 Applicatio
ns
, 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 Manag
ement Shell: Click
Start
, click
All Programs
, click
Microsoft
Lync Server 2010
, and then click
Lync Server Management Shell
.

Planning, Deploying, and Monitoring Mobility

34

3.

Enable push notifications. At the command line, type:

Set
-
CsPushNotificationConfiguration

EnableApplePushNotificationService $T
rue

EnableMicrosoftPushNotificationService $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 configurat
ion. At the command line, type:

Test
-
CsFederatedPartner

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

T
est
-
CsFederatedPartner

TargetFqdn accessprox.contoso.com

Domain push.lync.com

ProxyFqdn sipfed.online.lync.com

4.

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 W
ork 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 us
er 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.

Planning, Deploying, and Monitoring Mobility

35

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 t
wo 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 en
abled 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 mem
ber 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 co
mmand 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 modif
y 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 Serve
r 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

Identity site:<site identifier>

EnableMobility $False
-
EnableOu
tsideVoice $False

Planning, Deploying, and Monitoring Mobility

36

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 M
anagement 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 lev
el 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

Gra
nt
-
CsMobilityPolicy

Identity

MobileUser1@contoso.com

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 tha
t 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
mobil
ity 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

Planning, Deploying, and Monitoring Mobility

37

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 Ser
vice 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 Sessi
on 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 b
ackground
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, c
apacity 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 n
eed 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
)

The Front End Server needs enough available m
emory 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.

Planning, Deploying, and Monitoring Mobility

38

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 detail
s, see "Scenario Examples" in
Capacity Planning for Mobility
.

Monitoring Mobility Service Usage

On an ongoing basis, you should monitor the CPU and memory tha
t 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 deplo
yments, 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 tr
ace 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 ser
ver, 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.mi
crosoft.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 settin
gs 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).

Planning, Deploying, and Monitoring Mobility

39



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 y
ou 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 an
d 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.


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
.

Planning, Deploying, and Monitoring Mobility

40

Mobility Performance Counters

Counter

Description

Average Lifetime for a Session in Milliseconds

The average lifetime for a session in
milliseconds

Current Push Notification Subscript
ions

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 Networ
k 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 S
ervice

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 Notificati
on 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 notificat
ions

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 succ
essful 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
Planning, Deploying, and Monitoring Mobility

41

Counter

Description

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