Why does Source not show me the computer name that generated the alert?

We’ve all seen little nuances with some alerts that just don’t quite provide the information we’d expect to see.  One element that displays in an alert that we all want to display consistently is Source.  When possible, Source should always display (or contain) a computer name.  However, in reality, Source does not always display computer name, and this is the cause of a lot of questions and complaints from customers and in the forums.

The problem isn’t only that we cannot see which computer generated the alert easily from the list of alerts in the object pane.  It also causes some headaches for customers who use a connector to forward alerts to other systems, because these connectors and external ticketing systems are expecting Source to contain a computer name.

An example of an alert where Source does not contain computer name.

Not very helpful, is it?  We know the alert generated but cannot see at a glance by which computer.  Why do we not see a computer name, and how do we fix this problem?

Why does Source not contain computer name?

We do not see a computer name because either the Discovery Mapper was not configured, it might have been configured incorrectly or the targeted class is not hosted by or based on a class that can resolve a computer name.

The last case is either not possible to fix or would require significant reworking of the entire management pack.  However, the last case is not very common, and is usually not possible because the alert was generated by some aggregate or dependency monitor where the source is a Distributed Application or a rollup of health determined by an algorithm which evaluates health across multiple computers.

The good news is the first two cases we can fix, and I’ll show you how.  The bad news is if this is a sealed vendor management pack you are stuck with it unless you are so bold as to unseal the management pack and essentially “own” it, because once you unseal a management pack the vendor will most likely not support it any longer and you will NOT be able to upgrade to subsequent versions the vendor releases.

How do we fix this to display a computer name?

In my example, the alerts that do not show computer name are generated by a rule that is targeting a class named ApplicationX.FileServerRole.  As we can see in the Source of the alert, it contains the name of the Discovery that discovers instances of the ApplicationX.FileServerRole class.  Because the alert Source contains the name of the Discovery, this is a classic case of the DisplayName property not being mapped.  If the Source contained anything other than the Discovery name, then this is a case of the DisplayName property being mapped to some other property that isn’t helping us here.

Open your management pack in the Authoring Console, and take a look at the properties of the discovery for the class your rule or monitor is targeting.

Open the Discovery that needs to be fixed

Click on Configuration tab, then click Configure…

Click on the Discovery Mapper tab.

Notice that Entity\DisplayName is blank.  Remember, this is the classic case observed when the alert Source contains the Discovery name.  If Entity\DisplayName is currently mapped in your case, then whatever property that is resolve here will be what is displayed as Source in your alert.

The simple fix is to map this to the PrincipalName or NetbiosComputerName property value.  In most cases, you can resolve this by walking up the hosting path to Windows Computer.

Expand the fly-out and navigate the hosting path to Windows Computer.

Selecting either PrincipalName or NetbiosComputerName is okay.  If you are monitoring computers in more than one domain, sometimes it is better to map this to PrincipalName since we might want to see the FQDN.

Now it’s mapped to display the FQDN.

Now any alerts generated by a rule or monitor that targets this discovered class will have a Source that contains computer name.

Not only future alerts will have computer name, but SCOM recognizes this change in the class properties and updates alerts that were previously generated with the computer name (this will happen after the next discovery interval).  The above image is actually the same alert I showed you at the beginning of this post.  Nice!