• Author
• Recent Posts

Jeffery Hicks

Jeff Hicks is a long-time Microsoft MVP specializing in PowerShell and automation. He creates PowerShell content for Pluralsight and blogs regularly at https://jdhitsolutions.com/blog. Jeff's latest project is a premium content newsletter at jeffhicks.substack.com Follow him on Twitter as @jeffhicks.

Latest posts by Jeffery Hicks (see all)

• Use PowerShell splatting and PSBoundParameters to pass parameters - Wed, Nov 9 2022
• Using PowerShell with $PSStyle - Mon, Jan 24 2022
• Clean up user profiles with PowerShell - Mon, Jun 9 2014

Moving a single user

Let’s say a user has been transferred to another department. Al Fredo, who had been a senior sales manager in the Government Sales department has been promoted to Assistant VP for Sales. In order for his user account to receive all of the executive perks delivered through Group Policy, you need to move is account to the Executive organizational unit.

Now, you could certainly do this manually via Active Directory Users and Computers once you launched the MMC, navigated or found the account and then move it to the new OU. In PowerShell, I would have had this done before you finished loading the MMC. The solution that I’m going to show you is using the Microsoft Active Directory module which many of you already have. Let me step you through the process. I’ll assume you are running at least PowerShell 3.0 so you don’t have to import the module first.

I always find it easiest in these situations to get the objects in question first assuming you know the user’s samAccountname.

PS C:\> get-aduser afredo

get-aduser

You can see in the user’s distinguished name where his user account currently resides. Now to move the user account. You might try looking for help using Set-ADUser or Move-ADUser. Sadly, the former doesn’t work and you won’t find the latter. So ask PowerShell.

PS C:\> get-command -module ActiveDirectory -verb move

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Cmdlet          Move-ADDirectoryServer                             ActiveDirectory
Cmdlet          Move-ADDirectoryServerOperationMasterRole          ActiveDirectory
Cmdlet          Move-ADObject                                      ActiveDirectory

The cmdlet to use is a more generic Move-ADObject. Looking at help and examples you discover all you really need, is to specify the distinguished name of the target OU.

PS C:\> get-aduser afredo | move-adobject -targetpath "ou=executive,ou=employees,dc=globomantics,dc=local" -whatif
What if: Performing the operation "Move" on target "CN=Al Fredo,OU=Sales,OU=Sales and Marketing,OU=Departments,OU=Employees,DC=GLOBOMANTICS,DC=local".

Yes, the Move-ADObject cmdlet supports –WhatIf so you can verify your syntax before committing. Although this is still a bit to type, and assumes you know the target distinguished name off the top of your head.

Using a nested pipeline you could simplify the expression.

PS C:\> get-aduser afredo | move-adobject -targetpath (Get-ADOrganizationalUnit -filter "name -eq 'executive'")

I omitted –Whatif to implement the move which I can verify by getting the user account again.

PS C:\> get-aduser afredo | select distinguishedname

distinguishedname
-----------------
CN=Al Fredo,OU=Executive,OU=Employees,DC=GLOBOMANTICS,DC=local

The same technique can now be used across multiple user accounts.

Moving many

Let’s say you need to reorganize and move members of the Customer Service department to a new OU. For the sake of my demonstration, like you, the accounts may be scattered.

get-aduser -filter

Using the same technique it is snap to move all of these accounts with a single command.

PS C:\> get-aduser -filter "department -eq 'Customer Service'" | move-adobject -targetpath (Get-ADOrganizationalUnit -filter "name -eq 'Customer Service'")

By the way, if an account is already in the target destination nothing really happens to it. After giving replication a chance to finish I can verify the moves.

PS C:\> get-aduser -filter * -searchbase (Get-ADOrganizationalUnit -filter "name -eq 'Customer Service'") -property Department,City | Select Name,Department,City

get-aduser -filter  -searchbase

Build your own

Another great advantage to learning a management tool like PowerShell, is that once you have a command working, it doesn’t take that much more effort to turn it into a re-usable tool. Even though there is no Move-ADUser command, you can create your own. Here’s my bare bones function that you can start with.

#requires -version 3.0
#requires -module ActiveDirectory

Function Move-ADuser {

[cmdletbinding(SupportsShouldProcess)]
Param(
[Parameter(Position=0,Mandatory=$True,
HelpMessage="Enter a user's samAccountname",
ValueFromPipeline=$True)]
[ValidateNotNullorEmpty()]
[Alias("samaccountname","name")]
[string]$Username,

[Parameter(Position=1,Mandatory=$True,
HelpMessage="Enter the name of an OU")]
[ValidateNotNullorEmpty()]
[string]$TargetOU,

[switch]$Passthru

)
Begin {
 #get the OU
 Write-Verbose "Getting OU $TargetOU"
 $OU = Get-ADOrganizationalUnit -filter "Name -eq '$TargetOU'"

 #define a hash table of parameters to splat to Move-ADObject
 $moveParams=@{
   TargetPath=$OU
   Identity=$Null
 }
 if ($Passthru) {
    $moveParams.Add("Passthru",$True)
 }
}
Process {
 $User = Get-ADUser -identity $username
 $moveParams.Identity=$User
 Write-Verbose "Moving $username to $($OU.Distinguishedname)"

 Move-ADObject @moveParams
}

End {
 Write-Verbose "Finished moving user accounts"
}

} #end function

The function lacks error handling, support for alternate credentials and comment based help. But it is simple now to move either a single account with either of these two approaches

move-aduser afredo Executive
get-aduser afredo | move-aduser -TargetOU Executive

Or many:

get-aduser -filter "department -eq 'Customer Service'" | move-aduser -TargetOU 'Customer Service'

My function even supports –Whatif. I’ll let you take it from here.

Summary

If you are still managing Active Directory accounts manually, you are spending way too much time in the MMC and not enough time enjoying your job. Next time we’ll look at a similar approach to handle group membership.