After OCS is deployed and the Office Communicator and Office Live Meeting clients are being rolled out to your users, the next question you will likely have is how do I configure the Communicator client for users so that it is tailored for my environment? This can be a challenging task in an diverse environment.
Practically, there are three administrative options at your disposal:
1) Group Policy: Communicator and Live Meeting client configuration settings are mostly set via client-side registry entries in three places:
- Local Machine Settings (i.e. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator)
- Current User Settings (i.e. HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator)
- Current User Settings share with Live Meeting (i.e. HKCU\Software\Microsoft\Shared\UcClient)
2) Set Registry Entries through a Deployment Script. This is similar to the GPO option, except that one or more of the same settings used in the GPO can be set in a Windows script (usually the same script used to deploy Communicator).
3) In-Band Provisioning: Communicator receives settings from the OCS server (or pool) when the user signs in.
These three options are summarized below.
There is one other way Communicator settings can be set – users can simply change them through the Communicator Options Dialog box. Fortunately for administrators there is the notion of ‘Precedence’ which allows the three options above to take precedence over user settings directly in the client. Most Office Communicator settings configured with a GPO or in-band provisioning will be unavailable to the user in the UI (i.e. those options will be grayed-out).
Here is the exact precedence taken by the various ways that Office Communicator client settings are set:
- Local Machine Policy Registry (HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator)
- Local Current User Policy in the Registry (HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator)
- OCS In-Band Provisioning
- Office Communicator Options Dialog Box
Troubleshooting Note: with Communicator having different configuration sources, it helps to know exactly what settings are in-affect when trying to debug an issue with a particular user. A nifty feature was added to Office Communicator R2 that will show the current configuration of many important settings when it is running. See my previous blog post ‘Great New Office Communicator R2 Troubleshooting Feature’ for more information.
Office Communicator Group Policy
The various Communicator settings that can be set through a GPO can be found here:
Both of these downloads are installer files which ‘install’ (extracts to a directory) an administrative template (.adm file) and a corresponding Excel spreadsheet documenting the settings and the possible values. I have found a few errors in the spreadsheet involving possible values for a couple settings. I will try to publish these at a later date.
The Communicator GPO can then be applied to User or Computer Configuration objects in an AD domain or OU. The choice to tie the GPO to a user or computer has advantages and disadvantages. The user object is generally a good idea because the GPO will apply be applied on any machine the user login’s to. The downside is it will not get applied if the user is using a machine that is not part of the AD domain that it was applied to. The local machine policy will also work, but it will not apply the settings to any other machines (or devices) that the user uses.
For this reason, you might want to consider using a deployment script or in-band provisioning.
Set Registry Entries through a Deployment Script
This option uses a windows script (VBScript, Jscript, or any Windows Script File) to set Communicator registry entries with values that are tailored for the user and the environment. The script will typically exist on a common network share and users (or Administrators) will manually run the script, or it will be attached to a Windows user logon script.
One advantage of this approach is that the same script can double as a software deployment script if there are not good existing mechanisms to deploy the client software. The script will typically run the client installer (i.e. *.msi) files that exist on a common network share.
Another advantage of this method is flexibility and customization. For example the user’s SIP address can be configured by setting the registry value in “HKCU\Software\Microsoft\Shared\UcClient\ServerSipUri”. Within the script you can do things like do any AD lookup to populate the users’ SIP address with same format as their email address in AD.
The “Microsoft Office Communications Server 2007 R2 Resource Kit” contains a sample installation script that can be customized to a particular environment. I hope to release an advanced Office Communicator, Office Live Meeting, and Outlook Conferencing Add-In deployment script shortly that I have been working on for some time which has many more features and offers a better experience for Vista and Windows 7.
There are a limited number of settings you can set through this mechanism. Most settings are geared towards ensuring a consistent user experience regardless of the endpoint (or device) that a user signs in with.
Rather than repeat the settings here, this Microsoft TechNet article on ‘In-Band Provisioning over SIP’ does a great job detailing the settings, and where to find them in the OCS Management Console.
Arguably the three most significant, and often used, settings are the URLs for the Address Book, the A/V Edge Server (which tells the client what server to use as a Media Relay (aka “MRAS Server”), and the Global Meeting Policy.
Also note that the in-band provisioning settings can be set programmatically using three WMI classes: MSFT_SIPClientPortSettings, MSFT_SIPCommunicatorConfigSettings, the MSFT_SIPUCPhoneConfigSetting. My previous blog entry ‘OCS WMI Reference’ gives more information on using the WMI classes to administer OCS.