WMI: Custom Component Fails
Description:
It is important when utilizing custom WMI components to thoroughly scope the issue to define the symptoms and pieces so that the appropriate support organization can be engaged and provided the relevant information to begin troubleshooting the issue.
If an issue is found to be with a Microsoft supplied WMI component then support for it will be provided by Microsoft. However, if an issue is found to be with a custom WMI component then support for it will ultimately be the responsibility of the vendor. Note that Microsoft does not support the writing or troubleshooting of scripts. Scripts found within Microsoft documentation are provided as-is.
Scoping the Issue:
As mentioned previously, it is important to identify the components involved in the WMI issue. With this in mind, an attempt should be made to determine whether an issue is due to a problem with the client application or script that is utilizing WMI, WMI itself, or the WMI provider and/or the object being managed by WMI. Of these general pieces, the client application/script and/or a provider could be a custom component created by an individual or vendor.
If a custom client application/script is involved, then it will be important to be somewhat familiar with how the application or script is utilizing WMI. This may require the engagement of the vendor or developer of the application or script. For example it would be important to know what namespaces, classes and providers are being used. Once these are known then a different application or script should be tested that utilizes the same namespaces, classes and/or providers in the same way to note whether the symptom continues. If it does then the issue is likely not unique to the application/script. If it does not, then the issue may be unique to the specific application/script. For scenarios where the symptom is unique to the custom client application/script component then the vendor/developer should be engaged for further support.
When performing the application/script comparison tests, the WMI testing utility that comes with Windows (Wbemtest.exe) can be implemented to perform various queries and actions. New .VBS scripts can be utilized as well. The SCRIPTOMATIC scripting tool is another resource that may help with writing test scripts/queries:
Scriptomatic 2.0
http://www.microsoft.com/downloads/details.aspx?familyid=09dfc342-648b-4119-b7eb-783b0f7d1178&d...
If a custom client application or script is not involved, then another possibility could be a custom provider. As with a custom client component, it is important to be somewhat familiar with a custom WMI provider. Beneficial things to know would be what class or classes it makes available and under what namespace(s) it resides. Additionally it would be beneficial to know what properties and methods it provides.
When suspecting that an issue with a custom WMI provider component is occurring it will be important to identify whether that is true for just that one provider or others as well. The more obvious types of issues are those that involve failures obtaining data via WMI for specific target applications or objects that have their own WMI providers. For example, data failing to be accessed from IIS by its provider while other data is attainable via other WMI providers indicates a problem with the IIS provider and not WMI as a whole. Refer to the following templates for suggestions on narrowing the scope for provider related issues:
WMI - Microsoft Application (non-OS) WMI Providers
WMI - In-box Operating System WMI Provider
If tests only fail with a specific class and provider then that would indicate a provider-specific issue.
Data Gathering:
Gathering the following data is helpful to help troubleshoot issues related to WMI provider issues.
· Note any enterprise management software that may be installed and in use on the affected machine such as SMS, MOM, Tivoli, BMC Patrol, HP OpenView, NetIQ, etc.
· Note any other applications or scripts that are running that might utilize/query data via WMI. For these, also note the WMI classes and/or providers that may be utilized by these.
· Configure WMI Verbose logging on the machine via the WMI Management snap-in:
- 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
Collect an MPSReports from the machine:
1. For 32bit systems, download and save the reporting tool to your local hard drive:
http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706/MPSRPT_SetupP...
2. Double click 'MPSRPT_SetupPerf.EXE' to run the program. When a command window opens you will be asked to press 'Y' or 'N'. Press the letter 'Y' on your keyboard. No further interaction is required
3. The .CAB file is saved to C:\Windows\MPSReports\Setup\Reports\cabMPS Reports.
1. For 64bit systems, download and save the reporting tool to your local hard drive:
http://download.microsoft.com/download/f/0/4/f047169c-6357-47f3-835c-2665d6426e66/mpsrpt_pfe.ex...
2. Double click 'MPSRPT_PFE.EXE' to run the program. When a command window opens you will be asked to press 'Y' or 'N'. Press the letter 'Y' on your keyboard. No further interaction is required
3. The .CAB file is saved to C:\Windows\MPSReports\PFE\cab
Additional Resources: