SCOM Trick 18 – Removing management packs

SCOM, SCOM Tricks Send feedback »

Once in a while you will need to remove a management pack. Either because you are no longer monitoring whatever that management pack was for, or a new version of the same management pack requires you to remove the previous version first.

Well removing a management pack is not that difficult in principle. Check out the following page:

However, in some cases you will find that you have used references to this management pack from other management packs. This can be due to setting overrides or by using objects of a class in this MP to a dashboard in another management pack, or perhaps you have used it somewhere else.

Here is write-up by Jonobie Ford about removing dependencies on the default management pack (which is one of the most used management packs for setting overrides UNFORTUNATELY):

Back to the SCOM Tricks general list

SCOM Trick 17 – SCOM 2007 R2 and SQL 2008 R2

SCOM, SCOM Tricks Send feedback »

A question that comes up a lot is whether SQL 2008 R2 is supported for SCOM 2007 R2 and what to do while installing a new SCOM installation on that version of SQL.

If you do a fresh installation of SCOM on a SQL 2008 R2 you will find that you cannot connect to the SQL server. It will refuse to install the database component. In that case you will have to use the dbcreatewizard to create the databases (for operationsmanager and operationsmanagerdw databases).

Support for System Center Operations Manager 2007 R2 that runs on a SQL Server 2008 R2 database

Also you will first need to go to SQL 2008 R2 with CU5 or higher. Watch this post from Kevin pointing at the issues and fixes:

When upgrading from SQL 2008 SP1 to R2 version you might refer to this posting from Marnix:

And a posting from my friend Walter Eikenboom with videos:

Back to the SCOM Tricks general list

SCOM Trick 16 – 1106 event from HealthService

SCOM, SCOM Tricks Send feedback »

In a few cases we have seen 1106 events in SCOM environments appearing. You will see those in the operations manager event log from the HealthService with ID 1106. These will have a text referring to RunAs accounts. For instance: Cannot access plain text RunAs profile in workflow bla bla bla.

So, here are some possible solutions to this issue:

Back to the SCOM Tricks general list

SCOM Trick 15 – cross platform agent troubleshooting

SCOM, SCOM Tricks Send feedback »

So you want to do some cross platform monitoring of Linux and Unix clients with SCOM. A very good idea. As mentioned before in Trick 1: Read the product documentation at

But in some cases you might run into issues. These can range from networking, firewalls, dns, certificates, ssh, root rights and more.

There are a few good write ups on things to check to troubleshoot deployment of agents to Linux or Unix servers. In most cases encountered issues and solutions apply to any kind of cross platform agent.

:!: I have done some extensive troubleshooting myself and blogged about it here:

A three part series on troubleshooting cross platform agent discovery and installation:

SCOM agent on Sun Solaris:

SCOM agent error: cimserver: Failed to load the Provider Manager for interface type "CMPI" from library:

Discovery wizard errors while deploying RedHat agent:

:!: Discussions by Robert Hearn:

Can’t get your Linux computer discovered? Check your network configuration

A four part series on troubleshooting cross platform discovery and agent installation:

:!: Discussions by Daniele Muscetta:

