You need to know about this. Yes, there will be a test later. 
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: https://docs.microsoft.com/en-us/system-center/scom/enable-service-logon?view=sc-om-2019
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:
https://docs.microsoft.com/en-us/system-center/scom/enable-service-logon?view=sc-om-2019
Recap:
- 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
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
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?
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
Its worth noting if you do set a GPO and as you say overwriting years worth of config simply disabling the GPO will restore the old config for local policy.
That would be helpful for any domain that doesn’t use a gpo to lock down log on as a service.
Yes, that would be helpfule
Thanks for the update. Too bad this isn’t the gmsa support, but it’s still good.
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
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:
-gpedit.msc
-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
Just saw your refresh your post with the same finding. You can dismiss my last comment. Thank you.
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?
/Benny
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.
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.
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.
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?
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.
Hello Kevin. Are any changes in 2016/19 in modules/mp authoring ? Something helpful ?
Tnks
No, not really. Most core base modules are the same. Some differences in Linux log file monitoring.
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?
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.
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
Hi Kevin,
This article is very helpful in 2019 verssion. I have one query, my linux/unix machines are not domain joined. i am using local accounts to monitor. is these accounts required logon on as a server accounts in scom 2019,
Hi Kevin,
This article is very helpful in 2019 verssion. I have one query, my linux/unix machines are not domain joined. i am using local accounts to monitor. is these accounts required logon on as a service accounts in scom 2019,
Hi pls,
if install agent on server is action account better local system or domain account ?
I prefer always using Local System for the default agent action account.
thank you for answer,
and if scom monitor domain controller. you prefer local system too ?
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
Ridiculous
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.
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)
Hi Kevin
I’m a big fan of your SQL Addendum mp, but i have trouble getting it to work in SCOM 2019. The SID monitor works fine, but when i am running the “Create Health Service as SA role” task, i get “Run As Account does not have requested logon type”. Both on the target machine and management servers, my account has “Log on as a service” permissions. Do you have any idea what could cause this error? Thanks!
Had the same issue, but i forgot to restart the healtservice on the target after i added my account to logon as service.
Hi, we built up a new SCOM 2019 environment. At first we installed the agents with our service Action Account but then you wrote, you prefer to use local system. So we do.
Our Action account has the right log on locally.
Now i get a warning from one of my Management Server: Run as accounts cannot log on locally, i thought i dont need it anymore.
Any suggestions?
Thanks alot
someone mentioned this earlier, but I did not see a response. if you start granting log on as a service rights via GPO, it replaces the current list with the list in your GPO, rather than appending the current list with the list in your GPO. I just checked one of my Dev servers, and its local GPO has granted “log on as a service” to 14 IISAPPPOOL\[account] and four domain.com\[custom service account]. and these accounts would be different on pretty much every server in my domain, and I bet we don’t stop adding new services to servers with new service accounts running them. so is GPO really a practical way of granting this permission outside of a scom test lab?
and here is the answer. https://kevinholman.com/2019/04/07/scom-2019-log-on-as-a-service-management-pack-helper/
🙂
Hi Kevin,
It’s not totally clear to me. I get the problem with deploying agents. I also experienced that the discovery goes wrong, and after adding our SCOM Admins group to the Log on as a service right, the discovery did work.
But I don’t really see what I need to configure for the agents. I’ve deployed several agents, and they are all healthy. Without me configuring any account in the Log on as a service right on those agents. In what scenario do I need to do that?
Raoul
You would ONLY need to configure something on an agent, IF you were USING a run-as account on that agent for something. This is incredibly rare. Very few MP’s leverage run-as accounts on agents. You will see this more commonly on SharePoint, SQL, and some Skype servers.
How do you setup run as account for logon as a service on domain controllers ? I am getting the “The Run As account must have requested logon right.” for all of my DC’s. I was planning to setup the run as account with the logon as a service setting in a new GPO and apply it to Domain Controller OU, so the default domain controller policy is intact. Is this the best practice to setup the run as account on Domain controller. Are there any other options? Please advise.
I never use RunAs accounts on DC’s. Why would you? I recommend Local System for the default agent action account and not really using RunAs for anything.
The agent is installed on the DC and running under the local system account, but the AD Replication monitoring rule needs a run as account. What should I specify under the Run as account for AD MP account profile ? Please advise.
I do not use RunAs accounts for replication monitoring. I believe those were only needed if you DIDN’T use LocalSystem as the default agent account.
We recently upgraded to 2019 and are now running into this problem. We used to perform Discovery and Installation with a Domain Admin account, but due to other security requirements, those accounts are all Denied the Logon as a Service right. We granted the action account explicit Logon as a Service right, but it is not a member of the local Admins, so it cannot perform the install.
So, I have tried to perform the install using a local computer account that is in the local admins by checking the box for “This is a local computer account, not a domain account” in the Discovery wizard. This also fails, and the logs on the target server very clearly indicate that it is trying to use a Domain account, not a local account for the install. Is that check box not working, or am I missing something? I’d rather not have to add the action account or some other new domain account to the local admins on all of our servers just to complete the agent install.
The right thing to do is grant Log on as a service to your Administrator’s accounts (Domain account) that need to be able to push agents. These accounts had local Administrator rights AND log on locally rights previously, now all we need is a MUCH lesser right of log on as a service. Granting that should be simple and should not impact any good security posture. Allowing that account to have log on locally and local administrator (which was previously required) is much worse.
Using a local computer account attempts to use Local System on the management server, which will not work… as you found out – because that account by design APPEARS to all others at a domain account in the form of DOMAIN\COMPUTERNAME$. That isnt SCOM, that’s how Active directory works.
Bottom line – you need an account that had the Log On As A Service right on the SCOM MANAGEMENT servers, and has Local Admin rights on a targeted agent machine to be able to deploy agents. The best practice is to use individual user accounts that are the SCOM admins to do this, and never use a shared account/service account for this purpose as that is impossible to track “who” did it. If you cannot make that work, then you need to use some other system to deploy agents, like software distribution via SCCM or similar. Many of my customers in highly secured environments have ZERO issue with Log on as a service on the management servers, the issue is that in a properly secured environment, there is NO easily accessible account that has local admin rights on ALL agent managed machines…. therefore they must use an approved software distribution mechanism, like SCCM, Puppet, etc.
This is all fine and dandy if the agent targets are in the same forest/domain as the SCOM infrastructure. I have several trusted domains that I manage in a single management group now, in 2016, but can’t get the agent installation / discovery wizard to discover and deploy agents to a foreign/trusted domain. How would my scom admin user in DomainA use the wizard to deploy an agent on a server in DomainB without giving all my SCOM admins the right to logon as a service in all domains?
Kevin,
Thank you for your response. I get what you are saying about the accounts and rights and will look into addressing it that way.
However, I don’t see it behaving the way you described in the second paragraph. The text for the check box on the fourth page of the discovery wizard sounds to me like it’s going to use a user account on the target computer for the install, not the AD computer account. I don’t see any log entries for “mydomain\computeraccount” on the target system either. I DO see log entries for “mydomain\useraccountname” where I was expecting “localhost\useraccountname”
I can send screenshots, if you would like.
Hi Kevin,
We are moving to Tier 0 model for AD, so if i install agent on AD server, is agent action account should not be local system as per the model and not allowed to use local system account.
So can tried to use domain account.(Healthservice not starting).
Kindl advise on this approach.
Hi Kevin , I am pretty new to the IT field , so basically whenever an agent is deployed to a server that needs to be monitored via discovery on SCOM, we have to make sure that the account on the server has the appropriate log on as service right? My question is that what if there are over 2000 servers, we have to go to each one individually and manually change the setting?
We deployed agents to 4 servers yesterday for testing , but I keep getting the event 7002 “log on service not enabled” error message, and for some reason when I go to change the action account in the Administarions> run as profile setting for those specific servers my whole system crashes. Instead of using our account that we specified for scom admin, the agents keep using the Local system account, so I was trying to change that.
Any suggestions ? Thanks a ton
You likely need to get some more experience with SCOM and security in general…. and understand these ramifications. First, I’d say you SHOULD be using Local System as the default agent action account for ALL your agents. Period. Next, if you are getting 7002 events, the important part of that event is “what account” is alarming? This means there is a RunAs account configured somewhere, and distributed to this system. That’s likely bad. My first question that MUST be answered and understood is “why” is that account attempting to run on that agent? In general, the use of RunAs accounts should be very limited, and only to a small number of MP’s and server roles.
Most of the time, the only reason these accounts are running on agents, is because the previous SCOM admins didn’t understand SCOM, SCOM security, or best practices. They would do BAD things like set a RunAS account to “less secure” which makes it run on ALL agents, or they would associate RunAs accounts with RunAs profiles which was completely unnecessary. In the WORST cases, I’d see customers use the SAME action account for their SCOM servers, AND all their agents…. which is just begging to be compromised.
Bottom line:
1. Set all agents to use Local System as the Default Agent Action Account.
2. Look at any 7002 events and see which accounts are causing the problem.
3. Look at your RunAs accounts (Windows) and ensure they are all set to “more secure”.
4. Look at your RunAs accounts (Windows) and examine their distribution and ensure this is correct, necessary, and by your design.
Then – if you DO need to manage setting these accounts to allow log on as a service – no, you don’t need to log on to each one…. I have provided an automation solution to handle this for you. But DO NOT just implement this to make the noise go away – get your environment secured properly FIRST!
https://kevinholman.com/2019/04/07/scom-2019-log-on-as-a-service-management-pack-helper/
Hey Kevin, appreciate the very detailed response what you said about using Local System account, I could not find anywhere in the Microsoft documentation , they should put those details in there or I am probably just very blind. The 7002 events mentions the account that we are using.
I went ahead and checked agents too, and they all are using this “bad” account. If I set all agents to use Local System as the Default Agent Action Account, I would have to give the LocalSystem the “log on as service” user right , right, as you mentioned above. Also the Local System account you mentioned is the one for Windows right the one that I should set for agents? And that looks like an amazing Management pack. Thank you once again.
You do not have to grant Log On As A Service to local system. Only for other RunAs accounts, or when using some domain account as the default agent action account.
So your task is to look at the account in the 7002 events and see why it is attempting to log on to your agents.
The event viewer says Health Service could not log on the RunAs Account for management group because it has not been granted the “Log on as service right” , thats why I am guessing the agents fall back to using Local System account. We use that “bad account” to deploy the agent. I guess I should set all agents to Local System account and then download your management pack. However we did put that “bad” account with the right you mentioned above on the Management Server, so my question is why would it still say does not have “log on as service right”
Has anyone managed or documented on how you enable Active Directory integration with a managed service account? This appears to have been overlooked by all forums I’ve searched so far. I’m getting the “MomADAdmin failed to map the user” error when attempting to use a managed service account.
This is weird, I´m back at work after vacations and when I left in early July all worked fine.
It seems ok almost everywhere in the SCOM console, except for:
In the Scom Management management pack. In Healthservice all nodes look ok, green and beatyful.
The same in Healthservice watcher, all green and ok.
But in Scom agents, and in Scom servers the nodes are Not Monitored and only has the green ring.
I updated the management pack to the latest but no difference.
I have checked the security and Run As accounts, I use the domain action account in OM admins as default action account on the Management servers, and local system on all the agents.
I also use local system on the SQL server as a Run as account.
I really don’t see whats has gone wrong here, and hoping some of you all could help me further.
Thaks in advance.
/Roger
That’s by design. Those classes do not have any monitors targeting them. Its always been that way.
Haha, so my memory is playing games with me then.
Thanks for that clarification.
/Roger
Kevin, i think yous should add a link here to your other post “SCOM 2019 Log On As A Service Management Pack Helper” which helped me alot.
I also would like to add a tip to https://www.catapultsystems.com/blogs/scom-monitor-reset-script/
Hello, what about monitoring Failover Cluster. I can see that, performance log and event log readers not enough. I ve got “cluster discovery warning”. Tried to add read access to cluster using grant-clusteraccess -user -readonly, but this not helped.
This doesn’t have anything to do with that as you really shouldn’t use a runas account for cluster monitoring. You should just use the default action account which is local system.
Hi Kevin,
This article is very helpful in 2019 verssion. I have one query, my linux/unix machines are not domain joined. i am using local accounts to monitor. is these accounts required logon on as a server accounts in scom 2019,
Hi,
Apologies if I have missed this in the comments, but just want to check I am understanding this correctly…
If we do NOT push deploy agents from SCOM and we use (generally) local system when installing all agents, then we do not need to configure this on our agents? I am reading from this that only if we needed to perform a task (or anything) on an agent using a different Run-As account to the default action accounts, that we would need to add THAT Run-As account to allow Log on as a Service?
Just preparing for 2019 now and engaging with AD Team to confirm any new requirements for our SCOM accounts across the agents, and wanted to make sure I am understanding this correctly.
Thanks
Your summary is correct.
If you do not use RunAs accounts on agents, and use Local System as the default agent action account, then there is no need to configure log on as a service rights.
Push deployment doesn’t really have anything to do with Log On As A Service on the agent. If you push agents from the SCOM console, Log on As A Service is required for the SCOM admin user accounts doing the pushing, on Management Servers.
Perfect, thanks Kevin. Our AD Team will be happy (and one less thing for me to cover off) 🙂
I think this needs an update to say all management servers AND gateways. I was unable to perform agent updates on nodes using a gateway until I performed these steps of adding the AD group to the log on as a service on the gateways as well.
That’s true. The majority of customers do not apply agent updates via GW because they are usually deployed for the purpose of untrusted domains.
Thanks Kevin,
We now using SCOM 2012 R2 and installed new SCOM 2019 RU3 (Side By Side Migration), When we are trying to install 2019 agent on server that already has 2012 r2 agent we received the below error
The Agent Management Operation Agent Install failed for remote computer MY-SCSMMS01.mcm.local. Install account: MCM\scomaction
Error Code: 80004021
Error Description: The operation attempted is not supported.
so do we need the action account to be run as a service on the target server to be able to install the new agent ?
Unfortunately – upgrading from SCOM 2012R2 to SCOM 2019 is not supported. This is called out here: https://docs.microsoft.com/en-us/system-center/scom/deploy-upgrade-overview?view=sc-om-2019
This upgrade attempt wont work from the console. However, it will work if you use something like a command line install and SCCM to upgrade the agents.
The last part of the article is not clear for me:
“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)
5 = Log on as a service”
I have SCOM 2016 Agent reporting to SCOM 2016 Management Server.
The registry key “HKLM\SOFTWARE\Policies\Microsoft\System Center\Health Service” does not exist on the Agent.
I have created it and I have created the “Worker Process Logon Type” value with decimal value 5.
After restarting the HealthService and distributing a RunAs Account to the agent – it still logs an event saying that the RunAs account does not have logon locally right. Also the monitor which should use the runas account configured via RunAs profile does not use it. It uses default RunAs account.
Is it that I do something wrong and I should keep trying or it is not possible to switch SCOM 2016 agent reporting to SCOM 2016 MS to use RunAs Account with Logon as a service user right?
Morning, SCOM 2019 UR3- can I use domain accounts for monitoring linux servers? What about MSA’s?
Thanks as always!
Tony
Yes – as long as your Linux servers are participating in an active directory domain.
MSA’s – I am not sure. I have not looked into using gMSA’s for RunAs accounts with Linux.
Hi, our security windows configuration: the local administrators group is grant to run as a service. My account of my domain is a member of the Local Administrators group on all domain servers, and account SCOM is also a member of the local administrators group of the all domain servers. Based on this, my account gets the right grant to run as a service. But when installing the agent at the search stage, I still get the error…
Does SharePoint 2019 Management Pack support gMSA account for the Run As Account to discovery SharePoint monitoring?
I have meed trouble in DB engine discovery session (helthservice it’s created in DB), still got “logon as service” error from event 7002.
How to allow “Healthsevice” to set to logon as service ?