Link to home
Create AccountLog in
Avatar of somewhereinafrica
somewhereinafricaFlag for Haiti

asked on

redirection of folder went wrong, how do i fix it

I was redirecting everybody's 'document' folder to a share on a server. I then changed the shared folder for a DFS folder instead. Every bodies change went over well except for one guy.

he had over 14GB in his documents folder, and grew tired of waiting while the copy was underway, so he unplugged.

His computer is still convinced his documents folder is on the old share [\\servername\sharename] instead of the dfs share [\\dfs-share\dfsuserfolder].

however, it did create a folder when he started the initial change (as in that the computer started to move his documents folder), but now it just wants to keep pointing at the old share.

How do i "reset" his folder re-direction, and then set it up again. Alternatively how do i just set the documents folder to catch on to what the Group Policy tells it?

Avatar of Darius Ghassem
Darius Ghassem
Flag of United States of America image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of somewhereinafrica


that guide was for server 2000, I run server 2008, is the procedure the same (as far as you know)?
I'm sorry, i meant to say that the guide is for Windows 2000. This is a windows 7 client on server 2008 backbone. Noot feeling confident to assume all settings are the same?
The registry settings should be the same in Windows 7
ok, so i Make the registry change... Then what?
Will GP not get mad?
Once you change reboot the server then the GPO should apply properly
I am confused, what does the server have to do with this?

I am attempting to change the re-direction of a folder from a previous location to a new location. The GP works, since everyone else has their stuff working for them. I was under the assumption that I was to erase the registry setting on the local computer, and that would take care of it (as in that when i reboot the GP would kick in and set it straight).

what am I missing? Why is there a server reboot involved?
I'm not saying the server on a client that the user is logged into
'Once you change reboot the server then the GPO should apply properly"

sounds like you are saying 'server' to me.

I am going to assume that you mean to say that once the registry change has been made, a reboot of the client should solve the problem once the GP kicks in a sets it up again
Sorry must have been typing fast client needs to be rebooted
ok, have been crazy busy, will try it today...
Ok, so I created the exact same GP with a different name.

I log on user 'X' to her old computer

i run gpupdate /force

all looks like it is working fine

When i log back on nothing has changed

i then log on using user X's credentials on a newly imaged machine

works perfect

now back to her computer again, and it still does not work.

So you are saying, go in and manually change the registry settings - mentioned above - and now it should work...

That's the gist of it?

I just don't understand why it doesn't change on her original machine, i mean surely the GP tries to edit the value, but it doesn't stick...
Yes but there are lagging registry keys.
ok, so I have been given a generic registry fix, could someone help me decipher it?

Here it is:
REG DELETE “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders” /v Desktop

REG ADD “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders” /v Desktop /t REG_SZ /d C:\NEW_LOCATION


This is supposed to delete the old and put in the new - here are my questions:

1 - What is the "/v desktop" switch and what does it do?
2 - so all I have to do is change the "c:\NEW_LOCATION" to "\\DFS_ROOT\DFS_SHARE\" and i'm golden?
I wouldn't even do the RED ADD your new gpo should create this for you.
Well, you are assuming that the registry change will be set by the GPO - Whos failure to do so is the reason why I am in this mess to begin with.

So your statement opens a few questions:

so you are saying - kill the registry setting, reboot and it should be fixed by the GPO.

1 - By deleting the previous setting you are telling me that the new setting will fill in fine by GPO... Because it 'should' or you KNOW that an empty registry setting will be fixed by the GPO where it failed to edit it last time?

2 - what happens if i reboot, the registry setting is empty  (after my hack) and the GPO does not work? what will happen to 'documents' with an empty registry value?

3 - why do you think it would be better to bet that the GPO will fix (what it failed to fix before) the registry setting than editing it myself? Will the end result not be the same?

Please don't read any attitude in these questions, I just type them out as they come up in my mind...
When you don't move the gpo location properly you can see issues like this when it comes to a GPO folder redirection location. You can test this by running the command Reg delete on one computer only this will allow you to see if after a reboot the GPO applies properly
... and an empty reg setting in this case will make what happen?

there will simply not be a 'documents' folder when i log in?
and if that is the case;
what happens to all the files that was in the 'documents' folder that does not exist?
If you have the MyDocs currently located on a network drive then the files will stay. If you have them on the local computer then I would copy to make sure you have a backup but the files should stay or redirect.

Documents folder will always be there this can not be removed. You are just removing where it is actually stores it data.
The Documents folder can indeed 'disappear' as it has done on several machines that has had this issue.

You open the user folder and the documents folder is just simply not there... at all...
Well, as far as i can tell it at least tries to apply.

I run the gpupdate /force, and it 'acts' like it is doing what it is supposed to be doing (mentioning that there is a folder redirect that can not be dealt with unless i log off and on again)

I run the gpresult /z blah blah blah
and it says that the GPO in question is the only one that is being parsed (skipping the others that i have not associated with this user), yet no change has happened.

SO I do this 20 times over in every combination i can possibly think of, nothing. Then today this morning I log on with my test machine and now it seems to be working perfectly.

I will now go and try to see if the rgistry hack works or not...
Let me know
Ok, so here is how it went.

Running that first part of the script does not work ( REG DELETE “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders” /v Desktop ), nothing happens and it says it can't find the registry key.

So I go in and clean out any references to "\\server_name\share_name in the shell settings for the registry.
I leave them blank and run a gpupdate /force, rebot and so on and so forth.
that will make the computer boot up with STILL empty registry settings... The GPO fixes nothing.

So I then add the UNC manually in the registry and reboot.
The UNC stays (after reboot) but the video and music folder didn't work for some reaon.
I run gpupdate /force again and reboot...
Now when i log on the UNC is there, and the video/music/picture has been filled in automatically
Now it seems to work.

So here's how to do it:
1 - manually change the 'personal' key (documents) in the registry and add your own UNC
2 - delete the UNC references to music/video/pictures
3 - reboot
4 - run gpupdate /force
5 - reboot
6 - done

Thanks for all your help.
Weird you had to do all those steps I justed tested on a system I have broke the GPO without sending contents to new location properly within the GPO. I then deleted the reg key then after a gupdate /force then rebooted the correct path came up.

Glad it is working for you
well, I wish it was a simple as your instructions, but you know as well as I that there can be a gazillion little things that messes up something that "should work".

Your theory was sound, I just know these machines have a mind of their own sometimes.  I also am very pressed on time to deal with each case, and they are not very keen to lend their computer to IT for a couple of hours. In the end the solution that worked for me was the brute force one. I could not have done it without your guidance to the registry issues...

Until next time...