chapter 03 client administration

7/23/2019 Chapter 03 Client Administration

1/33


2/33

This document is provided as-is. Information and views expressed in this document,including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real

association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any

Microsoft product. You may copy and use this document for your internal, referencepurposes.

Copyright 2011 Microsoft Corporation. All rights reserved.

Microsoft, Internet Explorer, Lync, Outlook, PowerShell, Silverlight, and Windows aretrademarks of the Microsoft group of companies. All other trademarks are property of their

respective owners.

Microsoft Lync Server 2010 Client Administration Page 2


3/33

This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currentlybeing developed. Chapters will be available for download while this book is being completed.

To help us improve it, we need your feedback. You can contact us at

[email protected]. Please include the chapter name.

For information about the continuing release of chapters, check the DrRez blog athttp://go.microsoft.com/fwlink/?LinkId=204593.



4/33

ContributorsProject Manager: Susan S. Bradley

Content Architect: Rui Maximo

Chapter Lead: Michele Martin

Writers: Philipp Beck, Brandon Taylor

Contributing Writers: Paul Brombley

Sidebar Contributor: Paul Brombley

Technical Reviewers: Paul Brombley, Dave Howe, Antti Kiviniemi,Cameron Parker, StefanPlizga, Jeffrey Reed, Nick Smith, Stephen Wong, Rob Young

Lead Editor: Janet Lowen

Art Manager: Jim Bradley

Production Editor: Kelly Fuller Blue



5/33

Table of ContentsClient Administration ................................................................................................. 6

Internals for Client Administration............................................................................13

Troubleshooting Clients............................................................................................ 28

Summary..................................................................................................................32

Additional Resources................................................................................................32



6/33

Client AdministrationMicrosoft Lync Server 2010 introduces updated and enhanced tools for managingservers and clients. With the introduction of the Microsoft Lync Server 2010 Control Panel,

all client management tasks are integrated into the same tool that is used to manageservers. You can centrally manage all policy settings and apply them at the global level, site

level, or user level (single user or group of users). In addition, with the new Lync ServerManagement Shell, you can use Windows PowerShell command-line interface commands

to automate policies across the entire infrastructure.

The clients for Lync Server 2010 provide a full set of unified communications features for

the enterprise information worker, the external meeting attendee (anonymous user ortraveling enterprise member), the federated partner, and the occasional user who rarely

connects to your infrastructure. In addition, the Microsoft Lync 2010 Attendant combineswith the Response Group application features to cover a wide variety of receptionist

scenarios.

This chapter covers details about the operational management of the following clients: Microsoft Lync 2010, the full-featured client that installs on client computers.

Microsoft Lync 2010 Attendee, the meeting-only client for enterprise and non-

enterprise attendees that installs on client computers.

Microsoft Lync Web App, the web-based, meeting-only client for enterprise and non-

enterprise attendees.

Lync 2010 Attendant, the call-management client designed for receptionist or

administrative assistant scenarios.

In this chapter, you will find information about managing the client experience, updating

clients as needed, and configuring policies based on your administrative, compliance, andcountry/regional needs.

Note. This chapter focuses on Lync Server 2010 computer-based clients. For detailed information aboutusing Microsoft Lync 2010 Phone Edition and devices, see Planning for Devices, available athttp://go.microsoft.com/fwlink/?LinkId=204935, and Deploying Lync 2010 Phone Edition, available athttp://go.microsoft.com/fwlink/?LinkId=204936.

Managing Lync 2010

Lync 2010 is the primary Lync Server client used in an enterprise. To ensure a consistent

user experience across all endpoints, Lync Server uses in-band provisioning to propagatepolicies to clients. Client management settings that were previously controlled through

Group Policy are moved into the shared Central Management store database. This enables

policies and settings, for example, the Media Relay Authentication Server (MRAS) setting, tobe sent to clients that are not joined to the domain in addition to Lync Phone Editiondevices.

For endpoints such as Lync, an advantage of using in-band provisioning is that informationcritical to client functionality is stored on the server and not on the computer or the specific

endpoint. This simplifies the application of policies and server settings across theorganization because the settings apply to all clients that sign in to the server pool.



7/33


8/33

Using client version policy to specify versions of Attendee that are allowed in your

environment.

Determining whether or not you want to present Attendee as an option to users

when they join Lync meetings.

Meeting Join PageWhen a user clicks a meeting link in a meeting request, the meeting join page detects

whether a Lync Server client is already installed on the users computer. If a client isalready installed, the default client opens and joins the meeting. If a client is not installed,

the meeting join page (the page that prompts the user to join the meeting) displays optionsfor joining the meeting by using alternate clients.

The meeting join page always contains the option to use Lync Web App. In addition to thisoption, you can decide whether to show a link for downloading Lync Attendee or a link for

joining by using a legacy Communicator 2007 R2 client. Both of these links are disabled bydefault. The Communicator 2007 R2 option allows users to join Lync meetings with some

limitations. These users will be able to participate in the IM, voice, video, and sharing

portions of the meeting, but other features such as PowerPoint upload, whiteboard, and

polling features are unavailable.

Figure 1 shows how the meeting join page appears when the Attendee download is enabled.

Figure 1. Meeting join page

You can control the Lync Server 2010 clients that are available for joining scheduled Lync

Server 2010 meetings by using the Lync Server Control Panel or the Lync Server



9/33

Management Shell to configure the meeting join page. For details about how the meetingjoin page determines the options available for joining the meeting, see the section Meeting

Join Flow later in this chapter.

Managing Lync Web App

Lync Web App is a browser based Microsoft Silverlight-based application that enables

access to Lync meetings. The Lync Web App requires a Silverlight enabled browser and runson the operating system and browser combinations listed at

http://go.microsoft.com/fwlink/?LinkId=211720. Users who do not have Lync, LyncAttendant, or Lync Attendee installed can use Lync Web App to attend meetings. Lync Web

