Haiku # 30
Published May 20 2019 02:57 PM 1,072 Views
Occasional Visitor
First published on TECHNET on Jan 21, 2011

Oh, you beautiful

Doll. Oh, you must be joking.

OU permission.

Before we launch into today's article we thought we should mention that time is running out in order to enter the first-ever Lync Server PowerShell One of These Things is Not Like the Others Challenge . Do you have to enter the Lync Server PowerShell One of These Things is Not Like the Others Challenge? Well, unfortunately for us, Microsoft's legal department repeatedly insists that you don't . On the other hand, picture this: it's several years in the future, and you're sitting around the breakfast table with your darling daughter. "Mommy," says your pride-and-joy, "How did you do in the first-ever Lync Server PowerShell One of These Things is Not Like the Others Challenge?" At that point, will you really be able to look your daughter in the eye and admit that you didn't even bother to enter the first-ever Lync Server PowerShell One of These Things is Not Like the Others Challenge?

We didn't think so.

Fortunately, time is still on your side: we'll continue to accept entries until 9:00 AM Pacific Standard Time on Monday, January 24, 2011. And yes, that looks like you have lots of time to get your entry in. On the other hand, there are people who believe that Judgment Day will arrive on May 21, 2011. What if they're off by a couple months and Judgment Day comes this weekend? Picture this scenario: you're standing in front of St. Peter and he says, "OK, this is just a formality, I simply need to verify your score on the first-ever Lync Server PowerShell One of These Things is Not Like the Others Challenge -- oh, dear. It appears we have a problem here …."

If that happens to you, those of us here at the Lync Server PowerShell blog will not be held responsible. After all, we warned you.

For now, however, let's focus on today's haiku. When you install Microsoft Lync Server 2010, one of the first things you do (or, to be more precise, one of the first things Setup does) is prepare your domain for the installation of the software; that's a process that includes such things as extending the Active Directory schema to allow for the addition of attributes specific to Lync Server as well as assigning the required Access Control Entries to the universal groups needed for managing and operating Lync Server. As a general rule, you don't have to do anything when it comes to domain preparation: you just sit back and wait for Setup to finish.

As we all know, however, general rules are made to be broken. If you have disabled permission inheritance on Active Directory then Setup will not be able to give the RTCUniversalUserAdmins group the permissions needed to manage users, computers, contacts, application contacts, and InetOrg persons. Domain administrators will still be able to manage these entities, but Lync Server admins won't.

Note . Is that a problem? Well, we're not exactly experts when it comes to Lync Server administration. But we do believe you're better off having admins who can do administrative tasks than admins who can't do administrative tasks.

So what are you supposed to do if you find yourself in this situation? For that matter, how do you even know if you're in this situation? Listen, don't worry about that: that's what the CsOUPermission cmdlets ( Grant-CsOUPermission , Revoke-CsOUPermission , and Test-CsOUPermission ) are for.

To begin with, if you aren't sure whether or not the proper permissions have been granted on a given OU you can verify that by using the Test-CsOUPermission cmdlet. All you have to do is run a command similar to this one:

Test-CsOUPermission –OU "ou=Redmond,dc=litwareinc,dc=com" –ObjectType "user", "contact", "inetOrgPerson"

As you can see, all we're doing here is checking to see if permissions exist for managing users, contacts, and inetOrgPersons. (The inetOrgPerson class is very similar to the user class, and is often used when you migrate to Active Directory from some other directory service.) Test-CsOUPermission will report back True if the required permissions are there or report back False if the required permissions are not there.

And yes, that is pretty easy, isn't it?

And what if Test-CsOUPermission does report back False? No problem; you can simply apply the correct permissions to the OU by running the Grant-CsOUPermission cmdlet:

Grant-CsOUPermission –OU "ou=Redmond,dc=litwareinc,dc=com" –ObjectType "user", "contact", "inetOrgPerson"

Note that Grant-CsOUPermission gives the necessary permissions only to the security groups who would typically be given those permissions when you run Setup. You can’t use this cmdlet to grant permissions to an arbitrary user or group. If you want that user or group to have user management permissions then simply add that user (or group) to the RTCUniversalUserAdmins group.

Oh, one more thing we should mention: when we set up the first-ever One of These Things is Not Like the Others Challenge, we accidentally configured the thing for "chain letter mode." That means that, if you fail to enter the challenge, and thus break the chain, you'll endure 10 years of bad luck. Is it really true that breaking the challenge chain will result in 10 years of bad luck? Let's put it this way: 10 years ago, the author of today's haiku broke a challenge chain. Recently, he received his official award for 10 years of service at Microsoft. Coincidence? Maybe. But, then again ….

Version history
Last update:
‎May 20 2019 02:57 PM
Updated by: