Friday, November 2, 2007

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.


Anonymous said...

Thanks for publishing this. I have been struggling with this for the past week. You experiences have helped solve my issues. In my situation, engaging appfolder redirection with admin rights work, but that defeats the whole idea of UAC and hands carte blanche to users that blithely navigate the internet unawares

anotaro said...

Have you ever discovered a workaround for the issue of Vista deleting the network folders for which you have updated a registry key to point to a drive letter?

I was trying to do the same thing to be able to use a redirected AppData folder and Adobe 9 which does not work with a UNC path for AppData. I am seeing inconsistent results. In some cases, the Application Data folder gets deleted and in other cases it does not. But I don't understand why it happens when it does. I can't really have Application Data as part of the roaming profile because the folder gets too large to copy down and up to the server each login.

Any insight would be greatly appreciated!

Gordon Martin said...

Hi Anataro,

There is no fix - even today. You are aware of all the alternatives:

1) Don't redirect and live instead with data being copied up to the server.
2) Redirect to a drive letter and lose data stored on the server.
3) Redirect to a UNC path and stop using Adobe 9.

That's it, that's all. Well...

For a little while I played with a logoff script that would change the drive letter path back to a UNC path at logoff time so that the data wouldn't get killed at the next logon time. Then I would reapply the drive letter path during each logon - surprisingly effective actually. But data wouldn't survive power outages, etc. (because the logoof script wouldn't happen)

The scary thing is, I don't think Windows 7 fixes this problem. I fully expect Windows 7's underlying architecture to be Vista - with very few changes (folder redirection included). I can understand Microsoft's argument that we should constantly buy new applications for our whole organization so that we can help Windows work. Unfortunately, I can't understand why Windows Explorer has to treat redirected folders so poorly. The user doesn't know which end is up when being buried deep within a network path and the duplicate folders don't help.

anotaro said...

Actually, after a little trial and error, I discovered that in my case it was not the registry hack causing the redirected Application Data folder to delete from the server. The culprit here was simply a corrupt local copy of the roaming profile.

So, it seems for me that the registry hack of updating the AppData path in User Shell Folders to use a drive letter instead of a UNC path is in fact working. Have not seen any other ill effects (yet). Have you noticed that in the final release version of SP1 that this bug was fixed?

anotaro said...

Posted that last one without realizing you had replied. Again, this seems to be working for me and is not deleting the Application Data folder off of the network, except in this one case where the problem seemed to have more to do with a corrupt local copy of the profile. What else should I be looking for to determine if this is actually causing some major problems that I am just not noticing yet?


Gordon Martin said...

Very interesting. I'd say just keep watching it to see if it decides to do a delete a some point.

Perhaps it is a corrupt local copy that causes the problem. Perhaps SP1 corrupts the local copy on its way in or something. Please update us if your situation changes!