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 encountered a user who was browsing to a webpage that locked up their computer. I kid you not, we had to do a hard reboot, no ctrl-alt-del anything. She was using IE 7 and there were no fancy-schmancy toolbars on there, but I took a looksee at her add-ons as I have found these to not merely be an issue on occasion but even to be where malware has secreted itself.

I noticed an add-on named "jqsiestartdetectorimpl" which referenced jqs_plugin.dll. That is the Sun Java quickstarter file.

Now one of the problems in the whole realm of computers is that with so much competition, vendors do not care if they break your computer as long as they are on top. Who cares if your computer is slower as long as our product launches a microsecond faster. So you end up with a thousand (okay, I exaggerate) little programs sucking up memory because they each are thinking about numero uno. And no, numero uno is NOT you.

So I disabled that add-on and voila!

Note that many of these do NOT need to run for your stuff to work beautifully. And in this case (and others I have run across) all they do is mess up the browser, and possibly freeze the computer.

One nice thing about IE 7 and 8 is that they have a "no add-ons" mode. You can get to it a few ways

1. Start/Run and type "iexplore.exe -extoff" (sans quotes). Note that you will need to reenable any add-ons that you want since this turns them all off.
2. From the Start menu, to into Accessories / System Tools / Internet Explorer (No Add-ons). This will only disable add-ons for the duration of this session.

Note that #2 is better for troubleshooting since it does not turn them off permanently.

Remember - malware likes to hide here, so keep an eye on these.