SCAPaoT

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 connect.microsoft.com.

Actually there is a bug within an update, that replaces the conhost.exe on Server 2008 R2 systems that do not have SP1 installed.
At these serversystems the eventlog for application is flooded with “EventID 33,  SideBySide” pointing towards conhost.exe and a missing assembly.

For further details on that error see the following KB article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;977648

 The corresponding hotfix can be found here:

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=977648&kbln=de

At a customer, there are many servers with 2008 R2 installed.
So we decided to build a monitor in SCOM that displays an information for every system that hasn’t been updated with the hotfix or an sp1 installed.

The monitor fires the following script, checking the fileversion of conhost.exe.

Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()

Set objFSO = CreateObject("Scripting.FileSystemObject")
conhostVersion =  objFSO.GetFileVersion("c:\windows\system32\conhost.exe")

If InStr (1,conhostVersion, ".16823", 1) > 0 Then
 Call oBag.AddValue("Status","BAD")
else
 Call oBag.AddValue("Status","OK")
End If

Call oAPI.Return(oBag)

So after enabling the monitor, we have 138 servers left to patch.

Kind regards and happy patching.

A customer had the error that scheduled reports where not sent out from the SCOM 2007 R2.
In that case, the status of these schedules where: Error: Thread was being aborted.

There was no more error in the eventlog or any other location that pointed out to an error.
Also if the reports where opened from the opsmgr console, they where shown fine.

So one thing we figured out was, that the time slot for the reports was really big.
For example: Get CPU-Usage Performance for 5 Servers for the last year.

So we had a look at the server usage at the time when the scheduled report should have run and found that the server was under big pressure at that moment.
We recommended to move the reportingservices to an other machine for running the reporting services only and to spread the reports all over the days.

Now also big reports are generated as requested.

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.

Conclusion:

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

When implementing a new management pack for SCOM 2007 R2, most of the time I try to use Powershell instead of VBScript.
For the development I normally use notepad++, but since this wasn’t installed at customers’ I tried using the ISE.

After an hour of troubleshooting, I switched to the console host of Powershell, and the script was working as suspected.
The code that confused myself are only a few lines:

$api = new-object -comObject 'MOM.ScriptAPI'
$bag = $api.CreatePropertyBag()

$bag.AddValue("test","123")

$api.return($bag)

Running the code in the ISE returns: NOTHING

Running it in the normal console host, retruns the xml structure of the SCOM property bag as suspected.

So, using notepad++ and the consolehost for deployment of managment pack scripts is my recommended way at the moment…