When you install a CU or a GDR, Setup runs a script msdb110_upgrade.sql which does a lot of things, and of which some certainly are questionable. And if this script fails, you are in trouble.
This is where things go wrong:
2025-06-19 19:51:29.47 spid15s Error: 15138, Severity: 16, State: 1. 2025-06-19 19:51:29.47 spid15s The database principal owns a schema in the database, and cannot be dropped. 2025-06-19 19:51:29.47 spid15s The failed batch of t-sql statements :
-- Do not recreate the user for Managed instance (EngineEdition 8). -- Recreation of the existing login does not happen for MI, so we don't need to recreate the user. IF EXISTS (SELECT * from sys.database_principals where name = N'##MS_PolicyEventProcessingLogin##') AND SERVERPROPERTY('EngineEdition') <> 8 DROP USER [##MS_PolicyEventProcessingLogin##]
I see that this is on a virtual machine, so the best may be restore a backup of the VM, if there is one before the upgrade. When you have restored in run:
USE msdb
go
SELECT * FROM sys.schemas WHERE principal_id = user_id('##MS_PolicyEventProcessingLogin##')
Review the schema in question and drop it or make dbo the owner of it.
If you cannot restore the VM, you can add trace flag 902 as a startup parameter to SQL Server. This instructs SQL Server not to run the upgrade script. Once you have cleaned up the schema for ##MS_PolicyEventProcessingLogin##, remove the -T902 startup option again, and restart SQL Server. Hopefully, the upgrade script now completes successfully.