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.
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:
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:
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:
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
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.
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.
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:
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:
The script is located at $\Nimsoft\probes\service\discovery_server\scripts