{"id":2795,"date":"2013-09-30T00:01:00","date_gmt":"2013-09-30T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2013\/09\/30\/domain-migration-why-we-need-the-script\/"},"modified":"2013-09-30T00:01:00","modified_gmt":"2013-09-30T00:01:00","slug":"domain-migration-why-we-need-the-script","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/domain-migration-why-we-need-the-script\/","title":{"rendered":"Domain Migration: Why We Need the Script"},"content":{"rendered":"

Summary<\/strong>: An anonymous blogger shares a domain migration script.<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. Today’s guest blogger will remain anonymous due to privacy considerations at his company. This does not mean that his knowledge needs to remain undisclosed. Without further ado, here is a really nice guest blog…<\/p>\n

We are a large international organization with many legacy domains. A major business objective this year is to move users, workstations, servers, and applications from these legacy domains into one domain and then collapse the legacy domains. The approach to migrating users, applications, etc. is not your typical “lift and shift” from the legacy domains into the target domain. Rather, the aim is to coexist in the legacy and target domains while the users and applications are migrated to the target domain. Coexistence allows for the continual use of production applications while they are being moved and remediated in the target domain.<\/p>\n

The migration approach entails that each legacy user will have a user account provisioned in the target domain. Each legacy domain user account will be matched with its associated target domain account for purposes of password and data (that is, sIDHistory<\/strong>) synchronization. Microsoft Forefront Identity Manager performs this synchronization. A unique User account attribute contains a value that associates the legacy and target accounts. The primaryTelexNumber<\/strong> user attribute contains the unique value that associated the legacy and target accounts.<\/p>\n

Populating primaryTelexNumber<\/strong> correctly and maintaining a historical record of the changes are key requirements in the process. I developed a Windows PowerShell script that takes a CSV input file of the legacy users by Distinguished Name with the associated IDMGuid, take a before shot of the attribute, update the attribute, take an after shot of the attribute, then write the before and after shots of the attribute to a file and invoke a GridView<\/strong> list after all the changes are complete. This approach leaves us with an audit trail of what was done, which helps in a variety of situations.<\/p>\n

A secondary requirement is an “all-purpose” script to change the value of any Active Directory user attribute without having to consider the use of the Active Directory cmdlets or ADSI. I wanted one mechanism to use to change any attribute, complete with an audit trail.<\/p>\n

Now to the script<\/h2>\n

The script begins with the normal housekeeping as follows. This includes importing the Active Directory module, assigning variables, and removing any PSDrives<\/strong>. The intent of the Get-MyModule<\/strong> function is to load the Active Directory module once and not load it on subsequent runs during the session.<\/p>\n

The variable assignment section requires the specification of the attribute to be modified, the name and path of the input CSV file, the name and path of the output text file, and the array name where the output objects are stored before they are written to the text file.<\/p>\n

The intent of the $OutFile<\/strong> and $FileDT<\/strong> variables is to dynamically construct an output text file at run time so each output file is unique and contains the date and time when it was run. This is very useful in that the results of a specific run are contained in a file named with the date and time when it was run. The $DateTime<\/strong> variable is used in the output file, and it indicates when the attribute was updated.<\/p>\n

Function Get-MyModule<\/strong><\/p>\n

{<\/p>\n

Param([string]$name)<\/p>\n

if(-not(Get-Module -name $name))<\/p>\n

{<\/p>\n

if(Get-Module -ListAvailable |<\/p>\n

Where-Object { $_.name -eq $name })<\/p>\n

{<\/p>\n

Import-Module -Name $name<\/p>\n

} #end if module available then import<\/p>\n

else { $false } #module not available<\/p>\n

} #end if not module<\/p>\n

else { $true } #module already loaded<\/p>\n

} #end function get-MyModule<\/p>\n

 <\/p>\n

 Get-Mymodule -Name “ActiveDirectory”<\/p>\n

 <\/p>\n

$UserAttribute = “primaryTelexNumber”<\/p>\n

$InFilePath   = “C:\\Users\\adm-a99426\\”<\/p>\n

$InFileCSV   = “IDMGuidUsers.csv”<\/p>\n

$OutFilePath  = “C:\\Users\\adm- a99426”<\/p>\n

$OutFile    = “UserAccountMods_$FileDT.txt”<\/p>\n

$FileDT    = get-date -Format MM_dd_y_HHmmsstt<\/p>\n

$DateTime  = get-date -Format MM\/dd\/y-HH:mm:sstt<\/p>\n

$MyArray   = @()<\/p>\n

 <\/p>\n

Remove-Psdrive File -Force -ErrorAction SilentlyContinue<\/p>\n

Next, the New-PSDrive<\/strong> cmdlet is invoked to create a mapping to the file system, and specifically to the output file that is associated with the $OutFilePath<\/strong> variable. This is where the results of the script will be written to.<\/p>\n

New-PSDrive -PSProvider FileSystem -Name File -Root $OutFilePath<\/p>\n

This is required because to work with the file system and files, you have to work within the file system provider; whereas to work with Active Directory and user accounts, you have to work within the Active Directory provider. Because we have the requirement to update Active Directory user account attributes and save the updates to a file, both the FileSystem<\/strong> and ActiveDirectory<\/strong> providers need to be accessed at the right time when working with objects within those providers.<\/p>\n

The following CSV input file provides is a list of user accounts in Distinguished Name format with the new value of the attribute specified in the IDMGuid field. The value of the IDMGuid field will be used to update the attribute as specified in the $UserAttribute<\/strong> variable, which is the primaryTelexNumber<\/strong> attribute.<\/p>\n

Each user account in the input file will have the value of their primaryTelexNumber<\/strong> changed to what is specified in the file in the IDMGuid field. For example, the primaryTelexNumber<\/strong> for user account A62100 will change to 001510230, the primaryTelexNumber<\/strong> for user account A62101 will change to 001510231, and so on.<\/p>\n

\"Image<\/a><\/p>\n

The Import-CSV<\/strong> cmdlet is used to read the IDMGuidUsers.csv file of user accounts with the new value of the attribute, thereby creating an object for each line (or user) in the file. The User<\/strong> property refers to the distinguished name for each user, and the IDMGuid<\/strong> property refers to the value of the primaryTelexNumber<\/strong>. A Foreach<\/strong> loop will process each object in the $Accounts<\/strong> variable. This is illustrated here:<\/p>\n

$Accounts = Import-Csv $InFilePath$InFileCSV<\/p>\n

Foreach ($User in $Accounts) {<\/p>\n

To change the value of the attribute, we have to first map to the Active Directory provider, which is accomplished by using the Set-Location<\/strong> cmdlet.<\/p>\n