Lync Server Policy Default Values and Inheritance

Where are policy defaults stored? Are they inherited from the global policy? Can I change the default values?

For all intents and purposes, the default values for anything you can create in Lync Server PowerShell (which includes configuration settings as well as policies) are hard-wired into the product. For example, suppose you use the following command to create a new voice policy:

New-CsVoicePolicy –Identity TestVoicePolicy

If you then look at the properties of this new voice policy, you'll see things like this:

EnableCallTransfer : True

EnableCallPark : False

Why is the default value for EnableCallTransfer set to True and the default value for EnableCallPark set to False? Well, there's really only one reason for that: that's the way the product team designed things to be. In some cases they might have based the default value on the way most people configure things; in other cases they might have based the default value on the recommended way of configuring things. Regardless, the default values are built into the system and they can't be changed. If you'd rather not enable call transfer then every time you create a new policy you'll need to specifically disable that feature:

New-CsVoicePolicy –Identity TestVoicePolicy –EnableCallTransfer $False

In addition, these default values are only tangentially related to the global policies and settings. As you might expect, when you first install Lync Server the global voice policy will use all the default settings for a global voice policy. However, you can easily change any of these policy settings within the global policy:

Set-CsVoicePolicy –Identity global –EnableCallTransfer $False

The global policy will no longer allow call transfers. But what happens if you create a new voice policy:

New-CsVoicePolicy –Identity TestVoicePolicy2

Will that new policy allow call transfers? As a matter of fact, it will. Why? Because the default value for EnableCallTransfer is True, and changing the global policy will not change the default policy values. That's because default values come from Lync Server itself and not from the global policy.

Another tangentially-related note. If you "remove" the global policy, that policy won't be deleted; Lync Server won't let you get rid of global policies. However, all the settings in that global policy will revert to the default values. Remember how we changed EnableCallTransfer to False? Well, if you remove the global policy, then EnableCallTransfer, like all the other policy settings, will revert back to its default value. In that case, that means EnableCallTransfer will, once again, be set to True.

Ah, good question: if the default values are built into the system then how are you supposed to know what those default values are? Well, to tell you the truth, there's no simple, straightforward way to look at the default values for a policy or a collection of configuration settings. However, there are a couple of reasonably simple, reasonably straightforward ways to work around that issue. For one, you can always look at the help topic for the policy or settings in question:

Get-Help New-CsVoicePolicy –Full | More

That works pretty well, although, admittedly, you'll need to wade through the entire help topic in order to tease out the default values for all the properties.

Because of that, another option is to create a "pretend" policy, a policy that won’t ever get applied to the system (because it exists only in memory) but will contain all the default values. How do you create a pretend policy? Like this:

New-CsVoicePolicy –Identity TestVoicePolicy –InMemory

What we've done here is tack the InMemory parameter onto the end of our call to New-CsVoicePolicy. What that does is ensure that the policy we create is created only in memory; it doesn't get added to our collection of Lync Server voice policies. When we run that command, the properties of our pretend policy will all be displayed on the screen. And because we didn't specify values for any of those properties, each property in the pretend policy will be set to its default value.

And yes we know: it does sound like cheating, doesn't it? But it's not.