No man is an island, entire of itself; every man is a piece of the continent, a part of the main; if a clod be washed away by the sea, Europe is the less...any man's death diminishes me, because I am involved in mankind.
– John Donne
Although he died nearly 400 years ago, John Donne, the English poet and philosopher, probably understood Microsoft Lync Server 2010's conferencing policies as well as anyone. (Which might actually be true, seeing as how we're not convinced that anyone really understands Lync Server's conferencing policies.) As Donne noted, no man (or woman) is an island: anything that affects one man affects every man. It's like the butterfly effect : the idea that a butterfly flapping its wings in Brazil could end up causing it to rain thousands of miles away.
Note . Which explains why those of us who live in the Seattle area aren't real fond of Brazilian butterflies. Guys, do you have to flap your wings all the time ? We're tired of the rain up here!
Stupid meddling butterflies ….
Of course, Lync Server policies would seem to be an exception to the notion that no man is an island. For example, suppose you have a global external access policy, and the global policy happens to be the only external access policy you have. You’ve set up this policy to allow all your users to communicate with people who belong to a federated organization; that means that, for example, users Ken Myer and Pilar Ackerman are allowed to communicate with federated users.
Now, suppose you create a per-user external access policy that prohibits communication with federated users; in turn, you assign that per-user policy to Pilar. Can Pilar communicate with federated users? Nope; her new external access policy prohibits that. Can Ken communicate with federated users? Of course he can; after all, his external access policy (the global policy) allows him to do that. The fact that we assigned a particular external access policy to Pilar doesn't affect Ken in any way, shape, or form. In other words, Ken Myer is an island.
Or is he? After all, we haven't talked about conferencing policies yet.
Lync Server Conferencing Policies
As the name implies, conferencing policies are used to dictate what users can – and cannot – do in a Lync Server meeting or conference. For example, how many people can you actually have in a meeting? Well, that's determined by your conferencing policy, and by the MaxMeetingSize setting. By default, users are allowed to have as many as 250 participants in any meeting that they host. You say that's too many people to have in a single meeting? That's fine; just change the value of the MaxMeetingSize setting, something you can do with a single Windows PowerShell command:
Set-CsConferencingPolicy –Identity global –MaxMeetingSize 50
Admittedly, there's nothing special about that: you wanted to change a conferencing policy setting so you used the Set-CsConferencingPolicy cmdlet. In that respect, conferencing policies are no different from any other type of Lync Server policy.
However, there's another respect in which conferencing policies are very different from other types of Lync Server policies: per-organizer settings vs. per-user settings. This is where people begin to get confused.
And, with any luck, this article marks the point where we begin to unconfuse them.
Per-Organizer Settings
As we saw a few minutes ago, a Lync Server policy typically affects only the user (or users) that the policy is assigned to.
Note . Which makes sense. After all, it would be a bit odd to assign an external access policy to Pilar Ackerman and then have that policy affect Ken Myer too.
For example, when we assigned a per-user external access policy to Pilar Ackerman, only Pilar Ackerman was affected by that policy; the policy had no effect on users (like Ken Myer) who hadn't been assigned that policy. Yes, it's a shame that Pilar can no longer communicate with federated users, but what difference does that make to Ken Myer? To be blunt, it makes no difference to him whatsoever. Ken can continue to communicate with federated users, and it doesn't matter whether or not Pilar Ackerman (or anyone else) can do the same.
Like we said, it looks like Ken is an island.
Except for one thing: this isn't always how things work with conferencing policy settings. For example, remember MaxMeetingSize? MaxMeetingSize is an example of a per-organizer setting. Big deal, you say? Well, as it turns out, it is a big deal. Why? Because a per-organizer setting not only affects the user who organizes a meeting, it also affects every single person who attends a meeting organized by that user . And don't worry: we're about to show you just exactly what that means.
Note . But here's a hint: it means that no man is an island after all.
In order to do this, let's take a look at the AllowPolls setting, a per-organizer setting that determines whether or not users are allowed to conduct online polls during a meeting. (We chose that one because it makes it easy for us to use screenshots that show the actual effect of this setting.) We're going to look at meetings involving three users, users who have been assigned different conferencing policies. These policies include the following settings:
User |
AllowPolls |
EnableAppDesktopSharing |
Ken Myer |
True |
Desktop |
Pilar Ackerman |
False |
SingleApplication |
April Reagan |
False |
None |
Note . Why did we also throw in EnableAppDesktopSharing when we're talking about the AllowPolls setting? The reason for that will become clear when we get to the section of this article titled Per-User Settings .
See how that all works? Good. Now let's suppose that Ken Myer has organized a meeting and invited both Pilar Ackerman and April Reagan to join that meeting. As shown in the table above, Ken's conferencing policy allows him to conduct online polls (AllowPolls is set to True). By contrast, Pilar and April both have conferencing policies that do
not
allow them to conduct polls (AllowPolls is set to False). To recap, Ken can do polls; Pilar and April cannot.
At this point, we'll assume that the meeting has started and that Ken, Pilar, and April have all joined the meeting, with Ken being the meeting organizer. Let's take a peek over Ken's shoulder and look at his copy of Microsoft Lync:
No surprises there. As you would expect, the New Poll option appears under Ken's Share menu. And it should appear there: after all, Ken's conferencing policy allows him to conduct online polls.
OK, now let's peek over Pilar's shoulder:
And, while we're being nosy, let's look over April's shoulder, too:
Sacre bleu! The New Poll option shows up for both Pilar and April! But how can that be: don't the conferencing policies assigned to Pilar and April prohibit them from conducting online polls?
You bet they do. But remember, the AllowPolls setting is a per-organizer setting; that means it applies to the organizer of the meeting and to everyone who participates in that meeting . When it comes to a per-organizer setting, Lync Server looks only at the policy applied to the organizer of the meeting; it then applies that same capability (or restriction) to every single person in the meeting. You say that April's conferencing policy doesn't allow her to conduct online polls? It doesn't matter; when it comes to a per-organizer setting like AllowPolls, if she’s not the meeting organizer Lync Server doesn't care what April's conferencing policy says. (Why not? Because April is just a participant and, in a case like this, participant settings don't matter.) Lync Server only cares what Ken Myer's conferencing policy says. That's because Ken is the meeting organizer and AllowPolls is a per-organizer setting.
In other words, a policy applied to Ken Myer does affect other users. John Donne was right!
At least when it comes to per-organizer settings.
To prove that John Donne was right, let's now say that April has scheduled a follow-up meeting and invited both Pilar and Ken. With April now the meeting organizer, let's see what her copy of Lync looks like when she clicks Sharing :
Ah-ha: notice that the New Poll option has disappeared! Why? Because April is the meeting organizer, and her conferencing policy doesn't allow her to conduct polls. No polls means no New Poll option.
Now, what about her colleagues, Pilar and Ken? Well, here's Ken's copy of Lync:
And here's Pilar's:
Again, the New Poll option has vanished, even though Ken has a conferencing policy that allows him to conduct online polls. But remember, it doesn't matter what a participant's policy might allow: the ability to conduct online polls is determined exclusively by the conferencing policy assigned to the meeting organizer. If the organizer (April Reagan) can't conduct polls then no one can conduct polls.
Period.
Most conferencing policy settings work like this: they apply to the organizer of a meeting. And that makes sense. Take the MaxMeetingSize setting, for example. Suppose Ken Myer is allowed to invite 50 people to a meeting, April is allowed to invite 75 people, and Pilar is allowed to invite 100. If MaxMeetingSize applies to the organizer of the conference then Lync Server knows exactly how many people can attend Ken's meeting: 50. But what if MaxMeetingSize was configured at the per-user level; in that case, how in the world could you determine how many people can attend one of Ken Myer's meetings? You couldn't determine that, which is why the setting applies to the meeting organizer instead of all the individual participants in the meeting.
Note . Good question: how do you know which settings are per-organizer settings and which ones are per-user settings? Take a look at the help topics for the PowerShell cmdlets New-CsConferencingPolicy and Set-CsConferencingPolicy . Each parameter should have a note similar to this one, which accompanies the AllowAnnotations parameter:
"This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will include annotations. However, the user can participate in other conferences where annotations are allowed."
So what’s the moral of the story? The moral of the story is that most conferencing policy settings apply to a given meeting, and are based on the conferencing policy assigned to the meeting organizer. For example, in this meeting (which Ken Myer organized) no one can do onscreen annotations, no one can record the proceedings, and no one can dial in to the conference using a telephone. Why not? Because Ken Myer's conferencing policy prohibits him from doing those things. And if the meeting organizer can't do those things then no one can do those things.
See how simple that is?
Of course, we did say that most conferencing policy settings apply to the organizer of a meeting, didn't we? And that's true: but there are settings that apply to conference participants rather than conference organizers. Which brings us to our next topic: per-user settings.
Per-User Settings
To be perfectly honest, life would be much easier if all conferencing policy settings applied to the conference organizer. As we just noted, however, they don't. Instead, some conferencing policy settings apply to individual users (i.e., the conference participants) rather than conference organizers. That includes the following:
Setting |
Description |
AllowExternalUserControl |
Indicates whether external users (either anonymous users or federated users) are allowed to take control of shared applications or desktops. |
AllowParticipantControl |
Indicates whether or not meeting participants are allowed to take control of applications shared during the meeting. |
EnableAppDesktopSharing |
Indicates whether participants are allowed to share applications (or their desktop) during the course of a meeting. |
EnableP2PFileTransfer |
Indicates whether peer-to-peer file transfers (that is, file transfers that do not involve all participants) are allowed during the meeting. |
EnableP2PRecording |
If True, users will be able to record peer-to-peer conferencing sessions. |
EnableP2PVideo |
If True, users will be able to take part in peer-to-peer video conferencing sessions. |
So how do per-user settings affect a conference and the people in that conference? In order to address that question, let's first review the settings assigned to our three users:
User |
AllowPolls |
EnableAppDesktopSharing |
Ken Myer |
True |
Desktop |
Pilar Ackerman |
False |
SingleApplication |
April Reagan |
False |
None |
Note . Remember, EnableAppDesktopSharing is an example of a per-user setting.
Suppose Ken Myer has organized yet another meeting involving himself, Pilar Ackerman, and April Reagan. Now that the meeting has started, let's see what Ken's copy of Microsoft Lync looks like:
As you can see, Ken has a couple of options for sharing applications: Desktop and Program . Why? Because, in his conferencing policy, EnableAppDesktopSharing has been set to Desktop ; that enables Ken to share individual programs or to share his entire desktop.
So what about April? As you may recall, in April's conferencing policy EnableAppDesktopSharing has been set to None ; that means April is not allowed to share anything. Let's see what her copy of Lync looks like:
Well, what do you know: April doesn’t have any options for sharing applications. That's very different from Ken, who has two options for sharing applications. Why does April have different application sharing options than Ken does? That's easy: because she has a different conferencing policy than Ken does. The ability to share applications is a per-user setting, which means that Ken's conferencing policy applies only to himself. When it comes time for Lync Server to determine whether or not April can share applications then it's going to rely on April's conferencing policy.
Note . Notice that, in this example, April can still share a PowerPoint presentation and a whiteboard. To eliminate those options you'd have to set the per-organizer setting EnableDataCollaboration to False. However, and because that's a per-organizer setting, it will only take effect in meetings that April organizes herself. But we'll talk about those things in a future article.
We should also note that even though April cannot share applications she can still view any applications that someone else shares during a meeting. She can even take control of that shared application (well, depending on her conferencing policy settings). She just can't share a program of her own.
Now let's take a look at Pilar's copy of Microsoft Lync. As you might recall, Pilar's conferencing policy, EnableAppDesktopSharing is set to SingleApplication ; Pilar can only share one application at a time. So let's see what her copy of Lync looks like:
Voila: the only option Pilar has for sharing applications is Program , which lets her share a single program. The system works!
Note . If you're thinking, "Wait, doesn't that mean that different people in a meeting might have different options and capabilities?" Well, congratulations: that's exactly what could happen. With a per-organizer setting, every person in the meeting will be the same: you either can conduct polls or you can't conduct polls. With per-user settings, however, different people, sitting in that same meeting, might be able to do different things. Ken can share applications and his desktop; Pilar can share a single application; April can't share anything. That's the nature if a per-user setting.
Of course, there is a catch. (Actually, there are two catches.) To begin with, suppose April Reagan, who is not allowed to do any kind of application sharing, schedules a meeting. In that case, neither Ken nor Pilar will be able to do application sharing, either. Instead, their menu options for application sharing will be grayed-out:
If the meeting organizer can't share anything then no one can share anything. We're not sure why things work that way; they just do. However, if Pilar (who can only share a single application) organizes a meeting then Ken will be able to share both his desktop and/or a single application. It's a bit of an oddball case, but it's worth knowing about.
Note . Are there other oddball cases like this? That's something we'll be exploring in future articles.
And then there's another problem: what happens when per-organizer and per-user settings don't agree?
Per-Organizer Settings vs. Per-User Settings
Fortunately this doesn't happen very often; however, it is possible for a per-organizer setting to conflict with a per-user setting. For example, we've already seen that, in Ken Myer's conferencing policy, the per-user EnableAppDesktopSharing setting is set to Desktop ; that allows Ken to share individual applications and/or his desktop. However, there's another conferencing policy setting (a per-organizer setting) called A llowUserToScheduleMeetingsWithAppSharing; if this is set to False on a policy applied to Ken Myer, this setting prohibits anyone attending a meeting organized by Ken from using application sharing. So what's the deal here: can Ken Myer use application sharing in one of his own meetings or can't he? EnableAppDesktopSharing suggests he can. A llowUserToScheduleMeetingsWithAppSharing suggests he can't.
And the answer to that question is … no, he can't. Let's look at Ken's copy of Lync now that we've set A llowUserToScheduleMeetingsWithAppSharing to False:
Look at that: no options for application sharing . Why not? Because a per-organizer setting trumps a per-user setting. That means that Pilar, who usually can share single applications, won't have any options for sharing applications, either:
Remember, though, that A llowUserToScheduleMeetingsWithAppSharing only applies to meetings that Ken Myer organizes. What happens if Ken joins a meeting organized by Pilar? Well, unless Pilar's conferencing policy also has A llowUserToScheduleMeetingsWithAppSharing set to False, Ken should be able to share individual applications and/or his desktop. And guess what? He can:
And yes we know, it seems a little complicated. But it actually makes sense: in case of a conflict, a per-organizer setting takes precedence over a per-user setting.
To Make a Long Story Short
So what have we learned today? Here's a quick recap:
· If a setting is a per-organizer setting, Lync Server will check the conferencing policy assigned to the meeting organizer (e.g., Ken Myer) and enforce that setting on every person who attends the meeting. It doesn't matter who you are or what your conferencing policy says: you’ll only be able to do what the meeting organizer is allowed to do.
· If a setting is a per-user setting, then Lync Server will check your conferencing policy and let you do whatever your policy allows you to do. (At least for the most part. As we noted, there are some oddball cases.)
· If a per-organizer policy conflicts with a per-user policy, the per-organizer policy wins. End of story.
Um, I Have a Question …
We were afraid someone was going to say that; after all, the one problem with writing an article like this is that these articles often generate more questions than they answer. Our goal today was mainly to explain the difference between a per-organizer setting and a per-user setting; with any luck, we've managed to do that. Along the way, we also tried to give you a more detailed look at some of the conferencing policy settings; for example, we've shown you what happens when A llowUserToScheduleMeetingsWithAppSharing is set to False, and what happens when AllowPolls is set to True. But what about all the other conferencing policy settings; for example, what exactly happens when EnableFileTransfer is set to True or EnableP2PVideo is set to False?
Well, to tell you the truth, we don't always know. (We can make a pretty good guess on most of those things, but ….) But don't worry: over the next few weeks we plan on taking it upon ourselves to investigate each one of the conferencing policy settings and report back (complete with plenty of screenshots) exactly what it means to set X to True or Y to False.
And what if you can't wait for us to finish that investigation? Well, we're not sure. But you might take a look at the works of John Donne . He seems to have known quite a bit about this stuff.