App does not require installation, although Silverlight is a prerequisite and a plug-in isrequired for the sharing features. As with Lync Attendee, the user may or may not have an

account within the enterprise, which makes Lync Web App useful for external users orpartners and during migration. Lync Web App is always an option on the meeting join page.

Lync Web App in Lync Server 2010 is analogous to Communicator Web Access in OfficeCommunications Server 2007 R2. However, Lync Web App is a meeting client only, and it

does not support presence, contacts, or audio/video capabilities. Deployment andmaintenance is minimal with Lync Web App because it is provided by default as a service on

the Front End Server.

Managing Lync 2010 Attendant

In Lync Server 2010, the Attendant is designed primarily for receptionist and administrative

assistant scenarios. For receptionists and administrative assistants who must manage highvolumes of calls and conversations, you can create an effective solution by combining the

Response Group application in Lync Server with the Attendant client. This section describesthe Lync Server features you should consider and ways that you can manage these

features.

Managing the Lync 2010 Attendant is similar to managing Lync 2010. As with Lync, most of

the settings that determine client features and functionality are configured by using Lync

Server Control Panel and are passed along to Attendant clients through in-bandprovisioning. However, there are Group Policy settings you can configure to control thebehavior of Attendant clients.

Note. For details about Group Policy settings for Attendant, see Lync 2010 Attendant Group Policy athttp://go.microsoft.com/fwlink/?LinkId=219947.

Optimizing the Receptionist Scenario

The following features, though not required, are commonly used in a receptionist

deployment. Some of these features are likely to be part of the corporate setup already,such as Call Park and malicious call tracing. Others, such as the Response Group

application, are intended to help organize incoming calls to provide the best experience forthe caller.

The following scenarios are recommended in a standard receptionist deployment and arediscussed in the following sections in more detail:

Response Group application

Sorting search results by last name

Reporting a malicious call

Parking a call



10/33

Location services for Enhanced 9-1-1 (E9-1-1)

Integration with Response Group Application

The Response Group application is very important to a receptionist deployment because it

enables the administrator to define rules and criteria to handle calls before the calls reachthe receptionist. This allows for features such as additional screening, call waiting music,

and fallback queuesall of which are designed to make the experience more pleasant forthe caller, which makes the receptionists job easier.

Note. For details about deployment and setup of the Response Group application, see the chapter titledResponse Group Application.

There are three recommended ways to deploy the Response Group application with thereceptionist. These methods build on each other as the complexity of the scenario increases.

Tier 1: Single response group

Tier 2: Single response group, multiple agent groups

Tier 3: Multiple response groups, multiple agent groups

The following sections explain in more detail the deployments previously listed and discusstwo important features that are relevant to deployments. The important thing to remember

is that the configuration and setup of the response group for a receptionist is fairlystraightforward, it just requires some planning to identify which deployment is the most

appropriate.

Single Response Group

The single response group is useful when the deployment is:

In a smaller office or branch office

There is a single receptionist working at one time

The receptionist is not expected to cover for any additional buildings or numbers(other than the main line)

On the surface, this setup appears to be similar to simply routing the main line number

directly to the receptionist. However, configuring a response group is stronglyrecommended because it provides the following benefits:

Anonymity With the anonymity feature, the identity of the receptionist can be

hidden from the caller, by replacing the receptionists name with a title such as

Contoso Receptionist. Besides keeping the identity hidden, making the receptionist

an anonymous agent gives the receptionist the flexibility to still be contacted directly

by internal colleagues. The receptionist can easily identify in the user interface the

difference between a caller to the main line number and an internal caller, because

of the Via field in the Attendant.

Overflow A concern of having only one receptionist is that it becomes difficult to

handle situations of overflow. If the receptionist is currently handling a call, the caller

must wait. A response group can be configured to play music, and, if necessary,

follow backup options after a caller has been waiting for a certain period of time.

Without this, the caller might hear only a busy signal and ultimately give up on the

call entirely.



11/33

Outside working hours The response group lets you easily define rules for callers

that call outside office hours and on holidays. It can play a different announcement

and direct the caller to a shared voicemail to be picked up the following morning by

the receptionist.

Multiple Agent Groups

Multiple agent groups are useful when more than one receptionist is responsible for handling

calls to a single number. In this scenario, you can set up a backup receptionist agent groupso that a user who is not the primary handler of a specific number can take calls if the

primary receptionist is unavailable. The backup receptionist can receive calls without havingto physically re-locate.

Figure 2 is a visual representation of the recommended configuration of a single response

group that has multiple agent groups.

Figure 2. Multiple agent groups

Multiple Response Groups

When you set up multiple response groups, each response group represents the physicalnumber that is called. A receptionist can belong to multiple groups and act as a backup for

one or more groups.

Figure 3 is a visual representation of the recommended configuration for multiple response

groups with multiple agent groups.



12/33

Figure 3. Multiple Response Groups

Formal Agents

Formal Agents are not new in Lync Server 2010, but are particularly useful for receptionists.

As a formal agent, each person is automatically assigned to the response group for the mainline number, but an individual agent will not receive calls until he or she signs in. This

feature provides the flexibility for each person take calls only when they are ready andenables receptionists to switch shifts seamlessly.

Attendant Routing

An important new Lync Server 2010 response group feature designed specifically for theAttendant is the attendant routing method. Attendant routing uses parallel ringing so that

any number of receptionists will receive all calls that arrive to the main line number. Thisfeature takes advantage of the queuing interface in the Attendant and allows users to see

multiple calls stacking up as they arrive in order. Each user can see the actual call, withcaller information, and a timer for how long they have been waiting. Then they can choose

to answer the most important calls first.

Note. For details about deploying and setting up the attendant routing method, see the chapter titled

Response Group Application.

Sorting Search Results by Last Name

In a locale where surname is the most common way to address someone, users will benefitfrom the ability to sort search results by either Last Name or Display Name. This feature,

which is available in both Lync and Attendant, lets users quickly locate the internal caller towhom to transfer a call by searching for the last name and then looking for that same value,

as would be natural in this scenario.



13/33

Reporting a Malicious Call

In many companies, the receptionist handles the majority of external callers. Unfortunately,

this can also include callers who make threats against the company during the call. WithLync Server 2010, the ability to report a call as malicious is now supported. Information for

the last call received is marked in the call detail records (CDRs) for the administrator tofollow up on as appropriate.

Note. For details about how to identify malicious call in the database, see the chapter titled EnterpriseVoice. Additionally, there are partners that will provide the ability to record calls automatically.

Parking a Call

In an environment where many workers do not have desktops or actual phone numbers, the

receptionist is required to park calls on an open-space phone where the call can beretrieved. Typically, the receptionist announces the call over a paging system and specifies

the orbit that the call can be retrieved on. In Lync Server 2010, this functionality is

available when the Call Park application is installed on the server and enabled for thereceptionist through in-band provisioning.

Note. We recommend that you configure the paging system as a contact. This allows the receptionist toeasily call that system to announce the orbit.

Note. For details about configuring the Call Park application on the server, see the chapter titledEnterprise Voice.

Location Services for E9-1-1

A receptionist is often expected to report emergencies. In Lync Server 2010, thereceptionist can call emergency services and the location will automatically be passed along

to the emergency services provider.

The receptionist cannot modify or correct the location, because this is expected to be

automatically determined through the wired network they are on. However, they can verifytheir location from the Attendant Options and report any discrepancies to their

administrator.

Note. For details about configuring E9-1-1 functionality for the server, see the chapter titled EnterpriseVoice.

Internals for Client AdministrationIn the following sections, you will find in-depth information about managing the client

experience, updating clients as needed, and configuring policies based on youradministrative, compliance, and country/regional needs.

Lync Client Sign-in Process

During signin, Lync or the Lync Attendant determines the server it should sign into byusing the users SIP URI and any manual settings configured on the client. If the

ConfigurationMode, ServerAddressInternal, and ServerAddressExternal values exist in theclient computer registry, the client uses the specified server settings. For details, see

Understanding Manual Configuration later in this chapter. However, if these settings donot exist and the URI is the only information provided, the client performs automatic

discovery to search for an appropriate server. For details, see the section UnderstandingAutomatic Discovery later in this chapter.

After the client discovers the server to sign into, it tries to connect to the server by using

TLS over TCP. The server provides a certificate to authenticate itself to the client. The client



14/33

must validate the certificate before it continues. The client might negotiate compression,and then it initiates a SIP registration.

Note. In previous versions of Office Communicator, the client could try to connect to the server over TCP.However, Lync Server 2010 no longer supports TCP for client connections. Although the Transport settingis still available, allowing you to configure Lync clients to use TCP, we strongly recommend that you do notdo this in production environments.

Next, the client sends a SIP REGISTER message to the server without any credentials. Thisaction prompts Lync Server to challenge for user credentials and specify to the client the

authentication protocols that it accepts. If the current Windows credentials match thecredentials associated with the SIP address, the client is allowed to sign in. Otherwise, Lync

Server prompts the user for credentials associated with the SIP address.

Authentication failures can occur during the first part of the sign-in process if the desktopcredentials do not match the account that Lync is trying to use. Sign-in failures can also

occur when the SIP URI, account name, or password is typed incorrectly or when credentialsentered do not correspond to the SIP URI entered. For example, if Kim tries to sign in with

the URI sip: [email protected] along with the user account and password for

CONTOSO\vadim instead of the user account and password for CONTOSO\kim, sign-in willfail.

Understanding Automatic Discovery

With automatic discovery, Lync 2010 or Lync Attendant automatically connects to the

appropriate server without requiring the user to specify a server name. Whether the client isconnecting from inside or outside the internal network, the automatic discovery feature uses

the same process to redirect the client to the appropriate server (in the case of StandardEdition) or pool (in the case of Enterprise Edition). For the automatic discovery process to

work successfully, you must publish the appropriate DNS Service (SRV) records internallyand externally.

When a user attempts to sign in, the client begins querying DNS SRV records. By default,the client uses TLS for authentication. First, the client searches for an internal DNS SRV

record that contains the same domain name that is specified in the users SIP sign-inaddress. For example, if the user signs in with the SIP address [email protected], the

client searches for the following DNS SRV record:

_sipinternaltls._tcp.contoso.com

If the client finds this record, it receives the host name and the port (internally, port 5061)to which it should connect. The host certificate name should match the domain of the SIP

address. The client then resolves the host name to the IP address of the Lync Serverwhichcan be either a Director or a Registrar pooland connects directly to it. To ensure that

internal clients can sign in, make sure this internal DNS SRV record is published in theinternal DNS namespace. You can also publish multiple records with this same name but

with different hosts and priorities.

If the client is unable to find this internal DNS SRV record, the client continues by searching

for the following external DNS SRV record:

_sip._tls.contoso.com

If the client finds this record, it connects to the specified host over the specified externalport (443). Usually, this host is the Access Edge Server. (However, this is not always the

case; see the Direct from the Source section titled Configuring DNS SRV Records: OtherPossibilities.) The Access Edge Server proxies the request to a next hop, which could be a

user pool or a Director. If the next hop is not the users home pool, the SIP messaging isproxied to the users home pool and the client signs in. As with internal records, you could



15/33

also publish multiple records externally with the same name but with different hosts andpriorities.

If the client is unable to locate an SRV record, the client uses Dynamic Host Configuration

Protocol (DHCP) next, if configured. You can configure DHCP options in your corporate DHCP

server to reply to DHCP 120 queries, or you can turn on Lync Server DHCP so that the LyncServer Registrar responds to Option 120 queries. Note that for devices, you must also

configure Option 43, which specifies the URL for the Lync pool certificate provisioningservice.

If DHCP is not configured the client uses the following queries to look up the host recordsdirectly:

sipinternal.contoso.com

sipexternal.contoso.com

sip.contoso.com

If all of these queries fail, the sign-in process fails and requires manual intervention.

For details about configuring DNS for Lync, see Determining DNS Requirements at

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

Direct from the Source

Configuring DNS SRV Records: Other Possibilities

Paul Brombley

Senior Consultant

Some organizations, especially those that use split brain DNS (where the SIP domain matches theActive Directory domain), configure the _sip._tls.contoso.com record to resolve to sip.contoso.com forboth internal and external queries. They use A records to direct clients further by configuring the Arecords with a different IP address internally and externally. The internal IP address specifies theaddress of the pool or Director, and the external IP address specifies the address of the Access Edge

Server.

It is also worth noting that without split brain DNS, users can experience a delay when attempting tosign in from outside the network. This happens when the client finds the _sipinternal SRV record andthe A record, and then is forced to wait for a TCP timeout before it tries the _sip SRV record. This is acase in which manual configuration might be a more efficient option.

Some organizations configure two SRV records to provide a fall back in case of an outage. Forexample, they might configure _sipinternal to point to sip.contoso.com, which resolves to an internalDirector. In addition, they configure _sip to resolve to pool1.contoso.com, which is often in differentdata center. If the Director or the WAN link is unavailable, clients are still able to sign in. However,now that DHCP is an option, this situation is less likely to happen.

Understanding Manual Configuration

There are many reasons an organization might want to manually specify the internal and

external sign-in server for clients. For example:

The organization has not used a split-brain DNS configuration, and instead of

creating SRV records for internal servers, they want to use manual configuration to

specify the server for user sign-in.

The organization has multiple SIP domains, and instead of creating multiple DNS SRV

records, they want to use Group Policy to manually specify the sign-in server.



16/33

The organization has a single SIP domain but it has several large sites, each with its

own server, and they do not want users to be dependent on one site for sign-in.

There are two ways to manually configure the server that clients should sign into. You canuse Group Policy to assign server values to groups of users, or the settings can be specified

in the Advanced Connection Settings from within Lync or Lync Attendant. Group Policy

settings take precedence over options configured in the client.Manually configured server values can be stored in the following registry locations:

HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient

HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator

If one of these registry locations has a ConfigurationMode DWORD key with a value of 1, the

client checks the accompanying ServerAddressInternal and ServerAddressExternal keys, asshown in Figure 4.

Figure 4. Manual configuration registry values

The client tries to contact the internal server first. If there is no response, the client tries toreach the ServerAddressExternal server. If none of the servers can be reached, sign in fails.

If the ConfigurationMode value is set to 0, automatic discovery will take place. The nextsection outlines the discovery feature of Lync 2010 and Lync 2010 Attendant.

Server Settings versus Group Policy

Application layer settings that were previously controlled through Group Policy have moved

into the Lync Server shared Central Management store database. This change was made sothat clients could receive these settings through in-band provisioning. Because the settings

are applied to the client and not to the computer registry or WMI (as with GPO), settings

are easily reversed or removed.

The use of Group Policy, however, is not completely deprecated. One reason you mightwant to use Group Policy instead of server settings is that Group Policy can be based on a

computer and not a user. For example, an organization might want to prevent applicationsharing on computers that are located in a public area. Another reason to use Group Policy

is when you want to control client behavior before the client signs into a server. Before youremove any group policies because the settings have moved in-band, you should consider

the effect on Lync Server clients.

Group Policy settings are used in Lync Server 2010 to control client behavior prior to sign in.

For example, if the SIP domain is not configured on the internal DNS servers, or if you want



17/33

specific clients to connect to a given pool, the DNS records used for automatic sign in maynot be suitable for your needs. In this case, you can use the Group Policy Object (GPO)

setting ServerAddressInternal to define the internal Registrar Server for internal clients.

In some cases, organizations that have an existing Office Communications Server

deployment and that require a TLS connection between clients and servers may havealready set the group policy for SIP Security Mode. The SIP Security Mode setting is used

during the bootstrapping process to specify whether TLS is required. Even though thesetting is in-band, you should retain the SIP Security Mode group policy because it is still

used during bootstrapping, before the client is able to receive settings through in-bandprovisioning. Maintaining the SIP Security Mode policy helps retain security during the

bootstrapping process.

Also consider the effect on legacy clients. If you have legacy (prior to Lync 2010) clients,

the Central Management store settings and the client policy settings that are applied eitherthrough the Lync Server Control Panel or Windows PowerShell cmdlets are not reflected in

legacy clients. These clients must still be managed by Group Policy. The legacyCommunicator.adm file is available with the client media in the Support folder. Import

the .adm into your environment using the Group Policy Object Editor as you would for anyother Group Policy administrative template.

Policies configured on the server take precedence over Group Policy settings and client

options configured by the user.

How Clients Receive In-band Provisioning Information

Settings that you configure through the Lync Server Control Panel or through cmdlets can

apply to any Lync Server 2010 client or device regardless of membership or location. Afterthe client signs in, the client receives settings configured in the Lync Server properties

through in-band provisioning. In addition, forced refreshes occur approximately every eighthours.

For example, Lync Server clients receive server locations, security information, and settingsrelated to specific client features during in-band provisioning. Lync Phone Edition devices

receive the list of supported location profiles and pool-level defaults through in-bandprovisioning.

Note. For details about the provisioning groups and settings that are configurable in Lync Server 2010Control Panel or through Lync Server Management Shell cmdlets, see Overview of Client Policies andSettings at http://go.microsoft.com/fwlink/?LinkId=216729.

Unlike Group Policy, which is delivered by using a separate mechanism that is based onWindows and Active Directory Domain Services, in-band provisioning carries settings

within the SIP and does not require a separate communications channel. In-bandprovisioning settings are requested when a client signs in. The client sends a sequence of

messages and the server responds. The following shows the sequence of interactionsbetween the client and the server.

The client first sends a SERVICE request for the location profile settings. The following is anexample of the start-line.

SERVICE sip:[email protected];gruu;opaque=app:locationprofile:get;default SIP/2.0

The server responds with a 200 OK message that contains the location profile settings. The

content type of the response is application/ms-location-profile-definition+xml. The messagebody contains the dialing rule patterns and corresponding translations. An example of a

message body is as follows:



18/33

RC

^0$+15555550199

false

true

The client then sends a SUBSCRIBE request for the Contacts list. The event header in the

SUBSCRIBE message has a value of vnd-microsoft-roaming-contacts. The server respondswith a 200 OK message that contains the Contacts list, the various groups that the users

has created, and contacts who belong to each group. The content type header of theresponse is application/vnd-microsoft-roaming-contacts+xml. The following snippet shows

an example of the response that contains the Contacts list.

A client endpoint also sends a SUBSCRIBE message for various provisioning settings. This

SUBSCRIBE message contains an Event header with a value of vnd-microsoft-provisioning-v2. The Content type of the message is application/vnd-microsoft-roaming-provisioning-

v2+xml.

An example of a SUBSCRIBE message for the roaming provisioning settings is as follows:



19/33

The server responds with a 200 OK message that contains the settings for the requestedprovisioning groups. The content type of the response is application/vnd-microsoft-roaming-

provisioning-v2+xml. The response contains server configuration such as the endpointconfiguration, location policy, and meeting policy provisioning settings, as shown in the

following example:

true

false

30

true

truetrue

AllPhotos

WebSearchOnly

127

true

http://contoso/help/ContosoLyncHelp.htm

300

http://contoso/_vti_bin/search.asmx

http://contoso/searchcenter/Pages/peopleresults.aspx

true

true

false

10

0

http://contoso/pages/feedbackprivacystatement.aspx

http://b43-brb-01/CollectLogs

True



20/33


21/33

Client Version Policy and Updates

In Lync Server 2010, the Client Version Check application has been adapted to use the

updated management tools. Client version policies enable you to specify which previousclients, such as Office Communicator 2007 R2, will be able to log on to your Lync Server

2010 system. If you do not want to allow a particular client to use the system, you cancreate a policy that will prevent users who are using that client from logging on.

Clients are identified by their name, such as Lync 2010, and their designator or user agent.

Table 1 maps client names to user agent identifiers.

Table 1. User agent codes for UC clients

Client Name User Agent

Lync 2010, Office Communicator OC

Lync Web App, Communicator Web Access CWA

Lync 2010 Phone Edition, Office Communicator Phone OCPhone

Communicator Phone Edition Platform CPE

Unified Communications Platform UCCP

Lync 2010 Attendee AOC

Live Meeting Add-In LiveMeetingAddins

Office Live Meeting LMC

Windows Messenger WM

Real-time Communications Client RTC

Some of these clients were part of earlier releases of Communications Server, and may not

be familiar to you if you are managing Communications Server for the first time.

Note. You can also specify clients other than those provided by Microsoft, which your organization haswritten or purchased. To do this, it is important to know the correct user agent string name for the client.

Client version policies are a collection of client version rules. Client version rules are used to

identify a particular client version such as Communicator 2007 R2, and whether the client isto be allowed to log on. When a user attempts to log on to Communications Server, the

client sends a SIP register or invite request to the server. This request includes a headerthat contains detailed information about the client itself, including the clients major version,

minor version, and build number. The service looks at the client version information, andlooks to see if there is a rule that matches. If there is, the service responds with the actions

and other information in the rule. If the action is block, the Communications Server willreturn an error and other information to the client. If the action is allowed, Communications

Server continues to process the register or invite request.

Rules are designed to address clients on a one-to-one basis. Depending on your needs, you

may have one rule for dealing with Lync, a second for handling Lync Phone Edition devices,and a third rule for Microsoft Office Live Meeting. Individual rules can then be bundled

together into client version policies.

Client version policies can be applied at the global scope, the site scope, the service scope

(Registrar service only), or per-user. This gives considerable flexibility in deciding whichclients can be used to access the system.

Example: As a general rule, you might want to prevent users from logging on with OfficeCommunicator, which doesnt support all the features of Lync Server 2010. However, you



22/33

have several users who are exceptions. In this case, create a global policy that has a rulethat blocks Office Communicator, and then create a rule that allows users to log on to Office

Communicator in each of these users client version policies.

The available actions for a client are the following:

Allow The user will be allowed to log on.

Block The user will not be allowed to log on.

Allow with URL The user will be allowed to log on, and a message will be displayed

by the client pointing the user to a URL where the latest version of the client can be

downloaded and installed.

Block with URL The user will not be allowed to log on, but a message will be

displayed by the client pointing the user to a URL where the latest version of the

client can be downloaded and installed.

Note. Not all clients display the message that contains the URL to the user. For example, devices runningLync Phone Edition will not display a message to the user directing them to a URL with the latest versionof the software. This is because device updates operate a little differently. For details see the sectionDevice Updates later in this chapter.

If you specify an action that includes a URL, you must have a web page available with linksto download the updated client. If your organization enables external access, it is

recommended that you provide a way to access this site from inside and outside your

organizations network.

The following actions are provided for Lync and Communicator:

Allow with Upgrade The user will be allowed to log on, and his or her copy of Lync

or Communicator will be upgraded to the latest update from Windows Server Update

Service (WSUS) or Microsoft Update.

Block with Upgrade The user will not be allowed to log on, his or her copy of Lync

or Communicator will be upgraded to the latest update from WSUS or Microsoft

Update.

Note. By default, when the action is allow with upgrade or block with upgrade the client will check to seewhether an update has been downloaded from Microsoft Update. If your organization uses WSUS, you canuse this instead. If you want Communicator to check WSUS instead of Microsoft Update, ensure that theWSUS client is using the WSUS server for updates. For details about WSUS, seehttp://technet.microsoft.com/en-us/wsus/default.aspx.

Choosing Between the Actions

