FQDN in Displayname / LMS3.2

Unanswered Question
Jan 26th, 2010

We don't want to see the Domain Name at the display Name. But all devices having a local domain name (for SSH) configured will show FQDN instead of name only.

The Discovery Settings are:

1. Name only, not FQDN

2. SysName. Cant use Name, because all IP-Interfaces will be resolved reverse - so we cant force the automatic Management-IP choise to that what we want.

How can we suppress the domain names of the devices with Sysname set at Discovery Settings? When the discovery settings was Name instead of SysName before, the domain names was suppressed, but the choise of Management-IP's was catastrophic.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Tue, 01/26/2010 - 16:43

If the preferred DCR display name is "Host Name" then any time Discovery updates DCR, it should use the hostname only.  What are some of your device's FQDNs?  Post your NMSROOT/conf/csdiscovery/CSDiscovery-config.xml file as well as all CSDiscovery-config.xml files under NMSROOT/objects/csdiscovery/*.

STEFFEN NEUSER Wed, 01/27/2010 - 02:11

Yes only devices with local domain-name configured will display the FQDN.

Attached the XML's: names, IP's and Communities has been scrambled.

Joe Clarke Wed, 01/27/2010 - 19:43

The configs look okay, but what about the actual device names which are being improperly updated in DCR?

STEFFEN NEUSER Thu, 01/28/2010 - 00:03

The problem still exists even after the next 2 discoverings with same discover settings.

The FQDN will be shown for devices that have configured:

ip domain name x.y.z

and for all other devices not. Its currently just a fiew devices, but we plan to rollout SSH and for keygen you will need the local domain-name set.

So we are afraid, to get the UNWANTED FQDN display for all devices. Guess there is a bug, if in LMS=> Management-IP choise: SysName instead of Name is set, than DCR will append the local configured domain-name to host and displayname. Is this the case?

Joe Clarke Fri, 01/29/2010 - 18:55

No, this is not the case.  The code to update the DCR display name is independent of the management IP address algorithm used.  The domain name should be getting stripped off.  But without knowing EXACTLY what the FQDN is for one affected device, I cannot run it through the algorithm.

STEFFEN NEUSER Wed, 02/03/2010 - 01:46

Will DCR strip the domain as well, if the SNMP sysName @Standard-MIB will contain the Domain-name, that could be the case if local domain name is set at the device? If there is no workarround, is it possible to activate SSH at devices without the need for setting the local domain?

Joe Clarke Wed, 02/03/2010 - 15:05

DCR won't strip the domain name, but when Discovery adds or updates a DCR entry, it should strip the domain name (if so configured).  If the

FQDN contains more or less than four dotted elements, then domain truncation should just work.  I don't see any problem with the code in th

at regard.  If the FQDN is exactly four elements, then there could be an issue depending on the specific FQDN.

No, you can't use SSH without a domain name component.

Martin Ermel Wed, 02/03/2010 - 23:55

could you post a screenshot of the discovery settings that shows how the display name will be choosen (and are these settings the same for adhoc and scheduled discvery?)

STEFFEN NEUSER Thu, 02/04/2010 - 11:38

Hups, 2 Discovery Profiles now?

Where could we seperate between adhoc and scheduled discvery settings?

Martin Ermel Thu, 02/04/2010 - 16:19

Yes, I think it was introduced with the LMS 3.0.1 update.

Adhoc discovery
CS > Device and Credentials > Discovery > Discovery Settings
here you can define the settings for a discovery cycle that gets started by clicking on the button "Start Discovery"

Scheduled discovery
CS > Device and Credentials > Discovery > Discovery Schedule
if you click "ADD"  a scheduled discovery job gets added. It has the settings from the CURRENT adhoc discovery, You can change them by clicking on "Edit Setings" when the job is created
That is, if you change the settings for the adhoc discovery and add a second scheduled discovery afterwards, the scheduled discovery job will have the settings of the changed adhoc discovery

You can use this feature to test different settings in bigger environments - but you have to take care if a configuration change is necessary - it must be done for all relevant discovery jobs:

And for the determination of the display name have a look at the attached document in this thread, perhaps this could shed some light into the process - I think it is still valid:

STEFFEN NEUSER Fri, 02/05/2010 - 01:00

Than we still have one "Discovery Settings". I was first thinking after reading your last message, that could be another place to store the settings for scheduled discovering or a possibility to make different profiles for discovery settings for different purposes as with Default Credentials introduced with v3.2. But Joe checked alrady the GUI compiled XML's containing the real settings where the engine is working from and found them OK.

Yes I now this 2 kinds of discovering: immedietly, after changing discovery settings and scheduled. Do you still need the screenshot - because I'm no more onsite at this customer and I must ask him?

Joe Clarke Fri, 02/05/2010 - 10:38

This is not a factor.  I already checked this by requesting the XML files.  The settings are the same for scheduled and ad hoc discoveries.

STEFFEN NEUSER Mon, 02/08/2010 - 09:30

As assumed, the box itself will add the domain name to the host-name, a snmpget will output:

SNMPv2-MIB::sysName.0 = STRING: c6506-xxxx.intern.xyz.de

So I see only 2 possibilities if you want to see SSH configured devices without Domain name in LMS and need the Management-IP rule sysName instead of DNS:

Either there is a possibility to configure SSH without local domain name at devices - I don’t know any

Or LMS need to strip the domain name from sysName, if the Radio Button is away from "FQDN"

What can we do?

Joe Clarke Mon, 02/08/2010 - 09:40

This hostname should produce c6506-xxxx when put through the algorithm.  You should open a TAC service request so more debugging can be



This Discussion