Sunday, November 25, 2007

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.

30 comments:

Anonymous said...

Excellent post. I just went through a server move, and now have to do it again. The biggest challenge was preflighting redirected folders, etc. for path length, invalid chars, etc. prior to the move. This was a tedious process. I'm still in favour of roaming profiles, folder redirection and offline lines but server support usually balks when having to move user data. Have you looked at DFS namespaces with failover root targets for folder redirection?

Go Sens go!

Anonymous said...

Your suggestions worked like a charm! (XP/2K). Now what about those redirected folders that are made available offline while the target servers are changed? I've had to deal with annoying persistancies in the offline folders cache.

Gordon Martin said...

Welcome NRCan! It looks like a few of you have been visiting today... I'm surprised path lengths and invalid characters are giving you grief - what were you doing before?

I've successfully redirected to DFS targets without issue. In fact, Folder Redirection was fun without my hack because it got confused by the old and new target really being the same location ("File in use!" :-)

@Tony - you used my hack on XP and 2K? With a UNC path or with a drive letter?

I haven't come to any conclusions on the Offline cache issues. I have put many questions to Microsoft trying to get real detail on how the cache behaves (persistence, etc.). I haven't got any useful answers yet - mostly just links to outdated XP docs - Vista's cache has a lot of differences from XP. I'll post if I ever get more info.

Elric said...

Hello,

We tried to move redirected folders back to "classical" roaming profiles using GPO and letting Vista do the move. Most of time it works, but sometimes a part of the folders still redirected, it may be the Desktop, AppData, ...
The best thing is that you can not see it in vista with normal tools, you have to look in the registry to see that these folders are still redirected.

Did you already face this type of issues while playing with folders redirection changes and GPO ?

Gordon Martin said...

Hi Elric,

I wouldn't mind some more details on your experiences. What tools do you speak of, and how do you return to Classical roaming?

I did write an article, Vista's GPMC: Don't trust it, where I had similar experiences with GPMC. I should mention that I have confirmed that when you install Vista's SP1, GPMC is removed from the system and Microsoft has not yet made it's replacement available yet. If you are configuring Folder Redirection for Vista, ensure that you do not upgrade one of your management PCs.

Also, Windows treats managed and unmanaged GPO settings differently. Unmanaged settings aren't returned back to their default state after settings have been removed. Behavior of such settings could be more difficult to interpret for profiles that roam from one computer to another (an old machine would continue with the old setting while a new machine would only know to use the default setting.).

Elric said...

Hello,
In the beguining we were using redirected folders coupled with offline files for all profile related elements.
After a lot of issues related to the offline files and some poor network performances we decided to go back the way profile were handled in XP.
To do that we added a domain policy where all profile elements are stored back in the local roaming profile, and that profile data is moved automatically by the system.

We applyed the policy to a specific OU and moved the the users we wanted to convert into it.

Thanks to the ability of vista to move the files by itelf we where able to convert profiles quite fast.

Once the operation is done we clear all the offline cache through a registry key.

It is quite efficient, with gpupdate and two login/logout you are finished.

The thing is that the "Magic" move worked partially on some profile, where one directory (not always the same) is still redirected on the network.

The best thing is it still redirected after going back and forward between old and new policies.

Concerning gpmc we did the SP1mistake, and we had to reinstall the computer use to manage policies ...

Gordon Martin said...

Hi Elric,

That's a clever solution. I'm sure others will find it handy to temporarily abandon Folder Redirection as well. Not everyone is comfortable with scripts or with registry modifications.

Do you remember which folders would sometimes continue to redirect? I have memories of seeing different behaviors from the folders that were traditionally redirected in XP versus those that are new to Vista.

Elric said...

Hello,

The worst case was AppData/Roaming.

Gordon Martin said...

Hi Elric,

Yep, AppData\Roaming would be one of those new folders.

