Out-of-Band Management in an RMM Using Native Intel AMT or 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. That means 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 comparison is written from that position. The facts about each model are stated with sources, so the tradeoff is visible either way.
What an out-of-band channel provides in an RMM
An out-of-band channel reaches the management controller built into business-class hardware. That controller is Intel AMT on vPro machines, DASH on some AMD PRO systems, and IPMI on servers. 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, integrating 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. 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. It also adds a component to run, another server to deploy, enroll devices into, and maintain alongside the RMM.
Approach two, driving 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 take 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. That path uses no provisioning certificate and no firmware setup visit.
There is no Intel EMA and no separate provisioning server in this path. The relay is the RMM's own gateway. 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 vPro provisioning post.
Comparison of the two approaches
| 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) |
Where provisioning happens in each model
Provisioning a controller is where the two models differ 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 is the path, which means a certificate through EMA or a manual setup.
Which model fits which organization
Both models work. An organization that already runs Intel EMA, or that needs Admin Control Mode across the fleet, has a working path through the EMA integrations. The agent-driven model covers organizations that want out-of-band control inside the RMM they already run, without a separate management server to stand up and maintain. ET Ducky also reaches DASH and IPMI hardware through the same gateway. 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 vPro provisioning post.