You are browsing the archive for 2011 May.

Start to SCOM: Phase 1: The design doc

9:38 pm in Uncategorized by Dieter Wijckmans

Phase 1

So now that you normally have a clear view on the assessment and what people expect you can start writing your design document.

I’ll be pointing out how I usually write my design docs. You can use these guidelines or create your own totally different layout + structure. Feel free to do so.


The different components in a design doc

First of all you need to write a design doc for people who are not familiar with the product. You already have some insights in the technology / product but be aware that most of the managers do not have these insights so you have to educate a little bit as well.

Therefore it’s a good thing to explain all the different components of your SCOM structure briefly before pointing out your decision concerning the component.

This is a brief overview of my framework for my design doc. Again this is my framework. Feel free to use it or alter it as you please:

  1. Goals of the project
  2. Introduction
  3. The current situation and why you want to implement the new product (remember the assessment phase)
  4. Explanation of the Operations environment and different components
  5. The proposed architecture + sizing
  6. Security + accounts which are needed for the environment
  7. Conclusion and summary.

These are in general the 7 chapters you need to cover. Let’s start with the first one:

1. Goals of the project

This chapter will be an easy one. You formulate here what you came to know during the Assessment phase. It’s best to sum up where you want to be when the project finishes. Don’t go much into detail here yet. There’s plenty of room for this later on Smile

2. Introduction

Describe a little bit the purpose of this design document. Again don’t go into much detail here yet.

3. The current situation

Again you can use your notes from the assessment meetings to summarize what the current situation is and why there’s decided to switch to SCOM. Here you can already make a small high level comparison between the current system and the new SCOM environment.

Include maps of the current topology of the network environment and/or the old monitoring system.

4. Explanation of the Operations Environment and different components.

Here begins the hard work. Luckily you only have to do this once because you can reuse this section later on because the explanation of the components will not change except for the design decisions.

SCOM 2007: Start to SCOM.

8:44 pm in Uncategorized by Dieter Wijckmans

Everybody who has been working with SCOM remembers his first time when he opened the console. It can be overwhelming and you just got passed the experience of designing and installing the SCOM system.

So you lean back and ask yourself… Where do we go from here. Where to start. Where to get the info needed… So many questions and so many answers to find online posted by user groups, team blogs, white papers,…



In the next series of blogs I’ll try to set up a step by step guide to get things going to a level where you can already showcase the environment and further fine tune. I’m working 2 years with SCOM 2007 so the memory of the start is still fresh but fading fast when you dig deeper in the program.

First things first. The different phases of a SCOM project and the different trap holes they bring along:

Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

Phase 6

These are subject to change off course but I always keep more or less to these 6 Phases. I call it my SCOM framework.

This series will be based on a install of a SCOM 2007 R2 environment.

I’ll walk through  different phases of process. If there are any suggestions down the road please do not hesitate to leave a reply or contact me via my contact info on the front page.

SCOM 2007: Scheduled reports failing

10:14 am in Uncategorized by Dieter Wijckmans

Recently I got a mail of a user stating he’s not receiving his reports anymore via mail. They were created way back and normally these reports are in my category “set it and forget it”…

When I checked the schedule reports pane instantly I noticed that all the reports are showing an error as shown below:


“The Subscription Contains parameter values that are not valid” error message is in the status field.

During my search on the web the most common solution was to recreate the report which I did for one but because these are like 20 reports it will be a lot of work to recreate them all and risk the fact that they break again without knowing when and why.

So the next step I tried in my troubleshooting is to see whether I could fill in the missing parameters in the report which resides in a custom management pack holding all these special reports.

When I tried to run the report I noticed the following: Data Aggregation and Histogram are greyed out and it’s impossible to change them


When I tried to run the report the following error message came up:


So there is an issue with the ‘Data Aggregation’ parameter. No possibility to troubleshoot any further in the SCOM environment so we’ll have to dig deeper and turn our attention to the underlying SQL Reporting Services (SRS) install.

Connect to the SRS server and open up the SQL management studio.

Note: If you’re not sure where your SRS install resides navigate to SCOM console > administration > Reporting. The Reporting Server URL is filled in there so you can retrieve the server name / alias here.


Make sure you select “Reporting Services” in the Server Type and select the server name you’ve retrieved from your console.

Navigate to Home > “Your management pack” > reports > Subscriptions.

