none
WSUS 3.0 SP2 not syncing anymore? SHA-1 or TLS 1.0 deprecated already? RRS feed

  • Question

  • I have a Windows 2003 SP2 server with WSUS 3.0 SP2 running. Until recently this setup worked quite well. However, WSUS does not sync with update servers anymore. The error message is 

    WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

    I suspect it is due to insufficient crypto between WSUS and MS update servers; either SHA-1 or TLS 1.0 is an issue. Here's what I did to further investigate the issue:

    1- I downloaded trials of Server 2012 R2 and Server 2016. They work fine and the communications between WSUS and update servers is done over TLS 1.2, using SHA-384.

    2- I checked what's being transmitted and received using wireshark. I saw that after the DNS query for www.update.microsoft.com, the WSUS starts the handshake with a TLS hello, offering the following list of cipher suites:

    TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

    TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

    TLS_RSA_WITH_RC4_128_MD5 (0x0004)

    TLS_RSA_WITH_RC4_128_SHA (0x0005)

    TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

    TLS_RSA_WITH_DES_CBC_SHA (0x0009)

    TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)

    TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)

    TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)

    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)

    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

    TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)

    TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)

    In this case, update servers immediately close the connection with a TCP RST.

    3- Then I installed a trial build of Windows 2008 R2 SP1 server. After installing the trial and configuring WSUS 3.0 SP2 (by adding the role), I let the server update itself first via windows update. After downloading about 1GB of updates and restart, I was surprised to see that I am getting the exact same error from the Server 2003 SP2 case.

    Checking the network traffic in this case shows one common details with the server 2003 case: No ciphers that have newer hashing algorithms than SHA-1 are offered to windows update servers. Windows Server 2008 R2 SP1 supports, for example TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) which actually is used by Server 2012 R2 and 2016. However, it is not offered during handshake at all.

    After searching around a bit, I found out why WSUS 3.0 SP2 is not offering the more advanced cipher suites during handshake: On Server 2003 SP2 and Server 2008 R2 SP1, WSUS binaries are built against .Net Framework 2.0, which does not support TLS beyond 1.0. On Server 2012 R2 and 2016, WSUS binaries are built against .Net Framework 4.0 and with this comes the support for TLS 1.2 and advanced hashing algorithms.

    To summarize, I am trying to confirm/figure out the following:

    1- Are SHA-1 and/or TLS 1.0 deprecated on the windows update servers?

    2- If SHA-1 and/or TLS 1.0 are not deprecated, what should I do to get my Server 2003 SP2 installation with WSUS 3.0 SP2 back in working order (update/hotfix/anything else)?

    3- If these are deprecated and clients will not be able to download updates if they don't have support for newer cipher suites, did the support status of WSUS 3.0 SP2 or Windows Server 2008 R2 SP1 change? As far as I know, both are supported until January 2020.

    I can provide the network traces and other information if necessary.

    Thanks in advance for your help.


    • Edited by TE_723 Saturday, January 21, 2017 9:02 PM
    Saturday, January 21, 2017 9:01 PM

