I could not remote desktop to one of my servers so I actually had to get up and walk over to it.

Sheesh!

I had the firewall already happy, had Remote Desktop enabled. Luckily, the solution was fairly easy to fix. The server was part of a cluster and it had the network connection listed as Public, not Work. If this happens to you, simply open up the Network and Sharing Center, right click on the appropriate 'active network' and select Work.

My favorite bit in the description for Work network is "Don't choose this for public places such as coffee shops or airports." Hey, but what if I work there???

My Windows Update service on one a w08r2 x64 box told me that I had an update.

So I checked and discovered that it was KB967723.

I ran the install but it failed with error code 80070490

After trying various solutions (such as turning off the Windows Update service and moving the log files) I finally manually downloaded the problematic file and installed it. No more problems. I don't know what was the issue - was it snagging the x86 version? was it getting the Vista one? Whatever triggered it, this resolved it.

Download Locations:

• x64 - http://www.microsoft.com/downloads/details.aspx?familyid=6E46822E-F79D-492D-AD01-EE680AD324F5&displaylang=en
  
• x86 - http://www.microsoft.com/downloads/details.aspx?familyid=35c1d5a9-a953-4fc6-90c0-d2358c7b89e6&displaylang=en
  

We recently had a case where a user moved a folder into another folder expecting that the permissions in the parent folder would automatically roll on down. Of course they did not, when you copy WITHIN a volume it maintains its original perms.

What was really interesting is what happened when we tried to use the ole 'Replace all child object permissions with inheritable permission from this object'. Although the user was copied down, the perms were not. The user DID NOT get the inherited perms on the sub objects.

You have to dig to find the correct checkbox.

• Open up the properties for the parent folder
• Selected "Advanced"
• Select "Change Permissions"
• Make sure "Replace all child object permissions with inheritable permissions from this object" is checked.
• Click on the user/group that you want to push the perms down for and select the "Edit" button
• Make sure that the "Apply these permissions to objects and/or containers within this container only IS CHECKED (note it is not checked in my image)
• Click 'OK' till you are done...

This was verified by checking the logs. I tried many, many things to resolve it, including making sure "Network Service" had full control over the 14-hive, per this blog and setting up Network Service using the aspnet_regiis -SampleKeys, etc. I even disabled the UAC (see my earlier post for an explanation).

No dice.

The resolution lay, as you may be suspecting, in messed up perms on the RSA folder, specifically C:\Program Data\Microsoft\Crypto\RSA\MachineKeys. I had checked to the RSA level and Administrators had full perms (I was logged on as with an Administrative account) but I had not taken the next step and checked MachineKeys.

Turns out that that folder had removed all perms from Adminstrators. I ended up having to take ownership of the folder and give Admins full perms again. Sure enough - it worked...

As a bonus it DID fix my Search problem (I was getting "The search request was unable to connect to the Search Service.").

Maybe.

There appears to be an issue with w08r2 when it comes to using Hyper-V. When attempting to launch your VM you might encounter the error: The application encountered an error while attempting to change the state of %yourVM%.

The solution seems very simple (thanks to this post) which is that you need to give 'Authenticated Users' the 'List folder / read data' permission at the root of the drive that contains the Virtual Machines (and you ONLY need to do it at that level, not the ones below).

Why this solves the problem I do not know, but here are the steps (with some pictures) to walk you through the process:

1 - Open up the root of the drive's properties and choose the Security tab. Click on the Advanced button

2. Click on 'Change Permissions'

3. Click on 'Add', Type in 'Authenticated Users' and hit the OK button, you should see the screen below. Change the "Apply to:" to be "This folder only" and put a check in to the "List folder / read data" check box. Click 'OK'

4. Make sure NOT to check the 'Replace all child objects...' checkbox. Check your settings, and click OK. Click OK to close the Properties screen for the drive and you should be good to go.

When clustering two servers together you may still want to set up private network connections. If you do hook a crossover cable and give it a different set of IPs from your domain you may find that the private network does not working. Pinging will return no responses. What you may have run into is that the Windows Firewall is interpreting your little private network as being 'Public' and so is block all communications in.

The solution depends on what flavor of w08 you are running. If you are running w08 you can go into the "Network and Sharing Center" and customize the network to be "Private" which will allow communication through. If you are running w08r2 it is not so simple. You have to go into Windows Firewall and explicitly tell it NOT to apply "Public" rules to the adapter you are using for your private network. 

