WMI Diagnosis Tool can be downloaded from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=62562. More information about the WMI Diagnosis Tool usage can be found at these Internet locations:

WMI Diagnosis Tool webcast:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032290320&Culture=en-US

WMI Diagnosis Tool usage:

http://www.microsoft.com/technet/scriptcenter/topics/help/WMI Diagnosis Tool.mspx

WMI Troubleshooting:

http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx

2. Are there any plans to include WMI Diagnosis Tool in new versions of Windows?

There is no plan to include WMI Diagnosis Tool in the future versions of Windows. However, the WMI Diagnosis Tool package will remain available from the Microsoft Download Center.

3. Is there a WMI Diagnosis Tool version for beta testers of Windows Vista?

No. A WMI Diagnosis Tool version supporting Vista is currently under work. However, WMI Diagnosis Tool will support Vista by the time it is released.

4. Is it possible to "officially" engage Microsoft for feedback on this tool?

There is no official support for WMI Diagnosis Tool. However, feedback for the tool is welcome and can be sent to WMIDiag@microsoft.com.

5. Did Microsoft develop this tool as a script knowing that a lot of us will enhance it for our own uses?

The WMI team decided to develop this tool as a script simply because the development cycle and maintenance are easier and faster. Moreover, because the scripting community is quite large in the WMI space, we thought that some people would be interested in re-using or enhancing some of the functionality of WMI Diagnosis Tool. Some people have already provided feedback and enhanced the tool on their own.

6. Is there any documentation describing what WMI Diagnosis Tool does not check?

No. However, this information – for WMI Diagnosis Tool version 1.1 – is briefly mentioned in the WMI Diagnosis Tool webcast.

7. How much development time went into creating WMI Diagnosis Tool?

The project started in October 2005, a few weeks after the MVP summit in September 2005 in Redmond. The number of hours spent developing WMI Diagnosis Tool has not been tracked because it was a side project and not one of our normal activities. However, we can estimate a development time of 4 months with an average of 16 to 20 hours per week for one person. This includes the analysis, the problem detection pattern studies, the development and the testing of the tool.

8. Are there plans to document the top (say 25) problems customers find with WMI Diagnosis Tool?

Currently, there are no such plans. It is also important to note that obtaining a valid top 25 problem representation requires customer feedback. Therefore, we are counting on the community to provide feedback. If we get enough feedback, we may revisit this.

9. Do you plan to write future versions of WMI Diagnosis Tool in compiled code instead of a scripted version?

There are not such plans. New versions of WMI Diagnosis Tool will still be scripted.

10. Is it possible to store WMI Diagnosis Tool information in a SQL Server instead of a LOG file?

Technically, anything is possible. Because WMI Diagnosis Tool is a script, nothing prevents anyone from adding this feature to meet his or her needs. However, WMI Diagnosis Tool is quite verbose and the viability and scalability of this solution is unknown. Today, there are no plans to include this capability in WMI Diagnosis Tool.

11. Is there a release date planned for the next WMI Diagnosis Tool version?

There is no release date planned for the next version of WMI Diagnosis Tool. However, we do plan to have a version that supports Windows Vista.

12. Is there an e-mail address to send feature requests for future versions?

All communication related to WMI Diagnosis Tool should be sent to WMIDiag@Microsoft.Com.

13. What are the new features planned for the next WMI Diagnosis Tool version?

Although none of the features planned are confirmed at this time, during the WMI Diagnosis Tool web cast we mentioned that features such as the following are being considered:

· NT Event Log Events analysis for WINMGMT messages

· Support for DCOM and WMI namespace security deciphering and analysis (Security Descriptor)

· Tighter integration with SMS by adding tests for specific SMS WMI classes.

The feedback we receive will determine what features are planned and added first.

14. Is there an Internet BLOG for WMI Diagnosis Tool?

There is no BLOG specifically for WMI Diagnosis Tool. However, the WMI team has a BLOG at http://blogs.msdn.com/wmi/default.aspx.

WMI Diagnosis Tool usage questions

1. How should you use the Excel spreadsheet that comes with WMI Diagnosis Tool?

Each time WMI Diagnosis Tool is executed, a LOG file and a CSV file are created. By default, these files are created in the %TEMP% directory. To easily collect all CSV files created by all WMI Diagnosis Tool instances started in all computers, it is highly recommended that you collect the files in a central location. This can be done with the LogFilePath command-line parameter by specifying a UNC (share). Once all CSV files are centrally available, it is very easy to load all of them into the WMI Diagnosis Tool Excel spreadsheet included in the WMI Diagnosis Tool package. Simply execute the following steps:

· From the central location, execute

Copy /a \\MyCentral\Server\MyShare\*.CSV All.CSV

· Load the ALL.CSV in Excel

· Load the WMI Diagnosis Tool Excel spreadsheet in Excel (WMIDiag.xls comes with the WMI Diagnosis Tool package)

· Copy the content of the ALL.CSV Excel spreadsheet in the clipboard

· Paste the clipboard content in the DATA tab of the WMI Diagnosis Tool Excel spreadsheet

Once completed, the WMI Diagnosis Tool Excel spreadsheet adjusts all calculations and the results with associated graphics.

2. How do I know what to fix once the WMI Diagnosis Tool is executed successfully?

The WMI Diagnosis Tool creates a LOG file in the %TEMP% folder by default. This LOG file contains a WMI Report (at the end of the LOG file. Search for the “WMI REPORT: BEGIN” string). If you read carefully that report, WMI Diagnosis Tool will suggest which kind of action can be done to fix reported problems. Some of the suggested actions even contain some command line samples to execute in order to fix the reported problems. Note that several actions can be reported for one single problem. These actions are usually reported by order of importance and should be considered in the same order.

3. Can you run WMI Diagnosis Tool in a RUNAS command?

Yes. Ensure that you correctly specify the RUNAS parameters, the CSCRIPT.EXE parameters (the Windows Script Host engine running WMIDiag.vbs), the WMI Diagnosis Tool script full access path, and the WMI Diagnosis Tool command-line parameters. For instance, the RUNAS command could look as follows (the command line below must be typed on one single line):

Runas /User:MyDomain\MyAdminUser

"Cscript.Exe C:\WMI Diagnosis Tool\WMIDiag.vbs

Basenamespace=Root\Default"

4. Can WMI Diagnosis Tool diagnose a remote computer?

WMI Diagnosis Tool is not designed to diagnose computers remotely because WMI remote access is mainly based on WMI infrastructure for existing OS platforms. The aim of WMI Diagnosis Tool is to diagnose WMI, so the WMI Diagnosis Tool does not use WMI to perform its operations. That’s why WMI Diagnosis Tool must be run locally on the computer being diagnosed. However, WMI Diagnosis Tool can be deployed remotely with Group Policy, Systems Management Server (SMS) or Microsoft Operations Manager (MOM) via a Management Pack. Third party tools such as PSEXEC.EXE can also be used.

5. Can WMI Diagnosis Tool be remotely executed with PSEXEC.EXE on a remote computer?

Yes. For example, you can execute WMI Diagnosis Tool on a remote computer with PSEXEC.EXE from a network share so that you do not need to copy WMI Diagnosis Tool to the remote computer.

To store LOG and CSV files on a dedicated share and send WMI Diagnosis Tool failures only (Warnings and Errors) to Microsoft Corporation via email, the command line must be as follows (note that the command line must be typed on one single line):

Psexec.exe \\MyRemoteServer

-u MyRemoteServer\Administrator -p MyPassword

Cscript.Exe

\\OtherRemoteServer\RemoteShare\WMIDiag.vbs

SMTPServer=MyIntranetSMTPRelay.MyDomain.Com

LogFilePath=\\OtherRemoteServer\RemoteShare

SmtpWMIInvalidState

In this example, PSEXEC.EXE uses the Cscript.Exe WSH engine to execute on \\MyRemoteServer the WMI Diagnosis Tool located on the \\OtherRemoteServer\RemoteShare share.

6. Can WMI Diagnosis Tool be run using “WMIC process call create”?

Yes. For example, you can execute WMI Diagnosis Tool on a remote computer with WMIC from a network share so that you do not need to copy WMI Diagnosis Tool to the remote computer.

To store LOG and CSV files on a dedicated share and send only WMI Diagnosis Tool failures (Warnings and Errors) to Microsoft Corporation via email, the command line must be as follows (note that the command line must be typed on one single line):

WMIC.EXE /NODE:MyRemoteServer /User:MyRemoteServer\Administrator /PASSWORD:MyPassword

Process Call Create "Cscript.Exe

\\OtherRemoteServer\RemoteShare\WMIDiag.vbs

SMTPServer=MyIntranetSMTPRelay.MyDomain.Com

LogFilePath=\\OtherRemoteServer\RemoteShare

SmtpWMIInvalidState"

