SQL SERVER – Script Level Upgrade for Database ‘master’ Failed – The Server Principal Owns One or More Availability Group(s) and Cannot be Dropped

I have helped many clients in upgrade failures via my On-Demand consulting and I am amazed to see various ways that can break SQL Server upgrade. In this blog we would learn about fixing error Script level upgrade for database ‘master’ failed because of upgrade step ‘msdb110_upgrade.sql’.

Below are few earlier blogs which have other causes of the same error:

• SQL SERVER – Script level upgrade for database ‘master’ failed because of upgrade step ‘sqlagent100_msdb_upgrade.sql’
• SQL SERVER – Script level upgrade for database ‘master’ failed – There is already an object named ‘DatabaseMailUserRole’ in the database
• SQL SERVER – Script level upgrade for database master failed – Error: 4860, Severity: 16, State: 1 – Cannot bulk load. SqlTraceCollect.dtsx does not exist

This time it was a new error, so I am blogging it. As usual, I asked for ERRORLOG and was looking for the cause of failure.

Error: 15141, Severity: 16, State: 1.
The server principal owns one or more availability group(s) and cannot be dropped.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database ‘master’ failed because upgrade step ‘msdb110_upgrade.sql’ encountered error 15141, state 1, 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.
Error: 3417, Severity: 21, State: 3.
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.

The real cause of upgrade script failure is “The server principal owns one or more availability group(s) and cannot be dropped.”

WORKAROUND/SOLUTION – Level Upgrade

Whenever we have such an upgrade script failure issue and SQL is not getting started, we need to use trace flag 902 to start SQL which would bypass script upgrade mode. This would allow us the find the cause and fix it. So, here are the steps I have done.

As I mentioned earlier, first we started SQL with trace flag 902. I started SQL using trace flag 902 as below via command prompt.

NET START MSSQLSERVER /T902

For named instance, we need to use below (replace instance name based on your environment)

NET START MSSQL$INSTANCENAME /T902

Refer: SQL SERVER – 2005 – Start Stop Restart SQL Server from Command Prompt

As soon as SQL was started, we were able to connect because the upgrade didn’t run. We located “msdb110_upgrade.sql“ file under “C:\Program Files\Microsoft SQL Server\MSSQL14.SQL2017\MSSQL\Install” folder and executed it in SSMS. We got the exact same error.

Error: 15141, Severity: 16, State: 1.
The server principal owns one or more availability group(s) and cannot be dropped.

This was due to the drop login command in the script. The following statement was the cause of the failure.

IF EXISTS (SELECT * from sys.server_principals WHERE name = '##MS_PolicyEventProcessingLogin##')
BEGIN
    IF EXISTS (SELECT * from sys.server_triggers WHERE name = N'syspolicy_server_trigger')
        DROP TRIGGER [syspolicy_server_trigger] ON ALL SERVER
    DROP LOGIN [##MS_PolicyEventProcessingLogin##]
END
GO

We used the below script to figure out which AG is owned by the above account.

SELECT agrp.[name] AS availability_groups_name
	,agrp.group_id
	,arep.replica_id
	,arep.owner_sid
	,sp.[name] AS owner_name
FROM sys.availability_groups agrp
JOIN sys.availability_replicas arep ON agrp.group_id = arep.group_id
JOIN sys.server_principals sp ON arep.owner_sid = sp.[sid]

To change the ownership below is the command (you need to change the group name).

USE [master]
GO
ALTER AUTHORIZATION ON AVAILABILITY GROUP::SQLAG TO sa;
GO

After this, we stopped SQL Service and started normally (without trace flag). It worked well and the SQL version of updated. I am wondering why someone would change the ownership of AG to ##MS_PolicyEventProcessingLogin## account. If you know the reason, please share it via comments.

You can add me on Linkedin here.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Script Level Upgrade for Database ‘master’ Failed – The Server Principal Owns One or More Availability Group(s) and Cannot be Dropped