Because a picture is worth a thousand words:

Windows 2008 (non-R2)

Windows 2008 R2

When are Domain Admins NOT Domain Admins?

I stumbled across some strange errors when using the UAC as a Non-Default Admin (NDA). When logged in as an NDA and not the Built-In Administrator Account (BIAA) I ran into permission issues with the User Access Control (UAC) turned on. It appeared as if the w08 box (and w08r2) could not enumerate Domain Admins membership then the UAC is turned on. Even when I gave Domain Admins Full Control of a folder (or a drive) it would not recognize membership therein.

More info (than you might want) on that at my entry here: http://www.myfriedmind.com/techBlog/2009/10/14/UACAndDomainAdminsPermissionsIssueOnWindows2008.aspx.

This is the follow up to that, after I got a hold of MSoft. I called in and even though it was the middle of the night for the gentleman on the other end of the line (he was in India) he was very coherent and helpful. Or perhaps, helpful is not the right word since I found the solution that Msoft suggests rather, ummm, absurd. This should not reflect on him at all, he was great, it is just the, ummm, solution that is whacky.

After some testing with me he did verify that I was right and that the issue was with the Domain Admins membership enumeration. He then did some research and located this article: http://technet.microsoft.com/en-us/library/cc772207(WS.10).aspx.

This lays out what is triggering the issue, how w08 (and Vista) handle Admin Approval Mode (AAM). Again, you can read my earlier post for more background if you want. Basically, Domain Admins, unlike ALL OTHER USERS, are given two tokens. They have the full access token (like everyone else) and a second access token referred to as the filtered access token. This filtered access token has the administrative powers removed. Explorer.exe (ie the root of all) is started with the filtered access token, and thus everything is started with it.

Think of it is as RUNAS in reverse. Rather than being a Domain Admin you are reduced to peon status. It is, in effect, kryptonite.

The solution that MSoft gave was very simple – do not use the Domain Admins account. At least for file and folder permissions. Create a TOTALLY NEW group and assign the people that you would normally have as Domain Admins in there. Then give THAT group the permissions that you want.

You know, that answer still makes me chuckle. What a stupid, stupid solution. Here's why

1. It does not actually do the AAM thing. It does not ask me for consent, credentials, whatever I have it set to. It just says NO when I try to access a folder. No discussion. So UAC is not actually doing its job here.
2. I can access the share of the drive or the folder if I do it via shared drives. It is only an issue if I am logged on directly to the box. I really get using UAC to prevent malicious software install, but to stop me from opening a folder??? So now I need to be the Domain Admins to log on to the server, but something completely different to access a folder.
3. It has no affect on the Built-In Administrator Account.

I already have a group that I want to use for file and folder permissions or sensitive areas. The Domain Admins. And with good reason, because they are the DOMAIN ADMINS!!!!!!!! Now I have to track two groups. All because the UAC will not play well with others.

Here is my solution –> Hey UAC! Buh-bye!!!!!

Note - this is tested on a Windows 2003 R2 domain.

Further note - I have corrected it a bit - specifically the problem applies ONLY to Domain Admins - see http://www.myfriedmind.com/techBlog/2009/10/20/UACAndDomainAdminsPermissionsIssueOrPocketFullOfKryptonite.aspx for more info.

A while ago I noticed something odd on my Windows 2008 clustered file server. When I tried to open the clustered drive that I was using to hold my shares  from the box while logged in as a non-default admin (hereafter referred to as NDA) I got a message stating “Access is denied”.

This only happened if I was logged into the box itself in the server room or via Remote Desktop. I could access the hidden share for that drive remotely with no problem. Also, if I logged on with the built-it administrator account (hereafter referred to as BIAA) I had no problem. Finally, if I disabled the User Access Control (UAC) I could access the drive with the NDA.

Originally I thought that this might be caused by it being clustered, but Symon Perriman from MSoft assured me that he had not heard of this. Then I thought it might be because storage we were using and the driver – EMC PowerPath. But I put off any further testing until I had time to work on a non-production box and to wait for W08R2 to see if that would make a difference.

First the good news – it does not have to do with clustering. Now the bad news – it might be a serious issue.

The basic issue is that the UAC, on both W08 and W08R2 appears to have issues enumerating membership for certain groups. What is especially unfortunate is that Domain Admins is one of those groups that it has trouble enumerating.

My Discovery of the Issue

