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.

Comments (11)

  1. Ed (DareDevil57) says:

    thanks for sharing.

  2. Maybe I could rename the post "Raising the functional level to Windows 2008 R2 – Are you getting cold feet because of KB2260240?" to be more specific. The idea of the post wasn’t to link on the KB article, it is already well known, it is to give a little
    bit more background. Besides, version numbers are easy to identify and report (with inventory tools for example).

  3. Ros, potentially yes. But again it depends what the app is doing. A non updated version of the Framework will not have the problem if it is not using the enumeration mentioned in this article. So if the app is not updated, standing in a trusted domain
    and tries to enumerate trusted domains and their respective functional level, you could encounter the exception described in KB2260240.

  4. The KB2260240 deals with Windows 2008 R2 functional level. For Windows 2012 R2 level, you can have a look at this post:

    http://blogs.technet.com/b/pie/archive/2014/10/29/raising-functional-level-to-windows-2012-or-windows-2012-r2-will-i-break-anything.aspx

    The concept is that he functional level needs to be listed in the possible values of the property DomainMode. And this is a different list depending on the version of the DLL. The new versions of the DLL do not prevent the exceptions, they are just adding support
    for the next functional level. Now, it is true that they could have coded this in a way that it does not throw an exception anymore but just an "Unknown" value. But because it is affecting managed application, the dev can still add some error management to
    their code (what they might have done already because of the KB2260240).

  5. Simply update your Framework .Net and that should do the trick.

  6. Anonymous says:

    In short, yes… Meaning that it is possible that you are facing the same problem as the one described

  7. Joe says:

    You seem to be implying its the version of the dll installed on the machine which makes a difference, it’s not.

    Actually, if you updated the framework on the machine, it wouldn’t make any difference to a .NET application that references an older version of the dll. The application would still throw an exception if it used the enumeration on a 2012 R2 Domain.

  8. Ros Jordan says:

    If the app isn’t in the forest having the FL upgrade is this still an issue

  9. James McCabe says:

    Do you have a recommendation on how to acquire this hotfix? It does not appear to be readily available by downloading via the KB article, and requires you contacting Microsoft (which may incruse additional charges – it sounds like)?

  10. Message to Joe, I updated the post
    http://blogs.technet.com/b/pie/archive/2014/10/29/raising-functional-level-to-windows-2012-or-windows-2012-r2-will-i-break-anything.aspx to reflect that. If your application is explicitly using the old Framework, yes you can be impacted indeed. I added
    something about PowerShell since it is by default configured to use the .Net 2.x…

  11. Thomas says:

    Hi there, firstly thanks for all the good info. I have updated a couple of old test 2003 servers like this but hey still show supported domains up to Server2008 only – despite the patch being applied and System.DirectoryServices.dll being the correct version…has anyone else seen this, too ?

Skip to main content