Unable to monitor Windows service

What PRTG version and windows versions are you using? Do you have any other WMI sensors working fine or they all fail?

We have seen issues when the windows user executing a service is different than the windows user for WMI, the WMI user is not allowed to see the services. Can you try running a service using the user you use for WMI, then try to create the sensor for that service?

Hi,

PRTG version is: 22.3.78.1873+

We are already monitoring Windows services without any issues. It's not possible to add new WMI sensors. It doesn't matter which Windows version we are trying to monitor.

I use my TIER account, and have used this for 2 years without issues

Please use our WMI Tester (https://www.paessler.com/tools/wmitester), run it on the PRTG Host (or host of the Remote Probe) and scan against this particular target, usually the "OS-Query" from the "Advanced" Tab of the Tool works best. The error might help to fix the issue.

Please also see our extensive WMI Troubleshooting Guide: https://kb.paessler.com/en/topic/1043-my-wmi-sensors-don-t-work-what-can-i-do

Regarding the WMI user access, make sure the password is the same, also the windows user have to be included in the user groups "Performance Log Users" or "Performance Monitor Users", "Remote Desktop Users" and "Distributed COM Users". You also need to enable permissions and services. For more detailed information you can refer to this guide https://www.ibm.com/support/knowledgecenter/en/SSMKFH/com.ibm.apmaas.doc/builder/ab_config_wmi_user.htm

This has been discussed in our knowledgebase, so you might consider to check out the feedback of PRTG users and additional hints here:

https://kb.paessler.com/en/topic/83070 https://kb.paessler.com/en/topic/4213

And you can get some more information here: https://www.infrasightlabs.com/setting-wmi-access-ad-gpo https://serverfault.com/questions/28520/which-permissions-rights-does-a-user-need-to-have-wmi-access-on-remote-machines/44997#44997

​ Microsoft recently rolled out a patch which hardens the DCOM authentication, which can cause authentication login attempts to fail. You can try to roll back the update or remove the registry entry as described in the official document: https://support.microsoft.com/en-us/topic/june-14-2022-kb5014699-os-builds-19042-1766-19043-1766-and-19044-1766-5c81d49d-0b6e-4808-9485-1f54e5d1bb15

As first workaround you can use the following article to disable the hardening again: https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c