WinRM service issues on Server 2012 R2

Can you confirm that you recently installed this Windows Update KB5014754?

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

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 enable 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 iteration for the bespoke hardening, due to our inhouse 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 Oktober 2021 security update packets. In a fully updated and correctly configured environment, PRTG and WMI work flawlessly with the 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). Which 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 customer may face problems with inconsistently applied patches through their infrastructure. This is caused by an outside factor, so we concluded to not be able to do much about it. Configuring the DCOM Settings per Device target is not an sufficient solution and would make the whole system much more brittle and even would open up new vulnerability path's. Customer 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 what Microsoft did to the authentication and how to set the packet integrity correctly per host. Or to consider rolling back the update.