Home Dashboard Directory Help

SQL Server 2012 SP1 CU1 installation failure + Instance will no longer start by PatrickPurviance



Sign in
to vote
Type: Bug
ID: 775401
Opened: 12/28/2012 12:13:27 PM
Access Restriction: Public
User(s) can reproduce this bug


When attempting to apply SP1 CU1 to SQL Server 2012 Enterpise 64bit, the CU installation fails to update the following Features:

Data Quality Services
Full-Text and Semantic Extractions for Search
SQL Server Replication
Database Engine Services

To make matters worse, as a direct result of the last feature upgrade failure, the SQL Server instance itself will no longer start due to permissions failures regarding scripts that must be run against the master database prior to startup post update application.

The following is found in the SQL Server Error logs for the subsequent service start attempts:

Script level upgrade for database 'master' failed because upgrade step 'u_tables.sql' encountered error 25641, state 0, severity 16. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

A workaround has been found and documented in this Connect Feedback, but this situation could occur rather frequently for anyone installing SQL Server using the default settings (typical for developer or end user installations where no DBA supports the environment) and then later wants to apply service packs and cumulative updates. Essentially the user is painted into a corner that renders their SQL Server Database Engine unusable because it will not start under these conditions.
Sign in to post a comment.
Posted by RobNicholson, MCSM on 9/16/2013 at 8:51 PM
This happens on 2012 SP1 CU5 as well.
Sign in to post a workaround.
Posted by PatrickPurviance on 12/28/2012 at 12:19 PM
One simple workaround is to change the service account from the virtual account (NT Server\MSSQLServer) to Local System, which is a member of the local admin group on the server for the duration of the Cumulative Update 1 installation. This works because the Local System account has local admin privs and thus is able to run the required scripts against the master database. After changning this service account the installation completes and the instance is again operational. Then the service account can be set back to the virtual account (or better yet a correctly permissioned domain account).

Either way, it's not good to have the default installation options for SQL Server 2012 paint users into a corner like this, effectively making the use of the defaults cause an inoperable instance down the road.