Haiku #191

Group Policy gone?

How can we go on? Oh, right:

Client policies.

 

In case you've been wondering whether or not today's going to be a good day, well, here's your answer: no, today is not going to be a good day.

 

At least not here in the Seattle area. For one thing, it's cloudy and overcast yet again. For another, it took the author of today's haiku – who only lives about 10 miles from Microsoft – over 40 minutes to get to work this morning, mainly because of one .4 mile stretch that took nearly 15 minutes to get through.

 

Note. Why did it take 15 minutes to go less than half a mile? Because there are too many people here, and the vast majority of them don't have the slightest idea how to drive a car.

 

At any rate, if you do the math – and don't worry, you don't have to do the math because we did it for you – if the entire journey had proceeded at the same pace (15 minutes to go .4 miles) it would have taken the author of today's haiku over 6 hours to make the 10-mile drive to work. Figuring that he'd probably have to stop for gas along the way, and stop to eat at least once during that time, the trip would probably take closer to 7 hours, meaning that he would have arrived at work just in time to turn around and go home.

 

So, OK, maybe there would be an upside to that after all.

 

And before you ask, no, taking the bus is not an option. The author of today's haiku would love to take the bus to work, but for him to take the bus to work means:

 

· A 10-15 minute walk to the bus stop.

· A half hour bus ride to downtown Kirkland.

