mwalker-mdb
asked on
Moving Terminal Services Profiles
I am trying to move our Terminal Services Profiles from one server to the other. Here is what i have done:
Created the share on the new server and gave Everyone Full share access
Added the Domain users group to the folder access lisst with the default rights.
Copied the users profile from the old server to the new and deleted the old profile.
When I log in as that user they log in with a brand enw profile. when they log off there is a new fiolder on the old server with their newly created profile.
For some reason it is ignoring the newly created profile completely.
Created the share on the new server and gave Everyone Full share access
Added the Domain users group to the folder access lisst with the default rights.
Copied the users profile from the old server to the new and deleted the old profile.
When I log in as that user they log in with a brand enw profile. when they log off there is a new fiolder on the old server with their newly created profile.
For some reason it is ignoring the newly created profile completely.
have you changed the location on the actual account?
ASKER
Yes and it still doesn't move.
its premissions, you should have used xcopy to copy them over as your permissions are now screwed
test one account for me. Grant Authentication users full control share permissions on the root. On the users profile, grant the user full control in security settings, as well as making sure they are the owner
test one account for me. Grant Authentication users full control share permissions on the root. On the users profile, grant the user full control in security settings, as well as making sure they are the owner
ASKER
No difference. It still re-creates the profile directory on the old server. It totally ignores the settings in AD.
Is it possible it is a setting in a Group Policy? I don't know if you can set that through a policy.
I will check that out. Any other ideas?
Is it possible it is a setting in a Group Policy? I don't know if you can set that through a policy.
I will check that out. Any other ideas?
you can set roaming profile stuff through GPO yeah....but if you set an account setting it overrides anyway
ASKER
Yeah and I checked all the GPO's and there is no setting. I thought this was going to be easy.
have you got multiple DC's?
ASKER
Three DC's.
has replication occured on all DC's?
ASKER
Yes. I forced replication.
can you confirm the settings have taken on each server (just confirm the prof path for me)
ASKER
The change is on all servers
in that case i have no idea, usually a profile path is a simple process to move over - i have done it beyond count - sorry mate
ASKER
I know. I thought this was supposed to be easy. Thanks for the input. If you come across anything please let me know.
I've fixed this problem before by deleting the profile registry entry on the Citrix /TS server(s).
Each user gets an entry under
HKEY_LOCAL_MACHINE\SOFTWAR E\Microsof t\Windows NT\CurrentVersion\ProfileL ist
The key name is the user's SID, and values include the roaming profile path. I've occasionally had Citrix/TS that don't "see" the new path.
Fix is simple:
- identify the affected user's SID (I like psgetsid.exe from SysInternals/Microsoft's PSTools kit)
- delete the matching key from the registry
** Usual disclaimer about you're on your own: editing the registry may cause your server to crash, locusts to infest the Empire state Building, and a 3rd party candidate to hijack a close election. I'm not responsible. Really. Just ask my wife.**
when the user logs on again, the TS is forced to read the new entry from AD.
As far as permissions, Microsft has a technet entry on permissions for redirecting "My Documents", and I've successfully used the same permissions for roaming profile directories.
http://technet2.microsoft.com/windowsserver/en/library/a1b7ce04-708b-4145-830a-cadfc003acd31033.mspx?mfr=true
Here's part of a shell script I wrote that sets up permissions based on the KB. It requires the marvelous SETACL.EXE utility from sourceforge.net
set new-dir=%baseDataDir%\MyDo cs
mkdir "%new-dir%"
rem //
rem // backup existing DACL
setacl -ot file -on "%new-dir%" -actn list -lst "i:n;f:sddl" -bckp "%new-dir%.acl"
rem //
rem // set DACL to inherit perms (np - "no protection")
setacl -ot file -on "%new-dir%" -actn setprot -op "dacl:np"
rem //
rem // clear any explicit DACL permissions assignments
setacl -ot file -on "%new-dir%" -actn clear -clr dacl
rem //
rem // display DACL explicit assignments
rem // - should be empty
setacl -ot file -on "%new-dir%" -actn list -lst "i:n;f:tab"
rem //
rem // set DACL to "do not allow to inherit" and copy existing perms
rem // then set explicit ACE for "domain users"
rem // traverse: Traverse folder / execute file
rem // list_dir: List folder / read data
rem // read_attr: Read attributes
rem // add_subdir: Create folders / append data
rem //
setacl -ot file -on "%new-dir%" -actn setprot -op "dacl:p_c" -actn ace -ace "n:domain users;p:traverse,list_dir, read_attr, add_subdir ,;i:np;m:s et"
rem //
rem // display results in tab-separated format
setacl -ot file -on "%new-dir%" -actn list -lst "i:n;f:tab"
net share MyDocs$="%new-dir%" /grant:"Domain Admins",full /grant:"SYSTEM",full /grant:"Domain Users",change /cache:documents
Each user gets an entry under
HKEY_LOCAL_MACHINE\SOFTWAR
The key name is the user's SID, and values include the roaming profile path. I've occasionally had Citrix/TS that don't "see" the new path.
Fix is simple:
- identify the affected user's SID (I like psgetsid.exe from SysInternals/Microsoft's PSTools kit)
- delete the matching key from the registry
** Usual disclaimer about you're on your own: editing the registry may cause your server to crash, locusts to infest the Empire state Building, and a 3rd party candidate to hijack a close election. I'm not responsible. Really. Just ask my wife.**
when the user logs on again, the TS is forced to read the new entry from AD.
As far as permissions, Microsft has a technet entry on permissions for redirecting "My Documents", and I've successfully used the same permissions for roaming profile directories.
http://technet2.microsoft.com/windowsserver/en/library/a1b7ce04-708b-4145-830a-cadfc003acd31033.mspx?mfr=true
Here's part of a shell script I wrote that sets up permissions based on the KB. It requires the marvelous SETACL.EXE utility from sourceforge.net
set new-dir=%baseDataDir%\MyDo
mkdir "%new-dir%"
rem //
rem // backup existing DACL
setacl -ot file -on "%new-dir%" -actn list -lst "i:n;f:sddl" -bckp "%new-dir%.acl"
rem //
rem // set DACL to inherit perms (np - "no protection")
setacl -ot file -on "%new-dir%" -actn setprot -op "dacl:np"
rem //
rem // clear any explicit DACL permissions assignments
setacl -ot file -on "%new-dir%" -actn clear -clr dacl
rem //
rem // display DACL explicit assignments
rem // - should be empty
setacl -ot file -on "%new-dir%" -actn list -lst "i:n;f:tab"
rem //
rem // set DACL to "do not allow to inherit" and copy existing perms
rem // then set explicit ACE for "domain users"
rem // traverse: Traverse folder / execute file
rem // list_dir: List folder / read data
rem // read_attr: Read attributes
rem // add_subdir: Create folders / append data
rem //
setacl -ot file -on "%new-dir%" -actn setprot -op "dacl:p_c" -actn ace -ace "n:domain users;p:traverse,list_dir,
rem //
rem // display results in tab-separated format
setacl -ot file -on "%new-dir%" -actn list -lst "i:n;f:tab"
net share MyDocs$="%new-dir%" /grant:"Domain Admins",full /grant:"SYSTEM",full /grant:"Domain Users",change /cache:documents
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you want to stick to local user profiles on the Terminal Server, here's the procedure to move them to the new server:
1. Create a test user account
2. Log on to the old server with the test user account and make a couple of changes in the user environment. Write them down and logoff
3. Start regedit on the old server and export the following 2 registry keys:
HKEY_LOCAL_MACHINE\SOFTWAR E\Microsof t\Windows NT\CurrentVersion\ProfileG uid
HKEY_LOCAL_MACHINE\SOFTWAR E\Microsof t\Windows NT\CurrentVersion\ProfileL ist
4. Start regedit on the new server and export the same keys, as a backup copy
5. Copy the exported keys (the .reg files) from the old server to the new server and import them, by double-clicking on them
6. Use robocopy to copy the user profiles. In the following example robocopy is run from the new server:
robocopy "\\old_server\c$\documents and settings" "c:\documents and settings"
/COPYALL /S
/XD "\\old_server\c$\documents and settings\Administrator"
"\\old_server\c$\documents and settings\LocalService"
"\\old_server\c$\documents and settings\NetworkService"
"\\old_server\c$\documents and settings\Default User"
"\\old_server\c$\documents and settings\All Users"
7. That's it! Log on with the test user account and check the changes you made in step 2 to verify that your profile is loaded properly
1. Create a test user account
2. Log on to the old server with the test user account and make a couple of changes in the user environment. Write them down and logoff
3. Start regedit on the old server and export the following 2 registry keys:
HKEY_LOCAL_MACHINE\SOFTWAR
HKEY_LOCAL_MACHINE\SOFTWAR
4. Start regedit on the new server and export the same keys, as a backup copy
5. Copy the exported keys (the .reg files) from the old server to the new server and import them, by double-clicking on them
6. Use robocopy to copy the user profiles. In the following example robocopy is run from the new server:
robocopy "\\old_server\c$\documents
/COPYALL /S
/XD "\\old_server\c$\documents
"\\old_server\c$\documents
"\\old_server\c$\documents
"\\old_server\c$\documents
"\\old_server\c$\documents
7. That's it! Log on with the test user account and check the changes you made in step 2 to verify that your profile is loaded properly
ASKER
Thank you for the response but this was resolved months ago