Folder Redirection: Problems with the Well-known Folder Cache

Microsoft recently published KB951049 which describes a folder redirection problem for Windows Vista and Server 2008.

If you use folder redirection to redirect your User File Folders and they either disappear or give a "currently unavailable" error after a reboot, this KB may be for you. Apparently, if you log in too soon after a reboot, Windows Explorer may attempt to display the Desktop before the Workstation service has started. This creates Well-Known folders caching problems.

I don't think I've experienced this problem myself, but I'd be curious to know if this is a common problem for any of you.

Microsoft not branding web sites

I'm starting to notice an odd trend. Teams within Microsoft are creating their own web sites - but without branding them or clearly advertising them as Microsoft property.

I first noticed this when Microsoft advertised their Windows Vista AppReadiness site during a Springboard Live! Virtual Roundtable. The AppReadiness site is devoid of any Microsoft logos, common-look-and-feel or any Microsoft copyright information. The only clue is the Vista subject material and the fact that Microsoft sends you there. Very odd.

Here is another interesting example... It appears that Microsoft Windows Sysinternals Team has decided to try a new distribution method for their Sysinternals tools. This new web site has all of the individual Sysinternal executables available for download and immediate execution (no installation required). Although extremely useful (check it out), it looks just like an FTP listing with absolutely no branding, logos, etc. One would think it was a pirate site if not for the readme that claims otherwise. I'm surprised that they wouldn't have a quick instant Microsoft template for whipping up a common-look-and-feel and that they wouldn't use it.

I am thankful that these sites exist, I just find it a little odd.

UAC: Elevate Windows Explorer

Back in March I wrote the article UAC: How to elevate anything, where I discussed the various methods for elevating non-executables (such as .VBS scripts). At the time, I highly recommended using an elevated DOS CMD prompt and barely mentioned using Windows Explorer. Windows Explorer would seem like the logical choice, but is rarely used for elevated work. Let's cover it now. It's time to learn how to elevate Windows Explorer and discover some of its shortcomings.

The first trick is finding the darn thing (I have traditionally used the Windows+E key to launch it). To ask it to Run As Administrator, you need an actual shortcut to click on. For some reason, even though I run the thing all the time, it doesn't show up at the top of my Start menu with the rest of the recently run programs. You'll find it under Accessories:


Unfortunately, just selecting the Run as Administrator option won't get Windows Explorer to elevate. Sure, it looks like it does by providing elevation prompts - but if you try to do anything requiring elevation, it will fail - or maybe it will provide the elevation prompts again before finally doing something. The problem is caused by the fact that Windows Explorer is always running in the background in order to display your desktop. UAC can only elevate an application to a higher token when it is launching a new process - it can't elevate an existing process. Windows Explorer is already an existing process. To get around this problem, you need to set a Folder Option in Windows Explorer:


That last option "Launch folder windows in a separate process" is the one you need. With this option checked, the Windows Explorer windows you ask for will launch in a new process separate from the Desktop that is already running. This gives UAC a chance to elevate when you ask to Run as Administrator. Nice eh? It should really be the default setting. It changes Windows Explorer from being useless to being somewhat useful. But there are limitations...

You cannot have any Windows Explorer windows open when you want to elevate to the high level token. Any instance of Windows Explorer (including things like Control Panel) will already be using the separate process (all Windows Explorer windows share the same process). Again, if you accidentally leave a window open, no elevation will occur. Also, since all Windows Explorer windows will use the same process, all subsequent windows will be elevated as well - the process only dies and returns to a standard user token once all windows have been closed.

For those who wish to work the way Microsoft recommends with one standard user account and a separate administrative account, this trick still won't help. In this case you can provide credentials for another account, but it won't actually work. You either get a new window that is still using the standard token of the first user account or you get no window at all. The different behaviors will depend on how the "Launch folder windows in a separate process" option is set for the administrative account - it actually affects the behaviour in the standard user account! (You get no window if the option is set.) So even with this trick there are many occasions when you still must use a DOS CMD window.

The most annoying part is the lack of error messages when Windows Explorer fails to elevate. If you don't use the separate process trick or you mistakenly try to elevate while another window is open, Windows Explorer will never tell you. It will just sit there quietly letting you believe that you had achieved the elevation you desired. Maddening. You will just have to try things and test the results until you learn how it behaves - don't trust that it is doing what you asked it.

Also, be warned that the Vista SP1 upgrade drastically changed the rules for Windows Explorer. If you think you knew how Explorer behaved before SP1, look again - most things behave differently (in most cases better).

There are many more Windows Explorer behaviors/bugs/features that you should know about. I will cover those in future articles.