Designing the perfect SCOM report – my workflow (Part 1/3)

Intro

It was more than four years ago when I created my first SCOM report. I have authored several dozens since that. Some of them were great, most were just good. Many people asked me how do I do that and assumed that report authoring for SCOM is something really complex. In fact, it is not. At least it is not more difficult than writing non-SCOM report or your own resume. The only thing one need to author good SCOM report is to understand the process and follow it.

The process is simple:

  1. Get knowledge;
  2. Prepare your development environment;
  3. Plan;
  4. Implement;
  5. Test.

That’s it. Pretty simple, isn’t it?

Now let’s discuss all these steps in details.

Get knowledge

No doubt, you’ll need some knowledge and skills. I don’t think you’ll start to build a house without having read a couple of books. Fortunately, report authoring is not a rocket science and you do not need to possess a license for that. The price of mistake is pretty low when you start, so just open your favorite browser and search for online learning materials for the  following:

  1. Querying the SQL Server with T-SQL;
  2. Building reports with SQL Server Reporting Services (SSRS);
  3. System Center Operations Manager data warehouse structure (btw, my MMS2013 session may be also useful);
  4. System Center Operations Manager management pack authoring;
  5. Report Authoring for SCOM.

You’ll find tons of articles, trust me. Study them. Don’t forget to unseal Microsoft Generic Report Library and/or Veeam extended Generic Report Library and review their implementation to get some ideas about how this could be done. Please note, that neither of these two report packs is ideal – nobody is the saint, so learn from them but do not stick to that implementation. Keep your mind open.

Get prepared

This part is the easiest one. You’ll need a development environment (lab) to write and test your reports. I prefer to have an isolated lab to avoid any possible impact on production systems. The lab will include:

  1. SQL Server to run SCOM databases (both operational and data warehouse);
  2. OpsMgr management server
  3. SQL Server Reporting Services with OpsMgr extensions installed;
  4. Something to monitor – depends on what your report is going to be about. This may be the most tricky part because you may have nothing to monitor for your specific report. Think of emulation in this case;
  5. Client PC with OpsMgr console, SQL Server Management Studio and Business Intelligence Development Studio. Be careful with versions: SCOM 2007 R2 and SCOM 2012 use different version of report viewer control. I use BIDS 2008 at a moment, so I cannot advise about later versions. You’ll need to apply some custom configuration steps to support all features of SCOM reporting – more details are available here.

Now, when you have installed everything you need, when your SCOM lab is up and running, when your rules and monitors deliver data to the data warehouse, you’re almost ready to rock! Why almost? Because you definitely need some planning before diving into code.

Part 2 (Plan)

Leave a Comment