Blog Post

Skype for Business Blog
4 MIN READ

Are Unused Settings Applied From the Global Scope?

NextHop_Team's avatar
NextHop_Team
Brass Contributor
May 20, 2019
First published on TECHNET on Sep 12, 2010

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:















Property



Value



IMWarning



Notice: All electronic communications are archived by Litwareinc.




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:















Property



Value



IMWarning






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 .

Updated May 20, 2019
Version 2.0
No CommentsBe the first to comment