SQL Server 2012 – CUs are Inevitable (T-SQL Tuesday #29)


This T-SQL Tuesday is being hosted by Nigel Sammy. Enjoy.

Ever build a Slipstream install of SQL Server?  All that manual cut and move and pasting of little binary files here and there and everywhere it seems. Always felt so hands-on. Always wondered if it would actually work. Always had to update the thing.

Don't get me wrong it was a HUGE time saver if you were building several servers in the shop, but it did take a bit of extra time and testing. This was also a bit of a hidden feature. Not intentionally hidden, but not as well known as you would think. I know of a LOT of DBAs that are blissfully unaware of this installation option/technique. Bit of a shame.

Product Update

SQL Server 2012 improves and extends the Slipstream concept by adding Product Update functionality right into the SQL Server installation process.

Product Update is on by default and has the ability to search Microsoft Update, use Windows Server Update Services, or a folder or network share for SQL Server updates.  Any updates found get integrated into the setup process. No more building Slipstream installations. No more running the install and then the SP and then the CU. No more forgetting entirely to install service packs and updates.

By default SQL Server 2012 install will use Windows Update on the client and using its configuration (either Microsoft Update or WSUS) find whatever is the latest update; Service Pack, cumulative update (CU), or whatever combination of these is the latest patch level for SQL Server.

But what if you don't want the latest CU? What if the latest is not approved for use yet in your organization? What if I need to install the RTM? Never fear there are always choices.  If you just run the setup without changing a thing it will use Windows Update to retrieve any updates either from WSUS or Microsoft Update and if any exist the install will stop and list all the updates it has found and allows you to opt out of the updates entirely. What about that second scenario? What if your organization very carefully approves updates and has a prescribed CU level for all SQL Servers? Then as each CU is approved for use it should be downloaded and placed in a common network share. Then SQL install can utilize the new UpdateSource parameter to search in the specified network share for SQL updates.

The Product Update feature by default is enabled and uses the client's Windows Update settings.  If you wish to either disable Product Update entirely or you wish to seek updates from a folder or network share then you will need to specify input parameters to the setup process.

There are two parameters;

  • /UpdateEnabled=True|False - allows you to turn off the Product Update feature
  • /UpdateSource="MU"|local folder path or UNC path containing downloaded updates

There are three ways to specify input parameters for SQL Server 2012 setup;

  1. Command line installation
  2. Place the parameters in a ConfigurationFile.ini and start the install from the command line specifying that configuration file
  3. Modify the DefaultSetup.ini file in /x86 or /x64 folder at the root of the installation media

Which you choose will have a lot to do with your organization. If everyone uses the same installation media, modifying
DefaultSetup.ini may be the best choice.  If everything is scripted, placing the parameters right in the script or in a configuration file used in the script may be the best
choice. 

Not many updates for SQL Server 2012 yet <wink> but this new feature has the potential to streamline your installation process, reduce the complexity of your SQL Server
installations and reduce the risk of updates not being applied properly.

More can be found here.

Comments (2)

  1. Rob says:

    I find that Product Updates take away some of the features that were in slipstreaming. For instance in my organisation we sometimes need to install service pack N-1 when adding a new server to a cluster or in a DR situation.

    With slipstreaming I can just set CUSOURCE/PCUSOURCE to the correct folders and it will install the correct SP and patches. From what I understand with Product Update the choice is either the latest SP on your WSUS/MS update/network share location or nothing.

    In the case of installing SP N-1 you would have to install the RTM build then patch manually which slows a build down considerably.

    Please tell me if I'm wrong but that is my understanding of how this new feature will work

  2. Rob, Many many organizations work just like yours and trial and then approve SP and patches. You will be able to supply the folder containing the SP and patches that you wish to include using the /UpdateSource = parameter.

Skip to main content