SCOM R2: Service Level Dashboard

Even though SCOM R2 already contains a good working solution for Service Level Tracking (look here for a blog posting of mine about it), Microsoft released an additional solution for it, named the Service Level Dashboard (SLD), to be downloaded via Microsoft Connect.

There is much to tell so let’s start. For the answers of the questions I have used the SLD document a bit.

Question 1: What does it add compared to the default solution already available in SCOM R2?

This solution is built on Windows SharePoint Services 3.0 and designed in such a way to work in conjunction with SCOM R2, configured to monitor business critical applications. When the SLD components are correctly configured and operating, the dashboard displays – almost real-time at 2 to 3 minutes (!) – summarized data about the service levels.

So this solution combines the strengths of SharePoint and SCOM. Besides that, no more need for a manager to request access to SCOM in order to know whether the SLA’s are being met, since the measured results are available in SharePoint.

Question 2: How does it work?

In SCOM one defines the service level goals (named Service Level Objectives, or SLOs in SCOM) against an application or group of objects. Here the service level targets are set as well.

The SLD evaluates each SLO over a defined time period and decides whether it met its goal or not.

The dashboard displays each SLO and identifies its states based on the defined service level targets. The dashboard can display a maximum of six different applications or groups.

Question 3: What does the dashboard summarize?

• Current status & health of all defined SLOs
• Service Level Metrics
• Mean Time To Repair (MTTR)
• Mean Time Between Failures (MTBF)
• Service Level Trends

Process Flow of the SLD:
(picture taken from SLD document)

Requirements
Of course a working SCOM R2 environment is needed. Besides that:

• SharePoint Services 3.0 (SQL Embedded won’t work)
• SCOM Reporting (Data Warehouse database)
• .NET framework 3.5
• A good translation of the SLAs to SLOs in SCOM
• Good knowledge of SharePoint Services 3.0
• Good knowledge of SCOM R2

Quick Guide
Here is described how this solution is installed, configured and some SLOs are built and displayed in SharePoint. This quick guide presumes SharePoint 3.0 is already present, configured and in working condition.

• Import the SLD MP in SCOM (only one file)
• Run the SLD wizard on a server where SharePoint 3.0 Central Administration is installed
• Follow the steps in the installation wizard
• Open the SLD site after the installation to see all is well. When this is displayed something is wrong…
  
  All is well when this is being displayed:
  
• In the SCOM Console, built one or more Service Level Tracking Management Pack Object(s). (Authoring –> Management Pack Objects –> Service Level Tracking). Of course one can built a Web Application first, use this component in a Distributed Application and target a SLO against it.
• Now open the SLD SharePoint Site and configure it to display the SLOs:
  
  The SLOs to be displayed are selected:
  
  
  The Windows 2003 Servers meet their agreed SLA:
  Oops! The SQL-servers don’t meet their SLA:
  
  
  The earlier mentioned MTTR and MTBF:
  The SCOM WebConsole is also under surveillance:
  

Conclusion
With this new solution – even though it is still in beta – Microsoft has shown its dedication to SCOM/OpsMgr. It delivers added value for many organizations and combines the strength of SharePoint Services 3.0 and SCOM R2.

Now managers can see – almost real-time – how the Business Critical systems/applications are performing and whether they meet the SLAs.

With this a good tooling has been brought to the market which enables businesses to get a good insight of their processes and their weakest links.

Even though this solution is rather easy to implement one must realize that the most of the time needed to make this work is a good translation of the SLAs to the SLOs in SCOM/OpsMgr.

Otherwise one is looking at a nice dashboard but getting wrong information.

Therefore preparation is the keyword for which most preparation must be done at the organizational level instead of the technical level. Only than this solution will live up to its promises.

Since this SLD is tightly integrated with SharePoint, it can use it’s security as well. Therefore the dashboards can be separated from each other. So customer X can only see his/her related dashboard and customer Y can only see his/her dashboard.

For companies using SCOM as a hosted service, this is a huge advantage. Their customers can now see how their systems are performing.

Special thanks
It took me a while to get everything working. As stated before in an earlier blog posting of mine, this wasn’t because of the solution but because of problems within my SCOM test environment and a shortage in my knowledge of SharePoint.

The Program Manager for this solution, Raghu Kethineni, has been of great help to me for making this work. Thanks Raghu!