As you deploy the latest OpsMgr R2 core MP updates version 6.1.7599.0 which I blogged about HERE, you will probably notice a new script error popping up in your environment:
Alert Description:
The process started at 10:36:57 AM failed to create System.PropertyBagData. Errors found in output:
C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 2\4885\SCOMpercentageCPUTimeCounter.vbs(125, 5) SWbemRefresher: Invalid class
Command executed: "C:\Windows\system32\cscript.exe" /nologo "SCOMpercentageCPUTimeCounter.vbs" servername.domain.com false 3
Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 2\4885\
One or more workflows were affected by this.
Workflow name: Microsoft.SystemCenter.HealthService.SCOMpercentageCPUTimeMonitor
Instance name: servername.domain.com
Instance ID: {50E57AC1-08CC-6E7E-149A-1E8690881BBD}
Management group: MGNAME
This is caused by a new script based monitor (Agent Processor Utilization) and collection rule (Collect agent processor utilization) that was added to this core MP… which measures the agent CPU impact, including the Healthservice, MonitoringHost, and all ancillary processes spawned by the SCOM agent. This monitor and rule targets the Health Service class:
Both the monitor and rule share the same script datasource – so make sure if you override ANYTHING on one, you make the SAME override on the other…. otherwise you will break cookdown for the datasource.
The problem is – there is a fair percentage of Windows Servers – that for some reason randomly will have a problem with WMI health, or (more likely) will not have the WMI performance counters enabled for Perfproc.dll, which this script needs in order to measure the CPU.
This is not a big deal… but until you fix this – the monitor wont work…. and will throw these script errors on a regular basis.
The good thing is – this issue is fully documented in the guide that ships with these new MP’s. You DID read the guide first – didn't you? :-) The guide lists many possible steps to go through in order… I will discuss the most common resolution I am seeing in the field, below.
So – gather a list of all servers throwing this specific script error for “Invalid class” on “SCOMpercentageCPUTimeCounter.vbs”, then make plans to fix them. This will likely require a reboot – so keep that in mind. Another alternative is to fix them now, and then let them get rebooted on their next patching cycle if that works better for you.
What is typically seen – is that there is a missing WMI class, due to the WMI perf counter being disabled. Right now this appears pretty random…. I have three VM’s all built from the same media on the same day – and one out of those three had this issue. I recently worked with a customer who had 4 machines out of 16 missing this perf counter. Here is an example of the WMI class we are looking for: (Run wbemtest, connect to root\cimv2, then click Enum Classes, select recursive, OK)
Luckily – the fix is VERY simple. There is a tool you can download and install on your workstation – and remotely connect to each machine and fix them:
Windows 2000 Resource Kit Tool : Extensible Performance Counter List (exctrlst.exe)
http://www.microsoft.com/downloads/details.aspx?familyid=7ff99683-b7ec-4da6-92ab-793193604ba4&displaylang=en
Using this tool – connect to \\servername and click refresh. Sroll down in the list until you find “PerfProc perfproc.dll”. What you will likely find is that this class is disabled.
Simply check the box to enable it… and then reboot the machine at your convenience.
This will persist the class in WMI and the script error should go away.
Other errors from this script:
Now – if you are getting some OTHER error – not “Invalid Class”… this is likely an environmental problem with your server. I would walk through all the steps called out in the guide for this issue. If those don't work – then try some of these:
- Connecting to WMI using WBEMTEST, root\cimv2 and seeing if there is a WMI issue.
- Ensure WMI service is running.
- Ensure OS is healthy and not experiencing severe memory pressure.
- Reboot server
- Run script manually: copy the script from the \Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files\<numeric>\ location in the alert – to a local temp directory… then run it manually at a command prompt. For instance – I search the “Monitoring Host Temporary Files directory for SCOMpercentageCPUTimeCounter.vbs to find a copy of the script, copy it to C:\temp\, and then run: cscript.exe /nologo "SCOMpercentageCPUTimeCounter.vbs" servername.domain.com false 3. Change the FQDN in this example to your actual servername FQDN you are testing it on. This should return a XML propertybag that looks like:
If you don't get a XML propertybag returned – then something is broken…. you can look and see if you get an error returned, or if nothing…. then make sure you gave the script the correct expected parameters as above, then start debugging the script.
Another example I am seeing is the following:
The process started at 6:56:10 PM failed to create System.PropertyBagData. Errors found in output:
C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 2\1220\SCOMpercentageCPUTimeCounter.vbs(124, 5) Microsoft VBScript runtime error: ActiveX component can't create object: 'WbemScripting.SWbemRefresher'
This happens on Windows 2000 servers. This note came from a reader comment: It appears from http://msdn.microsoft.com/en-us/library/aa393838(VS.85).aspx that this Script API is only supported on Windows XP/Windows Server 2003 and up – so it is likely that this script will not work on Windows 2000 Servers. If that is the case, you can disable this monitor AND rule for all Windows 2000 Computers, by overriding this monitor AND rule – for a group – and choosing the “Windows 2000 Server Computer Group”. That should make these errors go away for old legacy systems you might still be monitoring.