Monthly Archives: February 2013

On The Importance Of Building Test Environments

One of the things I didn’t quite grasp when I first started using SCOM a few years back was the importance of test environments. SCOM was this bright and shiny new tool that was going to help proactively monitor our servers, increase uptime, and as long as I only installed Microsoft approved Management Packs everything would be alright. This was admittedly extremely naive– but it was good starting point. I was enthusiastic as well as fortunate enough to learn that this was a terrible idea long before making a critical mistake.

SCOM is an incredibly powerful tool, but it has to be used and implemented intelligently:

-Installation guides must be read.

-MP’s should be evaluated in Test or Dev environments first (If you don’t have a test environment build one)

-Blogs should be scoured for relevant info.

-Management Packs should be installed in production because they provide value not just because you happen to have the associated product installed.

Anytime an engineer or admin asks to have a shiny new management pack installed in production and doesn’t want to test it first I remember this slide from a talk I stumbled across from Microsoft’s Management Pack University entitled “Getting Manageability Right” given by Nistha Soni, a program manager on the Ops Manager team at Microsoft:

Getting Managability Right Nista Soni

The talk was for the different Microsoft product teams to help them think about how to build better management packs that are useful to their customers. If a MP reduces total cost of ownership this is a good thing, if it increases TCO then we have a problem. This slide was referencing an iteration of a Microsoft MP–name omitted to protect the guilty– which provided feedback that while potentially useful for a developer at Microsoft, was also inundating their customers/operators with alerts.

Building a useful MP is a delicate balancing act and its important to remember that even the ones made by Microsoft are essentially a work in progress. Each successive iteration tends to get better, but if you just import into production without testing and research you are asking for trouble.

The talk itself is an interesting look at how Microsoft thinks about monitoring and building management packs and is still available here.

Tagged , , , ,

Review: Mastering System Center 2012 Operations Manager

Generally, when a new version of software comes out I like to spend some time just reading and familiarizing myself with what is new before I dive in and start tinkering. This means both searching through community blog posts as well as occasionally plunking down some cash on Amazon for a book. My first recommendation if you are buying technical books of any flavor is to buy a digital rather than paper copy. I love the user experience of a good old fashioned physical book when reading a novel or some quality nonfiction, but when it comes to technical books I want two things: portable, and searchable.

Mastering System Center 2012 Operations Manager by Bob Cornelissen, Paul Keely, Kevin Greene, Ivan Hadzhisky, Sam Allen, and Telmo Sampaio is highly readable, which is pretty rare.

There are very few technical titles that I have started and been willing to read more or less cover to cover without succumbing to boredom. Admittedly, I skimmed the beginning part on ITIL MOF et cetera–useful but nothing that hasn’t been said before– and the Powershell section at the end is nice as a reference, but feels a bit like it was tacked on last minute.  With that said, I would highly recommend this book to anyone who is new to SCOM or who works with SCOM, but doesn’t get to play with it as their full-time job.

I agree with the comments of some of the Amazon reviews that “Mastering” might not be the best title for this series, but titles are the children of publishing companies and marketing folk, not authors.

At least for the moment, this is the best overview of SCOM 2012 in book form out there right now.

The general System Center 2012 Unleashed book which touches on each of the 2012 system center releases has some noteworthy names attached to it, but based on my reading a few months ago it came out way too early to have anything really useful in it.

I will reserve final judgement until after March 7th when the new System Center 2012 Operations Manager Unleashed title comes out, but at 1536 pages I suspect that book will be more reference and less reading.

 

 

Tagged , ,

Tuning the Exchange 2010 Management Pack

One thing that I always find slightly counter intuitive with SCOM is overriding rules and monitors for the Exchange MP. Normally when we have an alert that an engineer wants overridden or tweaked in someway the easy method is to right click the alert that was generated– select–overrides–summary–and then target the override at the appropriate object–modify thresholds or settings–save to custom mp–and were done.

With Exchange Alerts it often doesn’t work that way. A few days ago when I started getting requests for overrides I followed my normal technique in this case the alerts were for:

Alert Description: Retry Remote Delivery Queue Length – sustained for 30 minutes – Red (>1) – Hub Transport.

Alert Description: The database copy is low on log volume space. The volume has reached error levels.

So as usual I clicked the alert selected overrides–summary–targeted at the Exchange Server object I wanted to override and then found myself staring at this screen for slightly longer than I would like to admit:

Where were my enable alerts, my thresholds, the things that I could change to make my Exchange engineer happy?

As my brain slowly began to process that I was looking at a rule and not a monitor I remembered that I just needed to find the associated monitor and make the necessary modifications.  In the past when I have gone monitor hunting I would go to Authoring–Management Pack Objects–Monitors and then search for the appropriate monitor. If you are doing this once, this is fine but with the Exchange 2010 MP the frequency of override requests is bit more persistent.

I have found that a better way of locating the associated monitor to override is to right-click the troublesome alert and instead of going to override, select Open–Health Explorer (If the entity is now in a healthy state and the alert is technically closed remove the Filter Monitors which automatically Scope to only unhealthy child monitors in 2012)

Then you have all the monitors that you might want to tweak right in front of you without having to navigate to authoring.

Now you can right click the individual monitors and select monitor properties and from there the overrides tab.

This is one of those simple SCOM 101 things that I am sure most SCOM admins will look at and go “well duh”, but the more I use SCOM the more I find these little inefficiencies in how I work with the application.

Tagged , , ,

Innagural post

The primary focus of this site is the Microsoft System Center Suite particularly: SCOM & SCCM though more general IT topics may creep in from time to time.