THIRD PARTY WMI PROVIDERS


Description:  Failures with WMI providers rarely occur and it is often difficult to discern when having various issues with WMI whether a problem is due to an issue with a client application/script utilizing WMI, WMI itself, a WMI provider and/or the object being managed by WMI.

A WMI provider is the software component that allows for the presentation and management of enterprise objects through the WMI interface. Examples of enterprise objects that could be managed in this fashion are logical and physical things such as hard drives, network adapters, database applications, operating systems, processes, services, active directory objects, etc. WMI providers implement this functionality by registering specific classes for these objects within WMI. These classes have associated methods and/or properties by which the objects are defined and accessed. There are many providers that come with the various versions of Windows operating systems. These and the various classes that they present are outlined in the below Microsoft MSDN articles. The majority of those described are the operating system-related providers and classes but the ones for the Microsoft applications IIS, SQL and Exchange are also discussed.

3rd party vendors can create and supply their own WMI providers to allow their specific software and/or hardware to be accessible via WMI if not made so via existing providers. If an issue is found to be with a Microsoft supplied WMI provider then support for it will be provided by Microsoft. On the contrary, if an issue is found to be with a WMI provider produced by a 3rd party then support for it will need to be provided by that vendor. Furthermore, support for Microsoft default operating system providers will be provided by the Platforms-Performance support teams while support for Microsoft application-specific providers such as those for SQL, IIS, Exchange, etc. will be provided by the support teams for those applications.

 

Scoping the Issue: 

When suspecting an issue with a WMI provider is occurring it is important to identify which provider is involved so that the scope of the issue is understood and the appropriate support organization can be engaged.  More obvious types of issues with Microsoft-created operating system WMI providers are those that involve failures obtaining data via the providers and classes referenced via the two MSDN links above.  Multiple tests should be performed in an attempt to determine whether an overall WMI issue is occurring or one involving just a single provider. Try the following tests on the target machine to help determine the scope of the issue.

Test the Win32 class provider using the WBEMTEST utility:

  • Click START and then RUN and enter WBEMTEST.EXE
  • From the WBEMTEST utility, choose the CONNECT button and enter “root\cimv2” in the Namepsace box.
  • Click the CONNECT button to connect to the namespace
  • At the parent screen, click the QUERY button and then enter “SELECT * FROM WIN32_PROCESSOR” in the Enter Query box.
  • Click the APPLY button to execute the query and note whether the number of processors on the system are returned once the query completes.

Test the Active Directory provider using the WBEMTEST utility: 

  • Click START and then RUN and enter WBEMTEST.EXE
  • From the WBEMTEST utility, choose the CONNECT button and enter “root\directory\ldap” in the Namepsace box.
  • Click the CONNECT button to connect to the namespace
  • At the parent screen, click the QUERY button and then enter “SELECT * FROM DS_LDAP_CLASS_CONTAINMENT” in the Enter Query box.
  • Click the APPLY button to execute the query and note whether information is returned once the query completes. NOTE, the query may take a few minutes to complete.

If issues are encountered while trying the previous tests then that would indicate that the scope of the issue is broader than just a problem with a Microsoft application’s WMI provider.  If the tests were successful then one of the following tests below should be implemented for the specific Microsoft application where the WMI provider is in question.

Test the IIS provider using the WBEMTEST utility: 

  • Click START and then RUN and enter WBEMTEST.EXE
  • From the WBEMTEST utility, choose the CONNECT button and enter “root\microsoftiisv2” in the Namepsace box.
  • Click the CONNECT button to connect to the namespace
  • At the parent screen, click the QUERY button and then enter “SELECT * FROM IISSETTING” in the Enter Query box.
  • Click the APPLY button to execute the query and note whether information is returned once the query completes

Test the Exchange provider using the WBEMTEST utility:

  • Click START and then RUN and enter WBEMTEST.EXE
  • From the WBEMTEST utility, choose the CONNECT button and enter “root\microsoftexchangev2” in the Namepsace box.
  • Click the CONNECT button to connect to the namespace
  • At the parent screen, click the QUERY button and then enter “SELECT * FROM EXCHANGE_MAILBOX” in the Enter Query box.
  • Click the APPLY button to execute the query and note whether information is returned once the query completes

Test the SQL provider using the WBEMTEST utility:

  • Click START and then RUN and enter WBEMTEST.EXE
  • From the WBEMTEST utility, choose the CONNECT button and enter “root\microsoft\sqlserver\reportserver\v9” in the Namepsace box.
  • Click the CONNECT button to connect to the namespace
  • At the parent screen, click the QUERY button and then enter “SELECT * FROM MSREPORTSERVER_INSTANCE” in the Enter Query box.
  • Click the APPLY button to execute the query and note whether information is returned once the query completes

 

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:

  • Make a note of any enterprise management or monitoring software in use on the affected machines – for example: SMS, MOM, Tivoli, BMC Patrol, HP OpenView, NetIQ etc
  • Make a note of applications or scripts on the affected system(s) that may require the use of WMI.  Also, note the WMI Classes and / or providers used by these applications / scripts

In addition, you should configure WMI Verbose logging on the affected system:

  • Click START and then RUN and enter 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

Also – capture the output from the WMI Diagnosis Utility:

  • After downloading the utility, create a folder at the root of a drive to store WMIDIAG, for example: C:\WMIDIAG
  • Download wmidiag.zip to the newly created folder and unzip contents
  • Open a command prompt and navigate to the folder containing the WMIDIAG files
  • At the prompt, execute WMIDIAG by running the following command:CSCRIPT WMIDIAG.VBS
  • The WMI Diagnosis Tool should complete within 15-20min and creates three files in the %TEMP% directory: a .LOG file, a .TXT file and a .CSV file

NOTE: More information on the diagnostic utility is available at the TechNet ScriptCenter.

 

Troubleshooting / Resolution:  Once you have gathered the data, review the Event Logs for WMI errors.  If you have captured the output from the WMI Diagnosis Utility, review the logs and resolve any errors where possible.  Since WMI is such an integral part of Windows Operating System, please engage a Microsoft Support Engineer for assistance, as incorrect settings could cause damage to your system(s).

 

Additional Resources: