RACADM ships inside every recent Dell iDRAC, and you can SSH straight to an iDRAC address and use it there. That is fine for one server. It stops being fine the moment you want the same setting on forty of them, because SSH to a controller gives you an interactive session and not much else. Running RACADM remotely — from your own workstation, against an iDRAC over the network — turns the same commands into something you can put in a loop, a script or a pipeline. Dell ships it as the iDRAC Tools package, and this is how to install and use it.
Why run RACADM remotely instead of SSH into the iDRAC
The remote mode is the same binary and the same subcommands; only the transport changes. What you gain is everything around it:
- one command per server instead of one login per server;
- the output lands in your shell, so
grep,awkand a CSV are available; - credentials can come from a variable or a prompt rather than being typed 40 times;
- it works from a jump host that can reach the management network, without giving that host an interactive session on every controller.
Download the iDRAC Tools package
At the time of writing, v11.3.0.0 is the current release, available for Windows and Linux:
- Windows: <https://www.dell.com/support/home/en-us/drivers/driversdetails?driverId=W3M24>
- Linux: <https://www.dell.com/support/home/en-us/drivers/driversdetails?driverId=MFV7T>
- Support for RHEL 8.10 OS
- Support for RHEL 9.4 OS
- Support for SLES 15 SP6 OS
Note: always check Dell's Support site for the latest version, as the links above may change over time. The package is versioned against iDRAC generations, so a RACADM that predates your controller may not know its newer subcommands — if a command that exists in the documentation returns ERROR: Unrecognized subcommand, check the version before anything else.
Linux installation
Tested on RHEL 9; the same steps work on Rocky Linux 9 and AlmaLinux 9, and the RHEL8 directory in the archive covers the 8.x line.
Step 1. Download the latest .tar.gz to your system
Use the links above, or search Dell's Support site for a newer release.
Step 2. Untar the archive
Replace the file name with the one you actually downloaded:
tar -xzf Dell-iDRACTools-Web-LX-11.3.0.0-795_A00.tar.gz
Step 3. Change to the directory for your distribution
cd iDRACTools/racadm/RHEL9/x86_64/
Step 4. Install every RPM in that folder
sudo dnf install -y ./*.rpm
The leading ./ matters: without it dnf treats the argument as a package name and goes looking in the repositories instead of installing the local files.
Dell's driver page describes a different layout for the same archive — a linux/rac folder with an install_racadm.sh wrapper, plus IPMI RPMs under linux/bmc/ipmitool. Both shapes are in circulation depending on the release, so list the extracted tree before you cd into it and use whichever you actually got:
ls iDRACTools/racadm/ 2>/dev/null || ls linux/rac/
If racadm is still "command not found" right after a successful install, run hash -r or open a new shell — bash caches the result of the failed lookup.
That puts racadm on your PATH. Run it with no arguments to check:
[root@rocky-a01 ~]# racadm
===============================================================================
RACADM version 11.3.0.0
Copyright (c) 2003-2024 Dell, Inc.
All Rights Reserved
===============================================================================
RACADM usage syntax:
racadm <subcommand> <options>
Examples:
racadm getsysinfo
racadm getsysinfo -d
racadm getniccfg
racadm setniccfg -d
racadm setniccfg -s 192.168.0.120 255.255.255.0 192.168.0.1
racadm getconfig -g cfgLanNetworking
Display a list of available subcommands for the RAC:
racadm help
Display more detailed help for a specific subcommand:
racadm help <subcommand>
-------------------------------------------------------------------------------
Remote RACADM usage syntax:
racadm -r <RAC IP address> -u <username> -p <password> <subcommand> <options>
racadm -r <RAC IP address> -i <subcommand> <options>
The "-i" option allows the username and password to be entered interactively.
-------------------------------------------------------------------------------
[root@rocky-a01 ~]#
Windows installation
Dell ships the Windows build as a self-extracting executable — Dell-iDRACTools-Web-WINX64-11.3.0.0-609_A00.exe for v11.3.0.0 — not as a bare MSI. Run it, let it unpack, and install the RACADM component it offers.
Then open a new Command Prompt or PowerShell window: an already-open shell keeps the old environment and will tell you racadm is not recognised even when the install succeeded. If the new shell still cannot find it, the installer did not put the folder on PATH — add the install directory yourself. Dell's driver page documents no install path and no PATH behaviour, so check where it actually landed rather than trusting a path you read somewhere. From there the syntax is identical, with racadm.exe instead of racadm.
Run RACADM remotely against an iDRAC
The remote form adds three options in front of any subcommand:
racadm -r 192.168.10.50 -u root -p calvin getsysinfo
Two things to fix immediately in that line.
Do not pass the password with -p. It lands in your shell history and in the process list, where every other user on the machine can read it with ps. Use -i instead and type the credentials when prompted:
racadm -r 192.168.10.50 -i getsysinfo
Expect a certificate warning. iDRACs ship with a self-signed certificate, so RACADM prints a warning on every call. --nocertwarn suppresses it, which is what makes scripted output readable:
racadm -r 192.168.10.50 -u racadmin -p '<password>' --nocertwarn getsysinfo
Suppressing the warning does not disable the encryption; it silences the message about the certificate not being in your trust store. If you have replaced the iDRAC certificates with ones from your own CA, leave the flag off and let a genuine mismatch surface.
A few commands worth knowing
# inventory: model, service tag, BIOS and iDRAC firmware
racadm -r <ip> -i --nocertwarn getsysinfo
# the management NIC configuration
racadm -r <ip> -i --nocertwarn getniccfg
# System Event Log, and the Lifecycle Controller log
racadm -r <ip> -i --nocertwarn getsel
racadm -r <ip> -i --nocertwarn lclog view
# read and set any attribute
racadm -r <ip> -i --nocertwarn get iDRAC.Users.3
racadm -r <ip> -i --nocertwarn set BIOS.SysProfileSettings.SysProfile PerfOptimized
# power control
racadm -r <ip> -i --nocertwarn serveraction powerstatus
lclog view on its own dumps the whole Lifecycle Controller log, which is long. It takes filter options, but they differ between iDRAC generations and some short flags are destructive on neighbouring subcommands — run racadm help lclog against your own controller and use what it prints rather than a flag from a blog post.
Loop over a list of iDRACs
This is the reason to run RACADM remotely in the first place. Put the addresses in a file, ask for the password once, and collect the output:
#!/bin/bash
read -rp "iDRAC user: " RACUSER
read -rsp "iDRAC password: " RACPASS; echo
while read -r ip; do
[ -z "$ip" ] && continue
printf '%s;' "$ip"
racadm -r "$ip" -u "$RACUSER" -p "$RACPASS" --nocertwarn getsysinfo 2>/dev/null \
| awk -F'= ' '/Service Tag|System Model|Firmware Version/ {printf "%s;", $2}'
printf '\n'
done < idracs.txt
A row that comes back with only the address and nothing after it means that iDRAC failed: 2>/dev/null is swallowing racadm's own ERROR: Login failed or ERROR: Unable to connect to RAC at specified IP address. Drop the redirect for one run to see why.
read -rsp keeps the password off the screen, and it is in the environment of this script only — better than a literal in the command line, though still visible to ps for the duration of each call. For anything long-lived, create a dedicated read-only iDRAC account rather than reusing an administrative one.
Troubleshooting
ERROR: Unable to connect to RAC at specified IP address. The iDRAC is not reachable on TCP 443 from where you are running the command. Check routing to the management network first, then confirm the web interface answers at all; RACADM remote uses the same HTTPS service.
ERROR: Login failed. The account is a local iDRAC user, not a domain user, unless directory services are configured — and if you want that, see how to automate the Active Directory authentication configuration on Dell iDRAC, which does it with the same remote RACADM calls used here.
The command hangs, then times out. Almost always a firewall silently dropping 443 rather than rejecting it. A dropped packet looks like a slow server.
A subcommand exists in the docs but not in your RACADM. Version mismatch, in either direction: an old RACADM against iDRAC9, or a new one against an iDRAC7. The first line of racadm with no arguments tells you which version you have.
With the tooling in place, iDRAC work stops being a browser task. Changing an address across a set of nodes, for example, becomes one loop rather than forty logins — as in changing the iDRAC IP address on Dell EMC ECS nodes.
One Comment