How to Move a Computer Account From Within Powershell
I’m going to show you how to move a computer account to its new OU in just one line.
Not only that, I don’t even need to know the name of the OU it’s going to be placed in. That piece of information is going to come from a reference computer that’s in the same department. In this case the computer that I’m referencing is actually the older system that the new pc is replacing, so I’m sure it will be the correct OU.
After I add the computer onto the domain it is created in the Computers container. I don’t like the computer container because it’s not an OU and I can’t apply policies directly to it. I don’t even know that I would apply GPO’s there if I could. I probably wouldn’t. But now that I can’t, it makes me furious! Also worth mentioning is I do NOT pre-stage the computer. Why? Two reasons:
Why I Don’t Pre-Stage Computers In My Domain
- Because to pre-stage a computer I would have to know where it goes. I do not know the OU that this computer should go in, so I cannot pre-stage it. At least, I should say that statistically my chances of dropping it into the correct OU by luck alone aren’t great.
- Because I am bad like that. You might be the type that pre-stages computers, but I’m not. Most of the time I am a messy type that uses PowerShell to clean up after my messes; and occasionally I’m a clean type that uses PowerShell to make it appear that I’m messy.
Using the .NET Framework with PowerShell to Work With AD
Microsoft’s PowerShell comes ready to use the .Net framework classes, so it is possible to use the System.DirectoryServices.DirectoryEntry and DirectorySearcher classes. But even with the simplicity of PowerShell, that code starts out looking like this.
Note: The one line version of this is awesome and it’s coming up soon so keep reading
PS C:\Windows\system32> $domain = new-object directoryentry
New-Object : Cannot find type [directoryentry]: make sure the assembly containing this type is loaded.
See? It doesn’t even start out easy. This is gross. Here’s how you can really create the object. If you try this, at least it works, but it’s even more confusing.
PS C:\Windows\system32> $domain = new-object system.directoryservices.directoryentry
PS C:\Windows\system32>
No error. Still, you’re just getting started with finding an Active Directory account. Next, you would have to create a new object of type DirectorySearcher, set filters and then find the account, like this
$domainsearcher.FindOne()
That’s just to get one account, and you’ll still have to go through the steps getting the parent container of the reference account, finding the new account, updating the parent container attribute, then confirm changes.
My Boss Would Love it if I Pre-Staged My Computers in Active Directory
If accessing the .Net framework was all PowerShell could do to help me move an account, I think I would have given up. If PowerShell were limited like this I would have gone back to pre-staging computers with AD Users and Computers, and my boss would have won.
He would say to me “So, you have finally have seen the light. I knew you would. This PowerShell thing does not work, and you have no way to make your messy ways be clean. This is why I tell all of you: keep the Computers OU clean, and pre-stage your computers”.
Here’s a picture of me crying because I’m forced to use Active Directory Users and Computers
My boss loves it when I use this tool. I do not.
Note: I have removed this picture for 2 reasons:
1) You may never see me cry.
2) You may never see me use Active Directory Users and Computers.
A PowerShell Secret Weapon – Quest Activeroles ADManagement
For this little bit of PowerShell goodness, I use the Quest Activeroles Admanagement tools. Microsoft now has cmdlets for working with Active Directory, but I’ve never used them. Microsoft was too slow on this one, and Quest got it done.
I will try the Microsoft variety, because I am a huge Microsoft fanman. But so far, I just keep using the Quest tools because I know them and they’re second nature to me now.
Load the quest.activeroles.admanagement snapin to your PowerShell session. This absolutely does not count towards my one line that I promised you because:
- You could have just as easily gotten into a ADManagement Shell, which is placed in your Programs Start Menu when you install the Quest snapin.
- You should already have this added to your profile, so the tools are loaded every time you start a session.
The Command To Script Moving a Computer
Given:
- A computer (“new-pc”) added to the domain, and not prestaged.
- A computer (“old-pc)” already on the domain and in the OU where “new-pc” is supposed to go.
- An OU (“Mystery-OU”) that old-pc is and where new-pc goes. Notice in the one-liner I do not use “Mystery-OU”, because I do not know what OU it is
- A domain (“ilovepowershell.com”) in which new and old computers are organized into units of organization called OU’s.
move-qadobject –identity ‘ilovepowershell.com\new-pc’ –newparentcontainer (get-qadcomputer –service “ilovepowershell.com” old-pc).parentcontainer
Follow ILovePowerShell on Twitter
