SCAPaoT

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.

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.

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.

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.

Since a few years, every consultant for SCOM is on it’s way to tell the customers: “Do not save anything into the Default Management Pack”

There where tips like renaming the Default Management Pack into something like: “Do Not Use This On”
And the best practise in every MP documentation to use a new MP instead of the Default MP.
Also there is a comunity MP that monitors the changes on the Default MP to give an early hint that there where things saved on.
And there are a lot of guides how to manually clean up the Default MP.

In SCOM 2012 Beta there was done some nice thing, helping keeping the Default MP clean.
If you disable a rule or a monitor, in SCOM 2007 it was save into the Default MP.
In 2012 Beta, it is not. But see your self:

As you can see:
Disabling a rule leads to the same dialog as overriding a rule does.
In here “Enabled” is checked and set to “false” 

And the best thing in here is: You have to select a Management Pack!
The Default MP isn’t selected by default. 

Thanks a lot Microsoft!

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 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.

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.

After having that issue at a customer,
I found a blog (http://gefufna.wordpress.com/2010/12/27/no-graphs-charts-are-included-in-scheduled-scom-reports/)  
and a corresponding kb article at Microsoft that describes that behavior.

http://support.microsoft.com/kb/972821/en-us

Not mentioned in the kb article is, that the written code has to be place between the <runtime> </runtime> section of the reportingservices.exe.xml file.
Also you have to be sure that the code is placed next to existing <dependentAssembly></dependentAssembly> sections if they already exist.
And, at least, the reporting services have to be restarted.

If the reporting services do not start up right after your modification, you wrecked up the xml structure.

When everything works fine, the report shows the graph like it does in the interactive view.

Yesterday, Microsoft released the cummulativ update pack number 4.

http://support.microsoft.com/kb/2449679

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,
Benedikt