SCAPaoT

At @teched they spoke about some nice features in the upcoming service pack of SCCM 2012.

These features are things like Linux and Mac management, sending emails on error or pin support for bitlocker.

But my personal favorite is the, that there will be a powershell provider for SCCM.
Perhaps you remember my post written in earlier days (Mai 2010): http://www.scapaot.de/blog/?p=57 and http://www.scapaot.de/blog/?p=69

I can’t wait to get the wmi scripts gone.

So, hopefully SP1 will come soon!

CU
benedikt

We have released a new version of our bitlocker pin tool.
You can get it here: http://blpintool.codeplex.com/

The tool is a compiled version of the bitlocker WMI methods to get a bitlocker startup pin set by a user.

This version is asking for admin credentials if UAC is enabled.

Also we have started a new discussion for “Feature Request”.

http://blpintool.codeplex.com/discussions/287612

If you have any suggestion or wish you can enter it here.

We stumbled over the following error while trying to push out agents:

Failed Agent Push/Repair – Could not remotely verify agent operating system version

Full Event Description:

The Operations Manager Server cannot process the install/uninstall request for computer IAUSYDIN0004.network.zz due to failure of operating system version verification.

Operation: Agent Install
Install account: NETWORK\systemservice
Error Code: 80070035
Error Description: The network path was not found.

Sure, there is a blog from Kevin Holeman with error-numbers (http://blogs.technet.com/b/kevinholman/archive/2009/01/27/console-based-agent-deployment-troubleshooting-table.aspx). But the error didn’t match with ours.

In our case, the firewall was turned off. Also we could remotely manage the server. And we where able to connect throug RDP. And the default action account had enought rights.

So, we did a second look at DNS and saw, that there was a second, a private, IP was registered.

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.

A requirement for installation for System Center Orchestrator 2012 Beta is to have the right collation in SQL server.

As SCOM, SCO also needs the SQL_Latin1_General_CP1_CI_AS for its databases.

We where faced with an error in the Send Email Activity, caused by wrong collation.

As Microsoft told us, there is a bug submitted to check for right collation at installation time.

We actually force SQL_Latin1_General_CP1_CI_AS as we write our schema entries (as does SCOM) but having the alternate collation would have some impact in terms of temp table usage and such.

I have submitted a bug previously to include a prerequisite check requiring the SQL Server to be installed using SQL_Latin1_General_CP1_CI_AS so I will check on that bug to make sure it is in fact being included in RC/RTM.

This was a bug we where facing in the actual installation of System Center Orchestrator 2012 beta.

The build in activity to send emails from within a runbook didn’t store its settings.
So the runbook failed.

The error was caused by a wrong collation.
The sql server 2008 R2 was set up with SQL_Latin1_General as collation.

As a requirement, System Center Orchestrator needs SQL_Latin1_General_CP1_CI_AS as collation.
So we had to reinstall the sql server with the correct setting and everything was correct.

A Senior Support Escalation Engineer from Microsoft wrote us about that bug:

We actually force SQL_Latin1_General_CP1_CI_AS as we write our schema entries (as does SCOM) but having the alternate collation would have some impact in terms of temp table usage and such.

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!