By Stefan Koell on Wednesday, February 17, 2010 4:32:41 PM

I was asked recently to post an article on how we do web page monitoring. For a number of reasons we do not really use the built-in “Web Application” monitoring template. One of the reasons is that we are not really happy with the selection of the watcher nodes. We needed a way to monitor every web server in our farms without managing the watcher nodes manually all the time. We create host entries on our web servers pointing to themselves. So every time you browse to www.code4ward.net on one of the web servers you do not go through the load balancer. Since the host entry for www.code4ward.net points to the web server itself, you will browse to the web hosted on the server you are currently connected to.

So I created a small script which is basically doing web monitoring the way we wanted it to be. In this blog post I will talk about the implementation we started to use back in MOM 2005 and still use it (slightly modified) in our SCOM 2007 environments. We have recently migrated all those scripts to PowerShell and did our own class definitions using the authoring console. For now, I will focus on the much simpler implementation using VBScript and OpsConsole without any work in the Authoring Console. Download the vbscript from the following link:

http://www.code4ward.net/c4w/files/Misc/code4ward.Sample.WebContentCheck.zip

Before you begin you should create a group containing all your computers you want to monitor with a web page. Or you can of course also use the script like the Web Application template to monitor a web page through a load balancer or whatever using watcher nodes. In any case, create a computer group with your web servers/watcher nodes.

	In your Operations Manager console switch to the “Authoring Space”, expand “Management Pack Objects”, right-click on the “Monitors” node, select Create a Monitor –> Unit Monitor Now select “Scripting / Generic / Timed Script Two State Monitor” Select a destination management pack. Attention: The group I talked about earlier needs to be in the same management pack with the script monitor we now create. Or the group is in a sealed management pack, then you can select a different destination management pack. Click next.
	Provide a name for your monitor and select a target like “Windows Server”. Notice that we uncheck the checkbox “Monitor is enabled”. We will later create an override to enable the monitor for all the web servers/watcher nodes we created the group earlier.
	Configure a schedule. In general we schedule all our monitors (or rule) to run every 5 minutes (of course there are exceptions).
	I strongly suggest to provide a meaningful script file name on this page, as it will help you to find it on the agent when you have to trouble shoot something. Let’s setup the timeout to 5 minutes. Open the script attached to this blog post and copy everything from the code4ward.Sample.WebContentCheck.vbs into the script text field. The script is very generic and needs 3 parameters to run successfully.  As you can see from the script body, Parameter 1: is the URL of the web page you want to monitor Parameter 2: is the expected text in the content Parameter 3: is the timeout in seconds (-1 means no timeout) Before we click on next, click on the Parameters button to specify your parameters.
	To be on the safe side, I always put the parameters in double-quotes. The parameters line reads: ”http://www.code4ward.net” “code4ward” “30” The configuration means, download the web page from www.code4ward.net every 5 minutes (the scheduled we configured earlier), look for the string “code4ward” (without the quotes) in the content, abort request after 30 seconds if there’s no answer from the web server. If “code4ward” is in the content and the web page was returned within 30 seconds, the monitor is healthy. If “code4ward” is not in the content or the web page took longer than 30 seconds, the monitor is unhealthy.
	Now we need to hook up the property bag status messages from the script with the health monitor’s unhealthy state: Property[@Name=’Status’] Equals Error
	Now we need to hook up the property bag status messages from the script with the health monitor’s healthy state: Property[@Name=’Status’] Equals OK
	Here you can decide, if you want the health state to be warning or critical.
	The last page of the wizard let’s you configure the alert properties for this monitor. In order to get all the nice output from the monitor in the alert description, you need to copy “$Data/Context/Property[@Name='Message']$” (without the quotes") into the alert description field. Now click on “Create” and your monitor is ready to use. All you need to do now, is to create an enable-override on the monitor for the group we created before.

As you can see, the monitor itself is pretty simple and has not all the features you know from the Web Application template. But sometimes less is more and this script monitor is used to monitor hundreds of sites without any problems.

If you have any questions or feedback, just comment or drop me an email.

cheers,
Stefan
http://www.code4ward.net

By Stefan Koell on Sunday, December 13, 2009 1:40:23 PM

I just want to share this piece of information because it’s not really documented and someone might wonder about how SCOM behaves with discovered entities in the Operations Manager DB and Data Warehouse DB. We had a discussion with our Microsoft contacts and here’s the (somewhat surprising) outcome.

Let’s start with a short overview, why this information is so important for us (and maybe for you too):

As many of you do, we deploy our own authored management packs containing our own class definitions which are discovered and monitored. In our case, we created a sealed MP, a “library” MP containing our classes, rules, monitors, etc. We also create MPs programmatically which have a reference to this library MP. Sometimes we are forced to update this library MP to a new version and sometimes it happens that we break compatibility so that we cannot just “upgrade” our MP. We are forced to uninstall all referenced MPs, the library MP and reinstall the new library MP (my friend Tenchuu wrote an awesome script to automate this process: http://systemcentercentral.com/BlogDetails/tabid/143/IndexId/55738/Default.aspx).

First question came up: what happens to my discovered entities when I uninstall the MP containing the discovery and class definitions?

The second question was: what happens when I re-import the MPs, the discovery runs and the exact same entities with the same ID are discovered again?

The answer to the first question was – as expected:

When you uninstall the MP containing the class definitions and discovery, all discovered entities are deleted and all associated operational data (Events, Alerts, Performance Date, State Change Data, etc.) will be gone as well.

So everything is gone from the OperationsManager database.

In the data warehouse database the data will still be there.

The answer to the second question may be obvious as well:

When you reinstall your MPs and the discovery will create your entities with the same object IDs as before, the data warehouse would continue to associate the data to the same object you had before. Except for the missing data while you had your MP deleted, you will not see a difference.

There’s one caveat and you should be very careful: Since the data warehouse also keeps track of the MP version with each object ID, the data warehouse will only keep the data from the last three MP versions in the database. This is not configurable! In other words, when you keep your data warehouse data for 6 months and you do uninstalling and re-importing your MPs more than 3 times in one month, you will lose more than 5 months of data.

UPDATE: The above – the rule of 3 – only applies to unsealed Management Packs. When you use sealed Management Packs the DW data will always be kept until standard grooming kicks it out, regardless how often you update, delete or re-import the MPs.

One other small detail is, that you cannot trick this mechanism by just not changing the MP version. The data warehouse will create an “internal” versioning of the MPs which will change upon update, even if the MP version is still the same!

cheers,

Stefan
http://www.code4ward.net

Read More »

By Stefan Koell on Sunday, July 19, 2009 5:21:52 PM

 

Read More »

By Stefan Koell on Tuesday, November 04, 2008 4:46:59 PM

... but those who are may have received a conference guide like this:

How do you spell connect?

Thanks to David Allen for this.

Read More »

By Stefan Koell on Thursday, September 25, 2008 12:05:05 PM

ComponentFactory is offering their Krypton Suite (Value: $299) for free to MVPs and .NET bloggers. Go, ckeck it out here: http://www.componentfactory.com/blog/?p=328

By Stefan Koell on Thursday, February 28, 2008 7:35:37 AM

CheckServiceState Script CheckServiceState Script

If you ever wanted more control how to monitor windows services with Operations Manager 2007 you most likely realized, that you have to do it all by yourself with a custom script.

I had at least two major problems which forced me to use a custom script:

• It seems that you cannot monitor the status of a service which has the startup type set to "Manual". (There is a parameter in the overrides dialog called "Alert only if service startup type is automatic" but it doesn't have any effect, the health state simply doesn't change)
• When using templates to monitor a windows service you cannot override the monitor to only monitor a subset of services using a group. The group just doesn't show up in the list

So this is my approach to windows service monitoring:

First of all, let's set up a Windows Service monitoring using the standard Management Pack Templates Wizard. In this example: "Print Spooler". In the monitoring wizard select or create a destination management pack, here: "Windows Service Monitoring".

I use the template wizard because I can use the discovered service class to target my own script and I get all the other goodies (performance monitors, baseline rules, etc).

After a while the service you just configured to monitor will be discovered. Now let's setup a group:
Create a new group with a name like "Print Spooler Service Group" in the "Windows Service Monitoring" management pack. In this example I use explicit group members but you can also use dynamic membership of course. The beauty is, that your group can (and should) contain the discovered service instances:

Next, bring up the monitors the template wizard creates for us:

There you should see the (very inflexible and buggy) availability monitor:

 

Right-click on the "Service Running State" monitor and select "Overrides > Override the Monitor > For all objects of type: Print Spooler". In the Override Properties, disable the monitor (check "Override" for the Parameter Name "Enabled" and change the "Override Setting" to "False").

Next, right-click on the "Availability" node and select "Create a monitor > Unit Monitor...". In the unit monitor dialog, select the "Scripting > Generic > Timed Script Two State Monitor" as monitor type and place it in the same Management Pack "Windows Service Monitoring".

In the General properties page we can now target the script to the "Print Spooler" class. Also be sure to disable the monitor by default (We enable it later using a group override).

Pick a schedule which makes sense to you (I recommend every 5 minutes but depending on your environment I suggest that you don't go below 2 minutes).

In the Script page, provide a script name, like CheckServiceState.vbs and paste the attached script into the script area.

The script takes 3 parameters (documented in the script) but for a standard scenario you can just use:
"$Target/Property[Type="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/DisplayName$" "Running" "Auto"

Because we already target the print spooler class we can use a dynamic parameter to pass on the service name. Parameter 2 and 3 (which is optional) can be used to define the desired status and startup type. Please be sure to encapsulate each parameter in double-quotes - just to be on the safe side.

Next let's define the health expressions:
 
 

And finally the alert:

I suggest an alert description like:
The state of the monitored service '$Target/Property[Type="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/DisplayName$' on '$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$' is invalid: $Data/Context/Property[@Name='AlertText']$

After you created your monitor, enable it using an override for the group we created earlier.

As last (optional) step I suggest to create a state view containing the Print Spooler instances and scoped to the group where we enabled the monitor.

Of course, it would be much better if that functionality and flexibility is provided by OpsMgr out of the box...

cheers

By Stefan Koell on Tuesday, December 18, 2007 3:00:37 AM

Once again, a little post to share with you guys about Operations Manager Tasks - this time using Powershell. First a little background story: Current version of Operations Manager 2007 (SP1RC) has still some nasty bugs and it seems that especially the events view doesn't get much attention from the product team.

The event view doesn't HTML-Encode the event description in the details pane. Which is bad if you have to look at events (published exceptions for example) with fragments of XML or HTML included. This information just doesn't appear in the preview pane.

So, the first thing which came to my mind is: Ok, then. How about some kind of console task which executes a quick Powershell command to dump out the event details using the Get-Event Cmd-Let.

Next Problem: You can create an event task and put a dynamic parameter $ID$ in it. However, starting the task using the actions pane on the right always passes the same ID (I guess the ID from the first event selected when the view gets loaded) to the task - regardless which event was selected!

Lucky me, there is a workaround: When you execute the task using the Actions menu in the console, the task will always get the ID from the selected event.

So, now the interesting stuff: How to setup such a task?

• First create a console task for events using the authoring section in the console.
• When defining the command, set the application to: C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe
• Set the parameter to: -PSConsoleFile Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Console.psc1 -NoExit .\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1;Get-Event -Id $ID$
• Set the working directory to: C:\Program Files\System Center Operations Manager 2007
• Finally, uncheck the "Display output when the task is run" checkbox

That's it. Enjoy...

By Stefan Koell on Wednesday, September 19, 2007 2:43:37 AM

In MOM 2005 it was easy to notify someone on specific alerts. SCOM 2007 - with it's subscription based system - cannot handle these kind of notifications. But the limitation is the user interface. Jakub from the SCOM 2007 product team released some very useful code which helped to implement a notification based on the alert name. One problem of Jakubs code is, that it's a C# program which is not very handy and that he creates most of the stuff in code which can be created with the UI.

I translated the script to power shell, which should be much friendlier to use, deploy and let's you quickly tweak some settings. The code below works for me (at least working with email notifications), but I have to admit, I didn't test it that much. The script usage is pretty simple, but you have to do some stuff first:

• Setup email notification
• Create at least one recipient
• The alert has to be raised at least once
• Change the $RMS variable in the script to your root management server
  

Then, just execute it in Power Shell: ".C:\Set-NotificationForAlert.ps1 "This is a test alert" "This is a test notification recipient"

Parameter 1: The name of the alert

Parameter 2: The name of the recipient

So, hopefully I can ease some pain with this...

 Set-NotificationForAlert.ps1

By Stefan Koell on Thursday, May 03, 2007 6:08:37 AM

Someone might ask: why the heck do I need that? And yes, I never thought that I will need it but I learned that in SCOM 2007 a group is not always a group.

Jakub Oleksy helped me to understand and solve my problem and I am happy to share this information with you.

The problem is, that groups created by the web application wizard can not be tweaked using the UI in SCOM 2007. It's not possible to create a dynamic membership rule. It's also not possible to assign a subgroup to such a group. So having a lot of servers and a lot of web applications it's not really fun to pick every single server in every single web application.

Here my workaround:

• Create a web application using the wizard
  A group named after your web application with the suffix "watcher computers group" will be created
• Create your own computer group using the UI and define a dynamic membership rule
• Configure the script (the 3 lines at the beginning) and test (DO NOT RUN THIS UNTESTED IN PRODUCTION ENVIRONMENT!)

This is just a proof-of-concept script to show how you can do stuff like this. According to Jakub there may be a fix in SP1 which enables you to utilize the group created by the web application wizard in a way to either create a dynamic membership rule or attaching a subgroup, or both.

Disclaimer:
USE THIS AT YOUR OWN RISK. I AM NOT RESPONSIBLE FOR ANY DAMAGE THIS SCRIPT MAY CAUSE. THAT SAID, HAVE FUN!

Source Code

By Stefan Koell on Tuesday, April 24, 2007 11:08:37 AM

During the deployment of System Center Operations Manager 2007 we realized that the database is not supported on Itanium (IA64) hardware. This was a big issue for us, because we only had IA64 hardware for our database machines. So a sick idea came to our minds: just install it on a temporary x86 or x64 machine - with the exact same machine name as the final IA64 production machine, detach the database and move it to the IA64 and re-attach it there.

After that, you have to ensure that the broker function is enabled on the DB. To do so, execute the following query in the SQL management studio (assuming you named the database 'OperationsManager':
SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

This should return '1'. If not fire up the following statement (again, assuming the database is named 'OperationsManager':
ALTER DATABASE OperationsManager SET ENABLE_BROKER 

If the service broker is not enabled you might get errors or hangs during discoveries and submitting tasks. 

So far this is working great for us, it's still not clear if a setup like this is supported by Microsoft. But there really should be no difference running the DB on a IA64 instead of running it on a x64. No binaries are installed by the setup, only the database schema is created. As far as I know, Microsoft is working on IA64 support for the database - maybe a Service Pack 1 thing...

Update:

You also have to be sure that the CLR (.NET Common Language Runtime) for stored procedures is enabled. To do so:
EXEC sp_configure 'clr enabled', 1;
RECONFIGURE WITH OVERRIDE;
GO