In this example, WMIC.Exe uses the Cscript.Exe WSH engine to execute on \\MyRemoteServer the WMI Diagnosis Tool located on the \\OtherRemoteServer\RemoteShare share.

7. Does WMI Diagnosis Tool fix problems it discovers?

No. WMI Diagnosis Tool purely executes in read-only mode. Even though WMI Diagnosis Tool diagnoses the situation and provides some procedures to fix discovered problems, at no time does the tool automatically fix the problem. This is by design because the correct repair procedure depends on the context, the usage, and the list of applications installed on the computer.

8. By limiting WMI Diagnosis Tool to check only one namespace, are you missing some possible error detections?

Yes. However, after running WMI Diagnosis Tool once without any namespace limitations, and if WMI Diagnosis Tool reports problems for only one single namespace, it is safe to limit the verification to the namespace reporting problems. But this approach assumes that no new problems are created on the computer. The BaseNamespace command-line parameter scopes the browse operation of the WMI repository to the namespace specified. Therefore only the WMI provider registrations related to that namespace will be verified. However, irrespective of the BaseNamespace command-line parameter, WMI Diagnosis Tool always performs the verification of all WMI core components in the system.

9. If the repository has been deleted and the computer still has WMI errors, can this situation be resolved with WMI Diagnosis Tool?

Yes, depending on the problems. If the repository has been deleted, it will be rebuilt when WMI Diagnosis Tool is run. The list of MOF files recompiled during the reconstruction re-registers the WMI providers in the WMI repository. If a DCOM registration is missing for one of these WMI providers, WMI Diagnosis Tool will be capable of detecting the error even after a repository reconstruction. This situation also demonstrates that deleting and reconstructing the repository is far from the right course of action to solve all problems reported.

However, some static classes specific to a 3^rd party application may be missing because the MOF file was never re-compiled during the reconstruction process. In this case WMI Diagnosis Tool will not be able to discover that error because WMI Diagnosis Tool has no specific knowledge of 3^rd party applications other than the WMI core setup. MOF files that do not contain the #pragma autorecover statement are not recompiled during the auto-recovery process. The missing classes from a 3^rd party MOF can cause the associated applications to fail. Once again, deleting and reconstructing the repository may solve some problems, but can eventually create new ones as described in this example!

10. Can WMI Diagnosis Tool identify the problem and root cause of the repository growing very large (+300 MB)?

No. WMI Diagnosis Tool is intended to verify the setup and the core elements of WMI based on the information in the registry and the WMI repository. To trace all activities of WMI at runtime, WMI logging/tracing must be used instead. Tracing runtime activities is not the purpose of the WMI Diagnosis Tool.

11. Does the WMI Diagnosis Tool report on any security settings or problems with rights?

The current version of the WMI Diagnosis Tool does not verify the security settings. However, it is a feature we hope to add in a future version of the tool.

12. Does WMI Diagnosis Tool output ERRORELEVEL codes?

Yes, it does. When WMI Diagnosis Tool terminates, the ERRORLEVEL CMD environment variable is set to a specific value:

· 0 = SUCCESS

· 1 = ERROR

· 2 = WARNING

· 3 = Command Line Parameter errors

· 4 = User Declined (Clicked the Cancel button when getting a consent prompt)

Note that if you use the SMS parameter, then WMI Diagnosis Tool does not set the ERRORLEVEL parameter. This functionality exists to prevent confusion between the failure of the execution of the tool and the state of WMI as reported by the Tool after a complete and successful execution.

13. How can I determine if I am using the latest version of WMI Diagnosis Tool?

The latest WMI Diagnosis Tool version is 1.10 dated the 8^th of March 2006 at 13:26.

14. If VersionA of WMIy.dll and VersionB of WMIx.dll are present on a system, does the WMI Diagnosis Tool tool detect that scenario?

No. However, the Windows File Protection is handling problems regarding invalid versions of the Windows system files.

15. Will the log have a unique name, or can you specify a log name (perhaps with computer name as a variable)?

No. WMI Diagnosis Tool names the LOG and CSV files itself by using a combination of the computer name and several other parameters to guarantee the uniqueness of the created files. However, the location used to create the files can be overwritten. By default, LOG and CSV files are created in %TEMP%. This can be modified with the LogFilePath command-line parameter by specifying a folder or share if required. The LOG and CSV filename format is as follows:

WMI DIAGNOSIS TOOL-vv.vv_wwww.ppp.sss.aa_COMPUTERNAME_yyyy.mm.dd_hh.mm.ss

Where

· vv.vv is the WMI Diagnosis Tool version (for example v1.11)

