Utah: the land of

Mountains, smiles, Beetdiggers, and

Conference policies.

 

As you no doubt know by now, the author of today's haiku is currently in Utah, partly to take a few days of vacation here and there, and partly to do his regular old work. (Based on the kind – and amount – of work he does, he can easily do that from Redmond, from Utah, or even from the dark side of the Moon.) And because he is supposed to be working from time-to-time, he thought he'd start out today's haiku by reporting on some of the things he's learned during his stay in Utah:

 

·         Up until a couple of years ago, Utah required bars and restaurants to install a "Zion curtain," a partition that separated a bartended from his or her customers. The Zion curtain is no longer required; however, new bars and restaurants are required to mix drinks in a separate part of the building, where the bartenders can't be seen by customers.

 

Note. If a friend of yours says, "Hey, I've got this great idea to remake Cheers, only this time to set it in a bar in Utah," well, you might want to encourage him to reconsider.

 

·         Like most newspapers, the Salt Lake Tribune does restaurant reviews: 3 stars is exceptional; 2 stars is very good; 1 star is good. What about a restaurant that isn't very good, that is downright bad? Hey, this is Utah, and the people are incredibly nice here: they would never write a review that called a restaurant bad!

 

Note. OK, so probably they just wouldn't give the restaurant any stars. But the people here really are nice, so we like to think they'd give everyone at least one star regardless of how bad they might be. Heck, even at Microsoft you can't actually get a zero on your annual performance review. (Although the author of today's haiku has come awfully close in the past.)

 

·         Jordan High School's nickname is The Beetdiggers. To be honest, the author of today's haiku was a little disappointed by that. The Fighting Beetdiggers would have been way cooler. "Ladies and gentlemen, your Jordan High School Fighting Beetdiggers!"

 

·         In Utah, everyone's favorite set of Lync Server cmdlets is the CsConferencingPolicy cmdlet set: Get-CsConferencingPolicy, Grant-CsConferencingPolicy, New-CsConferencingPolicy, Remove-CsConferencingPolicy, and Set-CsConferencingPolicy.

 

Note. Really? Well, maybe. To be honest, we didn't get a chance to take as extensive a survey as we really wanted to.

 

So what makes the CsConferencingPolicy cmdlets so popular? Well, to tell you the truth, we can't really speak for the people of Utah. (Nor would they really want us to.) Speaking for ourselves, however, we like the CsConferencingPolicy cmdlets simply because we've already written a whole bunch of articles about these cmdlets (for example, An In-Depth Guide to Conferencing Policy Settings). That means that we won't have to write very much for today's haiku: we'll just refer you to all our previous articles (such as No Conferencing Policy is an Island: Per-Organizer Settings vs. Per-User Settings).

 

As the name implies, conferencing policies determine what users can and cannot do while in a conference. (In Lync Server, a conference is roughly defined as a communication session involving 3 or more people. A session involving just 2 people is generally referred to as a peer-to-peer session.) For example, there are conferencing policy settings that determine whether users can transfer files within a conference; settings that determine whether users can use video within a conference; and settings that determine whether users can record conferences that they take part in.

 

What the name doesn't imply, however, is the fact that conferencing policies are also used to determine what users can and cannot do while in a peer-to-peer session: there are also conferencing policies that manage file transfers, video use, and recording within peer-to-peer sessions. That's important to know, because the Microsoft Lync features available to a user might change depending on whether or not a user is in a conference or a peer-to-peer session. For example, suppose Ken Myer is in a conference where file transfers are allowed. There are currently three people in this conference.

 

Now, suppose one of those three people drops out. At that point, you no longer have a conference: you now have a peer-to-peer session. And if Ken's conferencing policy doesn't allow him to do peer-to-peer file transfers then, just like that, Ken will no longer be able to do peer-to-peer file transfers. In many cases there's a sharp distinction drawn between the things you can do in a conference and the things you can do in a peer-to-peer session.

 

A little confusing? Possibly. What's even more confusing is the fact that some settings apply to the organizer of a conference and some settings apply to the individual users in a conference. We won't go into a whole lot of detail on that topic today; instead, we'll take the easy way out and refer you to a previous article on that very subject. Briefly, however, let's take the AllowIPVideo setting as an example. This setting applies to the organizer of a conference, which means it also applies to every single person who joins that conference. Suppose Ken Myer is not allowed to use video in conferences he organizes (AllowIPVideo is False). If Ken organizes a conference no one will be able to use video in that conference; Ken's conferencing policy won't allow it. (With a per-organizer setting, the only conferencing policy that matters is the organizer's conferencing policy.)

 

What's that? You say Ken has been invited to a meeting hosted by Pilar Ackerman, and Pilar's policy allows IP video? That's cool: Pilar will thus be able to use video in her conference, and so will everyone who joins that conference, including Ken Myer. Remember, the only conferencing policy that matters is the organizer's conferencing policy.

 

For better or worse, there are also policy settings that apply to the individual user. For example, your ability to share a single application (or to share your entire desktop) is enforced at the per-user level. Suppose Ken Myer's conferencing policy prohibits him from sharing anything. In that case, Ken won't be allowed to share an application (or his desktop) in any meeting he organizes. However, if Pilar Ackerman is allowed to share her desktop, she can do so in any meeting, even in one organized by Ken. (Which, admittedly, leads to the odd scenario in which the meeting organizer can't share anything but a meeting participant can share everything.) The reverse is also true: in a meeting organized by Pilar, Ken still can't share anything. His conferencing policy won't allow it.

Yes, we know: we can get confused by all this, too. But take a look at No Conferencing Policy is an Island for more information. And take a look at some of our policy setting articles if you want to see what this per-organizer/per-user stuff really means.

 

Other than that, there isn't anything particularly noteworthy about conferencing policies. These policies can be created (at the site or the per-user scope) by using the New-CsConferencingPolicy cmdlet:

 

New-CsConferencingPolicy -Identity SalesConferencingPolicy -MaxMeetingSize 50

 

Note. In case you're wondering, that policy sets the maximum size of a meeting to 50 people instead of the default value of 250 people.

 

Existing policies can be modified using the Set-CsConferencingPolicy cmdlet, and those existing policies can be deleted by using – that's right, the Remove-CsConferencingPolicy cmdlet. Need to assign a per-user policy (by the way, that's the per-user scope, not the per-user setting) then just use the Grant-CsConferencingPolicy cmdlet:

 

Grant-CsConferencingPolicy -Identity "Ken Myer" -PolicyName SalesConferencingPolicy

 

And, of course, there's everyone's favorite, the Get-CsConferencingPolicy cmdlet, which allows you to retrieve information about your conferencing policies. This command retrieves information about all your conferencing policies:

 

Get-CsConferencingPolicy

 

And this one retrieves information only about those policies where the maximum meeting size is greater than 50:

 

Get-CsConferencingPolicy | Where-Object {$_.MaxMeetingSize -gt 50}

 

Etc., etc.

 

At any rate, that's about all we have to say for the CsConferencingPolicy cmdlets. As for the state of Utah, we've also learned that the weather is always beautiful here (although we've seen some evidence that there was a foot of snow on the ground here in Park City as late as April 23rd). We've also learned, the hard way, that people in Utah drive just as terribly as people from Washington.

 

But we'd still give them one star for their driving ability.

 

Or was that one fing – nah, never mind, See you tomorrow!