Folder Redirection: Misbehaves after target move

[EDIT 01/13/2008] Please note that this article has been rewritten to accommodate changes found in Vista Service Pack 1 (SP1 RC1). For those revisiting this article, all references to hacking the registry with a mapped drive letter have been modified. Now the correct value to use is "%HomeShare%%HomePath%" - the attached script has been modified accordingly (although it could be further simplified to ignore drive letter verification now). [/EDIT]

This is a follow-up to my article Folder Redirection: Duplicate User Files Folders II where I suggest the use of the Folder Redirection GPO setting "Move the contents of ______ to the new location". This setting is important to prevent duplication of User File Folders, but can have other undesirable effects. It turns out that this setting can cause all sorts of bad folder redirection behavior when a user's redirected folders get moved from one network share to another. In this article I will discuss the triggers for the problem and possible solutions. I will also be providing a sample script that can help you avoid the problem entirely.

This article is only necessary if one uses the Folder Redirection GPO setting "Move the contents of ______ to the new location". If this setting is disabled, the problems described here don't occur. However, I think I made a very good case for using this setting in my previous article. This setting provides the valuable service of moving user data stored in local User File Folders to the new network locations defined in the Folder Redirection GPOs. Now one might think that Vista has a very sophisticated way of determining when it needs to move data - but in fact, it is really quite simple. Vista looks at registry keys in "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Documents" There is one key per User File Folder that records it's storage location (i.e. Documents = "C:\Users\SRDTest5\Documents"). When Vista kicks off the folder redirection feature at logon time, it simply looks at the keys. If the storage location defined in the key is different than the one defined by the Folder Redirection GPO, Vista knows there has been a change. If the move setting is set, then Vista knows that it must move data from the old location specified in the registry to the new location specified by the GPO.

This may sound just fine -- it works great if we have local data that must get up to the network -- but Vista uses this same thought process if we are moving user data from one server to another. In this case the move setting isn't so good. The problem is that I don't know any self-respecting network administrator who would change the target location for the Folder Redirection GPO from a target such as \\ServerA\ShareA\SRDTest5\Documents to a target such as \\ServerB\ShareB\SRDTest5\Documents and then sit back and wait for Vista to move the data.

The Vista GPO seems to expect an administrator to follow this scenario:

1. An administrator would leave the old target alone.
2. Create an empty folder in the new location and set user permissions to it.
3. The administrator would set the new target in the Folder Redirection GPO.
4. The administrator would then wait for the user to eventually log on.
5. The user finally shows up and logs on.
6. Vista's Folder Redirection feature notices that the GPO target doesn't match the old target specified in the registry and springs into action!
7. Vista holds up the logon process while it moves all data from the old location to the new location (How long does it take to copy a few hundred megabytes in your environment?).
8. Eventually the data finishes copying and the user can get on with his life. (Somewhere in here the Offline Files feature will create a new partnership with the new target and sync up all the data as well.)
9. A few weeks later our administrator checks on the user and sees that he has logged in and that the data has been moved. He then proceeds to remove the user's permissions from the old location -- and decommission the server if that was what he was planning.

Now take the above scenario and imagine having 100 user accounts on one server that needs moving or the regular churn that requires the relocation of some user's data on a weekly basis. The scenario above is completely unworkable, but it is what Vista is demanding.

I now present the scenario we would all expect (and which this article will help you attain):

1. The administrator moves the user's folders from the old target to the new target.
2. He sets the permissions on the new target and removes them from the old one.
3. He tells the Folder Redirection GPO where to find the data (sets the new target).
4. The administrator walks away and never gives the issue another thought.
5. The user shows up weeks later and logs in without a care in the world. (Maybe he is particular bright and notices that the target path changed, but I doubt it.)
   

