Microsoft Community Contributor Award

Uncategorized, SCOM 1 feedback »

Today I got the following message from Microsoft...

Congratulations! We’re pleased to inform you that your contributions to Microsoft online technical communities have been recognized with the Microsoft Community Contributor Award.

The Microsoft Community Contributor Award is reserved for participants who have made notable contributions in Microsoft online community forums such as TechNet, MSDN and Answers. The value of these resources is greatly enhanced by participants like you, who voluntarily contribute your time and energy to improve the online community experience for others.


Wow, thats cool!

As you might know by now I really like being an active member of the community on community websites and forums and blogging and beta programs of all sorts. Its great to be awarded such a community based award. Thanks to all for this! It is also another push forward to continue being active and helping others, as I have been helped by others in the past as well.

To read more about what this program is about you can go to:

SCOM Trick 19 – Remove SCOM agent command

SCOM, SCOM Tricks Send feedback »

Once in a while you will encounter a situation where you will have to uninstall the agent from a command line. For instance if somebody shutdown a SCOM test environment while forgetting to do the uninstall of all agents first. They will all be active and pointing to a non-existing server and giving errors and trouble. So here are some ways of removing an agent if you cannot use the SCOM console for instance to uninstall them.

Agents: remove configured management group or uninstall agent using command line

Brute Force Uninstall of Management Group

Windows Agent Install MSI Use Cases and Commands

If you are trying to remove or change an agent through the manual route from a machine by using the add/remove programs option you might also run into errors, especially on Windows 2008 servers: Microsoft ESENT Keys are required.

Back to the SCOM Tricks general list

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

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