WMI Diagnosis Tool general questions. 3
1. Where can I get the WMI Diagnosis?. 3
2. Are there any plans to include WMI Diagnosis Tool in new versions of Windows?. 3
3. Is there a WMI Diagnosis Tool version for beta testers of Windows Vista?. 3
4. Is it possible to "officially" engage Microsoft for feedback on this tool?. 3
5. Did Microsoft develop this tool as a script knowing that a lot of us will enhance it for our own uses?. 3
6. Is there any documentation describing what WMI Diagnosis Tool does not check?. 3
7. How much development time went into creating WMI Diagnosis Tool?. 4
8. Are there plans to document the top (say 25) problems customers find with WMI Diagnosis Tool?. 4
9. Do you plan to write future versions of WMI Diagnosis Tool in compiled code instead of a scripted version?. 4
10. Is it possible to store WMI Diagnosis Tool information in a SQL Server instead of a LOG file?. 4
11. Is there a release date planned for the next WMI Diagnosis Tool version?. 4
12. Is there an e-mail address to send feature requests for future versions?. 4
13. What are the new features planned for the next WMI Diagnosis Tool version?. 4
14. Is there an Internet BLOG for WMI Diagnosis Tool?. 5
WMI Diagnosis Tool usage questions. 5
1. How should you use the Excel spreadsheet that comes with WMI Diagnosis Tool?. 5
2. How do I know what to fix once the WMI Diagnosis Tool is executed successfully?. 5
3. Can you run WMI Diagnosis Tool in a RUNAS command?. 6
4. Can WMI Diagnosis Tool diagnose a remote computer?. 6
5. Can WMI Diagnosis Tool be remotely executed with PSEXEC.EXE on a remote computer?. 6
6. Can WMI Diagnosis Tool be run using “WMIC process call create”?. 7
7. Does WMI Diagnosis Tool fix problems it discovers?. 7
8. By limiting WMI Diagnosis Tool to check only one namespace, are you missing some possible error detections?. 7
9. If the repository has been deleted and the computer still has WMI errors, can this situation be resolved with WMI Diagnosis Tool?. 7
10. Can WMI Diagnosis Tool identify the problem and root cause of the repository growing very large (+300 MB)?. 8
11. Does the WMI Diagnosis Tool report on any security settings or problems with rights?. 8
12. Does WMI Diagnosis Tool output ERRORELEVEL codes?. 8
13. How can I determine if I am using the latest version of WMI Diagnosis Tool?. 8
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?. 9
15. Will the log have a unique name, or can you specify a log name (perhaps with computer name as a variable)?. 9
16. When running WMI Diagnosis Tool, can we combine multiple command line parameters?. 9
17. How frequent WMI Diagnosis Tool should be used?. 9
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?. 10
WMI Diagnosis Tool and SMS Questions. 10
1. Does WMI Diagnosis Tool work with SMS 2003 Advanced Client?. 10
2. Can WMI Diagnosis Tool realistically find serious WMI problems if the SMS client needs a healthy WMI infrastructure to work?. 10
3. Is there a best practice for WMI Diagnosis Tool parameters to find common errors when deployed via SMS 2003?. 10
4. Is Microsoft really recommending that customers send any WMI failures that occur from SMS clients?. 11
WMI Diagnosis Tool and MOM Questions. 11
1. Is there any ready WMI Diagnosis Tool Management Pack for MOM 2005?. 11
WMI questions. 11
1. Why is WMI broken as often as it is?. 11
2. Why did Microsoft develop WMI Diagnosis Tool instead of fixing WMI?. 12
3. Is there a tool or a method to uninstall/reinstall (refresh) all components (and non-core-OS dependencies) of WMI?. 13
4. Can you shed some more light on why WMI returns an 0x8004001 error so frequently?. 13
5. Where are the WMI errors documented?. 13
6. If we have already been deleting our repository as a way to remedy problems, could we have damaged anything in the process?. 13
7. How can we determine if the repository is actually corrupted?. 14
8. How does the WMI repository get re-created?. 15
7. WMI requests have long latencies, up to 3 seconds. Will this change in the future?. 15
8. What are the MOF files marked with #PRAGMA AUTORECOVER?. 16
9. Can you modify WMI/DCOM security remotely through command line utilities?. 18
10. Is there a list on microsoft.com that shows all known applications using WMI?. 19
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:
http://www.microsoft.com/technet/scriptcenter/topics/help/WMI Diagnosis Tool.mspx
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.
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.
There is no official support for WMI Diagnosis Tool. However, feedback for the tool is welcome and can be sent to WMIDiag@microsoft.com.
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.
No. However, this information – for WMI Diagnosis Tool version 1.1 – is briefly mentioned in the WMI Diagnosis Tool webcast.
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.
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.
There are not such plans. New versions of WMI Diagnosis Tool will still be scripted.
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.
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.
All communication related to WMI Diagnosis Tool should be sent to WMIDiag@Microsoft.Com.
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.
There is no BLOG specifically for WMI Diagnosis Tool. However, the WMI team has a BLOG at http://blogs.msdn.com/wmi/default.aspx.
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.
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.
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):
"Cscript.Exe C:\WMI Diagnosis Tool\WMIDiag.vbs
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.
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):
-u MyRemoteServer\Administrator -p MyPassword
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.
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
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.
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.
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.
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 3rd 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 3rd 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 3rd 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!
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.
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.
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.
The latest WMI Diagnosis Tool version is 1.10 dated the 8th of March 2006 at 13:26.
No. However, the Windows File Protection is handling problems regarding invalid versions of the Windows system files.
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
· 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
WMI DIAGNOSIS TOOL-V1.11_XP__.CLI.SP2.32_SERVER02_2006.03.08_04.52.42
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):
SMS LogFilePath=\\RemoteServer\RemoteShare SmtpWMIInvalidState
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.
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 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.
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.
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.
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.
At this time there is no specific MOM Management Pack for WMI Diagnosis Tool. Because WMI Diagnosis Tool is a tool using some advanced WMI features such as asynchronous calls, it can’t be executed as a management pack. With this in mind, WMI Diagnosis Tool could be leveraged by a management pack acting as a parser on the WMI Diagnosis Tool results produced in the LOG.
Based on feedback, we may eventually provide a WMI Diagnosis Tool MOM Management Pack but there is no committed plan at this time.
WMI is a pervasive technology in Windows, which interacts with a very large number of Windows components. These components provide information to WMI or consume WMI information. In both cases, the components rely directly or indirectly on WMI. If one of these components fails, even for a normal reason such as insufficient access privileges or an invalid request, WMI will return an error. However, the error returned to the WMI consumer or the provider does not necessarily indicate that WMI is broken. To isolate the error source, you must differentiate between WMI native errors and errors returned by WMI but originating in other components. To give a brief example of error categories:
· 0x800410xx and 0x800440xx are WMI errors. These error codes mean that a specific WMI operation failed. For instance, it could be due insufficient privileges to perform the WMI requested operation or due to the nature of the request itself (for example,. no WMI rights, bad WQL query) or due to a WMI infrastructure issue, such as CIM or WMI DCOM registration preventing a provider from being loaded.
· 0x8007xxxx are Win32 errors, not WMI errors. WMI may return these types of error due to an external failure (for example, DCOM security).
· 0x80040xxx are pure DCOM errors, not WMI errors. WMI may return these types of error due to an external failure (for example DCOM configuration)
· 0x80005xxx are ADSI errors (LDAP), not WMI errors. WMI may return these types of errors due to an external failure, such as an Active Directory access failure when using the WMI Active Directory providers.
Because WMI can return errors from other Windows components, WMI appears to be the root cause of all failures reported, which is a misperception. For instance, if a consumer issues a WMI request that fails due to a WMI provider DCOM registration issue, WMI will return a WMI error stating that the WMI provider cannot be loaded (WBEM_E_PROVIDER_LOAD_FAILURE). Obviously, this prevents the WMI operation from succeeding even though the problem is in the DCOM registration (which in this case can be fixed with the REGSVR32.EXE command).
Another example can be related to the WBEM_E_NOT_FOUND message. This message is generally due to a missing WMI class in the WMI repository. The requested WMI class can be missing for many reasons. For instance:
· A misspelled WMI class name issued by the consumer
· A correct WMI class name but the request attempts to connect to a WMI namespace where this class does not exist
· An improper or incomplete application installation, which failed to create all expected classes
· A MOF file containing the class definition that was not (re)compiled after a repository reconstruction
· A WMI repository corruption preventing location of the requested WMI class
In this last list of examples, WMI will return the same error message because the symptoms are the same. However, only the WMI repository corruption cause is a pure WMI core issue.
To help people in triaging and understanding the various errors and problems that can be encountered, Microsoft developed the WMI Diagnosis Tool to ensure that the right course of action is taken. Deleting the WMI repository is not the right course of action as a first action for most reported problems! Deleting the repository can create additional problems if not handled properly. The aim of WMI Diagnosis Tool is to help people to understand and fix problems that they encounter. Repository deletion and reconstruction is recommended only when truly needed and must be a last resort action.
Microsoft is working on two fronts: One front consists of addressing customer concerns and feedback for the new release, the other front consists of addressing customer concerns for existing releases. In the first case, Microsoft is making many investments to improve the WMI infrastructure like any other Windows components. In the second, Microsoft is both helping customers address problems they face in existing products and getting feedback on those problems at the same time. This second case is the aim of WMI Diagnosis Tool. Once Microsoft gains additional understanding and feedback about all problems encountered, the appropriate course of action will be taken to address these in the actual products or tools but also in the future versions.
No. However, WMI Diagnosis Tool will tell you if there are some WMI core files missing or incorrectly registered in the system and what to do to fix the situation. Some WMI dependencies are also analyzed by WMI Diagnosis Tool such as DCOM and RPCSS.
WMI returns a large number of error codes. Despite the fact that this series of error codes covers many specific situations, there are still cases that don’t fall into a pre-defined category. Cases out of these pre-defined categories generally return the 0x8004001 error code. After 10 years of experience deploying WMI (WMI has existed since the NT 4.0 era as a download from the Web), the number of cases outside of the pre-defined categories has increased with exposure. During the design of the WMI core infrastructure 10 years ago, most of these cases didn’t exist or were minimal and considered as edge cases. In this context, WMI has been obviously improved in many areas. However, it is very complex and risky to revamp the error management sub-system while maintaining a 100% backward compatibility with existing applications. This explains why WMI still returns such a type of “generic” error today.
WMI errors are documented on MSDN. WMI Diagnosis Tool also helps to understand what to do with most common errors reported.
By deleting the repository, WMI recovers most of the information the deleted repository contained, provided that the MOF files used to rebuild the repository are part of the auto-recovery process. If there are MOF files not included in this process (because they didn’t include the #pragma autorecover statement at installation time), then some components working with WMI may not work anymore. Generally speaking, the type of information lost can be classified into three categories:
1. Registration – the registration of the WMI providers supporting a set of WMI classes added to the system at installation time. This information can be recovered by re-compiling the MOF files if there are not in the auto-recovery process.
2. Classes – the set of WMI classes itself, which is used by any WMI consumers or the application itself at run-time. This information can be recovered by re-compiling the MOF files if they are not in the auto-recovery process.
3. Static Information- some static information created by the application at run-time and stored in the repository. This static information may not exist in the repository. This really depends on the application itself and the way it uses the repository. Generally, this information is not contained in any MOF files and the auto-recovery process does not re-create this information.
Items 1 and 2 can be easily fixed as long as you have access to the MOF files included with the application. These are not necessarily stored in the %SystemRoot%\System32\WBEM folder. Instead they can be located in the folder where the application is installed. If there is no MOF file available, then it means that the repository content for that application was programmatically created during the setup of the application (which is not the recommended approach). If this is the case, then there is no choice other than to re-install that application.
However, some applications provide MOF files but also have their own recovery approach. For instance, the SMS Advanced Client provides its MOF files but does not list these MOF files in the WMI auto-recovery process simply because the CCMRepair.Exe tool, located in %SystemRoot%\System32\CCM, automatically reinstalls the entire agent when some information of any kind is missing, such as registry or WMI repository information.
Regarding static information in the repository, if the application was dynamically storing information in the repository at run-time, it is clear that this information actually represents the real loss because that information must be recreated. Note that the WMI repository is part of the System State backup. Even though it is easy to obtain a System State backup of servers, it is generally much more complex to obtain and manage the System State backup of thousands of workstations.
This is exactly why the deletion of the repository must always be the last course of action and should be performed only when the WMI repository is really corrupted. This prevents the administrator from having to chase the MOF files installed with applications or simply reinstall the applications.
The WMI Diagnosis Tool checks the repository consistency with the CheckConsistency command line parameter. This validation is only supported under Windows XP SP2 and Windows Server 2003.
Systems running Windows XP SP2 and Windows Server 2003 SP1 can determine if the repository is really corrupted because the required instrumentation is available to make this determination.
Other operating system versions and Service Packs do not have the required tools and therefore do not offer a way to clearly make that determination. Therefore, it is highly recommended to upgrade systems to Windows XP SP2 or Windows Server 2003 SP1 in addition to the fixes that these platforms bring regarding the repository management.
WMI Diagnosis Tool leverages that instrumentation whenever available and returns the state of the repository in the WMI report:
.4979 20:17:19 (0) ** WMI repository state: .................... CONSISTENT.
However, when used in Windows XP SP2, if the repository is determined to be inconsistent, it is automatically rebuilt during the next reboot. Because this is a Windows XP SP2 design and not a WMI Diagnosis Tool design, by default WMI Diagnosis Tool verifies the repository consistency under Windows XP SP2 only when the CheckConsistency command-line parameter is specified. In Windows Server 2003 SP1, this switch is not required, as the consistency check is always made. On this platform, the repository is not rebuilt when it is inconsistent.
The repository gets recreated when it does not exist at the location where WMI expects to find it (at %SystemRoot%\System32\WBem\Repository). The recreation process leverages a registry key called “Autorecover MOFs” located at HKLM\SOFTWARE\Microsoft\WBEM\CIMOM. This key contains the list of MOF files to be recompiled with MOFCOMP when the reconstruction process takes place. For a MOF to be listed in that registry key, it must contain the #pragma autorecover statement. When the MOF is compiled and when that statement is found during the compilation, the registry is updated with the MOF path file name. If the statement is missing, the MOF will not be listed and the definition it contains will be missing from the reconstructed repository. This is why it is recommended to have this statement in every MOF file.
This really depends on the request issued. Normally, WMI does not have a 3 second latency for most requests issued. If this is the case, then there is a problem lurking in the installation and we would like to hear about it. For instance, if you locally request the list of all Windows services with the following WQL statement:
Select * From Win32_Service
With WMIC, it is:
WMIC path win32_Service get /Value
The response must be almost immediate (unless you are using WMIC for the first time on the system). Now if you execute the same operation remotely:
WMIC /Node:MyRemoteServer path win32_Service get /Value
The response could be slower because the list of Windows services comes from a remote location, which introduces a latency. Another example could be:
Select * From CIM_DataFile
Executed locally, this WQL query sample will be much slower than the previous one because it requests the list of all filenames that exist on the system, and a system may have thousands of files. Now, if you narrow the scope to the C: drive and only to the files located in the root directory, the response will be almost immediate:
Select * From CIM_DataFile Where Drive="C:" And Path="\\"
The nature of the WMI class queried, its scope, and the location where the query is executed greatly influence WMI responsiveness.
WMI is an abstraction layer on top of native APIs. Therefore, it aids access to the management information because it abstracts the use of native APIs with the WMI providers and the CIM class representations. Like any abstraction layer, it eases the access to information but it introduces additional hops that could impact the performance to a certain extent. On the other hand, native APIs are faster but much more complex to use directly.
Microsoft does not have a complete list of all MOF files that may contain the #pragma autorecover statement because many third parties and/or administrators can create their own MOF files and decide to make them part of the auto-recovery process. However, MOF files included in the operating system default installation are part of the auto-recovery process. MOF files included in a Windows XP SP2 installation and containing the #pragma autorecover statement are the followings:
MOF files included in a Windows XP SP2 installation and not containing, by design, the #pragma autorecover statement are the followings:
MOF files included in some typical Microsoft products such as Microsoft Office 2003, ASP.NET 1.1 and 2.0, and the Microsoft WMI Tools also contain the #pragma autorecover statement:
C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\MSINFO\OINFOP11.MOF
C:\PROGRAM FILES\WMI TOOLS\EVIEWER.MOF
There is no tool included in the operating system that can be used to modify WMI or DCOM security. However, this can be done under Windows XP and Windows Server 2003 with scripts. The scripting technique is pretty complex because it consists in reading the DCOM security from registry keys containing a binary blob representing the security descriptor. The conversion of the binary blob can be achieved with the IADsSecurityUtility ADSI interface documented on MSDN as follows:
' ADsSecurityUtility security descriptor components definitoon (ADS_SECURITY_INFO_ENUM)
Const ADS_SECURITY_INFO_OWNER = &h1
Const ADS_SECURITY_INFO_GROUP = &h2
Const ADS_SECURITY_INFO_DACL = &h4
Const ADS_SECURITY_INFO_SACL = &h8
' ADsSecurityUtility security descriptor format definition (ADS_SD_FORMAT_ENUM)
Const ADS_SD_FORMAT_IID = &h1
Const ADS_SD_FORMAT_RAW = &h2
Const ADS_SD_FORMAT_HEXSTRING = &h3
' Make sure you have the registry key binary blob in arrayBinSD
strHexSD = ConvertBinDataToHexString (arrayBinSD)
Set objADSSecurity = CreateObject ("ADsSecurityUtility")
objADsSecurity.SecurityMask = ADS_SECURITY_INFO_OWNER Or _
ADS_SECURITY_INFO_GROUP Or _
ADS_SECURITY_INFO_DACL Or _
Set objSD = objADSSecurity.ConvertSecurityDescriptor (strHexSD, _
' Here you have an ADSI Security Descriptor representation
' Decipher/Change the ADSI Security Descriptor here!
Function ConvertBinDataToHexString (arrayBinData)
Dim strbyte, intIndex
On Error Resume Next
For intIndex = 0 to UBound (arrayBinData)
strbyte = Right ("0" & Hex (arrayBinData (intIndex)), 2)
ConvertBinDataToHexString = ConvertBinDataToHexString & strbyte
Once you have an ADSI Security Descriptor object, it is possible to decipher the security descriptor in ACL and ACE by using the ADSI security descriptor object representation documented on MSDN.
There is no official list of applications using WMI. However, the words “using WMI” must be clarified. This means consuming and providing WMI information, which, for the latter, can be consumed by any WMI consumers. Although it is almost impossible to provide a list of the WMI consumers, because ANY scripts and applications in the world could consume WMI information, the number of WMI applications providing WMI information is fairly limited (outside of the operating system). Here is a list of applications that Microsoft knows about (this list is not exhaustive and anyone is welcome to let us know any application providing WMI information that is not on that list by sending an email to WMIDiag@Microsoft.Com):
Systems Managerment Server
Microsoft Operations Manager
Host Integration Server
Automated Deployment Services
Exchange Server 2000/2003
Microsoft Office 2000/2003
SQL Server 2000/2005
Microsoft Identity Integration Server
Microsoft Office Live Communication Server (LCS)
Audit Collector Service (ACS)
Not released yet.
Windows 2000 -> Vista
2000: 29 Providers, XP: 57 Providers, 2003: 83 Providers, Vista Client: 70, Longhorn Server: +110
Intel Network drivers
MetaFrame Enterprise Edition
HP/Compaq Insight Manager Agents
Tucows Asset Logger
IPSwitch WhatsUp Professional