Here is a great question and reply from a lead developer for AD Recycle Bin.

Q: After enabling the AD Recycle Bin, is there any downside to bringing the tombstoneLifetime value down to, e.g. 7 days? On the face of it it seems sensible to do this to keep the database trim.

A: With the recycle bin on, you don’t have tombstones, you have deleted-objects and recycled-objects. Recycled-objects are indeed not of any use to an administrator. They exist just and only for replication convergence. The lifetime for that is based on 1) end to end worst-case replication time (everyone needs to hear about the object becoming recycled) and 2) backup shelf-life (can’t bring back an object that the rest of the forest has already physically deleted). So, the recycled-object lifetime is all about avoiding lingering objects and replication divergence.

The deleted-object lifetime also feeds into backup times. This is because restoring from backup where an object in the backup is not recycled and the object in the live forest is recycled results in the object coming back to life on the DC that you restore on, but then it is re-recycled after a replication cycle. Once an object is recycled anywhere in the forest, it gets recycled everywhere in the forest and the fact of the recycling is sticky and spreads via replication. This is so you don’t lose links on one DC and not others, instead you lose them everywhere (hey, at least it’s deterministic). So the deleted-object lifetime is all about how long you have to undelete something.

So those are the principles. If you feel you can tolerate or mitigate around lingering objects, then you could lower recycled-object lifetime, although it seems to me that you don’t really want to set it low enough to cause lingering objects. I’d just let the convergence algorithm work its magic. Lowering deleted-object lifetime is fine as long as you don’t want to have very long to decide to undelete an object, and don’t mind the shelf-life issue.

Finally, the amount of space taken up in the directory by deleted objects is a function of database turnover (i.e. deletions per day). If you delete 1% of your objects daily and then replace them with other objects daily, you end up with about 22% of your objects live objects, about 39% deleted and about 39% recycled. But to get real size numbers, you’d need to know the average size of a live object, a deleted-object, and a recycled-object; these sizes are going to be based on data usage patterns of individual AD installations.

Final word; sure, shorten them if you can handle the trade-offs, and think it’s really worth the size you may save. But, unless you are running into a size issue, I wouldn’t.

OK, after-final-word word. A mitigation is to run some process that re-deletes deleted objects based on some criteria, like perhaps object class. This moves those objects along from deleted to recycled immediately, reducing the amount of time they spend in your DIT. We had to do something similar to handle an issue resulting from some specific builds that were produced during development.

 With thanks to Tony Murray and Tim Williams