The Easy Way to Use PowerShell to Move Computer Accounts
Summary: Use the Active Directory module and Windows PowerShell to move computer accounts.
Hey, Scripting Guy! I need to figure out a way to manage computer accounts in Active Directory. We are running Windows Server 2008 R2. I have seen some VBScript scripts to manage computer accounts, but they are rather complicated. In fact, many of the Windows PowerShell scripts that I have seen look the same way. I do not want to install any third-party stuff (due to company security policy). What I want to do immediately is move computers from one OU to another one. Is there an easy way to do this?
—DJ
Hello DJ,
Microsoft Scripting Guy, Ed Wilson, is here. Well, it is a perfect day down here in Charlotte, North Carolina in the United States. In fact, I would say it is days like this that make up for the heat and humidity of the summer down here. Anyway, I am sitting with my laptop on the lanai, sipping a cup of Jasmine Dragon Pearl tea, and checking the email that has been sent to scripter@microsoft.com, and DJ, I ran across your email.
DJ, you are right that some Windows PowerShell scripts to manage computer accounts look amazingly like VBScript scripts that perform the same task. This is because at their heart, they use the same technology. I have written many such scripts myself. There are several advantages to this approach—the first is that they are certain to work and they have no external dependencies. In fact, such scripts work across the broad spectrum of servers. The only dependency is having at least Windows PowerShell 1.0 on the computer. The second advantage is that if one is very familiar with ADSI scripting, from a VBScript or other automation background, the Windows PowerShell version is immediately understandable. That is, there is no learning curve if you already know and understand ADSI.
The two prior advantages aside, if you have the necessary infrastructure (and you do), there is absolutely no reason not to use the cmdlets from the Active Directory module. In fact, by getting familiar with them now, you are putting yourself in a great position to move forward in the future.
Note I have written several blogs that detail working with the Active Directory module.
In addition to being available when you enable the Active Directory Domain Services (AD DS) role on a computer running Windows Server 2008 R2, you can also install the Active Directory Management Service (see Install Active Directory Management Service for Easy PowerShell Access). To use the cmdlets, you can install the Remote Server Admin Tools (RSAT) on your computer running Windows 7, or you can use Windows PowerShell remoting (see What’s up with Active Directory Domain Services Cmdlets?).
By using the Active Directory module, it is super easy to manage computer accounts. If you have the RSAT tools installed, the first thing to do is to import the Active Directory module by using the Import-Module cmdlet. If the RSAT tools are not installed, use Windows PowerShell remoting and create a remote session to a computer that has the Active Directory module. To do this, use the Enter-PSSession cmdlet. This is the option I used in the image that follows.
In the image that follows, I need to move the Win7-c1 computer from the Test Organizational Unit to the Charlotte Organizational Unit.
To do this by using Windows PowerShell and the AD DS cmdlets is relatively easy. I can use the Move-ADObject cmdlet. The Move-ADObject cmdlet uses the Identity parameter to identify the object to move. The Identity parameter accepts either DistinguishedName or ObjectGuid to identify the object to move. While it is possible one might know the actual DistinguishedName of a computer, it is very unlikely that one would know the ObjectGuid. But even knowing the DistinguishedName of an object does not mean it is easy to type. Luckily, the Get-ADComputer does not have these restrictions. It is easy to use the Get-ADComputer cmdlet to retrieve the information needed for Move-ADObject. The following command shows the output from Get-ADComputer.
[dc3]: PS C:\> Get-ADComputer win7-c1
DistinguishedName : CN=WIN7-C1,OU=test,DC=iammred,DC=net
DNSHostName : WIN7-C1.iammred.net
Enabled : True
Name : WIN7-C1
ObjectClass : computer
ObjectGUID : e922119e-377e-4eef-a4db-aff340ac0022
SamAccountName : WIN7-C1$
SID : S-1-5-21-1457956834-3844189528-3541350385-1134
UserPrincipalName :
One way to use the Get-ADComputer cmdlet is to have it retrieve the ObjectGuid for you. This is shown here (keep in mind that this is a single line command, and I have not included any line continuation marks).
Move-ADObject -Identity (Get-ADComputer win7-c1).objectguid -TargetPath ‘ou=charlotte,dc=iammred,dc=net’
It might be easier—and certainly it is easier to understand—to use the pipeline. When using the pipeline to move the computer to another organizational unit, use the Get-ADComputer cmdlet to retrieve the computer object, and then pipel it to the Move-ADObject cmdlet. This command is shown here.
get-adcomputer win7-c1 | Move-ADObject -TargetPath ‘ou=charlotte,dc=iammred,dc=net’
The command and the associated output from the command (there is no output from the command) are shown in the image that follows.
If you do not know the distinguished name of the OU, use the Get-ADOrganizationalUnit cmdlet to find the distinguished name attribute. This technique is shown here.
Note I split the command into two separate commands due to the length of the command. But it would be possible to do this as one really long command by grouping the Get-ADOrganizationalUnit command, and then using dotted notation to retrieve the DistinguishedName attribute.
$target = Get-ADOrganizationalUnit -LDAPFilter “(name=charlotte)”
get-adcomputer win7-c1 | Move-ADObject -TargetPath $target.DistinguishedName
DJ, that is all there is to using the Active Directory module to move computers from one OU to another one. Join me tomorrow when I will talk about more cool Windows PowerShell stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments