Friday, June 27, 2008

Folder Redirection: IE7 Favorites Bugs

I have been amazed at how many different problems people are having just using something as simple as Favorites in IE7 under Vista. I am no different - I can't save my Favorites within IE. I have come across all sorts of possible solutions having to do with NTFS permissions and even Integrity Levels. The solutions work for some people - but not for everyone - and certainly not for me. But before I get started ranting about the IE7 bug I found, I thought I'd link to a number of the alternate solutions I found in case they are a solution for you:

  1. Here's a Microsoft blog that describes the trouble-free way to redirect the IE Favorites folder.

  2. Here's a blog that describes why NTFS permissions can stop IE Favorites from working properly.

  3. Here's a blog that describes how to fix the Integrity Levels that impact IE's ability to work with Favorites.

  4. Here's another blog that provides some additional ways of setting the integrity levels.

My Problem

Windows Internet Explorer 7 is unable to save - or even open Favorites. When trying to save Favorites I will get "access denied" errors or unspecified errors like this one:

Here is the "cannot find" error I get if I try to open a shortcut stored in a UNC path:

Who is Affected

Windows Vista users of Internet Explorer 7 (IE7) using all of the following features:
  • Protected Mode (if you aren't using protected mode you won't experience the problem).
  • User Account Control (UAC needs to be turned on in order for Protected Mode to work).
  • Folder Redirection of the Favorites folder to a local location (there is no problem redirecting to a network location).
  • Folder Redirection to UNC path (GPOs can only redirect to a UNC path on the network).
The Solution

As I mentioned, you only have the problem if you use all of the features shown above. If you can avoid using any one of those features, you can avoid the bug and go back to looking at permissions issues if the problem persists. For the rest of us that must use all of those features listed, there is no solution. You have stumbled into an IE7 bug. Microsoft is currently working on it - I'll post if I receive a fix.

What's Going On

Basically, IE7 Protected Mode gets upset when it encounters a UNC path for the Favorites folder that points to a location on the local machine. It seems to interpret the UNC path as some sort of web address and applies some zone rules or something to it. When it sees the local machine name in the URL, it seems to think a baddie is doing an end-run around its security or something and shuts it down.

IE7 doesn't kick into this mode if a local drive letter path is used and doesn't seem bothered if the UNC path refers to some other computer. But unfortunately I must redirect to a UNC path because that is the only kind of path that the Folder Redirection GPO will allow in my situation.

I felt I had somewhat of a unique situation that got me into this predicament, but the more that I look around, I suspect that the problem is quite a bit more common. Tell me if this sounds familiar.... I have a large organization that wishes to manage things like Folder Redirection via GPO. This is not a problem for my environments with dedicated servers. But my satellite offices with less than 10 people get their shares from a non-dedicated server/workstation. These users also move about the office. When they use a simple workstation with their redirected folder pointing to another computer, there is no problem. But when a worker finds himself on the non-dedicated server, the GPO redirects the favorites folder to a local location on that machine and IE7 has a fit.

Cute eh? Obviously these people want to continue roaming and I don't want to strand their data on individual machines. I won't bother discussing any of the work-arounds I have found because they are all messy and awkward and prone to failure. I'm stuck until Microsoft solves this problem.

For those of you who would like to recommend Firefox to me, let me stop you right here... Firefox stores its Bookmarks in the Roaming AppData folder. But I've had to strand that folder locally and not use folder redirection because of another Vista problem.

Yay Vista!

Wednesday, June 25, 2008

XP Support for 6 more years

It looks like companies that are planning to continue using Windows XP beyond the June 30th deadline may be onto something. InformationWeek posted details of the ongoing support and availability of Windows XP in their article: Microsoft Pledges Windows XP Support Through 2014.

Having another 6 years of support for this product is nothing to sneeze at. It now makes the strategy of entirely skipping Vista a viable option. It is already clear that Microsoft is racing to develop Windows 7 as quickly as possible (likely hoping to sell something ASAP to those who want to skip Vista). So there will be plenty of time for Windows 7 to get released January 2010 and a Service Pack or two to follow before an organization is forced to step off its stable XP platform.

I've read plenty of articles talking about how software companies are still developing for XP (some not developing for Vista at all). Large computer manufacturers like Dell have announced that they will continue to make XP available - this of course means that drivers will also continue to be developed for the various PC components from companies like ATI, etc.

So it looks like all the pieces are in place to allow the whole world to tick along and happily pretend that Vista never existed. Frankly, after working with Vista for the past 1.5 years, I think it is a prudent strategy. But don't worry - I've already boarded the Vista boat - I'm still bailing and will continue to post when I find something of value to talk about.

Friday, June 20, 2008

Want your Windows Vista bug fixed?

I found a great plea from Soma, a Microsoft developer, on his blog Shipping Seven. It's a bit old but very relevant - I felt you should all see it so I am reprinting it here:

Do you hit the same annoying Windows Vista crashing bug day after day?

Please, please, please click the 'Send information' button when you see this crash dialog.


If in the very unlikely event that you are the first person to encounter and report this bug, a new entry in our bug database is entered automatically.

If anybody else encounters the same bug, and reports it, our automated crash reporting system finds the correct bug in our database, and then updates a counter. (Basically, there is a field in the bug that indicates that X people on the internet have encountered this bug.)

