Allow /UpdateSource for Service Pack installers

Allow /UpdateSource for Service Pack installers by aaronbertrand

Active

Type:	Suggestion
ID:	774109
Opened:	12/12/2012 4:33:28 AM
Access Restriction:	Public

Workaround(s)

view

Currently /UpdateSource allows you to minimize the number of steps to take to get fully patched when you are laying down a *brand new* instance of SQL Server.

This doesn't help reduce steps if you've already installed the product and want to apply, say, SP1 and SP1 CU1. /Action=Patch and /UpdateSource are incompatible switches, so what you must do is install Service Pack 1, then install Cumulative Update 1 separately.

To add insult to injury, you must perform a restart in between these two steps, even in the case where the file checker during SP1 setup does not find any files in use that would require a restart.

Slipstreaming for the core product during an initial install is great, and a massive time-saver. But I would argue that slipstreaming during a service pack installation is even *more* important, because downtime during servicing or maintenance windows needs to be as minimal as possible. Since SP1 requires a reboot before applying CU1 (see https://connect.microsoft.com/SQLServer/feedback/details/774111/cumulative-update-requires-a-restart-after-sp1-install), this is certainly going to be critical for a lot of businesses where downtime is an issue.

I also blogged about these issues here:

http://www.sqlperformance.com/2012/12/system-configuration/sql-2012-slipstream

Details (expand)

English

Setup

Embed the same smarts in the SP installers that exist in setup.exe for the core product.

Improved Administration

Quicker patching, fewer steps.

0 attachments

Posted by Gregory.Stigers on 3/27/2013 at 10:43 AM

I found this linked from SQL Server 2012 Service Pack 1 & Cumulative Update 1 http://www.sqlperformance.com/2012/12/system-configuration/sql-2012-slipstream when trying to figure out why I couldn't get /UpdateSource to work with SP1. Definitely would love to see this where a CU is released close to the SP. 2008 R2 SP1 was published July 11, 2011. CU1 was July 24, and CU2 was August 31 before the pace slowed down. If that happens for 2012 SP2's CUs, we need this feature

Posted by Leo Pasta on 2/26/2013 at 4:35 AM

Especially with issues like http://support.microsoft.com/kb/2793634 which is present on SP1 and fixed on subsequent CU, having an "update slipstreamed" option would allow to upgrade an existing RTM instance to SP1 without risks: http://rusanu.com/2013/02/15/registry-bloat-after-sql-server-2012-sp1-installation/

Posted by RobNicholson on 2/3/2013 at 9:16 PM

I agree also. Slipstreaming the initial install is great but slipstreaming an SP would be greater as it reduces the time required for maintenance of production systems.

Posted by Microsoft on 1/7/2013 at 2:31 PM

Hi Aaron, thanks for taking the time to submit this feature request. We'll take this into consideration for the next major release.

thanks,
[SQL Server Team]

Posted by TheSQLGuru on 12/12/2012 at 6:06 AM

I STRONGLY AGREE that once a SQL Server is up and running there should be no need to separately install sequential updates and there should almost NEVER be a reason to require downtime to patch.

Posted by Gregory.Stigers on 3/27/2013 at 10:22 AM

We save ourselves one restart between updates by providing /SkipRules=RebootRequiredCheck to the CU setup