Accidental deletions can happen in Active Directory in many ways. An administrator can end up deleting a single user object unintentionally or fat finger an entire tree of OUs. A rogue script could end up deleting multiple objects at multiple locations in the AD hierarchy. In Active Directory, when deleted objects are moved to the deleted objects container, they lose their hierarchy (because the DN is mangled to ensure uniqueness).Once accidental deletions happen it's important to analyze the impact carefully, before devising a restore strategy. Things which are required to analyze the accidental deletion are
In the absence of a good GUI for inspecting the recycle bin contents, here's a script that can inspect the contents of your deleted objects container, and give you info on the 3 categorizations above.The script reads the deleted objects container, to construct a hierarchy of all deleted containers (organizational units and containers). Further it reads the replication metadata of these containers to ascertain when and where the object was deleted.See in the figure below. 5 trees of OUs have been deleted. 4 of those trees were under the domain NC and one was under the users container. For each deleted OU, the script shows accurate when deleted (not the value of whenChanged attribute) and where the deletion happened.I can now Pipeline the output of this command to Where-Object and filter out the view per criteria of my choosing - per where deleted and/or when deleted
I can also sort the output of the command on WhenDeleted - it does mess up the tree view though …
Tree RestorationRestoring deleted trees isn't as easy as single object restores. When objects are deleted they are moved to a flat hierarchy in the Deleted Objects Container. The RDN of the object is mangled with its GUID and so a deleted tree loses its hierarchy. The Restore-ADTree script makes it easier to restore an entire tree. You can pass to the script the DN or the GUID of the root of the tree and it would restore all objects under that root recursively. You can use Restore-ADTree on deleted OUs if *all* the deleted children of that OU (presently residing in the deleted objects container) should be restored. When used with the -LeafObjectInfo parameter, this script (Get-ADDeletedContainers) also shows info about the subordinates of each container. The 'subordinates' field shows the number of deleted objects which are immediate subordinates of the deleted OU, and the maximum gap of time between the when deleted time of the subordinates. So, if an fresh OU had 5 user objects, one was deleted 3 days back (a valid deletion) and today the OU and 4 of its children got deleted accidently - the subordinates field of the OU would show 5 (3.00:00:00).
LeafObjectsInfo option will take longer to execute. This option will help you analyze whether or not to use the Restore-ADTree script on deleted OUs. If the subordinate time of an OU is more than a few minutes - you should analyze if all the deleted subordinates are candidates for restore or not.So, before using Restore-ADObject or Restore-ADTree or even if you are planning an auth restore (if recycle bin feature isn't available) - you can use this script to better view and analyze the contents of your deleted objects container better.Usage: Map an AD PowerShell drive to your AD or cd into the default AD: drive and use the script per the following samples. RecycleBin feature needn't be turned on for this script to work
ps: Protect your OUs against accidental deletion to avoid future accidental deletions. To learn how - search for the phrase "Protect an Organizational Unit from Accidental Deletion"enjoy!Dushyant GillProgram Manager, Directory Services