Menu Close

Security changes in SCOM 2019 – Log on as a Service


You need to know about this.  Yes, there will be a test later.  Smile

One of the changes in SCOM 2019 is increasing the out of the box security configuration.  Previous versions of SCOM not only allowed, but *required* the “Log on Locally” user right for SCOM service accounts and RunAs accounts.  This has changed in SCOM 2019.

The default configuration on SCOM 2019 Management Servers, Gateways, and Agents, is that service accounts and RunAs accounts will now leverage the “Log on as a Service” user right, and no longer require “Log on locally” user right.  This means that in order for any RunAs account to work, Log on as a Service is now *required*.

When you install SCOM 2019, the setup program automatically configures this for accounts you specify during setup.  You can review this by opening the Local Security Policy > Local Policies > User Rights Assignment > Log on as a service:


You can read all about this change here:

One of the FIRST places you will notice a challenge, is pushing agents.

When you push an agent, and provide the credential that will query AD then connect to the remote agent and push it, you are actually spinning up a local MonitoringHost.exe process under that credential to do the Agent Push.  This works the same as a typical RunAs account, and ANY account you want to use here will require Log On As A Service.

What you might notice is a failure to “find” the agents you are trying to deploy:


You will see an alert generated when this happens:   Run As Account does not have requested logon type

You will also see the management server go into a warning state


This is all telling you that the account you provided, even if only temporary for agent deployment, must also have the Log on as a Service Right.  For this reason, if you want to do a lot of agent pushes from the console, you should grant your Global Group in AD for SCOM Admins to have Log on as a Service on ALL Management servers.  I will show what this looks like here:


You will need to restart your management server after making this one time change for it to take immediate effect.

My Global Group in AD for all my SCOM Admins and service accounts is OPSMGR\OM_Admins, and once I grant “Log on as a service” on ALL management servers, restart the management server, and run the agent discovery wizard:


Keep this in mind, on ALL traditional RunAs accounts, this will be required with SCOM 2019 agents.  In previous versions of SCOM, the Log on locally (interactive) user right was required, however in most scenarios customers would simply ensure that RunAs accounts were a member of the Local Administrators group, and Local Admins inherited the Log on Locally user right.  That is NOT TRUE for Log on as a Service as this user right must be explicitly defined.  Therefore, if you use traditional RunAs accounts in SCOM – you need to prepare and test for this improvement in security, as it will require changes to your process to ensure RunAs accounts have the minimal rights required to work.

Again, I recommend you review the product documentation on this subject here:


  • SCOM 2019 agents and management servers (by default) will use the “Log on as a service” user right, and will need to be granted that.
  • SCOM 2016, 1801, and 1807 Agents will leverage the “Log on locally” user right by default, and will need to be granted that right.

This can be configured via policy, if you wish to modify it.  For instance, you can switch SCOM 2019 agents to use Log on locally, or switch SCOM 2016 agents to leverage “Log on as a service” via:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service
  • Worker Process Logon Type (REG_DWORD)
  • 2 = Log on locally
  • 5 = Log on as a service


  1. Artūras Radzys

    Hi Kevin,

    any idea what about DMZ/Workgroup servers? Run as service account should be administrator or? Have pushed agent update to all servers now have this alert from each agent, wondering if there is a way to set SCOM admins log on as service from SCOM Console or I need to use something like SCCM or GPO? If now out of the box solution then it is kind of sad

    • Kevin Holman

      Domain RunAs accounts never worked on workgroup machines – so nothing changes.

      It does not matter if the agent is in a DMZ, remote Forest, or local Forest – any RunAs accounts will need log on as a service, this new security model was an important and necessary change.

      You can use GPO to set your accounts to have Log on as a service rights.

      I am considering writing a MP that will automatically append the user rights for accounts that need it…. I assume you think that would be helpful?

      • Artūras Radzys

        That would ease the procedure very much. Using GPO might be tricky sometimes because it would overwrite all customization that were done through the years on different servers

  2. Artūras

    As a fix I have created task in SCOM that is running .bat file that is triggering ntrights.exe +r SeServiceLogonRight -u domain\SCOMadmins. Placed .bat file and ntrights.exe to \\domain\netlogon share. After this one is set had to use “flush Health service state and cache” task from SCOM Console>operations manager>againt details> agent health state> agent state

  3. Patrick Boulanger

    There is a workaround to restore the old behavior in case you want to buy time for testing. On the client computer, there is a local Gpo where you can set the logon type to Interactive Logon:
    -Local Computer Policy\Computer Configuration\Administrative Templates\System Center – Operations Manager\Monitoring Action Account Logon Type
    – Set the logon type to “Interactive”

    With the monitoring agent from a previous version (1807 – 8.13053.0), the help state “The default logon type is Interactive”
    With 2019 (10.19.10014.0), help says “The default logon type is Service logon”.

    You can also set with the registry key:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service]
    “Worker Process Logon Type”=dword:00000002

  4. Benny

    I have a question on this.
    When i read this my conclusion are the following:

    The (LOG ON AS A SERVICE) userright should be set to the (OM-ADMIN) group only on the SCOM Management servers.

    The thing is i have done that, BUT! When i trying to enable Audit Collection on a server with a SCOM Agent with an action account who is a member in the OM-ADMIN group , it fails.
    The message in the EventLog on the server with SCOM agent that i trying to enable ACS for, is that my Action Account missing the userright (LOG ON AS A SERVICE).

    So the question is do i also have to give the userright LOG ON AS A SERVICE to the OM-ADMIN group on all the servers with SCOM agents?

    I really hope the answear is NO, but if why am i getting this?


    • Kevin Holman

      Any time you run an agent task on an agent, and provide an alternate credential to run the task – that credential MUST have Log on as a service, because we spin up a monitoringhost.exe process under that credential to complete the task.

      So yes – this would require you configure that first on agents where you need to run tasks as anything other than the default agent action account or a pre-defined and configured RunAs account.

      My question to you – is why are you using an alternate credential? The default agent action account should be able to run almost anything on the local box, assuming you are using local system for the default agent action account.

  5. Benny

    In our case we use alternate account for tasks because almost everything we do in the environment must be done with an account who belong to a specific user. The policy says that we can not use a functional account for specific tasks. Yes its kind of weird/hard i know, but it´s the fact.

    • Kevin Holman

      In that case you need to allow log on as a service for the accounts you want to use on agents, OR switch your SCOM 2019 agents to go back to the legacy method – which does not require Log On As A Service, and uses Interactive Logon (Log On Locally) which is by default inherited by Local Administrators.

      Either way – you have to configure security on the agent – the old way simply worked because Log On Locally right was granted to Administrators group, while Log on as a service is not.

      If you use my management pack – the task will fail the first time – then work after that, because my MP will append the Log on as a service right to any account that failed to log on in SCOM due to this restriction.

  6. Benny

    Ok i will sure look at your MP Kevin.

    We have an old SCOM 2012 R2 environment today that in the end should be replaced by SCOM 2019.
    For a while the SCOM environments will run at the same time and our thougts was that all agents should report to both environments with the new SCOM 2019 agent. I guess this could be a challange when there is different methods, i mean legacy method SCOM 2012 R2 and not for SCOM 2019.

    The method for switching SCOM 2019 agents back to the legacy method can you tell me what steps that includes?
    If we do that, is it possible then to have the new SCOM 2019 agent to report to both environments for a while?

  7. Benny

    Ok i saw now that PATRICK BOULANGER wrote the method for Legacy mode earlier in this thread.
    But general question remains if it is possible for a SCOM 2019 agent to report to both SCOM 2019 and SCOM 2012 R2 MGMT groups under a short time? No problems with not supported, but works. But if the answear is NO it would not work at all, then we have to change our plan.

  8. Chris

    Hi Kevin, I’m assuming this affects SCVMM integration as well? I have an account that I use in VMM to connect to OM, do I need that account to be able to Login as a service on my monitored VMS/Hyper-V Hosts?

    • Kevin Holman

      It affects any SCOM workflows, running as a SCOM RunAs account, under the MonitoringHost.exe process. If VMM is connecting to SCOM via the SDK – then no. If there are SCOM workflows running that use a SCOM RunAs account and connect to VMM – then yes.

      • Chris

        Thanks Kevin! Must be the later – I just updated and I’m getting runas errors and its the account I specified in VMM for the PRO integration

  9. Echo Frank Delta

    This is why come budget time I am moving my company AWAY from SCOM. They cant leave a good thing alone and they cant fix whats been broken since 2012


    • Kevin Holman

      In my opinion, this change is a GOOD thing and makes the product more secure. And we allow it to be set back to the “old way” for people who have trouble changing/adopting the better, more secure model.

      • Ganesh

        Yes, this change is a GOOD thing, I agree because, using 2012 R2 with allow log on locally rights pushed to be in TIER 0 architecture due to security reasons.

        But SCOM 2019 addressed it, hence we have a plan to upgrade.(fingers crossed)

Leave a Reply

Your email address will not be published. Required fields are marked *