System Center, Automation, Powershell and other Thoughts

Archive for the ‘Operations Manager’ Category

Power Shell Script failed to run – SCOM 2012 Beta

After installation of the actual version of SCOM 2012 beta, we encountered the following error:

Power Schell Script failed to run (see Screenshot)

Searching for the script, we stumbled over a new management pack called “Microsoft SystemCenter OperationsManager Summary Dashboard”

As part of this management pack, there are three discoveries that failed running its Powershell script.
So we extracted one of this scripts and found, that the error was trown by $mp.GetDisplayString($lang) while $lang is filled by the get-culture commandlet.

Execution of get-culture while logged in with the SCOM action account delivered:

LCID             Name             DisplayName
—-             —-             ———–
1031             de-DE            Deutsch (Deutschland)

So we changed the cultur of all system accounts to en-US and the error was gone.

Hopefully this error get fixed in the future being independend from the language, like the powershell already tries to be.
So only the if() case need to have a executionpreference set to continue for fixing the error permanantly.

A bug is reportet at


Orchestrator 2012 Beta Integration Pack for SCOM not working on SCOM 2012 Beta

The Integration Pack for System Center Operations Manager, released for Opalis 6.3 but also avaliable for System Center Orchestrator 2012 Beta does not work with System Center Operations Manager 2012 Beta.

It’s caused by a change inside the SDK.

You can see the error here:

So, I have to create my own activities / powershell scripts for creation of alert or setting maintainance in SCOM 2012 Beta.

Set Resolution State directly in SCOM 2012 Beta

Ok, most of you might not care about those little things that changed inside of SCOM 2012 beta, but there are really nice changes.
The first thing I regcognized was the Deauft MP is not set as default.

Second, little but nice, extra:

You can set the resolution state of an alert directly without opening the properties of an alert.

At many of our customers, there are custom resolution states established. So alerts are set to “In Progress” for example. So everybody knows the alert isn’t new and a supporter has started to resolve it.

Before SCOM 2010 Beta, the user had to open the alert to set these value.

OperationsManager DB is growing fast

A customer installed a new instance of Operations Manager 2007 R2 CU 4 and added some management packs for monitoring server, sql, active directory and exchange.

Also the agent was deployed to 10 servers in the infrastucture to tune the managment packs.

After round about one week, the OperationsManager database size was 4GB.

Five days later, it was at nearly 8GB big.

So the customer asked, if that growing is as expected and was surprised, that we told him, it should be quite below 1GB with this amount of management packs and agents.

To get a handle on the fast growing of the database site, I stumbled over a create blog from Kevin Holeman about “Useful Operations Manager 2007 SQL queries”.

Yes, it is an old article, but it is the best for finding spammers that fill up the database by running some queries against it.

In conclusion:

The unexpected database growing was caused by the event collection rule from the exchange management pack and a leftover form exchange troubleshooting that traced verbose into the eventlog on a mailbox server.

Thanks Kevin for an other very usefull blog post.

System Center Operations Manager 2007 R2 Cumulative Update 4 released

Yesterday, Microsoft released the cummulativ update pack number 4.

Before you are going to install it, read the corresponding documentation twice.
Also make sure, you follow the steps written in the KB article.

I would recommend to install it at a test environment at first (if you have).
For production environments, wait round about 2 weeks to get the most issues found by the community.

But after that time don’t miss to install the CU4.

Kind regards,

SEP 11: Pattern File Age Monitor

A customer asked me to monitor the age of the pattern files of the Symantec Endpoint Protection 11 Client (SEP11) on its server systems.

As I didn’t found an Symantec SEP Management Pack, I decided to create it on my own.

Perhaps someone could make use of it too, I decided to show it step by step.

Lets start

In the Authoring view select Monitor and “Create a Monitor” on the right site.

1. Select the Monitor type to create: “Timed Script Three State Monitor”
2. Change the Management Pack, for example, create a new one called “_SEP”

3. Name the Monitor and add a description
4. Select the target for the monitor: (in our case, all computers) Windows Computer
5. Make sure that “Monitor is enabled” is checked

6. Set a value how often the monitor will run and check for the pattern file age
(normally once a day should be enough, but that way it would take also one day to close the alerts automatically if the pattern are updated)

7. Add a script name (make sure that the name of the script is unique to avoid conflicts with other Management Packs)
8. Add the script that collects the pattern age from the registry of the computer system

Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
const HKEY_LOCAL_MACHINE = &H80000002

badState = 10
warningState = 5

Set objRegistry = GetObject("winmgmts:root\default:StdRegProv")
strKeyPath = "SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\AV"
strValueName = "PatternFileDate"