You probably did this so I mention it for others... If you want to stop redirecting to the network, don't simply remove the GPO setting, rather specify that the redirection target should be "Redirect to local user profile path". This will hopefully force the folder back to the local location rather than relying on Vista to do the right thing on its own accord.

Anonymous said...

I'm experiencing this very thing right now in my area with ~300 XP users. Our old fldredir server space is being decommissioned and a new one is ready to roll. I backed up the users redirected data, restored it to the new location, set share and verified ntfs permissions, changed the GPO to point to the new location, removed the share on the old server, and a couple test users I created had trouble with the move. When I logged in as them, I got an error stating that they no longer had access to \\oldserver\fldredir\userjoe\desktop. Even though I set up permissions on the new server correctly, it was still looking for the old server in the users profile. Reading up on this, microsoft seems to want me to remove the policy, have every user log in and out, (this will return their data to their roaming profiles because I have that set in the GPO) then reinstate the policy with the new location identified. 300 users? 110 of which haven't logged in in over 30 days? There had to be a better way to get this done. I'm not a script guy. Will this script accomplish what I need to do in an XP world?

Gordon Martin said...

Hi Rob,

Yes, XP has its share of Folder Redirection problems as well. In the XP days we did without the Folder Redirection GPOs entirely and just used the registry trick to make things happen. That wasn't possible this time around because the Desktop and Start Menu are now redirected under Vista.

This script will work under XP just fine. There are of course extra redirected folders not used by XP, but they would just be ignored by the OS if you don't take them out. The Documents folder hasn't changed in the registry - it's still called "Personal" so that will all still work. You also have to make sure that your Home Folder Path is pointing to the correct location (same as in Vista).

Just call the script from your logon script and change the GPOs back to your old locations. Once you are sure everyone has had a chance to logon at least once, set the GPOs back to the new location.

If you have no one to script for you, I do consult.

Let us know how it goes!

Anonymous said...

Heh, right after I posted here, I saw what I wrote, and realized "I removed the old share"...crap lol. Without the old share in place, the system couldn't do it's job and move the files, because I moved them already. So I did a few more test users and did it the microsoft way. It worked, but ugh, what a PITA!
Of my users, 1/3 are infrequent and this path would take an eternity unless I log in/out as them, and that opens up privacy issues.
So, I'll give the script a shot here, where do I run/put it?

Gordon Martin said...

I didn't understand Microsoft's logic on that one either.

It doesn't really matter where you put the script. It just has to run before the user logs out and has to be able to edit the user's own registry settings. Typically you would call it from an existing logon script. But you could also use a GPO to launch it or even the Startup Folder. It really is quite a straight forward little trick.

Anonymous said...

Well, I went the old fashoned route on this and had users log in and out...4 months later things were looking ok. Recently I've noticed a new pain in my temples and I can't wrap my head around it.

When I create a new user named, tracy, the GPO for folder redirect points them to \\newserver\share\tracy. BUT when the user logs in for the first time I get an error message stating: "\\OLDserver\share\BOB\desktop refers to a location that is unavailable. blah blah blah"

No matter what I name the new user, they all try to use "BOB"'s desktop.

The only way I have found to stop the error is to delete \\OLDserver\share\bob. then when tracy or tim log in, they create \\OLDserver\share\BOB again and they are listed as the owner. I'm truely lost on this one.

Anonymous said...

Quick update. 'tracy' is indeed creating a \\newserver\share\tracy folder like the policy wants. What the error is referring to is that she doesn't have access to the \\OLDserver\share\bob\desktop folder BECAUSE (per event logs) "failed to perform redirection of the folder desktop. The folder is configured to be redirected from <\\OLDserver\share\bob\desktop> to <\\newserver\share\tracy\desktop>. The following error occured: the directory name is invalid.

SO, it's trying to move the desktop from the old server to the new server. But with this being a brand new user, I don't know why it's trying to do this instead of simply creating the new users desktop.

Gordon Martin said...

Fun!

I found this line interesting:
"The folder is configured to be redirected from <\\OLDserver\share\bob\desktop> to <\\newserver\share\tracy\desktop>."

As you know, the redirection GPO only specifies the target - not the source. If this is indeed a new user with a new profile, the old location should be the default location of "C:\Users\Tracy...".

Vista has to be getting told about Bob's folder somehow in the user's registry in the user's profile. Are you doing a registry hack as per my suggestion but pushing the wrong value at the wrong time? Are there registry entries in the default user profile that get copied over when a new profile is created?

Since Vista thinks it is unable to migrate from an old location to a new location, it should continue using the "old location" and you should see the value in the registry. If you were to manually replace that value with the desired one, the problem should go away (for that instance anyway - it might come back when the person logs into another machine and gets a new profile there).

I hope this helps - let us know what happens!

Anonymous said...

heh, I found that interesting as well. I'm creating new accounts, I'm not copying any accounts, and it leads me to believe it must have something to do with the default user, but I have no idea where to look. It's windows XP btw.
Best I can figure, 'bob' was the account I created, then copied as the default user account some time ago, and somehow that hosed it up. I think I'll have to come up with a way to re-create a fresh default user account. Ugh.
I pussed out and didn't use the registry hack when I began this, I did it the microsloth way and waited for all users to log in and out.

Gordon Martin said...

Yep, I'm sure it's coming from the default user profile you've put up on the domain controller. At least you will find plenty of clear and accurate MS documentation to guide you through the process of making a new one - it's not a big deal.

I'll forgive you for not putting complete trust in me this time - how were you to know I speak the truth ;-)

Unknown said...

This is en excellent article!! But I'm unsure about what you write regarding DFS. We have Folder Redirection to \\ad.local\dfs\Users\username\Documents. This is physically \\SRVOLD\Users$\username.

Are you saying that if we would move the data to \\SRVNEW\Users$\username and then change the DFS link to point to the new share, we'll have a problem?

For the user and his computer, the link for the users HOMEPATH and HOMEDIR would be exactly the same since we're using DFS.

Gordon Martin said...

Hi Jonas,

I'm pleased you were able to follow that long article. Regarding DFS, you don't quite get what I was saying...

Your scenario of moving from SRVOLD to SRVNEW would never be a problem because DFS adds a layer of abstraction so Folder Redirection never sees the physical location, but instead the published DFS name (the DFS name shouldn't have changed).

Problems are experienced when the published DFS name changes. In the old days physical UNC paths changed whenever data was moved to new servers. Now DFS names are changed whenever there are organizational changes or a change in approach to DFS naming conventions. In the end any name is always changed for one reason or another.

The two DFS scenarios I discussed in my article are this:

1) You introduce DFS for the first time. The data remains in the same physical location, but now you change the target UNC path from the physical path to the new DFS name. Folder Redirection will think this is a change of location (since it will see different paths), but the data does not need to be moved since in reality it is still the same physical folder. This is when Folder Redirection will ignore the new location and resort to using the Offline Files cache stored locally.

2) Inevitably you will change the published DFS name one day. Folder Redirection will see the new UNC path as another situation where data will be moved. It will fail in the same way it does for data moves when DFS isn't involved because the old location shouldn't be available any longer. However, if scenario 1 had already happened and previously shifted to offline mode, Windows is now completely confused.

-- I hope this helped clarify things a bit.

I assume you are trying to apply all of this to Windows 7? I haven't worked with that OS yet. Is all of this information still appropriate to Windows 7? I'd love to know.

Unknown said...

Thanks for the clarification. In your comment, it's 1) that we're implementing. We're moving away from \\SERVERNAME to using DFS. So I guess we simply have to make sure that we run your script at login to make sure the registry is changed to the DFS-path instead of SERVERNAME-path?

We're still at Vista so sorry, can't say if this has changed in Win7.

rpscripter said...

