Author: Andreas Stenhall

So the beta release of Internet Explorer 9 has been released for public download. I’ve only been using it for a very short period of time but I can really notice the improvements in performance. Download now from
http://windows.microsoft.com/sv-SE/internet-explorer/download/ie-9/worldwide

EDIT: Woohoo, finally a download manager within Internet Explorer. And that also means that the downloads are downloaded directly to the destination folder instead of passing through the Temporary Internet Files cache.

Join me and other colleagues, friends and experts for After work at Grodan, Grev Turegatan in Stockholm on Tuesday 14th.

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!

Yesterday I blogged about the classic shim for suppressing the UAC prompt for certain applications. To determine why an application requests an UAC prompt you can look at the application manifest, if it has one at all. The handy little tool ManifestView lets you load an EXE file and see which requested execution level the developers have set for it.

If you should find the requested execution level to be set to something you do not like, for instance “runAsAdministrator” when what you actually want to do is to run is as a standard user, you can apply a shim to the EXE file to solve that problem. Be aware that most of the times the higher execution level is set for a reason but that does not mean you can still fix the problem, sometimes by modifying file and registry permissions for instance.

If you during your way in testing app compatibility with Windows 7 encounter an application that require a UAC prompt to launch you can suppress this UAC prompt by creating a more or less classic shim “RunAsInvoker”. A few years ago Microsoft posted this as a KB article but not long after it vanished. Now the guide for creating this shim is available in Ask The Performance Team blog and I strongly suggest you put this shimming tip in mind because it might come in handy when you least expect it.

I’ve received a question on why Microsoft stopped supporting the old way of making changes to the default user profile in Windows 7. As you might already know the only supported way to make changes to the default user profile is to make them with a local user account and then sysprep the image with an answer file containing CopyProfile=TRUE.

The question or should I say problem is that the user in question find it ineffective to make changes to the default user profile, by installing the image to a machine then make the changes and once again to sysprep and capture the image.

Fortunately there is a much more effective way to make changes (though unsupported). Just mount the image using imagex or dism, and then add or remove the files you want. If you want to change some settings they most likely stored in the registry so then you can just start the regedit.exe utility as usual and then mount the ntuser.dat file within the image to make the changes and when done just applying the changes and you are done!

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.

If you use the Office Live Meeting client you have surely noticed that it does not support Windows Aero. Thanks to Brian McCann for the solution to enable Aero when using Live Meeting. Great!

When teaching a Windows 7 course some time ago I was asked why shared folders often are not displayed in Windows Explorer as being shared. Well, the reason for this bug is still unknown but at least there is now a solution available, se KB article KB2291175. This fix will be included in service pack 1.

Opening CHM (Windows Help Files) downloaded from the internet or from a network location will most likely give you “Navigation to the webpage was canceled” and it will refuse to display the contents of the help file. This is due to changes that were introduced some years ago by a security update, and this is the default behavior in Windows Vista and 7 (and their Windows server equivalents).

I experienced this case at a customer site and to resolve the problem you can follow the steps in MS KB article KB896054. However adding the trusted UNC path caused some problems in this case, as the UNC path was sort of hidden because the CHM file was opened from an embedded link within an application.

So to find the UNC path from where the CHM file was opened I had two choices, either to use the famous Sysinternals tool Process Monitor to trace the open file action, but I chose a quicker way. Opened CHM files are logged in a file called hh.dat which can be found at C:\users\\AppData\Roaming\Microsoft\HTML Help. This file, when opened with WordPad contains the path to the opened CHM file, which lead me to the key which was an important part of this solution.