Deep respect

I know, this article is not SCOM related but still I want to make a posting about it.

Eventhough the company I work for - C2ICT - isn't big (about 40 people), it is certainly special since the knowledge & experience all my colleagues have is of a very high level.

Whether you talk about Windows 2008 Server, AD, IIS, SCOM, SCCM, Exchange, OCS, ISA, Forefront, they know it, inside and out. It is good to work with colleagues like that since I learn so much every day.

Last friday a colleague of mine, Nikolai van Luijtelaar, passed for his last exam to become an Microsoft Certified Master | Exchange Server 2007!

This is not just a title, no way. One really has to work hard to get to this level. It is a mix of much experience in the field with a very thorough understanding of the product and all other related issues like running projects on a big scale.

Nikolai, congratulations with your Master title on Exchange 2007. I know you have worked hard for it so it's good to know it returned itself into this magnificent result!

SCOM R2 RC: RTFM

When one installs SCOM R2 RC the Console is really different compared to the older versions. But these are just the looks. The real changes are to be found inside SCOM itself.

MUCH has changed. All I can say is...

Read The Friendly Manual(s)

Microsoft has delivered many guides in conjunction with SCOM R2 RC. Eventhough many of these guides contains placeholders, the information within these documents is certainly worthwhile to be read.

To keep track of what guides to read and in what order, every guide contains a roadmap diagram. However it doesn't match completely with the guides contained within the file 'OpsMgr2007R2-RCDocs.zip'.

Therefore I have made a small overview about what documents are to be found in the zip-file and what they are all about.

First of all, the roadmap diagram:
(The highlighted boxes are the guides to be found in the zip-file.)

A small note: the 'Migration Guide' depicted in the diagram has another name in the zip-file: 'Upgrade Guide'.

These guides have self-explanatory names so they do not need further introduction.

