Moving a Computer to different OUs through using PowerShell scripts

NOTE: You can find the new methodology and code in my later post located here. 

I know there have been a lot of blogs out here showing how to move a computer to an OU, but I have taken a different approach. This is a suitable process for a small to mid-size company that doesn't have a lot of OUs to move machines to during a build. If it is a company the size of HCA, Dell, GM, etc., this isn't a good process because they likely have hundreds of OUs and you would be creating hundreds of PowerShell scripts. The way this process works is that the PowerShell script does not read anything from MDT or SCCM. It is executed, but does the move process on the system and not through MDT or SCCM.

The first thing to do is to get a drop-down window for the organization unit prompt under the join domain portion of the MDT setup process. Andrew provides two different ways of doing this. I ended up using the first one by applying the settings to the customsettings.ini file. When populating this field, it is going to be for informational purposes only. The field itself does not move a system to the new, selected OU.

The next thing to do is to create a separate PowerShell script for each OU you want to move a machine to. This is a straightforward process. The script below is what I wrote and use. All you have to do is to change the $NewOU variable to whatever OU you desire.

 Set-Variable -Name CurrentOU -Scope Global -Force  
 Set-Variable -Name NewOU -Scope Global -Force  
   
 cls  
 Import-Module activedirectory  
 [string]$NewOU = "OU=BNA, OU=Computers, OU=Front Office, DC=ACME, DC=COM"  
 $CurrentOU = get-adcomputer $env:computername  
 Write-Host "Computer Name:"$env:computername  
 Write-Host "Current OU:"$CurrentOU  
 Write-Host "Target OU:"$NewOU  
 Move-ADObject -identity $CurrentOU -TargetPath $NewOU  
 $CurrentOU = get-adcomputer $env:computername  
 Write-Host "New OU:"$CurrentOU  
   

You can download this script from my GitHub site located here.

This script does require that remote server administration toolkit is installed and the AD PowerShell feature is enabled. That is what the import-module activedirectory requires. If your security is setup correctly, users will not be able to see or do anything even if they go in and enable other features in RSAT. The list below are the commands for enabling the AD PowerShell on the machines. This really comes in handy for other uses. I am currently deploying a huge upgrade package that requires users be moved to new OUs once the package is installed. RSAT has given me that capability.

 dism.exe /online /enable-feature /featurename:RemoteServerAdministrationTools  
 dism.exe /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles  
 dism.exe /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles-AD  
 dism.exe /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles-AD-Powershell  
   

The next step is to create the MDT or SCCM Applications. The way to do this is to go in and create an application for each OU to execute the powershell script associated with that OU. The catch is that the powershell script will not move the machine under the credentials of MDT because it uses the system account for installing applications and it will not have access to AD. To get around this, you will need to use psexec to run the powershell script as a different user. Here is the command line I use to execute the scripts from an MDT Application:

 \\NetworkLocationOfPsexec\psexec \\%computername% -accepteula -u domain\username -p Password cmd.exe /c "echo . | powershell.exe -executionpolicy bypass -file \\NetworkLocationOfPowerShellScript\MoveOU_AUS.ps1"  
   

The final step is to put the applications into the task sequence. I created a folder and put an individual application task for each OU and associated the matching application with it. Here is an example:

You will need to filter each task sequence by creating a conditional statement in the options of the task sequence application. You will create a Task sequence variable, use MachineObjectOU, and associate with the matching OU in the customsettings.ini file. This will limit them to run only if the selected OU in the Windows Deployment Wizard matches.

That is everything you need to do to get this process to work.