Tip

Active Directory's inner workings influence backups and restores

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

Requires Free Membership to View

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.

Summary

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 laurahcomputing@gmail.com.
More information from SearchWinIT.com

This was first published in February 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.