Update on WSUS 3.0 SP2 End of Life


As you may have seen, there has been an update to the extended support lifecycle for WSUS 3.0 SP2 (WSUS 3.2).  We received feedback that ending this product's life in July 2017 would cause a significant disruption for those Windows Server 2008/R2 deployments that planned to rely upon it until January 2020.  As such, the end of life for this product is now January 2020.

For those that currently rely on WSUS 3.2, please use this extension as an opportunity to plan a smooth transition to WSUS 4.0 (Windows Server 2012 or 2012 R2) or even our newest offering (Windows Server 2016) that will be available later this year.  Especially for larger businesses, migrating a WSUS hierarchy is nontrivial, and may take much of the extra time that has been granted for this operation.  We've assembled a collection of resources that will help inform your migration efforts; should you have any trouble with the process, feel free to reach out on our TechNet forum for assistance.

Finally, it bears repeating: if you plan to deploy Windows 10 your environment, yet are still using WSUS 3.2, then we strongly recommend considering a migration sooner rather than later.  WSUS 3.2 cannot today and will not in the future be able to fully support Windows 10 servicing (specifically feature updates), and in order to experience the true vision for Windows as a service, you'll need to use WSUS 4.0 or later.


Comments (15)

  1. Anthony says:

    I find this interesting that Microsoft seems to want to stop support of a core component of an intergrated feature of a OS that has an end of life in the future.
    This is the trouble when you start baking in features into the OS but don't want to keep supporting them. Sorry but you have to! Next time think about making the features true add ons that have their own installers and not enbedded in the OS.

    1. Actually, Anthony, it's not baked into the OS: if it were, then the lifecycle discussion would have been much simpler (as it is with Windows Server 2012/R2). The rub here is that WSUS 3.0 started as an external feature only downloadable via Download Center, and at some point a hotfix allowed you to make this appear as a role in Server Manager. That hotfix was included in Windows Server 2008 R2 SP1, which provided an appearance that the products had merged, when in fact they hadn't.

  2. Hackers says:

    "As such, the end of life for this product is now January 2020"
    wisdom won!

  3. Steve,

    I wonder if you can correlate the above "WSUS 3.2 cannot today and will not in the future be able to fully support Windows 10 servicing (specifically feature updates)" with the reality of today. I recently noticed that Windows 10 1607 Pro clients.... which of course had to be updated to 1607 without WSUS 3.2... are also unable to receive a cumulative update like KB3194496 through the prroper channels. In my description of the problem at https://social.technet.microsoft.com/Forums/windowsserver/en-US/3042ede5-0a4c-452c-915a-432dd86eb593/wsus-settings-ignored-on-windows-10-1607-client-downloads-kb3194496-directly-from-m?forum=winserverwsus I noted that the client ignores the WSUS server and pulls this particular update directly from Microsoft servers.

    This is not a "feature update" we are talking about. So in that linked thread I asked many questions about whether this is intended behavior or if this is something that can be stopped. To me, this was a test that went very bad. I was surprised that I've got a client that checks WSUS for some updates, is updated via WSUS, and on the next reboot decides to report 100% to WSUS.... only to clandestinely bypass WSUS to get KB3194496.

    This may be a Windows 10 or KB3194496 issue, but it bears repeating that the above statement doesn't cover what just happened during my test of Windows 10 clients on the Anniversary Update.

    It almost seems like this is going to be a surprise to you... and you may need to discuss this with the Windows 10 folks that are pulling updates and ignoring WSUS. The Server 2008 R2 in question, running what you call WSUS 3.2, is oblivious to the problem. I stumbled upon it on accident when I logged in remotely and saw Windows Update at around 40% slowly increasing. WSUS says the client just checked in minutes ago as 100% updated.

    1. This might be the Dual Scan behavior that I covered in today's blog post. Feel free to let me know if that doesn't address your scenario.

  4. Gemma says:

    Will WSUS 4.0 run on Windows 2008r2 server?

    We only have Windows 2008r2 servers in our business. Are you saying we need to have Windows 2012 server to support WSUS 4.0?

    1. No, WSUS 4.0 will not run on a platform other than Windows Server 2012/R2. These server products contain WSUS as a server role, rather than a separate product. If you're going to migrate to a new WSUS server, then we recommend Windows Server 2016 because it helps you avoid many of the complications discussed in the past year with WSUS.

  5. The Windows Internal Database used by WSUS 3.0 SP2 on Windows Server 2008 R2 is based on SQL Server 2005 which is no longer supported. Is the WID component of Server 2008 R2 still supported, and if so, is there an official document stating that it is, in fact, supported?

    The problem is that WID is being flagged by vulnerability scanners as being an unsupported version of SQL Server 2005. I need official documentation to prove that this is a false positive and won't require corrective action.

    This is for a federally-regulated institution, and such documentation will be necessary if it is indeed a false positive.

  6. TE says:

    Maybe the decision has been changed back and WSUS 3.0 SP2 + Windows Server 2008 R2 SP1 is no longer an option as of January 2017:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/498082a6-db94-4e44-83a4-ac4c6c15e527/wsus-30-sp2-not-syncing-anymore-sha1-or-tls-10-deprecated-already

    1. No deprecation has taken place yet: both TLS 1.0 and SHA-1 are still supported, though we always negotiate across client and server for the latest protocol available to both endpoints.

  7. danielam98 says:

    I've installed WSUS 2016, clients could not get updates if changed to port 80 by usecustomwebsite=false. Any suggestion? In addition, the report still needs to install SQL CLT version 2012 and Report Viewer version 2012, the latest version of them could not work.

    1. WSUS deliberately uses 8530 (for non-SSL) because it is not likely to be in use by anything else on the system. Why do you need to change it to port 80?

      Yes, the report viewer requirements are still based on relatively old technology. Even newer .NET versions do not cover this functionality. Once you install the older Report Viewer version, does everything work as expected?

  8. Elb says:

    Can a WSUS Server running on Windows Server 2016 support Windows Xp and Windows 2003 servers? I know that Microsoft has stopped releasing security updates for Windows Xp and Windows 2003. However I want to make sure that when Microsoft does release an adhoc critical security updates for Windows Xp and Windows 2003, the WSUS 2016 server is able to provide the patch management functions to the Windows Xp and Windows 2003 servers.

    1. Yes, WSUS on WS16 is capable of managing every version of Windows. This does not guarantee that any content will be released on the WSUS channel for a given platform, but assuming that it is (as in the recent one-off release for Windows XP), WS16 will do the job as needed.

      To the point: you gain nothing in terms of down-level machine management by staying back on old versions of WSUS.

Skip to main content