Upgrades reset service account user to local from domain account

Brice

I have an issue where installing updates causes the service account to change from a domain account to a local account. I have not be able to resolve this issue as of yet. The result is all server monitor connections fail. So before I release alerts I need to make sure this is updated.  Any one else having this issue? If you have, what solution did you employ? Also can I run the service with a GMSA account? 

Alex B

Hi @Brice,

The reason the change occurs is because when you use SQL Server authentication to connect to the data repository it automatically sets the base monitor service to be run as Local System.  This happens because the service is being uninstalled and reinstalled using the credentials provided in the installer - but when SQL Auth is used, you can't provide credentials for the service, only the data repo connection and so it uses Local System.

If you were using AD auth (or a gMSA) in the installer to connect to the data repository, it would run the service as that user (and so on future updates as long as you kept using AD auth it would keep using that user for the service).

This is something we are aware of and there's some discussion internally on how best to handle it, but unfortunately that is the way it currently functions, so when using SQL Authentication, you will need to reset the service to use the AD auth user you had previously set it to use.

Kind regards,
Alex

Brice

I will verify that we are using a SQL account to connect to the SQL instance. I was sure we had been using an AD account. Once I can verify this. I will either mark this as answered or provide more information. 

Brice

Alex B said:

Hi @Brice,

The reason the change occurs is because when you use SQL Server authentication to connect to the data repository it automatically sets the base monitor service to be run as Local System.  This happens because the service is being uninstalled and reinstalled using the credentials provided in the installer - but when SQL Auth is used, you can't provide credentials for the service, only the data repo connection and so it uses Local System.

If you were using AD auth (or a gMSA) in the installer to connect to the data repository, it would run the service as that user (and so on future updates as long as you kept using AD auth it would keep using that user for the service).

This is something we are aware of and there's some discussion internally on how best to handle it, but unfortunately that is the way it currently functions, so when using SQL Authentication, you will need to reset the service to use the AD auth user you had previously set it to use.

Kind regards,
Alex

I was able to confirm that we had in fact been using a SQL user instead of an AD account. I just applied the latest update and changed it to use an AD account. Once that was done. I had no issues with the service account retaining the user information. As the connection account is the same AD user as the service.

Thank you for the assist.