I really appreciate your posting this. The issue continues in Windows 7, and so does your fix! This fix really made a much smoother transition from one server to another in our mixed XP/7 environment. Parts of the script worked for XP, but since it tended to update right away, I didn't have nearly the complexity as 7.
Thanks again!

Gordon Martin said...

Thanks, glad I could help rpseek. Nice to know the blog is still helping people out there.

I was quite sure that all of this still applies to Windows 7 since the basic architecture hasn't changed, but since I have moved on to other responsibilities I have been unable to test.

Good luck with everything!

Brian Klish said...

"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."

So would there be any issue if you just set Group Policy not to move them? Then an admin could move the files as you explain he would want to. Would the sync work for existing files that hadn't yet been sync'd to the old server? Would the offline file cache still think it had files from the old server or would they now be associated with the new server?

Anonymous said...

Hello.

Your post is very clear and understandable. very helpful for my work.

Well done.

Anonymous said...

This is still the best article around that I return to whenever I need to perform a fileserver move.

Have you figured out the differences for Windows 8 yet? :)

Gordon Martin said...

Hi Brian, Sorry for the incredible delay in responding - I haven't blogged in ages.
You have found the exact problem with the feature. Any admin would not naturally want that GPO feature turned on. But then files don't get hoovered off of the workstations either. The OS treats a change from no redirection to redirection as a "move" as well. The GPO really needs two check boxes. One for server moves and one for workstation to server "moves"

Gordon Martin said...

Hello Anonymouses,
Thank you for your kind words. It was nice to fill the void back in the Windows Vista days when there was almost no information available on the subject. It's nice to see that this blog still has a place.
Regarding newer versions of Windows. I have moved onto other challenges and so haven't been in a position to explore or test these features any longer. But it is my understanding that the architecture in Windows 7 has remained largely untouched since Vista so virtually every article in this blog still holds true. I would expect similar results from Windows 8 since the GPOs governing this feature haven't changed yet.
I know that after 5 years my organization still uses this script/hack and we are supporting Windows 7 as well.

Anonymous said...

Nice that you still reply :). Wish you the best in your new challenges.

If you remember, what would your BEST PRACTICE be if you're building new? Make sure you keep the redirected folders on a path that will "NEVER" change so you don't have to worry about "filservermigration"? I guess that would mean DFS.

Gordon Martin said...

How's this for a fast reply? :-)
Actually, I can confirm that the problems that lead to this solution still exist in Windows 8, so I fully expect this script to continue to function.
Within the confines of a Windows implementation, I have no regrets with the solutions we chose. We had discovered the majority of our problems before going live and mitigated those with the various solutions found in this blog. Although the script may look daunting, it has been a breeze to maintain. No modifications have been required and it has not given us any nasty surprises. I really don't know how anyone can have a safe Folder Redirection experience without it.
Duplication of folders is unavoidable without the "Move data" option. All of our GPO folder redirection destinations would have been impossible to manage within the confines of the GPMC interface - using the Home Path within the user's profile was a must.
It really isn't possible to have an environment where the paths never change. You may be able to avoid it for some years, but ultimately new staff won't be aware of the pitfall of a path change and will fall right in. DFS isn't of any help either. Server names may no longer change, but if names are based on organizational, locational or functional relationships, those will be required to change for one reason or another. The only way to avoid change is to start using ridiculous meaningless names like serial numbers or cartoon character names or something.
The nice thing about the script above is that it doesn't need to be implemented before implementation time. It can be slipstreamed in anytime since it just swaps out the harcoded names with varioables that get to be spoofed later. The only problem is that it must be done before any migration/change takes place. No one will have the presence of mind to not implement this solution with the plan to remain static, then 2 years down the road decide to implement because they realize they have an unavioidable change coming. I am very curious about how many companies have spent time with Microsoft trying to fix lost data problems, etc. I imagine a great many of them are very thankful for their backup solutions.