What can I do when my WMI sensors in PRTG are showing errors? Can you provide trouble shooting steps?
General introduction to WMI and PRTG
Every so often customers using our monitoring tools (e.g. PRTG Network Monitor) report issues when trying to monitor their systems using WMI (Windows Management Instrumentation) sensors. In most cases, these issues stem from a malfunctioning WMI configuration/installation. For example, we have noticed that many times when WMI issues arise one (or multiple) WMI components crucial for proper WMI monitoring are missing or have not been implemented properly.
Important! Before going any deeper into troubleshooting, a good knowledge of the principles and functions of WMI is necessary. Please refer to the following Microsoft article for frequently asked questions about WMI:
Please ensure the following:
- DCOM needs to be enabled on probe and target computer. Check the respective registry entry.
- The user whose credentials are specified for monitoring WMI is a member of the Domain Administrators group in the same Active Directory as the target computer. In case of a target computer outside of a domain the user has to be a member of the local Administrators group and of the DCOM group and of the Performance Monitoring group on this machine.
- The monitoring user’s access rights on COM and WMI include remote access rights for the target computer. Read about Securing a Remote WMI Connection on MSDN.
- The target computer's Windows Firewall is set to allow WMI. MSDN features an article on this topic for XP and W2k3: Connecting Through Windows Firewall. For computers with Vista and above read this article on MSDN: Connecting to WMI Remotely Starting with Windows Vista.
- If the firewall is enabled by group policies you have to enable the "Allow Remote Administration Exception" as outlined in this article at Addicted to IT: Group Policy: Windows Firewall setting to allow your WMI scripts to run
- The RPC server used for WMI on the target computer is running on the port specified in PRTG (135 by default).
- DCOM and RPC need open high ports in the 49152-65535 range on Windows Vista and Windows Server 2008 or later. In previous Windows version, ports in the 1024-5000 range are required. Some customers have found that opening TCP port 1091 helped them getting a connection. For more information, see the article
Service overview and network port requirements for Windows.
To define a more specific port range for DCOM, follow these steps:
- Run dcomcnfg to open the DCOM console.
- Open Components Services | Computers | My Computer.
- Right-click My Computer and choose Properties from the context menu.
- Open the Default Protocols tab.
- Open the Properties... of Connection-oriented TCP/IP.
- Define the port range you want DCOM to listen at. Set a minimum of 100 ports in the 49152-65535 or 1024-5000 range, depending on the Windows versions in your environment.
- Security Software: It's always a good idea to double-check that no local security software (anti-spy, anti-virus, etc.) on either side is blocking WMI connections.
- If you do not get a WMI connection, try to restart the WMI service manually or change the IP address of the target server to its DNS name in the device settings in PRTG. This establishes a completely new WMI connection which might help.
Troubleshooting in detail
Please refer to the following articles for further information:
- WMI Tools Overview
- The most common WMI errors
- PRTG WMI error messages (PE code)
- Which WQL queries are used by PRTG's WMI sensors?
- Why do my WMI sensors show error PE263 after updating PRTG?
A very good external article for troubleshooting WMI is found here:
Tips against slowness on Vista and Windows 2008 are found here:
If you are monitoring a massive number of hosts with one probe, this here might help:
- Memory and Handle Quotas in the WMI Provider Service (but bear in mind it is always a good idea to distribute WMI queries over one or more Remote Probes)
If you are experiencing high handle count in WMI service (Winmgmt) or WMI provider (wmiprvse.exe), please see this article:
PRTG settings for WMI
PRTG offers a few settings for dealing with WMI issues:
Tips and Tricks
The following articles provide guidelines for special scenarios:
- How can I monitor WMI sensors if the target machine is not part of a domain?
- WMI consumes a large amount of memory on my Windows Server 2008 R2 – what can I do?
How to repair WMI
If all else fails we've gathered some procedures which might fix the WMI system on affected computers:
Another good article about all things regarding WMI can be found under:
This reference provides a list of WMI providers, information on the COM API for WMI, WMI queries, WMI log files, WMI security, WMI tools and WMI infrastructure objects and values.
Further articles of interest (providing more detail than the troubleshooting articles above), relating to particular aspects of WMI configuration can be found under :
Maybe a little addition.
If you query your WMI from within a powershell on Windows 2008R2, you maybe get a Class not Found error. Remember that PRTG uses the 32-bit powershell as default.
Execute your powershell script in powershell 32-bit, receive the same error? Execute your powershell script in powershell 64-bit, error resolved? Than execute your script in a 64-bit powershell by calling it from a commandline in your 32-bit script.
start.ps1 <- the 32-bit, notice the sysnative folder.... c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\<script>.ps1"
main.ps1 your working 64-bit WMI script.....
Nice thing to know is that you still can use arguments...
I can't really understand what prevented you from developing something like "WMI proxy" which will run as a service on remote machine and execute all the WMI queries - there won't be any overloads, permission issues, flickering issues and so on...
we want to avoid the need to install and maintain extra software on the hosts you monitor.
@Vadim Doroginin: Actually we did develop such a service. It's called "Remote Probe" and can be installed on one, or a few, or all your machines in your network. But it's a lot of work to install a software on all machines in a network and in most cases it is not necessary.
A huge majority of PRTG users is using WMI just fine to monitor their networks with hundreds or even thousands of Windows PCs.
And for those who do have problems with WMI there is the option to install Remote Probes.
Windows Server 2008 & 2008 R2 WMI Defects
Paessler: please consider making the relevant information below part of the body of your KB article. I hope it helps someone else.
A while back I started closely monitoring the WMI service on the various servers that often false alarm during WMI overload. Most often, the free space check would fail returning a null or zero value instead of the correct value for free disk space. To troubleshoot, I added the PRTG WMI service monitor for the WMI Service itself with a 60 second interval. I also monitored the system and application event logs with 15 minute intervals. It helped to get more specific errors about what was going on with WMI. Most often I'd get one of these errors in succession:
- WMI Free Disk Space [Multi Drive]: 0 % (Free Space C:) is below the error limit of 10 %
- Windows Management Instrumentation (WMI Service) Warning: 80041006: There was not enough memory for the operation.
- Event Log (Windows API) Value changed: Faulting application wmiprvse.exe, version 6.1.7600.16385, faulting module 4a5bc794, version ole32.dll, fault address 0x6.1.7600.16624
Armed with this new information, I was able to find two Microsoft KB articles that seemed to match the symptoms:
- 958124 A wmiprvse.exe process may leak memory when a WMI notification query is used heavily on a Windows Server 2008-based or Windows Vista-based computer
- 954563 Memory corruption may occur with the Windows Management Instrumentation (WMI) service on a computer that is running Windows Server 2008 or Windows Vista Service Pack 1
Applying these two hotfixes stopped the false alarms on my Windows 2008 and 2008 R2 servers.
great finding, thanks a lot for this!
I've added your solution to our Most common WMI errors article.
To have WMI to work on 2k3 with firewall, I've opened port 1091 TCP.
Here's the DEBUG solution we've used to see this :
- start windows firewall logging and check the logs for dropped connections Go to the Windows Firewall, Advanced settings Security Log group-box -> Click on Parameters button Select "Log dropped packets" Look at the log file location (if not present define one) Click OK
You can now press 'Windows + R' and then type '%WINDIR%\pfirewall.log' to see what's wrong.
If WMITest shows Error 800706BA: In Windows Firewall enable port TCP 1091 and TCP 56301
If WMITest show Error 8007005 for Windows Pro with firewall off : Disable simpe file sharing. Method 1: Explorer -> Tools -> Folder options -> Display -> Simple file sharing
Method 2 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Set 'forceguest' to 0
a great thanks to ERIC Drezet from CNRS who give me a simple working solution.
It works for Windows XP : Netsh firewall set service remoteadmin enable
For Windows 7, we must have a closer look because netsh firewall [...] has been replaced by netsh advfirewall [...]
it should be something like (don't work for me): NETSH advfirewall firewall SET rule group="remote administration" new enable=yes
but this command seems to works (even if depreciated) : netsh firewall set service type=remoteadmin mode=enable
CAUTION : it seems that UAC will block these commands to work.
80070005: Access is denied SOLVED
Just delete the device and "add" it again to your prtg monitor Group. Do an automatic discovering and it will work fine again. Try it.
Hey everyone.. I had been struggling for ages with a server that just suddenly stopped responding to WMI. Throwing a mixture of PE015, 80041002 (Object Not Found).
I tried everything across all the WMI threads on here and had no luck.
I found a guy online talking about general WMI errors, and I followed through some of the steps he had posted and boom! Working WMI sensors.
It boiled down to rebuilding WMI on the target server.
I've written up my process here: http://craigerrington.com/blog/prtg-wmi-repair-80041002/
@CraigE: Thanks for sharing your findings!
The prtg kb has been a godsend and so far solved any issues I encountered, namely WMI sensor issues that may relate back to the probe dependencies not being met. Thank you.
Please, update this article to not recommend adding the PRTG service account to the DOMAIN ADMINS. It's 2016, such blatant insecurity is not an acceptable solution to this problem!
We have the same doubts as you have about using domain admin credentials for WMI Montioring. However, it's the most reliable option for all WMI / Performance Counters that the sensors monitor. Bear in mind, we do not define the necessary permissions / privileges to access those counters. That's done by Microsoft and potentially the Windows Admins in an organization. PRTG can only adapt to it.
@PRTG, is it true, that WMI does not work over a NATed network?
We recommend actually to use Remote Probes in a NAT-scenario. Place a Probe into the subnet and configure it to connect back to the PRTG Core Server. That usually also resolves any administrational struggles then when alerts happen, to see in which actual subnet they happen.