That’s right – more WMI adventures. Today we’re going to take a look at a problem that we recently encountered with a customer whose WMI script did not return any Event Log information – but the Event Logs themselves were functioning with no apparent issues. In this particular instance, the customer was using a script to retrieve Event Log information – the Application, Security or System Logs were not returned, but the DNS, NTFRS, NTDS etc logs returned fine. A conundrum indeed! First, let’s take a look at a sample script that is very similar to what the customer was using:
All this script is designed to do is list out the different Event Logs. When I run this on my Windows XP system, I get the following result:
There were no problems with the permissions on the WBEM folder, and changing the log file sizes didn’t resolve the issue either. There was obviously something not quite right with WMI somewhere though. Some elementary troubleshooting using WBEMTEST (steps below) revealed that there was a problem with the data in the repository when comparing a system that worked with one that did not.
STEPS TO CHECK THE REPOSITORY USING WBEMTEST 1. Launch WBEMTEST and connect to Root\CIMv2 2. Enumerate all classes recursively 3. Locate the Win32_NTEventLogFile class (referenced in the script above) and double-click it 4. Once the next window opens, click on "Instances" to see what data is in the repository 5. On the non-working system, the entries for the Application, System and Security logs were missing
And below is the screenshot of what the results look like (again, this is from a working machine):
What happens when the script is run is exactly what we did with WBEMTEST – query the provider and return the data. But where does the provider get its data from? In this specific instance, the provider opens the registry key for the Event Logs (HKLM\System\CurrentControlSet\Services\EventLog) and enumerates all the subkeys. Each subkey represents a log. So the first thing to check would be the permissions on these subkeys. Assuming the subkeys are correct, the next thing to look at would be what information the provider needs from within the subkey. For the Win32_NTEventLogFile provider, it reads the value named “File”. Things to check here – does the value exist, and what is its type. Based on the value returned in our example, it should be a REG_SZ or REG_EXPAND_SZ (string values).
Assuming that the subkey exists, and the value exists, the provider asks the CIM provider to populate the Win32_Datafile subset of properties using the “File” value as the path to the log file. The obvious things to check here are whether file referenced in the registry value exist? What are the permissions on the file? Does the value contain references to environment variables that don’t exist (for example, is the variable %SYSTEM% as opposed to %SYSTEMROOT%?).
So as you can see, narrowing down why a particular WMI script, or portion of a script fails can be accomplished by understanding what the WMI provider does on initialization. By following the initialization process we are able to identify where the problem lies.
That’s it for this post – thanks for stopping by! Until next time …
|Share this post :|