WMI PERMISSIONS & GENERAL ERRORS
Description: WMI can fail for a number of reasons. Some of those can include not having appropriate rights and permissions for access to machines or namespaces, problems with provider registration, corrupted repository, and scripting errors to name a few.
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.
Never delete the WMI repository as a first troubleshooting step because deleting the repository can cause damage to the system or to installed applications.
Scoping the Issue: When dealing with general WMI troubleshooting, the first thing to do is to test the WMI service. The quickest way to do this is via the WMI Control snap-in:
- Click Start, click Run, type wmimgmt.msc, and then click OK.
- Right-click WMI Control (Local), and then click Properties.
- If the WMI service is configured correctly, the WMI Control will connect to WMI and display the Properties dialog box.
- On the General tab, you should see information about the operating system and the version of WMI. If it shows any errors or is unable to display the information, document the message seen (or capture a screenshot)
When working on WMI issues, we also need to check the status of DCOM. If you are not terribly familiar with DCOM, our blog post " COM and DCOM for Administrators " is a good place to get familiar with the basics. Our basic testing for DCOM begins with ensuring that DCOM is actually enabled:
- Click Start, click Run, type dcomcnfg, and then click OK.
- Expand the Component Services node.
- Expand the Computers node.
- Right-click the My Computer node, and then click Properties.
- Click the [Default] COM Security tab.
- Ensure that Enable “Distributed COM on this computer” is enabled
- Default Authentication Level is set to Connect
- Default Impersonation Level is set to Identify
Assuming that DCOM is enabled, we also need to check if the Distributed Transaction Coordinator service is started by checking the service status in the Services console snap-in.
Additionally, if you are seeing any "Access Denied" error messges, we need to verify that the DCOM and WMI Service settings are at their default values, and that the Network Service account has been granted impersonation rights. For more information, see the MSDN article WMI Troubleshooting .
Data Gathering: In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done. Additional data required may include the following:
-
Run the WMIDiag utility for all issues -
The WMI Diagnosis Tool can be run from Windows Explorer or from the command line. (cscript wmidiag.vbs) -
Each time it runs, the WMI Diagnosis Tool creates three files: A .LOG, .TXT, and a CSV file -
The three files are created, by default in the %TEMP% directory
-
Configure WMI Verbose logging on the local (and remote machines if needed) via the WMI Management snap-in (wmimgmt.msc) -
Right click on WMI Control (local) and select Properties -
Select the Logging tab, and change the "Logging Level" to verbose -
Set the "Maximum Size" value to 26214400 -
Click OK
Troubleshooting / Resolution: Once you have gathered the data, here are some things to check:
- MPS Reports:
- Review the Event Logs for relevant events
- You should also check the Event Logs and Windows Update logs to see if there were any application updates or patches that preceded the unexpected behavior - there may be a correlation
- Review the WMIDIAG report.
- At the end of the .LOG file you will find the WMI report which is the same information found in the .TXT file. Fix all reported problems suggested by the WMI Diagnostic Tool
Additional Resources: