US How out-of-band management works
Out-of-band (OOB) management is remote control of a computer through a path that is independent of the computer’s own operating system and, often, of its main network connection. Normal remote access, such as SSH, remote desktop or a device management agent, runs inside the operating system. That is called in-band management, and it stops working the moment the operating system hangs, the network stack fails or the machine is powered off.
Out-of-band management adds a second, always-on path. It is usually a small dedicated controller on the board or in an add-on module, with its own processor, firmware and power from the standby rail. Because it does not rely on the main system, it can still report health, switch power and give console access when the computer itself is unresponsive. On servers the controller is called a baseboard management controller (BMC); on edge and industrial computers it may be a processor feature such as Intel AMT, or a plug-in module.
What OOB management lets you do
The exact functions depend on the controller, but most OOB tools cover the same core tasks.
-
//
Power control. Turn a computer on or off, or hard-reset a frozen system, from anywhere.
-
//
Health monitoring. Read temperatures, voltages, fan speeds and storage status, with alerts when a value goes out of range.
-
//
Remote console. See the boot screen and BIOS or UEFI setup, or a serial console, even before the operating system loads.
-
//
Recovery and reimaging. Mount a remote image, roll back an update or reinstall the operating system without touching the device.
-
//
Fleet management. Manage hundreds of distributed edge systems from one dashboard, with logs and change history.
Types of out-of-band management
Several technologies deliver OOB management. They differ in where the controller sits and what network it uses.
| Technology | Where it lives | Typical interface | Common use |
|---|---|---|---|
| BMC with IPMI or Redfish | Dedicated chip on server and some industrial boards | Dedicated management Ethernet port, web console | Rack servers, edge servers |
| Intel AMT (vPro) | Built into vPro processors and chipsets | Shared or dedicated Ethernet, remote KVM | Business and industrial x86 PCs |
| Add-on OOB module, such as Allxon | Plug-in card or module linked to the host board | Cloud portal over Ethernet or cellular | Jetson and x86 edge AI computers |
| Serial console server | Separate appliance wired to device consoles | RS-232 console, often with a cellular backup link | Network equipment, remote cabinets |
IPMI is the long-established BMC interface; Redfish, published by the DMTF, is its modern REST-based replacement. Our FAQ on Intel vPro covers the AMT route in more detail.
Why OOB matters at the edge
Data centres have staff on hand. Edge computers do not: they sit on vehicles, in roadside cabinets, on factory lines and in remote substations, often hours from the nearest engineer. When one locks up, a remote fix through an OOB channel takes minutes, while a site visit can take a day and may need access permits or a vehicle off the road.
For that reason we fit OOB management to edge fleets where downtime is costly. Our guide to Allxon out-of-band management explains how the module works with industrial PCs, and our smart factory case study shows it on AI inference systems. Many of our edge AI computers can take an OOB module or use built-in remote management.
Choosing OOB for an edge fleet
The right OOB approach depends on the hardware already chosen and how the sites connect.
-
//
Processor support. Intel AMT needs a vPro processor and chipset, and BMCs are mostly found on server-class boards. Add-on modules suit Jetson and Arm systems that have neither.
-
//
Connectivity. A site with only a cellular link needs an OOB path that works over it, ideally with its own SIM or a failover route.
-
//
Power design. The controller has to stay powered when the host is off, so the power supply, ignition control and any UPS must keep its standby rail alive.
-
//
Scale and access. A cloud portal with groups, alerts and audit logs suits large fleets; a local web console suits a handful of systems.
Securing out-of-band access
An OOB controller can switch power and reinstall the operating system, so it has to be protected as carefully as the system itself. Good practice is to keep management interfaces on a separate network or VPN, change default credentials, use encrypted protocols such as Redfish over HTTPS rather than legacy IPMI over LAN, keep controller firmware updated and log every management session. Cloud-based OOB services add multi-factor sign-in and role-based access, which helps when many people manage a large fleet.
Quick answers on out-of-band management
Out-of-band management: common questions
What is the difference between in-band and out-of-band management?
Dependence on the operating system. In-band tools run inside the operating system and fail when it does. Out-of-band tools use a separate controller and path, so they still work when the system is hung or off.
Is IPMI out-of-band management?
Yes. IPMI is a standard interface to a baseboard management controller, which works independently of the host operating system. Redfish is its newer, more secure successor.
Does OOB management need a separate network?
Not always, but it helps. Some controllers share the main Ethernet port. A dedicated port, separate management network or cellular link keeps access available when the main network is the problem.
Can out-of-band management fix a crashed computer?
Usually. A remote power cycle clears most hangs, and console access and remote reimaging can recover a corrupted operating system without a site visit.
What are iDRAC and iLO?
Vendor names for server BMCs. iDRAC is Dell’s controller and iLO is HPE’s. Both provide out-of-band management with IPMI and Redfish support.
We fit and configure out-of-band management on edge and industrial computers as part of the build, enrol each system in the management portal and test remote power and recovery before it ships.