In this example we’re troubleshooting the “PROD3_IOReport”.

Right click and choose view report.


The web browser opens and will generate the report. However in this case the following error shows up:


Didn’t we have an issue with the “DataAggregation”? The error above shows we have an issue with our “ManagementGroupId”.

Let’s take a look at the report properties to find out.

Right click the report and choose Properties.


The familiar SQL properties page pops up.


Behind the “ManagementGroupID” (in the above print screen the sixth item) it’s indicated that there are multiple… We only have one management group so why should there be multiple?

If you open the value you get a drop down box with the 2 id’s listed


So which one is the correct one…

I opened a newly created report in the same management pack (which I recreated to solve the issue with the first report) and there there’s only one ID listed:


This report is working with all the parameters so this ID is the correct ID for our management group.

Next step is deleting the ”wrong ID” in my report parameters and click ok:


Now we go back to our SCOM console and check the report once more.

Open the report and now it’s possible to check the Data Aggregation and Histogram again.


After clicking “run” the report is generated successfully.

So all we need to do is change the parameters in our scheduled report.

Navigate back to the scheduled reports list, right click the report and choose edit.


Check the parameters and fill in the correct Data Aggregation / Histogram settings (and check the other settings as well while you’re at it).


Click finish and check back at the scheduled report view.

The report has gone from error to “ready” and is able to process when the scheduled time is there…


In this particular case it apparently was an issue when there were agents temporarily multi homed to a test environment and this test environment was deleted afterwards.

Although this was a mistake on our side I posted this blog post to illustrate that the error message in SCOM was not the cause of the real problem which was hidden in the SRS installation. This threw me off when troubleshooting the issue because I was focusing on the wrong error and has cost me a lot of valuable troubleshooting time.

I’ve posted my experience to save you some time in troubleshooting the issue Smile

SCOM 2007: Renaming Default Management Pack display name

11:01 am in Uncategorized by Dieter Wijckmans

One of the most common frustration I face (and I’m sure I’m not alone) is the fact that from time to time there are things saved in the default management pack.

imagesCALXWMLCIt’s so easy to forget to change the destination management pack while creating rules / monitors and just click next. We all know once you’ve created the rule it’s not possible to change the management pack anymore…

It’s best practice not to write anything to your default management pack but it’s always selected as default…

Yet you have 2 options:

  • Delete the rule and start all over again
  • live with the rule residing in your default management pack which is not a good idea in case you face issues with dependencies…

To avoid this common mistake / lack of attention I make a habit of renaming my default management pack display name to something eye catching so I see it before clicking next while creating a rule / monitor.

Open the SCOM console and navigate to Administration > Management packs and right click your Default Management Pack


Choose Properties in the menu:


Change the Name of your Default Management Pack. In my case I always put in capital “DO NOT WRITE TO” before the name.


And click apply.

This changes in fact the display name of your management pack but not the management pack ID. It’s not possible to change the ID (it’s greyed out) so your management pack will still hold all the dependencies…

At this point the default management pack is still the default when creating a rule but there’s a nice message in capital just above the next button.

This small modification saved me already a lot of (additional) headache to remind me to change to a different management pack when creating a rule / monitor…

SCOM 2007: Custom Alert Fields

8:34 am in Uncategorized by Dieter Wijckmans

Just recently I needed to connect SCOM to an in-house written Problem Management system. There was not a connector available and it was also not possible to generate tickets directly in the system itself.

The only way the system is receiving input is via mail through specific keywords.

Most of the keywords could be mapped to standard alert fields like severity, time raised, description….

BUT (off course there’s a but) the system also requested other fields to decide proper escalation, severity,…

The previously used system onsite is MOM2005. In MOM2005 there’s an option to define globally these fields so you can use them in whatever alert you want to raise.

This is in MOM2005:

Open Operator Console > Administration > Global Settings > Custom Alert Fields


Up to 5 Custom Fields can be named here:Customalertfields_2

These fields can than be addressed in the Rules you create and can be populated with the text you define:


When you select Custom Fields the labels you specified in the Custom Alert Fields settings are shown here and you can pass info to the fields via the rule into the alert:


question-markWhile setting up the same connection from SCOM to the Problem management system I found out it’s not possible to define the custom fields globally in SCOM like we did before in MOM.

BUT there are 10 (!) Customalertfields available in the SCOM dbase to use as u please.

So How can we use these fields and fill them in with the proper parameters to give the correct data to the Problem Management system to do it’s magic?

Well through an Alert Generating Rule which is event based:

Open Scom Console and navigate to Authoring > rules > right click in the right pane and choose new Rule…


Note: Always change your destination management pack to something OTHER than your Default Management Pack.

In this example I’ll be creating a new rule for event ID 145 in the application log to show where exactly the custom fields are.


Fill in:

  • The rule Name
  • Description (if required)
  • Rule Category: We’ll leave it at Custom for this rule
  • Rule Target: Choose the Target class to where you want to target your rule. In this example we’re targeting towards all Windows Computers


Fill in the Event log name where you want to look for the event. In our case this is the Application log.


We want to look for an event ID which is equal to 145 in this case.


And in this screen there’s the option to add Custom alert field parameters.


Unfortunately it’s not possible to label them as you could in MOM so you need to keep a description at hand what you want to fill in in what number of custom field.

The custom fields are written in the SCOM dbase and can be used in PowerShell or other scripting language.

The parameter in PowerShell is $_.CustomField1 through $.Customfield10.


By passing the info here I was able to deliver the correct data to the Problem Management system to do it’s magic in the background…

SCOM 2007: Dump alerts to text file and mail

1:16 pm in Uncategorized by Dieter Wijckmans

Just recently I had an issue at a client where there was a need to rethink the notification possibilities due to various issues. I’ve developed a powershell script to gain more control over the notification process.


My Client is using an in-house developed and maintained problem management system installed on a mainframe platform.

The alerts which need escalation are detected in SCOM and then sent by mail to a Lotus Notes system. The data is then read through a connector between the mainframe system and the Lotus Notes dbase. The mail is scrubbed and through a series of scripts on the mainframe the key fields of the mail are detected and filled in in the ticket….


So far so good… BUT because of the use of different systems there was an issue with encoding. The mails were sent in UTF8 encoding and correctly decoded when viewing in the Lotus Notes Client but stayed encoded in the Lotus Notes Dbase and therefore the scrubbed text was all scrambled and unusable for the problem management system.


After various attempts to mail in different encoding formats I decided to rethink the notification and detach it from the SCOM system to get more freedom in testing.

The following Powershell script together with a custom notification channel did the trick:

It’s constructed in 3 sections: preparation + composing file, mailing and error handling for reporting reasons.

You can Download the script here.



First of all we are preparing everything to execute the script.

The areas in yellow need to be customized for your environment.

Variables which need customization:

