SCAPaoT

System Center, Automation, Powershell and other Thoughts

Archive for the ‘SCOM 2012’ Category

Single point of failure removed, mostly – SCOM 2012

In the upcomming version of System Center Operations Manager, SCOM 2012 Beta, the single point failure is removed.

There is not more Root Management Server. All management servers are equal to each other.

Really? Almost.
There is still a RMS, called RMS – Emulator.

If you can think of the old days of NT4,  and the concept of PDC and BDC, SCOM was working the same way till 2012.
Now it is more than Active Directory. The PDC is avaliable for older systems and some special things, called PDC-Emulator.

So the SCOM Team did it the same way. They decided to bring the RMS back as emulated version to keep the backward compatibility.
Management packs that rely on the RMS role, for example the exchange 2010 one, can be used without any restrictions.

And there are some new cmd-lets for the powershell to managed this old/new role:
Get-RMSEmulator and Set-RMSEmulator.
Also it is shown in the windows computer view, who has the role of RMS-E at the moment.

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