Adding to the best practices category, I will discuss the entity display name.

Note: Check back if you find yourself thinking about this stuff later, because I may update these pages at any time!

 

Entity Display Name

 

The first time I realized entity display name was so important was when I was authoring a monitoring pack some time ago, and while testing some monitors I noticed the alerts had a source of the class system name. I wrote about my experience in a previous article.

I learned a valuable lesson by not assigning a value to entity display name, and it got me thinking about so many other monitoring packs that have the same issue – and some of these packs are from Microsoft, by the way.

The biggest offenders to me are the Windows Operating System packs. There are many monitors in those packs that target types with entity display names of something like "Microsoft Windows Operating System XXX".

Ever notice all the Windows alerts in the Operations console that have a source of "Microsoft Windows Operating System XXX?" When a Windows server is low on free memory, is it useful in any way to draw focus of the operator to the version Windows? I don’t think so – and the source column is the all important default focus column in the console.

The point here is, ALWAYS assign computer name (PrincipalName is preferable in most cases) to entity display name whenever possible – and this is accomplished in the discovery of that object, not in the monitor. I’m not sure why Microsoft and some others haven’t fixed this problem, but I have a hunch it has something to do with versioning – in other words, it was baked into the pack from the beginning, and changing this would break upgrade compatibility for future packs.

I say "whenever possible" because sometimes it’s really not very possible. But 99% of the time, it is. The only time it can be a real challenge, is when we’re dealing with distributed applications, client side monitoring (perspectives) or a connector-based management pack – even still there are ways, but I won’t get into that here.

 

The nuts and bolts of a good system entity display name looks like this.

 

Define entity display name for the class type (not required)

<DiscoveryTypes>
  <DiscoveryClass TypeID="YourPack.YourClass">
    <Property TypeID="System!System.Entity" PropertyID="DisplayName"/>
  </DiscoveryClass>
</DiscoveryTypes>

 

Set entity display name property in a registry discovery (suggesting PrincipalName)

<InstanceSettings>
  <Settings>
    <Setting>
      <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
      <Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
    </Setting>
  </Settings>
</InstanceSettings>

 

Set entity display name property in a script (programmatically passing a name)

call oInst.AddProperty("$MPElement[Name=’System!System.Entity’]/DisplayName$", PrincipalName)

 

Set entity display name property in a script (auto-assign a name – netbios example)

oInstance.AddProperty "$MPElement[Name=’System!System.Entity’]/DisplayName$", "$Target/Property[Type=’Windows!Microsoft.Windows.Computer’]/NetbiosComputerName$"

 

Moving on to other types of display names…

 

Regular Display Names

 

Other types of display names are pretty straight forward throughout the pack – these are just user friendly names your operators and administrators see in the UI. These display names do effect user experience, and are just as important as the entity display name.

Be sure you are familiar with namespaces before getting into display names, because namespace is equally important.

Display names are pretty easy to understand. It’s a short snippet in the pack that assigns a user friendly name to any element. It looks like this:

 

<DisplayString ElementID="YourPack.YourElement">
  <Name>I'm a display name!</Name>
  <Description>I'm a description of this thing!</Description>
</DisplayString>

 

It’s simple. In the LanguagePacks section of the pack (or fragment), just add a few lines to give a user friendly name to the elements that you’ve created – right? Don’t forget a description, because that’s always helpful for others that may be looking at your stuff – don’t pull a "superwall" (inside joke).

For the name – be succinct. 2 to 5 words to briefly describe the discovery, rule, or monitor.

For the description – go to town on what that particular workflow does. This is an opportunity to document what the workflow does, and it’s always good to be verbose here.

At a minimum, ALWAYS provide a display string for classes, discoveries, rules, and monitors. Classes – be minimalistic with 3 or less words, if possible. Pay attention to the fact that classes in other packs might have the same name, so differentiate your class display name from those other classes. An example of a poor name is "Logical Disk", because this name is already assigned to a base class in the Microsoft packs.

Other elements, like relationships, data sources, and monitor types – these things aren’t quite as visible to most operators or administrators. Although it is still imperative to user proper namespace, missing a display name on these elements probably will not degrade usability much, if at all.

 

This is an open forum – your comments are welcome. I do not check or moderate comments (I support freedom of speech).

If you have a particular subject you’d like me to talk about, or to call me out on anything I write, send me a message at https://projects.scomskills.com/messenger/suggestion.

 

😉

UPDATED 03/15/2015

Targets need to be carefully selected for everything from overrides, to creating new monitors and discoveries. In my experience, this is one of the most difficult concepts to grasp. A crash course in object-oriented programming (OOP) concepts is a great primer to understanding the service model framework in SCOM.

Understanding classes and how inheritance works is essential in selecting or creating targets. Every class may have one or more instances, and each class may be typed (or specialized). When an class is typed, it can be considered a concrete class in SCOM. Concrete classes are typically the best target for monitoring.

For example, Windows Computer is not considered a concrete class, and in most cases should not be targeted for monitoring. See this article for an example of how the Windows Computer class is typed.

Windows Computer is typed because there are several different versions, and each version may have different or additional monitoring requirements. Typing allows the developer to easily implement these monitoring differences, and also allows the administrator to select the correct type for new monitoring or overrides.

 

Here are some general rules for targeting:

