Assigning Policies

[NextHop_Team]

First published on TECHNET on Jun 06, 2010

So how do you grant (assign) policies? Well, to begin with, it’s important to keep in mind that the only policies that need to be assigned are the per-user policies. When you create a site, service, or global policy those policies are automatically assigned at the time your create them. If you create a new site policy named site:Redmond you don’t have to assign the policy; instead, the moment you press Enter the policy is created and automatically assigned. And where is it assigned? You got it: it’s assigned to the Redmond site, which explains why you gave it the Identity site:Redmond . Global policies are automatically assigned at the global level and service policies are automatically assigned to the designated service; it’s as easy as that.

Which, of course, leads to an obvious question: how do you assign the policy site:Redmond to a different site? And the answer is a simple one: you don’t. Instead, you have to create a new policy (one that has the same values as site:Redmond ) and then give that policy a site-specific Identity, such as site:Dublin . You can’t copy a policy from one site to another.

Note , Well, OK, we’ll show you a simple example of how you could write a script that effectively copies a policy from one site to another. To do this, we’ll make a copy of an existing voice policy ( site:Redmond ) and then assign that copy to the Dublin site. However, we’ll only copy over a couple of property values; we’ll leave it up to you to figure out how to copy all the property values from one policy to another:

$x = Get-CsVoicePolicy -Identity site:Redmond

New-CsVoicePolicy -Identity site:Dublin –AllowCallForwarding $x.AllowCallForwarding –AllowSimulRing $x.AllowSimulRing

See what we’ve done here? In line 1, we’ve used Get-CsVoicePolicy to retrieve the site:Redmond policy; that policy gets stashed in the variable $x. In line 2, we used New-CsVoicePolicy to create a new voice policy with the Identity site:Dublin ; that means this policy will automatically be assigned to the Dublin site. We’ve also added two parameters: -AllowCallForwarding and –AllowSimulRing . But notice the parameter values we’re using. For example, we don’t set –AllowCallForwarding to either $True or $False; instead, we set it to this:

$x.AllowCallForwarding

In other words, we want the Dublin policy’s AllowCallForwarding property to have the same value as the Redmond policy. And it will have the same value, because $x.AllowCallForwarding just happens to be the value of the Redmond policy’s AllowCallForwarding property. (Remember, we stashed the property values for that policy in the variable $x.)

If you continue this pattern (like we did with –AllowSimulRing) for all the parameters you’ll eventually have a command that will copy the settings from site:Redmond to site:Dublin .

It takes a little work, but it’s worth it.

Now, where were we? Oh, yes: per-user policies are different from other types of policies. When you first create a per-user policy that policy doesn’t automatically get assigned anywhere; instead, it simply sits in the database and awaits further instructions. And what happens if you never assign that policy to anyone? Nothing; that just means that the policy never gets assigned to anyone.

Of course, what’s the fun of having a per-user policy that never gets assigned to anyone? Bearing in mind that user policies can be assigned only to users, you can assign a policy using a command similar to this:

Grant-CsVoicePolicy -Identity "Ken Myer" -PolicyName RedmondPolicy

As you can see, all you have to do is call the Grant-CsVoicePolicy cmdlet followed by the Identity of the user you want to assign the policy to; in this case, that’s a user with the display name Ken Myer . You also need to use the –PolicyName parameter followed by the policy Name (which is really the policy Identity minus the policy scope).

Note . So why is this Grant -CsVoicePolicy rather than Assign -CsVoicePolicy? Going with Grant was a decision the Microsoft Lync Server team made to adhere to Windows PowerShell naming standards. As it turns out, “Assign” isn’t an approved verb for PowerShell cmdlets – the closest alternative the Lync Server team could find was Grant. It’s not an exact match, but it does help to keep the Lync Server cmdlets consistent with the cmdlets used in other Microsoft products.

Of course, you’re more likely to want to assign a policy to a group of users than to a single user. Without going into any detail (see Retrieving Active Directory and Microsoft Lync Server User Accounts for more information) here’s a command that assigns a voice policy to all the users in the Sales department:

Get-CsUser -LDAPFilter "Department=Sales" | Grant-CsVoicePolicy -PolicyName RedmondPolicy

Assigned Policies

It’s not always easy to tell which policy is being applied to a given user account. Oh, it’s easy enough to retrieve a list of all the policies that are assigned to a user; for example, this command will take care of that:

Get-CsUser "Pilar Ackerman" | Select-Object DisplayName, ClientPolicy, ClientVersionPolicy, ArchivingPolicy, PinPolicy, LocationPolicy, ConferencingPolicy, ExternalAccessPolicy, HostedVoicemailPolicy, VoicePolicy, DialPlan

Like we said, retrieving the information is no problem. The problem occurs when you try to interpret the information. For example, take a look at the list of policies that have been assigned to Pilar Ackerman:

DisplayName : Pilar Ackerman

ClientPolicy :

ClientVersionPolicy :

ArchivingPolicy :

PinPolicy :

LocationPolicy :

ConferencingPolicy :

ExternalAccessPolicy :

HostedVoicemailPolicy :

VoicePolicy : UserVoicePolicy1

DialPlan :

PresencePolicy:

To begin with, you’ll notice that there are a lot of blank entries; for example, nothing is listed for ClientPolicy or for ClientVersionPolicy . That doesn’t mean that no such policy has been applied to Pilar’s user account; instead, it simply means that no per-user policy has been applied to her account. If you don’t see a value listed for a policy that means that either a global policy or a site policy (or, more rarely, a service policy) is being used to manage that account. The following table shows a preliminary list (subject to change) of the scopes where policies can be applied.

Policy	Global Scope	Site Scope	Service Scope	Per-User Scope
ClientPolicy	Yes	Yes		Yes
ClientVersionPolicy	Yes	Yes	Yes	Yes
ArchivingPolicy	Yes	Yes		Yes
PinPolicy	Yes	Yes		Yes
LocationPolicy	Yes			Yes
ConferencingPolicy	Yes	Yes		Yes