ADMT, User Profiles With Unusual Requests

  • Article

I was approached with a rather unusual request. My customer has two Active Directory domains: DOMA and DOMB. The workstations would remain in DOMA, but the users and associated mailboxes would reside in (or be moved to) DOMB. In addition, they needed to convert user profiles so that when the user logs into DOMB, they get their old profile from DOMA.  Once flipped, the agency would use USMT to copy the new profile to a common share and build a new desktop image, returning the recently migrated profile, documents and settings to a new machine.

The solution had to support as rapid a migration as possible, with the fewest possible mistakes (read: automation). I came up with a batch file that reads an input file with two parameters: user name and computer name, separated by a comma. There is one text file per office, so that we can expedite the migration component of the deployment in a fully automated fashion. 

The batch file uses the ADMT from the command line to re-migrate the user to the new domain, disable the old account, transfer SID history, etc. The next command goes after the PC, translating all profiles from the old domain to objects in the new domain. Keep in mind that this particular solution also assumes that all users had been previously migrated to the new domain, but the accounts in that domain were inactive.

@ECHO OFF

FOR /F "tokens=1,2 delims=, " %%a IN (%1) DO CALL :MIG %%a %%b

GOTO END

:MIG

REM *** Move User Account, Disable Source Account in DOMA

ADMT USER /N "%1" /SD:"DOMA" /TD:"DOMB" /MSS:YES /UUR:YES /MGS:YES /DOT:DISABLESOURCE+ENABLETARGET /CO:MERGE /UMO:YES

REM *** Translate all profiles in the user's PC

ADMT SECURITY /N "%2" /SD:"DOMA" /TD:"DOMB" /TOT:Replace /TUP:YES

:END

 

When run, the batch job goes through each line in the supplied text file (supplied as a parameter to the batch job). It tells ADMT to migrate the user (/N) in column one from DOMA to DOMB (/SD and /TD). It disables the source account (/DOT), merges (updates) the results if a duplicate is found (/CO and /UMO) and updates user rights (/UUS), user group membership (/MGS), migrate the SID (/MMS) as SIDHistory.

 

The second command in the loop uses the security translator to update the computer object (second parameter /N) from the source to the target domain, replacing (/TOT) all user profiles only (/TUP). By leaving off additional parameters in ADMT, we can avoid migrating the workstation to the new domain. 

 

A few things I would like to add in the post mortem:

  1. You must ensure that the SP2 Windows Firewalls are disabled during this batch process (or at least opened for ICMP and a file sharing, etc.).
  2. If a user is logged in during the profile translation, they will get their profile translated to the new SID, but at the cost of copying (adding) versus translating (relacing). For very large profiles, this could take considerably more time than necessary.

 UPDATE: I realized recently that /UUS was a typo and should be /UUR.