Slipstreaming Updates Into a New Install

Installing SQL Server and then patching it straight away costs you an extra restart and an extra hour. Slipstreaming updates applies the cumulative update during the install itself, so the instance starts life at the patch level you chose.

What Slipstreaming Updates Does

A normal base install starts with the files on the original SQL Server media. You then run a CU package as a second operation. Slipstreaming integrates the selected update into SQL Server Setup. The result is one installation workflow with the update applied as the instance is built.

This approach saves a second patch pass and can avoid an extra operating system restart. It can also work around known setup issues in base media when the CU contains the relevant fix. It does not remove the need to test. Setup still changes services, shared components, and machine state.

Use it for a new instance, not as a substitute for a rolling patch plan on an existing availability group. The production topology determines how existing instances are serviced. A fresh build in a lab is the easiest place to learn the syntax.

Choose the Exact CU Package

Start with the target SQL Server major version and the approved CU. Read its release notes and verify that the package applies to the media, architecture, and features you plan to install. Do not assume that a file named “latest” still contains the version you tested last month.

Record the package name and expected ProductVersion in the build ticket. Keep the downloaded package in a controlled local folder. Verify its integrity using the publisher’s documented hash or signature process. Do not mix several candidate CUs in the UpdateSource folder. A clean folder makes setup behavior easier to explain.

If the application team has certified a specific build, use that build. A surprise package replacement during installation turns a tested build into an untested one. The convenience of slipstreaming should strengthen consistency, not weaken change control.

Point Setup at the Update Folder

SQL Server Setup supports UpdateEnabled and UpdateSource parameters. Set UpdateEnabled to True and point UpdateSource at the local folder holding the selected update package. Use the Setup executable from the SQL Server installation media. Include Action=Install so Setup performs the installation action.

I keep one folder per approved CU and nothing else in it. Setup is very happy to pick up whatever update it finds, including the one somebody dropped there last spring.

The following example launches an interactive install. Replace the paths with your approved local media and update folder. Confirm that setup detects the intended CU before completing the wizard. Do not silently accept a package from an unexpected folder.

If you automate the full install, keep all required Setup parameters in a reviewed configuration file. Avoid placing service account passwords in plain text scripts. Run the automation on a disposable test VM first, then compare the resulting build and features with the design.

REM Command line
C:\SqlMedia\setup.exe /Action=Install /UpdateEnabled=True /UpdateSource="C:\SqlUpdates"

Check Setup’s Choice

Read the setup summary after installation. It reports the operation, selected features, and component results. If Setup did not apply the CU, investigate UpdateSource, package compatibility, and the logs. Do not patch later and still call the result a verified slipstream. The distinction matters for reproducing the build process.

I read the setup summary line by line after every slipstreamed install. It takes two minutes, and it is the only proof the update was really included.

Connect to the running Database Engine. Query ProductVersion and ProductUpdateLevel. Compare the full version with the official build expected from the selected CU. Also inspect the SQL Server error log for startup issues. The actual running instance is the final check.

A host can have more than one instance. Make sure your connection targets the instance you just installed. Record the instance name beside the version. A successful setup summary for one instance does not prove a neighboring named instance changed.

SELECT
    @@SERVERNAME AS ConnectedInstance,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel,
    SERVERPROPERTY('Edition') AS Edition;

Remember Shared Features

SQL Server Setup can install components beyond the Database Engine. Some shared features have servicing details that a Database Engine version query cannot show. Review the setup summary and installed feature list. If Analysis Services or Integration Services is part of the build, test those components directly.

Adding a feature later can introduce a patch mismatch if the team uses base media without the same update plan. Keep the chosen media, CU package, and configuration file together in the build record. Future feature additions should follow a documented servicing step.

I also check SQL Server Agent, service startup type, network configuration, and firewall rules after installation. Slipstreaming handles update integration. It does not decide whether the new server meets your operations standards. Finish the normal provisioning checklist.

Test Slipstreaming Updates With a Rebuild, Not Just an Install

A repeatable build is the real benefit. Run the install in a test VM, capture logs, discard the VM, and rebuild from the same media and script. The second build should land on the same ProductVersion with the same intended features. If it does not, your process depends on an unrecorded choice.

Have you ever rebuilt a server from your own build notes? Almost nobody has until the day they have to.

Restore a sample database and run an application smoke test. Check backups and Agent jobs after provisioning. A correct CU level can coexist with missing logins or a disabled job. New server acceptance includes the full operational setup.

Record elapsed time from your own test if it matters to the migration window. Do not assume a universal time saving. Hardware, selected features, and restart requirements vary. The practical gain is one controlled setup path with fewer separate actions.

Keep the Procedure for Slipstreaming Updates Current

When a new CU is approved, update the package folder and expected build in the script or runbook. Retest the build. Do not let a reusable installer quietly pick up whichever file happens to be newest. A pinned package is easier to audit and troubleshoot.

Archive the prior build record for servers that still run it. An installer procedure is a versioned operational artifact. The team should know which server came from which media and CU. That helps when a later setup issue affects only one group of machines.

Slipstreaming updates is simple once the inputs are controlled. Select the CU, give Setup its source, verify the running build, and retain enough evidence to repeat the result.

Related reading on this blog: What a Cumulative Update Actually Contains and How to Check Your SQL Server Version, Edition and Patch Level.

Slipstreaming is not a shortcut around testing, it is a cleaner way to build the version you tested.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.