Out-of-Band Management

Overview

ET Ducky's Out-of-Band (OOB) management feature lets you monitor, power-cycle, and inventory hardware endpoints at the firmware level — independently of the Windows OS and the standard ET Ducky agent. OOB access works even when the machine is powered off, unresponsive, or has a crashed operating system.

OOB management is delivered through a Gateway — a lightweight Linux service (designed for Raspberry Pi) that sits on the same LAN as your managed hardware. The gateway scans the network for OOB-capable devices, maintains a cloud connection, and relays commands from the ET Ducky dashboard to the target hardware. A regular managed agent can also take on gateway duties for its network; see Agent-Hosted Gateway below.

Supported Protocols

Protocol	Hardware	Port	Notes
Intel AMT	Intel vPro business laptops and desktops	16992 (plain), 16993 (TLS)	ThinkPad, EliteBook, Latitude, OptiPlex with vPro badge
DASH	AMD PRO processors with Broadcom or Realtek enterprise NICs	623	HP EliteDesk AMD, Dell OptiPlex AMD, Lenovo ThinkCentre AMD
IPMI	Server baseboard management controllers	623	Identify/reachability probe only in current release

Note: Consumer hardware (gaming PCs, home desktops, consumer laptops) does not support AMT or DASH regardless of Intel/AMD CPU brand. OOB management requires business-class vPro or AMD PRO processors paired with enterprise-grade NICs.

Device Eligibility — is a machine OOB-manageable?

A device is eligible for out-of-band management when it has a supported hardware management controller that answers the gateway's discovery probe. Two things must be true:

The hardware supports it. Intel vPro (AMT), AMD PRO with an enterprise NIC (DASH), or a server baseboard management controller (IPMI). Consumer hardware does not qualify — see Supported Protocols above.
The controller is enabled and reachable. AMT/DASH must be turned on in firmware and sit on the same LAN as a gateway, so it can answer a WS-Man identify on ports 16992/16993 (AMT) or 623 (DASH). The gateway only reports a device as AMT/DASH when the identify response carries the expected Intel/AMT (or DASH) signature, which avoids false positives.

How to tell in the dashboard. Open Agents → Out-of-Band. That tab lists the installed agents eligible for out-of-band management. An agent qualifies when its host reports vPro/AMT-capable hardware, or when a gateway has discovered and linked an OOB controller to it. Each row carries a readiness status, so you can see whether OOB controls will work or what still needs configuring:

Readiness	What it means and what to do
Ready	Provisioned, linked to a controller, credentials set, and a gateway online. Power, cycle, and inventory actions are enabled on the row.
Needs setup: no controller linked	The agent reports OOB-capable hardware, but no AMT/DASH/IPMI controller has been discovered and linked to it yet. Scan from Systems → Network Discovery, then link the controller to this agent.
Needs setup: not provisioned	AMT/vPro is present but not provisioned. Provision it in one click from Systems → Network Discovery → OOB candidates (see Enabling dormant AMT); commands work once it reads Ready.
Needs setup: no credentials	Add AMT admin credentials from the toolbar on the tab.
Needs setup: no gateway online	OOB commands are relayed through a gateway. Bring a dedicated or agent-hosted gateway online on the network.

Eligible vs. operable. Appearing in the Out-of-Band tab means the hardware is eligible. To run power, console, or inventory commands, the row must read Ready: the controller provisioned and linked, credentials set, and a gateway online. Finding machines on the network (including which are not yet running the agent) is a separate, opt-in function under Systems → Network Discovery.

Enabling dormant AMT (vPro-capable but unconfigured)

Many business-class machines — Dell OptiPlex/Latitude, Lenovo ThinkCentre/ThinkPad, HP EliteDesk/ProBook with vPro SKUs — ship with Intel AMT present in the chipset but never configured. These need no added hardware to manage out-of-band: the capability is already in the silicon; it only has to be switched on.

Find them. Open Systems → Network Discovery → OOB candidates. That view lists your managed hosts whose hardware reports vPro/AMT-capable but whose AMT is not provisioned. It does not require a network scan — it reads what your installed agents already report. You can also build a report on the Agents entity and filter or group by OOB Posture = Dormant.

How enabling works. Because the ET Ducky agent already runs on the host, AMT is configured locally through the Intel Management Engine Interface (MEI) — natively, with no external tool, no BIOS trip, and no dongle. This uses Intel's host-based configuration, which puts AMT into Client Control Mode (CCM) and gives you remote power, serial-over-LAN, and KVM. One CCM behaviour to know up front: KVM/redirection sessions require a six-digit consent code shown on the target's screen, entered when the session starts. That is an Intel requirement for host-configured AMT, not an ET Ducky limitation.

