Out-of-Band Management in an RMM: Native Intel AMT vs an Intel EMA Integration
Remote monitoring and management tools reach a machine's hardware controller in one of two ways. They integrate a separate Intel management console, most often Intel Endpoint Management Assistant (Intel EMA), or they drive the controller from the RMM's own agent and gateway. Both deliver out-of-band control: power, a serial console, and pre-boot access on a machine that is off or whose operating system is unresponsive. They differ in what has to be stood up, and in where provisioning happens.
ET Ducky uses the second approach, so this is not a neutral survey. The facts about each model are stated plainly, with sources, so the tradeoff is visible either way.
What out-of-band buys an RMM
An out-of-band channel reaches the management controller built into business-class hardware: Intel AMT on vPro machines, DASH on some AMD PRO systems, and IPMI on servers. Because the controller runs below the operating system, an operator can power-cycle a host, open a serial console into POST and the firmware menu, or run a KVM session when the OS is unresponsive or the machine is powered off. Intel describes the same capability set for AMT: a hardware-based out-of-band channel that works regardless of power state or the presence of a working OS.
Approach one: integrate Intel EMA
Intel EMA is Intel's management console for AMT. It performs out-of-band power control and remote desktop on endpoints inside or outside the firewall, using Intel Active Management Technology. Several RMMs add out-of-band control by connecting to it. Datto RMM added out-of-band endpoint management through an Intel integration built on EMA, and ConnectWise lists an Intel Endpoint Management Assistant integration on its marketplace.
In this model the RMM is the front end and EMA is the management stack behind it. EMA is deployed as a server, on-premises or in your own cloud, and endpoints are enrolled into it; the RMM then drives EMA. The strength is that EMA is a mature Intel product with the full AMT feature set, including Admin Control Mode through a provisioning certificate, which allows KVM without an on-screen consent prompt. The cost is the extra component: another server to deploy, enroll devices into, and maintain alongside the RMM.
Approach two: drive AMT from the RMM agent
The second approach uses the agent the RMM already runs on each host. In ET Ducky, a regular agent can take a gateway role for its network and relay out-of-band commands to the controllers on its LAN. A small dedicated device can play the same role where there is no always-on host. On a machine whose AMT is present but unconfigured, the agent provisions AMT locally through the Intel Management Engine Interface, with no provisioning certificate and no trip to firmware.
There is no Intel EMA and no separate provisioning server in this path. The relay is the RMM's own gateway, not a separate Intel console, and the provisioning runs on the host being configured rather than from a management server. The protocol details, from the device interface up to the configuration call, are in the native provisioning deep-dive.
Side by side
| Dimension | RMM with Intel EMA | RMM agent (ET Ducky) |
|---|---|---|
| Extra components | A separate Intel EMA server, plus device enrollment into it | The agent you already run, and a gateway on the LAN (an agent with the role, or a small device) |
| Where provisioning runs | From the EMA server to the device | On the device itself, from the agent |
| Control mode | Client or Admin (Admin needs a provisioning certificate) | Client Control Mode (host-based configuration) |
| Consent-free KVM | Yes, in Admin Control Mode | No; Client mode shows a consent code for KVM |
| Protocols | Intel AMT (vPro) | Intel AMT, DASH, IPMI |
| Relay path | Intel EMA server | RMM gateway (dedicated device or agent-hosted) |
Provisioning is the practical difference
Turning a controller on is where the two models diverge most. The EMA path provisions AMT from the EMA server and can reach Admin Control Mode with a provisioning certificate, which removes the KVM consent prompt. The agent path uses Intel host-based configuration, which produces Client Control Mode from the host itself with no certificate. Client mode covers power, serial-over-LAN, and KVM; its one constraint is that a KVM session prompts for a six-digit consent code shown on the target's screen. For remote power, serial console, and reimaging work that constraint is usually acceptable. Where consent-free KVM across the fleet is a firm requirement, Admin Control Mode, and therefore a certificate through EMA or a manual setup, is the path.
Which fits
Both are legitimate. An organization that already runs Intel EMA, or that needs Admin Control Mode across the fleet, has a working path through the EMA integrations. An organization that wants out-of-band control folded into the RMM it already runs, without standing up and maintaining a separate management server, is what the agent-driven model is for. ET Ducky also reaches DASH and IPMI hardware through the same gateway, where EMA is specific to Intel AMT.
Setup and eligibility are in the Out-of-Band Management documentation, and the provisioning internals are in the native provisioning deep-dive.