Many moons ago I wrote a post about how a TechNet article on the default tombstone lifetime was wrong. That TechNet article eventually ended up getting corrected at some point though it doesn’t seem to be properly linked anymore to the GUID URL that I had for it – so much for theory of never losing TechNet articles again because they were "unique" GUID links… Regardless, it has been brought to my attention that once again a TechNet article has screwed this simple topic up when updating it for PowerShell[1].
http://technet.microsoft.com/en-us/library/dd392260(WS.10).aspx
Both here
By default, tombstoneLifetime is set to null. When tombstoneLifetime is set to null, the tombstone lifetime defaults to 180 days (hard-coded in the system)
and
In Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2008, or Windows Server 2008 R2 operating systems, when tombstoneLifetime is set to null its value defaults to 180 days.
So for now and all eternity, please link to, copy and paste, recite, or whatever you do around this topic from this blog post.
The tombstoneLifetime attribute is very simple. Don’t worry about the operating system as it exists now, don’t worry about the operating system as it existed when the Active Directory was initially built, it is all moot. The one and only way to know what the tombstoneLifetime value for a forest is is to look at it.
- If the value of tombstoneLifetime is NULL or <NOT SET> the value *IS* 60 days.
- If the value of tombstoneLifetime is > 0. The value *IS* the integer specified measured in days.
You can easily ascertain the value by using the following command: [2]
adfind -config -f objectclass=ntdsservice tombstonelifetime
Which will look like
C:\>adfind -config -f objectclass=ntdsservice tombstonelifetime
AdFind V01.45.00cpp Joe Richards (joe@joeware.net) March 2011
Using server: K8R2Dom-DC1.k8r2dom.loc:389
Directory: Windows Server 2008 R2
Base DN: CN=Configuration,DC=k8r2dom,DC=locdn:CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=k8r2dom,DC=loc
>tombstoneLifetime: 1801 Objects returned
Or if you really want to make this simple, use the following:
adfind -config -f objectclass=ntdsservice tombstonelifetime -oao 60
which will display the integer value no matter what through some AdFind "magic". That magic being that the -oao switch when specified with a value will populate that value in any empty attributes. So if the value isn’t populated in AD, it will still look like it is when the output is displayed.
For example, same command with one non-existent attribute to help illustrate the point:
C:\>adfind -config -f objectclass=ntdsservice tombstonelifetime hardcodedWindowsADTombstoneLifetimeValue -oao 60
AdFind V01.45.00cpp Joe Richards (joe@joeware.net) March 2011
Using server: K8R2Dom-DC1.k8r2dom.loc:389
Directory: Windows Server 2008 R2
Base DN: CN=Configuration,DC=k8r2dom,DC=locdn:CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=k8r2dom,DC=loc
>tombstoneLifetime: 180
>hardcodedWindowsADTombstoneLifetimeValue: 601 Objects returned
You can do the same with CSV
adfind -config -f objectclass=ntdsservice tombstonelifetime -nodn -csv 60
which could look something like:
C:\>adfind -config -f objectclass=ntdsservice tombstonelifetime hardcodedWindowsADTombstoneLifetimeValue -csv 60 -nodn
"tombstonelifetime","hardcodedWindowsADTombstoneLifetimeValue"
"180","60"
Simple?
In 2017 when this gets screwed up again in TechNet when they are describing how to figure it out with whatever new fancy tool they have now switched to the above information will STILL be correct and that AdFind command will still work just fine.
joe
[1] Further proof that PowerShell isn’t doing anything new, it is simply redoing what was done before with more verbose commands… 😉
[2] Or… even shorter "adfind -b -pr -f objectclass=ntdsservice tombstonelifetime". That can be an exercise for the class to figure out what is happening there.