The guides contained by the zip-file:
(The highlighted guides aren't depicted in the roadmap diagram)


So what are the highlighted guides all about?

The first guide 'OM2007_MP_OpsMgrR2.doc' writes about the SCOM MP for SCOM R2 RC itself.

The second guide 'OM2007_ReportTrouble.docx' writes about how to solve problems one can encounter when installing/running the reportfunctionality of SCOM.

The third guide 'OM2007_Usage.doc' is about how to use SCOM and is rather special. One could say on the first glance that it matches with the document 'Operations Guide' depicted in the roadmap diagram. But there are differences between both guides.

The 'Operations Guide'- depicted in the roadmap diagram - follows the 'Deployment Guide' in order of usage and teaches a SCOM Admin what to do after a Management Group has been deployed.

The guide 'OM2007_Usage.doc' provides information about how to use the SCOM Console to manage the monitored environment. This document contains examples about how to build different kinds of collection rules, how to create different kind of reports and so on, whereas the other guide doesn't go into that kind of detail.

But a keen reader will notice there is still one file left in the zip-file. It is not a Word-document but a html-file:
'OpsMgr2007SupportedConfigurations.htm'.

It is a very important file since it contains all the information about supported operating systems, hardware configurations, software requirements, installation combinations, and security configurations for SCOM 2007 R2 RC.

New Dell MP released

Dell has released its new MP, to be downloaded here.

As might be known the older version was buggy and very noisy: it could hose your SCOM-environment totally. Look here for that posting.

PFE (Premier Field Engineer) Kevin Holman and I were in a race about whom would post first about it. He beat me to it. So I will not repeat his posting but link to it since his posting is - as usually - a good one. His posting can be found here.

My comments on the MP: not many major changes and the MP needs a lot of work in order to make it far less noisy.

Advise: Run it in a testenvironment first and disable the unneeded monitors/rules and discoveries. Put all these adjustments in a seperate MP, export it. Import the Dell MP into the production-environment together with the MP containing all the adjustments. And keep a watchful eye on your SCOM-environment afterwards...

Personally I still think this MP has the potential to hose the SCOM environment. So do not run it without any modifications.

Another piece of advise: run the 'installer' DellBMCLogSetup.exe on the Management Servers so the folder 'c:\DellReports' will be created containing the executable 'DellBMCLog.exe'.

Otherwise these errors will popup in the OpsMgr eventlog of the Management Servers:

SCOM R2 RC available for download

NEWS NEWS NEWS. Read all about it...

Last night: Microsoft has released SCOM R2 Release Candidate on Microsoft Connect. Found here.

Not able to delete a View

Sometimes at customerssites I bump into issues where SCOM Administrators aren’t able to delete a view (Alert View for instance) they have created themselves. They get an error like this one:


Strangest thing was that other views they had also created could be deleted without any problem. So I had to dive deeper and to find the difference between the views which could be deleted and the ones which couldn’t.

First thing I noticed that the problematic views weren’t displayed in the correct order. Normally the available views in the monitoring pane are being displayed in alphabetical order, but these views seemed to appear in random order.

The SCOM Administrators didn’t have any clue. But when I told them that it seemed like these problematic views did have another name than being showed in the Console they told me these views did have other names when they were created.

Soon enough it appeared that all the Views which couldn’t be deleted did have other names when they were created. When I asked them how they had changed the name of the view they told me by selecting it, hitting <F2> and then changing it.

So there was the cause. And the remedy was simple.

Explanation
When one creates a View, an AlertView for instance, this View is stored in the Default MP. And the name of this View is written into this MP. So far so good. See the screendump of the xml-code describing this AlertView. As an example, the name of the AlertView is Tezt Alertview:


Now I change in the Console the name of this View by using the F2 method. (Selecting the View, hitting F2 and then retype the name) I change the name of the View to F2Alertview. Notice that the View is not being showed in alphabetical order, even after a refresh or dumping the cache of the Console:


Lets export the Default MP, open it in good old notepad and when I search for the name F2 Alertview it is nowhere to be found. As a matter of fact, the old name Tezt Alertview is still in the xml-code of the Default MP:


So there is the reason these changed Views cannot be deleted: the Default MP still has the old name and when one wants to delete it, it’s changed name cannot be found in the Default MP. Hence the errormessage.

Best Practice
So how to go about when changing a name of a View? Better is to right-click it, and select its properties. In the properties screen one can change its name:




And save the changes. When one looks at the xml-code of the Default MP, now the name change will be there as well:



Eventhough the original name is still to be found in the Default MP, the new name has an entry as well. So now when one wants to delete this view, it won’t be any problem what so ever.

This best practice is not only to be used for Views in SCOM but for all objects. Whenever a name needs to be changed, do not use the F2 option, but lookup its properties and change it from there.

Savision Live Maps

Normally I do not post about 3rd party products related to SCOM. Simply because I am running a blog and not a site with advertisements. But sometimes I do make an exception when there is a product which really has more than just an ‘added value’ for SCOM. Savision Live Maps is one of those products which brings SCOM to a higher level.

Why? Well, we all know the saying: ‘One picture says more than a thousand words.’ And that is exactly what this product does. Instead of having the SCOM Operators looking at a list of servers in a green/yellow or red state, they look at a map, AD Site, topology, dashboard or the layout of a datacenter.

Savision Live Maps visualizes the state of the monitored objects in SCOM. On top of that, one can work with nested maps, or layers.

Example
For instance, one has a map of the Netherlands, where multiple geographical locations are being displayed. Per geographical location a datacenter is being monitored:


Whenever a problem arises with a monitored object, the location where this object resides will show up on the map:


Since it is a nested map, one can click on it and the floorplan of the datacenter located in Rotterdam will be shown with the serverrack where the problematic object is located:


When one clicks on the rackspace (4.10) on the floorplan, the rack is being displayed:


In this rack the server with the problem is being displayed. Clicking on it starts the Health Explorer, giving detailed information about the problem:


Of course, one doesn’t need to go through all these maps since on the first map (main map) a part of the screen shows the problem already:


But imagine the situation when one needs to tell the maintenance staff onsite to perform certain tasks. It is very easy to find out directly where the problematic object resides. And not just its geographical location, but right to the place in the serverrack where the monitored object resides! This is a real timesaver for environments with a diversity of locations and objects.

Conclusion
The software itself is straightforward in its installation and usage. As it’s software Savision believes in visualization. So ofcourse there is a good and solid online helpmanual to be found, but even better, there are instructionvideo’s as well. And these video’s are of good quality. Having these video’s watched and understood, one comes to an easy understanding of the product and is capable of making good maps on his/her own.

Free version. Let’s play!
The nicest thing is, there is a free version now to be downloaded. With this version one can create a maximum of three maps and this version is valid for a year. So it is a good opportunity to get aquinted with this software. This version can be downloaded here.

Usage
To be frankly I cannot think of any customer for whom this product doesn’t have an added value since it brings SCOM to a new level of usage. Better said, easiness of usage.

Of course there is a price-tag attached to it, but that is the case with every product. However, the pricing is reasonable and when one decides to start using it for the most important monitored objects, the investment is more than justifiable.

However there is one drawback: when one is used to it, one wants only more maps in SCOM and no more lists… :)

Rules vs. Monitors

From many customers I get questions about rules and monitors. Most of the time they do not know when to use a rule or not. To make it even more confusing for them, certain SCOM tasks can be performed by a rule or a monitor. (like checking whether a certain service is up & running). So how to differentiate between both can be challenging.