When I created the new box to test I was initially unable to replicate the problem. It was not until I looked closer at the clustered drive on the original box that I realized that the problem had to do with permissions. Since the clustered drive would contain folders that would limit who would have access I had removed the “Users” group, leaving “CREATOR OWNER”, “SYSTEM”, “Administrators” (for that box) untouched. I then added “Domain Admins” with Full Control since this would be clustered and I did not want to rely on the “Administrators” of one of the nodes for perms. My plan was to create the shares, inherit from above, and add the appropriate security groups.

Unfortunately, with the UAC turned on I could no longer access the drive even though the account that I was using was a member of Domain Admins, albeit not the BIAA. I got a very strongly worded “NO”.

I replicated the permissions on my test box and discovered the same issue. I then added Everyone to the root of the drive with “Read” permissions and suddenly the NDA could access the drive.

By POE (process of elimination <g>) I determined that of the four permissions included in “Read” – “Traverse Folder / execute file”, “List folder / read data”, “Read attributes”, and “Read extended attributes” – I only needed the middle two – “List folder / read data” and “Read attributes”.

Hmm, I wondered if the issue could be that some special account was being used by the UAC to check for the drive. So I removed the “Everyone” group and added the NDA with those two specific perms. I could access the drive. So it appeared not to be an issue with a unique account, but more likely that the Domain Admins membership could not be enumerated. Maybe.

So I added an old Global Security group that the NDA belonged to (after removing the NDA) with the necessary perms. That worked. So I removed that, added an old Local Security group that the old Global security group belonged to. That worked.

I am stretching for possible causes. I can conceive of no reason why the Domain Admins membership could not be enumerated when other older groups have no issue, even when the NDA is a member of a member of a group. The only thing that strikes me is that all the old accounts I have used do not have spaces. Stretching, I know, but there has to be SOME reason.

I create two new Global Security groups – “PermTest” and “Perm Test”, one with a space one without. I add the NDA to each and try each of the, granting them the necessary perms. Neither one worked. So that blows that theory. Just to put a nail in the coffin I add “Domain Users” and that works. Further testing with Msoft and I catch that I have to Log OFF and BACK ON for this. Ooops. Those new accounts work, but Domain Admins still will not.

So far (when the UAC is turned on and accessing with the NDA):

Works

• Directly adding NDA
• Adding Everyone
• Adding Domain Users
• Adding Old Global Security groups containing NDA
• Adding Old Local Security groups containing old Global Security groups containing NDA
• Adding anny counter OTHER than Domain Admins

Does not work

• Domain Admins
• ?

I open up ADSIEdit to look at the properties of “Domain Admins” vs “Domain Users”, I specifically want to see when it says the whenCreated and the whenChanged attributes are. It turns out that although they both share the same whenCreated date, the “Domain Admins” whenChanged is more recent. Except that the old Global Security group containing the NDA has been changed more recently and that one works.

So that is a dead end.

And why does the default administrator account have no problem even with UAC turned on?

Verification by another forest

I want a totally isolated confirmation so I contact a buddy of mine down in Ohio (thanks Stuart) who is also running a w03 network with a w08 member server on it. He runs into the exact same problem. So the issue does not appear to be bad media or erroneous implementation, unless we both made the exact same mistakes.

Moving to subfolders

I move my study to subfolders. I create a subfolder on a local drive, remove Users, add Domain Admins and test that. I get this message “You don’t currently have permission to access this folder”. If I choose “Continue” it adds the NDA account with Full Control and lets me in.

A closer look at the UAC

It is past time now that we delve into the UAC which seems to be giving us such problems.

In the original w08 it was located in the Control Panel under “User Accounts” and you had two options there – on or off. In w08r2 it is still located in the Control Panel but it has now been moved to “System and Security” and now you have four options (see image).

Quick testing on w08r2 soon reveals that the only time that the NDA can access the drive via “Domain Admins” perms is when the UAC is all the way at the bottom (ie turned completely off).

What you may not know is that behind the scenes these apparently limited choices actually control ten different settings in the Local Security Policy. You can access your Local Security Policy by going to your “Administrative Tools”. Look under Local Policies, Security Options and at the bottom you will find the entries I am talking about.

First, let me draw your attention to the very top one – “Admin Approval Mode for the Built-in Administrative account”. This is the source of that odd exception – that the built-in administrative account can access the drive regardless of the UAC settings. This is set to Disabled and is ALWAYS set to Disabled regardless of the changes you make in the Control Panel. The only way to change it to Enabled is to change it here.