Example1: You have a mixed environment with some Communicator users and some Lyncusers. You want to allow all Communicator users to continue working, but prompt them to

upgrade to Lync. In this case, create a rule that has the Allow with URL action. After

sufficient time for all users to update to Lync, change the action on this rule to Block withURL. Remaining Communicator users will not be able to continue logging on and will berequired to upgrade to Lync to continue using communications features.

Example2: You have WSUS in your environment and you want to use it to update Lync.

Whenever an update is available from Microsoft and its been tested and determined to be

ready to roll out to the organization, make it available to the WSUS server. In this case, therule for updating Lync would use the action Allow with Upgrade. Lync will check for an

update from WSUS, and when one is found will upgrade the users client.



23/33

In addition to rules that you create, Lync Server 2010 ships with some rules. These rulesenforce the known supported client versions that work with Lync Server. Figure 5 shows the

default global client version policy settings as they appear in the Lync Server 2010 ControlPanel.

Figure 5. Default global client version policy settings

Rules are processed by the server in order. When a rule is added to a policy, it is added to

the top of the list, meaning that it will be processed first. After the server finds a rule thatmatches the client and version, it stops processing through the list. For example, consider a

client version policy that has the following rules in the following order:

1. UserAgent=OC, Action=block and upgrade, version=4.0

2. UserAgent=AOC, Action=allow, version=4.0

3. UserAgent=OC, Action=allow, version>=3.5

When a Lync client connects to the server, the first rule is processed and found to match, sothe action Block and upgrade is applied. Although there is a rule at position 3 to allow

Communicator version 3.5 or later to connect, because a match has been found with a rulehigher up the list, this rule is not processed.

As mentioned, client version policies can apply on a global, site, server (Registrar only), andper-user scope. These are processed by using a most specific wins methodology. Rules

are processed in the following order:

1. Per-user policy

2. Server client version policy

3. Site client version policy

4. Global client version policy

It is important to understand this order when you configure updates across your

organization.



24/33

Example: You have a large environment with sites at Redmond, United States; London,England; and Paris, France. You want to block all instances of Communicator, and have all

Lync clients in London and Paris upgrade to the latest update released by Microsoft.Additionally, you want to allow your executives the choice of when to move from

Communicator to Lync. To do this you need the following:

A global policy that has a rule to block Communicator (earlier than version 4.0).

A site policy for the London and Paris sites that has a rule to allow Communicator

(versions 4 or greater) to upgrade.

A per-user policy for each of your executives to allow and upgrade Communicator

(versions 3.0 and later, the release that corresponds with Office Communicator).

When a user at the Paris site connects using Communicator, they will be blocked, as per the

global policy. If they connect using Lync, they will be allowed to log on and will checkMicrosoft Update for a newer version to upgrade to, because the Paris site policy has a rule

for updating Lync. A user at the Redmond site with Lync will be allowed to log on, but Lync

will not check for updates because there is no rule at the Redmond site for this. Anexecutive will be able to connect at any of the sites with Communicator, because their user

policy is more specific than the global policy to block Communicator.

Management Shell Use

To configure client version policy, you can use the Lync Server Control Panel or Lync Server

Management Shell cmdlets. This section provides examples of how to use Lync ServerManagement Shell cmdlets to configure the global client version setting and specific client

version policies.

Note. For details about using the Lync Server Control Panel to manage client versions, see Specify theClient Versions Supported in Your Organization at http://go.microsoft.com/fwlink/?LinkId=219948.

To manage client version configuration in the Management Shell, use one of the following

cmdlets:

New-CsClientVersionConfiguration

Get-CsClientVersionConfiguration

Set-CsClientVersionConfiguration

Remove-CsClientVersionConfiguration

Like the tasks available in the Lync Server Control Panel, the previous cmdlets allow you to

enable or disable client version functionality for a scope or change the default action for thatscope.

By default, client version configuration is available at the global scope. This cannot be

removed or created, but it is possible to change the settings at this scope as shown in the

following example.Set-CsClientVersionConfiguration Identity global DefaultActionAllowWithUrl DefaultUrl https://contoso.com/clients

The previous example changes the default action for the global configuration to

AllowWithUrl, and sets the URL to https://contoso.com/clients. You can also create

ClientVersionConfiguration at the site scope.

For details about managing client version configuration, type the following cmdlet, replacingSet-CsClientVersionConfiguration with the cmdlet that you are interested in.



25/33

Get-help Set-CsClientVersionConfiguration

For some examples that use client version configuration cmdlets, type Get-help, plus the

cmdlet you are interested in, and then examples:

Get-help Set-CsClientVersionConfiguration examples

Note. In addition to the examples here, see Lync Server Management Shell at

http://go.microsoft.com/fwlink/?LinkId=213040.To create a new client version policy, use the cmdlet new-CsClientVersionPolicy. Youmust specify an identity, which is the scope to which the policy will apply. This can be

global, site, service (Registrar only) or a user.

To see the parameters and how to use this cmdlet, type the following into the Lync Server

Management Shell:

Get-Help New-CsClientVersionPolicy Full | More.

A newly created client version policy will contain a list of default rules. You can see these byusing the following cmdlet, which shows how to see the rules for policy created at the

Redmond site:

Get-CsClientVersionPolicyRule Identity site:Redmond

When a rule is created, you must specify an identity, which is the scope plus a uniqueidentity (GUID) for the rule. The easiest way to do this is as follows:

$y=[guid]::NewGuid()

$x=site:Redmond/ + $y.ToString()

New-CsClientVersionPolicyRule Identity $x MajorVersion 4 UserAgent OC Action AllowWithUrl CompareOp LEQ ActionUrl http://www.contoso.com/updates

This creates a new rule for the Redmond site, which will allow all Communicator clients ofversion 4 or earlier to log on, and will provide a URL where an update is available to present

to the end user. Because no position is specified, the rule is added to the top of the list.

If the rule needed to be added lower in the list of rules for that scope, for example, position4, the new rule command would look as follows:

