Server Management - Systems Insight Manager
1832102 Members
3209 Online
110038 Solutions
New Discussion

Re: SIM - Device display names

 
SOLVED
Go to solution
babecassis
Occasional Advisor

SIM - Device display names

Our SIM setup uses the systems hostname (aka Preferred System Name) as the default displayname. Is there anyway to make the default display name the Network Name (includes the domain name)? The reason being is that we have several machines with the same name, but part of different domains.
8 REPLIES 8
babecassis
Occasional Advisor

Re: SIM - Device display names

Alternatively, I would be just as happy is the Preferred System Name would be the full network name (including domain).

Thinking it through this would actually be better for reporting as well.
pmlb
Frequent Advisor
Solution

Re: SIM - Device display names

Hi,

From HP SIM 5.3 Technical Reference Guide
Chapter 9 Networking and security
Configuring the system link :

1. Select Options->Security->System Link Configuration. The System Link Configuration page appears.

2. Select from the following options:
* Use the system name. Select this option to use the system name.
* Use the system IP address. Select this option to use the system IP address. For systems with multiple addresses, you can enter multiple links.
* Use the system full DNS name. Select this option to use the full system DNS name.

Hth.
Pierre-Marie
babecassis
Occasional Advisor

Re: SIM - Device display names

I swear - that is the one place I did not look! Thanks for your help!
babecassis
Occasional Advisor

Re: SIM - Device display names

I should not have closed this thread before actually trying the solution. I have the option discussed; however it does not do what I request - The system link option is for creating relationships between managed systems and the CMS.

I want the display name of a managed system in SIM to be the network name and not the hostname. Very different
Michael Bernich
New Member

Re: SIM - Device display names

I have the same issue

we have a multi domain linux environment

server1.NY.domain.com
server1.CH.domain.com

in this case SIM sees server1 as a duplicate

I want to make perferred systems name a FQDN


zeroagemain
Frequent Advisor

Re: SIM - Device display names

Me too.
Association will not create properly (even with "Use full DNS name" when creating associations) because preferred name shows up as 'hostname' only.

So we have a clash between the server itself and it's iLO;

server.domain.ac.uk

server.ilo.domain.ac.uk

The obvious way around this would be to make the Preferred System Name = FQDN. Does anyone know how to do this, or an alternative workaround?
jim goodman
Trusted Contributor

Re: SIM - Device display names

After changing you system link

 

Did you verify both forward and reverse DNS?

 

Have you attempted to delete and re-discover it according to its FQDN to see if that makes a difference?

 

I haven't run into many occassions to need this and seems like I have done it at least once or twice over the years when encountering CMS monitoring another DR Domain where all servers had the same name just different suffix - off the top of my head these would be the first things I'd probably try.

zeroagemain
Frequent Advisor

Re: SIM - Device display names

Hi Jim,
Yeah fwd and reverse DNS are fine for both domains from the CMS, and I did delete and rediscover by fqdn.

To clarify, discovery (or identification) ALWAYS seem to set the Preferred Name field to HOSTNAME and never to the FQDN. So unless anyone knows a way to do change this automatically (there are some workarounds I've found below for anyone keen enough to read on..) then SIM doesn't function properly in multi-domain environments where the same hostname exists in different domain (as a reminder, in our setup every HP host is duplicated by name in the ILO VLAN).

There appear to be about 6 unresolved threads all asking this same question so I'm guessing it's a big deal for other people and not just us, as such I've added as much detail as I can below as both a request for help and some hints/tips for other people having the same problems;

What actually happens is that we discover the iLO VLAN (incl OA and VC etc) without any issues (preferred name=hostname in iLO VLAN and a placeholder is made for the server/OS based on its serial number as expected), but when we go on to discover the 'real' server/OS range (where preferred name is hostname in server VLAN and therefore clashes with existing iLO entry) it is OK for a few minutes then the following error appears as a result of the clash between Preferred Names: "The drilldown tool cannot be launched.The current user is not authorized to run the tool on the particular system". I'm admin with full privileges so it took a while to work out that this was caused by the hostname issue.

Some further info & potential alternatives/workarounds (to help others, not suitable for us alas..);

- Changing the System Link option to FQDN does not fix the issue (this fixes links between systems where fqdn issues exist but does not help for the multi-domain same hostname issue)

- Running discovery using a hosts file that contains both the iLO range and server range in the same file appears to resolve the issue (in SIM, iLO = hostname and Server = FQDN) - but this is no good for us as the overhead of creating such as hosts file in a fast changing environment is too high to be practical)

- One option would be to rename all systems in the iLO VLAN but I'm reluctant to do this for the sake of a single application, whatever it is

- Another option would be to manually edit the preferred system name on every host within SIM but again the overhead is too high (plus there is only a small windows of opportunity to get to the editing tools before the object is unusable).

I'm assuming there is no fix out there yet, but please HP could you incorporate a workaround to this in a future release? SIM was ditched at our institution by the previous server admins a few years ago due to functionality issues and I've fought long and hard to reintroduce it but problems like this aren't helping my cause and I suspect we will end up having to use an alternative monitoring solution once again.