I've also made a share for AppData with the same permissions as the user data share. Tried a few test users and it works fine, logins are like lightning compared to how it is at the moment!
The issue is moving the user data over seamlessly as the files (and the user subfolders) need to have appropriate permissions set... as it stands all users' files seem to be owned by the local administrators group as their folders were made manually on the file server. This doesn't seem to play well with folder redirection as it needs the owner to be the user itself by the looks of it.
I've just tried with a test user logging in then moving the files from the old share to the new one while being logged in, they then gain the right permissions and owner. If I move the files on the server the permissions stay as they were and owner changes (as expected really)
The other gotcha is that I don't want to copy the old Profiles over so somehow need to exclude them, I know you can do exclusion paths with Robocopy but don't think I can tell it to look in each folder and exclude any called Profiles?
One method of attack seems to be...
change paths over on GPO
users then get a fresh My Documents folder
login script to move files from old path to new
create a flag file once files are moved so the script knows next time it doesn't need to shift any documents again
leave that running for a few weeks to catch all users
after a set period unshare the old home folders and archive
if any users weren't in over that period move them manually afterwards
The advantage there is that I could use the drive letter mapping in a Robocopy script so it could exclude the profile folder when moving stuff around. I'll put delprof in a startup \ shutdown script just beforehand + the GPO setting so users' old local cached copies get wiped and they then start again with a fresh profile from the new share.
It doesn't seem the neatest option but unless someone has a tricksy script to set the right permissions and owner based on the folder's name from the server side I can't see many other options as it stands? Would need to somehow populate all the subfolders and have the right owner set on each one to be able to do the migration from the server side it seems? It looks like I can copy a set of folders using Robocopy robocopy \\srv1\share \\srv2\share /E /LEV:2 /SEC /XF *.* but that doesn't fix the ownership issue as far as I can tell...
Last edited by gshaw; 5th January 2011 at 03:55 PM.
I set an account's profile path to \\server\profileshare\<account> and their homepath to \\server\homeshare\<account> and although I couldn't use the variable in GPOs, I essentially redirect MyDocs to %homepath%\Documents and redirect (roaming) AppData next to that in %homepath%\AppData.
The script I made to clean up after robocopying lots of user MyDocs from an ex-system to a new one is the one I mentioned in this thread.
Check that Automatic Creation recipe link and have a think about all this e.g. if your redirection isn't relative to a user's AD home and profile paths my script won't help (it would need "re-tuning" for another system plus, ::horror::, a comment or two in the code regardless).
Alternatively, you could probably just make one using something like a DOS for /d command to call setACL on a bunch of subfolders (if you can make owner work with an account name - I didn't try too hard) or one of the other utils for fiddling with perms etc.
The user folders are working fine and their permissions are working OK with the GPO redirection, it's really just shifting the data that's the issue. I think it's better to try and move data into the new folders that are all setup correctly rather than trying to make the original folders match up with new permissions (seems like it could end up rather messy!)
Just found another issue, as it stands the folders look like this...
- all of My Documents in the root
- start menu
Which doesn't quite match with the proper redirected system that looks like this...
It checks to make sure the new redirected folder has been created and also checks that a flag file isn't already present (to show migration has already gone through)
It then shifts My Documents into the new location, skipping the old Profile folder and Desktop. If that completes successfully it then migrates the desktop files to the new location as well.
Log files go into a folder on the server with matching user name and if all goes through OK copies a flag file to the old My Documents location to ensure the script doesn't run next time.
Was thinking of putting this as a login script if testing goes OK, means one login will be quite slow as it moves over but should avoid any files in use issues...
Might try and tweak the sub_fail to email me with results of any migrations that fail for whatever reason as well.
if not exist \\server\userdocuments$\%username% goto fldrdirquit
if exist \\server\%username%\migrated.txt goto migrationquit
net use M: \\server\migrationlogs$
M:\robocopy.exe \\server\%username% "\\server\userdocuments$\%username%\My Documents" /MOVE /E /XD \\server\%username%\profiles /XD \\server\%username%\desktop /LOG:"\\server\MigrationLogs$\%username%\mydocuments.log"
if errorlevel 8 GOTO sub_fail
if errorlevel 4 GOTO sub_housekeeping
if errorlevel 1 GOTO migratedesktop
M:\robocopy.exe \\server\%username%\desktop "\\server\userdocuments$\%username%\desktop" /MOVE /E /LOG:"\\server\MigrationLogs$\%username%\desktop.log"
if errorlevel 8 GOTO sub_fail
if errorlevel 4 GOTO sub_housekeeping
if errorlevel 1 GOTO finish
echo DESTINATION NOT EXIST
echo ALREADY MIGRATED
echo MIGRATION COMPLETE :)
copy \\grs-adserv01\netlogon\migrated.txt \\server\%username%
echo Something failed
echo Some housekeeping may be needed!
echo *** END OF SCRIPT ***
Last edited by gshaw; 6th January 2011 at 11:35 AM.
Creating new systems is easy, in-place migration of old ones is where it gets "interesting"!!!
You've got a few more possibilities than migrating old ones to new ones, where for instance you couldn't do your logon script approach.
I wouldn't choose the login method because if there's any random pain it will just prolong that and it's not the most efficient approach. YMMV but I'd much rather move stuff in bulk at the server-side, fix any errors that happen, fix perms + ownership, job done, next.
Talking of errors: Whatever method you use I would look for stuff that is approaching maximum path length in the source, and perhaps reduce any culprits down to 200 chars or something.
Yup I agree, the server side move is easier but the worry I've got is that with the permissions and folder structure being so different to what they need to be it could make a horrible mess trying to move it in situ. Will need to play around a bit more and see if I can create the folder and permissions structure via script but might take a while to get it working neatly.
The only issue I've seen with path lengths has been in the profile but they're getting recreated from scratch anyway as they're a mess at the moment!
Think beyond the initial migration: If you're going to use this dynamic approach where you don't have explicit NTFS permissions and everything revolves around ownership, then you'll likely need to be able to remove stray perms and reset ownership for one or more user folders in future.
It's not that often, but there have been occasions when for one good reason or other, I've wanted to go to a server and drop a few files in one or more folks folders.. after which I want the ownership changed from Admin to the respective user(s). Better to have that capability present and correct now, rather than trying to make it in a hurry when someone's scwtheaming about how incredibly urgent..