Field Notes: Active Directory tombstone lifetime

It’s been a long time since I had to discuss the default values for the Active Directory tombstone lifetime. The value was 60 days for Active Directory in Windows Server 2000 and was changed to 180 days during the Windows Server 2003 Service Pack release cycles.

Considering that most Active Directory deployments are running on Windows Server 2012 R2 or later, we would never consider reviewing the tombstone lifetime, as we expect the value to be set to the default of 180 days. This however is not always the case.


Unexpected tombstone lifetime

I was delivering our Active Directory Recovery Execution Service for a customer. The purpose of this delivery is to perform a full Active Directory forest recovery from backup media. The actual recovery is peformed in an isolated environment.

We have a discussion around the backup frequency and storage of the Active Directory backups, which is one of the reasons why knowledge of the tombstone lifetime is important. I will provide the specifics to this further on in this article.

We also perform an Active Directory health check before attempting the recovery. We need to understand if there are any underlying issues, which may cause the recovery process to fail. During these health checks I found that two Domain Controllers in a specific site didn’t replicate for a significant amount of time. The customer was aware of this, and the Domain Controllers could not be brought back online yet due to technical issues on the site in question.

This would not prevent us from performing the Active Directory recovery, but upon reviewing the event logs, I found that the tombstone lifetime on their Server 2012 R2 Active Directory forest was set to 60 days, and not 180 days as expected.


Directory Service Event ID 1864

Standard Active Directory tools such as REPADMIN is sufficient to determine if there are any Domain Controllers that are not replicating successfully. Active Directory will log event ID 1864 in the Directory Services event log when there are replication issues for extended periods. There will be an event logged for each directory partition and these events will be logged once every 24 hours. They provide the count of servers that have not replicated for the following intervals:

  • More than 24 hours
  • More than one month
  • More than two months
  • More than a tombstone lifetime

The tombstone lifetime in days will also be provided in the event details. This is how I noticed that the Windows Server 2012 R2 Active Directory forest of my customer does not have the expected default setting of 180 days configured. The tombstone lifetime was still set to the previous default setting of 60 days.

Below are examples of the 1864 events in the Directory Service event log from my lab:



The details in one of these events for a specific directory partition reads as follows:


This is the replication status for the following directory partition on this directory server. 
 
Directory partition:
DC=dev,DC=thelabx,DC=co,DC=za 
 
This directory server has not recently received replication information from a number of directory servers.  The count of directory servers is shown, divided into the following intervals. 
 
More than 24 hours:
2 
More than a week:
2 
More than one month:
0 
More than two months:
0 
More than a tombstone lifetime:
0 
Tombstone lifetime (days):
180 
 
Directory servers that do not replicate in a timely manner may encounter errors. They may miss password changes and be unable to authenticate. A DC that has not replicated in a tombstone lifetime may have missed the deletion of some objects, and may be automatically blocked from future replication until it is reconciled. 
 
To identify the directory servers by name, use the dcdiag.exe tool. 
You can also use the support tool repadmin.exe to display the replication latencies of the directory servers.   The command is "repadmin /showvector /latency <partition-dn>".

Why is the tombstone lifetime important?

Effectively a Domain Controller will be blocked from future replication when it hasn’t replicated within the tombstone lifetime. This then determines how long a Domain Controllers can be offline, whether this be due to infrastructure issues or servers being transferred to remote sites as an example.

This also determines how long your backups can be used to perform data recovery and even how long IFM (Install from media) files can be used to promote new Domain Controllers.


Why was the tombstone lifetime not 180 days

There are several scenarios described in the Windows Server 2003 documentation to determine when the tombstone lifetime would not be updated from 60 to 180 days. In summary, a new forest deployment of Windows Server 2003 Service Pack 1 would set the tombstone to 180 days. Installing Service Pack 1 on an existing Windows Server 2003 Domain Controller would not update the tombstone lifetime and the same applies when a new Domain Controller gets deployed with the Windows Server 2003 SP1 media, in the existing forest.

In the case with my customer, they upgraded from Windows Server 2003 to Windows Server 2012 R2, and thus it seems the same logic applied. New versions were introduced in the existing forest, and the tombstone lifetime was not updated automatically. This value was never verified and updated manually as was required in their scenario.


Validate and update tombstone lifetime value

The tombstone lifetime attribute can be verified using ADSI Edit but it is so much easier to just use Windows PowerShell (Active Directory PowerShell module is required).

The following PowerShell commands can be executed to provide the tombstone lifetime value, and the Distinguished Name where the attribute is stored.


$RootDomain = (Get-ADForest).RootDomain
$DomainDN = (Get-ADDomain -Identity $RootDomain).DistinguishedName
Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$DomainDN" -Properties tombstoneLifetime |
Format-List tombstoneLifetime,DistinguishedName

You should see the following which confirms that the tombstone lifetime is set to 180 days:



If you don’t see a value here, as per the example below, it means the tombstone lifetime is still set to 60 days:



The tombstone lifetime can be updated to 180 days by running the following commands:


$RootDomain = (Get-ADForest).RootDomain
$DomainDN = (Get-ADDomain -Identity $RootDomain).DistinguishedName
Set-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$DomainDN" -Replace @{tombstoneLifetime=180}

There will not be any confirmation on the output. To confirm that the updated completed successfully, just run the first command that was used to validate the value again, as shown in the image below:



Summary

The days of updating the default tombstone lifetime for Active Directory may be long forgotten, but if your Active Directory Forest has been running since Windows Server 2000/2003 and you have never verified the tombstone lifetime, it may be worthwhile to do so.

As I have found first-hand with my customer, there are some deployments out there that may still be using a tombstone lifetime of 60 days. Expecting a value of 180 days and realizing too late that this is not the case may cause unnecessary complications in the future.


References

Shelf life of a system-state backup of AD – Windows Server | Microsoft Docs

The Active Directory database garbage collection process and calculation of allowed intervals (microsoft.com)

Determine the tombstone lifetime for the forest | Microsoft Docs

[MS-ADTS]: Tombstone Lifetime and Deleted-Object Lifetime | Microsoft Docs


Author

Leave a Reply