I think we can agree that this is the way an administrator would choose to work. Unfortunately, if you do it this way, Folder Redirection makes some incredibly horrible decisions when that move setting is set. Folder Redirection will notice that the data has been moved and will attempt to follow its orders to move the data. Unfortunately, the old location will not be available and the move will fail. Folder Redirection will react to this error condition and refuse to redirect to the new location - preferring to remain pointed to the old location. But because the old location is unavailable, it decides that the best course of action is to go into Offline mode and rely on it's locally cached copy of the files. This seems to work for Vista. It doesn't tell the user about any of this and goes on with life. Unfortunately this is a devastating turn of events.

The user never receives any error messages at all. The best Vista does is to put errors in the application event log:


If the user is very aware, they might notice the Offline status being displayed at the bottom of each folder in Explorer - but I doubt they will. How long will the user work before noticing that their user files are no longer getting stored on the network and getting backed up properly? - a week? - a year? Perhaps only after their hard drive crash.

Want to see some other symptoms? Try implementing DFS where the target goes from pointing to the real physical UNC path to a aliased UNC DFS Link. In this case the data doesn't change location but Folder Redirection will be fooled into thinking it did. In this case Folder Redirection will attempt to copy files to themselves and error out again. Folder Redirection will again stay pointed to the old location. In this case it will be a valid path, so files will get stored on the network. But the Offline Files feature decides to disable itself for some reason. This becomes an interesting trap since an administrator will feel he can safely move servers hidden under a DFS link at any time without notifying the user community since they would never notice - but in this case Folder Redirection would break all over again as in the first scenario, but this time the user wouldn't have an Offline cache to fall back on. NASTY!!

What to do to avoid this problem...

I've already mentioned disabling the move feature to avoid the whole mess it creates. But that creates other problems equally problematic. I don't recommend this option.

It turns out you can turn off the Offline Files feature to avoid the problem. For some reason Folder Redirection is willing to adopt the new target location even when it encounters errors - so long as Offline Files isn't in the mix. Of course, laptops absolutely rely on this feature and I'm sure you will have many other valid reasons to want to keep Offline Files.

This leaves us with only one solution. It's cludgy, but it works. Trick Folder Redirection so it never notices the target change.

Remember how Folder Redirection recognizes a data move? It compares the target in the GPO against the target it has stored in the registry. Remember how in my article Folder Redirection: Specifying a target share we learned how to setup Basic Folder Redirection so we never have to change the target values in the GPO but rather just change paths in user AD profiles? Well, we can use the same trick on the registry! Let's use the Documents folder as an example... The GPO has a target set to "%HomeShare%%HomePath%Documents". Set the registry key to the exact same string. If you give a user's AD profile a new Home Path like "\\ServerB\ShareB\SRDTest5", the GPO will determine that the new target is "\\ServerB\ShareB\SRDTEst5\Documents" - the GPO will then check the registry to see if the target had changed since last time - but since the registry is now using the same variables, it will return the same path of "\\ServerB\ShareB\SRDTest5\Documents". Folder Redirection will have no clue anything happened. It won't attempt a move of the data - no errors will occur and no strange coping decisions will be made. Life will be calm and beautiful.

(I know this article has been a long one already.... please bear with me for a long explanation and a long script.)

You may feel that this doesn't offer much of a solution because you can't find or visit the registry of every affected user on every machine they may have a profile on in order to make this change. It turns out there is a nice labour saving trick if you lay the cards out right...

The main thing to do is to make sure that every user has a Home Path defined - as I described in Folder Redirection: Specifying a target share. You can put the variables in the various Folder Redirection registry keys like so: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Documents" = "%HomeShare%%HomePath%Documents"

Substituting variables for the UNC path is a simple generic change that can be made to all users at logon time through a logon script. Folder Redirection will continue to function during the user's session because the variables and real UNC path agree with each other and point to the exact same location.

Here's a sample VBScript that you can incorporate into your logon script. It will pull off the trick just discussed. It will run in any domain with any Folder Redirection scheme. It does assume that a drive letter and UNC path have been defined as the user's Home Path in his AD User Profile - if this is not the case then you will need to adjust the script.

(This script should be largely unreadable here, but if you highlight it, you can copy and past it into a text editor and save it as a .VBS file.)

