SBS 2011 Standard – Disable TLS 1.0

SSLPost 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.

RDP-Tcp Setting

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.

SSL 2.0 Disable

Before I make any changes, I am just confirming I can access my RWA page and an internal client, via RWA.

SBS 2011 RWA

RDP to Windows 10

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

Disable TLS PowerShell

Disable TLS

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.

Things did not look good.

F SSL Report

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.

F SSL Report

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.

SSL Report Protocol

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.

B SSL Report

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.

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.

A- SSL Report

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.

Cannot connet to the remote computer because of an 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.

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!

Cant Get No RDP Satisfaction

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:

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.EAS DevicesSuccess 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.

SMTP TLS Not Working

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

PCI Compliance

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)

PCI Pass

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.

Got Satisfaction


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 1

Once 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
Robert Pearman is a UK based Small Business Server enthusiast. He has been working within the SMB IT Industry for what feels like forever. Robert likes Piña colada and taking walks in the rain, on occasion he also enjoys writing about Small Business Technology like Windows Server Essentials or more recently writing PowerShell Scripts. If you're in trouble, and you can find him, maybe you can ask him a question.

79 Responses to SBS 2011 Standard – Disable TLS 1.0

  1. Bob Groger says:

    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.

      • Bob Groger says:

        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)

      • Bob Groger says:

        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!

  2. Andy Parkes says:

    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

  3. Andy Parkes says:

    Ah cool. I will indeed give that a try! Thanks

  4. Mike Gibbs says:

    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.

  5. Badministrator says:

    The additional patch to let Windows 7 use TLS 1.2 through RD Gateway is here:

  6. 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:

  7. Robert your a life saver with this guide. Thanks for writing this up..

  8. Paul says:

    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.

      • Paul says:

        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.

  9. Paul says:

    And yes, thank you. My sharepoint is working after doing the update Updated 05/07/2016

  10. Paul says:

    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

  11. Paul says:

    To fix your Sharepoint 2010 when you see TEMP folders unders users follow this: . 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 :)

  12. Chadwick says:

    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.)

  13. Mike Gray says:


    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?

      • Mike Gray says:


        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.

      • Mike Gray says:


        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’.

      • Mike Gray says:

        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.

  14. Greg Z. says:

    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?

    • Bob Groger says:

      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.

  15. Mike Rolle says:

    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.

      • Mike Rolle says:

        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,
        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, ‘’

        ** 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 **

  16. Mike Rolle says:

    Here are the reg outputs also:
    Windows Registry Editor Version 5.00


    Windows Registry Editor Version 5.00


    Windows Registry Editor Version 5.00


    Windows Registry Editor Version 5.00


    • 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.

  17. Mike Rolle says:

    Hi Robert,
    I think you have a typo in the script. If I’m correct the lines about “DefaultSecureProtocols” should actually say “DefaultSecurityProtocols”.

  18. Mike Rolle says:

    I can see the conflicting information here. In your script you are looking at HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727″).DefaultSecureProtocols and
    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?

    • Bob Groger says:

      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.

  19. Mike Rolle says:

    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.

  20. Mike Rolle says:

    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.

  21. Mike Rolle says:

    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.

  22. Andy Wright says:

    Would you happen to have an all encompassing power shell script that will take care of this all at once?

  23. Mike says:

    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.

  24. Ted Cogger says:

    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?

      • Ted Cogger says:

        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

      • Mike says:

        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.

  25. Brooks Vaughn says:

    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

  26. Mike Gray says:


    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.

  27. TechnoNotice says:


    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 –

    Has anyone worked out how to get Search to use 1.2?

  28. protivakid says:

    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 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.

  29. Mike says:

    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!

Leave a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: