Tag Archives: Windows Server

How to remove SSL 2.0 Server-Side Support from Windows Server 2008 R2

SSL 2.0 was released in 1995 but almost immediately replaced by SSL 3.0 in 1996 due to a number of security vulnerabilities. Nevertheless, Microsoft still enables server-side SSL 2.0 by default in Windows 7 and Windows Server 2008 R2… which will cause your server to fail any PCI compliance testing.

Disabling Server-Side SSL 2.0 is actually quite simple, you just need to create a key and reboot the server:

Key: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
Name: Enabled
Value: 0


After you’ve disabled it, you can verify functionality by using this free SSL Server Test from Qualys SSL Labs.

There is no need to make any modifications to Internet Informations Services (IIS) or Threat Management Gateway (TMG)… this is strictly an operating system level function.

If you’re interested in where it’s at, Client-Side SSL 2.0 is disabled by this registry key which should already be present:

Key: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
Name: DisabledByDefault
Value: 1

Note that you can follow the same process for just about any version of Windows since 2003.

Key Management Service (KMS) Commands Everyone Must Know

There are several commands I use often with Microsoft’s Key Management Service.  Normally, when a server is joined to the domain, there is almost never an issue with KMS.  That’s because KMS advertises through DNS, and if a server is joined to the domain, it’s likely pointed at the right DNS servers to pick up the KMS advertisement.

However, sometimes I have a server in the DMZ that is not domain joined, and is also not using AD-based DNS servers.  Alternatively, I might have a server on the local IT network, and even be using the AD-based DNS servers, but through a combination of sysprep, not being domain-joined, being off for a while or a whole host of other related circumstances it’s just not picking up the KMS advertisement.

The first command specifies a specific KMS server and port, which works great in the first circumstance:

slmgr.vbs /skms <value>:<port>

Note that the default port of KMS is TCP 1688

…for the second situation, oftimes you just need to clear KMS so that it gets set back to automatic:

slmgr.vbs /ckms

…and other times, you may have used a retail key during installation, and need to get it set back to a specific volume license key, in that situation, use:

slmgr.vbs /ipk [Volume License Key]

Finally, the following command will show you a nice screen shot of what is actually happening with activation and if there are any problems with activation:

Slmgr.vbs /ato

That’s it!  Between those three commands you can likely get any modern windows client/server to pick up the KMS instance on your domain and know exactly what’s going on with it.