Folder Redirection: A case study

If you've read my other blog articles regarding Folder Redirection, you know I've analyzed this Microsoft Vista feature to death. I figured I knew how much harder the Vista version was going to be for me to manage and script for and how the users were going to have to adapt to a different experience. I made my configuration choices to provide the best possible solution for my client. The tests and pilots completed successfully, the big day arrived - it was time to deploy to production.

Well, the new feature caused problems I hadn't anticipated. It just so happens that the new Vista Folder Redirection feature breaks (read crashes) an internally developed application. A multi-million dollar application. A mission critical application. Fun eh? This application had been working happily on Vista before I implemented Folder Redirection. It also happened to work perfectly with Folder Redirection under XP. But putting Folder Redirection and Vista together broke this application in two different ways - neither of which I had anticipated.

I thought I'd cover this case here so you could get a good laugh at my expense and so that I could cover two more symptoms of Folder Redirection since that is what my blog has been about so far. I'll cover the more typical problem first...

In my article, Folder Redirection: Specifying a target share I told you about how Vista's Folder Redirection GPO requires a UNC target rather than the drive mapped target that XP used to enjoy. In Folder Redirection: Amateur Magician, I told you how what I would consider to be background details (like the folder's real storage location) manifests itself in the foreground to users and applications. These are the forces at play here. My client's multi-million dollar publishing system relies on an old version of a product called XMetal. At some point XMetal needs to store information in an AppData folder. The software gets the AppData path - but it isn't ready for what it receives. Rather than getting a path with a drive letter it gets a UNC path. This is of course totally new to Vista and Folder Redirection so the application simply trips and falls to the floor.

I tell the application owners to get with the 21st century and support UNC paths! They tell me that they aren't about to spend hundreds of thousands of dollars within the next few days to buy new product and fix a multi-million dollar system just because I feel like upgrading an OS that was working just fine before I fiddled with it. You get the picture - I'm sure many of you have heard similar laments. So, would you like to know what I had to do?

It turns out that there are work-arounds.

The simplest solution and probably most practical is to just stop redirecting the AppData folder and leave it stored locally in the usual location. A local AppData folder will always report a drive letter path rather than a UNC path. There is very little negative impact to this solution. Even though AppData won't follow the other redirected folders, users won't notice this if Roaming User Profiles are also utilized. The Roaming User Profile feature will copy the AppData folder up to the network every time a user logs off and back to the workstation when a user logs on. This isn't so bad for us because our average AppData folder is only 1MB in size and will transfer quickly. But I have heard of AppData folders that are hundreds of megabytes in size, so you may want to judge for yourself.

There is another interesting solution that isn't recommended by Microsoft but holds a lot of promise. It involves modifying the registry entries that control Folder Redirection. The Folder Redirection GPO stores the target path definitions in the registry when the GPOs are applied at logon time. The UNC path for AppData (\\Server\Share\UserDir\AppData) is stored in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder\AppData. Remember that the Vista GPO is unable to use a drive letter because it is applied before drive mappings have been established. UNC paths are necessary if Vista wishes to present the Desktop and Start Menu which are now redirected folders. However, once the Desktop is present and the Logon Script maps any required drives, I see no reason why the registry key above cannot be given a value that does contain a drive letter. It would be a simple matter of the logon script doing a search for the %HomeShare%\%HomePath% in any of the User Shell Folder Keys desired and replacing with the %HomeDrive%. The new path is radically different from the old path but in actual fact points to the exact same place. This is good enough for our multi-million dollar piece of software. I'm just left wishing that Vista's Folder Redirection was a better magician.

[EDIT 01/13/2008] Well, I'm sad to say I just found a reason why the solution outlined above can't be used. The reason is Vista Service Pack 1 Release Candidate 1 (SP1 RC1). It turns out that modifying the registry to point a network drive letter now causes Vista to delete the associated folders right off the network! I have more details in my last article: Service Pack 1 (SP1) for Vista is coming. Sorry for any inconvenience. [/EDIT]

This last solution also provides some other nice benefits. By making this change for all User Files Folders, the user experience will be much more pleasant when performing tasks such as "Save As". The folder pane will open a drive letter a user is used to accessing rather than drilling down into the servers and shares of the UNC path that the user has no interest in (see Folder Redirection: Amateur Magician). It even fixes the problem of CMD not being able to access the redirected User Files Folders when they contain a UNC path (drive letter paths only for CMD). Keeping the AppData folder redirected will also ensure that a Roaming User Profile will get a user logged into the system in the shortest possible time.

I almost hesitate telling you about the second problem that the application had since most of you are unlikely to ever experience the problem - but what the heck... There are many large organizations that ask in-house application development groups to also deploy and support the applications they develop throughout the organization. This is often because the systems must be highly customized to meet individual needs. My client organization is no different. In fact, this application not only needs individual customization, but it also needs frequent and rapid updates. This application group has developed tools that reach out and touch individual workstations and customize them on a per-user, as-and-when needed basis. The problem is that they reach out to the user's Desktop folder to change icons and parameters. But Vista's Folder Redirection moved the desktop to the user's network share for the first time - out of the reach of these application developers! This scenario is quite different from that of a commercial-off-the-shelf (COTS) product, but I'm sure it happens to some of you.

There are a number of ways to solve this problem. Giving developers access to every user's Desktop folder on the server is possible but not practical. Instead, the developers should adapt and deploy their applications differently. The typical recommendation from Microsoft is to divide the installation routine into two distinct parts. One part would be run as an administrator to install the machine specific elements of the program. The other part would be set to be run by the user and would only configure the elements specific to the user. The question is how to get the user part to execute. Choices would include an e-mail request with a link, an entry in the all user's Startup folder or perhaps a trigger in the logon script. I'm sure the best answer will be different for everyone.