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]] On Behalf Of Sherry Kissinger Sent: Wednesday, July 20, 2016 5:13 PM To: [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
