Best Practices – Namespace

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.

 

 

 

😉

3 thoughts on “Best Practices – Namespace”

  1. Jonathan, nice post! It’s so easy to make a mess of a SCOM implementation without clear namespaces and versioning 🙂
    2 things i would like to add/mention:
    1) I always use the company name in custom management packs for customers, so everyone can see that’s it’s a company management pack (in TFS for source control, the SCOM operations console, or a file share, etc.)
    2) I always include “SCOM” or “SCSM” in the naming convention for management packs for customers, so it’s always clear for which System Center product the management pack was built. And by doing this I create a naming convention for all system center product management packs.

    Sometimes (depending on the organisation) I also include the department in the management pack name. This way it’s clear if the pack is from an certain IT department (if you have multiple for hosting, applications, etc.) or business department.

    1. Frank, thanks for your input.

      I updated the part about starting namespace with company name, because the original text was too vague. Hopefully I added some clarity and options around that.

      Including “SCOM” or “SCSM” in the namespace is a good suggestion, especially in cases where the customer uses SCSM.

  2. This applies to SCOM 2007, but I will probably continue the practice in 2012.. I create four different mps usuall. Myapp.CSTM, Myapp.OVRD, Myapp.KNOW, Myapp.DISC. CSTM for any custom monitors, rules, etc. OVRD for storing overrides. KNOW for storing knowledge (granted these are usually overrides for sealed mps, but I tend to store them in their own mp, unless I am adding knowledge to a CSTM mp directly, and DISC for discovery management packs, that are used to be the seed classes for the CSTM mp. The display names of the MP have these four letters in ( ). So My Application (CSTM) would appear in the admin console view. If you are scanning groups in SCOM you might see My Group (CSTM) or My Group (OVRD) and in the description I state what management pack these groups belong to, so as to remove the guest work from it (say if I was to leave and someone stepped into my job). I think this method can be helpful. I gave up on using company name, but that’s just me.

Comments welcome (links require moderation)