'********************************************************************
' Vista Logon script by GordonPMartin@gmail.com, November 2007
'********************************************************************

' User Files Folders are redirected to the Home drive UNC path in Windows Vista
' To improve the user experience and solve an Offline file problem, the redirection must be
' reset to a drive letter at every logon...

' First we need to connect to Active Directory to collect information about the user's AD Profile...

Set objSysInfo = CreateObject("ADSystemInfo")
strUserDN = objSysInfo.UserName
strUserDN = Replace(strUserDN, "/", "\/") ' Microsoft AD uses "/" as a delimiter - any occurrances of it must be prefaced by a "\"
Set objLDAPUser = GetObject("LDAP://" & strUserDN) ' This is our LDAP handle to AD info about the current user

' Time to collect information about the user's home paths.

blnHomeDrive = False ' Flag tracks if we have a valid home drive
strMessage = "No Home Drive defined in the user's AD profile." ' Default error message

If objLDAPUser.HomeDrive > "" then ' The user has a home drive defined
strHomeMapping = ""
strHomeDrive = UCase(Left(Trim(objLDAPUser.HomeDrive),1)) ' Here is the home drive's letter
strHomeDirectory = UCase(Trim(objLDAPUser.HomeDirectory)) ' Here is the UNC path of the user's home directory
strHomeFolder = strHomeDrive & ": = " & strHomeDirectory

' Let's ensure that any Home Folder that has been defined in AD was actually mapped...
Set objFSO = CreateObject("Scripting.FileSystemObject")
For Each objDrive In objFSO.Drives ' Let's look at all mappings to find the one that we need...
if objDrive.DriveLetter = strHomeDrive then
' wscript.echo objDrive.DriveLetter & objDrive.DriveType & objDrive.ShareName
if Ucase(objDrive.ShareName) = strHomeDirectory then
   blnHomeDrive = True ' The mapped U: drive matches the defined one!  (yay)
else
    strHomeMapping = objDrive.ShareName ' It isn't mapped correctly - record the current path so we can report it
end if
end if
Next

If blnHomeDrive Then
strMessage = "Valid home folder: " & strHomeFolder & vbCRLF & vbCRLF
Else
strMessage = "Missing Home Folder: " & strHomeFolder & vbCRLF
strMessage = strMessage & "It is currently: " & strHomeDrive & ": = " & strHomeMapping & vbCRLF& vbCRLF
End If
End If

' If we have a valid home drive mapping, we can proceed to work on the Folder Redirection paths...
If blnHomeDrive then
strKey = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" ' The area of the registry to play in

