This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. Copyright © 2011 Microsoft Corporation. All rights reserved. Microsoft, Internet Explorer, Lync, Outlook, PowerShell, Silverlight, and Windows are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Microsoft Lync Server 2010 Client Administration

Page 2

This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently being 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 at http://go.microsoft.com/fwlink/?LinkId=204593.

Microsoft Lync Server 2010 Client Administration

Page 3

Contributors Project 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, Stefan Plizga, Jeffrey Reed, Nick Smith, Stephen Wong, Rob Young Lead Editor: Janet Lowen Art Manager: Jim Bradley Production Editor: Kelly Fuller Blue

Microsoft Lync Server 2010 Client Administration

Page 4

Table of Contents Client Administration .......................................................................................................................................... 6 Internals for Client Administration...................................................................................................................13 Troubleshooting Clients ....................................................................................................................................28 Summary ............................................................................................................................................................32 Additional Resources.........................................................................................................................................32

Microsoft Lync Server 2010 Client Administration

Page 5

Client Administration Microsoft® Lync™ Server 2010 introduces updated and enhanced tools for managing servers 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 manage servers. 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 Server Management 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 or traveling enterprise member), the federated partner, and the occasional user who rarely connects to your infrastructure. In addition, the Microsoft Lync 2010 Attendant combines with 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 nonenterprise attendees that installs on client computers. Microsoft Lync Web App, the web-based, meeting-only client for enterprise and nonenterprise 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, and country/regional needs. Note. This chapter focuses on Lync Server 2010 computer-based clients. For detailed information about using Microsoft Lync 2010 Phone Edition and devices, see Planning for Devices, available at http://go.microsoft.com/fwlink/?LinkId=204935, and Deploying Lync 2010 Phone Edition, available at http://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 propagate policies 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, to be sent to clients that are not joined to the domain in addition to Lync Phone Edition devices. For endpoints such as Lync, an advantage of using in-band provisioning is that information critical 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 the organization because the settings apply to all clients that sign in to the server pool. Most of the settings that determine client features and functionality are configurable through the Lync Server Control Panel or Lync Server Management Shell. These settings are then passed along to clients though in-band provisioning. However, cases remain for which

Microsoft Lync Server 2010 Client Administration

Page 6

Group Policy is required. Specifically, you must use Group Policy to set client bootstrapping policies that take effect before the client signs in to the server and receives in-band provisioning settings. For example, if you want to specify the server that a client should use during the sign-in process, you have to configure a Group Policy setting so that the server information exists on the client before the client signs into Lync Server. The section “Server Settings versus Group Policy” later in this chapter discusses when to use Group Policy.

Automatic Discovery During Sign-in When connection settings are set to Automatic Configuration, Lync 2010 and Lync 2010 Attendant use automatic discovery during sign-in to locate the Registrar server. The client uses a sequence of DNS and DHCP information to find the Registrar server. If the DNS and DHCP settings are not configured correctly, the client cannot sign in automatically. As in previous versions of Microsoft Office Communications Server, in Lync Server 2010 you can still use Group Policy to specify the sign-in server that a client should use. However, Group Policy takes effect only for clients that are joined to the domain. For the mobile user who signs into the domain network infrequently, a change in Front End Server will prevent the user from signing in. In situations like these, it is essential to ensure that DNS and DHCP are configured correctly to enable automatic discovery. For details about configuring the client sign-in process, see the section “Lync Client Sign-in Process” later in this chapter. Lync 2010 also uses the Autodiscover service of the Client Access server in Microsoft Exchange Server 2010 for Exchange Unified Messaging (UM) features, such as missed call logs, call history, and voice mail preview. The Exchange Autodiscover service must be configured properly for these features to be available in Lync 2010. For details about how Lync clients interoperate with Exchange, see the section “Exchange Web Services and Autodiscover Service” later in this chapter.

Managing Lync Versions In Lync Server 2010, you can use the enhanced Client Version Check application to filter by client version and specify the action the server should take when certain client versions attempt to sign in. Among the options you can specify for Lync 2010 clients is the new Block and Upgrade option, which automatically updates clients by using Windows Server Update Service (WSUS) or Microsoft Update. Because WSUS and Microsoft Update are more scalable solutions, this option helps to simplify client version management in small and large deployments. The auto-update feature that was provided in Microsoft Office Communications Server 2007 R2, in which the client polled the auto-update service to determine if an update was available, is not included in Lync Server 2010.

Managing Lync Attendee Attendee is a downloadable client that allows anonymous users or users with enterprise credentials to participate in meetings when they do not have Lync 2010 or Lync Attendant installed. This client is particularly useful when a meeting organizer wants to include external users and partners in a meeting. Attendee is also an essential client for users who have not yet moved to Lync Server 2010 during migration from a previous version of Office Communications Server. Lync Attendee does not receive in-band provisioning settings from the server. Management of Attendee clients generally consists of the following: 

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

Microsoft Lync Server 2010 Client Administration

Page 7



Determining whether or not you want to present Attendee as an option to users when they join Lync meetings.

Meeting Join Page When 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 user’s 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 (the page that prompts the user to join the meeting) displays options for joining the meeting by using alternate clients. The meeting join page always contains the option 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 Communicator 2007 R2 client. Both of these links are disabled by default. 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 Management Shell to configure the meeting join page. For details about how the meeting

Microsoft Lync Server 2010 Client Administration

Page 8

join 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 runs on the operating system and browser combinations listed at http://go.microsoft.com/fwlink/?LinkId=211720. Users who do not have Lync, Lync Attendant, 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 is required 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 or partners 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 Office Communications Server 2007 R2. However, Lync Web App is a meeting client only, and it does not support presence, contacts, or audio/video capabilities. Deployment and maintenance 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 high volumes 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 describes the 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-band provisioning. However, there are Group Policy settings you can configure to control the behavior of Attendant clients. Note. For details about Group Policy settings for Attendant, see Lync 2010 Attendant Group Policy at http://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 for the caller. The following scenarios are recommended in a standard receptionist deployment and are discussed in the following sections in more detail:     

Response Group application Sorting search results by last name Reporting a malicious call Parking a call Location services for Enhanced 9-1-1 (E9-1-1)

Microsoft Lync Server 2010 Client Administration

Page 9

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 reach the receptionist. This allows for features such as additional screening, call waiting music, and fallback queues—all of which are designed to make the experience more pleasant for the caller, which makes the receptionist’s job easier. Note. For details about deployment and setup of the Response Group application, see the chapter titled “Response Group Application.”

There are three recommended ways to deploy the Response Group application with the receptionist. 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 discuss two 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 fairly straightforward, 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 strongly recommended 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 receptionist’s 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. 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.

Microsoft Lync Server 2010 Client Administration

Page 10

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 group so 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 having to 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 physical number 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.

Microsoft Lync Server 2010 Client Administration

Page 11

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 main line 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 and enables receptionists to switch shifts seamlessly.

Attendant Routing An important new Lync Server 2010 response group feature designed specifically for the Attendant 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. This feature 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, with caller 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 benefit from 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 to whom to transfer a call by searching for the last name and then looking for that same value, as would be natural in this scenario.

Microsoft Lync Server 2010 Client Administration

Page 12

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. With Lync 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 to follow up on as appropriate. Note. For details about how to identify malicious call in the database, see the chapter titled “Enterprise Voice.” 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 be retrieved. 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 the receptionist through in-band provisioning. Note. We recommend that you configure the paging system as a contact. This allows the receptionist to easily call that system to announce the orbit. Note. For details about configuring the Call Park application on the server, see the chapter titled “Enterprise Voice.”

Location Services for E9-1-1 A receptionist is often expected to report emergencies. In Lync Server 2010, the receptionist 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 verify their 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 “Enterprise Voice.”

Internals for Client Administration In the following sections, you will find in-depth information about managing the client experience, updating clients as needed, and configuring policies based on your administrative, compliance, and country/regional needs.

Lync Client Sign-in Process During sign–in, Lync or the Lync Attendant determines the server it should sign into by using the user’s SIP URI and any manual settings configured on the client. If the ConfigurationMode, ServerAddressInternal, and ServerAddressExternal values exist in the client computer registry, the client uses the specified server settings. For details, see “Understanding Manual Configuration” later in this chapter. However, if these settings do not 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 “Understanding Automatic 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

Microsoft Lync Server 2010 Client Administration

Page 13

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 setting is still available, allowing you to configure Lync clients to use TCP, we strongly recommend that you do not do this in production environments.

Next, the client sends a SIP REGISTER message to the server without any credentials. This action 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 the credentials 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 desktop credentials 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 credentials entered 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 will fail.

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 is connecting 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 Standard Edition) 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 internally and 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 user’s SIP sign-in address. 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 Server—which can be either a Director or a Registrar pool—and connects directly to it. To ensure that internal clients can sign in, make sure this internal DNS SRV record is published in the internal 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 external port (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: Other Possibilities.”) 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 user’s home pool, the SIP messaging is proxied to the user’s home pool and the client signs in. As with internal records, you could

Microsoft Lync Server 2010 Client Administration

Page 14

also publish multiple records externally with the same name but with different hosts and priorities. 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 Lync Server 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 provisioning service. If DHCP is not configured the client uses the following queries to look up the host records directly: 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 the Active Directory domain), configure the _sip._tls.contoso.com record to resolve to sip.contoso.com for both internal and external queries. They use A records to direct clients further by configuring the A records with a different IP address internally and externally. The internal IP address specifies the address 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 to sign in from outside the network. This happens when the client finds the _sipinternal SRV record and the A record, and then is forced to wait for a TCP timeout before it tries the _sip SRV record. This is a case 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. For example, they might configure _sipinternal to point to sip.contoso.com, which resolves to an internal Director. In addition, they configure _sip to resolve to pool1.contoso.com, which is often in different data 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.

Microsoft Lync Server 2010 Client Administration

Page 15



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 can use 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, as shown 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 to reach 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 next section 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 so that 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 might want 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 application sharing 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 you remove 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 specific clients to connect to a given pool, the DNS records used for automatic sign in may

Microsoft Lync Server 2010 Client Administration

Page 16

not 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 have already 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 the setting 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-band provisioning. 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 either through 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 legacy Communicator.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 any other 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. After the client signs in, the client receives settings configured in the Lync Server properties through in-band provisioning. In addition, forced refreshes occur approximately every eight hours. For example, Lync Server clients receive server locations, security information, and settings related 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-band provisioning. Note. For details about the provisioning groups and settings that are configurable in Lync Server 2010 Control Panel or through Lync Server Management Shell cmdlets, see Overview of Client Policies and Settings at http://go.microsoft.com/fwlink/?LinkId=216729.

Unlike Group Policy, which is delivered by using a separate mechanism that is based on Windows and Active Directory® Domain Services, in-band provisioning carries settings within the SIP and does not require a separate communications channel. In-band provisioning 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 interactions between the client and the server. The client first sends a SERVICE request for the location profile settings. The following is an example 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 message body contains the dialing rule patterns and corresponding translations. An example of a message body is as follows:

Microsoft Lync Server 2010 Client Administration

Page 17

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 responds with 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 the response 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-provisioningv2. The Content type of the message is application/vnd-microsoft-roaming-provisioningv2+xml. An example of a SUBSCRIBE message for the roaming provisioning settings is as follows:

Microsoft Lync Server 2010 Client Administration

Page 18

The server responds with a 200 OK message that contains the settings for the requested provisioning groups. The content type of the response is application/vnd-microsoft-roamingprovisioning-v2+xml. The response contains server configuration such as the endpoint configuration, location policy, and meeting policy provisioning settings, as shown in the following example: true false 30 true true true 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 7f

Microsoft Lync Server 2010 Client Administration

Page 19

false user-tagid true 911 twoway true Any Off true true true Desktop true true true 250 true false true true true true true false true true false true VGA true true Desktop 200 50000 50000 50000 true

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 previous clients, such as Office Communicator 2007 R2, will be able to log on to your Lync Server

Microsoft Lync Server 2010 Client Administration

Page 20

