I have been moving user profiles from one server to another. For the question we'll call them 'oldserver' and 'newserver' and the user is 'jbloggs'
While the user is logged out...
Copy the entire profile of jbloggs (\\oldserver\users\jbloggs
) to the new server using robocopy.
When that is complete, rename the old folder to 'moved_jbloggs'
Then go into active directory and change the 'Profile path' to \\\newserver\users\jbloggs\profile
and 'Home folder' 'Connect U:' to \\newserver\users\jbloggs
I have also changed the group policy 'redirect my documents' setting from \\oldserver\users
to \\newserver\users
But when jbloggs logs in, a new folder is created in oldserver! \\oldserver\users\jbloggs\jbloggs's documents
Does anyone know what could cause the user folder to be re-created on the old server? Is there a further step that needs to be taken?
It sounds like you have a Group Policy Object (GPO) with the Folder Redirection for the Documents folder enabled. Run a Resultant Set of Policy against a user with whom you are seeing the problematic behavior and it will lead you in the direction of the GPO you need to modify.
In the RSoP have a look in the "Windows Settings" sub-node of the "User Configuration" sub-node. I suspect you'll find a Folder Redirection policy there applying to the "Documents" folder. Assuming you do, before you go modifying it you would do well to read-up on how the feature works so that you have a good idea of what's going to happen when you change it.
Edit:
In my haste I neglected to see that you say you did modify a GPO containing some Folder Redirection settings. Check the event logs on clients that are exhibiting problems to verify that the Folder Redirection Client Side Extension (CSE) isn't logging any errors. It may be that your modified GPO is having a problem applying and the setting is remaining as it was. The CSE's Event Log messages should give you some indication if the modified GPO is failing to apply.
We had what looks like a slightly similar issue when we migrated user profiles to new hardware. Our "It's on fire and needs a fix" solution was to blow away the local profile on the machines that were logging in.
The other fix that we employed with some of our more difficult users was to open the registry and search for
oldserver
and change relevant keys to point to the proper location. Consider repeating the search withusers\jbloggs\jbloggs's documents
As a *nix admin the explanation I made up and have no backing support for was: Windows is doing something silly with the cached profile. Blowing it away caused it to be rebuilt in a more proper manor.