If you have never worked with Microsoft PSS, PFE, QFE, MCS, RRE, or any other arm of their professional support staff you may not be aware of the tools that these army of men and women come equipped with to resolve issues.  These are often home grown, field developed, custom tools that these same folks have written to help customers and the support staff at Microsoft quickly resolve issues and the WMIDiag tool is a prime example of this.  Often these tools are used only by the Microsoft staff and are not given to the public to use and I can only speculate here (sorry Bill) but I am going to say that they hesitate to give these tools to customers for two reasons, first because they would have to support these tools if they provided them to customers and secondly because they help generate revenue.  I know it is hard to believe but Microsoft is actually in this business to make money and providing support is costly and giving away tools that they use to generate revenue would probably cause them to lose money, a lose lose situation for them.  But often times these tools do make their way to the public and are available on the Microsoft Download site, WMIDiag v1 and v2 are prime examples of these as well as the recent VMRCPlus tool.

WMIDiag Overview

WMIDiag was developed by Alain Lissoir who works on the WMI team at Microsoft, I can't say if this was developed as a support tool that made its way to the main stream because of its usefulness or if it was specifically developed for customers but I am thinking the later.  WMIDiag is a VBScript that helps you diagnose issues with WMI on a computer and suggest resolutions to issues it discovers, in many cases step by step detailed instructions on resolving the issue.

Why You Should Care

WMI has become more stable in recent months, there was the additional improvements that Microsoft made to WMI with Vista, although I was not able to ever ascertain specifics on what this actually means, then the same improvements were made available in an update for Windows Server 2003 and then Windows XP.  But as an IT admin, and even more specifically an SMS Engineer or SMS anything, WMI is critical to a reliable working SMS hierarchy.  As companies move to ConfigMgr this will become even more important, not only for the clients but for the ConfigMgr servers also as vendors and others plugin to the providers and create their own classes in WMI. 

Each week I receive several emails from people who have come across my blog and have a support related question and one of the most difficult problems to diagnose and resolve is WMI issues.  WMI problems can often result in incomplete patching, often to the point where SLA's are not met, clients no longer reporting and eventually being marked inactive and removed from the SMS db, preventing the install of the SMS client using any method, and countless hours spent at the users desk trying to determine the root cause.  WMI can be a very painful and difficult thorn in the side of an SMS admin.  With my job I get to see quite a few SMS installs and if you are feeling these pains you are not alone - trust me!

So why should you care?  Because your other options of fixing WMI are to delete the repository, an absolute last resort tactic, use other tools, to manually test the repository and remove the offending class manually, or just examine it yourself (why?).  None of these are high on the priority list for a busy SMS admin unless you have had recent events that warrant the extra attention.  Usually the number of clients having problems leaves the lowly SMS admin just shaking their head and dealing with tasks that they can cope with.

A side note on this last point, I heard for years that you should not rebuild the repository but no one that I asked could ever really tell me why other than they heard it from someone else so I eventually took it upon myself to figure out why.  When the repository gets built it runs through the MOF files and if the file contains a #PRAGMA AUTORECOVER statement then it will rebuild those classes into the repository.  If the MOF file does not have this entry, you guessed it, it gets left out.  So now you have an application installed with no corresponding classes or methods in WMI so when you try to do an operation or another application tries to use its class you get an error, or maybe nothing.  The easiest way to fix this is to reinstall the applications but this can be very time consuming.  This also causes the SMS Client to kick off a reinstall of the client including a full hardware and software inventory!

Modes Of WMIDiag

As I mentioned above you can run this tool as an SMS package and it has built in support to run silent you only need to add the SMS switch to the command line and it will set the tool to not display any output to the user or return the exit code when it completes as to not confuse SMS into thinking something bad has happened. 

You must run this tool locally on the system and cannot run it remotely against a list of machines without using SMS or a similar method, this is because it does not rely on WMI to get its data it actually runs under WSH to collect the data it needs and because of that you cannot use the impersonate method you are accustom to with WMI, you must also have local admin rights when starting it on the system.  I could debate this issue and most of you could probably get this to work remotely but I am not going down that path today.

Here are some of the other switches and functionality of WMIDiag. 

Display
  • Silent - No prompts to the user (except help)
  • NoEcho - Will not display current status of diagnostics to the screen
  • SMS - Configures the tool to run as an SMS package (see above)
  • ShowMOFErrors - Will display MOF errors
  • ShowLoadedProviders - Will display the currently loaded WMI providers
  • ErrorPopup - Will display a dialog box if an error is encountered
Running
  • Force - Runs WMIDiag even if the user does not have admin rights
  • Depth - Specify the level of checking in the WMI hierarchy (1-4)
  • RequestAllInstances - Retrieves all dynamic and/or static classes Static/Dynamic/StaticAndDynamic
  • WriteInRepository="root\namespace" - This check should be used to determine if you can still write to the WMI repository.  This will temporarily create a class under each instance of the WMI namespace specified.  It will default to root if you do not specify a namespace.
  • CheckConsistency - Will check the consistency of the WMI database.  If this check fails, the repository will be rebuilt automatically in XP, in Server 2003 this always runs but does not rebuild the repository unless you manually specify it.
  • RunOnce - Prevents the tool from running more than once a day, not 24 hours but day.
  • BaseNamespace = "root\name space" - This will cause the tool to only check the specified namespace and its classes instead of checking every single one in WMI.  For example the CCM namespace would be a good place to start.
