Manual Management Pack Creation

This section will go over creating a Management Pack Elements from scratch using YAMPAT. Sub-sections will have more detail on each element of a Management Pack that YAMPAT supports.

Management Pack Elements

All Elements

Most elements have some of the same fields. The following table describes the common fields among the elements.

Fields

Field Description
ID The ID equates to the "Name" inside of SCOM. It is a unique ID for the element and MUST be unique across all elements. The 'Auto ID' checkbox, will generate an ID based on the Name entered and will be formatted correctly.
Name This display name for the element as seen in most UI elements in the SCOM console.
Description A helpful description for the element.
Accessibility The values 'Public' or 'Internal' mean that this field determines whether the element can be referenced by other packs if this pack were to be sealed. In order for it to be referenced however, the pack MUST be sealed. You cannot reference an element in an unsealed pack.

Buttons

These buttons apply to most pack elements.

Alt text

  • Knowledge Article - Will automatically take you to the associated Knowledge Article if one exists in the pack. If one does not exist, it will take you to the root node of the tree to create one.
  • Apply - Will apply the changes to the pack in a pending state. If you leave the control before clicking 'Apply' your changes will not be added to the pack. You must also click 'Save' for it to be stored in the final xml file. This is a requirement of the SCOM SDK. There are some elements that rely on others in order to function and must be saved to the pack simultaniously. Clicking Apply will put those elements in a Pending state before they are added to the pack.

Placeholders

There may be cases where YAMPAT inserts an automatic placeholder entry for something that is required. The format for such entries will appear in the following format, with leading and trailing double pound (##) symbols:

##InsertSomethingHere##

Some Best Practices

Here area few best practices to keep things standardized when using YAMPAT, and for packs to be easily modifiable.

  1. Try to prioritize use of the Registry for Discovery on Windows over the other discovery types. Registry is more efficient for the agent.
  2. Create an Instance AND Computer group for each class. Even if you dont use them in your pack, others might later so it's good to just have them.
  3. Create an Aggregate Monitor if you have more than one or two monitors for an application. And only enable the alerts for the aggregate, not the child monitors. This helps reduce a ton of alert noise.
  4. Keep the timing intervals/frequencies consistent across your monitors, discoveries, and rules. This is for "cookdown". Basically, every module with a frequency or interval is run in the same module cycle. If too many monitors are on different triggering times, SCOM agents will need multiple instances of the modules for each timer. Fewer modules running means faster agents and less CPU time. Research "cookdown in SCOM" for more details on the subject.
  5. Always Seal your pack 'unless' you plan or expect the pack to be modified heavily or frequently from within the SCOM Console. YAMPAT makes this super easy.
  6. Create at least 1 State View for each class you create for an application.
  7. For State Views, try to Target the Winodws or Unix Computer class, and then scope to Computer Group class, instead of using the direct Class as the Class Target.
  8. Organize your folder structure like "Company Name > Application > App Component"
  9. Try to keep all Accessibility options as "Public" unless necessary. It helps to be able to reference your classes and such in other packs and changing that property is a "breaking change" to the pack, which means you cannot import that updated pack into SCOM without removing the pack first and reimporting it.
  10. For applications that are multi-role, create a seed class for it first, then other classes for each role or component. This requires creating "Relationships" but is better in the long term.

The 3 Golden Rules

  1. Always click 'Apply' after making a change to an element.
  2. If the pack was made with YAMPAT, it can be edited with YAMPAT.
  3. If the pack was made using another tool, I cannot guarantee it can be edited, or even opened with YAMPAT. But you can try, just make sure the packs references are in a Reference Store.