What will happen if it gets changed from Disabled to Enabled? Basically the built-in administrative account (BIAA) will be treated like any other administrative account (such as the NDA). See the “Explain tab”.

So, if your devious mind is like mine you instantly wonder if changing it to Enabled means that since the NDA cannot access the drive and since the BIAA is being treated like the NDA now, does that mean that the BIAA cannot access the drive? The answer is that, sure enough, the BIAA account CANNOT access the drive when it is treated like any other admin account and UAC is on. Yeah! I have succeeded in making things worse!

What does it mean that the BIAA is treated like any other administrator? How does the UAC determine how they are treated? For that I draw your attention to the third UAC entry in the Local Security Policy – named “Behavior of the elevation prompt for administrators in Admin Approval Mode”. This is one of the areas where w08 and w08r2 differ in their implementation of UAC. W08r2 does not add any more entries into the Local Security Policy, instead it adds three more options to this entry and adds one more to the subsequent (“Behavior of the elevation prompt for standard users”). See the image below.

So there are multiple ways that administrators can interact with the UAC when it is turned on. But what if the UAC is turned off? That affects the eighth choice –“Run all administrators in Admin Approval Mode”. Per the Explain below, disabling this disables Admin Approval mode, and hence (I believe) the entire UAC.

W08 and W08r2 Admin Approval Mode settings results

Regardless of what level I set the Admin Approval Mode to (three in w08, six in w08r2), including “Elevate without prompting”, I was unable to open a subfolder or a root drive that had the perms I have been talking about using the NDA account when UAC is on. The prompts where the same – denial on root drives, prompting to grant perms to the NDA on subfolders.

Only when the UAC is off w08 has no problem enumerating the NDA’s membership in Domain Admins.

What does this all mean?

It seems to me the simplest solutions are:

1. turn off the UAC
2. do not use an NDA to access the server (the above is an issue with file/folder perms, but it might affect other aspects as well)
3. do not rely on either Domain Admins for permissions. On second thought, do not rely on Domain Admins for ANYTHING.

Until this gets addressed by Msoft you are probably safest (ironically) in turning the UAC completely off on your w08 boxes. Not ideal, especially since the addition of “Prompt for consent for non-Windows binaries” helps remove some of the Clippy aspects of the UAC (see my thoughts on that here). Unfortunately the UAC has its tentacles in pretty much everything and who knows when this issue might trigger something more serious?

On a side note, some of you may be wondering why the UAC has that particular exception for the BIAA, especially as it is never turned off unless you do it via the Local Security policy. I cannot read the mind of the makers, but I suspect that it has to do with protection against elevated privileges. If you can restrict all NDAs (but not the BIAA) then if someone does hack your system on a regular user account and elevates themselves to an NDA they could STILL be restricted. It seems to me a logical way to guard against that.

Let me know what you think….

m

followup - http://www.myfriedmind.com/techBlog/2009/10/20/UACAndDomainAdminsPermissionsIssueOrPocketFullOfKryptonite.aspx

I checked the prerequisites for installing sp2 on w08 at this entry -> http://technet.microsoft.com/en-us/library/dd335038(WS.10).aspx and there is no mention that Internet Explorer 8 needs to be installed in order for w08 sp2 to be installed. And perhaps this is a quirk with Windows Updates, but on identitical w08 boxes (not r2) I am offered SP2 on one and not on the other.

What I AM offered on the other is the installation of IE8 for x64. It has already been installed on the first box. Note that it is simply called 'important' not 'critical'.

So I install IE 8 on the 2nd box and voila! Now I can install sp2.

If you have tried installing the Windows 2008 Failover clustering one of the nice things that MSoft provides out of the box is a Cluster Validator. Not merely does it allow a more robust set of options for hardware, but it runs through a basic checklist of necessary and suggested configurations so you do not have to.

However, you may run into the following error under "Validate IP Configuration" -> Found duplicate IP address blahblahblah on node blahblah adapter Local Area Connection *blah and node blahblah2 adapter Local Area Connection *blah.

The reason for this is what is called the Teredo Tunneling Pseudo-Interface (TTPI). Which, as you can intuitively tell from its name is used to tunnel IPv6 traffic over an IPv4 interface. It turns out that the TTPI gives IDENTICAL IPv6 addresses to all the servers. Since the IP address is going through a unique IPv4 already this is not a problem (and prevents it from bumping against a different IPv6). When you apply it to clustering, however, this is flagged as an issue.