' Load an array with the 13 User Files Folders that might be getting redirected...
' (0 = display name, 1 = registry key, 2 = desired folder path)

 Dim arrUserFolders(16,2)
 ' (0,x) has been intentionally left blank  ;-)
 arrUserFolders(1,0) = "AppData Roaming"
 arrUserFolders(1,1) = "\AppData"
 arrUserFolders(1,2) = "AppData"

 arrUserFolders(2,0) = "Contacts"
 arrUserFolders(2,1) = "\{56784854-C6CB-462B-8169-88E350ACB882}"
 arrUserFolders(2,2) = "Contacts"

 arrUserFolders(3,0) = "Desktop"
 arrUserFolders(3,1) = "\Desktop"
 arrUserFolders(3,2) = "Desktop"

 arrUserFolders(4,0) = "Documents"
 arrUserFolders(4,1) = "\Personal"
 arrUserFolders(4,2) = "Documents"

 arrUserFolders(5,0) = "Downloads"
 arrUserFolders(5,1) = "\{374DE290-123F-4565-9164-39C4925E467B}"
 arrUserFolders(5,2) = "Downloads"

 arrUserFolders(6,0) = "Favorites"
 arrUserFolders(6,1) = "\Favorites"
 arrUserFolders(6,2) = "Favorites"

 arrUserFolders(7,0) = "Links"
 arrUserFolders(7,1) = "\{BFB9D5E0-C6A9-404C-B2B2-AE6DB6AF4968}"
 arrUserFolders(7,2) = "Links"

 arrUserFolders(8,0) = "Music"
 arrUserFolders(8,1) = "\My Music"
 arrUserFolders(8,2) = "Music"

 arrUserFolders(9,0) = "Pictures"
 arrUserFolders(9,1) = "\My Pictures"
 arrUserFolders(9,2) = "Pictures"

 arrUserFolders(10,0) = "Saved Games"
 arrUserFolders(10,1) = "\{4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4}"
 arrUserFolders(10,2) = "Saved Games"

 arrUserFolders(11,0) = "Searches"
 arrUserFolders(11,1) = "\{7D1D3A04-DEBB-4115-95CF-2F29DA2920DA}"
 arrUserFolders(11,2) = "Searches"

 arrUserFolders(12,0) = "Start Menu"
 arrUserFolders(12,1) = "\Start Menu"
 arrUserFolders(12,2) = "Start Menu"

 arrUserFolders(13,0) = "Videos"
 arrUserFolders(13,1) = "\My Video"
 arrUserFolders(13,2) = "Videos"

 ' That takes care of the main 13 folders that get redirected.  Now here are some more that seem relevant...

 arrUserFolders(14,0) = "Administrative Tools"
 arrUserFolders(14,1) = "\Administrative Tools"
 arrUserFolders(14,2) = "Start Menu\Programs\Administrative Tools"

 arrUserFolders(15,0) = "Programs"
 arrUserFolders(15,1) = "\Programs"
 arrUserFolders(15,2) = "Start Menu\Programs"

 arrUserFolders(16,0) = "Startup"
 arrUserFolders(16,1) = "\Startup"
 arrUserFolders(16,2) = "Start Menu\Programs\Startup"

' Process each of the User Files Folders in the array...

Set objShell = WScript.CreateObject("WScript.Shell")

for intFolder = 1 to 16
strCurrent = objShell.RegRead (strKey & arrUserFolders(intFolder, 1)) ' Get the path from the registry

If Left(strCurrent, 2) = "\\" then ' We have a UNC path!  The folder is being redirected!
' Do the drive letter substition...
' strSubstPath = strHomeDrive & ":\" ' This is the pre-SP1 version where we substituted a drive letter
strSubstPath = "%HomeShare%%HomePath%" ' This is the post-SP1 version where we substitute variables that get evaluated at logon time
If Right(objEnvProcess("HomePath"), 1) <> "\" then strSubstPath = strSubstPath & "\" ' We need one backslash at the end (no more, no less)
objShell.RegWrite strKey & arrUserFolders(intFolder, 1), strSubstPath & arrUserFolders(intFolder, 2)
'     wscript.echo strKey & arrUserFolders(intFolder, 1) & vbcrlf & strHomeDrive & ":" & arrUserFolders(intFolder, 2)

' Check the registry again to ensure that the new setting is there
strCurrent = objShell.RegRead (strKey & arrUserFolders(intFolder, 1))
End If

' Report the paths to the user
strMessage = strMessage & arrUserFolders(intFolder, 0) & " directed to " & strCurrent & vbcrlf
Next
End if

wscript.echo strMessage

I should mention that this script will only modify User Shell Folders that have been redirected to a UNC path. It will not affect users who have local User Files Folders. You can safely deploy a version of this script to all users in your organization.

Obviously the ideal solution to all of this is for Microsoft to fix the Folder Redirection feature. It wouldn't take much. I think a simple addition of one more setting in the Folder Redirection GPO would do the trick. The GPO should have a setting to determine how to treat new accounts or local data - something like "Move local User File Folders to the network". If the current move setting was to only apply to UNC path changes where both paths are network paths, it would fix everything. We could use the local setting to make sure we get all user data up to the network (avoiding duplicate folders) but at the same time choose to have no data moved when a server-to-server data move occurs. Are you listening Microsoft?

Thanks for slogging through this long article with me. Please share any interesting behaviours you may encounter.

Vista: Even the packaging needs instructions

Windows Vista is so complicated that instructions are needed just to open the box - no joke!

http://windowshelp.microsoft.com/Windows/en-US/help/2e680b8d-211e-41c5-a0bf-9ccc6d7e62a21033.mspx

Now for the jokes from my team:

"Doesn’t surprise me - What surprises me is that opening the product package actually works."
"Knowing Microsoft, they provided the scissors - but INSIDE THE BOX"
"Ya, but they are probably battery operated and have a laser guide... Batteries not included."
"But you have to buy an extra CAL to be able to use the scissors... with EA."

I just couldn't resist...

Folder Redirection: Duplicate User Files Folders II

Duplicate folders appearing in Vista have become an obsession if my Google hits are to be believed - and for good reason. I am amazed at how many different ways Vista and Folder Redirection can cause duplicate or extra folders to appear. If this article doesn't match your situation, take a look at my article Duplicate Folder Problems? Talk to me! which will lead you to my other articles on the subject.

Did you just configure user(s) for Folder Redirection and end up with duplicate User Files Folders like this?:


Or maybe you got lucky and can tell the duplicates apart because of the Offline Files sync icon like this:


The problem is likely caused by the Folder Redirection GPO setting "Move the contents of ______ to the new location" which can be set for each of the 13 User Files Folders. If the setting is disabled, you will get the duplicates shown above.

Here's what happens... The User Files Folders are subfolders displayed under the user's name (SRDTest5 in this case). But the user's name actually represents the parent folder C:\Users\SRDTest5. Any subfolders located in this directory location are displayed. (You will sometimes see even more folders if the user chooses to see hidden and system files.) The folder will also display any redirected folders (wherever they are stored) as if they are located within C:\Users\SRDTest5. When User Files Folders are redirected to a network location, the folders are still displayed as if they are stored locally. However, if the setting to move contents to a new location was not set, then the original folders were not moved and will still exist locally -- and will also be displayed. This gets you your duplication.

You now have a slight problem on your hands. The only way to tell the folders apart is to check out the properties of the folders which will tell you the real storage location. The folders stored on the network are the only legitimate folders, but the local folders are the only ones storing any user data!

You will need to find a way to merge these two folders and delete the illegitimate one. If this situation just occurred and the user hasn't stored anything in the new redirected folder, you may have an easy solution. Look into unlinking the Folder Redirection GPO from your affected user(s). Once Folder Redirection is cancelled and each user has logged in at least once with local folders, you can set the move contents settings described above and relink your GPO to the affected user(s). Vista should think that it is redirecting folders for your user for the first time and move the data to the new folders.

To ensure that no new Vista users (and particularly migrated ones) end up with duplicate folders, you should leave the Folder Redirection GPO set to "Move the contents of ______ to the new location" at all times. This will ensure that the local User Files Folders do not remain local. This also has added benefit for those of you who have been using Vista for a while without Folder Redirection. In your case you are likely to have users who have logged onto multiple Vista computers and left multiple Local User Profiles lying around. With this settings, a user's Redirected Folder will hoover up any local user files left in the various local User Files Folders. This will ensure that all of the user's files are safely stored on the network.

Now that we have all that cleared up, come back for my next article where I tell you to do exactly the opposite.

Folder Redirection: Back to talk about Settings

Well, not a single article posted about UAC and I'm back talking about Folder Redirection again. Is it possible to become a consultant that specializes in nothing but Folder Redirection?!

I have written a number of articles about Folder Redirection configuration choices, management headaches and problems (check my archives if you are curious). But until now I haven't mentioned the settings tab of each folder's redirection GPO -- here it is:


The reason I haven't talked about it is because I didn't want my blog to become a Microsoft brochure like so many other books have. I'd rather leave the generic education to them and deal with the bits where the rubber hits the road. The tricky bits that don't behave as advertised but which still must function at the end of the day. Many of the options on the Folder Redirection settings tab are well explained elsewhere and are usually set as a reaction to one's own environment.

