Haiku #125
It's always a great
Day if you have your client
Version policies.
Well, it's Monday, and the author of today's Lync Server PowerShell haiku is definitely excited about being back to work, especially after the weekend that he was forced to endure. How bad could that weekend have been? Well, on Saturday temperatures climbed well up into the 70s, and the author of today's haiku took a 34-mile bike ride along the Centennial Trail in Snohomish County. And while temperatures were a tad bit cooler on Sunday, it was still shorts and T-shirt weather, and the author of today's haiku took a nice long walk around the Kirkland waterfront. And on both days it was dining al fresco, out in the fresh air and sunshine: once at a funky little steakhouse/tavern and once at a Mexican restaurant.
Hint. Try the barbecued meat loaf sandwich with caramelized onions and provolone cheese. Surprisingly good.
At any rate, after all that it's a relief to finally be cooped up once more in a cramped little office, writing about Lync Server PowerShell.
As you would expect.
Speaking of Lync Server PowerShell, today we're going to talk about the CsClientVersionPolicy cmdlets: Get-CsClientVersionPolicy, New-CsClientVersionPolicy, Remove-CsClientVersionPolicy, and Set-CsClientVersionPolicy. (Yes, now you can see why we were so excited to come back to work today!) As you probably know, Lync Server 2010 uses client version policies to determine which client applications can be used to log on to the system and which client applications can't be used to log on to the system. Why would you even care which client application someone used to log on to Lync Server? Well, believe it or not, there are a number of different reasons. For one thing, client applications differ in their capabilities: Microsoft Lync 2010 lets you do way more things than you can do with Office Communicator 2007. If you allow users to log on using any old client application then you'll have to deal with the fact that some users will be able to do A, B, and C, and other users won't.
Likewise, you'll also be faced with the prospect of having to support all these different applications. Depending on your situation that might not be that big of a deal, and you might not have much choice in the matter. But, at the very least, you can use client version policies to ensure that users are using the latest and most up-to-date version of Office Communicator 2007 and not an early beta version that was released sometime in October of 1871.
Without going into a detailed explanation of how the client versioning system works, suffice to say that the system relies on a series of client version policy rules, rules that specify a particular client application (down to the build level, and even down to the patches and updates that have been applied to the application) and specify what Lync Server should do if someone tries to log on using that application:
· Allow. The user will be allowed to log on.
· AllowAndUpgrade. The user will be allowed to log on, and his or her copy of Office Communicator 2007 R2 will automatically be upgraded to the latest version of Lync.
· AllowWithUrl. The user will be allowed to log on, and a message will be displayed pointing the user to a URL where the latest version of Lync can be downloaded and installed.
· Block. The user will not be allowed to log on.
· BlockAndUpgrade. The user will not be allowed to log on, but his or her copy of Office Communicator 2007 R2 will automatically be upgraded to the latest version of Lync.
· BlockWithUrl. The user will not be allowed to log on, but a message will be displayed pointing him or her to a URL where the latest version of Lync can be downloaded and installed.
These client version policy rules are bundled together in client version policies, which can be assigned to the global scope, the site scope, or the service scope. (That is, each Registrar could have its own client version policy.)
To be perfectly honest, there isn't much to a client version policy other than a collection of client version policy rules. And that's actually a good thing: that means all you have to understand in order to manage your client version policies is how to deal with client version policy rules.
Of course, there are a number of things you need to know about those rules in order to get things to work just exactly right, and the daily haiku probably isn't the best forum for a detailed and comprehensive look at client version policies.
Note. What's that? What is the daily haiku the best forum for? We'll have to get back to you on that one.
However, here are a few little tricks that you might find useful.
To begin with, any time you create a new client version policy you will, by default, get a bunch of predefined rules along with that policy. Is that good or is that bad? Well, it depends. However, if all you want to do is apply the same default rules then there probably isn't much reason to bother creating a new client version policy in the first place.
Which simply means that you might want to start with a blank slate any time you create a new client version policy; that is, you'd like a policy that doesn't have any client version rules. Can you do that? Of course you can; all you have to do is set the Rules parameter to a null value:
New-CsClientVersionPolicy –Identity "site:Redmond" –Rules $Null
That's going to give you a policy that looks like this:
Identity : site:Redmond
Rules : {}
Description :
If you want to add a new rule or two to this policy (which we assume you do) you can do that in one of two ways (at least). For one, you can use the New-CsClientVersionPolicyRule cmdlet to create a new rule, like so:
$x = [guid]::NewGuid()
New-CsClientVersionPolicyRule -Parent "site:Redmond" -RuleId $x -MajorVersion 4 -UserAgent InHouse
Two things to watch out for here. First, a client version policy rule has an Identity that consists of two things: the policy to which the rule is being assigned (e.g., the Redmond site) and a globally unique identifier (GUID). In order to create a new rule, and get it assigned to the appropriate policy, we need to use the NewGuid method to create a GUID, and set the value of the Parent property to the correct client version policy.
Which we seem to have done. Good for us!
Second, you don't need to assign this new rule to the correct policy; Lync Server will do that for you based on the Parent property.
Now here's a cool little trick. Suppose you want to create a new rule and assign it to all your client version policies. How many commands do you suppose that will take?
Oh. Well, you're right: 2. (We were kind of hoping you'd say, like, 10,000 or something.) But yes, here's a set of commands that create a new rule and then adds that rule to all your client version policies:
$x = [guid]::NewGuid()
Get-CsClientVersionPolicy | ForEach-Object {New-CsClientVersionPolicyRule -Parent $_.Identity -RuleId $x -MajorVersion 4 -UserAgent InHouse}
Not bad, huh? Here's another useful little trick. This command copies a rule from one client version policy to another:
$x = Get-CsClientVersionPolicyRule –Identity "global/74ba9211-8610-42f9-91ba-846cdee98820"
Set-CsClientVersionPolicy –Identity "site:Redmond" –Rules @{Add=$x}
What we've done here is use the Get-CsClientVersionPolicyRule cmdlet to retrieve a specific rule (with the RuleID 74ba9211-8610-42f9-91ba-846cdee98820) from the global policy, storing that rule in a variable named $x. We then use the Set-CsClientVersionPolicy cmdlet to add that rule to the rules already in the policy for the Redmond site. Could we instead replace all the rules currently in the Redmond site with this one rule copied from the global policy? Of course we can:
$x = Get-CsClientVersionPolicyRule –Identity "global/74ba9211-8610-42f9-91ba-846cdee98820"
Set-CsClientVersionPolicy –Identity "site:Redmond" –Rules @{Replace=$x}
Etc., etc.
That's all we have time for today. The sun is shining behind us, so we're going to pull the blinds, close the door, hunker down, start drilling into some of the truly exciting new things we're supposed to be working on, and enjoy ourselves.
For a change.
See you tomorrow.