Resetting a Policy

When we first started working with the Microsoft Lync Server 2010 implementation of Windows PowerShell , we did a series of presentations for Technology Adoption Program (TAP) customers. After we finished doing our first talk we asked if anyone had any questions. The first question we were asked was this: “How can I reset a policy so that it uses all the default values?” And our answer was … well, to tell you the truth, we didn’t actually have an answer. We knew how to create a policy, we knew how to modify a policy, we knew how to assign a policy—heck, we even knew how to delete a policy. But reset a policy? We had no idea how to do that. After all, way back then there was no such thing as, say, a Reset-VoicePolicy cmdlet.

 
Although, come to think of it, even today there’s no such thing as a Reset-VoicePolicy cmdlet; that means there’s no built-in way to reset policies (or settings, for that matter) to their default values. But that’s OK; after all, there are a couple of tricks you can use that will reset policies in all-but the rarest of occasions.

 
What kind of tricks, you ask? Well, here’s one. Suppose you have a conferencing policy for the Redmond site, a policy that – by definition – has the Identity site:Redmond. You’ve made a bunch of changes to that policy, changes you now wish that you hadn’t made. With that in mind, you’d like to reset this particular site policy back to the default values. But how are you going to do that?

 
Go ahead; take your time on this one.

 
Oh, right: we were supposed to provide the answer to that question, weren’t we? Well, one easy way to reset a policy is to do this: delete the policy and then create a new one to take its place, making sure that you use all the default values when you create the new policy. For example, to “reset” the conferencing policy with the Identity site:Redmond all you have to do is run these two commands:

 
Remove-CsConferencingPolicy –Identity site:Redmond
New-CsConferencingPolicy –Identity site:Redmond

 
It’s not the most elegant solution, but it works. And, hey, what do you want anyway: style or substance?

 
Oh, OK. In that case, here’s another, more stylish way to “reset” the site:Redmond policy:

 
$x = New-CsConferencingPolicy –Identity site:Redmond –InMemory
Set-CsConferencingPolicy –Instance $x

 
What are we doing in these two commands? Well, in the first command we’re creating a new conferencing policy, one that has the Identity site:Redmond. And yes, we know: policy Identities have to be unique, and we already have a conferencing policy named site:Redmond. Isn’t this command doomed to fail? After all, we can’t very well have two conferencing policies with the Identity site:Redmond, can we?

 
No, we can’t. But, believe it or not (and you might as well believe it; we don’t have any reason to lie to you about this), we don’t have two policies with the same Identity, or at least not two real policies. Granted, we have one actual conferencing policy with the Identity site:Redmond. However, the policy we just created using New-CsConferencingPolicy isn’t real; that is, it doesn’t exist in the Microsoft Lync Server database. Why not? Because we tacked on the –InMemory parameter. When you use the –InMemory parameter, the policy you create initially exists in memory only. In other words, it’s a virtual policy, and if we didn’t store this virtual policy in a variable (in our case, a variable named $x) then the policy would have been created in memory and then almost instantly have disappeared.

 
Just like the professional careers of the writers of this article.

Note. So why would you even want to create a policy (or a collection of configuration settings) that exists only in memory? For one answer to that question see the article Looking Up the Default Values for a Policy .

 
At any rate, $x will now contain a virtual policy that has the Identity site:Redmond, which just happens to be the Identity of the policy that we want to reset. This virtual policy also uses all the default values used by a conferencing policy. We know that this policy uses the default values because we didn’t include any parameters when we created it: if you don’t specify a parameter for a policy (or collection of configuration settings) then Lync Server automatically assigns the appropriate default value to the property corresponding to that parameter. Let’s do a quick property comparison to show you what we mean; as you can see, our virtual policy has the same property values as the default conferencing policy values:

