

If they are not installed, the script will install them. The script just needs to be copied to a directory one each server, along with the software prerequisite files.ĭownload these files, and just drop them in the same directory as the script. It can be run on Management Server, Gateway, Reporting, Web Console, ACS Collectors, SQL database servers, anywhere you want TLS 1.2 enforced.Prompt to reboot the server to make the changes active.NET hardening, and ACS ODBC driver where required. Configure the registry for SCHANNEL protocols.Install software prereqs if they are missing.Ensure the software prereqs are installed (SQL Client and ODBC driver update).Ensure that SQL is a supported version for TLS 1.2.Ensure the SCOM Roles are patched with the correct UR level to continue.Determine the local SCOM roles installed.Ensure the environment is supported for TLS 1.2.Lets dive into the script and MP, and then we can discuss the finer details later! Microsoft has some guidance around what should be included in any test plan: There are always risks because you must understand where endpoints communicate, and any dependencies they might have on older TLS protocols. What are the risks of enforcing the use of TLS 1.2 protocol? WS2008 SP2 requires an update and then a registry change to enable TLS 1.2 WS2008R2 requires a registry change to enable TLS 1.2 Starting with Windows Server 2012 and later, these Operating Systems negotiated TLS 1.2 out of the box. Windows Server versions, and their support for TLS 1.2: Windows Server 2003ĭisabled by default – enable with Hotfix update and registry changeĭisabled by default – enable with registry change

The Microsoft documentation for TLS 1.2 and SCOM is available here:Īs you can see, even TLS 1.2 is 10 years old!!! I also will demonstrate a management pack which will help confirm the settings are correct, and help identify risks before you implement. This article will demonstrate the steps involved, and will include a script I wrote the help automate the configuration, remove the risk of errors, and ensure nothing is missed. The bad news: is that the configuration is a little complicated, there are software prerequisites, and the manual steps can be error prone. The good news: is that SCOM 2012R2 (with UR14+), SCOM 2016 (with UR4+), and SCOM 1801 all support working in an environment that is configured to use TLS 1.2 ONLY. Customers are getting told by their security teams that they need to support their application and database servers using TLS 1.2 only, and no previous protocols enabled for SCHANNEL communications. This is a requirement that I see is picking up steam with customers.
