Parameters

Client version policy rules are used to determine which client applications are allowed to log on to Lync Server 2010. When a user attempts to log on to Lync Server 2010, 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 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 by using Microsoft Office Communicator 2007 R2. Before the user can log on to Lync Server 2010, the system will check to see if there is a client version rule that applies to Office Communicator 2007 R2. If a rule exists, Lync Server 2010 will then take the action specified by the rule. That action must be one of the following:

Allow. The user will be allowed to log on.

AllowAndUpgrade. The user will be allowed to log on, and his or her copy of Communicator 2007 R2 will automatically be upgraded to the latest version of Lync. Upgrades are carried out using either Microsoft Update or Windows Server Update Services, depending on how you have configured your system.

AllowWithUrl. The user will be allowed to log on, and a message will be displayed pointing the user to a URL where the latest version of Lync can be downloaded and installed. The URL must point to a website that you have created yourself; no such site is created for you when you install Lync Server.

Block. The user will not be allowed to log on.

BlockAndUpgrade. The user will not be allowed to log on, but his or her copy of Communicator 2007 R2 will automatically be upgraded to the latest version of Lync. The user can then try to log on by using the new client application. Upgrades are carried out using either Microsoft Update or Windows Server Update Services, depending on how you have configured your system.

BlockWithUrl. The user will not be allowed to log on, but a message will be displayed pointing him or her to a URL where the latest version of Lync can be downloaded and installed. The URL must point to a website that you have created yourself; no such site is created for you when you install Lync Server.

Client version policy rules are collected in client version policies, policies that can be configured at the global scope, the site scope, the service scope (Registrar service), or the per-user scope. New client version rules are created by using the New-CsClientVersionPolicyRule cmdlet. When you create a new rule you must also specify the Identity for that rule; that Identity consists of a scope (for example, site:Redmond) and a globally unique identifier (GUID). You can either put together an Identity yourself, or provide the scope (the Parent parameter) and the GUID (the RuleId parameter) to have New-CsClientVerisonPolicyRule create the Identity for you.

It’s important to note that client version policies do not apply to federated users; instead, federated users are bound by the client version policies used in their own organization. For example, suppose a federated user uses client A, a client allowed by the federated organization. As long as the federated organization allows the use of client A, this user will be able to communicate with your organization using that client. This will be true even if your client version policy blocks the use of client A. Client version policies enforced in your organization do not override the client version policies used in a federated organization.

Who can run this cmdlet: By default, members of the following groups are authorized to run the New-CsClientVersionPolicyRule cmdlet locally: RTCUniversalServerAdmins. To return a list of all the role-based access control (RBAC) roles this cmdlet has been assigned to (including any custom RBAC roles you have created yourself), run the following command from the Windows PowerShell prompt:

Get-CsAdminRole | Where-Object {$_.Cmdlets –match "New-CsClientVersionPolicyRule"}

None. New-CsClientVersionPolicyRule does not accept pipelined input.

New-CsClientVersionPolicyRule creates new instances of Microsoft.Rtc.Management.WritableConfig.Policy.ClientVersion.Rule object.

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

	Copy Code
$x = [guid]::NewGuid() New-CsClientVersionPolicyRule -Parent "site:Redmond" -RuleId $x -MajorVersion 4 -UserAgent InHouse

Example 1 demonstrates how you can create a new client version policy rule. Policy rules have Identities that are composed of two parts: the scope where the announcement is to be assigned, and a 36-character GUID. Creating an Identity for a new client version policy rule first requires you to use the .NET Framework method NewGuid to create a new GUID. This step is carried out in the first command in the example, with the resulting GUID being stored in the variable $x.

After the GUID has been created, you can then use New-CsClientVersionPolicyRule to create the new rule. This command uses four parameters: Parent, with a parameter value representing the scope (site:Redmond) for the new rule; RuleId, with the parameter value $x (representing the newly-created GUID); MajorVersion (4); and UserAgent (InHouse). In this case, the UserAgent parameter represents an in-house client application.

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

	Copy Code
$x = [guid]::NewGuid() $z = New-CsClientVersionPolicyRule -Parent "site:Redmond" -RuleId $x -InMemory $z.MajorVersion = 4 $z.UserAgent = "Inhouse" Set-CsClientVersionPolicyRule -Instance $z

The commands shown in Example 2 represent a variation of the command shown in Example 1: in this case, however, the new rule is initially created in memory only, and only later added to Lync Server 2010. To carry out this task, the first command in the example creates the GUID portion of the Identity. In command 2, a new in-memory-only client version policy rule is created; the InMemory parameter ensures that the rule exists only in memory and is not immediately added to the Lync Server 2010 infrastructure. As in Example 1, the Parent and RuleId parameters are used to specify the scope and GUID for the new rule, the two pieces that make up the rule Identity.

After the virtual rule has been created, the next two commands are used to assign values to the MajorVersion and UserAgent properties, respectively. When those tasks are complete, the final command in the example and the Set-CsClientVersionPolicyRule cmdlet is used to create the actual client version policy rule and assign the rule to the Redmond site.

Other Resources