• Target the most derived class (typed class) for new rules and monitors
• Avoid targeting Windows Computer for monitors* (see below)
• Target new rules to Windows Computer only if it applies to all versions of Windows
• Avoid creating new rules or monitors in a disabled state, only to enable for a group* (see below)
• If there is not a good target a new monitor, then create a new class and discovery

 

*The first best practice in this series:

Avoid creating monitors in a disabled state and target Windows Computer. There are very specific situations that call for any monitor to be disabled by default. Not having a valid target is not a reason – this indicates the need to create a new class.

Selecting Window Computer for new monitors will distribute that pack to every Windows instance in the environment. This in itself is not a detrimental problem – but if the monitor is disabled by default, the result is an empty white circle in the Operations Console and this is confusing to operators.

Imagine if this was a regular practice – Health Explorer could eventually turn into a list of empty white circles and monitors that do not apply to that instance.

Understanding targeting is a preface to service models, which is the framework for application health rollup. Omitting the service model will inhibit the ability to create useful dashboards in the future.

If you have a particular subject you’d like me to talk about, or to call me out on anything I write, send me a message at https://projects.scomskills.com/messenger/suggestion.

UPDATED 03/15/2015

In this article I will discuss namespaces in SCOM and things to consider when developing a pack.

One of the first things to consider when creating a new management pack project is namespace. It may seem like a trivial decision, but it’s important to adhere to some guidelines when choosing a namespace.

Here are some reasons why namespace is crucial:

• Monitoring pack versioning
• Better intellisense experience (code completion)
• Understanding data in the database

 

Let’s get into each of these points.

 

Monitoring pack versioning

Just like there are different versions of Microsoft applications, each requiring it’s own version of a monitoring pack, many organizations run different versions of line-of-business applications. Different versions of an application usually have slightly different monitoring requirements.

If there are different versions of an application being used in your organization, it is imperative that you version each monitoring pack to the application version. Even if it is not expected to monitor more than one version of an application, it is a good idea to couple the version of a monitoring pack with the application version.

A standard namespace convention I follow for is:

 

[application name].[application major version].[application minor version]

Example: ApplicationX.2013.123

 

Minor version is optional and usually is not used – it depends on your application lifecycle and monitoring requirements.

I have seen many companies include their company name in the namespace. Although there are reasons to do this, this is more of a preference in my opinion. The main idea is to ALWAYS follow the naming convention your company uses.

One reason you might want to start your namespace with your company name is so all your company packs will logically grouped together in the Operations Console. It also makes it a bit easier to select your packs using the Operations Manager Shell or in SQL queries.

If you are a consultant and developing packs for customers, you should use the naming convention established by that client. If the client hasn’t decided on a namespace, have this conversation with them – it adds value to the engagement.

For vendors or resellers that develop a packs for the marketplace, it’s a good idea to start the namespace with your company name as follows:

 

[company name].[application name].[application major version].[application minor version]

Example: MyCompany.ApplicationX.2013.123

 

Some other suggestions about namespace are:

• Do not use underscores
• Do not use any other special characters (alpha-numeric only)
• Use camelcase (CamelCase), not snakecase (snake_case)

 

Better intellisense experience (code completion)

Based on the namespace examples above, system names are further expanded when developing a monitoring pack. Each element needs a good name and should be separated by a period (.).

Keep in mind that a namespace has nothing to do with what is displayed to the user – it is a system name that is usually only visible to a SCOM administrator or developer. I discuss display names in another later article.

If you are a SCOM developer, and you use the Visual Studio Authoring Extensions, good system names appended to the namespace is a convenience because it makes intellisense much easier to navigate.

For example, MyApplication.123 should be extended for all elements like this:

• MyApplication.123.Class.[class name]
• MyApplication.123.Relationship.[relationship name]
• MyApplication.123.Monitor.[monitor name]
• MyApplication.123.Rule.[rule name]

 

Again, the primary reason for this naming convention is to make intellisense navigation easy – you will understand this once you start developing monitoring packs using VSAE – but it also makes data analysis easier, which is discussed in the next section.

 

Understanding data in the database

One of my chief complaints about authoring anything in the Operations console is the inability to control namespace, because the SDK automatically generates unique identifiers. This can result in confusion and extra work when triaging or investigating monitoring data, because the database will be filled with UIGeneratedXYZ*.

I always recommend never creating anything in the Operations console – this includes new monitors, rules, and using the monitoring wizards. Groups are an exception – sometimes it makes more sense to create groups using the Operations console (e.g., notification subscriptions). I understand that not everyone has the ability to develop monitoring packs using the Visual Studio Authoring Extensions, but this is a good reason to learn.

 

Also check out this article on display name best practices.

 

If you have a particular subject you’d like me to talk about, or to call me out on anything I write, send me a message at https://projects.scomskills.com/messenger/suggestion.

 

 

 

😉

I have started a best practices category to address various framework, process and decision-making considerations for management pack design and development, architectural design and deployment, and general automation and integration topics.

The articles in this category are a culmination of my experiences and lessons learned over the years, with the intent of helping the architect and administrator build a good foundation and avoid common pitfalls. This is in contrast to the typical how-to or break-fix article, and many of these articles are open to interpretation and discussion.

Send me a message if you have a particular subject you’d like me to talk about.