Group Policy Blog

Group Policy Tips, Tricks, and News from Darren Mar-Elia

Interesting “Bug” in GroupPolicy Folder Redirection results in lost data

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!




Hi guys,

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:


  1. 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.
  2. You apply this policy and the users registry is updated to reflect the path
  3. 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
  4. 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:

  1. Update the registry to reflect the new location
  2. Copy the files from the old location to the new location
  3. 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.

There are 15 comments .

Greg —

My company ran into this, too, several months ago. We lost very little data fortunately because of backups, but we worked quite a while trying to figure it out. This is the first time hearing that there is a group policy to prevent the issue. Someone presented the theory of why the files were being deleted and it matches perfectly what is described here.

Our fix was simply to turn off the option to move files to the new location. Any home drive moves to new locations we do generally happen en masse involving a file sync prior to the move.

Reply »

Hello Darren,
We have the exact issue but in my case i lost my data. I will tell you from start what happened. I applied the FR policy by configuring it in my default domain policy(mistake 1) at location “\\adc\users”
I then modified the policy and changed the setting to NOt COnfigured without being aware of the “Move contents to a location” was still checked (Mistake 2). I create a new FR policy and provided a new location but in the same shared drive (a new folder), but this folder name was “\\adc\user shared folders”. Now due to only some files and not all files being redirected and offline files mess i decided to turn off the new policy but this time i choose the “Redirect files to the original location” and choose to disable the ” Link Enabled” option but did not delete the files and all went well . But on this weekend the all servers had to be restarted and that caused the start of my issues, all users lost all data and i dont know why the policy is applying as all settings are diaabled and gpresults and rsop also show that no folder redirection is enabled. All my desktops and servers still have the registry user shell folder settings pointing to the netwok share even after using gpupdate /force. Also the network location is still getting populated with user folder which are empty. I need to know where these files are going. Can you help we find em I am going nuts.

Reply »

Ugh…. same issue happened for me today!

Fortunately backups are on my side, but I simply change the redirection from domain\username to fqdn\username (so the exact same server, same location, I just used the FQDN instead of the netbios name) and the same thing happened, the move deleted everything inside the My Documents redirect. :( How unexpected!

Reply »
martin —

same here, fqdn to netbios, this was not wanted quite a mistake.

XP clients we still have reacted differently, we had one that lost it all. but we also have 2008 r2 sessions on citrix and w7 and this has become a huge mess. and problem is I am not sure we are out of it. While restoring files after some logons and FR applied, things are going away again. Must I apply the verify policy ? it is a computer settings, strangely.

Reply »
    Darren Mar-Elia

    Thanks for this Martin. I meant to pass this along but here is the latest on this issue from one of our GPTalk list members:
    Final update here:

    • The final hotfix is scheduled for release on the 13th of March and will be available publically under KB2799904 on this day.

    This update is for machines with SP1 and will resolve the issue where the registry is not updated with the new path if the new path resolves to the same network path as the old path. So to summarize this messy issue:

    1. If old and new folder re-direction paths resolve to the same network location, there is a possibility of data loss if the ‘Move Content to new Location’ flag is enabled on the wining GPO. To resolve this, do one of the following
    a. Disable the ‘Move Content’ flag unless needed
    b. If the move content flag is needed then enable the policy ‘Verify old and new Folder Redirection targets point to the same share before redirecting’ is enabled

    2. 2nd issue where was if you had several folders re-directing in the same policies, at times, the registry would not be update at all and hence certain folders would not be re-directed. The solution to this is:
    a. Apply SP1
    b. Apply this hotfix even though is documented for a different application KB977229 –

    3. Finally, with SP1 installed, if a new folder re-direction path resolve to the same network location as the old path, the registry is not updated where as it should be. Note: This should happened regardless of the state of the move contents flag or ‘verify old and new locations …’ policies. The solution to this:
    a. The final hotfix is scheduled for release on the 13th of March and will be available publically under KB2799904 on this day.


    Reply »

Oh yes, same issue has been ongoing for years. I’m with a public school and I had a premiere support case on this way back in 2010.

Unfortunately, this is still happening on our student workstations. The home folders are no longer being deleted, but students are randomly denied access to their home folders.

There is a lot of detail here,(my posts are under altonPM):

And here:

I will be looking at the various hotfixes identified in the comments here.

Reply »
Rogier Burlage —

Pffff…luckily I’m quick. Did a desktop redirection with “Move the contents of Documents to the new location”. The redirection worked for new files and folders, but at the same time deleted the test folder which was already present on the desktop. Yikes – backup first before implementing this.
– Win7 Prof 32-bit

Reply »
    Rogier Burlage —

    *I mean “Move the contents of Documents to the new location” unticked of course

    Reply »
    Rogier Burlage —

    Pfff…ok. 2 users received the GPO..but it’s working correctly. I guess I should stop living on the edge and work on live GPO’s 😉 Needed to destroy my VM, because once the redirect is set, you can’t turn it off, even after gpupdate /force and reboot, it just kept redirecting. My new VM didn’t redirect.

    Reply »

I have tried to follow all kind of recommendations and links to minimize the risk for datalos but i’m consues and run into diffrent issues all the times.
Fist, when trying to install the KB2799904, it state it’s not valid for me. I have then found out that KB2798162 that I do have installed have a later version of the Shell32.dll so it should inlcude the fix as vel but i’m not 100% sure how I can validate. As for the KB977229, this is also not valid for my system (since it is SP1 I guess). When I add the FolderRedirectionEnableCacheRename registry key and then try to change my forder redirect path from \\oldserver\mydoc to \\mydomain.local\mydoc (pointing to the olds server share) I get and error:
Failed to apply policy and redirect folder “Documents” to “\\oldserver\mydoc\username\My document”.
Redirection options=0x9021.
The following error occurred: “Can not rename folder from “\\oldserver\mydoc\username\My document” to “\\mydomain.local\Mydoc\username\My documets” in offline cache, hr = 800700B7″.
Error details: “Cannot create a file when that file already exists.

Any tipps? Did you all get this to work?
The goal of my chaneg is to move from server share to DFS-N and not need to recopy data and not resyncronize offiline cach



Reply »
    Darren Mar-Elia

    You might want to post your issues on the GPTalk forum, under the posting related to this issue. You might get some responses about your issues, but it sort of sounds like your issue is a different issue.


    Reply »
Teukka —


I think one should not even use the “Move contents of the Documents to the new location” settings when moving user’s Documents folders from server share to another.

TechNet Article states:

“Move the contents of My Documents to the new location. Moves any document the user has in the local My Documents folder to the server share. This option is enabled by default.”

If I understood this correctly, only time you should ever use this setting is when you want to move user’s LOCAL My Documents folder to the server server.

I’m in the middle of migrating users Documents folders to new server share and originally planned to use this option, because it gives benefit of moving unsynchronized files from Documents client-side cache to server.

I think MS should do better job documenting use of this setting.

Reply »

Share Your Thoughts!


Copyright © 2015 SDM Software, Inc.
Site design by Social Media Ninjas