Have you ever looked in OpenManage Essentials and seen the above when looking at a device? I recently had this experience when checking on a number of older servers that we were not receiving alerts properly for.
Checking on the iDRAC and server it appeared that the management agents were running and correctly configured so that the OME server could contact the device, but attempts to discover and inventory were still failing. What was going on?
The Dell Troubleshooting Tool is an excellent utility by Dell to interrogate devices using variety of protocols. Querying the iDRAC using WSMAN soon found the problem:
Many of thew older servers had internal SSL certificates installed on them, which had subsequently expired. As most of the servers had been decommissioned, renewing the certificates had been overlooked.
Getting rid of the expired certificate is not as straight forward as it should be, with no ability in the iDRAC6 web interface to delete the certificate. This was resolved by accessing the IDRAC via SSH and using the racadm command:
After the iDRAC interface rebooted to apply changes, OME was then able to discover and inventory the iDRAC interface.
The Dell troubleshooting tool proved to be a very useful tool in the infrastructure admin’s toolbox for dealing with non-obvious management protocol issues.
Last week I attended Linux Conference Australia that was this year hosted in Hobart Tasmania. The weeklong event has the first 2 days dedicated to mini conferences before the selected presentations over the following 3 days.
I was actually there by virtue of being a speaker and mini conference organiser for the Open Radio mini conference. If this may interest you, you can read about it over here on my Radio Blog. Unfortunately this meant a clash with the sysadmin miniconf, but there will be time to catch up on that.
iDRAC firmware 2.40.40 was released on 17th Oct 2016. Details can be found by following this link.
We have recently had the need to upgrade our iDRAC firmware to 2.40.40 on one of our servers while troubleshooting another issue with Dell and found shortly after that this particular server was no longer able to be discovered by Dell OpenManage Essentials.
We found that the TLS protocol the iDRAC set after updating was set to version 1.2, which is not supported by Windows operating systems less than Server 2012 R2 (Our OME server runs on Windows Server 2012). There is a patch available to fix this. This is all covered in the driver release notes.
The other alternative, which we have chosen to do for now as this firmware is only on one device is to set the iDRAC to use the older TLS protocol, which can be found under the iDRAC Network Settings in the services tab:
I’ll apply the Microsoft patch to the system, and then set the TLS back to v1.2
A couple of weeks ago SAGE-AU announced that it was undergoing a name change and rebrand, to become the IT Professional Association, ITPA.
As a long time SAGE-AU and now ITPA member, this has come as little surprise. This has been something that has been on the cards for close to 4 years now. It does however mean good things for the organisation.
What I will say though is that if you are an IT Professional in Australia, your representation to government and industry is weak. Only 5% of people who identify as IT Professionals in Australia are members of a professional body like ITPA, ACS or AISA compared to say, accountants, who have near 100% membership to CPA or ICAA.
After a long break between posts over the last two years, is time to for The Practical Admin to have a bit of an update to reflect the changes in his skill sets and equipment availability.
Most of my absence was directly related to being actively involved with SAGE-AU (Now ITPA) for 3 years which included being editor for their monthly newsletter. Since stepping down in 2015 I have been heavily involved in some local community groups.
I now mostly work with Dell Hardware, which means I do a bit with the Dell OpenManage platform of tools. I still mainly work on the Windows Server platform, and have interests in the areas of automation, PKI and platform management. These days my involvement with getting hands on with hardware is minimal.
What this means for the Blog is you’ll see a whole lot more stuff on the Dell OpenManage Platform, Microsoft Windows Server, and more. It also means that many of my hardware scripts, (Such as iLO PS Library) will no longer be supported as I have no ability to test them any more.
One of the tasts I am working on is the configuration of our fleet of Dell servers to use Dell’s Open Manage Essentials monitoring and management platform. One of the servers however had been unwilling to have it’s SNMP configuration changed using the VSphere CLI tools and was generating the following error:
Changing notification(trap) targets list to: myserver.local@162/DELLOME…
Use of uninitialized value $sub in string eq at C:/Program Files (x86)/VMware/VMware vSphere CLI/Perl/lib/VMware/VIMRuntime.pm line 81.
Use of uninitialized value $package in concatenation (.) or string at C:/Program Files (x86)/VMware/VMware vSphere CLI/Perl/lib/VMware/VIMRuntime.pm l
Undefined subroutine &Can’t call method “ReconfigureSnmpAgent” on an undefined value at C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\vicfg-snm
p.pl line 297.
::fault_string called at C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\vicfg-snmp.pl line 299.
Hrm OK fine. Lets try logging in to the Host’s ESX Shell and use esxcli to set the trap:
Community string was not specified in trap target: myserver.local
Clearly something is broken with the SNMP configuration. Luckily the VMware forums were quick to supply a solution.
The SNMP settings for ESX are stored in the XML file /etc/vmware/snmp.xml. You can either clear this file (cat /dev/null > /etc/vmware/snmp.xml) or if you know what the setting should be, modify it. in my case I needed to update the <targets></targets> XML Tag to have a community string: