Delete Leaf Objects from Active Directory User Object

The Story

The past days I had a colleague of mine come to me with a user migration problem. He wanted to migrate a user between two child domains in an AD forest. For this most of the time you use Microsoft’s ADMT (Active Directory Migration Tool). He went through the whole migration wizard and had the migration fail with an error message like this:

2014-03-17 12:47:27 ERR2:7422 Failed to move source object ‘CN=Joey’. hr=0x8007208c The operation cannot be performed because child objects exist. This operation can only be performed on a leaf object.

That was strange, I was expecting the user object to be a leaf object itself, not to contain leaf objects?! Then I remembered we are in 2014, we also use Microsoft Exchange and use ActiveSync on Mobile devices. In case you didn’t know, when you configure ActiveSync on your phone a special object is created under your User Object in Active Directory. This object is of type “msExchActiveSyncDevices” and list each of the mobile phones where you have configured Active Sync. I used adsiedit.msc to confirm that the leaf objects were indeed these msExchActiveSyncDevices objects.

So that explains what the leaf objects were, and how they got there. Now since the user is being migrated across domains, it really doesn’t matter whether those leaf AS objects are there or not, because after USMT users have to reconfigure their devices anyway, so they’re “safe to delete”. To fix this you can either use ADSIEDIT to locate the leaf objects and delete them or use Exchange Shell to delete the AD devices….or use Powershell to delete them from the user object just like you would with ADSIEDIT, which is what i want to share now.

The Script

I built this script on a Windows 8.1 computer with Powershell 4.0 and RSAT tools for Windows 2012 R2 installed. Also the AD environment is Windows 2008 R2 FFL and only Windows 2008 R2 DCs run on it. I didn’t check if this runs on less than this configuration, so do report back if this is not working on older combinations of RSAT + OS + AD, though i’m pretty sure you need at least one 2008 R2 DC in the user’s source domain, otherwise the powershell cmdlets won’t wor. You can download this script from the link: Delete-AS-ChildItems.

The script takes only one parameter the SamAccountName of the user with leaf objects. From then on it will show you the leaf objects it wants to delete, and then actually delete them, if not canceled.

Learning Points

I’ve made the script “autonomous”, in the sense that it will automatically discover the closest DC running AD Web Services, and query it for the SamaccountName. This snippet accomplishes that.

$LocalSite = (Get-ADDomainController -Discover).Site
$NewTargetGC = Get-ADDomainController -Discover -Service ADWS -SiteName $LocalSite
IF (!$NewTargetGC)
    { $NewTargetGC = Get-ADDomainController -Discover -Service ADWS -NextClosestSite }
$NewTargetGCHostName = $NewTargetGC.HostName
$LocalGC = "$NewTargetGCHostName" + ":3268"

Once we have this information, we query the GC for the SamAccountName and Domain Information. We need the domain to also discover the closest DC for that domain, and get the list of leaf objects (Lines 14-26)You will want to do this for 2 reasons: first because the GC partition doesn’t contain all the information you want (the child object information) and second, you can’t write to the GC partition, so you have to find your closest respective DC anyway.

The “trick” with this script is to use Get-ADObject with a search base of the User’s DN on a DC in the User’s Domain and look for the respective msExchActiveSyncDevices object type like below:

$UserOjbActSync = Get-ADObject -SearchBase $UserObj.DistinguishedName -filter { ObjectClass -like 'msExchActiveSyncDevices'} -Server $UserobjDC -ErrorAction:SilentlyContinue

Now to actually fix the problem, we run this command, that deletes all the child items, and whatever may be inside them.

Remove-ADObject $UserOjbActSync -Server $UserobjDC -Recursive:$true -Confirm:$false -Verbose -Debug

That about wraps this up. Just wait for replication to occur on your domain and you should e good to finish the migration. As always, use with caution, this does delete things. If you found this useful share it around 🙂

Active Directory Domain Controller Backups – Part 1

I decided to write down for posterity and my own forgetfulness the workflow I developed for backing up domain controllers running Windows 2008 R2. I didn’t really reinvent the wheel, I merely adapted and put together some disparate pieces of code I found on the Internet.

Backup Overview

I guess this is the time we should ask ourselves the 5 Ws:

  • Who is being backed up?
  • What to backup?
  • Why do we need the backups?
  • When will backups run?
  • Where will backups be stored?

Who?

Our backup sources must be at least 2 domain controllers / domain. Why 2? Well because 2 is better than 1, in the remote case one of the backups is not working properly you are in trouble, having 2 backups, at least diminishes this chance. Also I would advice that your backup targets are, if possible, among the FSMO roles holders in the domain, so in case of a forest/domain recovery to avoid doing FSMO role seizing. Suppose you are managing a single forest, multiple child domain infrastructure. The forest root domain DCs that make the best candidate for backup are:

  • PDC Emulator
  • RID Master
  • Schema Master

I’m not saying the Domain Naming Master and Infrastructure master are not important, only that in a Forest/Domain Recovery Scenario, you must make sure you have the roles above working properly, and not have to go through the trouble of seizing them from dead DCs. Domain Naming Master is useful for setting up new domains – not something you do in a recovery, and Infrastructure masters are not so much used, if all your DCs are Global Catalogs, a common situation in my opinion  nowadays). On domain level I would pick servers that are PDCs (Primary Domain Controllers) and RID Master Servers, for mostly the same reasons above.

What?

  • System State (at least), Critical Volume Recommended
  • List of objects (distinguishedNames) – useful for restoring data
  • GPOs (contents)
  • GPO-Links

Why?

Well, the “System State” is an obvious choice, since that is the entire operating system, and in the case of DCs, the Active Directory files (database, logs, etc). Keep in mind though, that your restore options, for a supported setup are limited, as explained here.

The “List of Objects ” (object name and DN) is needed, because in some restore cases (e.g.: object restore from accidental deletion) you must provide a DN for the restored object, that is not included in deleted objects information in AD.

The “GPO objects” are backed up for convenience sake (they are included in the “system state backup”). In case we need to restore a GPO from backup, it is more easy to have it backed-up separately, compared to restoring a system state backup, mounting the backup, searching for the files, etc). The GPO links are something special that are not backed-up with the usual GPO backup tools. Also special care must be taken so that GP-links to GPOs outside of the domain where the GPO exists are also backed-up.

When?

In my case I did a backup to network share, which was included in the regular backup policy of the company. So the answer would be: “At a time of low activity on the server, before the regular backup runs over your backup location?”

Where?

The backup destination in my case was a network share in the same subnet and datacenter as my domain controllers. This obviously lowers backup duration and any load on the WAN links. I am fortunate enough to be able to have most of the DCs for my entire forest, with at least 1 member in a single datacenter, where I setup a network share to store the backups.

A word about security here. Take as much care in securing this network share and the OS that hosts it, as you would if it were a very sensitive system. Remember, this is where all of your domain controller backups are stored. Anyone gaining access to this share would be able to mount your AD files, view the content, steal password hashes from the backups, the attack possibilities are quite numerous. If you are setting up this share on a windows machine CHANGE the default security settings to only allow the Domain Administrators and Backup Operators access to it.

Tools and Requirements

To setup the workflow that I will describe you need to have these resources/permissions:

1. Domain Admin over all domains/child domains

2. You should be running Windows 2008 R2 with Powershell installed on your DCs (including AD-Modules)

I will discuss later on about specific requirements for the backup itself, when the time comes.

Resources

Some links and resources helped me build this workflow are below:

A good deep-dive video explaining a lot of the concepts around Domain Controller backups, and restore techniques, presented at TechEd US this year. I picked up form here what needs to be backed up, and some command for doing the backup.

This Technet gallery script for backing up GPO objects, the stuff there is pretty accurate.

This is it for an introductory post, giving an overview of how we will get the job done. Part 2 will cover the scripts/commands used to achieve this backup.