Why should you not restore a DC that was backed up 6 months ago?
As I am learning Active Directory Domain Services I came across this question in one of the blogs but I was unable to find a detailed answer. So please can anybody explain this concept to me.
There is a thing called tombstone lifetime in Active Directory. When you delete an object in Active Directory it is not immediately gone, it is converted to a tombstone and this information is replicated to the other DCs. When the tombstone lifetime is reached the object will be purged. If you restore prior to a state before the deletion and the tomsbtone is not replicated to the restored DC before it expires, the object will remain present in your restored DC but not in the other DCs. Now you have inconsistent data. Default tomsbtone lifetime for Server 2008 and onwards is 180 days (= 6 months).
The reason you cannot restore an object older than 6 months is because of 2 elements in AD. Tombstone Lifetime, and the object's Relative Identifier, or "RID".
RIDs are basically a sequential number, handed out by the "RID Master" FSMO role holder to every DC in the domain in "pools" of 500. RIDs become the last octet of an objects Security Identifier, or "SID" and SIDs are used for permissions to NTFS files, Applications, etc. So, the object SID is a key element in granting access to resources. Because of their security sensitive nature, the value of the RID for each object must be unique. As such, RIDs cannot be assigned by the admin who created the object. Microsoft uses the RID master to keep tight control over those RIDs. Each DC uses their "pool" of RIDS sequentially, and so, when AD objects are created, the RIDs are assigned in a semi-sequential order.
...and this is very important to understand: YOU cannot decide which RID your new user or group, etc. will get. And, for obvious security reasons, you cannot change the RID/SID value of an object. Allowing an admin to set this value would be a BIG security violation on how Permissions work in the entire AD infrastructure.
Enter Tombstone Lifetime (aka "TSL"): Microsoft didn't design this so that you can restore objects... they designed TSL so that every DC in the domain would be updated about the deleted state of an object, even if that DC was offline for an extended period of time. 60 days wasn't cutting it, so in Windows Server 2003 SP2, they changed to 180. So, when you delete an object, it isn't actually purged from the Directory until TSL is reached. Instead, the object is moved into the Deleted Objects container, and all but the essential attribute values are stripped from it. The SID is one of those "essential" attributes that is kept.
If you have the AD Recycle Bin enabled, things are a bit different: The object still moves into the Deleted Objects container, but all its attributes are kept (nothing is stripped). It stays this way for 180 days in a "Deleted" state, and then it changes to a "Recycled" state, which is just like the original Tombstone state (i.e. most attribute values are stripped from the object). When you look in the AD recycle bin, "Deleted" objects will show, but "Recycled" objects are there too, they're just hidden. So, "Recycled" = "Tombstone", and that 180 days in the "Recycled" state = the original 180 days in a "Tombstone" state, better known as "Tombstone Lifetime, or "TSL".
(Note: If you have the AD Recycle Bin enabled, Microsoft does not recommend restoring objects that have reached a "Recycled" state... but I've done it, and it works. I think they don't recommend this because of how tedious it was to restore objects before the AD Recycle Bin)
Still with me? Good! :) So, this whole time of "Deleted" "Recycled" or (original) "Tombstone" state, the object can be restored, because the RID (SID) is still on the tombstone object. With the AD Recycle Bin you can simply Restore an object, and you don't need a backup at all, because all its attributes are there. If the object is a Tombstone (or "Recycled") you'll need a backup to restore all the attributes. But after Tombstone Lifetime, a Garbage Collection process purges the object from the directory completely. Garbage Collection is an internal process that runs on each DC every 12 hours. Now the RID doesn't exist anymore in the Directory, and so even if you have the object in a backup, Microsoft will not allow you to write it back in, because YOU CANNOT ASSIGN a RID value to an object.
So, in summary:
I do hope this helps. If so, please give me some credit! :)
Not only deleted objects.
Let us assume for a while that some servers have been configured IIS, Certificate server (PKI), policies have been applied on OU, delegation has been given to some users, Authentication has been done on some AD users like VPN access, etc.
All these changes will be replaced with old Active Directory. This action is not acceptable at all.
