My Documents migration

[gshaw]

Didn't want to put one of my other threads off-topic so thought I'd make a new one

 

Situation is like this at the moment...

 

• one share per user on the file server
  
• roaming profile is inside My Documents folder in a folder called Profiles
  
• each user folder has permissions set as the User e.g. Joe Bloggs and Administrator Full Control
  
• each user folder has owner as local administrators group on the file server
  
• AppData was redirected inside the Profile folder (why I'll never know!)
  

 

This was how it was set up a long time before I was here, I want to change this to something more standard (and neater!) with a single share and user folders beneath.

 

Creating that system isn't difficult, standard GPO for redirection and I've used these permissions on the user data shared folder...

 

How to dynamically create security-enhanced redirected folders by using folder redirection in Windows 2000 and in Windows Server 2003

 

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

Edited January 5, 2011 by gshaw

[PiqueABoo]

I've used this recipe: Automatic creation of user folders for home, roaming profile and redirected folders which is "related content" on the KB you linked.

 

I set an account's profile path to \\server\profileshare\ and their homepath to \\server\homeshare\ 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.

[gshaw]

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

 

user.name (shared)

- all of My Documents in the root

- desktop

- start menu

- profiles

 

Which doesn't quite match with the proper redirected system that looks like this...

 

Userdata$ (shared)

- user.name

-- desktop

-- user.name's documents

 

So more scripting or trickery to make everything land in the right place

 

Creating new systems is easy, in-place migration of old ones is where it gets "interesting"!!!

Edited January 6, 2011 by gshaw

[gshaw]

Think I may have a solution using robocopy

 

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$

md \\server\migrationlogs$\%username%

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

: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




:fldrdirquit

echo DESTINATION NOT EXIST
goto end

:migrationquit

echo ALREADY MIGRATED
goto end

:finish

echo MIGRATION COMPLETE 
copy \\grs-adserv01\netlogon\migrated.txt \\server\%username%
goto end

:sub_fail
echo Something failed
goto end

:sub_housekeeping

echo Some housekeeping may be needed!
goto end

:end
echo *** END OF SCRIPT ***

Edited January 6, 2011 by gshaw

[PiqueABoo]

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.

[gshaw]

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!

[PiqueABoo]

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