DRAC SNMP Name Change Possible?

I too would like to see a solution for this one. The default is not a terribly user-friendly SNMP name.

I _think_ you may be able to just change the DNS name of the DRAC from the GUI.  Even if you're not using dynamic DNS or having the drac register, it should still update it's internal name.  

I havn't tried it, but it seems logical.

-Jake

Sorry Jake not logical,

But you have definitely not worked with DRAC cards.  I hope you don't think I would actually post a question of how to change the SNMP name it picks up, if I could easily change it by going to the GUI interface and change the Host Name.

Sorry not that easy!!  It does not use the Host Name, as I said in the last post it is embedded and is using "RAC_XXXXX"

X's being the serial number of the chassis.

I want to bring this thread up again, as it is a valid question I have seen a couple of times before.

We are also investigating on a resolution for this problem.

I am responsible for an environment of >160 Servers and it would really be good to get the hostnames of the DRAC boards shown in ITA instead of just the Service Tag. Is there really no solution for this yet?

Thanks in advance,

Fabian

Lets see if this does it, but please reply if it fixes your issue, I dont have a drac to test this with:

from Page 94 (same link below) racadm config -g cfgLanNetworking -o cfgDNSRacName

RAC-EK00002

Page 335 of http://support.dell.com/support/edocs/software/smdrac3/drac5/145/en/ug/drac5_en.pdf

Hi reybeast1,

thanks for your answer. That was the first thing I was trying. Unfortunately this doesn't help. I was thinking about changeing the discovery settings to "DNS names" and not to "Instrumentation Name", hopeing that ITA is showing the DNS names. But unfortunately we are forced to use the "Instrumentation Name" as we also have a bigger amount of clustered servers in our environment. Dell recommends to use the instrumentation names in order to have the clusters showing up properly. The naming setting is global so I am not able to enable different naming resolutions for DRACs and Clusters.

The "RAC_ServiceTag"-name seems to be hardcoded in any kind in the SNMP settings. When using the details tab of ITA to browse the DRAC MIB, it shows the name as "sysname". So this would be the parameter to adjust. Unfortunately there is no documented RACADM command to change this setting.

But anyway, thanks for your reply!

During the card's initialization in POST it's simply reading in the service tag of the server and setting its NETBIOS name which is why it doesn't get confused when you move the card to another server and why the service tag needs to be corrected when the motherboard is serviced.  The embedded OS used by the DRAC doesn't really retain a name permanently; it's stored in memory for as long as the card runs.

So aside from using the DNS option you're kind of at an impasse.  If the name provided by the SNMP traps is the extent of the problem I would point out that monitoring the DRAC instead of the server (via Server Administrator/SNMP service) is probably not a good idea.  Yes the SNMP feature is present but its mainly for inventory purposes and would not include a number of alerts (i.e. Storage alert for a drive failure) that would be provided through the server's SNMP traps.  First you're going to be doubling/tripling the amount of traps being processed by the monitoring system database.

Second, the DRAC is essentially forwarding information from the ESM logs and if installed Server Administrator so really the DRAC doesn't have much original information to provide. Especially when the single most common piece of information being monitored is drive failures.

Finally, the DRAC's benefit is in it's ability to operate as an Out of Band management tool for offsite disaster recovery and remote management.  It has limited resources to use and the majority of them are needed for the memory running its embedded OS.   The more you have it doing the faster its going to run out of memory and the sooner it will need to reset (that does send a trap from the DRAC).  I've seen some monitoring systems like Nagios configured to repeatedly login to the DRAC or make SNMP gets on the DRAC so frequently they reset the card to death. 

So bottom line I always recommend using OpenManage where it works best and relying on the DRAC where it is most helpful.  Otherwise you're going to be dealing with unreliable information at best and possibly limiting access to the DRAC when you most need it.   Just my opinion of course but I don't think you've got an alternative anyway.