· wwww is the Windows version (for example XP__, 2003, 2000)

· ppp is the service pack level (for example SP1)

· sss is the platform type (for example SRV for server, CLI for client).

· aa is the processor architecture (for example 32 or 64).

· COMPUTERNAME is the computer name of the system analyzed.

· yyyy.mm.dd is the date of the WMI Diagnosis Tool run

· hh.mm.ss is the time of the WMI Diagnosis Tool run

For instance,

WMI DIAGNOSIS TOOL-V1.11_XP__.CLI.SP2.32_SERVER02_2006.03.08_04.52.42

16. When running WMI Diagnosis Tool, can we combine multiple command line parameters?

Yes. For example, to deploy WMI Diagnosis Tool with SMS, store LOG and CSV files on a share and send WMI Diagnosis Tool failures (Warnings and Errors) to Microsoft Corporation via email, the command line must be as follows (the command line below must be typed on one single line):

WMIDiag SMTPServer=MyIntranetSMTPRelay.MyDomain.Com

SMS LogFilePath=\\RemoteServer\RemoteShare SmtpWMIInvalidState

17. How frequent WMI Diagnosis Tool should be used?

It is recommended that you run WMI Diagnosis Tool at least once in your organization to assess the situation. By doing so, you will be able to fix any possible lurking problems that were not discovered yet. If any problems are found and fixed, it is always possible to run WMI Diagnosis Tool once a week or once a month as a preventive action to detect and fix any new issue. This decision is at the administrator’s discretion.

18. Is WMI Diagnosis Tool a good utility to run on Windows 2000 computers that are going to be upgraded to Windows Server 2003 using the upgrade path?

If you plan to upgrade Windows 2000 computers to Windows XP SP2 and/or Windows Server 2003, there is no need to run WMI Diagnosis Tool before upgrading. During the upgrade process, the DCOM registration of all WMI components is executed which automatically fixes all DCOM problems. Because the WMI repository format changes from Windows 2000 to Windows XP SP2 and Windows Server 2003, a new repository is created by converting the old repository to the new format. Therefore, the actual repository is verified during the conversion process. Once the upgrade is successfully completed, it is a good idea to run WMI Diagnosis Tool to assess the WMI setup but it is not mandatory.

WMI Diagnosis Tool and SMS Questions

1. Does WMI Diagnosis Tool work with SMS 2003 Advanced Client?

WMI Diagnosis Tool works regardless of any installed software consuming or providing WMI information. Therefore, SMS 2003 Advanced Client is no exception. The SMS 2003 Advanced Client registers WMI providers in the WMI repository, so the registration will be verified like any other registration. The current version of WMI Diagnosis Tool has no specific knowledge of the SMS 2003 Advanced Client, therefore, if an SMS 2003 Advanced Client WMI class is missing, WMI Diagnosis Tool will not report the problem as it would do for the pure common WMI classes. Note that the next version of WMI Diagnosis Tool will include validation of the SMS 2003 Advanced Client WMI classes.

2. Can WMI Diagnosis Tool realistically find serious WMI problems if the SMS client needs a healthy WMI infrastructure to work?

Yes, WMI problems can exist that do not impact the SMS 2003 Advanced Client. For instance, the Resultant Set of Policy (RSoP), which is based on WMI, can suffer from some WMI provider DCOM registrations that are not impacting the SMS 2003 Advanced Client while deeply impacting the RSoP feature. This principle could be the same for any components or software using WMI. WMI coverage is quite large in Windows and some components can work fine while others do not simply because their dependencies are different.

3. Is there a best practice for WMI Diagnosis Tool parameters to find common errors when deployed via SMS 2003?

WMI Diagnosis Tool default settings are set in such a way that the tool finds most common errors. When deployed with SMS, the SMS command-line parameter is recommended, mainly to prevent any screen echo and popup during execution. If you want to collect the WMI Diagnosis Tool LOG and CSV files in a central location, use the LogFilePath command-line parameter. It will be very easy to consolidate all results in the WMI Diagnosis Tool Excel spreadsheet as described in question #1 of the previous section.

4. Is Microsoft really recommending that customers send any WMI failures that occur from SMS clients?

Yes. It is always helpful to get direct feedback from our customers. This is also a good way for our customers to directly contribute. By leveraging our customer feedback and experience, we will improve customer satisfaction. Listening to problems and seeing how we can improve the product across service packs and new versions of Windows is our most important goal.

WMI Diagnosis Tool and MOM Questions