The basic solution is to disable the TTPI. The method I use is very simple:

1. Open up Server Manager to get to your Device Manager and under View select "Show hidden devices". (It is hidden, in case that was not obvious).

2. The TTPI should magically appear.

3. Now right-click and select disabled. I suggest you do this on all nodes

And you are good to go.

If this STILL does not work, take a look at Symon Perriman's entry here -> http://blogs.msdn.com/clustering/archive/2008/07/26/8773796.aspx

Have fun clustering!!!

I was pondering the UAC (User Access Control) on Windows Server 2008 and Windows 7 (nobody talks about Vista anymore) and it occurred to me that the experience of interacting with it reminded me of another time. An annoying, apparently helpful attempt by Msoft that actually prevents you from doing work (see here). Suddenly it struck me - the return of 'Clippy'!!!

Now, first off, I can understand MSoft's implementing the UAC. After all, everyone knows that MSoft is so full of holes that it should if it were a cheese it would be swiss cheese. Everyone knows that, even if it is not necessarily true. So to convince everyone that they were secure they had to prevent users (that would be us) from doing stupid things. Like installing programs that should not be installed or changing setting that would render their computer unbootable. Because, of course, if a user does those things than the people REALLY at fault are not the users (heaven forfend) but MSoft!

To quote on of my favorite sayings - "calling something foolproof fails to take into account the ingenuity of fools."

They have to do this because we are so stupid as a race that an entire industry has sprung up to inform us of the obvious. Such as "do not put a gasoline can in a fire" or "ax blades are sharp" or (as in this picture) "this egg product contains eggs".

Still, there has to be some sort of happy medium. W08 only offers two options - on or off. W08R2 offers more (and I will make some notes on that in another blog) but I fear that in general MSoft has gone too far in the wrong direction. They are so concerned with protecting us that they are annoying us. And if something becomes annoying we generally stop doing it.

Goodbye Clippy. Goodbye UAC.

Do I have a solution? Of course not. Except to suggest that the UAC could be tweaked to be more specific. What I mean by that is simply that rather than trying to prevent you from doing EVERYTHING, it should only prevent the main crucial things. Perhaps it should not question you when you are installing programs but only when you are not installing them from an executable from a DVD or from your local drive.

Or perhaps the solution is that high-end users simply turn 'Clippy' off. He is annoying and YES I DO KNOW WHAT I AM DOING AND I WANT TO DO THAT!

At least, most of the time...

For those of you just enter the IT 'biz, let me assure you that Hewlett Packard was once a great company. Good, reliable printers. Functional Drivers. Not the crap we are handed today. It is always sad to see a reliable company start to tube and I can only hope that this is a quirk, but I once again ran into an issue with their drivers.

We are using their Universal Print Driver because they have not come out with the necessary drivers for Windows 2008 for our printers (not to mention the issue with their bidirectional channel component) and came across a rather strange bug. Let us say that we are trying to print the following document from Word 2007 that has a watermark. It should look like this:

However, when printed from an XP machine we only get half the letters. It looks like this:

I verify that there are no correct drivers from HP (nope!) and then I try changing a setting - maybe "Send Truetype as Bitmap". Wow! Now we have the other letters, we just dropped most of the original ones that were showing.

So I roll back the driver from PCL6 (v 5.0) to PCL5 (v 5.0). And guess what. It works. PCL 5 works where PCL 6 does not.

A little (true) story. I was about to fly out of town so I took my wife's car into an oil-change place just to get that task done. While there the tech pointed out that the alternator belt was missing a tooth. Now I have changed more alternator belts in my life than you can shake a stick at, and I should know better than to have an oil-change place change my belts, but since I was in a hurry I figured to let them do it for me this time.

Oops.

When I get back I find out that it is squealing when you start the car. Hmm, maybe they need to tighten it. I take it back and they can't repair it. It works on tensioning pulleys in that car and they tell me they think that one of the pulleys is broken. So I take it to the dealer to fix. The rep sits down next me after they have loaded the car up and taken a look and says, "Well, it is kind of good news. The pulleys aren't broken, they simply put on the wrong belt - it is too large."

It seems to me that these "Universal" print drivers from HP fall into that category. What use is a functional engine if the belts that you put on it do not fit.

Come on, HP, spend some time on the belts. Please.

