Join myITforum Community

I acknowledge and agree to Penton's Terms of Service and to Penton's use of my contact information to communicate with me about offerings by Penton, its brands, affiliates and/or third-party partners, consistent with Penton's Privacy Policy.

By clicking below, I acknowledge and agree to Penton's Terms of Service and to Penton's use of my contact information to communicate with me about offerings by Penton, its brands, affiliates and/or third-party partners, consistent with Penton's Privacy Policy.

DPM as a Distributed Application in SCOM

In Operations Manager 2012 there is something known as a Distributed Application (DA). The purpose of a DA is to give you the overall health of an application made up of different multiple objects. DA’s pull in objects that are already being monitored by SCOM. An example of using a DA could be to provide the health of a web application that consists of backend databases and front end web servers. Both the backend databases and front end web servers are objects that are monitored separately but together make up the entirety of the web application. Monitoring these alone lets you know what the health is of each object but when one of the objects is in a critical state it does not always help put two and two together that these objects make up the components of the web application.

When an infrastructure has multiple DPM servers a DA can be used to get an overall health of your DPM as a service vs… the health of each DPM server through state views trying to track down the root issue. We are going to create a new name for our multiple DPM servers. We need to do this because multiple DPM’s brought together in a DA become a service. We are going to call this “DPM Service”. DPM as a DA can be useful for quick spot checking of your DPM service health. Using a DA also allows you to connect relationships between the health of objects that make up DPM. For example you can see the health of disks in the DPM storage pool, tape libraries, SQL databases, protected servers and the DPM servers.

In this post I am going to cover setting up DPM as a DA using the Distributed Application Designer (DAD) and show what it looks like after DPM is a DA. There are a few items that need to be covered before you can setup DPM as a DA. These are:

You need to have DPM Central Console installed in SCOM.

All DPM servers that will be a part of your DA DPM Service will need to have the SCOM agent installed.

Create a custom management pack to store your new DA in SCOM.

Setting up a DPM DA using the Distributed Application Designer

In the SCOM console go to: Authoring.

Right click on Distributed Applications and select Create new distributed application.

The Distributed Application Designer (DAD) will open.

Enter in the information about your DPM Service.

The fields you will need are highlighted in the following screenshot.

In the Template box, select the template for the starting point of the distributed application. Chose Blank (Advanced).

Choosing advanced is going to give us a blank template to work from and this is what we want.

Select your custom management pack that you made for this DA and click OK.

Now we need to create a couple of component groups. Let’s create the following:

Databases

Servers

On the top menu click

Name your component group

select All Objects

Now we need to add the objects that will be included in the component groups.

Let’s do a search for DPM. It will pull up all objects related to DPM.

Select the objects you want and drag them out to the appropriate component group.

For example select the DPM databases and drag them to the Databases component group.

Now drag the DPM servers to the Servers component group.

Now click on

Now with click on one of the component groups and create the relationship.

You can see this in the following screenshot.

This is what you should see when it is all done:

Here is an example of DPM as a DA that is more complex:

I just wanted to show that we could add a lot of more objects and their relationships if we needed to see that at the top level of the DA.

However in this blog post we are going to stick to the simple DPM Service DA we created.

Viewing the DPM DA

Now that we have created the DPM Service DA let’s take a look at it in action.

Before we do here are some common uses for running DPM as a DA in SCOM:

Quickly see what agents are tied to what DPM servers.

Quickly see what storage or tape libraries are tied to what DPM servers.

Quickly narrow down issues.

One of our DPM servers and it’s database is offline:

We have healthy SharePoint Protection Group:

We have a problem with our HP Tape library and our Exchange Protection Group:

The following screenshot is an example of viewing the DPM service in the SCOM Web Console.

You will notice this looks the same as it does in the full SCOM console.

Stay tuned for follow up posts on creating a Service Level Objective for the DPM Service DA and building out some dashboard widgets that encompass the SLA, state view and performance of the DPM service DA.