Votes:
Hello!
I have a problem with 3 server with this problem. All other server are working correct. On this 3 server only the WMI Sensors are failing. I checked the DCOM Settings, WMI Settings and all helpful things in the knowledge base but I don't find a solution why this is happening. Maybe someone can help me.
1 Reply
Votes:
Hello Dear customer,
Thank you for contacting PRTG support.
This error code (PE015) means that the probe computer and target system could not establish a WMI communication. This can have several reasons. Performance issues most likely cause it in regard to WMI-based sensors. If possible, I recommend replacing the WMI sensor with the SNMP-based alternatives (as SNMP isn't producing as much performance load as WMI). Also, we have a detailed guide for this issue already, please take a look at it and follow the troubleshooting steps there:
- https://kb.paessler.com/en/topic/1043-my-wmi-sensors-don-t-work-what-can-i-do
Sometimes, this error occurs also when using an IP address to connect to a device. If this is the case using the hostname or FQDN instead might already solve the issue. Can you confirm that you recently installed this Windows Update KB5014754?
Microsoft recently rolled out a patch that 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 the 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
In addition, I would like to clarify the situation here. Instead of hardcoding the DCOM Configuration, PRTG uses the System default discovery of security settings of the System. This enables users to configure the (very frustrating way to define) DCOM Security once per System instead of multiple times per application. As long as the underlying system is configured correctly, PRTG can work with all security levels. In the first couple of iterations for the bespoke hardening, due to our in-house testing and many customer reports, Microsoft seemed to have messed up the default discovery and therefore the System PRTG used didn't work out correctly. This has been silently fixed by Microsoft with one of the patches from the September or October 2021 security update packets. In a fully updated and correctly configured environment, PRTG and WMI work flawlessly with higher security levels. For this both Systems, the system of the PRTG Probe and the target must be configured correctly appropriate to the chosen security level (via dcomcnfg.exe). We tested with different OS Combinations and a couple of customers. image This whole situation brings us to the stand, that PRTG is prepared for the changes to go fully live without any changes needed. We are aware, that customers may face problems with inconsistently applied patches through their infrastructure. This is caused by an outside factor, so we concluded not be able to do much about it. Configuring the DCOM Settings per Device target is not a sufficient solution and would make the whole system much more brittle and even would open up new vulnerability paths. Customers with major problems due to update processes can install a second remote probe with a different DCOM configuration and move/copy devices if really necessary.
Hope this gives you a better understanding of what Microsoft did to the authentication and how to set the packet integrity correctly per host. Or to consider rolling back the update.
If the issue persists, I highly recommend you proceed and open a support case at [email protected] along with screenshots of the following:
Best regards
Created on Nov 17, 2022 2:54:23 PM by
Add comment