Daniele has written a number of very informative posts since the beginning of the crossplat monitoring days (the beginning of the beta period that is &#59;) ). Lots of information available under the xplat tag on his site:

Back to the SCOM Tricks general list

SCOM grey RMS and agents with 7022 events after deleting crypto folder

SCOM Send feedback »

The other day I had been called in to help troubleshoot another case where management servers and agents turned to a grey state. It was a case with a reason I had not seen before so I thought I might mention it here.

What happened was that due to some reason the contents of the "C:\Documents and Settings\" folder got deleted from all machines. These were Windows 2003 machines. This happened right before the agents went into a grey state, so it was very likely to be linked. Some other programs (IIS, SCCM agent) also seemed to not have liked this. At first sight of course this only contains a few user profiles, so what the heck, right? But there are also some other directories in there (sometime of them hidden) that actually do have a function.

In the end what had happened was that the "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto" folder had been deleted which contains machine keys. Aha...

So we started out focussing on the management servers and the SQL box in order to get that up and running first. What you will see on agents and management servers are events 7022 saying something to the effect of that it has downloaded secure configuration but that it does not have the certificate or private key to decrypt it. So it fails. Crypto folder deleted, decrypt errors, looks like we have a link here. Now the management servers also had this, so we first had to get those talking again (and make sure we monitor its SQL as well in order to see if we had any other issues). We want to see an event 7023 please.

So the way to get this running was to:

  • Stop the System Center Management service
  • Clear the default value under the following registry key (making an export first might be a good idea!):
  • We deleted the contents of the following folder, also in order to flush the cache and have it re-download configuration and management packs:
    "C:\Program Files\System Center Operations Manager 2007\Health Service State\*.*"
  • Start the System Center Management service

After a while we finally got the 7023 event back and a minute later we saw the long list of 1201 events which means it is downloading the management packs again. Few minutes later the monitoring of those machines came back and the performance counters and health state.
Next we pulled down a list of all agents from the OpsMgr Shell with get-agent and we used that as input to run the above as a script on all other agents.

An hour later and everything was green\red again.

So if you ever delete that folder or have a corruption in it this is a way to try to get it fixed.

Good luck!
Bob Cornelissen

SCOM Trick 14 – Troubleshoot grey agents or management server

SCOM, SCOM Tricks 4 feedbacks »

Very often you will see some SCOM agent turn into a grey state. In some cases this can happen to your management server or RMS as well (I hope not!!). This can have several reasons and range from an agent being down or a machine being down to more serious issues.
Normally your first step might be to ping the agent (using the tasks in the actions pane), followed by a check if the agent service is running on the remote computer (System Center Management service).

I have already talked about machines that can turn grey in SCOM Trick 10 and SCOM Trick 11 in case you might be looking at stale data in your console or when a machine actually is not part of SCOM anymore. For instance if somebody turned the machine off at the end of its life cycle. Those pages discuss getting rid of objects that you know are not monitored anymore and you do not want them. Everything below this point I assume you actually do want these objects to be monitored and have a nice and green state (if possible).

:!: How to find grey agents?
In the SCOM console is one place of course.

There is a management pack that will show you alerts for grey agents:

Combining it with Opalis to find grey agents by Marcus Oh:

Find grey agents in PowerShell:
$WCC = get-monitoringclass -name "Microsoft.SystemCenter.Agent"
$MO = Get-MonitoringObject -monitoringclass:$WCC | where {$_.IsAvailable -eq $false}
$MO | select DisplayName

Find grey agents in SQL:
SELECT ManagedEntityGenericView.DisplayName, ManagedEntityGenericView.AvailabilityLastModified
FROM ManagedEntityGenericView
INNER JOIN ManagedTypeView ON ManagedEntityGenericView.MonitoringClassId = ManagedTypeView.Id
WHERE (ManagedTypeView.Name = 'microsoft.systemCenter.agent') AND (ManagedEntityGenericView.IsAvailable = 0)
ORDER BY ManagedEntityGenericView.DisplayName

:!: Troubleshooting grey agents:

Troubleshooting grey agents KB article KB2288515
Troubleshooting gray agent states in System Center Operations Manager 2007 and System Center Essentials
This is a very complete discussion on the subject.

Back to the SCOM Tricks general list

SCOM Trick 13 – SPN

SCOM, SCOM Tricks Send feedback »

Service Principal Names (SPN) are used to uniquely identify an instance of a service. SCOM Services are also registered and mostly everything will be just fine, but in some cases you might have issues with this.

My friend Walter Eikenboom has written up a very good post about SCOM and SPN, how to check it, how to set it etc. Check it out here:

Also a post by Kevin Holman about the subject:
System Center Operations Manager SDK service failed to register an SPN if you see an event from OpsMgr SDK Service with ID 26371

And another writeup by Jonathan Almquist:

Another case that can be brought back to an SPN issue by JC Hornbeck:
OpsMgr 2007: Agents stuck in Pending Management with Event ID 21016

Back to the SCOM Tricks general list

SCOM Trick 12 – Diagnostic logging

SCOM, SCOM Tricks Send feedback »

In some cases you might require a lot more info from SCOM about what is going on during troubleshooting. In that case you might want to have more diagnostic logging (more verbose). Here is how to use it.

How to use diagnostic tracing in System Center Operations Manager 2007 and in System Center Essentials

Back to the SCOM Tricks general list

SCOM Trick 11 – Seeing old or unmonitored entities

SCOM, SCOM Tricks Send feedback »

In some cases we might open the SCOM console and go into a state view and see old entries there. Devices that have actually gone already. Items that have been discovered before somehow and not being monitored. Assuming that we do not want these monitored we would like to get rid of them in our state views.

First of all check out SCOM Trick 10 and see if it is not just the SCOM console playing tricks on you.

Next you can go into the Start menu – All programs – System Center Operations Manager 2007 R2 – Operations Manager Shell. When it is loaded you can type the following command:

That should get rid of a lot of the unmonitored entries.

Back to the SCOM Tricks general list

SCOM Trick 10 – SCOM console renew

SCOM, SCOM Tricks 1 feedback »

Many times it can happen that you are looking at stale data in the SCOM console. For instance you click on an alert and it gives you an error, saying that it has already been closed (in more difficult terms). Sometimes you see an entry in a list that should not be there anymore. This could have several reasons, which will be discussed later. But the first things to do when you fear you are looking at data that could have some clutter in it are the following (going one step further every time until you see what you expect to see):

  • Press F5 to refresh the screen
  • Close the SCOM console and start it using the /clearcache option
    Click Start ? Run and put the following (in one line) as the command:
    "C:\Program Files\System Center Operations Manager 2007\Microsoft.MOM.UI.Console.exe" /clearcache
  • Next you can do the same after deleting the following registry key (close the console first):
    HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console
    This gets rid of most of the “ghost” entries of alerts and items in the view caused by the console itself.

Back to the SCOM Tricks general list

Contact / Help. ©2015 by Bob Cornelissen. blog software.
Design & icons by N.Design Studio. Skin by Tender Feelings / Evo Factory.