Unfortunately it is time to talk about this tab! The property called "Move the contents of ______ to the new location" deserves special attention for its ability to behave in unpredictable ways -- two articles worth! This option sucks big time. I loath it.

Come back soon for the first article in the series!

Let's talk Roaming User Profiles

Regular readers of my blog will know that I have written a lot of articles about Vista's User Files Folders and the Folder Redirection feature. Folder Redirection is beneficial because it moves all of the User Files Folders to a network share. Not only does this make user data accessible from any workstation on the network and facilitate data security, it also offers some wonderful benefits for Roaming Profiles.

User profiles are made up of the User Files Folders, local AppData folders and the user registry settings. By redirecting the User Files Folders to the network, the largest part of the user's profile is taken off of the local machine. The resulting lean User Profile can then be made to roam quite effectively.

A Roaming User Profile:

• is a User Profile that is stored on a network server share.
• is copied down to a workstation at logon time.
• provides all of the user's settings/preferences while using Windows.
• is copied back to the network server share when the user logs off.
• is stored securely on a server and backed up until the next time the user logs on.
  

It is wonderful to have a user's entire collection of settings and preferences follow them from one workstation to another without being stranded on any particular one. Having Folder Redirection shrink the size of the User Profile so that it can be copied down to the workstation quickly at logon time is a godsend.

I haven't planned to write much about Roaming User Profiles because it is very much a "set and forget" kind of thing as far as the configuration options go. The hard work is navigating all the Folder Redirection options and I've already covered that (check the archives in the blog if you want to see those articles).

Here is a very nice document from Microsoft Windows Vista: Managing Roaming User Data Deployment Guide that will get you started. It will tell you how to activate Roaming User Profiles for your users.

The document also talks about cohabitation of Vista with XP. As far as I am concerned, you will have to treat XP and Vista profiles as two completely unique and separate entities. Users who must roam between the two OSes will use a different profile on each OS without settings following them back and forth. After reading my past article Introducing the User Files Folders! I think you'll forgive me if I also declare that you won't be able to share Vista User Files Folders with XP Personal Folders in a mixed environment. They are just too different. If users wish to access the same data from each of the OS versions, they will have to browse to it manually via a network share or mapped drive - the two OSes won't be able to default to the same locations.


A warning... One thing I am discovering about Roaming User Profiles as I deploy Vista in my organization.... it does not appear to be very reliable. I am encountering instances of some user's profiles not roaming - not copying themselves back up to the server at logoff time. There is an interesting array of behaviours and errors that I am investigating at the moment. If I come to any conclusions or discover any universal solutions, you can be sure I will share them with you here.

Duplicate Folder Problems? Talk to me!

A big shout out to all you Vista admins out there with folder duplication problems! Half the queries sending traffic to my site are searches for information about duplicate folders. It is clearly a large problem for many of you.

If you have come to my site because of a similar problem, I would like to direct you to four articles I have posted:

Folder Redirection: Duplicate User Files Folders - This one is rather easy to spot and deals with duplication in the User Files Folder.

Folder Redirection: Not to the user's home directory - This one is less obvious, but it is an important article that describes why you can get what appears to be folder duplication in your network shares.

User Files Folders: What's with all these extra folders - This one talks about Junctions. Junctions can be mistaken for duplicate or dysfunctional folders.

Folder Redirection: Duplicate User Files Folders II - This demonstrates major duplication caused by the "Move the contents of ______ to the new location" GPO setting not being set.

If you are experiencing some other form of duplication not covered by these articles, please send me an e-mail or post a reply to this article. I'd love to help. When sending your request, please be as descriptive as possible and attach screen shots if appropriate.

Thanks,

Gordon

User Files Folders: What's with all these extra folders?

In a previous article, Introducing the User Files Folders!, I showed you the 11 green folders that comprise the User Files Folder for a nice new profile in Windows Vista. With that article and some of the others in this blog I think I have demonstrated how that folder can fill up rather quickly with quite a few others. As it turns out there are a few more subfolders worth mentioning.

