Haiku #115

  • Article

Sorry, but you're not

On the list. Take a hike, man!

Client versioning.

 

For those of you anxiously following the saga of Seattle's attempt to have a day where the temperature reaches 70 degrees Fahrenheit, we must inform you of a temporary setback. When the author of today's haiku left for work this morning, the thermometer read 49 degrees. (Not exactly balmy, but, then again, it wasn't even 7:00 AM yet.) By the time he got to work, the temperature had actually dropped 1 degree. Not a good omen, to say the least.

 

Note. The author of today's haiku assumes that one of two things happened. For one, the thermometer is so used to going down that it might have been temporarily confused and dropped a degree when it should have actually gone up a degree. The other possibility is that the thermometer is planning some sort of sneak attack on 70 degrees: just kind of hang out in the 40s and 50s and then, when you least expect it, make a mad dash for that elusive 70 degree mark.

 

Which, in case you're wondering, Minneapolis, MN reached well over a month ago. Minneapolis, MN for crying out loud!

 

At any rate, the author of today's haiku remains confident that the temperature will hit 70 degrees before the day is out. (But, then again, he also remains confident that he could play centerfield for the Yankees if they'd just give him a chance.) To that end, in fact, he has already polished up his mountain bike and made plans to sneak out early and hit the trails.

 

Note. We should probably clarify that, when he says "sneak out early," he means sneak out after he has put in a full day's work, plus the overtime hours that he puts in on a regular basis (not because he needs to work extra but because he wants to work extra), and only after he has planned out an agenda for all the work he'll be doing at home over the weekend.

 

That's what he means when he says "sneak out early."

 

In the meantime, of course, we need a haiku for today. Let's see, which Lync Server PowerShell nouns haven't we discussed yet … oh, here's a good one: CsClientVersionConfiguration.

 

Note. You're right: that's a really good one. We stand corrected.

 

Lync Server's 2010 client version capabilities are one of the more useful, yet one of the least-talked about, of all the Lync Server features.

 

Note. What's that? Considering that it's our job to talk about Lync Server features, wouldn't that make it our fault that this is one of the least-talked about of all the Lync Server features? Hmmm ….

 

As you probably know, Lync Server gives you the chance to determine which client applications users can use to log on to the system and which ones they can't. If you enable client versioning, then each time a user tries to log on, Lync Server will run a check to determine which application, and which version of the application, the user is trying to log on from. How specific you want to make this check is entirely up to you: you can simply determine whether the user is running Office Communicator 2007 R2, or you can go so far as to determine the build number of Office Communicator 2007 R2, as well as the latest update that the user installed.

 

How does Lync Server do this? Well, to begin with, administrators create a series of client version policy rules. (And yes, Lync Server ships with 10 of these rules predefined for you, giving you a head start on the process.) These rules identify a particular client application (such as Office Communicator 2007 R2) and specify what you're going to do if a user tries to log on with that application: will you allow them to log on, will you prevent them from logging on, etc. These rules are then collected into client version site policies, which can be applied at the global, site, or service scope (Registrar service only).

 

So then what are the client version configuration settings for, and why do we need the client version configuration cmdlets (Get-CsClientVersionConfiguration, New-CsClientVersionConfiguration, Remove-CsClientVersionConfiguration, and Set-CsClientVersionConfiguration)?

 

As it turns out, the client version configuration settings perform two important functions. First, they enable and disable client versioning. Let's say you just installed Lync Server 2010. Do you want to allow users to log on using Office Communicator 2007 R2? Good question: what exactly would it mean to log on using Office Communicator 2007 R2? If you disable client versioning you can go ahead and log on using any client application (including Office Communicator 2007 R2) and see for yourself what it would mean. After running a few tests like that, you can then make a more-informed decision as to whether that client should be allowed or not.

 

The other thing that the client version configuration settings do is specify the action to be taken if someone tries to log on with a client application that doesn't show up on any client version policy rules. What does that mean? Well, suppose you've decided that you're going to allow people to log on only using Microsoft Lync 2010. How do you prevent people from logging on with other client applications? Well, one way would be to identify every possible client application in the world, and create separate client version policy rules for blocking those applications. And, of course, create one client version policy rule for allowing Lync 2010.

 

But here's a better idea: create one client version policy rule that allows people to log on with Lync. After that, modify your client version configuration settings so that anyone trying to log on with a client not specified in a rule (that is, any client other than Lync 2010) is blocked. That's way easier and, when it comes to system administration, easier is almost always better.

 

Let's show you how this works in real life. Assuming we've set up the required client version policy rules, and added them to the appropriate client version policy, let's now configure the Redmond site so that: 1) client versioning is enabled; and, 2) we're going to block anyone trying to log on with a client that isn't called out in a client version policy rule. Here's how we do that:

 

New-CsClientVersionConfiguration –Identity site:Redmond –Enabled $True –DefaultAction Block

 

Well that was easy, wasn't it? Alternatively, we could have set the DefaultAction to Allow; that would allow anyone with an unknown client to go ahead and log on to Lync Server:

 

New-CsClientVersionConfiguration –Identity site:Redmond –Enabled $True –DefaultAction Allow

 

Or, we could have set DefaultAction of AllowWithUrl or BlockWithUrl. What would those actions do? Well, as the name implies, they'll either allow the logon or block the logon. In addition to that, however, they'll also present the user with a URL where they can go download an approved client. And where does that URL come from? From you: you specify the URL by tacking on the DefaultUrl parameter. For example:

 

New-CsClientVersionConfiguration –Identity site:Redmond –Enabled $True –DefaultAction BlockWithUrl –DefaultUrl "https://www.litwareinc.com/client"

 

Of course, all of that assumes that you need to create new settings for the Redmond site. If you already have client version configuration settings at the Redmond site then you can use Set-CsClientVersionConfiguration to modify those settings:

 

Set-CsClientVersionConfiguration –Identity site:Redmond –Enabled $True –DefaultAction BlockWithUrl –DefaultUrl "https://www.litwareinc.com/client"

 

Again, pretty easy.

 

And there you have it. Meanwhile, the temperature in Redmond has quietly crept up to 56 degrees. (Although, according to weather.com, it "Feels Like: 56o".) That means it's just about time for us to … uh, continue putting in a normal day's work ….

 

Oh: plus a little overtime. As usual.