Category: Windows Server 2008 R2

At the TechNet/MSDN after work I attended last week I got an interesting question on why a user (domain admin) gets a UAC popup on trying to access folders via Explorer which he knows for sure he is supposed to be able to access looking at the ACLs of the folder. Instead, when clicking OK on the UAC popup the ACL is populated with his account.

My first thought to this behavior was Explorer.exe not being able to elevate and the “split personality” i.e. the two security tokens involved when UAC is in effect. Here comes a more detailed explanation that I think is of interest to more. Note that this problem also covers some other scenarios such as AppLocker rules not appearing to work as intended for administrators. Read on to learn what is causing this.

First when UAC is enabled you get two security tokens when you log in, easily explained as one which contains the administrator privilege information and one which does not. Most of the times you run everything using the standard security token. When you for instance want to install software or change some system settings, then the security token containing the administrator privileges information is used.

If you do not explicitly request an application to launch with higher privileges, or the applications itself request higher privileges, all processes and applications run in the user context with the standard security token. Virtually all applications including Windows applications and processes are possible to elevate by right clicking and choosing “Run as administrator”. This is not true for Explorer.EXE though as all your attempts to elevate it will not result in any actual elevation. There are a few caveats with this and let us continue with the example of access certain files and folders.

So let’s have a look at what the ACL of the folder D:\Share looks like:

We can clearly see that there are no user accounts in this list. Under normal circumstances any user which is a member of the domain admins group should be able to access that folder but instead is presented with the UAC dialogue:

What happens when the user “stenis” in this case clicks “Continue” to that UAC dialogue box questions is that the ACL is populated with the user account in questions:

This happens because the fact that Explorer.exe cannot be elevated the normal Windows Explorer does not see that the user account should be able to access that folder. It is easy to verify as you can actually run Explorer.EXE elevated by changing the registry setting “RunAs” to “_RunAs” in HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}. Thanks goes to Andre Ziegler for this finding.

So what does this tell us? It is a somewhat strange problem but still by design. The fact is that this “problem” is not applicable to the folder and file access as described in this blog but also for AppLocker rules for instance, as many domain administrators must choose “Run as administrator” to be able to run software which they think they should be able to run without this little procedure.

When the SP1 beta for Windows 7 and Windows Server 2008 R2 was released a couple of months ago I pushed it in onto my Windows 7 machines without blinking. I was also about to install it (using the Windows Update script) on my Windows Server 2008 R2 Hyper-V server but thought twice as I cannot live without my virtual machines and I use many of them in my daily work.

Anyway I was kind of suprised the other day when I rebooted the Hyper-V server only to learn that the service pack was installing. Aaargghhh! I do not blame Microsoft, I blame my own stupidity. But hey, everything worked fine afterwards and by reading the release notes I can sleep good at night knowing there won’t be any problems when the next SP1 release comes.

Once you have installed this service pack, you will have to uninstall it prior to installing a later release of this service pack. The settings of any virtual machines will remain intact during the uninstallation and installation, but virtual machines that have RemoteFX or Dynamic Memory enabled will not appear in Hyper-V Manager while the service pack is removed. In addition, any snapshots taken when RemoteFX of Dynamic Memory was enabled will not appear in Hyper-V Manager. They will reappear and functional normally once the later release of SP1 is installed.

Lesson learned; check!

If you have started using AppLocker with Windows 7 you know that the default rules for executable files make sure that administrators can run anything on the box, and that everything from the Windows folder and Program files folder are allowed to be executed. There exists a slight problem with this set of rules.

The default rules are intended for non-administrator users on the machine to be prevented from running any software which is not already installed or managed centrally, in the Program files folder. The default rules are also intended to allow anything from the Windows folder to be executed. Both these rules are sort of safe, as a standard user per default cannot put files in the program files folder to execute them, nor anywhere in the Windows folder.

But, there is this but. Inside the Windows folder there is a folder called “temp”, which believe it or not, standard users can write stuff to and consequently executing it thereby bypassing all the nice security benefits that AppLocker provide.

Well, the standard user just cannot copy an executable to the Temp folder using Windows Explorer, but using traditional copy commands using the command prompt this is fine, and then the executable can be executed.

