Problem solve Get help with specific problems with your technologies, process and projects.

Active Directory's inner workings influence backups and restores

Expert Laura E. Hunter reviews some of the inner workings of Active Directory, which directly impact the AD backup and restore process.

We'll end this short month by talking about a topic that every AD administrator should know about in great detail: Active Directory backups and restores. We're all aware of the importance of performing regular System State backups of our domain controllers by now, so in this article we'll go over some of the inner workings of Active Directory that you may not be aware of, which have a direct impact on the AD backup and restore process.

Tombstone process

The first concept we'll discuss is what happens when you delete an object within Active Directory. When this happens, the object isn't deleted outright but is converted into a tombstone. The reason for this is the multi-master nature of AD replication. Let's say that we have two domain controllers in a single domain: DC1 and DC2. Let's say that you deleted a user object called jsmith on DC1, and DC1 simply deleted the object outright without creating a tombstone. When DC1 replicated with DC2, it would have no record of the jsmith user since it had been deleted outright, and DC2 would have no real way of knowing what to do with its own copy of jsmith.

Instead, Active Directory tombstones any deleted object, which means it renames the object and moves it to a hidden "Deleted Objects" container. (To save disk space on your domain controllers, a tombstoned object also has most of its attributes cleared when it is moved to this Deleted Objects container.) This way, when an object is deleted on DC1, DC2 will tombstone its own copy of that object the next time replication occurs.

So, what does the tombstone process have to do with Active Directory backups and restores? Each Active Directory forest has a tombstone lifetime that specifies how long deleted objects will remain in a tombstoned state before they are deleted from the AD database altogether. In Windows 2000 and Windows Server 2003, this value defaults to 60 days, while an AD forest that was created from scratch on a 2003 SP1 server will have a default tombstone lifetime of 180 days. (If you upgrade a 2003 domain controller to Service Pack 1, the value will remain at 60 days unless you manually change it.) To avoid data inconsistency, Windows 2000 and Windows Server 2003 will not allow a backup image that is older than the tombstone lifetime to be restored into Active Directory. This means that, by default, only System State backups that were taken more recently than your forest's tombstone lifetime are usable for disaster recovery.

Trusted domain objects

Things become a shade more complicated when you are restoring computer objects or trust relationships, as these objects have their own timelines to consider. Both computer accounts and the trusted domain objects (TDOs) associated with trust relationships have passwords associated with them; and these passwords are maintained by Active Directory and change on a regular basis. Computer accounts change their passwords every 30 days by default; trust passwords change every seven days, but AD maintains the current password along with the next-most-recent one. That, effectively, gives you a 14-day window in which a given trust password would be considered valid.

If you perform a non-authoritative restore of a computer account or a TDO, the correct password information will be replicated from the other DCs in your environment and this becomes a non-issue. But if you perform an authoritative restore of a computer account or a TDO from a backup that is older than either of these time windows, the password information will be out-of-sync. The computer account will need to be reset or the trust relationship will need to be re-created.


What we've discussed in this article covers only a few of the intricacies of Active Directory that can affect your backup and restore processes. It should be clear now (if it wasn't before you began reading this) that any backup process needs to be tested, tested and tested again so you'll know you can restore your data when you need it. Your Active Directory domain controllers represent the life's blood of your network; it's crucial that you have a plan in place to restore them if something goes wrong. And verifying your ability to do so in the event of an emergency is even more critical.

Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania, where she provides network planning, implementation and troubleshooting services for business units and schools within the university. Hunter is a two-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing). You can contact her at
More information from

Dig Deeper on Enterprise infrastructure management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.