$rootMS: Is used to read the RMS name (if the RMS is a single server you can use the first method, mine is on a cluster so I filled in the name to avoid issues with the RPC server when reading the name through WMI.

$NotifiedResState: Just pick any number which is not already in use. We’ll have to make the resolution state in SCOM afterwards.

$CultureInfo: Make sure you fill in the correct locale info to get the date / time format correct. For a list of all culture info check here: Table

Compose file


In this part of the script we are reading in all the different desired elements of the Alert and write them in a TXT file. You could however leave the txt file option out and just write this to a string but I prefer to keep the txt files for backup to check whether a ticket was raised at any given time.

Variables which need customization:

$strResolutionState: Because the resolution state is a number in the dbase and not the word itself we need to translate the number to the correct word. This way we’ll get the resolution state name in our mail instead of the number. You need to fill in the resolution state number you’ve chosen earlier + the text you’ve associated with it in SCOM. Check below on how to implement this setting in SCOM.

$strobjectname: Because not all the desired info was in the alerting I had to use 3 custom fields to get the mails to contain compliant info for the custom made problem management system. CustomField2 is reading out the NetBIOS name. Because I don’t need the full name (servername.domain.locale) but just the server name I’m splitting the name and using just the first part in the variable $Objectname

$FilePath: The file path is constructed out of 2 parameters from the alert to create a unique name and avoid overwriting an existing txt file. You need to use the time raised of the event because if you use the Get-Date function to get the current date and time it will generate 2 files if the time changes during the process.

Off course you can adapt the different fields + structure at your liking but for our problem management system this format had to be strictly followed to be able to scrub the mail.

Note: CustomField1 and CustomField3 are static text passed by the alert generated rule.

Mailing and error handling


In the last part of the script you need to send out the mail to your destination.

I’m using static parameters here because the destination will not change that often. However If you have multiple destinations it’s best to use a variable and pass it when you are running the notification command from SCOM.

Variable which needs customization:

$Sender: Fill in the From email address

$OKRecipient: This will be the email address where you want to send the mail to when everything went fine

$strOKSubject: Define the subject for the mail when everything was fine.

$ErrRecipient: This will be the email address where you want to send the mail with the error.

$strErrSubject: Define the subject for the error mail

$strErrBody: Small body to notify something went wrong along the way.

Note: due to my issues in my customers environment with encoding I’ve used a command line mail utility which I’ve used quite often and is platform independent: blat. It’s a lightweight mail utility which can be downloaded here: Blat Download

More info on Blat can be found here: Blat Info

The install + config info for blat on the RMS is at the end of the blog post.

Last but not least I’m writing an event in the event log for successful and unsuccessful script runs. This can be used to set up alerting in SCOM to give you a quick warning when the ticketing is not working anymore.

At the end we unload the snap-in to have a clean system and avoid error messages when running the script the next time:


Things which need to be in place to use this script

In order to use this script some things need to be configured in your SCOM environment + on your RMS:

  • The script needs to run on your RMS
  • The powerShell execution policy on your RMS needs to set to RemoteSigned or Unrestricted. More info here Execution policy Powershell
  • Blat needs to be installed on your RMS
  • The Notification state needs to be added to your SCOM environment: Check here to create
  • The command channel notification + subscribers need to be configured: Check here to create 

Install Blat:

  • Download blat here Blat Download
  • Extract the Archive to your %System%\windows\system32 folder to include it in the path
  • open a command prompt (just to be safe open an elevated one on win2k8)
  • Install blat by using the command: blat –install <your smtp server here> <the sender you would like to use> <Number of retries to send the mail out if unsuccessful>

Any tips or hints on improving this script are always welcome…

SCOM 2007: Setup Command Notification Channel + Subscriber

12:56 pm in Uncategorized by Dieter Wijckmans

Sometimes it’s necessary to launch a custom script or other action after an alert is detected. This can be all executable scripts or programs.

In my particular case I’m using this to launch scripts when an alert is detected to properly escalate the alert and perform additional tasks on the alert.

So how do you make sure that the script you intend to run will actually run when a predefined alert is raised?

By creating a Command notification channel and subscription…

Let’s start with setting up the command notification channel.

Note: I’m using my script Create_Ticket.Ps1 as documented here. The parameters I’m passing are useful for this script but you can pass many more parameters according to your needs.

First of all open the Notification Channels by opening the SCOM console > administration > Notifications > Channels


Right click in the Right pane > choose New > Command…


In the settings tab you need to fill in what you prefer to run:

  • Full Path of the command file: In my case this is PowerShell as I would like to run a PowerShell script
  • Command Line Parameters: In my case I’m running a PowerShell script and I’m passing the AlertID of the specific alert as an argument which I’m using in my script. Again you can use any arguments here if you like.
  • Startup folder for the command line: This is basically the path of your program you want to run.

Click Finish.


At this point your Command Notification Channel is set up. The next thing you need to configure is the trigger which will run this Command Notification Channel. This is done by creating a Subscriber:

Open the Scom console and navigate to Administration > notifications > Subscribers


Right click in the right pane and choose New…


Fill in a name for the Subscriber


Leave the “always send notifications” or specify a time window (ex. during business hours only) and click next.


Click Add to ad a subscriber address to the list. The following window appears:


Fill in the address name and click next


  • Channel Type: Select Command in the drop down list
  • Command Channel: Select the previously created Channel in this case it’s “Ticket” from the drop down list.
  • Click Next


Leave the always send notifications setting or change according to your needs.


Click Finish and you have configured your Command to run whenever you subscribe to an alert with this channel.

SCOM 2007: Create custom Alert Resolution States

12:02 pm in Uncategorized by Dieter Wijckmans

Sometimes it’s useful to make your own Custom Alert Resolution States to further classify your alerts in the console and use these states to trigger different actions using various scripts.

I’ll be posting some scripts which are going to use this custom alert resolution state so therefore I’m documenting here how to configure them.

Open your SCOM console, select the administration tab, settings and alerts.


Click new…


Type in the Resolution State display name and choose a uniqueID. Click OK.


And we are done.

Not much to it but it makes live a little easier when you want to classify different alerts.

In the next series of blogs I’ll be frequently using this Custom Alert Resolution States to classify and report on different types of alerts.