In a previous entry I spoke about some documentation on TechNet that was incorrect which stated that if the tombstonelifetime attribute wasn’t set on the Directory Service object in the configuration container of an Active Directory (or ADAM) that the tombstone lifetime (TSL) was either 60 days or 180 days depending on whether the forest was built with pre or post K3 SP1 (or pre/post ADAM SP1/R2).
This posting was a result of a question I fielded in one of the public newsgroups and the chain didn’t stop there… It seems folks were still seeing NOT SET with new R2 forest installations. This absolutely shouldn’t be so because R2 is Windows Server 2003 SP1 with some option packs tossed in for good measure (like ADAM and ADFS, etc).
Well, the guys were so adamant about this I built a new virtual server guest from from MSDN R2 ISOs for CD1 and CD2 and saw that after the first CD was completed, the version of schema.ini was correct. Then I installed CD2 and schema.ini was changed to a special R2 version. This R2 version was updated to reflect a new schema version (Version 31). Unfortunately, the file that whomever updated with this new schema version, wasn’t the most recent version of the file because it didn’t have the tombstonelifetime correction in it…
So what does this all mean…
It means that if you build an SP1 server and promote it into a new forest, it should have a TSL of 180 days. There is still some question around this in the newsgroups because a couple of folks are saying they aren’t seeing this. I have seen this every case I have tested (hundreds of test forests I have built, 20 live right now all are correct) so unless we have some variations in installation media, this shouldn’t be a problem.
It means that if you build an R2 server and promote it into a new forest it will have a TSL of 60 days. This is incorrect and unintended. Just to be absolutely positive something funky isn’t going on I chased into the source and while there is a new constant defined for SP1 forest TSL, it isn’t being used to correct any of this. The standing constant being used is, and this makes PERFECT sense, is the old constant of 60 days.
Oh my god!!! The sky is falling the sky is falling…
No not really, you can fix this bug in a very easy way… After you build your first DC run this command
adfind -config -f name=”directory service” -dsq | admod tombstonelifetime::180
All fixed. You only have to do it once… TSL is forestwide.
If you are building lots of R2 forests then maybe you want to tweak the schema.ini file but I am not a fan of that because at some point MSFT will change it again and maybe you won’t notice… But if you do, DO NOT copy the schema.ini file from CD1 of R2 over the version that gets installed on your server, instead find the portion of the schema.ini file that looks like
[Directory Service]
nTSecurityDescriptor=O:EAG:EAD:(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCRCWDWOSW;;;EA)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)S:(OU;SA;WP;f0f8ff86-1191-11d0-a060-00aa006c33ed;;WD)
objectClass=nTDSService
ObjectCategory=NTDS-Service
sPNMappings=host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc
ShowInAdvancedViewOnly=True
msDS-Other-Settings=DynamicObjectDefaultTTL=86400
msDS-Other-Settings=DynamicObjectMinTTL=900
msDS-Other-Settings=DisableVLVSupport=0CHILD=Query-Policies
and just before CHILD=Query Policies insert the following lines
; Explict TSL default set in W2K3 SP1 to increase shelf-life of backups and allow longer
; disconnection times.
tombstoneLifetime=180
If you copy the old file over the new file then you will dork with the schema object version number setting which you don’t want to do either.Â
I have sent this info off to some folks at Microsoft to get it looked at. Honesly, there really isn’t a whole lot they can do at this point except create a knowledge base article and stick it out there and hope people see it. In the meanwhile, all of you AD people… Let your friends know because this could really bite someone in the butt rather hard. If someone just assumes their forest is set for 180 days and then all of a sudden go to do something that that assumption is critical for they could have all flavors of nasty in their lap…
While this is a little premature, I.E. I haven’t heard official validation back from MSFT that this is indeed what is going on and it is wrong, I am pretty confident about it and we need to be aware of it. At the very least, running the little admod command above on a forest built from SP1 or R2 media certainly isn’t going to hurt anything unless you have already tweaked the value yourself to something else…
So if you want… first ask for the current value
adfind -config -f name=”directory service” tombstonelifetime
and if it is anything less than 180, then run the command so it will be set to 180. Again, so you don’t have to scroll back…
adfind -config -f name=”directory service” -dsq | admod tombstonelifetime::180
All that does is tells adfind to find the configuration container object named directory service and then output the DN of that object and then tells admod to read that DN from the pipe and to set the attribute called tombstonelifetime to the value of 180.Â
 joeÂ
Â
hehe, yep I’ve seen that (the difference of the Schema.ini files; i.e. missing entry for the tombstonelifetime property) but didn’t think too much of it because for now I’ve only had to handle upgrading from Win2000 or 2003 to R2 where the Schema.ini doesn’t play a role. It is “only” used to populate a blank schema at the time that you create a new AD forest – and yes, this means that your tombstone lifetime wouln’t match that of other Win2003 forests that were created from a DC that had SP1 applied to it…
I agree, not very nice, but easily fixed as you describe. Personally, I don’t think too much of the fact that the tombstonelifetime was increased to 180 days in SP1 anyways. This was done to avoid issues for companies with a badly managed AD – I would generally much prefer to adjust the value to what is appropriate for a company’s backup & recovery strategy. And this usually doesn’t mean that you need to keep the “garbage” in your AD for 1/2 a year…
Granted, it’s the inconsistency here with which MSFT has done the update of the schema.ini files which is not so nice – but the rules are pretty clear on how tombstone lifetime can be evaluated by an admin: if the attribute on the Directory Services object (tombstoneLifetime => CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=) shows NOT SET, then it’t the “original” default tombstone lifetime of 60 days. Else it’s whatever number of days has been set either by the DCPROMO routine writing a specific value into the attribute when creating a new forest, or by an admin changing the value to whatever is appropriate.
/Guido