Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a Windows network running in Workgroup mode with no server. There are around 14 machines on the network so it's clearly time we moved to a SBS 2008 server in domain mode. My question surrounds migration of user accounts to this domain setup.

There are multiple accounts on each machine, and some people have accounts on multiple machines. There are around 15 users in total plus some guest accounts for visitors. All of the machines are running Windows XP Pro but there is one Windows 7 laptop about to be added.

We want to transfer the profiles and not just create new accounts, and we probably want to move all the user's files to user home directories on the new server.

I've seen recommendations of USMT, moveuser.exe and ADMT in the past. I've also seen recommendations of migrating manually by creating the new accounts and then copying profiles across - though the last time I tried this method (around 2004) it was pretty messy. Using any of these methods would presumably mean we need to decide which machine we migrate from.

I'm expecting to be told we're going to need to do this fairly manually given the duplication of accounts across machines, but tips and good methods would be welcomed. How would you handle this situation and what potential issues and problems would you expect?

share|improve this question

3 Answers 3

up vote 0 down vote accepted

While I can't speak to having multiple profiles for the same user across multiple workstations, I will say that if SBS2008 is anything like SBS2003 it should do a pretty nice job of joining the computers to the domain and migrating the individual user profiles to domain profiles. Of course I'm talking about a scenario where there's one primary user per workstation, not multiples like you have. IMHO this is one of the strong points of SBS, making a migration from a workgroup to a domain as painless as possible. The "Add User Wizard" does a fairly nice job of assisting you in creating user and computer accounts based on your current user and computer names. I might suggest that you pick a "primary" user per workstation and use the "Add User Wizard" to "migrate" those users and profiles to the domain, as well as joining their computers to the domain. You can then go in after the migration and pick out the pieces you need from the various user profiles leftover that are scattered across the workstations.

share|improve this answer

It's going to be fairly manual given the duplication of accounts across machines.

>smile<

I'm not a fan of using tools to perform such a migration, beyond bespoke scripts I might write for the particular situation. I feel like manual attention in such a small environment gives the best results. Call me curmudgenly, but I feel like there are lot of human judgement calls that come up in this kind of work. (To be fair, I've also never done such a migration with more than about 20 seats where we cared about saving any of the user's profile data. Migrating a peer-to-peer hell that big sounds nightmarish, if you ask me. Automated tools, if properly tested, tested again, and tested a third time would probably make a larger migration a lot easier, but the number of clients would have to be a sufficiently large value to make all the time in testing pay off.)

I'd start by getting the server computer setup w/ the desired folder redirection, roaming user profiles, etc. Get a test machine joined to the domain and verify that everything acts as you'd expect it. If you need to do any customization of the new user environment get your Group Policy setup to do so. An ideal situation is such that a new user's roaming user profile doesn't require any of that "an Administrator has to logon the first time and setup things in the registry" silliness. I "break" SBS 2008 and provision redirected folders manually because I think the default method is silly. This has the advantage of giving you folders to put the user's documents, etc, into before they've ever logged-on.

If you can throw away the individual users' registries you'll have the cleanest migration. (Crappy apps are notorious for storing absolute paths in the user's registry and having to do mass search-and-replace across registries is no fun.)

If you can't get away with throwing out their registries then you'll want to either get cozy with USMT or, use the GUI to copy the local profiles to the domain profiles, or manually hack the permissions stored in the NTUSER.DAT. Personally, I'd throw out the registries, since they're likely gunked-up with absolute paths and such hooey anyway.

Assuming that you don't have file version conflicts to worry about between the various machines I'd just pile all of each user's files (Documents, Favorites, perhaps Cookies, maybe AppData if I felt like there was something useful there) into their newly-created roaming profile / redirected folders on the server computer and move a copy of the locally-stored profile to some offline media for safekeeping (and to prevent them from falling back to the local profile w/o telling you and creating an even bigger mess).

share|improve this answer

I'd strongly recommend using folder redirection rather than roaming profiles if users are going to be going windows 7<->windows xp, as they don't roam between each other at all, also you are going to have an upgrade soon anyways, and then they'll lose their settings that aren't migrated regardless.

If you insist on using roaming profiles, use USMT to migrate the local user profiles to network user profiles on the machines, setup the profiles to be roaming, point them to blank directories, and IIRC when the user logs out of the machines it will automatically copy up the profile, so be very careful where the user logs into (well out of).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.