Beruflich Dokumente
Kultur Dokumente
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.
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 nexthop@microsoft.com. 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.
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
Page 4
Table of Contents
Client Administration ................................................................................................. 6 Internals for Client Administration............................................................................13 Troubleshooting Clients............................................................................................ 28 Summary.................................................................................................................. 32 Additional Resources................................................................................................ 32
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.
Page 6
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 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.
Page 7
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.
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
Page 8
Management Shell to configure the meeting join page. For details about how the meeting join page determines the options available for joining the meeting, see the section Meeting Join Flow later in this chapter.
Page 9
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.
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 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.
Page 10
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.
Page 11
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.
Page 12
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.
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: kim@contoso.com along with the user account and password for CONTOSO\vadim instead of the user account and password for CONTOSO\kim, sign-in will fail.
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.
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.
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.
Page 16
specific clients to connect to a given pool, the DNS records used for automatic sign in may 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.
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:amst@litwareinc.com;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:
Page 17
<LocationProfileDescription xmlns="http://schemas.contoso.com/2007/03/locationProfileDescription"> <Name>RC</Name> <Rule> <Pattern>^0$</Pattern> <Translation>+15555550199</Translation> <InternalEnterpriseExtension>false</InternalEnterpriseExtension> <OptimizeDeviceDialing>true</OptimizeDeviceDialing> </Rule> </LocationProfileDescription> 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. <contactList deltaNum="316" > <group id="1" name="~" externalURI="" /> <group id="2" name="Northwest Region" externalURI="" /> <group id="3" name="Pinned Contacts" externalURI="<groupExtension groupType="pinnedGroup"><email/></groupExtension>" /> <group id="4" name="My Team" externalURI="" /> <contact uri="matej.potokar@contoso.com" name="" groups="1" subscribed="true" externalURI="" > <contactExtension><contactSettings></contactSettings></contactExtension> </contact> <contact uri="manjinder.kaur@contoso.com" name="" groups="1 4" subscribed="true" externalURI="" /> <contact uri="alex.darrow@contoso.com" name="" groups="1" subscribed="true" externalURI="" /> <contact uri="kari.hensien@contoso.com" name="" groups="1 2" subscribed="true" externalURI="" > <contactExtension><contactSettings></contactSettings></contactExtension> </contact> </contactList> 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:
Page 18
<provisioningGroupList xmlns="http://schemas.contoso.com/2006/09/sip/provisioninggrouplist" subnet="192.168.1.0"> <provisioningGroup name="endpointConfiguration"/> <provisioningGroup name="locationPolicy"/> <provisioningGroup name="mediaConfiguration"/> <provisioningGroup name="meetingPolicy"/> <provisioningGroup name="presencePolicyV2"/> <provisioningGroup name="privacyPublicationGrammar"/> <provisioningGroup name="publicationGrammar"/> <provisioningGroup name="ServerConfiguration"/><provisioningGroup name="ucPhoneSettings"/> <provisioningGroup name="ucPolicy"/> <provisioningGroup name="userSetting"/> </provisioningGroupList> 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: <provisionGroupList xmlns="http://schemas.contoso.com/2006/09/sip/provisiongrouplistnotification"> <provisionGroup name="endpointConfiguration" > <propertyEntryList > <property name="ShowRecentContacts" >true</property> <property name="ShowManagePrivacyRelationships" >false</property> <property name="MaxPhotoSizeKB" >30</property> <property name="DisableMusicOnHold" >true</property> <property name="EnableSQMData" >true</property> <property name="EnableURL" >true</property> <property name="PhotoUsage" >AllPhotos</property> <property name="AbsUsage" >WebSearchOnly</property> <property name="SearchPrefixFlags" >127</property> <property name="EnableEnterpriseCustomizedHelp" >true</property> <property name="CustomizedHelpUrl" >http://contoso/help/ContosoLyncHelp.htm</property> <property name="HotdeskingTimeout" >300</property> <property name="SPSearchInternalUrl" >http://contoso/_vti_bin/search.asmx</property> <property name="SPSearchCenterInternalUrl" >http://contoso/searchcenter/Pages/peopleresults.aspx</property> <property name="EnableContactSync" >true</property> <property name="ShowSharepointPhotoEditLink" >true</property> <property name="EnableVOIPCallDefault" >false</property> <property name="MaximumDGsAllowedInContactList" >10</property> <property name="P2PAppSharingEncryption" >0</property> <property name="PrivacyStatementURL" >http://contoso/pages/feedbackprivacystatement.aspx</property> <property name="OnlineFeedbackURL" >http://b43-brb-01/CollectLogs</property> <property name="ShowAliasOnContactCard" >True</property>
Page 19
<property name="SearchPrefixFlags" >7f</property> </propertyEntryList> </provisionGroup> <provisionGroup name="locationPolicy" > <propertyEntryList > <property name="EnhancedEmergencyServicesEnabled" >false</property> <property name="LocationPolicyTagID" >user-tagid</property> <property name="UseLocationForE911Only" >true</property> <property name="EmergencyDialString" >911</property> <property name="ConferenceMode" >twoway</property> </propertyEntryList> </provisionGroup> <provisionGroup name="mediaConfiguration" > <propertyEntryList > <property name="bypassEnabled" >true</property> <property name="internalBypassMode" >Any</property> <property name="externalBypassMode" >Off</property> </propertyEntryList> </provisionGroup> <provisionGroup name="meetingPolicy" > <instance > <property name="AllowIPAudio" >true</property> <property name="AllowIPVideo" >true</property> <property name="EnableAppDesktopSharing" >true</property> <property name="AllowAppSharingForExternalMeeting" >Desktop</property> <property name="RetainPPTForExternalMeeting" >true</property> <property name="AllowPresenterToRecord" >true</property> <property name="EnableDataCollaboration" >true</property> <property name="MeetingSize" >250</property> <property name="EnablePSTNConferencing" >true</property> <property name="TrustedConferencingPinRequired" >false</property> <property name="AllowParticipantControl" >true</property> <property name="AllowAnnotations" >true</property> <property name="AllowAnonymousParticipants" >true</property> <property name="AllowExternalUserControl" >true</property> <property name="AllowExternalUsersToSaveContent" >true</property> <property name="AllowExternalUserRecording" >false</property> <property name="AllowPolls" >true</property> <property name="AllowRecording" >true</property> <property name="EnableP2PRecording" >false</property> <property name="AllowFileTransfer" >true</property> <property name="MaxConferenceVideoResolution" >VGA</property> <property name="AllowUserToScheduleMeetingsWithAppSharing" >true</property> <property name="EnableP2PFileTransfer" >true</property> <property name="AllowedAppDesktopSharingLevel" >Desktop</property> <property name="AudioBitRate" >200</property> <property name="VideoBitRate" >50000</property> <property name="AppSharingBitRate" >50000</property> <property name="FileTransferBitRate" >50000</property> <property name="EnableP2PVideo" >true</property> </instance>
Page 20
</provisionGroup>
Client Name
Lync 2010, Office Communicator Lync Web App, Communicator Web Access Lync 2010 Phone Edition, Office Communicator Phone Communicator Phone Edition Platform Unified Communications Platform Lync 2010 Attendee Live Meeting Add-In Office Live Meeting Windows Messenger Real-time Communications Client
User Agent
OC CWA OCPhone CPE UCCP AOC LiveMeetingAddins LMC 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 clients 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 doesnt support all the features of Lync Server 2010. However, you
Page 21
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. 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 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 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.
Page 22
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.
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. 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.
Page 23
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 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.
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.
Page 24
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. 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
Page 25
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. 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.
Page 26
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
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.
Page 28
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 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 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 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.
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 3033 The Centralized Conferencing Control Protocol (C3P) request sent to the conferencing server failed. No conferencing server is available through the MCU factory. 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, 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
Page 29
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.
Table 3. Media connectivity ms-diagnostic codes 20-29 Call failed to establish due to a media connectivity failure where one endpoint is <internal/external/remote>. (Signaling with SIP allowed the endpoints to connect to each other but a media stream could not be established.) Call ended on a mid-call media failure where one endpoint is <internal/external/unknown>. (Media was established and then later dropped.) Call ended on media timeout. (Legacy version of diagnostics 30-39, which now give more context of user location - internal/external/federated/unknown(legacy).) 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. No conferencing server is available through the MCU factory. The C3P transaction timed out. User/number not found. This is a normal failure that is usually categorized as expected. 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. 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 12001 15030 15003 15004 15007 14005 13xxx 12xxx 15xxx 14xxx Multiple users associated with the target phone number User Policy does not contain phone route usage Failed to route to Exchange Server The specified Exchange Unified Messaging dial plan is unknown Exchange Unified Messaging dial plan has no servers Exchange Unified Messaging server did not respond to request Could not find profile in internal lookup Inbound routing of VoIP to VoIP calls Outbound routing (VoIP to PSTN calls) Exchange UM Translation Service (expands phone numbers from 5-digit dialing to E.164 numbers)
Page 30
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). 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.
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-band provisioning setting for the user, and then instruct the user to do the following:
Page 31
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. 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
Page 32
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
Page 33