WMI: Microsoft Application (non-OS) WMI Provider

WMI: Microsoft Application (non-OS) WMI Provider

  • Comments 1
  • Likes

MICROSOFT APPLICATION (NON-OS) WMI PROVIDER


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 a 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.

If an issue is found to be with one of these Microsoft-supplied providers, support for it will be provided by Microsoft.  Furthermore, support for Microsoft default operating system providers will be provided by the Platforms Performance support teams while support for Microsoft application-specific providers will be provided by the support teams for those applications.  If an issue is found to be associated not with a Microsoft-created WMI provider but instead one that is produced by a 3rd party then support for it will need to be provided by the vendor of that software.

 

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 as mentioned previously. The more obvious types of issues with WMI providers are those that involve failures when attempting to obtain data via a specific provider. 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: 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment