Well it wasn’t all for naught because I know how to do it now, but of the 10,500 computers between WSUS and SCCM, it’s disheartening to learn that a mere 101, just less than 1%, between the two will require me to leave TLS 1.0 enabled on both servers… sigh… curse you XP/2003 and Vista/2008.
From: [email protected] [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Tuesday, July 26, 2016 3:14 PM To: [email protected] Subject: RE: [mssms] SCCM and TLS 1.2 Yea this all should be in one place… I guess I’ll have to find somewhere to host it… So it continues… Reporting Services… “The underlying connection was closed: An unexpected error occurred on a send.” Found https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/07/12/enable-tls-1-2-protocol-for-reporting-services-with-custom-net-application/ which helped a ton. I had been on https://support.microsoft.com/en-us/kb/3135244 initially when we installed SQL 2014 for the WSUS server I started this journey out on, but didn’t revisit for the SCCM server until today. I installed all the ADO.Net, SQL Native Client, and ODBC Driver updates it listed. (I didn’t install the JDBC updates) in addition to the .NET 3.5 SP1 update. Both that update page and the msdn blog had another registry key to add [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 A reboot, and SSRS is now working. My SCCM Server is 1606 with SQL 2012 SP3 GDR TLS 1.2 Update (11.0.6216.27) I think that’s it… I’ll see what else crops up. Todd From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: Tuesday, July 26, 2016 1:03 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM and TLS 1.2 Awesome info! Now this is my this list is friggin’ great! //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: den 26 juli 2016 18:17 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM and TLS 1.2 *cough* Blog Post *cough* From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Tuesday, July 26, 2016 10:33 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM and TLS 1.2 Just in case anybody else is wondering about TLS 1.2, SCCM and WSUS... I moved my test SCCM 1606 to the OU with ONLY TLS 1.2 enabled and as I suspected, SCCM could not communicate with WSUS, so I unchecked the “Require SSL” box on the ApiRemoting30 website app in IIS. It could communicate again. Not feeling great about that, but what could I do? Then on my way home, a colleague of mine sent me a link to a configuration page for Azure AD Connect and how to configure it to use TLS 1.2, and knowing my odyssey with TLS 1.2 thought I might like to see it. And what do you know, it contained a registry setting for .NET Framework to make .NET use strong cryptography. https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-prerequisites/#enable-tls-12-for-azure-ad-connect HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 "SchUseStrongCrypto"=dword:00000001 It occurred to me that all of the calls in the errors in the WSUS console I saw were .NET assembly errors. I wondered if it was .NET and not the WSUS console that was the issue, so I checked the box on the “APIRemoting30” website app back to “Require SSL”, added the above registry key, and restarted the server. When it came back up, the WSUS console was able to connect and it shows SSL over port 8531 in the WSUS console. So it’s not the WSUS console that has the issue, it’s .NET Framework itself that by default doesn’t support strong cryptography. By adding this key, first, one can follow the published MS documentation on securing WSUS with SSL and use ONLY TLS 1.2. And consequently SCCM works as well with only TLS 1.2 enabled, including communicating with WSUS. Seems like that little registry key might help out a lot of things, including PowerShell, since it’s .NET, to use TLS 1.2… Todd From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Wednesday, July 20, 2016 11:12 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM and TLS 1.2 Thanks Sherry Our security office is starting to get twitchy about everything but TLS 1.2 so I’ve worked out the Group Policy to turn it off and it seems to work well for most things. Our WSUS adventure started with SQL 2014, we couldn’t get it all the way installed with only TLS 1.2 active, because TLS 1.2 wasn’t supported on SQL 2014 until CU 3 or 4 I think, so we had to reenable TLS 1.0, install SQL, install the CU then turn it back off again. The WSUS console, and subsequently WSUS PowerShell, was solved by a call to MS and by unchecking the Require SSL box on the “APIRemoting30” Web app in IIS. Clients connected fine and updated fine all along over TLS 1.2, it was only the console that couldn’t connect, so left WSUS working, but unmanageable. I know we’re not supposed to monkey with the WSUS console connected to SCCM, but it would seem to me that one would have the same issue from the SCCM console since it uses the same APIs to manipulate WSUS. Did you happen to try changing any of the Software Update stuff around in your testing? I’ve upgraded our lab to 1602 and SQL 2012 SP3 +GDR to support TLS 1.2. I may apply my GPO to it and see what happens. Prod is slated to upgrade later this summer, so I wanted to work this out before then. We don’t have anything, that I’m aware of, extra wanting at the SCCM DB. I’ll have to wait and see if anybody complains when it gets turned off. ☺ Thanks again for the reply. Todd From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Sherry Kissinger Sent: Wednesday, July 20, 2016 5:13 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] SCCM and TLS 1.2 This is anecdotal; not any kind of documentation on it. But we attempted to enable only TLS 1.1 and TLS 1.2 in the lab. (disable tls 1.0 and ssl3, ssl2 was already disabled for years) For Current Branch console connectivity (1602 at the time of testing, in case someone looks at this email in the future), it worked just fine for us. Keep in mind we were Server12 r2 everywhere (fully patched), and we were at SQL 2014, latest SP, and latest cumulative update, and latest SNAC on any machines hosting the console and the site servers themselves. With that said... the CONSOLE worked fine. But as you might imagine we have a lot of 3rd party "things" that want to get at our data in the database. Even after walking everyone through getting to the bare minimum versions of odbc drivers (if that's what they were using) or SQL mgmt. studio (if that's what they were using) and the latest SNAC; there were still let me see... 3 different not-under-our-control-at-all external-to-us processes that "need to get our data" and THOSE products didn't yet support TLS 1.1 / TLS 1.2. In 1 case we could leave SSL 3.0 disabled, but had to enable TLS 1.0 For the other 2 cases--we're at the mercy of those external-to-us technologies to get with the program and be able to communicate over something better than SSL 3.0. I think those 2 "ssl 3 only" products are slated for upgrades in "the fall"; so we can retest then. So if that's helpful to you at all... that as long as everything else you might have that wants to get to your database (if you have anything like that) can communicate, you'll be OK. If you're lucky and don't have a dozen things all wanting your data, and the only thing that needs to connect is the console and reporting, then you should be just fine. :) On Wed, Jul 20, 2016 at 3:27 PM, Mote, Todd <[email protected]<mailto:[email protected]>> wrote: I know that WSUS supports clients using TLS 1.2, (the console does not, though there is a work around). Does anybody have any info about SCCM and TLS 1.2 (and its console)? I couldn’t find very much, if any at all. Todd -- Thank you, Sherry Kissinger My Parameters: Standardize. Simplify. Automate Blogs: http://www.mofmaster.com, http://mnscug.org/blogs/sherry-kissinger, http://www.smguru.org
