The server is down and you are not at the site. The OS will not boot, or the network stack is dead, or someone needs to get into the BIOS. Without out-of-band management your options are a drive to the site or a phone call to someone who does not know what they are looking at.
Every serious server has a management controller: iDRAC on Dell, XClarity Controller on Lenovo, a BMC with IPMI on Supermicro and most others. It runs on its own, powered whenever the server is plugged in, with its own network port. Set it up on day one and you can power-cycle, mount an ISO, watch the boot screen and reach the console from anywhere you have a VPN.
Put management on its own network
The management controller should never share the production VLAN. It has a web interface, an SSH or Redfish API and, on older firmware, a history of vulnerabilities. Give it a dedicated management VLAN, or a physically separate switch, reachable only through the VPN or a jump host. Use the dedicated management port, not the shared LOM mode that piggybacks on a production NIC, because the shared mode goes down when the NIC or the switch port has a problem, which is exactly when you need it.
Address the controllers from a fixed range and record them on the layout sheet beside each server. Give each one a DNS name that matches the server, such as fs01-idrac, and set the same name inside the controller so it appears in its own alerts. Set a strong unique password, or better, join the controllers to Active Directory or LDAP so access is tied to real accounts.
- Dedicated management VLAN or switch, reachable only via VPN or jump host.
- Dedicated management port, not shared LOM.
- Static IPs from a documented range, DNS names matching the hostnames.
- Unique passwords or directory authentication, and a second local emergency account.
iDRAC setup on a Dell PowerEdge
The quickest way to configure iDRAC on a new server is at the console during the first boot. Press F2 for System Setup, choose iDRAC Settings, then Network. Enable the dedicated NIC, set the IP, mask and gateway, and enter DNS names. Under User Configuration set the root password. Save, and the controller is reachable at https on that address.
Once it is on the network, use `racadm` from a workstation to script the rest. Licensing matters: the base iDRAC gives power control and basic monitoring, and the Enterprise licence adds the virtual console and virtual media, which are the features that save the site visit. Check which licence shipped with the server and budget for Enterprise on anything you cannot reach on foot.
- F2 at POST, iDRAC Settings > Network. Set NIC Selection to Dedicated, then IPv4 settings.
- iDRAC Settings > User Configuration. Set the root password and create a named admin account.
- From a workstation: `racadm -r <ip> -u root -p <password> getniccfg` to confirm the network settings.
- Set the hostname and DNS registration: `racadm set iDRAC.NIC.DNSRacName fs01-idrac`.
- Configure alerts: `racadm set iDRAC.EmailAlert.1.Address alerts@yourdomain.com` and enable the SNMP or email alert destinations.
- Open the virtual console once and mount an ISO through virtual media to prove the whole path works before you need it.
racadm -r 10.0.0.50 -u root -p <password> getniccfg
racadm -r 10.0.0.50 -u root -p <password> serveraction powerstatus
racadm -r 10.0.0.50 -u root -p <password> serveraction powercycle
racadm -r 10.0.0.50 -u root -p <password> getselXClarity and IPMI on Lenovo, Supermicro and the rest
Lenovo's XClarity Controller works much the same way. Configure it from F1 System Setup under BMC Settings, or from the front USB port with a phone app on newer models. It has a web interface, Redfish, and a remote console. Lenovo's OneCLI tool scripts it from the command line, and the XClarity Administrator product manages a fleet if you have many.
Supermicro and most white-box servers use a BMC that speaks IPMI. `ipmitool` from any Linux host reaches it over the network with the lanplus interface, and the web interface gives you the remote console. IPMI over the network is weakly encrypted, which is one more reason the management VLAN must be isolated.
# Power status and a power cycle via IPMI
ipmitool -I lanplus -H 10.0.0.51 -U ADMIN -P <password> power status
ipmitool -I lanplus -H 10.0.0.51 -U ADMIN -P <password> power cycle
# Read the system event log and sensors
ipmitool -I lanplus -H 10.0.0.51 -U ADMIN -P <password> sel list
ipmitool -I lanplus -H 10.0.0.51 -U ADMIN -P <password> sensor
# Serial-over-LAN console
ipmitool -I lanplus -H 10.0.0.51 -U ADMIN -P <password> sol activateA KVM you can actually reach
Management controllers fail too. Firmware locks up, a licence expires, or the controller shares a fault with the server it is meant to save. A KVM-over-IP switch connected to the servers' video and USB ports is the layer under that. It needs its own address on the management VLAN, and it needs to be tested from outside the site, through the VPN, before you rely on it.
Put the KVM, the management switch, the firewall that terminates the VPN and the router on the UPS, on a circuit that stays up when the servers are shut down. Out-of-band access that goes down with the power is not out of band. For remote sites, a small cellular router on the management VLAN gives you a path that does not depend on the site's internet at all. Test the whole chain quarterly: VPN in, reach the KVM, reach an iDRAC, open a console.
- KVM-over-IP on the management VLAN, tested from outside the site.
- KVM, management switch, firewall and router on the UPS.
- Quarterly test: VPN in, reach KVM, reach a management controller, open a console.
Frequently asked questions
Is iDRAC Enterprise worth it?
For any server you cannot walk to, yes. The virtual console and virtual media are the features that let you reinstall an OS or fix a boot problem without a site visit.
Can the management port share the production switch?
It can share the switch on a separate VLAN with an access list, but a dedicated small switch is cleaner and does not go down with a production switch failure.
Takeaway
Set up the management controller before the server goes into service: dedicated port, isolated VLAN, static IP, DNS name, strong credentials and tested virtual console. Back it with a KVM-over-IP on the UPS and a path into the site that does not depend on the servers. Then test it from outside every quarter, because the day you need it is not the day to discover the firmware is stuck.