Raising the functional level - Are you getting cold feet because of KB2260240?

Raising the functional level of your domain is a pretty straight forward operation. It is a mandatory step if you want to start using the Recycle Bin with Windows Server 2008 R2 or other new great security features with the newest versions of Windows.

It is super well documented, and among the great resources we have on TechNet, I'd like to mention those two blog posts:

So it's a one-click thing with only one well-known side-effect described here: FIX: "The requested mode is invalid" error message when you run a managed application that uses the .NET Framework 3.5 SP1 or an earlier version to access a Windows Server 2008 R2 domain or forest. This is only one possible issue but it can turn out to be a big deal. When it comes to going through your classic change management process, functional level changes are tricky because it does not necessarily involve a rollback action plan. Technically you can downgrade your functional level from Windows 2008 R2 back to Windows 2008 if you haven't enabled the recycle bin yet. But what we are seeing on the field is usually one change record for both the functional level and the activation of the recycle bin. Then there is no possibl roll back.

What's the matter with KB2260240?

In a nutshell, the .Net Framework contains a class called System.DirectoryServices.ActiveDirectory.Domain (defined in the DLL System.directoryservices.dll). You can instantiate it with a specific domain of your environment. And there is a property called DomainMode which enables you to know what is the functional level of the selected domain. For example in a PowerShell console, we can call it for the current domain:

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainMode

Windows2012R2Domain

The problem is that the old version of the DLL doesn't know about the functional level 2008R2. Which means that if you have a managed application using this DomainMode enumeration, and your DFL Windows2008R2, it will generate an exception and your application will likely crash.

How can I make sure that I am not affected by KB2260240?

You can look at the version of the System.directoryservices.dll. To be on the safe side the version number of this DLL in your system must be at least:

  • 2.0.50727.4466 for Windows Server 2008 SP2
  • 2.0.50727.4467 for Windows Server 2003

On a vanilla install of Windows Server 2008, the version of the DLL is 2.0.50727.4016. So you are affected.
On a vanilla install of Windows Server 2008 R2, the version of the DLL is 2.0.50727.5420. Therefore you are not affected.

There is another simple way to know ahead of time if you are affected by this problem. Launch a PowerShell console on your server and type the following:

[System.DirectoryServices.ActiveDirectory.DomainMode] | Get-Member -Static -MemberType Properties | Format-Table Name

This will list all the supported modes on your system. On my Windows 8.1 I have this output:

Name
----
Windows2000MixedDomain
Windows2000NativeDomain
Windows2003Domain
Windows2003InterimDomain
Windows2008Domain
Windows2008R2Domain
Windows2012R2Domain
Windows8Domain

The same on a Windows Server 2008 with the version 2.0.50727.4016 of the DLL:

Name
----
Windows2000MixedDomain
Windows2000NativeDomain
Windows2003Domain
Windows2003InterimDomain
Windows2008Domain

I don't see Windows2008R2Domain in the output, do I have to update?

If you don't see the Windows2008R2Domain it does not mean that your .Net managed application will crash. It will only do so if it uses the enumeration mentioned above. Which is not necessarily the case. However, your release management process might have a problem if you are using an outdated version of the DLL. So make sure you test and update the .Net Framework in a timely fashion and you should be fine.