Is your domain migration data valid?

For many of us who spend alot of time in customer environments, fear of customer supplied data can cause the sandman to detour around our sleeping quarters more than one night in a row. It is difficult for those of us who practice so much self-reliance to depend on lists given to us by the people we are trying to help. And failure to validate the data they supply us with can lead to results worthy of that fear.

So please, for the sake of your own sleep quota, take a moment to consider checking the data.

I do lots of domain migrations, and of all the things I do in those migrations, merging users is one of the most potentially tedious simply due to the negative and far reaching effects that the mispelling of a login or samAccountName can have. If a user is migrated with the intent of merging with another account in a target domain, the mispelling has an avalanche effect. First, instead of merging the accounts, a "new" account is generated in the target domain containing the login name and sidHistory that was intended to be merged. And finding these duplicates is not as easy as simply running a "Find" on the directory, but may require running a CSVDE export to locate the offending object. Also, running a computer migration after this mistake can create a secondary profile on the workstation instead of merging the source and target domains, causing the user to lose the ability to see the original profile settings and making it appear that the user data is lost, requiring a backout process that CAN lose data if done incorrectly.

So why not make sure it is just done right in the first place? I modified a couple of simple scripts to help validate the data before using it in the ADMT tool.

The first one is a powershell .ps1 script that can verify if a user name submitted for migration exists and is spelled right. It requires one input .txt file with a single column of data, with UserName as the header followed by a login name on each subsequent line, like this:

UserName

user1

user2

user3

The body of the script looks like this:

$struser = import-Csv C:\users\res_migrator\desktop\userinput.csv
foreach($User in $struser)
{
$dom = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$root = $dom.GetDirectoryEntry()
$search = [System.DirectoryServices.DirectorySearcher]$root
$search.Filter = "(samAccountName="+$user.username+")"
$result = $search.FindOne() #start-transcript "c:\mu.txt"

if ($result -ne $null)
{
Out-File -Append c:\userexists.txt -inputObject $user.username
}
else
{
Out-File -Append c:\userdoesnotexist.txt -inputObject $user.username
} 
}

There are two output files, verified names and unverified names. The second one, "userdoesnotexist.txt" will have the unverified user names that be corrected. This script can be run in both the source and target domains.

Once the names are validated, user migrations can be done with a high degree of certainty that a merge will occur and sidHistory copied over, if that option is picked.

But that's not all you get, folks! I have a second .bat script to verify the sidHistory existence on each of the target accounts, using the same list of target login names used in the migration. This one requires an input .txt file, users.txt which requires only a single column of names without a header, i.e.:

user1

user2

user3

and the text of the batch file is:

For /f %%i in (C:\Users.txt) Do (
dsquery * -Filter "(samaccountname=%%i)" -Attr samAccountName ObjectSID sidHistory >> C:\User_Info.txt)

The resulting output file should have a sidHistory attribute listed for each name. If the attribute is missing, search for duplicate accounts by running csvde -f c:\users.csv and searching the resulting .csv for instances of the login name to find potential duplicates.

Hopefully, this will make your migrations go a little smoother. It sure helped me alot on my last one!

Happy Migrating!

"That's no moon...it's a space station".

- Peter Trast, SQL Expert; MCITP DBA, MCITP EA, MCT LinkIn with Peter