[This is preliminary documentation and is subject to change. Blank topics are included as placeholders.]

Removes the specified client version policy. (Client version policies enable you to specify which "downlevel "clients (such as Office Communicator 2007 R2) will be able to log onto your Microsoft Communications Server system.) This cmdlet can also be used to remove the global client version policy. In that case, however, the policy will not actually be removed; instead, the policy settings will simply be reset to their default values.


Remove-CsClientVersionPolicy -Identity <XdsIdentity> [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]


Parameter Required Type Description



Xds Identity

Unique identifier for the policy to be returned. To remove a policy configured at the site scope use syntax similar to this: -Identity "site:Redmond". To remove a policy configured at the service scope use syntax like this: -Identity "service:Redmond-Registrar-1". The Registrar service is the only service that can host a client version policy.

Policies can also be configured at the per-user (tag) scope. To remove one of these policies, simply leave off the scope portion of the Identity. For example, the policy tag:SalesDepartmentPolicy would be referenced like this: -Identity "SalesDepartmentPolicy".

You can also use the following syntax to "remove" the global client version policy. In that case, however, the policy will not actually be deleted. Instead, all the policy rules will be reset to their default values.



Switch Parameter



Switch Parameter

Describes what would happen if you executed the command without actually executing the command.



Switch Parameter

Prompts you for confirmation before executing the command.

Detailed Description

Client version policies are nothing more than a collection of client version rule. Client version rules are used to determine which client applications are allowed to log on to Microsoft Communications Server and which client applications are not allowed to log on. When a user attempts to log on to Communications Server, his or her client application sends a SIP header to the server; this header includes detailed information about the application itself, including the software’s major version, minor version, and build number. The version information included in the SIP header is then checked against a collection of client version rules to see if any rules apply to that particular application.

For example, suppose a user attempts to log on using Office Communicator version 2.0. Before logon can take place, the system will check to see if there is a client version rule that applies to Office Communicator 2.0. If such a rule exists, Microsoft Communications Server will then take the action specified by the rule. For example, the rule might tell Communications Server to allow the logon, it tell instruct Communications Server to block, or it might tell Communications Server allow the logon but then silently update the client application to the latest version of Microsoft Communicator. (This latter behavior can occur only if the user is logging on using a specified version of Office Communicator.”

Rules are designed to address client applications on a one-on-one basis: depending on your needs, you might have one rule for dealing with Office Communicator, a second rule for handling Communicator Phone Edition devices, and a third rule for Microsoft Office Live Meeting. Individual rules can then be bundled together in client version policies. These policies – which can be applied at the global scope, the site scope, the service scope (Registrar service only), or the per-user scope – give you considerable flexibility in determining which client applications can be used to access the system. For example, as a general rule you might want to prevent users from logging on using Office Communicator; after all, Office Communicator does not support the same features and capabilities as Microsoft Communicator. However, due to hardware or software conflicts you might also have a select group of users who cannot upgrade to Microsoft Communicator. In that case, you can create a separate rule – and a separate client version policy – that allows those users to log on from within Office Communicator.

You can create new policies for the site, service, or per-user scope by using the New-CsClientVersionPolicy cmdlet. These custom policies can later be removed by running the Remove-CsClientVersionPolicy cmdlet. When you remove a client version policy, users previously governed by that policy will automatically inherit the next policy in the management hierarchy. For example, if you delete a per-user policy, users will automatically be governed by the appropriate service policy. If no service policy exists then users will be governed by the appropriate site policy. If no site policy exists then users will be governed by the global policy.

Note that there will always be a global policy, meaning that no users will be left unmanaged when it comes to client version policies. Although you can run Remove-CsClientVersionPolicy against the global policy, the policy will not actually be deleted. Instead, all the policy rules will be reset to their default values. (That is, the same set of rules and property values that were in the global policy at the time Microsoft Communications Server was first installed.)

Return Types

Remove-CsClientVersionPolicy deletes existing instances of the Microsoft.Rtc.Management.WritableConfig.Policy.ClientVersion.ClientVersionPolicy object.


-------------------------- Example 1 --------------------------

Copy Code
Remove-CsClientVersionPolicy -Identity site:Redmond

The command shown in Example 1 deletes the client version policy for the Redmond site. When a site policy like this is deleted, users in that site will automatically inherit the global client version policy.

-------------------------- Example 2 --------------------------

Copy Code
Get-CsClientVersionPolicy -Filter tag:* | Remove-CsClientVersionPolicy

In Example 2, all the client version policies configured at the per-user scope are deleted. To do this, the command first calls Get-CsClientVersionPolicy and includes the -Filter parameter; the filter value "tag:*" limits the returned data to policies configured at the per-user scope (that is, policies that have an Identity that begins with the characters "tag:"). This filtered collection is then piped to Remove-CsClientVersionPolicy, which deletes each item in that collection.