Resetting a Policy

Brass Contributor

May 20, 2019

First published on TECHNET on Jun 06, 2010

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: