Is there any reason why TLS 1.1 and 1.2 are disabled on Windows Server 2008 R2?

Windows Server 2008 R2 seems to support TLS 1.1 and 1.2 but they are disabled by default.

Why are they disabled by default?

Do they have any drawbacks?

Server 2008 R2/Windows 7 introduced TLS 1.1 and TLS 1.2 support for Windows, and was released prior to the attacks that made TLS 1.0 vulnerable, so it's probably just a matter of TLS 1.0 being the default because it was the most widely used TLS version at the time Server 2008 R2 was released (July, 2009).

Not sure how you'd know for sure, or find out "why" a design decision was made, but given that Windows 7 and Server 2008 R2 introduced the feature to the Windows family, and Windows Server 2012 uses TLS 1.2 by default, it would seem to suggest it was a matter of "the way things were done" at the time. TLS 1.0 was still "good enough," so it was the default, but TLS 1.1 and 1.2 were supported for forward-support and forward-operability.

This technet blog from a Microsoft employee recommends enabling the newer versions of TLS and also notes that (as of October 2011):

Among web servers again, IIS 7.5 is the only which supports TLS 1.1 and TLS 1.2. As of now Apache doesn’t support these protocols as OPENSSL doesn’t include support for them. Hopefully, they’ll catch up to the industries new standards.

That further supports the idea that newer TLS versions weren't enabled by default in Server 2008 R2 for the simple reason that they were newer and not widely supported or used at the time - Apache and OpenSSL didn't even support them yet, let alone use them as default.

Details on precisely how to enable and disable the various SSL/TLS versions can be found in the Microsoft KB article number 245030, titled How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll. Obviously, the Client keys control Internet Explorer, and the Server keys cover IIS.

I was wondering this myself... maybe just due to known compatibility issues at the time... I found this MSDN blog entry (from 24-Mar-2011):

http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx

It talks about some web servers "misbehaving" in the way they respond to unsupported protocol requests, which then caused the client to not fallback to a supported protocol, with the end result being users not being able to access the website(s).

Quoting part of that blog entry here:

The server isn’t supposed to behave this way—it’s instead expected to simply reply using the latest HTTPS protocol version it supports (e.g. "3.1” aka TLS 1.0). Now, had the server gracefully closed the connection at this point, it would be okay-- code in WinINET would fallback and retry the connection offering only TLS 1.0. WinINET includes code such that TLS1.1 & 1.2 fallback to TLS1.0, then fallback to SSL3 (if enabled) then SSL2 (if enabled). The downside to fallback is performance—the extra roundtrips required for the new lower-versioned handshake will usually result in a penalty amounting to tens or hundreds of milliseconds.

However, this server used a TCP/IP RST to abort the connection, which disables the fallback code in WinINET and causes the entire connection sequence to be abandoned, leaving the user with the “Internet Explorer cannot display the webpage” error message.