Discovery no longer populating dns_name field in UIM 8.31 and above

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

This article covers a behavior change in discovery_server 8.31 and later which affects how the dns_name field is populated in the CM_COMPUTER_SYSTEM table of the UIM database. It also covers a few issues that may arise as a side effect of that and how to work around those problems.

Environment

• Release: UIM 8.31
• Component: UIMDSC

Resolution

In UIM 8.2 and prior, the discovery_server and agent engaged in specific behavior related to the "dns_name" field in CM_COMPUTER_SYSTEM which has changed in 8.31 and may impact other product areas and integrations.

Specifically, the "old" 8.2 behavior behaved in two ways:

• the discovery_server, when discovering Robots, would populate the "dns_name" field in CM_COMPUTER_SYSTEM with the robotname, even if the robotname was different from the actual server hostname.

         or

• the discovery_agent, when reporting discovered devices, would report names which weren't true DNS names (such as snmp.system name, for example) and those would be populated into dns_name.

This led to several issues with correlation, where machines were mistakenly correlated based on a dns_name that wasn't really their PrimaryDnsName.

In 8.31, this behavior has changed this way:

• discovery_server will no longer populate the dns_name for a discovered robot with that robot's robotname, but will only populate dns_name when it receives a PrimaryDnsName value for a device from a discovery_agent or probe publishing discovery messages.
  
  
• discovery_agent will only publish a PrimaryDnsName if it actually successfully performs a local "nslookup" against the IP address and receives a response from the DNS system.

The ultimate result of this change is that dns_name will now only be populated with an actual DNS Name, but as a drawback, it may be populated less frequently (e.g. show a NULL value more frequently) than users expect or desire.

Many users may not notice this change, depending on how the environment is configured, but so far we have seen the following impacts:

1. When a user who is configuring SNMPCollector requests that the probe query discovery_server for a list of devices to monitor, if the dns_name field is not populated, then SNMPCollector will use the IP address as the device's QoS source and display the device by IP address instead of hostname in the GUI, even if "PublishByHostName" is enabled

2. Users who are integrating UIM with CA Spectrum will notice that the devices displayed in Spectrum are displayed using their IP Address instead of hostnames.

3. Robots which are discovered by discovery_server, but which also fall within a discovery_agent's scope, may be displayed in USM using their hostname or FQDN, even if the robot itself has a specific name override set; ?in other words, the robot will not show up in USM using the defined Robotname, but will use an unexpected host/FQDN instead.

4. Alarms in SOI are displayed with Unknown device information, whilst the parent alarm in UIM contains the correct details of the affected device.

To mitigate these issues, we have the following options currently available:

1. If a discovery_agent can be configured to discover the devices whose dns_name is not populating, and that discovery_agent can successfully resolve the device IP's to hostnames, then this should cause the dns_name field to be populated.
   
   
2. Addiotnally, the Spectrum team has defect fixes available depending on what version of Spectrum is installed, as follows:

Spectrum_09.04.01.D26 (Defect 356539)
Spectrum_09.04.02.D34 (Defect 361512)
Spectrum_10.00.00.D04 (Defect 372320)

Customers may contact Spectrum Support to obtain these fixes, which will cause Spectrum to rely on the "name" field instead of "dns_name".

A longer term fix is being developed for Spectrum which will use the new 'DisplayAlias' property first, if available, or 'name' if not.

The discovery_server now includes the ability for customers to create an override_eval_dns_name.lua script to revert the behaviour of discovery_server so it works in a similar way as it worked prior to 8.31.

Here's how to use the LUA script:

In order to set dns_name similar to how it was set prior to 8.31, pre_v8_31_compat_eval_dns_name.lua is provided as an example.  It can be copied to override_eval_dns_name.lua to make use of it. Note that override_eval_dns_name only affects how dns_name is set and does not affect device correlation.

Additional Information

The script is located at $\Nimsoft\probes\service\discovery_server\scripts