Migrating roaming profile share to a new server

hi jfer, the new server is a member server already but i'm not sure what you mean - the migration tool wouldn't move the shares would it?

good point on the mirroring

Hi,

according to MS, yes

http://www.microsoft.com/DownLoads/details.aspx?familyid=6D710919-1BA5-41CA-B2F3-C11BCB4857AF&displaylang=en

I myself have never tried this, but it is worth at least trying it

Jfer

Hi Jfer

after going through the 200 odd page of the ADMT user guide and giving it a test run i have found out the migration tool is to migrate users to another domain, it will not let you migrate users folders to another server on the same domain

a good idea, i thought this would make my mission a lot easier, but sadly it is not the case.

thanks anyway

Hello,

i was under the impression the roaming profile reference would be moved to the new server

In any case i will make a script for you, to save the time

Jfer

Hi

yes the roaming profiles are moving to a new server, but in the same domain. i'm just replacing a tired old file server

thanks, any help is appreciated

to clarify - Active Directory is on a separate server (PDC) controlling only the logins, the users profile paths point to server1 to look for their profiles

Ok

first, make sure all 500 users are offline, seeing as this is a long weekend, take advantage of it

(it's important to make sure to get everyone's last bit of info because if they use info on the old profile while doing the move, they will lose the info-remember)

secondly, use a tool like RichCopy or Robocopy to move the profiles to the new server

after you made a good, working copy of everyone's profiles

Finally, found this on

http://forums.windowsitpro.com/web/forum/messageview.aspx?catid=43&threadid=47964&STARTPAGE=1

DSQUERY USER OU=Employees,DC=Example,DC=com | DSMOD USER PROFILE 3\\TargetServer\Profiles\$username$3

So modify your DSQUERY appropriately so that it outputs the appropriate list of users and pipe it to DSMOD

Viola, just make sure to modify script for needs

Jfer

Do you really need to copy the profiles?

Is it as simple as changing the AD roaming profile property to the new server location and the next time users log in, it will copy (syncronize) their local profle to the new server, since nothing is there. Just create the main folder/share first (e.g. e:\profies) on the new server.

He needs to copy the profiles because he indicated that he was running out of hard disk space, the profiles are only going to get larger over time

Jfer

Actually, nota's suggestion may work, try it out with a handful of users first

Jfer

They will need to log into the computer that they last logged into with the most recent local profile. You may still need to make each separate user's folder a hidden share, if needed. Why does each user's folder need to be a hidden share?

DSQUERY USER OU=Employees,DC=Example,DC=com | DSMOD USER PROFILE 3\\TargetServer\Profiles\$username$3

the script it posted before had character literals changed, follow the example on the link if the one above has the same errors

Jfer

nope, use the code on the link mrroonie

nota, what hidden share?

"All users have their own profile folder called username$ so they are hidden shares" - OP

the use of $username$ is a wildcard condition

sorry for the late response all, i was away from all technology over the weekend. thanks for all the suggestions, i'm just about to try nota...s and i'll get back to you

notas suggestion didn't work - when changing the profile path in AD to the new server, after clicking apply i get the message 'the \\server2\user$ home folder was not created because the path was not found......The user account has been updated with the new home folder value but you must create the folder manually'.

When first setting up a new users roaming profile i've had to create the user, then create the folder and share it on the file server, and once that has been set up THEN point the profile to the share

to add to the above - i tried logging in with my own user account after pointing the profile to the new server - it logged in  with a local profile but didn't save it back to the new location, ran a search on the new server for my profile name and a couple of files in my home drive (the home drive is mapped to the shared folder which admin has access to - it is not the profile folder, but is very nearly in the same location) - didn't find anything

nota - all profiles were set up as hidden shares when i inherited the domain. in fact, i have something else to try - instead of \\server2\username$ i could set it as \\server2\users\username$, so creating a 'users' folder on the new server and see if Windows dumps the profile in there

jfer - all users will be logged off when i do this, i have scheduled the big switch for the weekend of the 18th & 19 July, so my users have plenty of notice that they are not to come in that weekend. Woohoo - a lovely summers weekend and i'm stuck in the office!

>>instead of \\server2\username$ i could set it as \\server2\users\username$, so creating a 'users' folder on the new server and see if Windows dumps the profile in there  << didn't work either. it created a folder called 'username$' but it was empty, i even took ownership of it to see if the data was hidden but it weren't. didn't recreate the share either

jfer - would the dsquery work for sub OU's?  i have an OU called 'Staff' and then underneath there are several OU's (admin, IT, etc etc just to keep it organised)

I was able to successfully "move" a user profile to another volume on the same server by changing the profile path, but the office I'm at only has a single server. I will test this at a multi-server site this afternoon or tomorrow morning.

Is server2 a member server or is it a DC with a different domain?

Have you tried the following command:
Xcopy C:\UsersProfiles D:\UsersProfiles /e /o /d /h /v /c
Where "D" is the new server location. You may want to create a temporary drive map.

Parameter      Description         
C      The original location of the UsersProfiles.
D      The partition on the disk where you plan to move the UsersProfiles.
/e      Copies all subdirectories, even if they are empty.
/o      Copies file ownership and discretionary access control list (DACL) information.
/d      Copies only those files whose source time is newer than the destination time.
/h      Copies files with hidden and system file attributes. By default, Xcopy does not copy hidden or system files.
/v      Verifies each new file.
/c      Ignores errors

xcopy /? for help

server2 is a member server on the same domain. i have not tried xcopy yet - is that in the resource toolkit?

robocopy keeps the permissions but does not keep the share

what do you mean the share?

as long as you move the information, it should preserve ntfs and share permissions

the folder needs to be shared for active directory to see the profile folder, i did try to redirect a users profiole to the new server after running robocopy but AD moaned that it couldn't find the share

ok, did you place the

\\TargetServer\Profiles\$username$ as the profile direction in the users profile

the reason it wont see it is because "dollar-sign"username"dollarsign" is a wildacard, and it will apply any username currently loaded into the profile path

trust me, copy the profile over to the new one, and place the string

\\TargetServer\Profiles\$username$ in the path, it should work

aaah - no i didn't yet, robocopy is still running, only on users beginning with 'L' at the moment. i'll try that now

just got the same warning as above with the $username$ in place, and i've just tested logging the user in and it says it can't find the profile path. i thought it was % not $?

doesn't work with % instead of $ either. it's definitely because it can't find the shared folder though, the 'local profile' warning when logging on says it can't find the profile folder

i'm out of the office for the rest of the week so i'm not going to be able to try anything until next week now

thanks for your suggestions so far. 1st thing i'll try when i get back will be the xcopy and let you know how i get on. has anyone used rmtshare before? that looks like it can re-share the folders but i've never used it before

hi

did you make the shares based on their usernames?

i could make a script to make shares based of usernames, possibly

Jfer

Ok,

just remember we are doing three different things

1. Move all share and profile data

Either by Robo Copy, or Another Xcopy variant

2. Remap Profiles to Users

-Use the cmd line script i posted previously

DSQUERY USER OU=Employees,DC=Example,DC=com | DSMOD USER -PROFILE ""\\TargetServer\Profiles\$username$""

3. Remap shares

It seems you can use the MS File Server Migration Toolkit for the Shares

http://www.microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/msfsc.mspx

Jfer
also, found on

http://forums.techarena.in/server-migration/366197.htm

that explains how to use robocopy

hi jfer, back in the office today and all hell's broke loose, i've only just had chance to look back on here now. all sharenames are username$. haven't had a chance to look at xcopy yet but the file server migration kit looks promising, although it seems to be migrating from an NT server to 2003. i will test it this afternoon

what do you mean all shares are username$, you mean hidden as pointed out before,

you may have to append $username$&"$" at the end of query if so

Jfer

The tool also work from Win2k3 to Win2k3

hi jfer

so the script would read $username$$   ? or $username$"$"

yes i read that about the tool, i can't run the migration until this weekend though.

i have just tried xcopy but it still gives the user 'cannot find your user profile' when logging in

has anyone used subinacl to copy share permissions? i've been playing with it but i can't get the right syntax

the MS file server migration tool requires Windows server enterprise or datacentre editions - i am running std and storage edition so it won't work :(  so close...

apologies - its the DFS wizard that needs installing on the datacenter or enterprise editions, the migration tool works until i try to add the source server, which gives off

'cannot read file attributes  \\server1\users\username (NOT username$)
System error:2, the system cannot find the file specified

the plot thickens - the error above is pointing to a folder that doesn't exist

further investigation on the migration tool - i have removed all references to the \\server1\users\username in the registry at

HKLM>System>CurrentControlSet>Services>lanmanserver>shares

and

HKLM>System>CurrentControlSet>Services>lanmanserver>shares>security

but i'm still getting the same error as above. does anyone know where else to look for references to these missing shares?

excellent jfer -

DSQUERY USER OU=Employees,DC=Example,DC=com | DSMOD USER -PROFILE ""\\TargetServer\Profiles\$username$"$"

 worked a treat

whats the -profile equivalent for the home folder?

also, would this work for child OU's?

as in

DSQUERY USER OU=Employees,OU=admin,DC=Example,DC=com | DSMOD USER -PROFILE ""\\TargetServer\Profiles\$username$"$"

no it doesn't that way, nor does putting the direct OU=admin

-hmdir is for home dirs

i cannot understand the last two comments,

What the status on the Migration?

Jfer

its going ahead today, just got in the office now - i'm going to reboot the old file server to see if removing those shares from the registry will allow the FSMT to work

to clarify - i have OU's inside OU's, to keep it organised eg

in the OU 'STAFF' i have more OU's underneath 'ADMIN' and 'LIBRARY' etc

don't worry about getting the syntax for OU's inside OU's tho, i have put them all at the root of the AD forest to run the script you advised above

job done - i think it was the way the network was originally set up that stopped my from running the FSMT, xcopy or robocopy properly (inherited network and all that) so i backed up all profiles, restored them to the new server and re-shared all folders manually. Jfer gets the points because that invaluable DSQUERY script saved me spending another 2 days pointing the AD users to the new profiles

get an A as if the network was set up properly in the first place i reckon the FSMT and robocopy would have worked, but that DSQUERY script saved a lot more hours work