Starting with Windows Server 2008, the goal is to allow raising the DFL/FFL without auto enabling any features. All of the features introduced in Windows 2008 based AD can be used by merely raising DFL. This means admins can raise DFL/FFL knowing they are only restricting the OS choice of newer DCs and preventing any downlevel DC been introduced.
So once you raise your DFL it wont auto enable anything. You can go ahead and start choosing when you want to use features like fine grained password policies and dfsr for sysvol replication. Other features such as restartable AD, RODC, AD Powershell etc are not dependent on DFL/FFL raises so you can use them already. See following links for details
2008 - http://technet.microsoft.com/en-us/library/cc753516(WS.10).aspx
2008 R2 - http://technet.microsoft.com/en-us/library/dd378796(WS.10).aspx
also see http://blogs.technet.com/askds as they have details on usage of these features.
According to the Microsoft support engineer I spoke with... and the Microsoft engineer he escalated me to... and their manager, the short answer is that the only way to rid myself of this cursed object is to do an authoritative restore to before this object's appearance in the LostAndFound container. I'm convinced I could also rid myself of it by booting all the domain controllers to LiveCDs and manually editing the AD database, but short of those two non-options, I'm stuck with it.
As to how and why this is the case:
We ran a repadmin /showobjmeta against the object (to peek into its metadata) and were able to determine from the object's isDeleted version (2) that it was deleted, then unexpectedly and unsuccessfully/partially restored, which is what is causing the problem. It was suggested, and seems likely to me, that after the object was restored, but before the change had completely replicated, it was deleted again, along with its parent OU, causing the restore to fail, and resulting in it being considered an orphaned object by at least some of our domain controllers, landing it in the LostAndFound container.
As a result of the partial restore, it cannot be restored. As a result of the object's SAMAccountType being empty, it cannot be deleted (or modified).
The SAMAccountType attribute is a value that cannot be changed by any user, and attempting to do so throws the below error:
Operation failed. Error code: 0x209a
Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).
0000209A: SvcErr: DSID-031A1021, problem 5003
(WILL_NOT_PERFORM), data 0
We can't restore the object to get the system (Security Accounts Manager) to set this attribute because of the partially-restored state it's in, and we can't delete it (or modify it) without a valid value for that attribute.
However, since this is too interesting of a case for me to simply walk away from, I'm going to poke around for a while and see if I can't come up with a way around this, or at least expand my knowledge of AD a little bit more in the attempt. Beats troubleshooting printers... and frankly, it turns out that a computer telling me "WILL_NOT_PERFORM" is a challenge I cannot resist.
Oh yes you will perform, dammit!
Best Answer
The main implication of enabling this feature is that it will increase the size of your DIT. (Your database.) It tends to increase the size because objects that have been deleted hang around longer than they would without the AD Recycle Bin enabled.