One of the members of my gptalk mailing list posted this very informative email today regarding some issues he encountered with Folder Redirection. I figured it was worthwhile to re-post it here for everyone’s benefit. Hope everyone finds it useful!
Been having an interesting time with Folder re-direction on Windows 2008 r2 so thought I’d share my experience here in case anyone else encounters the same issue.
- Windows 2008 R2 Standard RDS Servers with no SP
- Folder Re-Direction being used
Folder Re-Direction not applying
Basically, to cut a long story short, there is a known issue with folder re-direction that can cause data loss. Consider the following:
- You apply a policy that re-directs the Documents folder to say \\server1\username. This policy has the flag ‘Move contents to new location’ enabled.
- You apply this policy and the users registry is updated to reflect the path
- You then change this policy or apply another policy that re-directs this folder to \\server2\username. This policy also has the flag ‘Move contents to new location’ enabled
- You check the locations \\server1\username and \\server2\username and find they are empty!
We encountered this issue and it caused us significant data loss (which fortunately we were able to recover). The issue is that in this case, \\server1\username and \\server2\username actually resolve to the same location. There can be numerous reason why different paths would resolve to the dame location (load balancing, DFS, segregated networks etc.) and I won’t go into them here.
The bottom line is the folder re-direction engine deleted my files! Why???????
Well, the issue is with the ‘Move contents to new location’ flag. When this is enabled the engine does the following:
- Update the registry to reflect the new location
- Copy the files from the old location to the new location
- Delete the files from the old location (as that essentially is what a move is)
Now, since the old and new locations are the same, step 2 never really happens and step 3 results in all the files being deleted!
Now, MS are aware of this and have a policy that prevents this happening namely:
- Verify old and new Folder Redirection targets point to the same share before redirecting
The description of which is:
“This policy setting allows you to prevent data loss when you change the target location for Folder Redirection, and the new and old targets point to the same network share, but have different network paths.If you enable this policy setting, Folder Redirection creates a temporary file in the old location in order to verify that new and old locations point to the same network share. If both new and old locations point to the same share, the target path is updated and files are not copied or deleted. The temporary file is deleted. If you disable or do not configure this policy setting, Folder Redirection does not create a temporary file and functions as if both new and old locations point to different shares when their network paths are different. Note: If the paths point to different network shares, this policy setting is not required. If the paths point to the same network share, any data contained in the redirected folders is deleted if this policy setting is not enabled.”
Note: Now, why this is not enabled by default to avoid this issue, I don’t know!!!!!!!!!!!!!!!!!!!!
Anyways, I applied it and it solved the issue for us. In fact, you only need this setting enabled and a failsafe if the ‘Move Contents to new Location’ is enabled on the winning folder re-direction setting. I generally don’t use this setting but that’s not to say anther team could not configure it and point the policy at the same location as one I’m using i.e. the user’s personal drive for Documents. The engineer creates a file with a >TMP extension in the old path and then checks for this file before moving the contents (if the move contents flag is set).
Thing is, enabling this breaks folder re-direction!
Yes, whilst this prevents data loss, it also prevents your folders being re-directed. It also has the annoying habit of leaving the .TMP files behind (if re-directing the start menu you will have a lot of .TMP entire sin your programs list!) . I have confirmed that this is a bug with MS support and they are working on a hotfix.
What happens is with this policy enabled, only some folders will re-direct. From what I have tested Contacts will re-direct but not ‘Documents’ and the .TMP file that is created in the old location is not being deleted. All event logs, traces etc. will tell you the folders are being re-directed but the registry will never be updated with the new path. It seems like a really bad bug to me. I’ll hopefully have some more info in the next days and be able to post back an update.
I’d be interested in seeing if anyone else had the same issue.