New-CsClientVersionPolicyRule Identity $x MajorVersion 4 UserAgent OC Action AllowWithUrl CompareOp LEQ ActionUrlhttp://www.contoso.com/updates Priority 3

Remember, that the highest priority is position 0 in the list; the fourth priority is positionthree.

To see all client version policy cmdlets, type the following:

Get-Command *CsClientVersionPolicy

To see all client version policy rule cmdlets, type the following:

Get-Command *CsClientVersionPolicyRule

Meeting Join Flow

The meeting join experience lets users click once to join a meeting regardless of whetherthe user has Lync or another UC client installed. When a user clicks a meeting link in a

meeting request, the meeting join page detects whether a Lync Server client is installed onthe users computer. If a client is already installed, the default client opens and joins the

meeting. If a client is not installed, the meeting join page displays options for joining themeeting using alternate clients.



26/33

The following steps describe the process that occurs when a user attempts to join ameeting. In this flow, the administrator has not enabled the optional links for downloading

Lync 2010 Attendee or using a legacy client.

1. The user clicks the HTTPS meeting URL or types the URL in a browser.

2. A web page hosted by the Meeting Join Launcher application opens.

3. The web page performs a detection test to determine whether an existing client has

registered for the Vnd.Microsoft.OCSMeeting MIME type.

a. If Yes, go to step 4.

b. If No, the Meeting Join Launcher starts Lync Web App.

4. The Meeting Join Launcher redirects the browser to a file with MIME type

Vnd.Microsoft.OCSMeeting and extension .ocsmeet. The file name is the meeting

name.

5. The browser opens the native client and passes the file in step 4 to the browser. The

file contains the meeting URL and any other information required to join the meeting.

6. The native client attempts to join the meeting with the available credentials.a. If successful, the user joins the meeting by using the native client. The native

client closes the browser window that was opened initially.

b. If joining fails with the available credentials (for example, in a non-federated

Lync meeting) or if there are no credentials, move to step 7.

7. The native client joins the meeting anonymously.

c. If successful, the user joins the meeting by using the native client. The native

client closes the browser window that was opened initially.

d. If joining fails, the native client displays an error that gives the user the

choice of joining using Lync Web App or retrying and using the same client.

Figure 6 illustrates this process.



27/33

Figure 6. Meeting join flow

For the scenario in which no client is installed, the meeting join page always contains theoption to use Lync Web App. In addition to this option, you can decide whether to show a

link for downloading Lync Attendee or a link for joining by using a legacy Communicator2007 R2 client. Both of these links are disabled by default. If you enable either of these



28/33

additional links, Lync Web App will not start automatically, and the user can choose how tojoin.

You can use the Lync Server Control Panel (the Web Service page in the Security group)

to configure the meeting join page. You can also configure these settings by using the New-

CsWebServiceConfiguration or Set-CsWebServiceConfiguration Lync ServerManagement Shell cmdlets with the ShowDownloadCommunicatorAttendeeLink and

ShowJoinUsingLegacyClientLink parameters.

Troubleshooting ClientsThis section discusses some of the Lync Server 2010 tools that are helpful when

troubleshooting client scenarios.

Client-Side Logging

In Lync and Attendant, client-side logging is turned off by default. You control whether

client-side logging is available by using the EnableEventLogging parameter in the Set-CSClientPolicy or New-CsClientPolicy cmdlet. In Lync and Attendant, two logging

options appear in the user interface:

Turn on logging in Lync

Turn on Windows Event logging for Lync

If you have enabled the EnableEventLogging parameter, the first option is selected and

cannot be deselected by users. These logs are created in the following location on the client:

%userprofile%\tracing\Communicator-uccapi-0.uccapilog

The second option is a user-selected option that writes the following types of errors to the

Windows Logs events on the client, along with detailed troubleshooting information:

Errors that prevent a user from signing in to the server, such as host or domain

name errors, or an invalid certificate.

Diagnostic messages returned by the server, such as version check failures,

problems with sign-in credentials, or errors generated in response to a SIP INVITE

message from the client.

MS-Diagnostics Codes

Lync Server 2010 includes ms-diagnostics headers, which are SIP error code extensions that

contain additional information that might be useful for troubleshooting connection problemsor reporting errors. The diagnostic header contains error codes that enable the client

application to take a predetermined course of action in case of an error. The diagnosticheaders serve two purposes:

Convey diagnostic information to help troubleshoot infrastructure (server) problems,misconfigurations, syntactical problems, and other reasons for a non-successful SIP

response.

Convey actionable error codes to the client, which can then be used by the client to

display appropriate messages to the user.



29/33

Client Sign-in

MS-diagnostic codes are useful for diagnosing many client issues. However, ms-diagnostics

are generated when the SIP protocol is actively in use, which assumes that a connection hasbeen established. Because sign-in and registration failures often occur before connectivity is

established, no ms-diagnostic codes are generated.

The following are common areas in which sign-in can fail, all of which occur before aconnection is established:

Failure to resolve a DNS SRV record. The automatic discovery sign-in process is

unable to locate the target server FQDN based on the users domain.

Failure to resolve a DNS A record. The automatic or manual discovery process is

unable to locate the IP address of a server based on the server FQDN.

Other failures during connection establishment. These can include issues with

certificates, misconfiguration of listening ports on the server, firewall ports that are

not open locally or remotely, IPSEC issues, proxy issues, and so on.

In addition, when a client attempts to sign into a Director but the Director specifies adifferent home pool FQDN, the client receives a 302/303 redirect. This redirect tells the

client to connect to the other FQDN by using SIP. Throughout this process, no ms-diagnosticcodes are generated because a connection has not yet been established.

In-Band Provisioning

If in-band provisioning failures occur, they are most likely the result of a major

misconfiguration that omits important data (such as the external FQDN) from the XMLdocument that is sent from the server to the client. As with sign-in failures, issues with in-

band provisioning will not typically produce ms-diagnostics codes because these scenarioswould not cause SIP errors.

Meeting Join Flow

Failures that occur when a client attempts to join a meeting generally result from one of the

following issues:

The conferencing server is offline or unavailable.

The firewall or load balancer is misconfigured.

There is a failure in the PSTN gateway.

Table 2 lists the possible ms-diagnostic codes that result when the conferencing server is

offline or unavailable.

Table 2. MCU ms-diagnostic codes

3122 The Centralized Conferencing Control Protocol (C3P) request sent to theconferencing server failed.

3097 No conferencing server is available through the MCU factory.

3033 The C3P transaction timed out.

Table 3 lists ms-diagnostic codes can indicate issues such as misconfigured firewalls,misconfigured load balancers, damaged network adapters, IPSEC trust issues, and so on.

These codes can also result from things that are outside the administrators control, forexample home or hotel network connectivity issues, the loss of a wireless signal, satellite

phone connection issues, and so on. If you see high occurrences of these codes, you should



30/33


31/33

As with meeting join failures, voice issues can result from misconfiguration of the firewall orload balancer (see Table 3) or a failure in the PSTN gateway (see Table 4).

If you see a high number of diagnostic codes in the 12000 to 15999 range, examine theFailure Distribution Report, which is provided with the Lync Server 2010 Monitoring Server

Reports. Look for phone numbers that are not being expanded properly, numbers that arenot correctly resolving to users, or outbound routes or policies that have been

misconfigured.

The error IDs and reason values for ms-diagnostic headers are documented in the

Appendix A: Diagnostics Header Error ID and Reason Values section of the [MS-OCER]:Client Error Reporting Protocol Specification at http://go.microsoft.com/fwlink/?

LinkId=144413.

Collect Logs Feature

The EnableDiagnosticsLogsCollection parameter of the CsClientPolicy cmdlet enables the

Collect Logs feature in Lync, which is used in troubleshooting audio, video, or connectivityissues. With this feature enabled, Lync collects and stores logs locally on the users

computer (in the directory %USERPROFILE%\tracing\). You instruct the user to manuallyupload the logs, which you can then send to Microsoft for troubleshooting purposes.

The EnableDiagnosticsLogsCollection is not available by default in the Set-CsClientPolicycmdlet. To add this option and enable log collection, run the following Lync Server Windows

PowerShell commands:

$policy = Get-CsClientPolicy Identity global

$logButton = New-CsClientPolicyEntry -Name EnableDiagnosticsLogsCollection-Value 1

$policy.PolicyEntry.Add($logButton)

Set-CsClientPolicy -Instance $policy

With the Collect Logs feature, the following information is collected:

Lync logs, which contain the users Contacts list and information about previousconversation sessions (but exclude the content of Instant Message conversations)

Audio parameters, such as speech signal level and noise level

Network conditions

Device setup

Operating system version and information

Applications running on the computer such as Microsoft Outlook messaging and

collaboration client and Windows Internet Explorer Internet browser

The user can also choose to send the following information:

A 60-second recording of the latest call

A screenshot of the users desktop

When a user encounters an issue, you can the EnableDiagnosticsLogsCollection in-bandprovisioning setting for the user, and then instruct the user to do the following:



32/33

1. Enable logs in Lync by clicking Tools, clicking Options, clicking General, and then

selecting the Turn on logging in Lync and Turn on Windows Event logging for

Lync check boxes.

2. Sign out and sign back into Lync to activate the Collect Logs feature.

3. After the issue is encountered again, click the Collect Logs button and choosewhether to send a 60-second recording of the latest call and a screenshot of the

desktop.

4. Upload the logs to the location that you specify.

After this process is complete, disable EnableDiagnosticsLogsCollection by settings it to 0.

Then ask the user to sign out and sign back into Lync to remove the Collect Logs button.You should also advise the user to delete the log files and the cab file. Then send the logs to

Microsoft for troubleshooting.

SummaryThis chapter covered methods for managing and troubleshooting Lync Server 2010 clients.Most organizations that deploy Lync Server 2010 also deploy Lync 2010 to their users

desktops. Depending on their needs for additional meeting options and Response Groupscenarios, many organizations must also manage Lync 2010 Attendee, Lync Web App, and

Lync 2010 Attendant. This chapter discussed how to manage the combination of clients inyour organization so that you get the most from each client.

Additional Resources Planning for Devices, http://go.microsoft.com/fwlink/?LinkId=204935

Deploying Lync 2010 Phone Edition, http://go.microsoft.com/fwlink/?LinkId=204936

Lync Web App Supported Platforms, http://go.microsoft.com/fwlink/?LinkId=211720

Lync 2010 Attendant Group Policy, http://go.microsoft.com/fwlink/?LinkId=219947

Planning for Clients and Devices in Lync Server 2010,

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

Overview of Client Policies and Settings, http://go.microsoft.com/fwlink/?

LinkId=216729

Windows Server Update Services, http://go.microsoft.com/fwlink/?LinkId=219950

Deploying Clients and Devices, http://go.microsoft.com/fwlink/?LinkId=205560

Specify the Client Versions Supported in Your Organization,


Lync Server Management Shell, http://go.microsoft.com/fwlink/?LinkId=213040

Appendix A: Diagnostics Header Error ID and Reason Values section of the [MS-

OCER]: Client Error Reporting Protocol Specification,




33/33

Determining DNS Requirements, http://go.microsoft.com/fwlink/?LinkId=219972

Planning for Client Migration, http://go.microsoft.com/fwlink/?LinkId=215405

Understanding the Autodiscover Service, http://go.microsoft.com/fwlink/?

LinkId=217012

Managing the Autodiscover Service, http://go.microsoft.com/fwlink/?LinkId=217016

White Paper: Exchange 2007 Autodiscover Service, http://go.microsoft.com/fwlink/?

LinkId=219949

Configuring DNS SRV records to support Exchange Autodiscover,

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

chapter 03 client administration

Documents