Forum Discussion
Understanding SQL Server (on-premises) Updates
Are updates for SQL Server delivered via Windows Update?
I am looking at implementing a new patch management solution in place for our organization.
The products we are looking at leverage automation / control over the Windows Update Agent to perform this function.
I need to understand if I need to look for the specific ability to control the installation of SQL patches / updates with these solutions.
We have many versions of SQL Server across all companies - so understanding that how updates are delivered might be different between modern and more legacy versions.
I am finding the MS documentation unclear, so any comments are greatly appreciated!
- olafhelperBronze Contributor
David Levine , no DBA would like to get SQL Server uncontrolled updates via Windows LiveUpdate, because most databases/SQL Server are running in high availibilty = 24/7.
In common MS delivers only security updates (GDR) by LiveUpdates, not SP (service packs) / CU (Cummulative Updates), see
Updates to the Microsoft Update detection logic - SQL Server | Microsoft Learn
- David LevineCopper Contributor
olafhelper Thanks for the reply - the article you shared is what I am having trouble understanding.
We are not looking to use WSUS for patch management - we are looking at 3rd party RMM tools.
We have many SQL instances running many different versions (not just 2016, 2017, 2019, etc.)
So, when the article is talking about MU, that is referring to the WUA (Windows Update Agent)? As in this:
How Windows Update works - Windows Deployment | Microsoft LearnI certainly agree that a DBA will not want SQL patches to be deployed / installed without manual intervention. This is what I am trying to avoid, but understanding if there would be any SQL Server related updates offered by the Windows Update Agent. I want to be sure that - whatever RMM we use (Windows Update Orchestration tool) - I need to be sure that NO SQL updates get offered or approved automatically.
Thank you!
- LainRobertsonSilver Contributor
The Windows Update client is the same whether it's looking to Windows Update (aka the Internet delivery endpoint), WSUS (the on-premise endpoint), SCCM (hybrid tool for complex environments) or InTune (more focused on managing end user clients than servers, but it's still possible).
Underneath the hood of the Windows Update client, different providers can plug into its architecture, but that's transparent to the host and the user.
Ensuring that no SQL updates are automatically installed (the worst outcome) - or even advertised (the lightest touch outcome where precisely nothing changes on the server - not even pre-downloading) is a configuration item, not an inherent behaviour of the Windows Update client.
You get the experience you configure for it. Nothing more, nothing less.
Applying that configuration to your objective, which is to have zero SQL Server updates advertised, if you have configured your Windows Update client to point to Windows Update (the Internet service), you don't get fine-grained control over per product selection.
All of the other endpoints I mentioned above do allow you to select which product family updates you receive, meaning they can all include or exclude SQL Server on a per version basis.
You can take that further using computer groups such that different Windows Update client configurations exist for different sets of servers, meaning there's a fair amount of flexibility to be had (with management suites like SCCM being the most configurable of that bunch above).
Anyhow, you can select whatever tool you like as they'll work in a mostly similar manner if they're leveraging the Windows Update client as distinct from providing their own vendor-specific client.
Cheers,
Lain
- LainRobertsonSilver Contributor
Hi, David.
Windows Server Update Services works well if you're running an Active Directory environment - including in a hybrid configuration (not to be confused with Azure Active Directory (Azure AD) - particularly a native Azure AD environment, for which WSUS is unusable).
For enterprise deployments, you should do some reading on appropriate, scalable configuration and not just install the feature using the Windows feature wizard and "next, next, next".
On the client side, you specify the configuration using group policy, where you can control the various download and installation choices - of which there are a fair few.
Cheers,
Lain