For many years, I’ve been pushing for a way for our SQL Server setup to “fix itself” or “get smarter”. What I mean is that I’ve always wanted a way for setup to detect if any fixes are available online to apply as part of running the original installation. Consider the scenario where you are going to install SQL Server 2012 now that it has been released for several months. Wouldn’t it be nice to take advantage of avoiding any problems that might have been found with setup since its release? Why wait and have to hit a problem someone else has encountered but has been fixed. Furthermore, if setup has been enhanced in any way to prevent problems (think setup consistency checks), why not get to use these as well. As I started to promote this concept within Microsoft, it took on the moniker of “Smart Setup”. Many people both in the product team and CSS then contributed over the last year to make this reality happen.
The concept was first launched with SQL Server 2008 with a feature called Patchable Setup. In addition, this capability included a method to “slipstream setup", but the process was very manual.
Now comes along a new feature for SQL Server 2012 called Product Update which can take advantage of the Microsoft Update Service.
Product Updates from Microsoft Update
I thought it would be interesting if I run through the experience in this blog post and make a few comments along the way. First, I’ll show the experience when you use the defaults of just “running setup” which is to look for updates from Microsoft Update. After that, I’ll show you how to point setup to update packages you have downloaded.
I’ll start the setup experience from the License Terms screen to show you what screen comes up right before the detection of updates. In this scenario, I just ran setup.exe. I didn’t pick any special command line parameters.
If there are updates found online, you will now get a screen like this one. Since SP1 just shipped, setup has detected that SP1 Setup Updates are available to apply as part of the initial product installation.
Notice the “Name” is called “SQL Server 2012 Setup Update”. This means that setup has automatically detected an update for SP1 but the update is only for setup fixes not for the entire SP1 package. Observe the size is only 14Mb. I’ll discuss later in this post how to apply the entire SP1 update. The main reason we chose to only post setup changes for SP1 when automatically detecting updates is the sheer size and time it would take to auto update setup with the full SP1 package.
if you click on the article listed in the More Information section, you will see a SP1 “fixlist” article.
Unfortunately we don’t have our SP1 setup fixes listed in this article at the time I’m writing this blog post but are working on an update.
If you select “Learn more about SQL Server product updates”, you will be sent to the documentation that references the Product Update feature.
Once you hit the Next button, you will be shown a screen for the installation of the setup files. This is the same screen you would jump to if no product updates were detected.
Once you complete this process and go through other setup screens, you can see that Product Updates are being applied as part of setup on the “Ready to Install” screen.
Once setup is complete, you can see that you have installed SQL Serve 2012 RTM + SP1 Setup updates by looking at the version of programs installed on your server.
While the overall “version” of SQL Server 2012 SP1 is 11.0.3000.0 we actual bump up the “minor” version field for the Setup Program.
Providing a location for Product Updates
What if though you wanted to run setup and apply product updates for the entire SP1 package instead of just the setup updates? And perhaps you want to apply SQL Server 2012 SP1 CU1 as well while you are at it. SQL Server 2012 setup comes with two new command line parameters /UpdateEnabled and /UpdateSource.. /UpdateEnabled takes a value of TRUE (default) or FALSE. You could use this parameter on its own to disable SQL Server Setup from automatically checking for updates online. /UpdateSource allows you to tell the setup program where to look for updates vs looking for them on Microsoft Update. (Note the value of “MU” is the default and means to update from Microsoft Update). The source can be any valid file path including local directories or UNC paths. Note the source is a directory not the package file names. There can be other files in this directory. Setup will look for packages it knows can be applied for SQL Server.
To demonstrate this, I download the SQL Server 2012 SP1 update package to a downloads folder on the server where I am installing SQL Server. I also copied down the SQL Server 2012 SP1 CU1 package as well to this same folder (NOTE: The CU package comes as _zip.exe file. You must run this .EXE to extract out the true .EXE package first).
Here is a screenshot of the downloads folder:
Now I ran setup..exe from the install media (in this case it was on a network share for me) with the following syntax (this was from PowerShell):
.\Setup.exe /Action=Install /UpdateSource="c:\Users\Administrator\Downloads"
NOTE: A few syntax comments:
- Quotes around the path are optional (at least this was the case in PowerShell)
- You don’t have to specify /UpdateEnabled=TRUE when using /UpdateSource
- The parameter is case insensitive. So for example, you can use /UPDATESOURCE
- Specifying /Action=Install makes things go faster as you skip the landing page screens
When you now get to the Product Update screen it will look something like this:
When you hit Next you get a similar screen as before except the Step to download setup files is Skipped
Now you will go through the same installation screens as before. When you get to the “Ready to Install” screen you will see a difference in the Product Update details:
The Product Update feature allows you to “slipstream” install a new setup or new instance along with updates such as service packs and cumulative updates. It also allows us to post setup fixes on Microsoft Update and allow you to apply them if you just want to take advantage of any setup fixes we discover as we progress through the lifecycle of a product.
We will start to look into what setup fixes and rules we can put into future cumulative updates so that as we produce a new cumulative update, the setup fixes can be placed on Microsoft Update to help keep setup "updated” all the time with the latest set of fixes.
I look forward to see how this technology can improve the user experience of setup and reduce the number of problems customers can encounter when installing the product.
I want to personally thank Shau Phang from the SQL Product team who is a PM working on this project and who patiently answer my questions along the way in building out this blog post.