Link to home
Start Free TrialLog in
Avatar of FFCIT
FFCIT

asked on

What is the best way to convert workstations/users with roaming profiles from a Samba domain to an AD domain

We are converting 200+ users from a Samba 3.5.6 domain to AD running on Windows 2012.  So far, it has been a spotty process, with issues pulling group machine and user policies, multiple re-boots, corrupted roaming profiles, etc.

The steps we are currently taking are:
   * Copy user's favorites and local files to a network directory
   * Log into PC (Win 7) as local Admin, and create new DNS entries for AD
   * Set the domain to WORKGROUP, restart, and join PC to the AD domain (FOG.Local)
   * On the AD server, move the newly joined machine to the OU that gets policy, run gpupdate and restart the PC
   * Log into the PC as Domain Admin (this is another spot where there are often problems - sometimes it take 3 or 4 restarts/gpupdate before the Domain Admin password is pushed from policy)
   * Log in as user (can take up to 15 minutes to build a profile, which is a roaming profile stored on a share created via GP)
   * Restore favorites and local files from network, and user is good to go

Once the conversion is done, the user doesn't have any trouble logging into FOG.Local, but we have a ton of users, and it can take an hour or more to convert one user machine, so to convert everyone to AD will take months.  It seems like there should be a much more streamlined process (or even a utility?) to make this go faster.  Are we doing something wrong or missing a step?
ASKER CERTIFIED SOLUTION
Avatar of Patrick Bogers
Patrick Bogers
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
* Log into the PC as Domain Admin (this is another spot where there are often problems - sometimes it take 3 or 4 restarts/gpupdate before the Domain Admin password is pushed from policy)
Do you mean local admin user's password?  You don't need to sync the DA password on the workstation.

* Log in as user (can take up to 15 minutes to build a profile, which is a roaming profile stored on a share created via GP)
This tells me there's something wrong.  Seriously 15 mins to build a new profile when the user first logs in?  What speed is your network connection?  Is your profile server using local storage?
Avatar of FFCIT
FFCIT

ASKER

We've already created the users in AD (they are all OWA users).  Didn't realize there was a migration tool for AD - we'll look into it.

Yes, we are assigning the local Admin password via policy (not the DA password - I mis-spoke)
Network connections are all fast ethernet or GB, and I believe the profiles are being stored on a SAN, but we don't have any other network performance issues.

I am going to look at the Resultant Set of Policy for a test workstation - I get the sense that there is something wrong with the machine policy that is causing an issue.
Avatar of FFCIT

ASKER

Didn't realize the ADMT could be applied to non-AD domains.  We'll look into this as a solution, but it apparently will only run on Server 2008, so we'll have to weigh the benefits of using the tool, vs. just hammering away a user at a time.

Thanks for the comments.