Logging
  • LogFilePath - Specify the path to store the log files and csv files
  • LoggingLevel - Sets logging level
  • OldestLogHistory - Will remove the log files and csv files older than n days (1-365)
  • LogNTEvents - This will force all messages to be recorded in the event log
  • LogNTEventErrors - Will log only error messages encountered to the even log instead of all messages
  • LogWMIState - The scaled down version of LogNTEvents, this also writes to the event log but only the start and finish time, and the health of WMI.
  • DisableWinZip - Will prevent the compression of the log files
  • OldestEventLogHistory - Gets events from the event log as far back as n days
SMTP
  • SMTPPort
  • SMTPAuthenticate
  • SMTPSSL
  • SMTPUsername
  • SMTPPassword
  • SMTPFrom
  • SMTPTo
  • SMTPWMIInvalidState
  • SMTPTest

The SMTP switches will report your troubles to Microsoft (by default).

 

Using The WMIDiag Tool

You can run this by simply double clicking it, you can launch it from the command line, run it as a package in SMS, the method is up to you.  When you launch it the tool starts by first verifying that you have the required rights to run the tool successfully, it then creates the log and csv files, begins the diagnostics, and then the checks of WMI.  This can take anywhere from a few minutes to over 10 minutes to possibly hours, in some cases it can cause the computer to become unresponsive during the time it runs.  It will depend on the level of checking and logging you set when you launch the tool and the computer.  The list of tests performed can be found in Appendix A on the WMIDiag page.

After it completes and depending on how you configured the tool to log the information it found you can examine the results in event log (app), and the .log file it created.  Open the .log file and do a search for "Report" this is the information you are looking for, it will show any errors or warnings, warnings can often be ignored but errors should be examined and accompanied by steps to resolve the error.  Some errors will cause WMI not to function while others may cause annoying problems for applications.  You should examine the list of errors on the WMIDiag web page to determine how serious your error is.

 

Real World Use

Here are some example scenarios of using this tool and the associated command lines that go along with it.  

A monthly check of all WMI namespaces on all SMS clients where the error logs are copied to a central store and compiled into a single Excel spreadsheet.

Assumptions: You have, or will create, a SMS package and program with an advertisement that reoccurs on monthly basis.  I would suggest you schedule this to run during off hours this can slow down machines and take some time to complete.  The package source directory contains the WMIDiag.vbs file and it set to download and execute not run from the server.  The package is set to run as admin and whether or not the user is logged in.

Command line:  WMIDiag.vbs SMS RunOnce LogFilePath=\\serverName\Share OldestLogHistory=23

Explanation of command line: The SMS switch tells the tool to run silent and suppress popups,

the RunOnce will prevent the tool from running twice in the same day and this is added in as an insurance policy incase the computer restarts during the package running SMS will tell it to start over but this switch will keep the tool from starting again,

the LogFilePath switch tells the tool where to copy the log files to, the last switch will delete any log files for the client that are over 23 days, the reasons will be clear when you read the next three paragraphs.

After all of your clients have run the tool you can then compile all the results into the WMI Diagnostic spreadsheet by following these instructions.

On the server in a command prompt navigate to your share where the log files have been stored and then type copy /a *.csv Data.csv this will combine all of the spreadsheets into one.  After that completes open the Data.csv file and click the top left corner selecting all the columns and rows in the worksheet and then use Control-C to copy the data. Next open the WMiDiag.xls file that comes with WMIDiag and then paste the data into the DATA spreadsheet.  This should produce a very nice report for all of your clients giving you a very nice picture of the health of WMI on your SMS clients! 

If you want to make it really slick you can create a custom macro that will use the copy command to combine all your spreadsheets the day after all your clients run the package, and then pastes the results into the DATA tab, and then deletes the clients spreadsheets from the share.

A monthly check of WMI on all SMS clients where the errors are reported to a local email alias.

Assumptions: You have, or will create, a SMS package and program with an advertisement that reoccurs on monthly basis.  I would suggest you schedule this to run during off hours as it can take up to two hours to complete an entire check of WMI.  The package source directory contains the WMIDiag.vbs file and it set to download and execute not run from the server.  The package is set to run as admin and whether or not the user is logged in.

Command line: WmiDiag.vbs SMS RunOnce SMTPServer=SMTP.ConfigMgr.com SMTPFrom=localhost@ConfigMgr.com SMTPTo=WMIDiagTeam@CongifMgr.com SMTPInvalidState

Explanation of command line: The SMS switch tells the tool to run silent and suppress popups,

the RunOnce will prevent the tool from running twice in the same day and this is added in as an insurance policy incase the computer restarts during the package running SMS will tell it to start over but this switch will keep the tool from starting again,

the SMTPServer= switch indicates your local SMTP relay server to use when sending the email,

the switch SMTPFrom is just an indication of who is sending the email you can play with this to make your own custom from,

the SMTPTo switch is the email address that the email is going to be sent to if you leave this switch out and include the other two SMTP switches you will send the email to Microsoft instead. 

The last switch, SMTPInvalidState tells the tool to only send an email when there is an error or warning reported and keeps you from sorting through emails to determine which ones are in need of help.

 

Regards,
Anthony

Anthony Clendenen | Solutions Engineer | 1E Inc.


image002

http://configmgr.com

© 2007 Anthony Clendenen

I Recommend These Books!
SMS 2003 Administrator's Reference: Systems Management Server 2003 -  SMS 2003 Recipes: A Problem-Solution Approach  -  Microsoft SMS Installer (Book/CD-ROM package)  -  Pro SMS 2003  -  Professional MOM 2005, SMS 2003, and WSUS  -  Start to Finish Guide to Distributing Software With Systems Management Server 2003  -  Microsoft Systems Management Server 2003 - Administrator's Companion

And you can check out more books and gadgets at my Amazon store here.



Trackbacks

No Trackbacks

Comments

No Comments