SBS 2011 Standard – Disable TLS 1.0
December 14, 2015 79 Comments
Post Updated 05/07/16
So you have completed a PCI Compliance scan, and you need to disable TLS 1.0?
You may have found the instructions here from TechNet which explain how to edit the registry to disable TLS 1.0, SSL 2.0 and SSL 3.0. What they don’t go onto explain is that this will break your RDP/RDP Gateway Connections.
Given that , as I understand it, the requirement to disable TLS 1.0 is being enforced from June 2016 I thought it was worth running through and sharing the process.
Before we start, I want to suggest you read through the whole process first. Also understand that I am documenting what happened in my lab system and by reading this aloud or in your head you waive any legal responsibility on my part in perpetuity throughout the universe.
Firstly, how are you accessing your server? We will be changing some settings that may cut you off without RDP access to get back. So, what is your backup plan? I am thinking iLO or DRAC.
We will change an RDP Encryption Level setting first. This should mitigate any potential risk to cutting you off.
Open up Remote Desktop Session Host Configuration, right click RDP-Tcp and then change the Security Layer to RDP Security Layer from Negotiate.
After you have applied this, confirm you can still RDP to your server.
Next open up Regedt32 and navigating to HKLM>System>CurrentControlSet>Control>SecurityProviders>SCHANNEL>Protocols
You will see that the SSL 2.0 protocol is defined, and by default the client component is disabled.
Before I make any changes, I am just confirming I can access my RWA page and an internal client, via RWA.
So armed with a confirmation we can go ahead and disable TLS 1.0.
Switching back to Regedt32 we can create a new Key for TLS 1.0, and then a new Key for Server, and finally a new DWORD to set ‘Enabled’ to 0.
You can do this manually if you like, or the PowerShell way.
New-Item "HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\PROTOCOLS" –Name "TLS 1.0" New-Item "HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\PROTOCOLS\TLS 1.0" –Name SERVER New-ItemProperty "HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\PROTOCOLS\TLS 1.0\SERVER" –Name Enabled –Value 0 –Type DWORD
The instructions on TechNet do not say if a reboot is required or not, a general rule of thumb I employ in this situation is to reboot, however before I did, I decided to try and verify if TLS 1.0 was off or not so I found an online SSL Report tool, in this case I am using the one at SSL Labs. https://www.ssllabs.com/ssltest/
Things did not look good.
The report confirmed TLS 1.0 was still active, so I rebooted the server and decided to try and lock down the other protocols.
Disabling SSL 2.0 seemed like a reasonable next step and is easy enough following the procedure above, after another reboot, I reran the scan expecting a result of at least C.
Well I was wrong.
Looking closer I found that whilst TLS 1.0 and SSL 2.0 were indeed, disabled, TLS 1.1 and TLS 1.2 were not and that TLS 3.0 was the only one available.
According to the documentation, to get TLS 1.2 enabled you need to create the ‘DisabledbyDefault’ DWORD and set it to 0.
I also enabled TLS 1.1 and disabled SSL 3.0.
Another reboot.
That certainly improved the situation.
Looking at the results here, I decided to look at disabling RC4 as this was holding me back to a ‘B’.
Luckily, Microsoft released a patch for that. https://support.microsoft.com/en-us/kb/2868725
Unluckily, it seems, that patch did not apply to my SBS Server.
Characteristically I didn’t bother to actually read the KB, which indicates that after the patch is installed you need to edit the registry.
So, after editing the registry to disable the RC4 Ciphers, I rebooted and reran the scan.
At this point I enlisted the help of long time caller first time listener Tim Barrett, who was keeping me company on a Friday night when the cool kids are out on the town and I am home working on SSL PCI Compliance. Luckily for me Tim lives in the past so he was still at work.
He confirmed to me via several lab systems, that at this point, if you were accessing the RWA from a Windows 7 machine, you would not be able to access any Remote Desktops, but that Sharepoint and OWA were still working.
Internally we had a Windows 7, Windows 10 and of course the SBS 2011, we could not connect to any of these from an external Windows 7 client.
Whilst you could login to the RWA itself, any RDP connection attempted would result in this error.
He also confirmed via some his own lab servers and clients, that Windows 10 clients were still able to connect to internal RDP Connections just fine and I confirmed from my PC that Windows 8.1 was also still working.
This is what I was expecting and I directed Tim to install this patch on his Windows 7 system. https://support.microsoft.com/en-us/kb/3080079
However, after applying the patch we were still unable to RDP using the RDP Gateway, we did confirm that a direct RDP connection to the server or a workstation was successful, this, I was not expecting.
What followed was a weekend of trying various configurations and repeated SSL tests, I decided to call it a day on Monday evening when I realised I could not even get an SSTP VPN to connect.
This of course leaves us with a dilemma, we can be PCI Compliant and refuse RDP Gateway Connections from clients running Windows 7 or earlier, or we can retain those connections, leave TLS 1.0 enabled and not be PCI Compliant.
Not the great outcome I had hoped for when I started this post, but we can’t always get what we want!
After I had finished all of this I decided to lookup Forward Secrecy and stumbled upon this excellent piece of PowerShell. This script will take care of locking down much more than I have covered here and goes into a lot more depth with setting CIPHERING orders. The script will configure your server to support an ‘A’ rating on the SSL Test.
Note this script currently enables TLS 1.0 so please disable it after use.
Useful Links:
- https://support.microsoft.com/en-us/kb/3080079
- https://support.microsoft.com/en-us/kb/245030
- https://technet.microsoft.com/en-us/library/dn786418.aspx
- https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12
- http://itexperiences.blogspot.co.uk/index.html2012/08/remote-desktop-connection-rdp-stopped.html
- https://www.ssllabs.com/ssltest/viewMyClient.html
- https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/
Update 15/12/2015
Following the comment below from Bob, I decided I had not done as comprehensive a test as I thought I had. Indeed, whilst OWA and Sharepoint were confirmed to work, what about EAS what about TLS with SMTP?
So, I linked my Phone (Windows 8.1) to the server for ActiveSync, and that worked correctly. I also roped in my wife and her iPhone and a co-workers Android.
Success all round.
Next I turned my attention to SMTP TLS. Using a reputable search engine, I found a website that would test a TLS connection for me. On a system where TLS 1.0 is enabled and functioning correctly, you will see that TLS 1.0 is negotiated.
Once you disable TLS 1.0, if you run the test you will see it fail.
This is a known issue in Exchange where SMTP TLS is hard coded to use TLS 1.0 and that it is resolved in UR9 for Exchange 2010 SP3 or CU8 for Exchange 2013.
Ater a reboot I reran the test and confirmed TLS 1.2 was now negotiated.
I am hoping Microsoft will release an additional patch to enable Windows 7 to work with an RDP Gateway Server using TLS 1.2, but we will have to wait and see!
Update 05/07/2016
I decided to try and run an actual PCI Compliance Scan against the server, which failed. However it did not fail on any TLS issues, it failed on some IIS vulnerabilities
I applied the two workarounds noted, which are to ensure a lockout policy is in place and that the administrator account was renamed, and that I believe was enough to change my status to Compliant.
(I did also tweak some IIS Settings to attempt to mitigate the HTTP Slow POST DDOS vuln, but not yet found the right combination of settings for that)
So as of the time of writing my SBS 2011 Standard is PCI Compliant. Whether or not this configuration will stay compliant after the 30th June, I cannot say.
I would expect Microsoft to release a patch to allow SQL 2008 R2 to function with TLS 1.0 disabled, prior to, or very soon after that June 30th deadline.
Updated 16/05/16
Thanks to commenter ‘Badadministrator’ I can tell you that Windows 7 can now operate using TLS 1.2 and RDP Gateway!
You will need this patch on your Windows 7 machines. I had to download this via the Update Catalog as my machine showed fully patched even after checking for updates from Microsoft.
CompanyWeb
Updated 05/07/2016
Following some comments below about SharePoint not working, i fired up my LAB machine to confirm what i had posted was correct.
Firstly i found my SharePoint was showing a 503 Service Unavailable Error. This was easily resolved using the method posted by Microsoft here.
Once this was done, i found i was presented with ‘An unexpected Error has Occurred” So i decided to walk back the changes i had made to the system in an attempt to get SharePoint at least functional before troubleshooting further.
The first thing i did was remove the FIPS GPO i mentioned above, i simply unlinked that particular GPO, i confirmed that the SQL Databases would not even start in this state. So next i re-enabled TLS 1.0. This of course required a reboot, but i confirmed after doing this SharePoint loaded as expected.
Next i did some research and found that as i half expected, Microsoft have indeed issued patches for TLS 1.2 for SQL and .Net. The first patch to apply is SQL Server 2008 R2 SP3. Reboot after applying this.
Next you will need to apply a second SQL 2008 R2 Update. KB3144114x64. Again reboot after applying this.
Thirdly a SQL Client Update is required.
Fourth, please apply the following .NET Hotfix. After this is done you will need to add two registry keys which are documented on this very helpful SharePoint TLS 1.2 Guide,
New-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name DefaultSecureProtocols -Type DWORD -Value 1
New-ItemProperty "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name DefaultSecureProtocols -Type DWORD -Value 1
New-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name DefaultSecureProtocols -Type DWORD -Value 1
New-ItemProperty "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name DefaultSecureProtocols -Type DWORD -Value 1Once you have done this you can Reboot and confirm SharePoint is still active, then you can Disable TLS 1.0 again.
Useful Link
About Robert Pearman
Title (Required) 
Robert, Can you confirm that OWA and ActiveSync work after these changes? There is a RDP patch for TLS 1.2, not sure if it applies here. KB3080079. Susan B opened a case for me on this earlier, it was resolved as “by design” so I have not revisited it. Thanks for doing the legwork!
Which devices did you need to check ActiveSync for?
It is working on my Windows Phone 8.1
We did check OWA at the time – just confirmed it is still working on Windows 7 – IE11.
This is a good tool to check what protocols your browser supports. https://www.ssllabs.com/ssltest/viewMyClient.html
I gave it another try. Everything now works except Sharepoint, which is not used at this site, and deleting or moving an item in OWA pops up a Dialog “The action you tried to perform cannot be completed due to a configuration error on the server”, event log has an error 108, source MSExchangeOWA, “Outlook Web App couldn’t connect Exchange Web Services due to a configuration error. Response code = “null, webException.Status = SendFailure”.” Mr. Google says it might be permissions on the EWS virtual directory, but the default install of Exchange 2010 does not create an EWS virtual directory. I suspect there may be some Apple users complaining tomorrow as well.
Hi Bob, I am working through some recently released hotfixes which i think will resolve these issues (and the other workarounds implemented above)
As an aside the copier can no longer authenticate with the Exchange server. I suspect that is on HP to fix. However, the PCI scan passed!
This can help too! https://www.nartac.com/Products/IISCrypto
After disabling SSL 3 AND TLS 1.0 do your SQL databases still start? (SBS Monitoring, SharePoint, etc)
As I understand it only SQL Server 2012 (with a variety of patches) and SQL 2014 support above anything above TLS 1.0
I hadn’t noticed (or thought to check) but you are correct, they do not. Looking into resolutions.
Only resolution as I can see at the moment is “upgrade to 2012 SP2 or 2014”
Would be very happy to hear otherwise!
I’m pretty sure it isn’t, but I need to confirm some things.
I enabled this GPO – Computer Configuration\Windows Settings\Local Policies\Security Options\ – System Cryptography: Use FIPS Compliant Algorithms
I did that, ran a GPUPDATE then another SSL Scan, which comes back as A rated still (TLS1.0 disabled) but now my SQL Databases start.
Will reboot and confirm, wanna try that?
I used IISCrypto to disable TLS 1.0, applied the GPO, and TLS 1.0 still shows as disabled. Testing confirms that it is.
Ah cool. I will indeed give that a try! Thanks
After a reboot, as expected TLS 1.0 is showing enabled again on the SSL Scan, however it still passes with an A rating.
I don’t know if this is as stringent as a PCI Scan though.
OK. I’ll make the changes, reboot and see if I can manually kick off a PCI scan
Running a PCI Scan now.
Well, it failed the PCI Scan, but looks like it failed on an NTLM Issue via SharePoint, not on TLS. Investigating.
A few IIS tweaks and I am now PCI Compliant.
Good work! :-)
Robert – ref your comment “A few IIS tweaks and I am now PCI Compliant” – mind if I ask what tweaks?
I don’t think I made a note.
However I was trying to mitigate the issues highlighted by the scan, which related to IIS NTLM and Slow HTTP DDOS.
The main tweak I think was actually enabling a password lockout policy, which I had not done on my lab system.
So the tweaks I made may not apply to all systems, so I would suggest you run a scan, see what your system fails on then target those specific issues.
The additional patch to let Windows 7 use TLS 1.2 through RD Gateway is here: https://support.microsoft.com/en-us/kb/3140245
Thanks, ill check that out.
Working! Awesome!
After disabling TLS 1.0 on both a Windows SBS 2011 Essentials box and a Windows 2012 R2 Essentials box, I was able to get PCI compliant on both of them. However, it broke the Client PC Backup feature of both systems. I found the following article which contains more information:
http://www.thirdtier.net/2016/04/what-happens-when-you-disable-tls-1-0
Robert your a life saver with this guide. Thanks for writing this up..
Well, now the sql communication is lost. Sharepoint broken and think better not to follow this manual if you have a production SBS2011 stil running
Did you follow all the way through – SQL stopping is a known issue until you amend a GPO.
Hello Robert. Yes i did, and the sql services are starting up without any problems. But when opening companyweb, i get an error: an unexpected error has occured. Inplace upgrade did not fix it and doing the sharepoint wizzard went ok, but still this error. TLS 1.0 is also still turned on but with a value of decimal: 4294967295 under protocols (registry). My certificate shows value A :).
Just curious. What will happen after 30-6-2016. (Tomorrow?) because i think windows 2008 (R2) can not run properly without TLS 1.0
I am also seeing this on my LAB system, where previously SharePoint was working with TLS 1.0 disabled. Will report back / update as needed.
Post Updated.
And yes, thank you. My sharepoint is working after doing the update Updated 05/07/2016
Hmmmm. FIPS turned off and my sharepoints works, but no mail coming in over MX anymore, FIPS turned on, my sharepoint shows : an unexpected error occured, and mails coming in again Any idea how to get my mails back in, without turning on FIPS in a GP? Thank you
Interesting, do you have Exch 2010 SP3 CU9 installed?
Confirmed, i have email in and out with FIPS policy unlinked. (i do not have CU9 on this particular server)
Will apply it now and confirm.
Confirming CU9 now applied, email flow still active, FIPS not enabled.
Hi Robert. I did all and fips off and sharepoint, mail and remote are fine now. Also updated exhange cu9 and latest versions for sql. Bit the short way is, use run all the updates and use iis crypto best practice and that’s it :).
Yeah, now MS released the patches, I wrote most of this last year :p
To fix your Sharepoint 2010 when you see TEMP folders unders users follow this: http://kb.itimpulse.in/?p=713 . Just reset the spfarm, spsearch and spwebapp password and your portal is ok again :) . I now set 4 sbs2011 servers to TLS 1.0 turned off and running better than before :)
I question this fix. I’ve been struggling with this and have patched an SBS2011 up to SP3 RU14, patched SQL for TLS, etc. However, when TLS 1.1 and 1.2 are the only protocols enabled things are still broken.
1.) OWA, users cannot move mail around to different folders – get an Exchange Configuration error.
2.) ActiveSync definitely breaks, but maybe only on certain mobile platforms / OS’s. Definitely confirmed that it does not work on an Android running Marshmallow with up through April patches (Nexus 5X.)
Run this script and see what it says for me?
https://1drv.ms/u/s!AitjjING4q12ldt1jM6nQJavcJpzQw
Hi,
Nice write up. I have followed this pretty much to the letter and I have found that Sharepoint worked for a limited time (a few hours last night), so I logged off and left. This morning I have report that sharepoint is not working, low and behold it is offline and stating “An unexpected error has occurred.”.
Strange that sharepoint was working under TLS 1.2 and now it is not. I ran you script above and received the following:
Multi-Protocol Unified Hello\Server – Disabled
PCT 1.0\Server – Disabled
SSL 2.0\Server – Disabled
SSL 2.0\Client – Disabled
SSL 3.0\Server – Disabled
TLS 1.0\Server – Disabled
TLS 1.1\Server – Enabled
TLS 1.1\Client – Error ‘Enabled’
TLS 1.2\Server – Enabled
TLS 1.2\Client – Error ‘Enabled’
** Testing Ciphers **
AES 128/128 – Enabled
AES 256/256 – Enabled
Triple DES 168/168 – Error
DES 56/56 – Disabled
NULL – Disabled
RC2 128/128 – Disabled
RC2 40/128 – Disabled
RC2 56/128 – Disabled
RC4 128/128 – Disabled
RC4 40/128 – Disabled
RC4 56/128 – Disabled
RC4 64/128 – Disabled
** Testing Hotfixes **
KB3154518 – Installed
KB3106991 – Installed
SQL Server 2008 R2 – OK
** Testing .NET 2.0 Registry **
DefaultSecureProtocols x64 – OK
DefaultSecureProtocols x86 – OK
** Test Exchange Version **
Exchange Server Version – OK
** Tests Completed **
I noticed there were a few errors in there, what does this mean? Please can you help?
Check your TLS 1.1 and 1.2 Client settings under, HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
What do you have there?
Hi,
Thanks for your help so far :) The keys I have there are as follows:
TLS 1.1 Client:
DisabledByDefault 0
Enabled: 4294967295 or HEX ffffffff
TLS 1.2 Client:
DisabledByDefault 0
Enabled: 4294967295 or HEX ffffffff
Should these be set to 1 or are these values ok?
Actually i think they are ok, ill amend that bit of the script.
Hi,
Figured out why sharepoint broke, I enabled FIPS in the local policy from your post above yesterday as I was getting constant SChannel 36871 errors and when I enabled FIPS, the errors stopped, but it looks to break sharepoint.
Now that FIPS is disabled again, sharepoint works, but constant SChannel errors. I’m at a loss at the moment, damned if I do, damned if I don’t situation lol
Will check my lab system and compare.
Ok i dont have any of those errors on my lab system.
I have a ‘1’ for the Client ‘Enabled’ on TLS1.1 & 1.2, i also have Triple DES 168/168 Enabled with ‘4294967295’.
thank you this, I will make the change and reboot the server when I can (as this is a Hotel system, so 24/7 an difficult to reboot) and will come back to you as soon as I can.
Thanks again.
Great article! Thank you. Has anyone solved the OWA issue with “The action you tried to perform couldn’t be completed because there’s a configuration problem on the server. If the problem continues, contact your helpdesk. The entire error report is listed below: Hide Report
The action you tried to perform couldn’t be completed because there’s a configuration problem on the server. If the problem continues, contact your helpdesk.” when moving items in OWA? Also we see our system event log filled with Schannel 36871 errors with an error sate of 10013?
I have given up on that for now. I think this is a good opportunity to upgrade these clients, or at least move the mail offsite. I have not figured out the Sharepoint not working with the FIPS GPO either.
New listener, 1st time caller…
I’m having the same issue as Mike Gray. Damned if I do, damned if I don’t. With FIPS off…same schannel errors as Mike, but sharepoint and companyweb work, with it on, they’re broke with the “an unexpected error occurred. I’m all patched, with exception of the last hotfix, which states it doesn’t apply to my server. Any ideas?
By the way, THANK YOU! for writing this up, it helped me greatly.
Can you try this script and post the output?
https://1drv.ms/u/s!AitjjING4q12ldt1jM6nQJavcJpzQw
Here’s the output. For some reason KB3106991 won’t install. That’s the one that states it doesn’t relate to my system.
SBS 2011 Standard, TLS Configuration Tester
Robert Pearman, WindowsServerEssentials.com
Use at own risk, no configuration changes will be made!
Check Server values against known working SBS 2011 Standard with TLS 1.0 Disabled
For more information visit, ‘https://windowsserveressentials.com/2015/12/14/sbs-2011-standard-disable-tls-1-0/’
** Testing Protocol Configuration **
Multi-Protocol Unified Hello\Server – Disabled
PCT 1.0\Server – Disabled
SSL 2.0\Server – Disabled
SSL 2.0\Client – Disabled
SSL 3.0\Server – Disabled
TLS 1.0\Server – Disabled
TLS 1.1\Server – Error ‘Enabled’
TLS 1.1\Client – Error ‘Enabled’
TLS 1.2\Server – Error ‘Enabled’
TLS 1.2\Client – Error ‘Enabled’
** Testing Ciphers **
AES 128/128 – Error
AES 256/256 – Error
Triple DES 168/168 – Error
DES 56/56 – Disabled
NULL – Disabled
RC2 128/128 – Disabled
RC2 40/128 – Disabled
RC2 56/128 – Disabled
RC4 128/128 – Disabled
RC4 40/128 – Disabled
RC4 56/128 – Disabled
RC4 64/128 – Disabled
** Testing Hotfixes **
KB3154518 – Installed
KB3106991 – Missing
SQL Server 2008 R2 – OK
** Testing .NET 2.0 Registry **
DefaultSecureProtocols x64 – Error – ‘Rgistry Entry Missing or Incorrect’
DefaultSecureProtocols x86 – Error – ‘Rgistry Entry Missing or Incorrect’
** Test Exchange Version **
Exchange Server Version – OK
** Tests Completed **
Here are the reg outputs also:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
“AspNetEnforceViewStateMac”=dword:00000001
“DefaultSecurityProtocols”=dword:00000001
“SystemDefaultTlsVersions”=dword:00000001
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
“AspNetEnforceViewStateMac”=dword:00000001
“DefaultSecurityProtocols”=dword:00000001
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
“AspNetEnforceViewStateMac”=dword:00000001
“DefaultSecurityProtocols”=dword:00000001
“SystemDefaultTlsVersions”=dword:00000001
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
“AspNetEnforceViewStateMac”=dword:00000001
“DefaultSecurityProtocols”=dword:00000001
You have some errors, is FIPS still enabled?
Please disable and run it again.
TLS 1.1\Server – Error ‘Enabled’
TLS 1.1\Client – Error ‘Enabled’
TLS 1.2\Server – Error ‘Enabled’
TLS 1.2\Client – Error ‘Enabled’
** Testing Ciphers **
AES 128/128 – Error
AES 256/256 – Error
Triple DES 168/168 – Error
The Protocols may show ‘Error’ if you have set value other than 1 for ‘Enabled’ however the Ciphers should all show enabled.
Hi Robert,
I think you have a typo in the script. If I’m correct the lines about “DefaultSecureProtocols” should actually say “DefaultSecurityProtocols”.
I’m fairly sure i have it correct, and refer you back to the SharePoint article i linked to.
There are a number of conflicting pieces of information of course, https://support.microsoft.com/en-us/kb/3154518 mentions ‘SystemDefaultTlsVersions’
This one, https://support.microsoft.com/en-gb/kb/3140245, mentions ‘DefaultSecureProtocols’ but in conjunction with WinHTTP.
All i can say is what worked in my lab.
I can see the conflicting information here. In your script you are looking at HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727″).DefaultSecureProtocols and
HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727″).DefaultSecureProtocols
however the “defaultsecureprotocols” in the MS article, as you stated, relate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp.
On my system, in relation to the first two entries, the name is there as DefaultSecurityProtocols.
I’ve just confirmed that with FIPS disabled, companyweb works, but RDP is broken.
Any other ideas or do you think I should place a call to MS?
Quite a while ago I opened (actually Susan Bradley opened for me) a ticket with MS. They closed it as “By Design”, they have no interest in further supporting SBS. With the suggestions here I can get it to “sort of” work but not completely. The best option I think is to move mail to hosted Exchange, disable RWW, and use RDGateway with TLS 1.2.The SBS individual components are or will soon be out of mainstream support. I am using Server 2016 release as my own personal end of life for SBS. That hardware is all due as well.
Can’t disagree with you, this will never be officially supported, but best effort to make it compliant and still work.
Just as an update, it seems that KB3106991 is for .net framework 2.0 SP2 and won’t install without it (unless I am missing something). Since SBS 2011 uses 3.51, it wont allow the install.
Another tidbit, I was under the impression that I was getting sharepoint updates automatically, but I wasn’t. I have a raft of them to go through, we’ll see if that makes a difference.
I was wrong, I misread. Everything is up to date, leaving companyweb broken as I need to have rww/rdp available. Seems odd that following MS best practices their own processes break…or maybe it isn’t really odd.
Run a qualys ssl scan against your system, what result do you get?
I get an A, I can post the full result if it helps
Sure, can’t hurt. Send it privately if you want, https://windowsserveressentials.com/support
Just sent it over. I couldn’t post anything other than basic text so hopefully you can read it well enough.
Would you happen to have an all encompassing power shell script that will take care of this all at once?
Just a shout out to anyone still facing this issue. I have been unable to stop using tls 1 as there is no workaround for the sharepoint requirement for it.
Im having the same problem as Mike Rolle
.netframework 2 kb3106991 will not install
active sync broken now is there a work around that I can use on this issue
Does it say why it wont install?
Problem is with SBS 2011 .netframework 2 isn’t installed SBS uses net framework 3
so therefore this patch will not install
the resultant effects are active sync will not work
Autodiscover also not working like mike I have to turn on tls 1.0 again
till this can be resolved
just a quick note, that I still have the same issue. Having tls1.0 is a must. I’ve found there are also exchange concerns related to disabling tls1.0. I received a multitude of calls from customers saying their emails were being rejected. Examining the server logs, I can see the attempts to connect and subsequent failures.
Hi Robert,
I am using your text-tls.ps1 script.
I find that it’s reporting the incorrect result when the protocol or cypher is Enabled using “0xffffffff” in the registry.
The script is using “-1″ in the as the compare in the If statements. The value should be compared to 4294967295 or to [System.UInt32]”0xffffffff”
if(($serverProtoColPropertyEnabled) -eq “-1″)
should be if(($serverProtoColPropertyEnabled) -eq [System.UInt32]”0xffffffff”)
if (($cipherEnabled) -eq “-1″)
should be if (($cipherEnabled) -eq [System.UInt32]”0xffffffff”)
Thanks for the Script, Regards, Brooks
Hi,
Apologies for my delayed reply.
Update, I turned off monitoring for SChannel errors as I read on an MS article that these are not important warnings and can be disregarded. These refer to exchange SMTP warnings, but we have an external antospam, so this is not too much of an issue for us at the moment.
The reason for my return is OWA is having the same problem as reported above – cannot delete emails in OWA as exchange EWS does not like TLS 1.0 being disabled and OWA and EWS doe not talk to each other properly. Activesync seems to work ok (which is strange regarding the OWA issue) and email clients appear to work correctly. I am running Exchange 2010 CU16 on SBS 2011.
Even though Sharepoint works, I do get a lot of sharepoint Timer and Search errors, but I’m living with it and the clients seem happy that everything is working in the foreground. I am keeping an eye out and finger crossed that the Exchange and Sharepoint problems get patched before EOL, but I can’t see it being MS and the big push towards office 365 now.
HI,
Thanks for the great guide.
The title is slightly misleading because you don’t disable tls 1.0 for WinHTTP (A80). For TLS 1.1 and 1.2 it should be A00 and 1.2 onlt should be 800.
If you are using Sharepoint (2010) Search we have found that if you disable TLS1.0/1.1 you will get Schannel errors that according to microsoft are related to SNMP approximiately 5 minutes after starting the service.
Have also implimented changes as detailed in the Microsoft document – https://technet.microsoft.com/en-us/library/mt773992(v=office.14).aspx
Has anyone worked out how to get Search to use 1.2?
Just wanted to say that this article was great. SBS11 is incredibly similar to WHS2011. As of 2020 the Remote Access website DNS update no longer worked. Your article steered me in the right direction to solve the issue. It was that TLS 1.2 needed to be enabled. After that the Server will correctly update it’s current IP to the HomeServer.com domain website.
My reason for commenting though was in regards to the iisforsslperfectforwardsecrecy script from Alexander Hass. After running this script Client PC Backup no longer worked. I narrowed down the problem to the disabling of TLS 1.0 for server SCHANNEL communications. If you delete that newly created key after running the script and reboot the Client Backup service will resume working and can back up other connected computers. Just a tip for anyone finding this in the future.
Great article! I support some legacy SBS 2011 on the side. This article was helpful in getting it to a “B” from an “F”. Every little bit helps!