Category Archives: 12695

Deleting AD Users with PowerShell – Why is a user not a leaf object?

I’ve been re-writing some automated processes around user account lifecycle recently, making use of the Active Directory PowerShell module on Windows Server 2012. Most recently this involved removing a large number of expired user accounts. On the first attempt of trying to remove the user objects I was receiving this error for a number of them, seemingly at random:

Remove-ADObject : The directory service can perform the requested operation only on a leaf object

So why would a user object in AD not be a leaf object? It turns out that when a user connects a device to Exchange with EAS, there’s an AD object created for that device inside the user object and that is what is stopping the user being a leaf object.

You might search for this and find advice on using Remove-ActiveSyncDevice before you remove the user. The trouble with that is that if you’ve got multiple versions of Exchange running in your org, then you might find that you can’t remove the ActiveSyncDevice for all your users with the same method.

It doesn’t matter anyway because the point is that the user isn’t a leaf; it has turned into a container, so what do you need to do to delete a container? Simply do a recursive remove. In the case of what I’ve been doing, this does the job:

$30daysago = (get-date).AddDays(-30)
Get-ADUser -filter {accountexpirationdate -lt $30daysago} | Remove-ADObject -Recursive

Locating AD Computer Objects with PowerShell

Yesterday I was asked how you can find the locations of a list of computer objects in the Active Directory. Not an issue if all of your computers are in Computers, but we’ve got a structure of OUs that would put any ant colony to shame, so it’s a valid question.

My answer was as follows:

Put your list of machines in a file (c:\temp\machine.txt – one computer name per line) and depending on where you’re going to run this it’s a bit different. If you were on a Server 2008 R2 server which has the Active Directory cmdlets, then you need to do:

Get-Content c:\temp\machine.txt | Foreach-Object{
Get-ADComputer $_
} | Select-Object name,@{
} | Format-Table -AutoSize

If not, I would suggest installing the AD cmdlets from Quest ( and doing this:

Get-Content c:\temp\machine.txt | Foreach-Object{
Get-QADComputer $_
} | Select-Object name,parentcontainer | Format-Table –AutoSize

I’m just outputting to a table because I wasn’t told how the output was going to be used. You could use Export-Csv instead to pop it in a file. I should also point out that each of those examples works as a single line of code. I’ve just put it on different rows to stop my blog wrapping it in a confusing place – they’re actually pretty easy to read as a single line.

Now those are the ways that I would do it, but if you have to do something without the Microsoft or Quest AD cmdlets (if your environment is really locked down), all is not lost. This should work anywhere in your domain you can run PowerShell:

$ds = New-Object DirectoryServices.DirectorySearcher
Get-Content c:\temp\machine.txt | Foreach-Object{
$ds.FindOne() | Select-Object path

Pre-staging Computers in Active Directory for WDS with PowerShell and Quest AD cmdlets

One of the most common issues when buidling computers with Windows Deployment Services (WDS, and RIS before that) are typos in the GUIDs used to net-boot the PCs. When you’re entering them by hand as you pre-stage the computer objects in Active Directory it’s very easy to make mistakes, especially when you’re entering a lot of them. It’s also extremely time consuming if you have to boot each machine to the point of PXE displaying the MAC and GUID – that’s why the smart move is to request that information from the supplier, preferably before they deliver the machines.

Anyone who has pre-staged a computer object before will be aware of the jiggery-pokery that goes on with switching round the first half of the GUID, so that when you view it later in ADUC, you see something significantly different to what you typed in. It appear that this conversion is done by the GUI when you create the object, so when you’re adding them programatically, you need to change the format yourself.

Microsoft published a VBScript function to reformat the GUIDs so they could be added to AD by a script, but I haven’t seen similar in PowerShell, so here it is:

function flip-guid ([string]$g) {
    $g = $g.replace(“-“,””).replace(” “,””)
    -join $g.substring(0,16).tochararray()[6,7,4,5,2,3,0,1,10,11,8,9,14,15,12,13] + $g.substring(16,16)

The function takes the GUID as a string and first removes any dashes or spaces (since I’ve received them from suppliers with both at different times). Next it converts the first half into an array of characters, selects them back in the new order and uses the join operator to make them back into a string, to which it concatenates the second half, unchanged from the original. As with most things in PowerShell it could be reduced down to a single line, or expanded further to enhance readability.

So, given the ability now to change the format, I use Quest’s AD cmdlets (if you haven’t come across these before, take a look now!) to create the computer objects. Assuming that you have a CSV file containing the new PC’s name and GUID, just do this…

Import-Csv newpcs.csv | foreach {
   New-QADComputer $ -ParentContainer “SomeOU” -ObjectAttributes @{netbootguid = ([guid](flip-guid $_.guid)).ToByteArray()}

That’ll leave you with a load of new computer objects ready for WDS. :-)

NB. It’s likely that the code snippets above have been wrapped to fit the page layout. In the function there are only two lines – everything from “-join” to the end is the same line. In the foreach scriptblock that’s just a single line.

Windows Server User Group

If I lived in the South East of England, I would’ve been going along to meetings of both the Active Directory User Group and the Windows Server Team. For those of you who do live an easily commutable distance from London, you might be interested to hear that these two groups have merged and now exist as the Windows Server User Group (WSUG).

The site is a little bit basic at the moment, but there are online forums there covering a range of Active Directory and other Windows Server topics, and knowing Mark Parris and Mark Wilson who are running the group, there’ll be lots of good things to come. Even if you wouldn’t find it easy to get to the group’s meetings, if you work with these technologies, it may be a site you’ll want to check out.