Provision it (one click).

Open Systems → Network Discovery → OOB candidates. Each row is a managed host with dormant, vPro-capable AMT.
Find the machine you want and click Provision on its row.
The agent runs host-based activation locally and reports progress on the row (Provisioning… → Provisioned, or an error message if it fails). You enter no credentials — the agent generates a strong AMT admin password, stores it encrypted in ET Ducky, and never displays it.
On success the host leaves the candidates list and appears in Agents → Out-of-Band as Ready, manageable through your gateway like any other AMT device.

Requirements & caveats. The target must be a genuine vPro/AMT SKU with the Intel MEI driver present, and the ET Ducky agent must be running on it (activation happens on the host itself). Activation targets CCM, so the consent-code behaviour above applies to later KVM sessions. If the hardware isn't vPro or the MEI path is unavailable, the row reports that host-based provisioning is unsupported on that machine.

Consent-free control (Admin Control Mode). Removing the consent code requires Admin Control Mode, which AMT only allows via a provisioning certificate or a manual BIOS/MEBx setup. That is an advanced path; for most remote-remediation and reimaging work, CCM is sufficient.

Serial Console (Serial-over-LAN)

Once a device is provisioned and reads Ready, ET Ducky can open a text serial console to it over AMT Serial-over-LAN (SOL). It runs independently of the operating system, so it works before the OS boots and while Windows is down: watching POST, reaching the BIOS/UEFI menu, choosing a boot device, or running a text-mode recovery. The console is relayed through the gateway; no software is installed on the target.

Open a console

Open Agents → Out-of-Band and find a device that reads Ready. (A console needs a provisioned controller, stored credentials, and a gateway online — the same requirements as any OOB action.)
Click Console on the device's row. A terminal panel opens in the dashboard.
Work with the target as a text terminal — your keystrokes go to the machine and its serial output streams back. To reach the firmware menu, trigger a reboot from the power controls and press the vendor's setup key (often F2, Del, or F10) as it POSTs.
Close the panel to end the session.

What it can and can't do. SOL is a text console: it carries serial/BIOS text redirection, not a graphical desktop. For a graphical view of a running OS, use KVM/redirection (which, under CCM, prompts for the on-screen consent code). Serial redirection must be enabled in the target's firmware for full pre-boot output; most vPro machines enable it alongside AMT.

Security. The console stream is brokered through your authenticated gateway and the ET Ducky cloud. AMT credentials are used just-in-time by the gateway, and are never shown in the browser or placed in a page URL.

Gateway Hardware Requirements

Raspberry Pi 4 or newer (64-bit OS required)
Wired Ethernet connection to the target LAN (recommended over Wi-Fi)
Network access from the Pi to etducky.com on TCP 443
Same subnet as the OOB-capable devices you want to discover

Recommended OS: Raspberry Pi OS Lite 64-bit. The gateway service runs as a systemd unit under a dedicated etducky service account.

Provisioning a Gateway Token

Gateway tokens are separate from Windows agent registration tokens. They use the etd_gateway_ prefix and are tied to a dedicated Agent record with AgentType = gateway.

Navigate to Agents → Install New Agent and select your organization.
Click Create Token.
Select Gateway as the token type (defaults to Windows Agent).
Enter a name for the gateway (e.g. Site A – Pi Gateway).
Click Create Token — the etd_gateway_ token is shown once only. Copy it immediately.

Gateway tokens do not have max-agent limits, expiry dates, or installer downloads. Each token provisions exactly one Pi gateway.

Deploying the Gateway

1. Build and package

From the repo root on a Windows build machine (requires .NET SDK):

.\ETDucky.Gateway\packaging\publish-gateway.ps1 `
  -Runtime linux-arm64 -Configuration Release `
  -Output .\ETDucky.Gateway\artifacts\gateway-linux-arm64

tar -czf .\ETDucky.Gateway\artifacts\ETDucky.Gateway.tar.gz `
  -C .\ETDucky.Gateway\artifacts\gateway-linux-arm64 .

2. Copy files to the Pi

scp .\ETDucky.Gateway\artifacts\ETDucky.Gateway.tar.gz pi@raspberrypi.local:/home/pi/
scp .\ETDucky.Gateway\install\setup.sh pi@raspberrypi.local:/home/pi/
scp .\ETDucky.Gateway\install\update.sh pi@raspberrypi.local:/home/pi/
scp .\ETDucky.Gateway\install\etducky-gateway.service pi@raspberrypi.local:/home/pi/

3. Install on the Pi

sed -i 's/\r//' setup.sh update.sh
chmod +x setup.sh update.sh
./setup.sh
./update.sh /home/pi/ETDucky.Gateway.tar.gz

4. Configure

sudo nano /opt/etducky-gateway/appsettings.json

Set Gateway:AgentToken to the etd_gateway_ token you provisioned from the dashboard.

5. Start

sudo systemctl start etducky-gateway.service
journalctl -u etducky-gateway.service -f

A healthy startup shows: config validation passing, WebSocket connected, heartbeat active, and a discovery scan starting.

Agent-Hosted Gateway

If a site has no dedicated gateway device, any regular ET Ducky agent can also serve as the OOB gateway for its network. The OOB gateway for this network toggle lives in the agent's properties panel (open the agent from the Agents page). When enabled, that agent runs the same discovery and relay duties as a dedicated gateway: it scans its LAN for AMT and DASH hardware and relays out-of-band commands from the dashboard, alongside its normal monitoring work.

Enabling it

Sign in as an org admin. Only org admins can change gateway designation.
Open the agent's properties panel from the Agents page.
In the Out-of-Band Gateway section, check OOB gateway for this network.
The agent picks up the change and starts gateway duties within a heartbeat. It then runs the same discovery and OOB relay as a Pi gateway; eligible agents on its network show up in the Out-of-Band tab.

Unchecking the toggle stops gateway duties on the next heartbeat. No install, token, or Pi is required; the agent you already deployed does the work.

Trade-offs

The whole point of out-of-band management is reaching machines that are off or broken, and an agent-hosted gateway is only as available as the host it runs on. A dedicated gateway device keeps working when your managed machines are down; an agent-hosted gateway goes down with its host, which may be exactly the moment you need OOB access. Agent-hosted gateways are a good fit for offices with an always-on server and no spare hardware. For true out-of-band independence, a dedicated Raspberry Pi gateway remains the recommended setup.

Note: OOB gateways (dedicated or agent-hosted) require a paid subscription. If the toggle reports a subscription error, upgrade the organization's plan first.

Discovery

On startup, and on demand, the gateway scans the local network: it auto-detects the subnet, pings host addresses, and probes live hosts for AMT (ports 16992/16993) and DASH (port 623). A discovered controller is matched to the agent installed on that host; the agent then appears in Agents → Out-of-Band with its controller linked and its power state populated.

Setting	Default	Description
`ScanSubnets`	`["auto"]`	Auto-detect subnet from the Pi's network interface. Use `["192.168.1.0/24"]` to specify explicitly.
`ScanIntervalMinutes`	`15`	How often to run a full rediscovery sweep.
`DiscoveryEnrichWithAmtCredentials`	`true`	When default AMT credentials are set, attempt a second-pass inventory to retrieve hostname, CPU, RAM, and serial number.
`AmtDefaultUsername`	empty	Default AMT credential username for enrichment.
`AmtDefaultPassword`	empty	Default AMT credential password. Never commit to source control.

Related: Network Discovery (finding unmanaged machines)

The same gateway can also inventory all the OS machines on its LAN — not just OOB hardware — and flag which ones are not yet running the ET Ducky agent. That is a separate, opt-in feature aimed at agent coverage rather than firmware management. See Network Discovery.

Quick contrast:

OOB discovery (this page) finds AMT/DASH/IPMI management controllers for firmware-level power and console; eligible agents appear in Agents → Out-of-Band.
Network discovery finds operating-system hosts to spot agent coverage gaps — results in Systems → Network Discovery.

Both run from the same gateway (dedicated or agent-hosted), so standing up one gateway unlocks both.

Updating the Gateway

After building and packaging a new version, copy the tarball to the Pi and run:

./update.sh /path/to/ETDucky.Gateway.tar.gz

The update script stops the service, extracts the package, sets the executable bit, fixes ownership, and restarts the service automatically.

Troubleshooting

Symptom	Likely Cause	Fix
Service fails with Permission denied	Executable bit not set on binary	`sudo chmod +x /opt/etducky-gateway/ETDucky.Gateway`
WebSocket returns 401	Token prefix mismatch or agent row missing	Ensure token starts with `etd_gateway_` and was provisioned via the Gateway token type
Discovery finds 0 devices	No AMT/DASH hardware on subnet, or OOB not enabled in BIOS	Verify vPro/AMD PRO hardware is present and AMT/DASH is enabled in BIOS/MEBx
Gateway shows as Desktop Agent	Old frontend JS cached	Hard refresh (`Ctrl+Shift+R`). Gateway status appears in the Out-of-Band tab.