If you don't report the crash, that counter is not updated.

Why is that important?

Our ship room (a bunch of guys who decide which bugs should get fixed and added to SP1, and which bugs are too minor to be fixed) rely a lot on this counter. If the counter reaches more than [redacted], we fix it.

So, every time you encounter any crash - hit that 'Send information' button. Please.

Thursday, June 19, 2008

Windows Explorer: Magic file deletions

In my article, UAC: Elevate Windows Explorer, I grumbled about how Windows Explorer is rather uncommunicative and can be quite confusing. I mentioned how outcomes can be quite unpredictable and that you'd need to spend time getting to know Windows Explorer. To help you in that endeavor, I'd like to describe the confusing behaviors of a simple file deletion...

Consider the case where you wish to replace an executable file on a network share (I happen to be scripting some installs at the moment). It is entirely possible that someone else has accessed that share and is currently executing (holding open) the file we wish to replace. (In my case, my executable hung on my test PC and I needed to fix my bug - my test PC held the file open.)

If I tried to delete an open file in the XP days, I would have received an error message like this:

Now that's a great error message! It tells me what file is at issue and figures out that it might be a problem with the file being in use. If I try the same action in Vista I won't get any message at all. The file will simply be deleted -- but not so fast - the file just LOOKS like it is deleted.

If I now attempt to replace it with a file of the same name, I get the following error from Vista:

The message doesn't discuss my file at all. It leads me to think I have permission problems with my 'E' folder. Incredibly misleading when you find out what is really going on. If I refresh Windows Explorer's view of the folder (hit F5 or reopen Windows Explorer, etc.) I find that my old file is back! It wasn't deleted at all. And since the file is probably still in use, I am unable to replace it with my new file. How's that for strange behaviour?

But wait! - There's more! Let's pretend that we don't know what is going on and have no idea what computer is holding my file open. Let's pretend we wander off and play a great round of golf - what a great day! In the mean time, back at the office, the PC holding my file open, for whatever reason, stops holding it open - suddenly the file gets deleted! Somewhere there is a pending delete file request that actually gets actioned!

Kind of a neat feature I guess, but incredibly confusing - perhaps dangerous. Certainly no fun when you are trying to figure out what the heck is going on with Windows Explorer.

(BTW, my team managed to create a silent install of Visual Studio 6 for SMS if anyone is interested. A very, very complicated procedure to say the least. I haven't been covering any scripting yet, but I can write an article on it if there is interest.)

Tuesday, June 17, 2008

Quick Command Prompt

Previous articles have made a compelling case for the use of the Command Prompt in Windows Vista. It is an essential tool for an administrator. I think we would all prefer to work in a GUI, but Windows Explorer just doesn't get the job done. Well Tim Sneath, a Microsoft Client Platform Technical Evangelist, tells of a way to help us have the best of both worlds with his article: Windows Vista Secret #1: Open Command Prompt Here. He tells of an extra hidden item on a folder's context menu that opens a command prompt in that location (use the shift key). It has an interesting feature, but also an unfortunate limitation.

Naturally, any shortcut that speeds our navigation through the system is welcome. Being able to quickly open a command prompt at the current location is no exception. In fact this shortcut goes a step further - if you are accessing a folder in a network location (no drive mapping), the CMD prompt will temporarily map a drive letter to the location and then disconnect it when you are done. A very nice feature! I have often been disappointed that Vista dropped its old love of drive mappings for sexy UNC paths but didn't bother teaching the CMD prompt how to use them.

Unfortunately this handy shortcut doesn't support the Run As Administrator feature. As you probably know, we usually find ourselves running to the CMD prompt because of the administrative work we must perform. There's really not much point getting into a CMD prompt quickly if it doesn't elevate us to the level we need.

Note that this shortcut is not available from the left pane of Windows Explorer. It is only available from the shift-context menu of the right pane.

So, like so many of the patches that have been added to Windows Vista, this is another thing that doesn't go far enough. I know that Microsoft has been demoing some fancy Windows Explorer features for the upcoming Windows 7 - I just hope they have learned how we want to use it by the time they release that product.

Monday, June 16, 2008

Need to install XP on Vista hardware?

Judging from the petition to save Windows XP and the lack of Vista uptake in my region, a good many organizations are taking advantage of the downgrade licensing option. This option allows companies to buy Vista licenses but actually use XP instead. HP and Dell are offering to support these customers by continuing to pre-install Windows XP when customers request it. But there are plenty of systems being manufactured out there with the expectation that they will only see Vista.

Many companies haven't developed Windows XP drivers to support their hardware. In fact, you may not even be able to run the XP install on such hardware because basic things like SATA drivers are missing. If you are considering the downgrade option, you should obviously avoid companies that don't provide XP support. However, if you are stuck in the unenviable position of already owning hardware like this, I may have found a solution for you. Edmonton Geek published a great article: The easiest way to downgrade a Windows Vista machine to Windows XP. In this article they describe how to create a custom XP install disk with integrated SATA support from other sources. This hack probably isn't for everyone, but if you're in a bind, this may just be the solution you've been looking for!

Saturday, June 14, 2008

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.

Thursday, June 5, 2008

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.