Haiku #1

[NextHop_Team]

First published on TECHNET on Nov 15, 2010

I am sorry, Dave.

I'm afraid I can't do that.

CsAdminRole.

We have entitled this haiku "Ruminations and Meditations on Cmdlets for Managing Role Based Access Control in Microsoft Lync Server 2010, Concerto in D Minor."

Commentary

As far as we know, HAL 9000 – the computer featured in the novel/movie 2001: A Space Odyssey and the inspiration for today's haiku – did not use Role Based Access Control (RBAC). We base that notion on the fact that the HAL 9000 tried to kill everyone around it; to the best of our knowledge, no computer running Microsoft Lync Server 2010, and using RBAC, has ever tried to kill anyone.

Note . Even more amazing, we've never heard of an administrator wanting to kill a computer that's running Microsoft Lync Server 2010. Not wanting to kill your computer? That might be unprecedented in software history.

You're probably already familiar with RBAC: after all, RBAC is the technology used in Active Directory and Microsoft Exchange to delegate administrative control. As a Lync Server administrator (particularly if you're an administrator in a large organization), there's a pretty good chance that you don't want to have to take care of all the management activities by yourself; instead, you might like to do things like give help desk personnel the right to, say, lock, unlock, or assign client PIN numbers. Which leads to an obvious question: how do you give your help desk the right to handle select tasks (like managing client PINs) without making each help desk person a full-blown administrator?

And the answer is: it depends. If you're asking, "How can I delegate administrative control in Office Communications Server 2007 R2?" then the answer is this: we have no idea; in OCS 2007 R2 that's not an easy thing to do. In Lync Server, however, we have a much better answer: use RBAC and the CsAdminRole cmdlets. We won't explain how RBAC works, at least not in this commentary. For more information, take a peek at the article A Brief Introduction to Role-Based Access Control – Part 1 .

Note . Good question: where is Part 2 of our introduction to RBAC? Well, to tell you the truth, we were just about to publish Part 2 awhile back when the product team elected to make a number of changes to Lync Server's version of RBAC. Those changes were major enough that we decided to hold off on Part 2 until the product was released and RBAC was complete. Now that the product is released, we'll get around to doing Part 2.

Well, assuming we can fit that into our schedule, which is currently chock-full of very important, very high priority items. You know, very important and very high priority things like writing Lync Server haikus.

In a nutshell, and leaving out some of the nuances, Lync Server ships with a number of predefined RBAC roles: CSVoiceAdministrator, CSHelpDesk, CSArchivingAdministrator, etc. Each of those roles has been assigned a set of cmdlets; those cmdlets represent the only things that users who hold a given role are allowed to do. For example, the CSArchivingAdministrator role has been assigned the cmdlet Grant-CsArchivingPolicy. That means that archiving administrators can assign users archiving policies. However, the CSArchivingAdministrator role has not been assigned the Grant-CsExternalAccessPolicy cmdlet. That means that archiving administrators cannot assign external access policies to users.

Pretty simple, right?

As for giving someone the role of archiving administrator, well, each RBAC role (e.g., CSArchivingAdministrator) corresponds to an Active Directory security group (a universal security group that, in this case, is also named CSArchivingAdministrator). To make someone an archiving administrator you just have to assign them to the CSArchivingAdministrator security group.

And yes, it really is that easy.

Before we call it a day, we should also point out one important thing to keep in mind when working with RBAC: RBAC roles only take effect if you are:

· Trying to manage Lync Server by using the Lync Server Control Panel.

· Trying to manage Lync Server by using a remote instance of Windows PowerShell.

In either of those cases, the cmdlets you'll be allowed to run, and thus the tasks you'll be allowed to perform, are based on the RBAC roles that have been assigned to you. However, suppose you log on locally to one of your Front End servers, open up the Lync Server Management Shell, and start managing Lync Server from there. In that case (that is, when you are managing Lync Server by using a local instance of Windows PowerShell) RBAC will not be used. Instead, your ability to carry out Lync Server management tasks will depend on your membership in one or more RTC security groups (e.g., RTCUniversalServerAdmins; RTCUniversalUserAdmins; RTCUniversalReadOnlyAdmins; etc.). But we'll explore that in more detail when we get around to writing Part 2 of our two-part RBAC series.

And yes, by now it should be pretty obvious that all the problems that occurred with HAL 9000 could have been avoided by using RBAC. Granted, the movie would have been nowhere near as exciting if HAL didn't go around killing everyone, but we have a feeling most people would happily forego action and suspense in favor of seeing the proper way of delegating administrative control of key IT management tasks. That's how you make a movie!

References

Get-CsAdminRole

New-CsAdminRole

Remove-CsAdminRole

Set-CsAdminRole

Get-CsAdminRoleAssignment