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.