1

I don't use WSUS for SQL Server patching because we have so many different compatibility issues, requirements and downtime OLA's that it makes it impossible to deploy anything in this way - not sure of many who can to be honest.

However, we have a custom DBA 'app' that I would like to develop a snap-in for that alerts the team to any new updates released by Microsoft for SQL Server (SP's, CU's, Hotfixes etc.)

I thought, hey, let's just hook into the WSUS database, poll for new updates and display them on a web page if they exist...

It works to a fashion, but I noticed that there is a lot of missing updates in WSUS from SQL Server. For example I'm not seeing SQL Server 2014 SP2 CU1 in there which was released recently, 2014 SP1 CU7 is not there, but CU8 is. 2012 SP2 and SP3 are not their either, as another example.

We sync WSUS half-hourly, and all SQL Server products are selected.

Any idea why some SQL Server updates aren't coming through to us via WSUS? IS this normal? Do Microsoft not publish everything through WSUS?

2
  • Wouldn't it be easier to follow one of aggregating websites? sqlserverupdates.com for example has both RSS feed and and e-mail alerts for CU'ss and SP's. sqlserverbuilds.blogspot.com doesn't have those (at least I don't see it), but has history of releases.
    – Marcin S.
    Sep 6, 2016 at 13:35
  • 1
    Yes, but no fun! Seriously though we do use both those sites to keep track as part of general review cycles - I was just trying to do something different using WSUS and noticed the gaps which seem strange to me.
    – Molenpad
    Sep 6, 2016 at 15:04

1 Answer 1

0

There is a good Microsoft article about it. I had the same problem and Microsoft's solution fixed it:

Non-applicable SQL Server CUs are listed in WSUS, MU, or ConfMgr

Resolution

To fix this issue, manually download and install any SQL Server Cumulative Update that applies to the baseline build. After this is performed, the latest cumulative update that is released to Update will be listed as applicable.

More information

This behavior is by design. The system administrator can install a CU to determine the servicing branch that SQL Server should follow.

Each servicing baseline (RTM or a service pack) includes two servicing branches:

  • A General Distribution Release (GDR) branch that contains only Security and other Critical fixes.

  • A CU branch that contains Security and other Critical fixes plus all other fixes for the baseline.

Currently, the MU detection logic is constructed so that instances on a servicing baseline or along the GDR branch are offered the GDR branch.

Users have to proactively install at least one CU to align the instance to the CU branch. However, after this is done, you cannot return to the GDR branch until the instance baseline is either reset by moving up to the next Service Pack or all CUs for the baseline are manually uninstalled. If all CUs are uninstalled, this moves the instance back to the GDR branch or servicing baseline.

This logic helps to minimize the default number of changes that are required in the event of a Security or other Critical update. Instances that are on the CU branch must necessarily accept all updates in the event that a required Security or other Critical release is provided for the baseline. This includes all cumulative nonsecurity changes for the baseline up to the point of the required Security update.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.