Patching is breaking the Master Database of SQL Server Installed

Question

Hello,

I am operating Microsoft SQL Server 2019 Enterprise Edition within our environment. One of our SQL Server instances, which is hosted on a virtual machine (VM), has SQL Server Integration Services (SSIS) installed. We’ve encountered a recurring issue during patching operations on this server.

Each time the host is patched, the SQL Server instance fails to start. The root cause appears to be tied to a failed upgrade process involving the MS_SSISServerCleanupJobLogin account. Specifically, the error message indicates that the login lacks sufficient privileges, which results in a failure to upgrade system objects in the master database. Consequently, SQL Server does not start, and the failure is logged in the Windows Event Viewer.

To troubleshoot the issue, I reverted to a pre-patch snapshot of the VM and created a clone of the SQL Server instance to serve as a test environment. On the cloned instance, I explicitly granted the necessary permissions to the MS_SSISServerCleanupJobLogin account. I then re-applied the patch to the clone, and this time the patch was successfully applied without any errors.

However, I observed that the permission changes made on the cloned instance unexpectedly propagated to the production instance. This raises concerns about the underlying isolation between the two environments.

I am seeking clarification on the following:

Is the patch failure solely attributable to insufficient privileges assigned to the MS_SSISServerCleanupJobLogin login, or could there be additional underlying factors that need to be addressed?

Under what circumstances would changes made on a cloned SQL Server VM reflect back on the original (production) instance? Could this be related to shared virtual disks, improper cloning, or some other configuration issue?

Answer 1

The patch failure is indeed caused by insufficient privileges on the MS_SSISServerCleanupJobLogin account once you granted the correct permissions, the patch applied fine, which confirms it. Still, I’d recommend also checking other system logins or jobs that might need permissions, as missing privileges can sometimes cascade during upgrades.

On the cloning issue, changes should never flow back to production. If they did, it usually means the VM was cloned with linked/shared virtual disks or snapshots weren’t handled correctly, so both VMs ended up pointing to the same underlying storage. To avoid this, make sure you’re creating a full independent clone with its own disks and that system databases are not on shared storage.

[Moderator: removed plug for third-party product which is not relevant here.]

Answer 2

I just stumbled on this post after this long. The issue was resolved over 3 months ago by providing the right permissions to that account. Thank you all for your respective inputs.

Answer 3

I can't really speak to any of the issues, but I post nevertheless.

When it comes to the first issue, the sad story is that although I am known as an SQL Server expert, I have never worked with SSIS. I have SSIS installed, but I don't have this login. I guess this is a login you get when you set up SSISDB (which I have not). I doubt that Microsoft would create the account with insufficient permissions, so if the account is missing required permissions, I'm inclined to suspect that someone locally has gone on a lockdown craze and removed one permission too many. Whether that could be more reasons involved, I can't say, as I have no knowledge about that update step. (There is another, more general, update script which is known to cause issues every now and then. But this script does not refer to ##MS_SSISServerCleanupJobLogin##.

For the second question, that is a question you would need to ask in a forum related to your virtualisation product. Although, without further knowledge, I am inclined to blame human intervention.