Dealing with WMI Issues – Part 1

One of the most common issues with SCCM client implementations is WMI errors. Unfortunately, while WMI errors are a common cause of problems, there is not a "one-size-fits-all" method of fixing them. In practice, there are three real approaches to addressing the problems and they are best used in a particular order to give one the best chance at success, but that is getting ahead of the game. First, we need to know that we have a problem.

Identifying WMI problems

Identifying WMI problems at client installation is pretty straightforward. If you look in the CCMSetup.log file (%WINDIR%\system32\ccmsetup\setup.log), you will see one of a number of symptoms.

• Errors registering WMI Namespaces
• Errors compiling .MOF files
• Most 1603 errors are related in some way to WMI issues

Identifying WMI problems post install gets a little harder. The most common way of finding these problems is looking at the Inventory log files. You normally will see a number of 800410XX errors in the inventory logs when WMI errors are creeping in

Phase 1 Repair

As mentioned earlier, there are 3 common approaches to addressing WMI errors: WMIDIAG, SCCM Client Console WMI Repair, and a Repository reset. In this first article, we will cover the WMIDIAG script.
WMIDIAG is a vbs script provided by Microsoft (Source at end of article) that addresses checking for common things that induce problems within the WMI subsystem. Some have said that you can run WMIDIAG with the SCCM client in place as long as it is shutdown, but I have found that if there are errors in the inventory files already you are usually better removing the client before getting started.
Removing the client is straightforward, simply run either ccmsetup /uninstall from the %WINDIR%\system32\ccmsetup folder or use the latest ccmclean utility by running ccmclean /client . Many times I will run the Client Wipe procedure used for duplicate GUIDs to make sure everything gets reset.
Once the client has been removed, one can start to address the WMI problems.
Simply copy the WMIDiag.vbs file local to the machine and run it. If you wish for it to run silently and simply record a log file of its activities, run it with the silent and logfilepath directives as shown below:
cscript wmidiag.vbs silent=true logfilepath=c:\temp


The script does a pretty good job of correcting permissions and registration based problems. Unfortunately, it is not a fast fix. On many machines, this process can take upwards of 5-10 minutes.
Once the WMIDiag script has completed, one can try to install the SCCM client again to see if you can get a successful installation. While this script doesn't end up being the stopping point for fixing many WMI problems, I have found it to do the most thorough job of checking to make sure that all of the fundamentals are in good working order. As a result, I usually start with this script.
Tomorrow, we will discuss the typical next step, the WMIRepair process from the SCCM Client Center from SourceForge.


WMIDIAG.VBS can be found at http://www.microsoft.com/downloads/en/details.aspx?familyid=D7BA3CD6-18D1-4D05-B11E-4C64192AE97D&displaylang=en