So how do we reset the real conferencing policy site:Redmond to the default values? That’s easy: we just use the Set-CsConferencingPolicy cmdlet and the –Instance parameter:

 
Set-CsConferencingPolicy –Instance $x

 
This command simply takes the virtual policy stored in the variable $x and uses it to overwrite all the property values in the real conferencing policy site:Redmond. (It can do this because the real policy and the virtual policy share an Identity. If they didn’t share an Identity this command would fail, because we would be trying to overwrite the real Identity with the virtual Identity, and that’s a no-no: Microsoft Lync Server doesn’t let you change Identities.)

 
Here’s what our table of property values looks like now.

 
See? We’ve effectively reset all the properties in the site:Redmond policy to their default values. Not bad, eh?

 
This works pretty well (and is at least a little elegant) although there are a couple of caveats here. First, while most of the New-Cs cmdlets support the –InMemory parameter there are a few exceptions; if a New-Cs cmdlet doesn’t have the –InMemory parameter this technique won’t work. Also, a few cmdlets have mandatory parameters: you can’t create a new X, Y, or Z unless you explicitly include that parameter and a value of some kind. In a case like that you can still use this approach, but you’ll need to include those mandatory parameters when creating your virtual policy.

 
Sound complicated? Well, we don’t think it’s too terribly complicated. On the bright side, we have good news for you if you’d like to reset a global policy or a global collection of configuration settings. Suppose you’ve made a few changes to your global conferencing policy, meaning that the policy now includes the following property values:

If we want to reset all the property value in a global policy all we have to do is this:

 
Remove-CsConferencingPolicy –Identity global

 
Wait, hold on, don’t panic: despite what it looks like we aren’t actually removing the global conferencing policy; in fact, Communications Server won’t let you remove a global policy or a global collection of configuration settings.

 
Why not? Well, for one thing, in Office Communications Server 2007 R2 there were ways (some sneaky, some simply built into the product) that enabled users to avoid Group Policy. In some cases, this allowed those users to avoid restrictions that would otherwise be applied to them; in all cases it complicated management and administration because you couldn’t easily tell which capabilities and limitations were being extended to a user.

Note. Why not? Well, some settings were configured using Group Policy, which could be set at either the User or the Machine scope, and at the domain level or the OU level, and with or without inheritance blocking. Meanwhile, other settings were configured in-band using the Administration Tool. Oh, and other settings were configured using WMI, and – well, you get the idea. If you were the only administrator in your organization you could probably figure things out without too much trouble. But if you weren’t the only administrator in your organization, well ….

 
In Lync Server 2010, however, policy and setting resolution is pretty straightforward. Let’s say the user Ken Myer has been assigned a per-user conferencing policy; in that case, Ken’s ability to schedule conferences, and the capabilities available in those conferences, will be determined solely by that per-user conferencing policy.

 
But what if Ken hasn’t been assigned a per-user policy? That’s fine: in that case his ability to schedule conferences, and the capabilities available in those conferences, will be determined solely by the site policy. And if his user account happens to be in a site that doesn’t have its own conferencing policy? Again, no big deal: he’ll then fall under the jurisdiction of the global conferencing policy. And if there isn’t a global policy? Well, there’s the answer to your question. There will always be a global policy; otherwise, users could be left in a totally unmanaged state.

 
And nobody wants that.

 
At any rate, when you run Remove-CsConferencingPolicy against the global policy you don’t actually remove the global policy; instead, you simply reset all the properties in that policy back to their default values. Let’s take a look at our property value table now that we’ve run Remove-CsConferencingPolicy:

 
See? Other than the Identity, the property values in the global policy and the default property values (which are stored in the Lync Server database) are identical.

 
Keep in mind that this only works with global policies or global configuration settings. Suppose you run this command:

 
Remove-CsConferencingPolicy –Identity site:Redmond

 
What’s gonna happen then? You got it: the site policy (site:Redmond) is going to be removed.

 
Hey, sometimes when we say we’re going to remove a policy we mean it.