· A half hour wait for the next bus. (Sadly, there aren't any busses that go directly from his house to Microsoft.)

· A 10-15 minute walk from the bus stop near Microsoft to his office.

 

Add that all up and you get about 7 hours once again. And that's assuming that the busses run exactly on schedule, which is no guarantee.

 

And no, riding his bike to work is out of the question, too. So far this summer there have been 9 or 10 fatal cases where a bike rider has been hit by a car. The author of today's haiku doesn't like riding in a car on the streets around here; there's no way he's riding a bike on those streets.

 

To be perfectly honest, the only solution is just to quit his job and stop working altogether. That would wreak havoc on the mortgage, but would definitely cut down his commuting time.

 

And, for once, his coworkers would support him 100%!

 

On the bright side, however – well, never mind, we can't actually think of a bright side to anything this morning. So let's talk about the CsClientPolicy cmdlets instead (Get-CsClientPolicy, Grant-CsClientPolicy, New-CsClientPolicy, Remove-CsClientPolicy, and Set-CsClientPolicy).

 

Now, admittedly, you might think that the mere mention of the CsClientPolicy cmdlets would be enough to put a smile on the face of the author of today's haiku. For better or worse, however, the client policy cmdlets present administrators (and haiku writers) with a mixed bag of goodies: there are some really, really good things about the client policy cmdlets, and then there are some not-so-good things about the client policy cmdlets. But let's talk about the good things first.

 

The client policy cmdlets were primarily designed to replace the Group Policy settings used in Office Communications Server 2007; all you have to do is look at many of the client policy parameter names to see that. Need an example of that? OK, how about this one: the parameter BlockConversationFromFederatedContacts is equivalent to the old Group Policy setting Block conversation from federated contacts. And, needless to say, there are plenty more examples where that came from.

 

So why didn't we just keep Group Policy? Why did we create these new client policies? Well, Group Policy is very powerful and very useful, but it definitely has its limitations. For one thing, Group Policy only applies to people who actually log on to the network: if you access Lync Server remotely (which many people do these days) Group Policy doesn't get applied to you. (Which means you might have a very different experience depending on how you access the system.) In addition to that, Group Policy is designed to apply to Active Directory: you assign policies to OUs or to domains. With Lync Server, however, there are often settings that you want to target much more finitely: you want salespeople in the Sales department to have different capabilities than accountants in the Finance department. Can you do that sort of targeting with Group Policy? Yes, sort of. But, take it from someone who's tried this, it's not easy.

 

At any rate, client policies make user/client administration much, much easier; if nothing else, policy resolution is much easier in Lync Server than it is in Group Policy. In Lync Server, per-user policies trump per-service policies which trump per-site per site policies which trump global policies. That's way easier than Group Policy, in which you have to worry about domain-level policies, OU-level policies, machine policies vs. user policies, inheritance vs. non-inheritance, etc., etc. Oh, and with Lync Server policies, the entire policy gets applied in-toto. You don't have to worry about settings from some other policy "trickling" down and affecting a user.

 

In short: client policies are better. Way better.

 

And client policies are much easier to create as well. For example, suppose you want to create a new per-user client policy that limits users to no more than 50 contacts. How do you do that? Why, like this, of course:

 

New-CsClientPolicy -Identity RedmondClientPolicy –MaximumNumberOfContacts 50

 

And then what if you want to assign that policy to Ken Myer? That's just as easy:

 

Grant-CsClientPolicy -Identity "Ken Myer" –PolicyName RedmondClientPolicy

 

Or, if you prefer, you can assign that policy to all the salespeople in the Sales department:

 

Get-CsUser -LdapFilter "(&(Title=Salesperson)(Department=Sales))" | Grant-CsClientPolicy -PolicyName RedmondClientPolicy

 

In case you're wondering, what we've done here is use the Get-CsUser cmdlet to return all the salespeople in the Sales department. And how exactly do we get all the salespeople in the Sales department? By using the LdapFilter parameter and this filter value:

 

"(&(Title=Salesperson)(Department=Sales))"

 

That's a bit complicated-looking, but it simply tells Get-CsUser to return all the users whose Active Directory Title attribute is equal to Salesperson and (the & character) whose Department attribute is equal to Sales. We then pipe all those user accounts to the Grant-CsClientPolicy cmdlet which, in turn, assigns each user the policy RedmondClientPolicy.

 

Note. You know, you're right: it would be cool to know how to write filters for the LdapFilter parameter, wouldn't it? If that's something you're interested in, take a peek at the article Retrieving Active Directory and Microsoft Lync Server 2010 User Accounts.

 

Of course, by now you're probably thinking, "These client policies and client policy cmdlets look fantastic! What could possibly be wrong with them?" Well, for the most part nothing. However, it is true that some of the New-CsClientPolicy and Set-CsClientPolicy parameters (and thus some of the settings you think you can set) don't actually work. For example, the TabURL parameter, which ostensibly helps you add custom tabs to the Microsoft Lync window? Well, that parameter doesn't work: it won't let add custom tabs to the Microsoft Lync window. The same is true for the ShowRecentContacts parameter: ShowRecentContacts doesn't actually work, either. The vast majority of parameters do exactly what they purport to do. Unfortunately, however, there are a couple of exceptions.

 

Note. So how did we end up with parameters that don't work? Well, it's a long story, and it mainly has to do with the fact that Lync Server development and testing were going on right up to the moment that the product shipped. The fact of the matter is that, with a big, complicated, largely-rewritten-from-scratch piece of software like Lync Server there were bound to be a few minor issues that slipped through the cracks. We'd still like to do an extensive look at all the client policy settings and what they actually do or don't do (similar to what we did with conferencing policies) but up until now we just haven't had the time to undertake such a big project. But we'll see. We'll see.

 

But don't let the fact that the TabURL parameter doesn't work keep you from using client policies; like we said, most of the parameters – like limiting the number of contacts a user can have (MaximumNumberOfContacts), adding a disclaimer to instant messaging sessions (IMWarning), including Microsoft Outlook calendar data in your presence information (DisableCalendarPresence) – work just fine, and can be extremely useful as well.

 

That's pretty much all we have to say about client policies; as you might expect, you can use the Get-CsClientPolicy cmdlet to return information about your existing policies, and you can use the Remove-CsClientPolicy cmdlet to delete any of those existing policies. One thing that might not be readily apparent, however, is the fact that the client policies include a pair of properties – EnableHotdesking and HotdeskingTimeout – which actually apply to common area phones rather than to users or to Microsoft Lync. "Hot desking" refers to the ability of an individual user to log on to a common area phone using his or her own credentials, and thus have access to their own contacts. If you'd like to enable hot desking you'll need to create a client policy for your common area phones; for example:

 

New-CsClientPolicy –Identity CommonAreaPhonePolicy –EnableHotdesking $True –HotdeskingTimeout 00:15:00

 

You can then use a command like this one to assign that policy to all your common area phones:

 

Get-CsCommonAreaPhone | Grant-CsClientPolicy –PolicyName CommonAreaPhonePolicy

 

Just something we thought you should be aware of.

 

At any rate, that's all we have for now. Enjoy the rest of the day (yeah, right), and we'll see you again on Monday.