All replies

  • Hi TE_723,

    1. Windows server 2003 is out of support on July 14, 2015, please check the following article for detailed information:

    https://www.microsoft.com/en-us/cloud-platform/windows-server-2003

    2. For WSUS server 2008R2, we'd upgrade it to version 3.2.7600.274 via installing KB2938066:

    WSUS 3.0 (SP2): Build 3.2.7600.226
    WSUS 3.0 (SP2) + KB2720211: Build 3.2.7600.251
    WSUS 3.0 (SP2) + KB2734608: Build 3.2.7600.256
    WSUS 3.0 (SP2) + KB2828185: Build 3.2.7600.262
    WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, January 23, 2017 5:21 AM
    Moderator
  • Hi TE_723,

    1. Windows server 2003 is out of support on July 14, 2015, please check the following article for detailed information:

    <snipped link since I cannot post messages with links inside>

    2. For WSUS server 2008R2, we'd upgrade it to version 3.2.7600.274 via installing KB2938066:

    WSUS 3.0 (SP2): Build 3.2.7600.226
    WSUS 3.0 (SP2) + KB2720211: Build 3.2.7600.251
    WSUS 3.0 (SP2) + KB2734608: Build 3.2.7600.256
    WSUS 3.0 (SP2) + KB2828185: Build 3.2.7600.262
    WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274

    Best Regards,

    Anne



    Windows Server 2008 R2 SP1 already has the 3.2.7600.274 build. I know Windows Server 2003 is out of support. The issue here is related to WSUS 3.0 SP2, which is supported until 2020. I explained in my message why WSUS 3.0 SP2, even patched to the latest build, will not be able use more advanced cipher suites (because on Server 2008 R2 SP1, WUS 3.0 SP2 is based on .Net Framework 2.0 which only has support for TLS1.0/SHA-1).

    I would like to repeat my questions in slightly modified form before they get lost in the discussion. I am looking for an answer especially for the first question, preferably from WSUS team:

    1- Are SHA-1 and/or TLS 1.0 deprecated on the windows update servers?

    2- If SHA-1 and/or TLS 1.0 are not deprecated, what should I do to get my Server 2003 SP2 and Server 2008 R2 SP1 installations with WSUS 3.0 SP2 back in working order (update/hotfix/anything else)?

    Keep in mind that any solution that makes WSUS 3.0 SP2 work on the Server 2008 R2 SP1 scenario will (most likely) fix the Server 2003 SP2 case automatically.

    3- If these are deprecated and clients will not be able to download updates if they don't have support for newer cipher suites, did the support status of WSUS 3.0 SP2 or Windows Server 2008 R2 SP1 change? As far as I know, both are supported until January 2020.

    Regards,

    Monday, January 23, 2017 1:03 PM
  • Hi TE_723,

    Thanks for your effort and share the detailed research information with us about the TLS progress for windows update.

    I tried to find official article to explain if TLS 1.0 is deprecated for windows update, while there seems no official statement.

    And as you have mentioned, WSUS 3.0 use .net framework 2.0, and WSUS 4.0 use .net framework 4.0, this can't be changed on WSUS 3.0. You may try disable TLS 1.0 to force it use TLS 1.2, check if it could help. If it still not work, then, there might not be a workaround about this issue. Just to upgrade the WSUS server.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, January 24, 2017 8:52 AM
    Moderator
  • Hi TE_723,

    Thanks for your effort and share the detailed research information with us about the TLS progress for windows update.

    I tried to find official article to explain if TLS 1.0 is deprecated for windows update, while there seems no official statement.

    And as you have mentioned, WSUS 3.0 use .net framework 2.0, and WSUS 4.0 use .net framework 4.0, this can't be changed on WSUS 3.0. You may try disable TLS 1.0 to force it use TLS 1.2, check if it could help. If it still not work, then, there might not be a workaround about this issue. Just to upgrade the WSUS server.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.

    Disabling TLS 1.0 would not help since there's no way a managed application using .Net 2.0-provided infrastructure could negotiate TLS1.1/1.2. I disabled TLS1.0 anyway, keeping TLS1.1 and 1.2 active and the result is as follows:

    WebException: The underlying connection was closed: An unexpected error occurred on a receive.

    ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm


    This shows that TLS 1.0 is the only common algorithm between Net20-based WSUS 3.0 SP2 and windows update servers. It also shows that the servers at www.update.microsoft.com are not rejecting TLS1.0, but rejecting the SHA-1-based cipher suites. If I enable TLS1.0, this is the list of cipher suites that WSUS 3.0 SP2 running on Windows Server 2008 R2 SP1 is offering to www.update.microsoft.com:

    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
    TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

    Notice that there are no SHA256 or SHA384-based cipher suites being offered (only SHA-1-based suites are being communicated; SHA256 or SHA384 would require TLS 1.1 or 1.2). This looks like the reason www.update.microsoft.com is closing the connection.

    As for your upgrade suggestion: Are you saying that I should upgrade to Server 2016? Windows Server 2008 R2 SP1 and WSUS 3.0 SP2 are both supported until January 2020. Is it possible for someone from WSUS team to look into this? Rather than finding a solution to the problem, I find it hard to accept the "move on to the newer release" suggestion on a product that is to be supported for another three years.

    Regards,


    Tuesday, January 24, 2017 12:30 PM
  • Hi TE,

    If you want to get better help, you may open a case with MS:

    https://support.microsoft.com/en-us/gp/support-options-for-business

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, January 26, 2017 6:42 AM
    Moderator
  • Hi TE,

    If you want to get better help, you may open a case with MS:

    https://support.microsoft.com/en-us/gp/support-options-for-business

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    I am not running a business so that option is not available to me. I was just hoping that you could contact either WSUS team or the team who is administering the windows update servers and have them read this thread. They are the only ones who could definitely confirm the deprecation of SHA-1 on certificates that involves windows update servers. Such a statement would confirm my findings, even though it would contradict the "Windows Server 2008 R2 SP1 and WSUS 3.0 SP2 are both supported until January 2020" statement from the product group. Only if the opposite was confirmed (i.e. SHA-1-based algorithms and certificates are not deprecated on windows update servers) I would have to worry about opening a support case.

    In addition, I do not know why my previous post is proposed as answer. Can you explain what answer is contained in that post? That "WSUS 3.0 SP2 running on Windows Server 2008 R2 SP1 will not sync anymore with windows updates?" Or "whoever gets into this situation should upgrade without looking for a remedy?" I am not too familiar with the rules of this forum so maybe that proposal simply means "there will be no further input from any MSFT person."

    Friday, January 27, 2017 12:10 AM
  • my WS2008R2SP1 WSUS has synchronised successfully with MUCatalog every day for the last 3 years.

    it did so again this morning without error (37 updates were sync'd)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, January 27, 2017 2:59 AM
  • my WS2008R2SP1 WSUS has synchronised successfully with MUCatalog every day for the last 3 years.

    it did so again this morning without error (37 updates were sync'd)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    This is good to know, thank you. Since I cannot get a clean installation of Windows Server 2008 R2 SP1 + WSUS 3.0 SP2 working (my WSUS 3.0 installation on Server 2003 also stopped working this month), this means that besides KB2938066, at some point you installed a hotfix/update that is not offered by default via Windows Update or maybe did a registry tweak somewhere to enable additional behavior. Any chance you could remember what you have done out of the regular updates?
    Friday, January 27, 2017 5:03 AM
  • This is good to know, thank you. Since I cannot get a clean installation of Windows Server 2008 R2 SP1 + WSUS 3.0 SP2 working (my WSUS 3.0 installation on Server 2003 also stopped working this month), this means that besides KB2938066, at some point you installed a hotfix/update that is not offered by default via Windows Update or maybe did a registry tweak somewhere to enable additional behavior. Any chance you could remember what you have done out of the regular updates?

    to my knowledge, have done nothing other than standard updates offered by MU/WU, and any specific WSUS updates like KB2938066.

    (I was also digging around the topic of TLS and ciphers for you, there was an update last year which added new ciphers, pushed the cipher order around a bit, which upset some of our older internal SSL web apps, but I didn't find any likely correlation to your symptom for that on. in case you want to follow it up, it's https://technet.microsoft.com/library/security/ms16-095
    and related;

    https://support.microsoft.com/en-us/help/3042058/microsoft-security-advisory-update-to-default-cipher-suite-priority-order-may-12,-2015 )


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Friday, January 27, 2017 6:21 AM
    Friday, January 27, 2017 6:17 AM
  • to my knowledge, have done nothing other than standard updates offered by MU/WU, and any specific WSUS updates like KB2938066.

    (I was also digging around the topic of TLS and ciphers for you, there was an update last year which added new ciphers, pushed the cipher order around a bit, which upset some of our older internal SSL web apps, but I didn't find any likely correlation to your symptom for that on. in case you want to follow it up, it's https://technet.microsoft.com/library/security/ms16-095
    and related;

    https://support.microsoft.com/en-us/help/3042058/microsoft-security-advisory-update-to-default-cipher-suite-priority-order-may-12,-2015 )


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    The "specific WSUS updates" that you installed are what I am after. Are there any to be installed other than KB2938066?

    In the meantime, I reinstalled Windows Server 2008 R2 SP1 and WSUS 3.0 SP2. Here are the steps I took and the observations I made at each step:

    1- Add Role wizard suggests that all available updates are installed before adding roles, so that's what I've decided to do.

    2- Out of the box, Windows Update does not work at all. This is because of the Windows Update Agent v7.5 that comes with Server 2008 R2 SP1 (wireshark trace indicates Agent v7.5 does not know to negotiate stronger cipher suites). Installing Agent v7.6 fixes the problem (at this point communication takes place using TLS1.2 via a cipher suite stronger than what Agent v7.5 was offering to windows update servers) and updates are offered from Windows Update. 

    3- There's IE11 among the offered updates, so I decide to install that by itself first and reboot.

    4- After IE11 is installed, I install the rest and reboot. This continues until Windows Update offers no more updates.

    5- Then I install the WSUS role. IIS role gets installed as well, with default selected options.

    6- At this stage WSUS version is 3.2.7600.226 and sync fails.

    7- I install KB2938066 and now WSUS version is 3.2.7600.274. Sync again fails.

    If you can point out some WSUS specific updates that you've mentioned, I want to give them a try and see what happens.

    PS: As you mentioned, the article you gave a link for does not seem to be related to my case. I can see the two reasons why: in my case, the necessary cipher suites are not being offered to windows update servers at all (i.e. the cipher suite ordering is not important at this stage) and WSUS does not know how to use the new ciphers until it is updated (i.e. even if the OS gets new capability, WSUS 3.0 SP2 does not know how to use it since it is based on .Net Framework 2.0).


    Saturday, January 28, 2017 12:31 PM
  • it's been some time since I built a fresh WSUS on WS2008R2, but when I did, these are the notes I made;

    built WS2008R2
    installed WSUS role (which also installs the IIS role)
    launched windowsupdate detection
    many updates were detected, including KB2720211
    installed all updates, excluding KB2720211, excluding IE11 upgrade
    restarted server
    configured WSUS products, classifications
    launched manual WSUS synchronisation
    confirmed KB2720211 still detected as Required on the WSUS
    manually downloaded and installed KB2734608
    confirmed WSUS server version had incremented from .226 -> .256
    confirmed WSUS console is correctly operational
    launched windowsupdate detection, still offered KB2720211
    manually downloaded and installed KB2828185
    confirmed WSUS server version had not incremented
    confirmed WSUS console is correctly operational
    launched windowsupdate detection, still offered KB2720211
    manually downloaded and installed KB2938066
    confirmed WSUS server version had incremented from .256 -> .274
    confirmed WSUS console is correctly operational
    launched windowsupdate detection, still offered KB2720211
    restarted server
    launched windowsupdate detection, still offered KB2720211
    installed KB2720211 via windowsupdate
    restarted server
    launched windowsupdate detection, no further updates are detected
    confirmed WSUS console is correctly operational


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Sunday, January 29, 2017 4:05 AM

  • The "specific WSUS updates" that you installed are what I am after. Are there any to be installed other than KB2938066?


    IIRC you should also install KB2828185 which is the latest (last?) cumulative update for WSUS 3.0 SP2. AFAICR KB2938066 is not cumulative.

    An update for Windows Server Update Services 3.0 SP2 is available (KB2828185)


    Rolf Lidvall, Swedish Radio (Ltd)

    Sunday, January 29, 2017 8:44 AM
  • it's been some time since I built a fresh WSUS on WS2008R2, but when I did, these are the notes I made;

    built WS2008R2
    installed WSUS role (which also installs the IIS role)
    launched windowsupdate detection
    many updates were detected, including KB2720211
    installed all updates, excluding KB2720211, excluding IE11 upgrade
    restarted server
    configured WSUS products, classifications
    launched manual WSUS synchronisation
    confirmed KB2720211 still detected as Required on the WSUS
    manually downloaded and installed KB2734608
    confirmed WSUS server version had incremented from .226 -> .256
    confirmed WSUS console is correctly operational
    launched windowsupdate detection, still offered KB2720211
    manually downloaded and installed KB2828185
    confirmed WSUS server version had not incremented
    confirmed WSUS console is correctly operational
    launched windowsupdate detection, still offered KB2720211
    manually downloaded and installed KB2938066
    confirmed WSUS server version had incremented from .256 -> .274
    confirmed WSUS console is correctly operational
    launched windowsupdate detection, still offered KB2720211
    restarted server
    launched windowsupdate detection, still offered KB2720211
    installed KB2720211 via windowsupdate
    restarted server
    launched windowsupdate detection, no further updates are detected
    confirmed WSUS console is correctly operational


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thank you very much for sharing your notes. I installed a new Windows 2008 R2 SP1 server and tried to follow the steps as best as possible. Here's what happened:

    1- Step 2 (installed WSUS role) is not possible right after OS installation anymore since the Windows Update agent that comes out of the box is no longer sufficient to talk to update servers (installing WSUS role involves getting the KB972455 package and running it. WSUS is not fully integrated into the Server 2008 R2 SP1 even though its installation is through the role mechanism). I got an error that says something along the lines of "cannot find the update". This is because windows update agent cannot download the WSUS installation package at this point.

    A manual installation of Windows Update Agent v7.6 is necessary to proceed.

    2- The step "configured WSUS products, classifications" is not possible until after WSUS is synced so I assume this step actually comes after the next step "launched manual WSUS synchronisation".

    3- The next step "launched manual WSUS synchronisation" failed. So I continued with "manually downloaded and installed KB2734608".

    4- Similar to what you observed, KB2720211 is still detected as required, even after KB2734608 and KB2828185 which are supposed to be cumulative. What is more interesting is that even though windows update thinks KB2720211 is required, the script at https://msdn.microsoft.com/en-us/library/windows/desktop/aa387290(v=vs.85).aspx combined with the latest wsusscn2.cab yields the result that KB2720211 is not needed. Go figure.

    5- Unlike what you have observed, installing KB2828185 increased the version from 256 to 262. This is correct per Anne He's reply in this thread.

    6- Towards the end, you have "launched windowsupdate detection, no further updates are detected" in your notes. I assume you installed IE11 right before KB2720211, even though this is not spelled out explicitly in the steps. I assume you installed IE11 since your notes indicate "no further updates are detected" at the end.

    Unfortunately at the end of these steps, WSUS still were not functional (unable to sync). However, I have noticed one issue while inspecting the wireshark traces: Even though WSUS never succeeds to sync, there are two distinct failure cases: In one case, WSUS initiates the communication with a "Client Hello" and MS update servers immediately close the connection with a TCP RST. In the other case, WSUS is able to negotiate a cipher suite successfully, but after "Server Hello" is done, WSUS tries to send another "Client Hello" and at this point MS update servers close the connection.

    This confirms my suspicion that configuration has been changing on MS update servers and depending on which server WSUS reaches, different events happen. Unfortunately the 2008 R2 server here could not get to an update server that WSUS has successfully completed a sync.

    If you do not mind me asking, could you let me know the IP of the update server that your Windows 2008 R2 SP1 can successfully sync? I would like to give it a try in order to isolate whether there's still something I need to do or this is a regional issue (i.e. your 2008 R2 server can get to update servers that it can talk to but mine can't).
    Monday, January 30, 2017 1:30 AM

  • IIRC you should also install KB2828185 which is the latest (last?) cumulative update for WSUS 3.0 SP2. AFAICR KB2938066 is not cumulative.

    An update for Windows Server Update Services 3.0 SP2 is available (KB2828185)


    Rolf Lidvall, Swedish Radio (Ltd)

    Thank you for the suggestion. I tried it but it did not help. Just in case, I installed KB2938066 after that but it did not help, either.

    There must be an update/hotfix somewhere that fixes this or your 2008 R2 SP1 server is talking to completely different MS update servers that allow it to sync with them. Let me ask you the same thing I asked Don above: Could you let me know the IP of the update server that your Windows 2008 R2 SP1 can successfully sync? I would like to give it a try in order to isolate whether there's still something I need to do or this is a regional issue (i.e. your 2008 R2 server can get to update servers that it can talk to but mine can't).

    Wireshark or any other ethernet sniffer should be enough. Even your router's log files could indicate which IP www.update.microsoft.com is resolving to in your case.

    Monday, January 30, 2017 1:38 AM
  • Sorry, I don't have 2008 R2 WSUS servers anymore. That's why I was so vague in my assumptions, I couldn't check.

    Rolf Lidvall, Swedish Radio (Ltd)

    Monday, January 30, 2017 7:56 AM
  • If you do not mind me asking, could you let me know the IP of the update server that your Windows 2008 R2 SP1 can successfully sync? I would like to give it a try in order to isolate whether there's still something I need to do or this is a regional issue (i.e. your 2008 R2 server can get to update servers that it can talk to but mine can't).
    I built this machine within Azure when I was still getting a grasp of Azure. I'll see if it's still parked up there, but not really sure if so, and, which Azure region I spawned it in, which may make a difference. Also, that it could now be terribly broken..

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Monday, January 30, 2017 7:57 AM
  • Hi TE, did you find a resolution to WSUS 3.0 SP2 not syncing on Server 2003. I am having exactly the same issue but interestingly, a year after you were experiencing this issue. Until recently it worked fine. Upgrading is not an option at this point in time.

    Holtan

    Tuesday, May 1, 2018 11:49 PM
  • Hi TE, did you find a resolution to WSUS 3.0 SP2 not syncing on Server 2003. I am having exactly the same issue but interestingly, a year after you were experiencing this issue. Until recently it worked fine. Upgrading is not an option at this point in time.

    Holtan

    I'm experiencing the same problem. WSUS 3.0 SP2 running on Windows Server 2003 R2 started to fail synchronization on April 20, 2018. It has not sync'd successfully since April 20. Sync works flawlessly for many years up to April 19, 2018. Nothing has changed on my part because I went on vacation a day before WSUS started failing sync.

    Here's the error:

    WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

    It looks like Microsoft is starting to refuse connection from Server 2003 machines. Is that correct?

    Monday, May 14, 2018 5:29 PM
  • Just want to give an update that KB948963 (hotfix) fixed my WSUS sync problem.

    https://support.microsoft.com/en-us/help/948963/an-update-is-available-to-add-support-for-the-tls-rsa-with-aes-128-cbc

    WSUS now synchronized successfully and picked up new (May 2018) updates.


    • Edited by morph2-7 Monday, May 14, 2018 6:13 PM
    • Proposed as answer by Hittin' Sunday, June 3, 2018 4:03 AM
    Monday, May 14, 2018 6:12 PM
  • Perfect works fine on scheduled synchronizations
    Sunday, June 3, 2018 4:03 AM
  • I can also confirm that installing the hotfix KB948963 on our Windows Server 2003 fixed the WSUS 3.0SP2 synchronization problem, which suddenly popped up for us in June 2018.
    Tuesday, September 18, 2018 10:32 AM