The problem here might not be that the average user can bypass AppLocker this way, but when securing servers or clients, potential attackers can use this to bypass your security rules.

A simple solution if running with the default rules is to simply add the Windows\Temp folder to the exception list, effectively blocking code from being executed.

The Infrastructure planning and design guide for DirectAccess has just been RTM:ed and can be downloaded from http://go.microsoft.com/fwlink/?LinkId=164151. If you’re planning on implementing DirectAccess read this document! ;)

Documentation from Microsoft regarding the new feature AppLocker in Windows 7 (and Windows Server 2008 R2) early stated that to be able to use AppLocker you must have a “Windows Server 2008 R2 Domain Controller to host the AppLocker rules”. I have seen this information several times since then and at a seminar I payed a quick visit to yesterday regarding Windows 7 this particular questions was raised.

Of course I had to make sure what’s really going on here and I have now verified that AppLocker works perfectly fine in environments where there are only Windows Server 2003 DCs or Windows Server 2008 DCs. I can see no reason what so ever for AppLocker to require a Windows Server 2008 R2 DC to function. The only requirement is that you’re running Windows 7 Enterprise or Windows 7 Ultimate edition to be able to use th powerful feature of AppLocker.

We saw an interesting issue with connecting via Remote Desktop from a Windows client to another machine using Remote Desktop Services in Windows Server 2008 R2. After doing some troubleshooting it turned out to be ESET NOD32 version 4 that caused the extreme slowdown. The work around is to turn off ”HTTPS filtering” in the NOD console.

Microsoft have just released a hotfix for Windows Vista, Windows 7 and Windows Server 2008 R2 that potentially can reduce CPU power consumption by ten percent for AMD processors, specifically ones supporting the power state C1E. This includes popular CPUs such as AMD Phenom and Athlon range of CPUs.

The hotfix can only be obtained by contacting PSS (Product Support Services) or by requesting it for instant download via the KB article below.

KB974090: An update is available that allows for a potential power saving in an AMD multicore processor that is running an x64-based version of Windows Vista SP2, of Windows Server 2008 SP2, of Windows 7, or of Windows Server 2008 R2

A new tool in Windows Server 2008 R2 that you must not miss is the Active Directory Administrative Center. The tool is far from the speediest to load but once you’ve got it started I promise you that you will find it very convenient to use for account and other Active Directory object management. As with the user interface, new search tools and more in Windows 7 the Active Direcory Administrative Center in Windows Server 2008 R2 makes you do things in fewer steps and eases your daily work!

If you have renamed a Windows Server 2008 or Windows Server 2008 R2 domain controller you should be aware of  a problem. The problem is that a DFSR object is not renamed to the new name. This does not cause any problems until you remove the domain controller in question and after doing a demote or cleaning it up with metadata cleanup the object will become orphaned. So if you have renamed 2008 or 2008 R2 DCs you should follow the steps in KB2001271 to fix this.

The other day I got an email from a blog reader which contained the information of a successful analyze of a memory dump file which is generated when an infamous blue screen of death occur. The reader wanted me to give him the solution or point him in the direction of a solution. This got me into thinking. When is it worth putting time on doing blue screen analyzes?

The content of the crash dump is maybe not that relevant after all. What is more important is how often and when the blue screen of death occurs. If the crash occurred just once or very seldom and randomly I would say that it might not be worth finding out exactly what caused the crash. Keep in mind that a blue screen could indicate a hardware failure, although driver problems are the most common cause for crashes.

However if the crashes occur often or at when doing specific tasks you have all the reasons in the world to get to the bottom of the problem. In these cases I recommend following the guide for troubleshooting blue screen crashes.

An interesting thing to note about blue screens that start occurring after for instance upgrading the OS from Windows XP to Windows Vista or Windows 7 is that the new memory management in the later operating systems might reveal problems in the memory modules that did not show when using Windows XP.

Finally, whenever having problem with blue screens of death I would recommend upgrading the machine BIOS. Often there are compatibility and stability fixes which solves problems with hardware which might be causing you the problems you are experiencing.