Hi all,
Our team is following this article:Ignition Security Hardening Guide | Inductive Automation
We managed to start the gateway service using a service account with minimal privileges (access only on the location where Ignition is installed) but we encountered this problem:
What are the minimal privileges that a service account should have to not affect the workflow of Ignition gateway?
Thanks,
Bogdan
Hey, thanks for quick reply.
Not sure if is the same case here, because when we added the service account in the local admin group, after service restart everything went back to normal.
Are you certain it’s related to the service user?
We’ve seen this with a few other customers and right now it’s looking like it may be a JDK bug based on a ticket we found.
Edit: oops, just saw your response. That’s good info to have for us though 
We are tracking a ticket on this internally. I was also able to reproduce this (thanks to your post here in addition to the other one that @Transistor linked above) by adjusting to use a standard user account on Windows.
Hi,
Any resolution regarding this topic?
Hi,
Any news about this topic?
Try adding the user that is running the Ignition Gateway to the Performance Log Users group. You will have to restart the gateway for it to take effect. It looks like this may be required to actually query the performance counters system to retrieve process cpu load.
After adding the Ignition service user (to Performance Log Users group) and restarting Windows (not just the Ignition service), CPU shows as expected. Thanks @kcollins1!
No luck here. 8.1.16 with redundancy. Curiously, this is with my Ignition service running as local system and NOT a dedicated service account. I’ve added NT AUTHORITY\SYSTEM to Performance Log Users for good measure. Still shows -100% CPU after a full Windows reboot on both master/backup.
I’ll reach out to support as well, but figured I’d post here first.
Please share if you get the fix. I am having the same issue with 8.1.16
Interesting. I’d never seen this issue before we set the Ignition service to run as a domain account with only regular user permissions plus full control of the Ignition installation directory. Doing that created this issue on every computer we did it on. Adding the domain account the service is running under to Performance Log Users group and restarting Windows resolved it in all cases.
@awarunek187, can do!
@witman, yeah it’s weird. In my case, I upgraded from a clean install of 8.1.10 to 8.1.16. Our environment also has a ton of domain policies - not sure if any could be having an impact, but at a minimum they weren’t causing issue at 8.1.10.
Yeah, same here.
@Cory.grube I’ve still got my test bench for this available, so I’m going to test a couple more things for you to see if I can reproduce the behavior. Ultimately, when you see that that CPU usage go negative, something is going wrong attempting to retrieve some local statistics for the process (through whatever native interface is available (Windows, macOS, Linux, etc)).
Also of note is that Performance Monitor Users is also probably enough, fwiw (versus Performance Log Users).
Great, happy to hear. For fun I tested adding local system to performance monitor users - no change
@Cory.grube, it sounds like version is relevant. Ours are all on 8.1.15–haven’t upgraded to 8.1.16 yet.
I’m running 8.1.16 with redundancy. The fix worked for me. However the user we use in this case isn’t local, it is a domain user.
We’ve upgraded to 8.1.17 and this still works for us.
Digging a little more into this, the above guidance on adding the user to Performance Monitor Users group does assume a standard permissions configuration on various registry keys. Reference was this [admittedly old] post from VMware regarding things to check on data collection under Windows: VMware Knowledge Base
I found that misconfiguring permissions to the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib keys (check the article for more details) results in instant regression to the -100 cpu usage:
