Modifies an existing 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. If you do not wish to allow a particular client to use the system then you can create a policy that will prevent people using that client from logging on.
Syntax
Set-CsClientVersionPolicy [-Identity <XdsIdentity>] [-Confirm [<SwitchParameter>]] [-Description <String>] [-Force <SwitchParameter>] [-Rules <PSListModifier>] [-WhatIf [<SwitchParameter>]] |
Set-CsClientVersionPolicy [-Confirm [<SwitchParameter>]] [-Description <String>] [-Force <SwitchParameter>] [-Instance <PSObject>] [-Rules <PSListModifier>] [-WhatIf [<SwitchParameter>]] |
Parameters
Parameter | Required | Type | Description |
---|---|---|---|
Identity |
Optional |
Xds Identity |
Unique identifier for the policy to be modified. To modify the global policy, use this syntax: -Identity global. To modify a policy configured at the site scope use syntax similar to this: -Identity "site:Redmond". To modify 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 modify 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". If this parameter is not included then all the client version policies configured for use in your organization will be returned. |
Instance |
Optional |
ClientVersionPolicy object |
Allows you to pass a reference to an object to the cmdlet rather than set individual parameter values. |
Rules |
Optional |
PS List Modifier |
Collection of individual client policy rules that have been assigned to the policy. |
Description |
Optional |
String |
|
Force |
Optional |
Switch Parameter |
|
WhatIf |
Optional |
Switch Parameter |
Describes what would happen if you executed the command without actually executing the command. |
Confirm |
Optional |
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.
Client version policies can be modified at any time; modifying a client version policy simply means adding new rules, deleting existing rules, or modifying the properties of an existing rule (for example, changing a rule action from Allow to Block). These changes can be made using the Set-CsClientVersionPolicy cmdlet; however, you will likely find it easier to make these changes by directly modifying the rule itself. For example, if you delete a rule that belongs to a given site policy then that rule will automatically be deleted from the policy. That’s typically far easier than using the PS list modifier methods (for example, @{Add=}) required to manipulate rules using Set-CsClientVersionPolicy.
However, Set-CsClientVersionPolicy does provide a way for you to easily copy an entire set of rules from one client version policy to another. See the Examples section for more information.
Return Types
Set-CsClientVersionPolicy does not return a value or object. Instead, the cmdlet configures instances of the Microsoft.Rtc.Management.WritableConfig.Policy.ClientVersion.ClientVersionPolicy object.
Examples
-------------------------- Example 1 --------------------------
Copy Code | |
---|---|
Set-CsClientVersionPolicy -Identity site:Redmond -Rules $Null $x = Get-CsClientVersionPolicy -Identity site:Dublin | Select-Object -ExpandProperty Rules Set-CsClientVersionPolicy -Identity site:Redmond -Rules $x |
The commands shown in Example 1 copy all the client version rules from one client version policy to another. To do this, the first command in the example uses Set-CsClientVersionPolicy to remove all the rules from the policy site:Redmond; this is done by setting the value of the Rules property to null ($Null). After the rules have been deleted, the second command in the example uses Get-CsClientVersionPolicy to retrieve all the client version policy rules configured for the site:Dublin policy. These rules are then stored in a variable named $x.
In the final command, Set-CsClientVersionPolicy is invoked again, this time setting the Rules property of the policy site:Redmond to $x. This effectively copies all the rules from the site:Dublin policy and adds them to the site:Redmond policy.