How to Correctly Create an Override for a SCOM Workflow

 

Never store overrides in the "Default Management pack". Don’t do it.

 

 In fact, rename the Default Management Pack right now to:

 DO NOT USE - Default Management Pack - DO NOT USE

 

 

If you store an override in the Default Management Pack then somewhere a puppy loses its ears and then Andres bursts a vessel.

 

What Not to Do

 

In the screenshots below are examples of the opposite of "best practice" and a great example of what I see in the field regularly. These are fantastic examples of what you should NOT do.

Notice there are an excessive number of unsealed management packs; apparently one for each and every override related to a SPN alert(s).  Additionally, there are an excessive number of generic and vaguely named unsealed packs.

 

 

 

 

An example of why this is a bad idea, consider the following for fictitious company “DIY”:

Let’s say that you want to override the Logical Disk Free Space monitor for a server: MyServer01. 

Consider the following scenario:

MyServer01 is a virtual machine on a Hyper-V cluster which consists of two physical Dell servers.

MyServer01 is also a domain controller and standalone certificate authority (with IIS) hosting a certificate enrollment website.

 

The server in question (MyServer01) is:

·         an Active Directory server (domain controller)

·         living on a Dell host

·         a Hyper-V virtual machine

·         an IIS server

 

Let’s pretend that you have the following unsealed management packs in your environment:

DIY - Active Directory

DIY - Dell

DIY - Hyper-V 2008

DIY - IIS

DIY - SCOM Overrides

 

In which unsealed MP do you store the override for the monitor???

 

You could make an argument for each of the unsealed MPs listed above!  There are plenty of articles, blogs, books, and guides which suggest that you should create a general SQL unsealed pack for your “SQL-related” overrides or a perhaps a general AD unsealed pack for your Active Directory overrides. However, we can see from the example above how this is problematic. If left up to the casual admin(s) to take a guess at which pack to use, you will end up with a spaghetti clown mess of dependencies and excessive number of unnecessary MPs like the example screenshots above.  If you follow the recommended practice outlined below, there will never be any doubt or confusion and you will have a tidy, clean, efficient environment. It requires a little bit more effort initially but it will save you much pain down the road. Don't be lazy! 

 

In the example below I demonstrate how to override a SQL Server DB Engine monitor. The best process (yes, the best) for creating an override is as follows:

*Note: I’m sure there are sticklers out there who will point out a few exceptions like many of the Exchange 2010 workflows. This article applies to normal MPs with normal workflows (rules, monitors, discoveries). This article doesn’t address overrides for custom groups either; that's where things can get really tricky. This will be addressed in a later blog post.

 

Steps for Creating an Override Correctly

 

Identify the Base Sealed Pack

1.       First identify in which management pack the workflow (monitor, rule, or discovery) is defined. You can find this information on the General tab of the workflow properties. In the example screenshot below, an alert was selected, then the Alert Monitor link was clicked to open the monitor Properties window. This is the Properties window of the actual workflow (a monitor in this case) that spawned the alert. In this window you can see the sealed management pack where the monitor is defined:  "Microsoft SQL Server 2014 (Monitoring) "

 

 

This monitor is defined in this sealed pack: "Microsoft SQL Server 2014 (Monitoring) "

 

 

 

Create the Unsealed “Buddy Pack”

2.       Now that we know the sealed management pack name, we can store the override into an appropriately named "buddy pack"; that is an unsealed management pack that should only contain overrides that apply to workflows contained within the base sealed pack. Another way to say this is that any and all overrides that are applicable to workflows in this sealed base pack, "Microsoft SQL Server 2014 (Monitoring) ", should be stored in this unsealed "buddy pack". The "buddy pack" should be named nearly identical to the base pack but with an obvious visual identifier appended. Example:  "Microsoft SQL Server 2014 (Monitoring) (OVERRIDES)" The process is demonstrated in the screenshots below.

 

Note: These instructions assume the “buddy pack” does not already exist.

 

 

 

 

 

 

Now we have an unsealed pack in which to store our overrides that are related to only the sealed base pack of the workflow. With this "buddy pack" strategy there should never be any doubt or confusion about where we should store an override related to any workflow in a sealed pack as long as we stick to the formula; a consistent repeatable process. Also we will keep our overall dependency ratio to a minimum which is a good thing. Our environment will be orderly and efficient. No clown spaghetti messes!

 

 

 

 

Document Your Changes

3.       Add a notation to the Enabled parameter with details about WHY you made the customization along with your name and a date. It’s very helpful to yourself and others to know WHY you made this change because you may not always be available to answer questions about this customization, especially at 3am. Save your changes with “OK”. (Selecting “Apply” is a waste of time for those with “admin OCD”.)

 

Note: It is possible to add a notation to each parameter that you have activated by checking the option box. However, it’s a little faster and less tedious to add all of your comments to just one line item. In this example, the only parameter being modified is the “Enabled” parameter.  For consistency, I suggest that you use the “Enabled” parameter as shown in the example above. Practically every override set includes this parameter. (I can’t think of an example right now where this parameter is not present.) Even if this parameter is already enabled by default, it’s OK to activate it, leave it “Enabled”, then add your comments to it. Consistency is important.

 

Your unsealed override packs will appear neat, orderly, professional, and alphabetized. By simply looking at the name of the unsealed pack you will immediately know what it is used for.

 

Examples:

Comments

• Anonymous
  July 25, 2016
  When you create overrides for SQL discovery, where do you store the discoveries?
  • Anonymous
    July 25, 2016
    @ThiloC, The instructions in the article apply to monitors, rules, and discoveries. Find the discovery. Inspect the properties to determine the sealed pack for the discovery. Create the "buddy pack" if it does not already exist. Override the discovery; save to the buddy pack.
• Anonymous
  December 05, 2018
  Thanks for this article. It does make sense... however, I was thinking about pre-pending something like "#OR_" to the Management Pack name so that all override MPs appeared at the top of any MP list. Most of the time when I'm creating an override for a monitor or rule (the majority of overrides I create) I want to be able to quickly see what override MPs I already have in the drop-down lists that pop-up. What do you think?
  • Anonymous
    December 05, 2018
    Hi Noah, ONLY eligible unsealed packs (most of which will be your override packs) will appear in that list. Granted, there are a few unsealed packs that show up for various reasons unrelated to your overrides, but not many. I don't see a ton of benefit to a prefix. However, don't let me stop you from using a system or process that works for you! I realize that my article was pretty strongly worded but at the end of the day, you have to do what's best for you. The ultimate goal should be to remain organized, consistent, and reduce administration pain whenever possible. Achieve that and you are winning.