Unassigning a Policy
OK, so the good news is this: following our guide to Assigning Policies , you’ve managed to successfully assign a new client policy to all the users in an OU. Congratulations!
Now here’s the bad news: as it turns out, there’s at least one user in that OU (the ubiquitous Ken Myer) who shouldn’t have been assigned that particular policy. And yet, if you look at Ken Myer’s user account, well, there it is:
Get-CsUser "Ken Myer" | Select-Object DisplayName, ClientPolicy
DisplayName ClientPolicy
----------- ------------
Ken Myer RedmondClientPolicy
Is that a problem? Well, it sure looks like a problem, doesn’t it? After all, while there’s a Grant-CsClientPolicy cmdlet to assign a client policy to a user, there’s no corresponding Ungrant-CsClientPolicy cmdlet to unassign a client policy. Uh-oh ….
But wait: there’s no need to despair; after all, this is Microsoft Lync Server 2010 Windows PowerShell we’re talking about. As it turns out, there’s a little-known trick (well, little known up until now) that allows you to unassign a per-user policy that has been assigned to a user. Want to remove the per-user client policy RedmondClientPolicy from Ken Myer’s user account? Okey-doke:
Grant-CsClientPolicy -Identity "Ken Myer" -PolicyName $null
Now, we know what you’re thinking: you’re thinking, “Man, those guys are so lazy they didn’t even finish writing their Grant-CsClientPolicy command.” Au contraire (which is French for … well, for something ….). Admittedly, we did call the Grant-CsClientPolicy cmdlet without specifying a policy name following the -PolicyName parameter; we just use the Windows PowerShell constant $null. But while that might look like an unfinished command, it’s really the little trick we were just talking about: if you call one of the Grant- cmdlets and set the policy name to $null, the cmdlet will actually remove a per-user policy assignment from a user account. It’s true; take a look at Ken Myer’s user account now:
Get-CsUser "Ken Myer" | Select-Object DisplayName, ClientPolicy
DisplayName ClientPolicy
----------- ------------
Ken Myer
See? No per-user client policy is assigned to Ken’s account. If we take a peek at his colleagues in the Redmond OU (the OU containing all the user accounts originally assigned RedmondClientPolicy), we’ll see that their policy assignments remain unchanged:
Get-CsUser –OU "ou=Redmond,dc=litwareinc,dc=com" | Select-Object DisplayName, ClientPolicy
DisplayName ClientPolicy
----------- ------------
Aidan Delaney RedmondClientPolicy
David Yalovsky RedmondClientPolicy
Jonathan Haas RedmondClientPolicy
Ken Myer
Lisa Jacobson RedmondClientPolicy
Matt Berg RedmondClientPolicy
Max Stevens RedmondClientPolicy
Pilar Ackerman RedmondClientPolicy
Which is just the way it should be.
The moral of the story? “To unassign a per-user policy, call the appropriate Grant- cmdlet, but set the policy to be 'assigned' to $null.” (Which, if memory serves us correctly, was also the moral of the story The Little Matchstick Girl.) For example, suppose we change our minds and decide that we don’t want any of the users in the Redmond OU to have the client policy RedmondClientPolicy after all. That’s fine:
Get-CsUser –OU "ou=Redmond,dc=litwareinc,dc=com" | Grant-CsClientPolicy -PolicyName $null
Here’s what we get after we run that command and then check the client policy assignments for all the users in the Redmond OU:
Get-CsUser –OU "ou=Redmond,dc=litwareinc,dc=com" | Select-Object DisplayName, ClientPolicy
DisplayName ClientPolicy
----------- ------------
Aidan Delaney
David Yalovsky
Jonathan Haas
Ken Myer
Lisa Jacobson
Matt Berg
Max Stevens
Pilar Ackerman
Nice.
Important Note
It goes without saying (although we’re obviously going to say it anyway) that this approach only works when it comes to per-user policies: you can’t use this little trick to unassign a site policy or a global policy. Why not? Well, for one thing, site policies and global policies are never assigned in the first place: instead, you simply inherit those policies based on the location of your Communications Server user account. If your account happens to be in a site that has a site-scoped client policy (see the article Scopes and Filters for more information) then your client-related activities will be regulated by the site policy. (Well, unless you’ve been assigned a per-user policy: per-user policies always take precedent over service, site, and global policies.) And what if your site doesn’t have a site-scoped client policy? That’s fine: in that case, you’ll be managed by the global policy: in lieu of any other policy you will always be managed by the global policy.
Clarification. But if we look at Ken Myer’s user account doesn’t it show his ClientPolicy attribute as being blank? Well, yes, as a matter of fact it does. But that just means that Ken Myer hasn’t been assigned a per-user policy: the Get-CsUser cmdlet doesn’t return information about service, site, or global policies. Rest assured that Ken’s account is under the jurisdiction of some kind of client policy. If you need to know which client policy (i.e., site or global), take a peek at our script for determining the effective policy of a user .
So what if, for some reason, you don’t want one particular user managed by the site policy or the global policy? Well, to be perfectly honest, there’s really only one recourse: you’ll need to create a per-user policy and assign it to just that user. That might seem like a bit of a hassle, but like death, taxes, and beer commercials featuring beautiful girls fawning over schlubby guys, there’s no escaping policy assignment in Microsoft Lync Server 2010.