1. Users may need to remove/add the printer back for this to get pushed down.
2. This is NOT Printing Preferences. The same screens are there, but they will not fix this, although they should be changed as well.
   

If you have moved to Windows 2008 for your Print Server and have encountered slow printing to your HP Laserjets, the issue may be the driver.

According to this support document by HP the issue lies in the HP Bidirectional Channel component - namely hpzbid.dll and hpzbidXX.msi). You can read all about the symptoms/cause there but to make a long story short it appears that this lies with issues where it continually tries to reinstall the .dll and fails.

The solution, according to HP, is NOT to call up and get updated .dlls (they probably will not give them to you) but to use their updated Universal Print Driver (UPD) version 5.0. This changes the .dll to cioum.dll for the bidirectional channel control rather than hpzbid.dll. HP has no intention of updating hpzbid.dll so get used to it.

The symptoms are hard to miss (for example it takes 30 seconds just to view the properties of a printer on a client machine) so this one should not be hard to miss. Just remember to use the 5.0 version of the UPD.

Printers noted by HP:

• Laserjet 4250 series
• Laserjet 4350 series
• Laserjet 9040 series
• Laserjet 9050 series
• Laserjet 5200 series
• Laserjet P3005 series
  

After installing our clustered w08 Print Server I noticed that there was a particular Warning in the System Log. Event ID 4 "The print spooler failed to reopen an existing printer connection because it could not read the configuration information from the registry key S-1-5-18\Printers\Connections. The print spooler could not open the registry key. This can occur if the registry key is corrupt or missing, or if the registry recently became unavailable."

I looked in the registry and, no surprise, that key was missing. I hunted around a bit and found this entry. Basically to resolve this was fairly simple - add the key back in:

1. Open up the registry on the computer (I did it on all nodes individually)
2. Go to HKEY_USERS/S-1-5-18/Printers
3. Add a new Key called "Connections" (no quotes)
4. Right-click and select Permissions on the new key to verify that System has "Full Control"

Now I am not sure if this is an issue with Clustering or just a strange whacky event that happened. But if it happens to you, hopefully this will resolve it.

NOTE: This is NOT an issue with clustering, but appears to be an issue with w08 (and w08r2) regardless of whether the drive is clustered or local. For more info look here -> http://www.myfriedmind.com/techBlog/2009/10/14/UACAndDomainAdminsPermissionsIssueOnWindows2008.aspx

============ The information below is misleading - see the above link for correction

Another addition to w08 that might trip you up is the use of the User Account Control (or UAC) to prevent Administrator accounts (other than the default created one) from doing anything useful (unless prompted). Connect that with the fact that you can only sign onto a machine once per account (see this) and you have a case where you have to log on as the non-default Administrator but are hampered in doing your work.

Put aside the annoying popups (are you SURE you want to see the security permissions? Really? Really?) there is are more serious issues. Case in point - we have a Cluster server with the Role of File Services. Logged on as a lowly Domain Admin I can not get to the actual drive that it is sharing. Let me state that again clearly

1. I am working on a Clustered w08 server with the Role of File Services
2. I am logged on with a Domain Admin account (but not with the default Administrator account)
3. UAC is turned on
4. I can NOT access the drive(s) (much less the shares) that the Cluster uses

1. Always use the default Administrator account when logging on to a Clustered w08 account. This always gives you access.
   
2. Turn off UAC ON ALL CLUSTERED SERVERS (since if it is not turned off on the host server, whichever one that is, you are going to run into the same problem).
   

I funny thing happened to me this morning. I was remotely connected to one of our w08 servers with our standard Administrator account when suddently my session came to a sudden end. I knew what must have happened, and sure enough one of my cohorts had signed on remotely to that server.

At first I thought it might be a limitation in w08 that you could now only have a single Remote Access connection, but I quickly realized that that was not the case. Instead the new tweak in w08 is that you can only sign on ONCE per account. So, when my cohort signed on with the same username it booted me off and handed my session over to him. This is new to w08, in w03 you could have sign on more than once with the same account and run different sessions.

The takeaway seems to be that you are going to have to have multiple Domain Admin accounts, probably assigning one per administrator. This will mean that you can have better security auditing (hopefully) but it also means that you will have more accounts that can do more damage.

Note that with the addition of User Account Control turned on by default this may restrict some critical tasks (see here).

Not a bad thing to have added to w08, just something to be aware of...