Based on my first experience with the Product Update feature in Denali (SQL Server 11) CTP3, I’d have to say that “the third time is the charm”. This is the third version of SQL Server to provide a method for incorporating updates during an initial product install. Slipstreamed updates were first provided for SQL Server 2008 and also in SQL Server 2008 R2. I was really excited about that capability until I realized that in the large, global enterprise environment in which I worked that it caused more pain than it solved. I won’t go into all the details, but since we ran our installs over the network and from multiple data centers, slipstreamed source was not efficient for us due to our install methodology and the number of combinations of source we needed to provide to our customers. However, based on what I’ve read about the Product Update feature in Denali as well as the testing I have performed so far, this solution will provide exactly what we need to easily and successfully deploy installations with the exact updates we want at setup time.
There are three ways to incorporate the Product Updates for Denali:
- Windows Update / Microsoft Update
- WSUS (Windows Server Update Services)
- File Share
In an enterprise environment, you won’t find many servers with Internet access, so the first method, Windows Update, is probably out. Also, enterprise environments typically have specific deployment schedules for changing even initial installs to a new service pack level. So, even if your servers do have Internet access, I don’t see this option being used by large enterprises. But, I love this option for my home installs!
As for the second method, WSUS, this one might be an option pending how well your DBAs interface with the team supporting WSUS. However, considering the various requirements in an enterprise environment – there are valid scenarios where a “down-level” install is required. Thus, this method might be eliminated as it would always provide the most current approved patch level.
That brings us to the File Share method. At first glance, this looks like slipstream. However, in my opinion, it is an order of magnitude better than slipstream. Why?
- I can maintain a single RTM code base. This reduces my storage footprint.
- I don’t have to copy/merge any files from the update into my RTM code base. This reduces potential for errors in translating what to copy/merge.
- I can specify the location of the updates using either a direct local path (e.g. C:\SQLUpdate) or a UNC name (e.g. \\SourceServer\SQLUpdate). This increases my installation methodology flexibility.
- I can have multiple update folders to choose from (e.g. \SQLUpdate\V11.Update1 versus \SQLUpdate\V11.Update2, etc.). This increases my ability to support varying customer version requirements.
With the File Share method, you simply add the /UpdateSource parameter to your
setup.exe command and tell it where that source resides.
Local Drive Source example:
setup.exe /Action=Install /UpdateSource=C:\SQLUpdate\V11.Test
Network File Share Source example using a local computer variable to designate the source server name:
setup.exe /Action=Install /UpdateSource=\\%Src%\SQLUpdate\V11.Test
When running setup using the command above, you’ll get the dialog shown below. You can see that the designated product update at the UNC location will be included in the installation.
It’s as easy as that!
But, what if you don’t want any updates included during installation? That is easy, too. Just add the /UpdateEnabled=False parameter to your setup command. By default, this parameter’s value is True. And, finally, these parameters can always be incorporated into a configuration ini file, so that you can initiate the whole install unattended, but that’s a topic for another day.
If you’d like to test out the Product Update feature for yourself, check out these links for obtaining, implementing and commenting on the Denali CTP3 Product Update feature: