The “Oops” Command: Minimizing Object Deletion Damage

A common problem associated with administering Active Directory is the “fatfinger” issue, when an account administrator accidentally deletes an important account, computer, group, or (heaven forbid) an OU. (Of course, YOU would never do this.) Much has been written about how to recover from this accidental object deletion situation. What’s rarely mentioned is how to minimize the damage.

AD changes within a site replicate very quickly (within 15 seconds) between any two domain controllers, so any changes you make have usually spread across most sites within a minute. This means if you delete an object, it’s toast within a site before you can do anything about it. However, the minimum replication interval between sites is 15 minutes (if you don’t have change notification enabled, the topic of an upcoming post). This gives you a little time to keep the deletion from propagating across the domain or forest, thus limiting the damage.

Our old friend REPADMIN provides a way to do this. (REPADMIN can probably solve world hunger, if we could only figure out the correct syntax.) The utility provides a command to disable outbound and inbound replication for a targeted domain controller using the /OPTIONS command:

Most people just put the DC’s name in the DSALIST parameter. However, REPADMIN also has a sophisticated, but little used, ability to target a number of DCs using the DSALIST (see REPADMIN /LISTHELP to learn about all the ways to use DSALIST.) One DSALIST option is SITE: to target a particular site. So, to disable outbound replication for all DCs in the Hub site you simply combine the two commands:

Voila! This will immediately disable inbound and outbound replication for all DCs in the Hub site. I’d save this as a batch file where the only parameter is the site you want this to operate against, call it “oops.cmd” (or something a little more representative of what the offender actually said), and save it in a common location for all admins to know:

It’s non-destructive, and if you can execute it quickly enough, you may even keep the deletion from replicating very far across the site. I would also recommend making your account changes to a specific DC, so you immediately know where the deletion originated from.

To turn replication back on, simply change the “+” to a “-“:

You still need to recover the object, of course, but since the deletion hasn’t propagated across the forest yet, you can perform an authoritative restore of an offsite DC that still has the DC, WITHOUT any restore from backup media. (http://technet.microsoft.com/en-us/library/bb727062.aspx#E03B0AA).

Follow Sean on Twitter: @shorinsean
Subscribe to Sean's Windows IT Pro articles: RSS