Haiku #153

We're gonna party

Like it's 1582.

Setup permissions.

 

Last week the author of today's haiku got an interesting email from one of the internal departments here at Microsoft, a message that said, in part, "You are receiving this message because you have been identified as a(n) requester/approver of at least one purchase order with a PO line item delivery date impacted by the shift to the Gregorian calendar."

 

Now, the author of today's haiku found this interesting for two reasons. For one, there's the notion that had been identified as a "requester/approver of at least one purchase order;" to be honest, he found it really, really hard to believe that Microsoft would let him have anything whatsoever to do with money.

 

Note. Just to be on the safe side, however, he went to the internal Web site, entered his email address, and checked to see if by some weird happenstance he really was a requester/approver of at least one purchase order; he wasn't. To add insult, he could have sworn that he heard the Web site snicker when he entered his email address and clicked the My Requests/Approvals button.

 

What he really found interesting, however, was this part of the message " … the shift to the Gregorian calendar." As you probably know, the Gregorian calendar was introduced by Pope Gregory XIII back in February of 1582. The Gregorian calendar was devised to fix a few problems with the Julian calendar, problem number 1 being the fact that the Julian calendar miscalculated the length of a year by about 11 minutes. That might not sound like a very big deal, but that does result in the loss of about three days every 400 years; if the Julian calendar was still in effect, today would actually be July 2, 2011 and we'd all get to live the past 13 days all over again.

 

That's what we said: how … nice ….

 

Note. There would be at least one bright side, however: seeing as how we've already written the daily haikus for July 2nd through July 15th, we wouldn't have to do hardly any work for the next two weeks.

 

Hmmm, interesting question: how would that be different from what we typically do (or don't do)?

 

After the proposed new calendar was unveiled, the new system was adopted by a number of Catholic countries within a year. However, many Protestant countries refused to make the switch, viewing the new calendar as some sort of Catholic plot to take over the world.

 

Note to Hollywood movie producers. Is there a potential film here, something about a mad scientist who plots to take over the world by creating a new calendar? Just wondering.

 

Eventually, however, every country in the world had little choice but to make the change. Great Britain held out until 1752; when they finally chose to adopt the Gregorian calendar, Wednesday, September 2, 1752 was followed by Thursday, September 14, 1752. Russia finally made the switch in 1918, and Greece followed in 1923.

 

And now, at long last, Microsoft is also switching to the Gregorian calendar. Hurrah!

 

Note. OK, we should probably clarify that – as near as we can tell – Microsoft has not been using the Julian calendar instead of the Gregorian calendar; instead, the switch involves aligning some internal fiscal calendar to some other external reporting calendar. Which is too bad: for some reason, we really liked the thought of Microsoft refusing the buckle under to peer pressure and sticking with the Julian calendar.

Incidentally, if you think you're concerned about the ramifications of this calendar switch, well, imagine how the author of today's haiku felt. Fortunately, though, he was able to watch an internal video about the change called It's Going to Be Okay. And guess what? It's going to be okay.

 

Of course, you're probably thinking that, if Microsoft is just now switching to the Gregorian calendar, well, that must mean that Microsoft is a stodgy old company that couldn't possibly do anything useful or cool. Do we have anything to counter that belief? You bet we do: the CsSetupPermission cmdlets (Grant-CsSetupPermission, Revoke-CsSetupPermission, and Test-CsSetupPermission).

 

So what's so useful, and cool, about the CsSetupPermission cmdlets? Well, you might not be aware of this, but when you run the domain preparation phase of Lync Server setup, setup does not automatically add the permissions that enable members of the RTCUniversalServerAdmins group to run the Enable-CsTopology cmdlet. Does that matter? It might; after all, that means you must be a domain administrator in order to enable a topology. In some organizations, that might not matter: the domain administrator and the Lync Server administrator are one and the same.

 

In other organizations, however, it might matter: you might not want to give your Lync Server administrators domain admin rights. The solution? Run the Grant-CsSetupPermission cmdlet to give members of the RTCUniversalServerAdmins group the right to install and enable Lync Server.

 

Note. So what exactly does it mean to give someone the right to install and enable Lync Server? Beats us. Fortunately, though, you don't have to rely on us to provide you with that information; instead, Jens Trier Rasmussen has written a blog post that provides an in-depth look at the permissions that are actually granted when you run the Grant-CsSetupPermission cmdlet.

 

As for actually running Grant-CsSetupPermission, well, that's not too terribly complicated; all you have to do is run a command similar to this:

 

Grant-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

 

As you can see, all you have to do is call Grant-CsSetupPermission along with the ComputerOU parameter; the parameter value for ComputerOU is simply the distinguished name of the Active Directory container where your Lync Server computer accounts are residing. You say that entering the distinguished name of the Active Directory container is too much trouble? That's fine; as long as that container is located with the domain root you can run a command like this one instead:

 

Grant-CsSetupPermission -ComputerOU "ou=CsServers"

 

We thought you might appreciate that.

 

We should probably point out two things before we go any further. First, setup permissions can only be granted to the RTCUniversalServerAdmins group; there's no way to grant these permissions to any other group. The moral of the story? If you want someone to be able to setup and enable Lync Server, you need to add them to the RTCUniversalServerAdmins group.

 

Second, you must be sure to run this cmdlet against each and every Active Directory container housing Lync Server computer accounts. What if your Lync Server accounts are in several different OUs? That's fine; you'll just have to run the command several different times:

 

Grant-CsSetupPermission -ComputerOU "ou=CsFrontEndServers,dc=litwareinc,dc=com"

Grant-CsSetupPermission -ComputerOU "ou=CsBackEndServers,dc=litwareinc,dc=com"

Grant-CsSetupPermission -ComputerOU "ou=CsEdgeServers,dc=litwareinc,dc=com"

 

Or, if you want to get fancy:

 

"ou=CsFrontEndServers,dc=litwareinc,dc=com", "ou=CsBackEndServers,dc=litwareinc,dc=com",

"ou=CsEdgeServers,dc=litwareinc,dc=com" | ForEach-Object {Grant-CsSetupPermission –ComputerOU $_}

 

Note. Here's another quick hint: keep in mind that the Computers container in Active Directory is not an OU; instead, it's just a container. If you have Lync Server machines in the Computers container you'll need to use a command like this one to grant setup permissions:

 

Grant-CsSetupPermission -ComputerOU "cn=Computers,dc=litwareinc,dc=com"

 

Note the syntax cn=Computers instead of ou=Computers.

 

If you later change your mind, and decide that you don't want the RTCUniversalServerAdmins group to have setup permissions after all, well, then just use the Revoke-CsSetupPermission cmdlet to revoke those permissions:

 

Revoke-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

 

Last, but definitely not least, you can verify the permission status for a container by using the Test-CsSetupPermission cmdlet:

 

Test-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

 

That command will return the value True if permissions have been granted to the specified container. And if permissions haven't been granted to the specified container? You got it: the command will return False.

 

Which, all in all, makes a lot of sense.

 

And there you have it. We hope you enjoy the weekend (which, we hasten to point out, would already be half over if we were still using the Julian calendar). Enjoy the Gregorian calendar, and we'll keep you posted on any other new developments here at Microsoft; for example, any day now we expect to announce that the sun does not revolve around the Earth. Stay tuned!