SQL Server 2012 SP1 CU1 Installation Failure – Resolved

So I was recently installing SQL Server 2012 on a couple of new machines and ran into the following error when attempting to apply SQL Server 2012 SP1 CU1:

Error during SQL Server 2012 SP1 CU1 Update

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.

This causes the SQL Server installation not only to be incompletely upgraded (Data Quality Services, Full-Text and Semantic Extractions for Search, SQL Server Replication, Database Engine Services fail to be upgraded), but also renders the entire database engine instance unable to start as the master database cannot be upgraded. Major bummer!

After a bit of digging around, it became apparent that a temporary choice I had made during the initial installation of SQL Server 2012 was the root cause, although in my professional opinion it’s a bug and I’ve submitted a Connect Issue with a provided workaround. Hopefully MS will fix the issue, but since the workaround exists, who knows.

The root cause for this error condition is security permissions for the SQL Server service accounts. During installation I chose to leverage the new for 2012, virtual accounts, which are the default configuration option mind you (although I don’t intend and wouldn’t recommend using these over correctly permissioned Domain Accounts). Essentially, the NT Service\MSSQLServer did not have appropriate permissions to access file system level objects to apply the required scripts to upgrade the master database or the other features that fail.

The workaround here is to simply set the service account to LocalSystem for the duration of the Service Pack/Cumulative Update installation and then setting it back to the virtual account (better yet to a domain account with appropriate permissions permanently).

My biggest concern here is that Microsoft has chosen for the default service accounts during installation to be based on these virtual accounts that later will render the SQL Server instance unusable until you find this post or Microsoft fixes the issue.

Later,

-Patrick