Learn about Windows PowerShell
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?
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 firstname.lastname@example.org, 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
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 email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
admin life can be really easy, if you have the right tools in place!
The AD Module is cool and should be admin's best friend, I suppose :-)
But, for moving around a single computer, I have to admit, that using the graphical consoel interface is not the worst idea, ... if you are a GUI guy ...
The same code can be extended to move multiple computer from different locations to one target OU. You may want to refer to techibee.com/.../1383 for examples...
@K_Schulte: It's more a matter of mass operation or repeating same operation over and over again. It comes a time where manual administration just can't stand.
I currently use an automated script (every minute) that fetch every computers joined in the "Computers" OU and then move them according to their name. It also join them in specific groups based on the same pattern. I couldn't do this by hand. Beside the speed consideration, you must think of the "human error" factor. It's pretty easy to slip and drag an object into the wrong OU.
I've been a GUI guy for a long time. But now that I have discover Powershell administration, I use the GUI lesser and lesser each day.
The easies way to target a specific OU is to change the default computer container to the OU you want the computers to be placed in. Now all joins will automatincally place the computers in that OU unless specified otherwise. Th problem with the defaulkt conntainer is that we cannot add policy to a container that is not an OU.
Domain Controllers will always end in in the DC container and should never be moved from there.
It's exactly you did that I need at my job. I'd like to have a copy of your script to adapt to my need. Please, if you could, send me a copy of script to firstname.lastname@example.org. Thanks a lot!
Great information, thanks! Is this method also supported for moving computers between Domains? We have an added "pain point", in that our target domain is Windows 2012 R2, and it won't let a computer join if an SPN with the same name already exists in
the Forest. Therefore, we either have to delete the SPN or the computer account before migration. This heavily impacts the automisation of the migration process, because of course, when the SPNs or the Computer account no longer exist, then you can't do PowerShell
remoting to the computer, or even use SCCM to deploy a script!