November 22, 2016 at 12:22 pm
I'm a bit confused about a recent security patch application. We applied the Security Patch KB3194722, but in looking at the server prior to this, the SQL Server version was:
Microsoft SQL Server 2014 (SP1-CU6) (KB3144524) - 12.0.4449.0
And now it's
Microsoft SQL Server 2014 (SP1-CU9-GDR) (KB3194722) - 12.0.4487.0
We're looking through the Windows logs to see if CU9 was accidentally installed, and we're not seeing anything. I'm probably wrong here, but I thought that version numbers didn't increment when only security patches were installed (or rather, the portion of the version number listed in parens, "(SP1-CU6) (KB3144524)", for example)? Even if they are, I definitely wasn't expecting the application of a Cumulative Update.
Anything you can think of for me to check, to further ferret out the reason for this change? Or to describe your experience on version numbers across solely applying a security patch?
Thanks,
--=Chuck
November 22, 2016 at 2:01 pm
chuck.forbes (11/22/2016)
I'm a bit confused about a recent security patch application. We applied the Security Patch KB3194722, but in looking at the server prior to this, the SQL Server version was:
Microsoft SQL Server 2014 (SP1-CU6) (KB3144524) - 12.0.4449.0
And now it's
Microsoft SQL Server 2014 (SP1-CU9-GDR) (KB3194722) - 12.0.4487.0
We're looking through the Windows logs to see if CU9 was accidentally installed, and we're not seeing anything. I'm probably wrong here, but I thought that version numbers didn't increment when only security patches were installed (or rather, the portion of the version number listed in parens, "(SP1-CU6) (KB3144524)", for example)? Even if they are, I definitely wasn't expecting the application of a Cumulative Update.
Anything you can think of for me to check, to further ferret out the reason for this change? Or to describe your experience on version numbers across solely applying a security patch?
Thanks,
--=Chuck
Out of interest, which o/s did this happen for?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
November 22, 2016 at 2:05 pm
Windows 2012R2.
Our latest suspicion is that someone inadvertently turned on Windows Update on the server. I'll let you know what we find out.
--=Chuck
November 22, 2016 at 2:18 pm
Looking at the MS pages for the KB, it looks like they might be flagging them as CUs now, possibly as a way to make it easier to see what updates are / are not installed on a SQL instance.
Of course, by treating them as CUs, this also means that (presumably) any updates in previous CUs *also* get applied as well.
When I recently updated my SQL instances (Some 2012s which got an update, some 2014s) they also increased the applied CU number.
November 22, 2016 at 2:21 pm
Oh, ok. So maybe not a Windows update. Hmmm...
November 22, 2016 at 10:38 pm
chuck.forbes (11/22/2016)
Oh, ok. So maybe not a Windows update. Hmmm...
Windows has it's own set of updates.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2016 at 8:43 am
The Network Team is still thinking that Automatic Windows Update was accidentally enabled on this server. Jeff, are you saying that even if that was the case, only the OS would be updated, and not SQL Server?
--=cf
November 23, 2016 at 9:00 am
chuck.forbes (11/23/2016)
The Network Team is still thinking that Automatic Windows Update was accidentally enabled on this server. Jeff, are you saying that even if that was the case, only the OS would be updated, and not SQL Server?--=cf
I share their suspicions, as I've seen some unexpected SQL Server updates go through recently.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
November 23, 2016 at 11:30 am
Phil Parkin (11/23/2016)
chuck.forbes (11/23/2016)
The Network Team is still thinking that Automatic Windows Update was accidentally enabled on this server. Jeff, are you saying that even if that was the case, only the OS would be updated, and not SQL Server?--=cf
I share their suspicions, as I've seen some unexpected SQL Server updates go through recently.
It's entirely possible it did come in through Windows Updates, depending on how things are configured. If you're using the local Windows Update, there's an option to receive updates for other MS products as well (which would include SQL Server.) If you're using WSUS for updates, then it may have popped up on their list to approve, which would then push it out to your server.
So, yes, check that Windows Update is not enabled, plus I'd suggest checking with the team that manages your Group Policy to make sure they didn't accidently enable it.
November 23, 2016 at 11:38 am
jasona.work (11/23/2016)
Phil Parkin (11/23/2016)
chuck.forbes (11/23/2016)
The Network Team is still thinking that Automatic Windows Update was accidentally enabled on this server. Jeff, are you saying that even if that was the case, only the OS would be updated, and not SQL Server?--=cf
I share their suspicions, as I've seen some unexpected SQL Server updates go through recently.
It's entirely possible it did come in through Windows Updates, depending on how things are configured. If you're using the local Windows Update, there's an option to receive updates for other MS products as well (which would include SQL Server.) If you're using WSUS for updates, then it may have popped up on their list to approve, which would then push it out to your server.
So, yes, check that Windows Update is not enabled, plus I'd suggest checking with the team that manages your Group Policy to make sure they didn't accidently enable it.
Bingo. I think it was our WSUS that did it.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply