Are Unused Settings Applied From the Global Scope?

Suppose I have a policy at the site scope, but it only uses one setting. Are the unused settings applied from the global scope?

Good question. To begin with, we should note that most Lync Server policies – and most policy settings – have default values. For example, suppose you use the following command to create a new conferencing policy named TestPolicy:

New-CsConferencingPolicy –Identity "TestPolicy"

When you run this command you’ll get a new conferencing policy. Furthermore, because you didn’t include any parameters other than Identity when calling New-CsConferencingPolicy, you’ll get a new conferencing policy that uses all the default values:

Identity : Tag:TestPolicy

AllowIPAudio : True

AllowIPVideo : True

Description :

AllowParticipantControl : True

AllowAnnotations : True

AllowUserToScheduleMeetingsWithAppSharing : True

AllowAnonymousUsersToDialOut : False

AllowAnonymousParticipantsInMeetings : True

AllowExternalUsersToSaveContent : True

AllowExternalUserControl : False

AllowExternalUsersToRecordMeeting : False

AllowPolls : True

EnableDialInConferencing : True

EnableAppDesktopSharing : Desktop

AllowConferenceRecording : False

EnableP2PRecording : False

EnableFileTransfer : True

EnableP2PFileTransfer : True

EnableP2PVideo : True

EnableDataCollaboration : True

MaxVideoConferenceResolution : VGA

MaxMeetingSize : 250

AudioBitRateKb : 200

VideoBitRateKb : 50000

AppSharingBitRateKb : 50000

FileTransferBitRateKb : 50000

As you can see, other than the Description, all the properties have default values. They're True, they're False, they're set to some number, they're set to something.

Now, suppose you create a new client policy using this same general approach:

New-CsClientPolicy –Identity "TestPolicy"

Run that command and you’ll get a new policy that includes property values like these (just to let you know, this is only a small subset of the property values found in a client policy):

Identity : Tag:TestPolicy

PolicyEntry : {}

Description :

AddressBookAvailability : WebSearchAndFileDownload

AttendantSafeTransfer :

AutoDiscoveryRetryInterval :

BlockConversationFromFederatedContacts :

CalendarStatePublicationInterval :

ConferenceIMIdleTimeout :

CustomizedHelpUrl :

CustomLinkInErrorMessages :

CustomStateUrl :

DGRefreshInterval :

DisableICE :

DisableCalendarPresence :

DisableContactCardOrganizationTab :

DisableEmailComparisonCheck :

DisableEmoticons :

This time around, most of the property values are blank; they've been left unconfigured. Why? Well, there can be many reasons for this. With client policies, this might mean that users are given a choice as to whether or not a feature should be enabled; for example, users can choose for themselves whether or not they want to enable or disable emoticons. In other cases, it might mean that an option won't be made available to users. Or it might mean that – well, to be honest, that doesn’t matter right now. What does matter is this: suppose we have a single client policy in our organization, a global policy that includes this setting:

As you can see, we’ve configured a value for the IMWarning property. This means that any time a user takes part in an instant messaging session he or she will see the following notice in their conversation window:

OK. So let’s say we now create a per-user client policy, one that includes this setting:

In other words, we haven’t configured a value of any kind for the IMWarning property. We then assign this new policy to the user Ken Myer.

So what’s going to happen when Ken opens up a new conversation window? Before you answer, remember that per-user policies take precedence over the global policy. At the same time, however, remember that we explicitly configured a value for the IMWarning property in the global policy, yet we left that value blank in the per-user policy assigned to Ken. So what will happen when Ken opens a new conversation window: will he get the notice or won’t he?

Note. Talk about being on pins and needles, huh? Kind of makes you wonder why Agatha Christie never used this plot in one of her books, doesn’t it?

Here’s what happens when Ken opens a new conversation window:

As you can see, Ken doesn’t see the notice. Why not? Because all the settings in the per-user policy take precedence over all the settings in the global policy. There’s no value configured for the IMWarning property in the per-user policy; as a result, Ken doesn’t get the notice in the conversation window. The blank IMWarning setting in the per-user policy gets used rather than the configured IMWarning setting used in the global policy. There’s no such thing as cumulative policies and policy settings in Lync Server. You get (in this case) either the global policy or the per-user policy, not some combination of the two.

Which, to be honest, makes your life as an administrator much, much easier. If you want to know what things Ken Myer can and cannot do when it comes to client policies all you have to do is figure out which policy he's been assigned (hint: here's a script that can help you do that) and then look at the values configured for that policy. You don't have to aggregate policies and try to figure out which settings are used when, and where. One user, one policy. Period.

And yes, that almost does make your life as an administrator too easy, doesn't it? That's just something you'll have to live with.

This question is one of many asked during a session on managing Lync Server 2010 with Windows PowerShell at the TechReady 11 conference. For more questions and answers asked during that session, take a look at the Questions and Answers from TechReady 11 .