When accessing WMI local or remote data in an application or script, you may encounter errors ranging from missing classes to access denied. The first step in most WMI-related cases is to test the ability to connect to the service on the local computer. Depending on the nature of the problem, you may also have to test the ability to connect to the WMI service on a remote computer.
Before you continue with any efforts, if not already, should run the WMI Diagnosis Utility (WMIDiag). If WMI returns error messages, be aware that they may not indicate problems in the WMI service or in WMI providers. Failures can originate in other parts of the operating system and emerge as errors through WMI. Despite what you may have heard or read elsewhere, deleting or rebuilding the WMI repository as the first step in troubleshooting is not recommended! Deleting the WMI repository could cause issues with the operating system or installed applications.
To obtain more information about the source of the problem, you can download and run the WMI Diagnosis Utility diagnostic command line tool. This tool produces a report that can usually isolate the source of the problem and provide instructions on how to fix it. After you have downloaded the utility, extract the files to C:\WMIDiag (for simplicity’s sake) and run the WMIDiag.vbs file. By default the WMIDiag script will write the output to the user’s temp folder, so I suggest defining where you want the log files written when you run the script – as follows: cscript c:\wmidiag\wmidiag.vbs LOGFILEPATH=c:\wmidiag. Once the script is finished, the log file will identify WMI issues. We’ll look at WMIDiag in more detail in a future post.
Microsoft, Windows, WMI, Troubleshooting, Knowledgebase