Did you know that without adding anything into your User Files Folder you can end up with something like this?!?!?:


It's time to talk about these folders because some of you are coming across them in the wild and don't realize how they got there. Some of you don't yet realize how you made them appear on your own Vista desktops. Still others think they have duplicate folders or even completely dysfunctional folders on their hands.

If you read my article Introducing the User Files Folders! you will know that the Documents folder (formerly My Documents) is no longer the parent folder but merely a peer. But I never really talked about what the parent folder is. The parent folder is listed as the user’s AD display name (“Martin, Gordon” in this example), but in reality it is the user's actual profile folder (C:\USERS\GMARTIN in this example). In the past with XP, the User Files Folder was the "My Documents" folder and it was a little subfolder within the user's profile waiting to get filled with the user's data. Now under Vista, the User Files Folder is the whole user profile! It's already full of junk - it's just hidden from the user.

I guess you know where the rest of this article is going...

I don't know why, but for some reason Microsoft decided that the User Files Folder should allow a user to see every one of their files - even those that a normal user wouldn't want to see. I guess Microsoft decided that if a user is able to figure out how to see their hidden and system files, that they will want to see all those that pertain to them in this folder. (I guess they forgot about us admins that briefly make a user's hidden files visible for technical support reasons and then forget to make them hidden again.) At any rate, you now know the story so let's wrap up with a few final details and griping...

In Vista, basically all system data that pertains to a specific user is stored in the AppData folder. The AppData folder is really king in these parts. It contains the Local Settings, Cookies, Start Menu and pretty much everything else. This folder is hidden - and therefore invisible to the user - until you choose Folder Options… | Do not show hidden files and folders from the Microsoft Explorer's Tools menu. (Can't see the Tools menu? Press the ALT key.)

You may be starting to doubt me here because my picture above plainly shows those folders outside the AppData folder. But trust me, Vista's lying to you - not me. See the black shortcut arrow on the folder icon for a bunch of the folders up there? That is your only clue that those folders aren't folders at all, but rather Junctions. Junctions are a new invention for Vista that fools older XP applications into thinking the folders are where they expect them to be. Meanwhile Vista has squirreled these folders off into the AppData folder. This wouldn't be so bad except that Vista is fooling a good many of us admins as well.

Microsoft thought they were being clever by making these folders hidden system folders. But let's face it, what admin hasn't chosen to show hidden files and Unhide protected operating system files? (BTW, that's done the same way as for the unhiding described above.) Of course that is long forgotten by the time you pull into your personal profile looking for your SendTo folder and find it staring you in the face right were you know it should be (because you are an experienced XP admin). You then click on it. It gives you some strange error about not being available but shows you the contents you requested anyway. You have to be ultra aware to notice that it has transported you off to the real location within the AppData folder. If you happen to be just that aware, you probably went back to that first folder to sniff around and try to figure out what just happened. You might even check the properties of the folder. It won't be any help to you. The only way to know what this folder is, is to key into the fact that there is a little black arrow on the folder icon. Actually, the best way to get info on these folders is to open a CMD window, change to your profile directory and execute DIR /A. Give it a try - I'll wait.....

CMD's DIR /A is the only thing that tells you what is going on. It will tell you which folders are junction points and tell you where you will end up if you dare walk through it. Here is the list it will give you:

Application Data [C:\Users\%UserName%\AppData\Roaming]

Cookies [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Cookies]

Local Settings [C:\Users\%UserName%\AppData\Local]

My Documents [C:\Users\%UserName%\Documents]

NetHood [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Network Shortcuts]

PrintHood [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Printer Shortcuts]

Recent [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Recent]

SendTo [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\SendTo]

Start Menu [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Start Menu]

Templates [C:\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Templates]

Thanks CMD - good info. I wish Vista's GUI could be so forthcoming. Actually, this raises another important point. I have never been driven to CMD so often as I have with Vista. There are a surprising number of things that are best handled through a CMD prompt because there is no alternative in Vista's GUI world. You have just met one example and you will meet more in future articles on this blog.

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.