SQL Server 2012 Service Pack 1 & Cumulative Update 1

Recently, Microsoft pushed out Service Pack 1 for SQL Server 2012, and they quickly followed up with Cumulative Update 1 for Service Pack 1. The reason for this is that the service pack – due to longer development and regression testing cycles – did not contain any of the fixes from RTM Cumulative Updates 3 & 4. Since many people have waited – based on mostly speculative bias at this point – to even start testing SQL Server 2012 until Service Pack 1 was released, I thought it might be useful to cover a couple of the scenarios you might come across. This isn't strictly a performance-related post, but some of the information does involve service disruptions, which may or may not affect your business, SLAs, etc.

UPDATE – SQL Server 2012 Service Pack 1 Cumulative Update 2 (11.0.3339) was released 2013-01-24.

If SQL Server 2012 is not already installed…

When you are installing a new instance of SQL Server, you want to perform as few steps as possible. SQL Server 2012 setup is much better about slipstreaming both service packs and cumulative updates than SQL Server 2008 / 2008 R2 (described by Peter Saddow here and here). This method is deprecated, but it is still supported in SQL Server 2012. So while you can still use the old method if you wanted:

D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder

The new method, which you should be using, is much simpler – and doesn't require you to manually extract the packages using the /x argument first:

D:\setup.exe /Action=Install /UpdateSource=C:\AllUpdatesFolder

You just need to put all of the relevant updates in the same folder. Note that any update you get with the filename [...]_zip.exe, you need to extract out to get the core executable. For example, when you first download Service Pack 1 and Cumulative Update 1, the download folder will look like this:

You need to extract 455715_intl_x64_zip.exe by double-clicking on it and choosing the output path (using /x at the command line is valid, but ignored). Once done, the folder should end up looking like this. (At which point, you can delete the 455715... file – though given how "compressed" it is, I have to wonder why they continue to place this package in a self-extracting archive in the first place.)

Now when you run the above command line, when you get to the Product Updates screen in setup, you should see that it has included both SP1 and CU1:

Bob Ward does a very good job of describing this scenario in much more detail here:

CSS Blog : SQL Server 2012 Setup just got smarter…

Note that you can keep all of your Service Packs and Cumulative Updates over time in the same folder – if you use the /UpdateSource argument, SQL Server Setup will be smart enough to choose the latest SP and its latest CU, regardless of what else might exist in that folder.

If SQL Server 2012 is already installed…

Again, all of that information applies if you are installing a new instance of SQL Server. I, on the other hand, have a bunch of SQL Server 2012 RTM instances that I wanted to patch – and since I didn't want to lose any of the fixes from Cumulative Updates 3 & 4, I wanted to apply both Service Pack 1 and Cumulative Update 1. I was hoping that the same slipstream smarts would be built into the Service Pack 1 setup executable, so that it could simply include the CU1 updates. I tried the logical:

C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder

But this eventually yielded the following error:

For search engine goodness:

The setting 'UpdateSource' is not allowed when the value of setting 'ACTION' is 'Patch'.
Error code 0x84B40005.

(And yes, I tried putting the extracted CU1 update folder in a different location.)

I've confirmed with Microsoft that, while SP1 does obviously contain some of the code and logic from the core setup.exe, it hasn't been built to allow for the incorporation of Cumulative Updates. In other words, you can't slipstream when installing a service pack, only when installing the core product.

This also means that you will need to perform the installation in two steps. I opened a new Connect suggestion, since slipstreaming is arguably *more* valuable during servicing than during initial installation:

Connect #774109 : Allow /UpdateSource for Service Pack installers

So, I proceeded to do this in two steps. I installed Service Pack 1, and noted that no files were in use that might require a reboot:

And then once SP1 was complete, I launched the SP1 CU1 installer. However I came across this error:

So not only did I have to take two steps to apply these patches, I also had to reboot in between. I looked in the log files for each install (Detail.txt) and I can see that when I ran SP1, there was no indication that Windows was expecting a reboot:

(07) 2012-12-12 06:46:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=True

But then when I ran CU1 and got the error, only a few minutes after SP1 was complete, I saw in the new Detail.txt that now Windows *was* expecting a reboot:

(07) 2012-12-12 06:53:38 Slp: Windows Update requires a reboot
(07) 2012-12-12 06:53:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=False

I'm not sure what has happened, since I certainly did not go and run Windows Update between steps.

UPDATE: Thanks to Shau Phang at Microsoft, we discovered in %SystemRoot%\WindowsUpdate.log that an automatic Windows Update had started after SP1 had started, and finished before I started the CU update. I presume this is because I woke the computer up and dove immediately into starting the service pack install; the "must reboot" check must have been triggered in between. I would accept full responsibility for this if I had just turned on Windows Update and accepted the default; but I did not. Here are my settings:

So, be careful out there.

Conclusion

The moral of the story is, if you haven't yet installed SQL Server 2012, slipstreaming to get to the latest update in one action – regardless of when you get around to it, and what updates are available at the time – is going to be simple and painless.

If you already have an instance installed, in which case service disruption and downtime is almost always going to be a more critical issue than during a new install, you will need to approach your patching methodology carefully, and be sure that your maintenance window will allow for a restart of the server, should it be required. This also means: be aware of your Windows Update settings and whether any updates have been installed since the last restart.

If you think this is an important issue, please vote on these Connect items and, more importantly, comment on how the current scenario might affect your business.