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 |
|
ExternalAccessPolicy |
Yes |
Yes |
|
Yes |
|
HostedVoiceMailPolicy |
Yes |
Yes |
|
Yes |
|
VoicePolicy |
Yes |
Yes |
|
Yes |
|
DialPlan |
Yes |
|
|
Yes |
|
PresencePolicy |
Yes |
Yes |
Yes |
Yes |
To really determine which policy is governing Pilar’s user account you would need to check to see if Pilar’s account falls under the jurisdiction of a site or service policy. If not, that means the global policy is being used to manage her account. (If there are no other policies available then the global policy will always be used to manage an account.) Is it possible to do this using Windows PowerShell? Yes, but the process is a bit more complicated than we can deal with in this introductory article. (But if you really want to know how to determine the “effective policy” for a user, well, then you should take a look at this article.)
What’s more interesting (at least for our immediate purposes) is the fact that a per-user voice policy has been assigned to Pilar:
VoicePolicy : UserVoicePolicy1
As you can see, Pilar has been assigned a per-user voice policy, a policy with the identity UserVoicePolicy1.
By the way, whatever happened to Group Policy?
Good question. As you have probably figured out, the policies we are discussing here have nothing to do with Group Policy: they aren’t built using Group Policy, they aren’t assigned using Group Policy, and few of the settings correspond to the Group Policy settings used in Microsoft Office Communications Server 2007 R2. So what did happen to Group Policy?
To tell you the truth, it’s gone. Instead of Group Policy, all the client settings for Lync Server will be managed using CsClientPolicy. If you’re wondering why we chose to get rid of Group Policy there are a number of factors that went into that decision. First, there’s no doubt that Group Policy is difficult to target towards specific users; for example, it’s close-to-impossible to apply a Group Policy to all the users in a given department, or all the users who have a certain job title. As we just saw, that’s not the case with Lync Server policies. On top of that, it can also be a challenge to determine which Group Policy object is taking precedence for a given user. That’s also much easier with Lync Server policies:
• If there is a per-user policy assigned to the user then the per-user policy is used.
• If there is no per-user policy assigned to the user then the service policy is used.
• If there is no per-user or service policy then the site policy is used.
• If there is no per-user, service, or site policy then the global policy is used.
Another important consideration is the fact that Group Policy is applied only to authenticated users who log on to Active Directory. That means that Group Policy does not get applied to users accessing Office Communications Server over the Internet or via a cell phone. Needless to say, that’s a problem. Or, more correctly, it was a problem. Unlike Group Policy, Lync Server 2010’s in-band policies and configuration settings are applied to everyone who logs on to the system, regardless of who they are, where they are, or what type of device they use to log on.