objRegistry.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath, strValueName, strValue
If IsNull(strValue) Then
 strKeyPath = "SOFTWARE\Symantec\Symantec Endpoint Protection\AV"
 strValueName = "PatternFileDate"

 objRegistry.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath, strValueName, strValue 

End If

If Not IsNull(strValue) Then

y = 1970 + strValue(0)
m = 1 + strValue(1)
d = strValue(2)

date1 = CDate(y & "/" & m & "/" & d)
date2 = now
diffdays = DateDiff("d",date1, date2)


diffdays = -1

End If

if diffdays >= badState then

 Call oBag.AddValue("state","BAD")
 state = "BAD"

if diffdays >= warningState then

  Call oBag.AddValue("state","WARNING")
 state = "WARNING"
 Call oBag.AddValue("state","GOOD")
 state = "GOOD"
end If

end if

Call oAPI.LogScriptEvent("SEPPAtternFileState.vbs", 101, 2, "Patternstatescript delivered state " & state & ". Pattern File age is " & diffdays & " days.")
Call oBag.AddValue("PatternDateTimeToNowDiff",diffdays)

Call oAPI.Return(oBag)

9. Add the BAD state. (If the script returns a BAD)

10. Add the WARNING state. (If the script returns WARNING)

11. Add the GOOD state. (If the script returns GOOD)

12. Set the monitor state corresponding to the script result.

13. Enable the check box for alert generation
14. Change the dropdown “Generate an alert when: The monitor is in a critical or warning health state”
15. Add an alert name (this is what you’ll see when the error is thrown)
16. Change the severity to: “Match monitor’s health”
17. Add an alert text. Mine can be found here (it includes the computer name an the age of the pattern files and a few common resoulution possibilities)

SEP Pattern files on $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$ are $Data/Context/Property[@Name='PatternDateTimeToNowDiff']$ days old!


1. Please check if enough space on systemdrive left.

(app. 400MB)

2. Check if Live Update Server is reachable

3. Check if SEP Service is running

4. Reinstall SEP Client


Using these steps you can easily add the SEP pattern file age monitor to your SCOM.
Things you can do if you want to make it more professional:

  • build an management pack including discovery for computers where SEP is installed
  • add parameters for overrides, so warning and error threshold can be overridden without changing the script
    (actualy it will warn if pattern are 5 or more days old and error when pattern are 10 or more days old)
  • this script can also be used to build a rule for performance collection

But this way, it is done in round about 5 minutes.

Kind regards,

KMS MP: Idle Minutes Monitor Alert

A customer of mine had several “Idle Minutes Monitor Alert” raised by the Key Management Server MP.

The eventlog for KMS on the KMS Server stated, that there was an KMS request round about every 30 seconds.
So the error was definitiv a false positive.

The treshold for the monitor was default (480 minutes).

I inspected the monitor and saw in the configuration, that the last activity in KMS is stored in the operations manager.
These values are inserted through a scheduled discovery that runs every 15 minutes.

I exported the management pack and had a look on that discovery. There I found an VBS script that does a lot of WMI queries.

As the KMS Server is a Server 2008 R2, and there is a WMI Memory Leak on excessive usage of WMI, I installed the corresponding hotfix and the error was gone.
This hotfix is: KB981314 (

Kind regards,


Failed Accessing Windows Event Log: Microsoft-Windows-BranchCache/Operational

I stumbled about the following warning at a customer:

The warning was thrown for several servers and claimed, that the special eventlog for the feature “branch cache” was not able to be read.
Inspecting the systems didn’t show up that the branch cache feature installed.
Also netsh branchcache show status brought up the message: “This command can only be executed when BranchCache is installed.”

The problem was, that branch cache was installed on the systems brought up a warning, but not needed anymore.
While they where installed and configured, SCOM has discovered the systems.
So I installed the brach cache feature again, set the branch cache to disabled using netsh and uninstalled branch cache feature.

After that I disabled the discovery rules shown in the screenshot below.

Next step was to remove the disabled discoveries from the database using the powershell.


After that, I removed the disable overrides.

So the warnings didn’t appear again.

SCOM R2 Agent push failed with error 80070102 and 8000FFFF

We had several new server with Server 2008 R2 that where identically installed.
On non of this systems we where able to push out the scom agent.

A look at the push log file on the management server (gateways in our case) showed the error message 8000FFFF and something about: registering a firewall rule failed.

Strange, the firewall was disabled on all systems. So, we had a look at the rules on one of the servers and saw a rule called “MOM Agent Installer Service”.
Deleting this rule started to make the push work like a charme.

Digging into the closed monitors on the SCOM, we saw, that the first push failed with the message:
“A system update is in progress”.

So, because of the windows update reboot while the first push was tried, the agent wasn’t installed, but the firewall rule not deleted successfully.


If push fails with error 80070102 and 8000FFFF in the log, have a look at the firewall on the system, even it is disabled.