A SQL Server update can install its new binaries and still fail when SQL Server starts and runs its database upgrade scripts. In a recent recovery, SQL Server 2019 CU32 failed at that second stage. The Database Engine would not start normally, and SQL Server Agent stayed stopped.

The blocker was a missing internal SSIS cleanup login. Recreating that login, reconnecting its existing database user, and restarting SQL Server normally allowed the pending upgrade scripts to finish. No database restore or SQL Server reinstall was needed in this case.

Update covered: SQL Server 2019 Cumulative Update 32 — KB5054833, build 15.0.4430.1. This is the update involved in this incident; it is not a claim that CU32 is the newest available update. Check Microsoft’s release guidance when choosing your patch level.

Recognize this specific failure

The SQL Server error log identified ISServer_upgrade.sql and error 15151, naming the missing login:

##MS_SSISServerCleanupJobLogin##

Errors 912 and 3417 followed, including a message about being unable to recover the master database. In this incident, those messages followed the failed upgrade script; they did not establish that master had been destroyed.

This repair applies when that server login is missing and the existing SSISDB user ##MS_SSISServerCleanupJobUser## needs to be mapped to it. Microsoft documents this condition in its SQL Server upgrade error 15151 troubleshooting article. Other errors or missing principals need their own diagnosis.

Recover after the update fails

The commands below are for a standalone Windows server with the default SQL Server instance. Use an elevated Command Prompt for service commands and a sysadmin connection in SQL Server Management Studio for SQL. Named instances have different service names.

1. Start SQL Server temporarily with trace flag 902

With the Database Engine stopped, run:

NET START MSSQLSERVER /T902

This temporarily bypasses the database upgrade scripts so you can connect and repair the blocker. Keep SQL Server Agent stopped during this work. Trace flag 902 is a recovery step, not a completed update or a normal operating configuration.

Before changing anything, preserve the error and setup logs and take fresh backups of master, model, msdb, and SSISDB, in addition to your user database backups. Keep copies off the server. Preserve applicable encryption keys and passwords securely. Verify the backups; a successful backup verification is useful, but a test restore is the stronger recovery check.

2. Confirm the missing login and existing user

Run these read-only checks. If SSISDB does not exist, stop: this SSIS catalog repair does not apply.

USE master;
SELECT name, is_disabled
FROM sys.server_principals
WHERE name = N'##MS_SSISServerCleanupJobLogin##';

SELECT DB_ID(N'SSISDB') AS SSISDB_ID;
GO

-- Run this next section only if SSISDB exists.
USE SSISDB;
SELECT name, SUSER_SNAME(sid) AS mapped_login
FROM sys.database_principals
WHERE name = N'##MS_SSISServerCleanupJobUser##';
GO

Our failed instance returned no server login, but the SSISDB user existed without a matching login. If your results differ, do not blindly create or drop accounts. Microsoft’s article also covers the separate missing-user case.

3. Recreate the login and map the user

For the confirmed missing-login case, run the following. Replace the password placeholder with a new, strong random password before executing it. These login options follow Microsoft’s repair example for this internal principal.

USE master;
CREATE LOGIN [##MS_SSISServerCleanupJobLogin##]
WITH PASSWORD = N'REPLACE_WITH_A_STRONG_RANDOM_PASSWORD',
     DEFAULT_DATABASE = [master],
     DEFAULT_LANGUAGE = [us_english],
     CHECK_EXPIRATION = OFF,
     CHECK_POLICY = OFF;
GO

USE SSISDB;
ALTER USER [##MS_SSISServerCleanupJobUser##]
WITH LOGIN = [##MS_SSISServerCleanupJobLogin##];
GO

The failed upgrade had also left our SSISDB in SINGLE_USER mode. Check its state:

SELECT name, state_desc, user_access_desc
FROM sys.databases
WHERE name = N'SSISDB';

If the failed upgrade left it in SINGLE_USER mode, return it to MULTI_USER:

USE master;
ALTER DATABASE [SSISDB] SET MULTI_USER WITH NO_WAIT;

If that command is blocked, investigate the connection holding the database before proceeding.

4. Restart normally so the upgrade scripts can finish

Run each command in sequence, waiting for the stop to finish before starting:

NET STOP MSSQLSERVER
NET START MSSQLSERVER

The normal start intentionally omits /T902. If you added -T902 as a persistent startup parameter through SQL Server Configuration Manager instead, remove it before this restart.

In our recovery, normal startup reran the pending scripts successfully. The installer window was already closed; reopening it was not required for this repair. Check the new SQL Server error log for successful script completion and recovery, not just whether the service briefly reports Running. If startup fails again, inspect the new error before taking another action.

5. Verify, then start SQL Server Agent

SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion;
DBCC TRACESTATUS(902) WITH NO_INFOMSGS;
SELECT name, state_desc, user_access_desc
FROM sys.databases;

For CU32, the engine build is 15.0.4430.1. Confirm trace flag 902 is off and the databases have their expected states and access modes. A trace-status result row with status zero means the flag is off; the row’s presence alone does not mean it is enabled. The build number alone also does not prove that upgrade scripts completed.

After those checks, start Agent, which resumes scheduled jobs:

NET START SQLSERVERAGENT

Check Agent’s log, application connections, and relevant jobs. Take fresh post-repair system database and SSISDB backups.

Prevent this particular failure before updating

Run the read-only login and user checks above before installing the update. If the login is missing and the SSISDB user exists, apply the same targeted login creation and user mapping while SQL Server is running normally. Repeat the checks and confirm that mapped_login resolves to ##MS_SSISServerCleanupJobLogin##.

A healthy server does not need trace flag 902 for this pre-update correction, and the login repair itself does not require a service restart. Do not create an SSIS catalog solely to perform this check. If the login already exists, investigate any mapping problem rather than recreating it.

Before patching, also confirm recoverable backups of both user and system databases, preserve required encryption material, test the update on a representative nonproduction instance where possible, and schedule a maintenance window. See Microsoft’s system database backup and restore guidance.

Correcting the missing login beforehand removes the blocker encountered here. It does not guarantee that an update will encounter no other issues. The key to this recovery was specific: restore the missing internal login, repair its user mapping, and let SQL Server complete its upgrade scripts during normal startup.