2010 system. If you do not want to allow a particular client to use the system, you can create 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 Lync Web App, Communicator Web Access

OC CWA

Lync 2010 Phone Edition, Office Communicator Phone

OCPhone

Communicator Phone Edition Platform

CPE

Unified Communications Platform Lync 2010 Attendee

UCCP AOC

Live Meeting Add-In Office Live Meeting

LiveMeetingAddins LMC

Windows Messenger Real-time Communications Client

WM 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 has written 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 is to 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 header that contains detailed information about the client itself, including the client’s major version, minor version, and build number. The service looks at the client version information, and looks 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 will return 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 which clients can be used to access the system. Example: As a general rule, you might want to prevent users from logging on with Office Communicator, which doesn’t support all the features of Lync Server 2010. However, you have several users who are exceptions. In this case, create a global policy that has a rule that 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.

Microsoft Lync Server 2010 Client Administration

Page 21





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 running Lync Phone Edition will not display a message to the user directing them to a URL with the latest version of the software. This is because device updates operate a little differently. For details see the section “Device Updates” later in this chapter.

If you specify an action that includes a URL, you must have a web page available with links to 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 organization’s 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 see whether an update has been downloaded from Microsoft Update. If your organization uses WSUS, you can use this instead. If you want Communicator to check WSUS instead of Microsoft Update, ensure that the WSUS client is using the WSUS server for updates. For details about WSUS, see http://technet.microsoft.com/en-us/wsus/default.aspx.

Choosing Between the Actions Example1: You have a mixed environment with some Communicator users and some Lync users. 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 with URL. Remaining Communicator users will not be able to continue logging on and will be required 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 it’s been tested and determined to be ready to roll out to the organization, make it available to the WSUS server. In this case, the rule 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 user’s client. In addition to rules that you create, Lync Server 2010 ships with some rules. These rules enforce 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 Control Panel.

Microsoft Lync Server 2010 Client Administration

Page 22

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 that matches 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, so the 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 rule higher up the list, this rule is not processed. As mentioned, client version policies can apply on a global, site, server (Registrar only), and per-user scope. These are processed by using a “most specific wins” methodology. Rules are processed in the following order: 1. 2. 3. 4.

Per-user policy Server client version policy Site client version policy Global client version policy

It is important to understand this order when you configure updates across your organization. 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).

Microsoft Lync Server 2010 Client Administration

Page 23

 

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 check Microsoft 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. An executive 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 Server Management 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 the Client 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 that scope. 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 –DefaultAction “AllowWithUrl” –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, replacing Set-CsClientVersionConfiguration with the cmdlet that you are interested in. 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.

Microsoft Lync Server 2010 Client Administration

Page 24

To create a new client version policy, use the cmdlet new-CsClientVersionPolicy. You must 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 by using 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 unique identity (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 of version 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, position 4, the new rule command would look as follows: New-CsClientVersionPolicyRule –Identity $x –MajorVersion 4 –UserAgent OC – Action AllowWithUrl –CompareOp LEQ –ActionUrl “http://www.contoso.com/updates” –Priority 3 Remember, that the highest priority is position 0 in the list; the fourth priority is position three. 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 whether the 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 on the user’s 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 the meeting using alternate clients. The following steps describe the process that occurs when a user attempts to join a meeting. 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.

Microsoft Lync Server 2010 Client Administration

Page 25

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.

Microsoft Lync Server 2010 Client Administration

Page 26

Figure 6. Meeting join flow

For the scenario in which no client is installed, the meeting join page always contains the option 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 Communicator 2007 R2 client. Both of these links are disabled by default. If you enable either of these

Microsoft Lync Server 2010 Client Administration

Page 27

additional links, Lync Web App will not start automatically, and the user can choose how to join. 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 NewCsWebServiceConfiguration or Set-CsWebServiceConfiguration Lync Server Management Shell cmdlets with the ShowDownloadCommunicatorAttendeeLink and ShowJoinUsingLegacyClientLink parameters.

Troubleshooting Clients This 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 SetCSClientPolicy 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 problems or 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 diagnostic headers 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.

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 has

Microsoft Lync Server 2010 Client Administration

Page 28

been 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 a connection 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 user’s 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 a different 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-diagnostic codes 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 XML document that is sent from the server to the client. As with sign-in failures, issues with inband provisioning will not typically produce ms-diagnostics codes because these scenarios would 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 3097

The Centralized Conferencing Control Protocol (C3P) request sent to the conferencing server failed. 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 administrator’s control, for example 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 look for trends. For example, check if a particular site is generating more instances than other sites. These codes generally indicate that the SIP channel is fine, but the media channels used for application sharing, audio, and video are not set up properly.

Microsoft Lync Server 2010 Client Administration

Page 29

Table 3. Media connectivity ms-diagnostic codes 20-29

Call failed to establish due to a media connectivity failure where one endpoint is . (Signaling with SIP allowed the endpoints to connect to each other but a media stream could not be established.)

30-39

Call ended on a mid-call media failure where one endpoint is . (Media was established and then later dropped.)

52021

Call ended on media timeout. (Legacy version of diagnostics 30-39, which now give more context of user location - internal/external/federated/unknown(legacy).)

52031

Call ended on media connectivity failure. (Legacy version of diagnostics 20-29, which now give more context about user location – internal/external/federated/unknown(legacy).) The media connection with the client was disconnected.

21012

Table 4 lists ms-diagnostic codes can result from failures in the PSTN gateways, although some of these codes are considered normal and expected, as noted. Table 4. PSTN gateway ms-diagnostic codes 10xxx

If the codes are generated by a Lync Server Mediation Server, the diagnostic header will contain the cause code returned by the PSTN gateway. You can use the cause code to look up error information in your gateway documentation.

10404 3033

No conferencing server is available through the MCU factory. The C3P transaction timed out.

10404

User/number not found. This is a normal failure that is usually categorized as “expected.”

10486 10500

User/number busy and does not have call waiting. This is a normal failure that is usually categorized as “expected.” Gateway responded with 500 Server Internal Error.

10503

Gateway responded with 503 Service Unavailable.

Voice Issues Voice issues can result from misconfiguration of the voice route, misdialing, and so on. Table 5 lists the ms-diagnostic codes might be generated in these instances. Table 5. Voice ms-diagnostic codes 4199

Multiple users associated with the target phone number

12001 15030

User Policy does not contain phone route usage Failed to route to Exchange Server

15003 15004

The specified Exchange Unified Messaging dial plan is unknown Exchange Unified Messaging dial plan has no servers

15007 14005

Exchange Unified Messaging server did not respond to request Could not find profile in internal lookup

13xxx 12xxx 15xxx

Inbound routing of VoIP to VoIP calls Outbound routing (VoIP to PSTN calls) Exchange UM

14xxx

Translation Service (expands phone numbers from 5-digit dialing to E.164 numbers)

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

Microsoft Lync Server 2010 Client Administration

Page 30

If you see a high number of diagnostic codes in the 12000 to 15999 range, examine the Failure 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 are not 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 connectivity issues. With this feature enabled, Lync collects and stores logs locally on the user’s computer (in the directory %USERPROFILE%\tracing\). You instruct the user to manually upload the logs, which you can then send to Microsoft for troubleshooting purposes. The EnableDiagnosticsLogsCollection is not available by default in the Set-CsClientPolicy cmdlet. 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 user’s Contacts list and information about previous conversation 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 user’s desktop

When a user encounters an issue, you can the EnableDiagnosticsLogsCollection in-band provisioning setting for the user, and then instruct the user to do the following: 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 choose whether 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.

Microsoft Lync Server 2010 Client Administration

Page 31

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.

Summary This 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 Group scenarios, 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 in your 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, http://go.microsoft.com/fwlink/?LinkId=219948 Lync Server Management Shell, http://go.microsoft.com/fwlink/?LinkId=213040 “Appendix A: Diagnostics Header Error ID and Reason Values” section of the [MSOCER]: Client Error Reporting Protocol Specification, http://go.microsoft.com/fwlink/?LinkId=144413 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

Microsoft Lync Server 2010 Client Administration

Page 32