One of the most commonly used classes in SCOM is Microsoft.Windows.Computer from the Microsoft.Windows.Library management pack. It has a number of properties including:
Microsoft.Windows.Computer
- PrincipalName
- DNSName
- NetbiosComputerName
- NetworkName
The property of NetworkName has caused me a lot of grief because some (poorly written?) management packs use it interchangeably with PrincipalName. I'm not exactly sure how NetworkName is set or what its intended uses are. But I have seen that it appears to be set inconsistently. On most of my computers PrincipalName, DNSName, and NetworkName are all the same. But on a few thousand of them, NetworkName matches NetbiosComputerName.
So, how do you know if you have the problem? The most easy way is to check the SCOM database.
SELECT * FROM [OperationsManager].[dbo].[MTV_Computer] WITH (NOLOCK) WHERE [PrincipalName] <> [NetworkName] AND [NetworkName] IS NOT NULL
That should return zero rows. If it doesn't, then you have computers where the NetworkName property doesn't match the PrincipalName, and may be at risk if you have management packs that assume they are the same.
Our most catastrophic problem was with the Hewlett Packard management pack, where discoveries and monitors liberally interchange NetworkName and PrincipalName. But many other MP's make the same assumption.
Here are some examples of discoveries from the Windows 2008 R2 Remote Desktop management pack.
This one correctly uses PrincipalName.
This one makes the false assumption that PrincipalName and NetworkName are always the same. I can say from experience, that they are sometimes, but not always the same.
So, what can we do about this?
My first suggestion is to avoid using NetworkName in our custom management packs as much as possible. But how does that help us with the off-the-shelf management packs that make this dangerous assumption?
From what I can tell, NetworkName is only ever discovered once, right after agent installation. So if you make a simple discovery to fix it, it should stay fixed.
A very simple solution is to use an unfiltered registry discovery, and just set NetworName to be the current value of PrincipalName. Here is an example that I use:
<Discovery ID="FixNetworkName.Discovery" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID="Windows!Microsoft.Windows.Computer" />
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.RegistryDiscoveryProvider">
<ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<RegistryAttributeDefinitions>
<RegistryAttributeDefinition>
<AttributeName>SystemKey</AttributeName>
<Path>SYSTEM</Path>
<PathType>0</PathType>
<AttributeType>0</AttributeType>
</RegistryAttributeDefinition>
</RegistryAttributeDefinitions>
<Frequency>21600</Frequency>
<ClassId>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/NetworkName$</Name>
<Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
</Setting>
</Settings>
</InstanceSettings>
</DataSource>
</Discovery>
After deploying this, a number of management packs started working correctly for us. I'll attach the example MP to the blog post.