However, there is a rule of thumb which makes it much easier to differentiate between rules and monitors:

Rules are used for collecting performance data or to run scripts and Monitors check on the health state of a component.

Of course there is much more to know but it is a good starting point. Lets continue.

Monitors update almost real-time so they show the actual state of a monitored object. When one opens the Health Explorer for a computer, the monitor will show up as well. So it is relatively easy to see whether a monitor 'has arrived' and entered a working state.

Screendump 1.
A newly built monitor (Intersite Messaging Monitor) is in place but not 'on':


Screendump 2.
The newly built monitor entered a running state:


Besides that, monitors work different compared to rules. Monitors collect data from various sources and based on that information decide the health status of the monitored object (red, yellow or green). Therefore monitors are also called 'State Machines'. This latter also tells about the way collected data by monitors is treated. The collected data is never stored in the OpsMgr database, nor the Data Warehouse, only the changes of state and the related alerts are.

Rules on the contrary store their collected data in the Data Warehouse so it can be used for reports later on. Rules collect their performance data from log files, perfmon, event logs and so on. Based on that collected information, rules are also capable of raising Alerts within SCOM.

So when one wants to monitor a device with SCOM but also wants to run reports on it, one has to build a rule for collecting performance data that will show up in reports and a monitor that shows the state of that device in SCOM.

Speeding up the SCOM Console

Beware! When editing the registry one can cause damage which cannot be undone. So be carefull when performing the procedure mentioned in this blogposting. Always make an export of the registrykeys before deleting ANYTHING from the registry.

Ok, having said that, there is a nice trick to get the SCOM Console running faster.

At a customerssite I bumped into a situation where the SCOM operators complained about the performance of the SCOM Console. And they were right. It was very slugish. So I checked the RMS and the related SQL server. These servers were performing just fine. No glitch what so ever. They were dimensioned properly (enough cpu, RAM and fast disks) and when running perfmon on those servers, all was well.

So the cause of the slugish SCOM Consoles wasn't to be found there. Then I turned my attention to the systems of the SCOM Operators. First I found that they were running the SCOM Consoles with the /ClearCache command.

They started with SCOM when it came RTM and with RTM it was advised to use that switch. But when they upgraded to SP1, they were still using this switch. But it is Best Practice only to use this switch when there are problems with the SCOM Console. Under any other circumstances this switch is not to be used. So I deleted this switch.

The performance of the SCOM Console did improve but not enough. Then I asked them for how long they were using the SCOM Console from their systems. As it turned out, from the moment they started to use SCOM which is more than a year now. All this time they had only upgraded the SCOM Console to SP1 but never ever changed anything about it.

Besides the well known cache file when one starts the SCOM Console, another 'kind of cache' is created as well. In the registry of the current user, the navigation history within the SCOM Console is being added. And on the systems of these SCOM operators this regkey had grown hugely.

So when I deleted this key and started the SCOM Console, it was very snappy. No more sluggish SCOM Console but one which worked really fast.

Of course you can perform this 'trick' as well. But remember this regkey has a function so only do this when you are experiencing the same issues and are sure that the RMS and the SQL servers are performing well and not the cause of a sluggish SCOM Console.

First close the console and than remove this regkey: HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console.

This regkey will be recreated when the SCOM Console is started. But as stated before, make an export before deleting this key. Better to be safe than sorry...
Screendump of the regkey involved:

Distributed Application not monitored

27-08-2009 Update: When sealing a DA other issues come into play. As a result not all objects are displayed in the Diagram View of that DA. Check here for a workaround.

13-03-2009 Update: Microsoft has released a QFE which addresses this problem. It is KB958490 to be found here. However be VERY VERY careful deploying this hotfix. See Marius Sutara's blogposting about it. Look here.

When one creates a Distributed Application based on the blank (advanced) template there is a significant change the DA ends up in an unmonitored state.

When one looks at the diagramview of this particular DA it will show most of the child nodes without the green checkmark.

But when such a child node is clicked further open, the components of this child node do show the green checkmark. So these components are being monitored but somehow this status doesn't roll up to the child node and the top level node.

Whatever I tried nothing helped. Rebuilt it over and over again but all to no avail. Then - as a last resort - I put a child node into maintenance mode (this can be done when opens the DA in Diagram View) for 15 minutes. (More out of being tired about why it doesn't work as it is supposed to then anything else actually.)

And presto! Already during Maintenance Mode things started to change. Green checkmarks were appearing! The child node - first without the green checkmark - turned up in a monitored state and not only that, the top level node showed up in a monitored state as well. And even better, it stayed that way after the set time for Maintenance Mode was passed.

So with putting these child nodes into Maintenance Mode it looks like the DA is becoming aware of what components it is made off and starts working as it should.

I have repeated these Maintenance Mode steps for each child node being in an unmonitored state, and here this trick worked just as fine.

Since I can not imagine being the only one experiencing this problem I have posted it on my blog.

'Script or executable failed to run' - Part 3

08-05-2009 Update: Check this posting about a possible solution. There is a possibility that the DNS MP itself is OK but that there are problems with the way DNS is defined in WMI.

Issues with the DNS MP ?

Despite of the two earlier postings about the Alert 'Script or executable failed to run', I keep bumping into this issue at many customer sites. It has everything to do with the most recent version of the DNS MP (version 6.0.6480.0).

There are two discoveryscripts for DNS (DNS2003Discovery.vbs & DNS2003ComponentDiscovery.vbs) which keep on failing.

Strangest thing is, the servers on which they fail, scripts from other MPs (AD, DHCP, Server OS, GPO and so on) are running smoothly.

So I tend to think there is still some work to be done on the DNS MP. Until now I haven't been able to find much information about it on the internet.

So I am interested what kind of experiences others are having with this DNS MP. Hope to hear from you.

'Script or executable failed to run' - Part 2 'It is all about looks..'

Eventhough it is purely cosmetic, it is still an improvement. Whether this Alert turns up as a Critical or as an Informational Alert is a huge difference.

It keeps the Console clean and the SCOM Operators more on the edge. When 'something red' turns up, they know it is NOT an Alert to be ignored.

So by changing the Alert severity to an Informational Alert (integer 0) might come in handy.

Even when you create a special view for these Alerts and add a counter column to it, you will see soon enough what scripts on what servers are failing the most. So it is easier to troubleshoot.

No, I didn't think this one up by myself, but I found it here, posted by a person named Graham Davies (GD). Since it is a good idea I want to give it a bit more exposure.

'Script or executable failed to run' - Part 1

This message can occur many times in a SCOM enviroment and can be a bit frustrating as well. Moreover since there is not a single cause for it so there isn't a single solution for it either.

However, in all the SCOM enviroments where I bumped into this Alert message I found there are some generic causes to be found. Here I will give the most common reasons for this Alert message:

Permissions
In a certain SCOM enviroment I bumped into the situation where the SCOM-account (Agent Action) - due too strong security settings - didn't have enough permissions to start the process cscript.exe, located in the folder c:\windows\system32. By granting this account the Read & Execute permissions everything was OK again.

x64 vs. x86
When a server is x64 based, an x64 SCOM Agent will be installed automatically (when the SCOM Agent is being pushed from the Management Server that is). When this server runs a x86 application the SCOM Agent will have difficulties to discover these applications. By installing a x86 Agent on this x64 server things will run better.

Antivirus software
This software can block certain (vb) scripts to run. Microsoft has written a generic KB article about it, found here. There is also another KB article which is more specific. Eventhough it writes about MOM 2005 and an older version of certain Antivirus software, it might come in handy. Look here for this KB article.

Version of Windows Script
It seems that a versions of Windows Script below 5.7 can cause memory problems and scripts not to run. The blog of the Operations Manager Support Team wrote an article about it, so all the credits goes to this team. The article is to be found here, with the solution for it (installing Windows Script version 5.7) as well.

More than a good read

There aren't many books around about SCOM 2007. For getting 'the job done' in order to pass the exam (70-400) the Sybex book 'Mastering System Center Operations Manager 2007 ' is a good read. However, when I finished this book it left me with many unanswered questions.

How happy I was when a colleague of mine showed me the book 'System Center Operations Manager 2007 Unleashed'. This book contains many many examples out of daily practice and describes SCOM in every detail. This book has become my personal 'SCOM bible'.

It is like 'All You Ever Wanted To Know About SCOM But Were Afraid To Ask'. Even the lesser known features of SCOM like ROM (Remote Operations Manager) are described.

So when I read this blogposting about a supplement to this book - all about SCOM R2 - it really made me happy. Can't wait to read it.

For all SCOM administrators/users/supporters out there all I can say: this book is a must have.

In conjunction with some very good blogs these are the BEST SCOM resources to be found.

To my opinion these are the best SCOM blogs:
- Kevin Holman
- Jonathan Almquist
- Russ Slaten
- Steve Rachui
- Jimmy Harper
- Knowledge Base of System Center Forum

Other good SCOM related sources:
- Updates about the newest SCOM Management Packs
- Updates about the newest SCOM KBs

Whenever you have a good source as well, share it with the community. Send me the link and I will update this posting with it.