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.
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
Where I work we have recently acquired a number of Dell R620 servers to be used in remote locations. Personally I think they are a great all round server for the light to medium workloads seen on the infrastructure we manage.
I’ve been pushing hard to use automated deployment systems that rely on the iDRAC interface, with the plan being that people take the rack and stack a previously unopened server at the remote site, use the front panel to configure iDRAC Network and then come back to work to provision the server remotely. The default username and password for the iDRAC is well known. That is until recently when we placed a server on site, confirmed we could remotely contact the iDRAC and came back, only to find the defaults not working.
It would appear that certainly the batch of servers we have, and some anecdotal reports from friends deploying Dell servers is that some server’s iDRAC interface appears to have a “faulty” default password. This was confirmed with a follow up call to Dell support. Current fix is (you guessed it) to ensure you set the password before going out on site. Whilst an inconvenience, luckily this was discovered after one server went out, and not all of them.
So just a heads for people that if you are relying on you iDRAC to remotely provision brand new boxes, you may want to set the default username/password yourself rather than making an assumption it will work.
It’s been a little while since my last post, after getting involved with some major projects, however now that much of that work has been completed, I am now getting back into configuration of iDRACs. With an incressing number of Dell servers appearing at work, I want to get on top of a standard configuration as soon as possible.
My iDRAC PS Library has been out there for a while, so it would seem appropriate to create a bulk updating script with it.
please be aware that in order to run this script you will need the RAC PS Library and the racadm iDRAC tools from Dell (Available on the scripts page). Please make sure you configure the RACLibrary $racadmpath or the scripts will not run.
Hot on the heals of the iLO Library, I am pleased to release the Dell iDRAC Powershell Library. This is a script that you “dot include” in the beginning of any script you are writing so that you can have access to the functions.
The library is a wrapper for the Dell RACADM DRAC Tool (check out the Third Party Utils on the Powershell Scripts page to get) which is much like the CPQLOCFG.exe tool for HP.
What I find interesting is that the Dell tool is really well written for applying configuration, but can be a little obtuse about the results it returns (strings mainly), which is the opposite of the HP Tool who use XML for configuration and results information – where I find the XML for configuration a bit obtuse, but excellent for reporting…
Anyway, If you are managing a large number of Dell servers with iDRAC Interfaces in a windows environment, you may wish to take a look at this powershell library – it may be quite handy!
We took delivery of our first order of Dell Servers. It was exciting to have a new vendor as HP drove me to despair as many would know. 2 R810s and 3 R910s sitting on a bench in the build room. “Ben can you please run these up for us and document the build process – we need to get the R910s deployed in the next couple of weeks”. No Problem.
Did all my build documentation on an R810. Nice and easy. Learnt about the iDRAC interface, and booting the VMWare image from the SD Cards. It was all a bit easy and I could imagine with a little bit of practice we could have these machines built and deployed in about 10 mins per box. But then I started work on building the R910s….