Last year there were a lot of hangups getting some applications onto TLS 1.2. Here are some common things that need to be done before disabling TLS 1.0 and 1.1.
Update SQL Server Native Client
This is the biggest hangup I’ve seen. Applications and Server 2016 seems to ship with a driver version from 2011. If you don’t do this then your SQL connection will still try to be established over TLS 1.1. As far as I can remember, on the SQL server side TLS 1.2 has been supported for a long time. It’s just the client side that requires the update. Here’s the latest version: https://www.microsoft.com/en-us/download/details.aspx?id=50402
App side: .Net Needs SchStrongCrypto
Assuming your application isn’t written in a fairly recent version of .Net (4.6+), you’ll need to apply a registry key to all of your application servers for each version of .Net.
registry key has a value of type DWORD. A value of 1 causes your app to use strong cryptography. The strong cryptography uses more secure network protocols (TLS 1.2, TLS 1.1, and TLS 1.0) and blocks protocols that are not secure.
Generally speaking, there’s more to this and everyone needs to read the entire webpage:
Remote Desktop Protocol
RDP breaks when you disable the older protocols on older OSes, namely 2008 R2 and 2012. Most of the time it’s a server side fix, but there are some folks still on older client OSes that cause issues too.
If none of this works for you, it may be best to just revert to RDP Security Layer (default is SSL/TLS1.0). It’s less secure, but it’s better than backing out of a change because people can’t RDP: https://blogs.technet.microsoft.com/askperf/2008/02/16/ws2008-network-level-authentication-and-encryption/
Enable TLS 1.2 and Disable All Others
Finally, you may be ready to execute the TLS change. I recommend using IIScrypto. Just load the pci31 template and disable TLS 1.1. It will write out all of the registry keys for you and leave no stone unturned. It even reorders your ciphers to most to least secure.