The very first time I deployed a Windows Server 2008 machine, I quickly became aware of some of the features that were lifted from Windows Vista when Microsoft transformed the desktop OS into the server OS.  The one that simply drove me crazy was the User Account Control, or UAC for short.

On the desktop, I see the benefit – keeping users from hurting  themselves when dealing with the rest of the world.  Makes complete sense.  Mainly because this was Microsoft’s attempt at mimicking the Linux/Unix root user-normal user operations.

But I think that Microsoft hasn’t implemented UAC the properly – especially when you apply it to servers.

I say that because, and hang with me here, I feel that not just anybody should be working on production servers!  I don’t think that John Doe, fresh out of school is qualified enough to be given administrative rights to machines that control the livelihood of a company.  I’m sorry, but I simply don’t.  Microsoft, on the other hand, does.  So they simply dropped the UAC from Vista into Server 2008 and left the upgraded version of UAC from Windows 7 in Server 2008 R2.

Herein lies my complaint.  While I see the benefit of UAC and if it were implemented a bit differently I would applaud it’s use, I don’t think that server administrators should be hampered by it.

Let me explain.

In the Windows Server 2003 and earlier days, when a domain was created, the active directory created several groups with which one could spread around administrative authority.  One of these groups, the “Domain Admins” group holds a great deal of power.  Anyone who had an account in that group basically had full control of every machine tied to that domain.  (We’ll keep it simple and not talk about multiple-domain forests, etc, OK?)  There was no UAC to get in the way.  This meant that before anyone was put into that group they needed to be trustworthy, knowledgeable and respectful of the power that they now had.  Being a member of that group allowed a person to perform many tasks that were denied to normal users – like installing software, changing group polices, installing printers, etc.

But there was a downside – users in that group were treated as local administrators on every computer in the domain.  This basically meant that every application that was started by that person ran at the same level of authority and could cause some some problems if it were buggy or malicious in nature.

Hence, everyone – including administrators – were meant to have “normal user” accounts and then everyone in the the admin team had a second account that was inside the admin group.  This second account was to only be used to perform individual tasks for short periods of time, reducing the security exposure.  For everyday tasks, the admins used their normal user accounts.

This is the way that I have been running my networks – even when they involved Linux machines.  I would log on as my normal user and, when needed, I would “elevate” my account to admin status for special tasks, dropping back to normal user when finished.  I made the choice when to use the elevated account and everything that I ran during that time ran as my elevated account.

And this is the crux of the issue that I am facing now.  You see, I no longer am in complete control of when to use this elevated status.  Microsoft has decided what requires elevated status and has put the UAC in between me and my servers.  These decisions may not always take in the “full picture” and certain tasks, when used in a certain way get dropped through the cracks.

Prime example – earlier this week, I needed to modify a logon script to deploy a shortcut to all my user’s desktops.  Not a problem, add one line to a batch file that already existed and move on.  Except now, I have a Windows Server 2008 R2 Domain Controller.  This server was built to replace the oldest domain controller I have.  Over the past several weeks, I’ve been slowly moving more and more duties to it.  At this point, it basically is the, to use a Windows NT term, Primary Domain Controller.  Primary for me now means that when something in the domain need to be done, I do it on this server and then the changes are replicated from it.

So I off I went to add my one line of code to the batch file.  I log on to the server with my admin account,  fire up the Group Policy Management Console, drill down to the logon script policy and open its properties. ( To this point, everything has worked as it would have in Server 2003 – no prompt asking for elevated privilege from the UAC, no notice that I may need elevated privileges other than the tale-tale small shield added to the GPMC’s icon in the program folder, which at first I simply didn’t notice.)

Once inside the policy’s properties, I click on a button to open the folder that contains the logon script itself.  BAM!!!  OH NO YOU DON’T!!  You don’t have permission to this folder!

What?  I’m logged on a Domain Admin, I even created the policy, the folder and the script in the first place.  What do you mean I don’t have permission?

This is when I notice that little shield.  I close the GPMC and this time, right-click the icon and choose “Run as Administrator”.  Do the song and dance getting to my script.  BAM!!!

What?   Again?  Even with elevated privileges?

Now I really am bothered.  So I ditch the GPMC and instead simply decide to use Windows Explorer to find the file and edit the thing and be done with it.  Off I go.  Drilling down through the folders in a manner that is really a pain.  I get the to the folder containing all of the group policy definitions.  I find the one that is supposed to contain my logon script and double-click it to open it.  BAM!!!!

Now, I’m simply worried.  Could I have done something when I deployed this server that is preventing me from making changes to Group Policies?  Is there something that I overlooked?  All kinds of disaster scenarios start to run through my mind.

But I take a step back and think – Why would I not have permission.  Could the folder simply not allow Domain Admins access?  I check the folder’s Access Control List and sure enough, Domain Admins have Full Control – exactly as I’d expect.  So why am I denied access?

A few days go by, a flurry of forum posts happen, and yesterday it came to me.  It was the UAC getting in the way.  Here’s my hypothesis.  When I fired up the GPMC, even when I did so with elevated privilege, I was able to access everything that might have been associated with the policy itself.  But the logon script is simply a file that the policy refers to – it’s not actually part of the policy – meaning to access it, I’d need to start another program.  When the “show files” button was pressed, it fired up Windows Explorer and it was told to open the proper folder.  But I’m thinking that the Explorer process was fired up in the non-elevated privileged mode.

I say this because I can fire up Windows Explorer in elevated privilege mode and drill down to the folder in question and (after telling Windows Explorer that I want access) can get into that folder and every folder below.  Just as it should be.

Here’s the way that I see UAC should work:  Once I enter elevated privilege mode, everything that I run afterwards should run in that elevated mode.  (Think “su -” in Linux.)

Or better yet – when I log on to a server as Domain Admin, please, for just one moment, assume that I know what I’m doing and let me do what needs to be done without getting in my way!