SLA Management in System Center Operations Manager

The idea behind this article is to show you how you can create dynamic groups that represent different Service Level Agreements (for example GOLD, SILVER or BRONZE). Depending what SLA level is certain CI (server) it will be put in the corresponding group.

Also I should mention that this solution is already available over Internet but is described in a couple of articles by different authors an I just want to gather all the information on one place and point out some tips that will be helpful if you decide to implement such solution on your own.

ALL CREDITS GO TO KEVIN HOLMAN, TIM McFADDEN AND ALL GUYS WHO PROVIDED COMMENTS ON THEIR ARTICLES.

First you need to build your SLA model. The best way is to use Active Directory. Lets say you have 3 different SLAs – GOLD, SILVER and BRONZE then you can create 3 security groups for example SLA-GOLD, SLA-SILEVR and SLA-BRONZE. In these groups you will put the AD computer objects of your servers. For example if server SQL01.lab.com have SLA GOLD the computer object of that server have to be added as member of group SLA-GOLD. With this example you distribute all your servers in the groups depending on your SLA. If you have servers that do not have SLA you do not add them in any of the groups. When you populate the 3 groups you have to create one GPO. That GPO should apply different registry key on the servers depending in which security group is. It is good idea the reg key to be applied in path like this HKLM\Software\CompanyName with DWORD Values like SupportLevel and data like 1 for GOLD, 2 for SILVER, 3 for BRONZE and 0 for NO-SLA. So if server doesn’t belong to any of the 3 groups DWORD Value SupportLevel with data 0 will applied. This GPO should be linked to the OU where you store the computer objects for your servers.

Note: You can use your own DWORD or String values for distinguishing SLA.

This SLA model for Active Directory was developed by my colleague Yordan Dimov.

Now that we have the registry keys applied to the servers we need to bring that information in SCOM. Kevin Holman has a great article describing how to do that titled “Creating custom dynamic computer groups based on registry keys on agents”.

The disadvantage of the proposed solution by Kevin is that it populates only the the SCOM computer objects in the dynamic groups. Kevin also mentions that disadvantage. Bu there is solution for that proposed by Tim McFadden in “Dynamic Computer groups that send heartbeat alerts”. In the article you will find out how to populate the groups the SCOM heartbeat object of the servers. In the comments of the article you can also find out a way to add the cluster names if the servers that are added to particular group are nodes of a cluster. I suggest to populate the groups with the heartbeat objects and the cluster names in order not to miss alerts when you forward them to SCSM or any other Configuration Management System.

Note: You have to have some some basic knowledge about the structure of management packs and XML.

After this you might think you are ready but there are some other obstacles you may face. If you have Hyper-V servers with virtual machines on top of them and you’ve imported Hyper-V management pack you will probably stumble on one particular issue. If you add Hyper-V server to SLA group all the virtual machines that are located on that server will be added to the SLA group in SCOM also. And some of these virtual machines may even do not have SLA and you alerts for them will be forwarded to your ticketing system. I can confirm that this issue is present in SCOM 2007 but you may also face it in SCOM 2012. In the Hyper-V Management Pack there is discovery that creates relationship between the Hyper-V server and the guest virtual machines but that association doesn’t work properly as it creates these weird issues. Another issue that you might face because of that association is for example if you put Hyper-V hosts in maintenance mode all virtual machines on that host will also be put in maintenance mode. But there is a cure for these issues also. You have to disable that discovery and Kevin described how in his article “Why do my group memberships for Windows Computers have machines that don’t belong there?”.

If you follow the steps described by Kevin and you still see this association for hyper-v servers that are part of clusters I suggest to follow these steps to resolve it completely:

1. Manually uninstall all SCOM agents on all nodes part of a cluster.

2. Remove the cluster name from agentless monitoring. If you can do it trough the SCOM console follow this article “Operations Manager (SCOM) 2007 – How to remove cluster objects from scom when computer objects in cluster cannot be deleted”.

4. Delete the nodes from Agent Managed views in Administration pane.

3. Run Remove-DisabledMonitoringObject command in SCOM PowerShell. Wait 20-30 min.

4. Install SCOM agents on all nodes.

5. Add cluster name to Agentless monitoring.

Now that you fixed any obstacles you can configure SCOM to send alerts to SCSM only for servers that are in SCOM SLA group. This can happen trough the following steps:

1. Open SCOM console.

2. Open Administration pane.

3. Open Internal connectors view.

4. Find the connector that sends alerts to SCSM and configure it to send alerts alerts only from your dynamic SLA groups.

Additionally with these SLA groups in SCOM you can create different overrides depending on SLA level.

Once again a big thank you to all members of the SCOM community.