Partner Support

English

X

Select your language:

Devices not appearing WMI-enabled in the Service Center

You may encounter situations where you have used all the correct configuration tools and followed the Managed Workplace documentation and knowledge base articles. However a Windows device still will not appear as WMI‐enabled in Service Center, even when monitored by a Device Manager instead of an Onsite Manager.

In these cases, there is likely some corruption of the WMI repository on the device which must be repaired. When this is true, no monitoring tools can query WMI information, including those that are included with the operating system itself.

WMI is a core component of all modern Windows operating systems, and issues with the component will eventually surface as problems with other features or applications. Using Microsoft tools you can demonstrate to end‐clients that the issue is with the operating system, and take corrective action.

In these cases, AVG Managed Workplace has actually discovered an issue on the network from the very first scan.

Using wbemtest.exe

This tool is included with all modern versions of Windows that contain a full implementation of Windows Management Instrumentation. When monitoring using an Onsite Manager, you will start by running the test from the Onsite Manager server to the managed device. If the results are unsuccessful, or when you are using a Device Manager for monitoring, you will have to run the test locally on the managed device.

To run the test from the Onsite Manager

  1. Open the Services applet on the Onsite Manager Device
    Click Start - Run, and type services.msc. Click OK to open the Service Control Manager
  2. Right‐click MWExpertSystem and choose Properties.
  3. Switch to the logon tab.
  4. Note the account. You will use the same account for your testing to duplicate exactly what Onsite Manager is doing.
  5. From the Onsite Manager application server, click Start - Run and enter wbemtest. Click OK.
  6. The Windows Management Instrumentation Tester opens.

    User-added image

  7. Click Connect and configure with the following settings:
    Namespace: \\[MACHINE NAME or IP ADDRESS]\root\cimv2
    User: enter the username collected in step 4.
    Password: enter the password for the username collected in step 4.
    Impersonation Level: Impersonate
    Authentication Level: Packet
    How to interpret empty password: Null

    User-added image

  8. Click Connect. You are returned to the main page with your configuration in place.
  9. Click Query, enter the following and click Apply:
    SELECT * FROM Win32_ComputerSystem

The query must be successful in both asynchronous and semi-synchronous methods. Devices will show up as WMI‐enabled when the query is successful in semi-synchronous mode, but asset collection will not occur unless the query also succeeds in asynchronous mode.

If you get any other kind of result, or are unable to run the query at all, this means that there is an issue with the operating system on the managed device. Very likely, the WMI repository is corrupted.

When you are unable to successfully query WMI devices from the Onsite Manager, and you have confirmed the account being used has the required privilege (Domain Admin, Enterprise Admin), you can try the same process locally to determine if the cause is corruption of WMI.

To run the test Locally

  1. From the Onsite Manager application server, click Start - Run and enter wbemtest. Click OK.
  2. The Windows Management Instrumentation Tester opens

    User-added image

  3. Click Connect and configure with the following settings:
    Namespace: \root\cimv2
    Impersonation Level: Impersonate
    Authentication Level: Packet
    How to interpret empty password: Null
  4. Click Connect. You are returned to the main page with your configuration in place.
  5. Click Query, enter the following and click Apply:
    SELECT * FROM Win32_ComputerSystem

The query must be successful in both asynchronous and semi-synchronous methods. Devices will show up as WMI‐enabled when the query is successful in semi-synchronous mode, but asset collection will not occur unless the query also succeeds in asynchronous mode.

If you get any other kind of result, or are unable to run the query at all, this means that there is an issue with the operating system on the managed device. Very likely, the WMI repository is corrupted.

Using WMI Diagnostics

This tool runs various tests against the WMI repository on the local device, and creates three log files with the results in the Windows temporary directory (%Temp%). The names of the files contain the machine name and date/time when the script was executed, so will vary from what you see below:
  • WMIDIAG‐V2.0_2003_.SRV.RTM.32_TRODNEY‐DT_2011.07.09_17.38.21.LOG 
  • WMIDIAG‐V2.0_2003_.SRV.RTM.32_TRODNEY‐DT_2011.07.09_17.38.21‐REPORT.TXT 
  • WMIDIAG‐V2.0_2003_.SRV.RTM.32_TRODNEY‐DT_2011.07.09_17.38.21‐STATISTICS.CSV
The log file is fairly easy to interpret as it is presented in plain language. You may see indicators of corrupt WMI as messages such as:
  • ..218 17:38:24 (2) !! WARNING: WMI System file 'C:\WINDOWS\SYSTEM32\WBEM\IISWMI.DLL' is MISSING or is access DENIED but it is an OPTIONAL component.
  • ..331 17:38:27 (1) !! ERROR: Unable to access or find file 'C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V3.5\MOF\SERVICEMODEL35.MOF' listed in 'Autorecover MOFs'.
Generally you want to examine all WARNING and ERRORS. For more detailed information on interpreting the results, please refer to the official Microsoft documentation on the WMI Diagnosis Utility or refer to the WMIDiag.doc included with the download.

We value your feedback, please help us to improve this article by voting below.

Was this article helpful ?