Agent Deployment

Overview

There are two ways to bring an unmanaged machine under management, and ET Ducky recommends the first:

Enrollment link (recommended). Generate a one-time link and run it on the target. The host pulls the signed installer over HTTPS and enrolls itself — no gateway, no open inbound ports, no credentials on the wire, and nothing added to the target's attack surface. This is the safest and lowest-friction way to onboard a host.
Agent Deployment (push). A gateway on the target's LAN connects to it over WinRM (Windows) or SSH (Linux) with admin credentials you supply, and drives the install. Use this when you can't run anything on the target yourself — but it requires an open management service on the target, plus a WinRM configuration step covered below.

Both are launched from Systems → Network Discovery — the Enroll button for a link, or Deploy agent for a push. Both are admin-triggered and never automatic.

Enrollment link (recommended)

An enrollment link is a one-time, single-use, short-lived command you hand to a host. The host runs it once; it downloads the signed ET Ducky installer over HTTPS and installs the agent, which then talks outbound-only to the cloud. Because nothing connects into the target, there is no WinRM/SSH to enable, no port to open, and no standing service to attack — which is why it's the recommended default.

Step by step

Open Systems → Network Discovery and pick the client in the organization dropdown. (You don't strictly need a discovered row — a link works for any host — but the Enroll button on an unmanaged row is the quickest way in.)
Click Enroll on the target's row.
Choose the operating system and how long the link stays valid (default 1 hour), then click Generate enrollment link.
Copy the one-liner and run it on the target:
- Windows — in an elevated PowerShell: irm '<link>' | iex
- Linux — as a user with sudo: curl -sSL '<link>' | sudo bash
Deliver it however you already reach the box — RDP/SSH, the console, an existing RMM, or a login script.
The host downloads the installer, installs the agent, and enrolls. It shows up under Agents within a minute or two.

Requirements: the target only needs outbound HTTPS to reach ET Ducky's download endpoint (or your distribution hub on data-residency/offline networks). No inbound access, no gateway, and no target credentials are required.

Treat the link like a password. Anyone who runs it enrolls a device into your organization. It is single-use and expires; generate a fresh one per host and prefer a short expiry.

Agent Deployment (push over a gateway)

When you can't run anything on the target yourself, a gateway can push the agent to it. This is the fallback path — better for bulk, unattended rollout, but it requires an open management service on the target and (on Windows) the WinRM configuration in Prerequisites below. It is remote code execution against a LAN host with the credentials you provide — validate against a throwaway lab machine first, and read the security notes.

How it works

You click Deploy agent on an unmanaged host and enter the target's admin username and password (plus domain, for Windows, or sudo, for Linux).
The cloud stores those credentials in a one-time, encrypted relay (valid 15 minutes) and queues a deploy command. The owning gateway claims it on its next poll — so a momentarily-disconnected gateway just picks it up when it reconnects, rather than the request being lost. The password never travels in the command itself and is never written to logs.
The gateway consumes the relay, picks a transport — WinRM for Windows, SSH for Linux — and validates the credentials against the target first. Bad credentials or an unreachable target fail here in seconds with a clear message, before anything is installed.
On success it downloads the signed installer to the target, runs it silently with a registration token, and waits for the installer's exit code.
The gateway posts the result back. The host's deploy state becomes Deployed, then Managed once the freshly-installed agent enrolls.

The credentials are held only for the single install and wiped immediately afterward. They are never stored after the deploy completes.

Prerequisites (push)

A deploy has three sides — the gateway, the target, and your account. All three must be in order or the deploy fails with a message telling you which one to fix.

Gateway

An OOB gateway that is on the same LAN segment as the target — a dedicated device, or a regular agent with the OOB gateway role enabled. It must be online.
Do not run the gateway on the target's own hypervisor host. A gateway on a VM's host often cannot reach that VM in bridged mode (the traffic has to hairpin back on the same physical port, which many NICs — and almost all Wi-Fi adapters — won't do). Put the gateway on a separate box or VM on the same subnet.
The gateway must be running a current build that polls for deploy commands. A gateway on an older build simply won't claim the command — it stays queued until the gateway updates or comes back online (it isn't lost). See Troubleshooting.

Target — Windows

WinRM must be enabled on the target. Stock Windows has it off; turn it on with Enable-PSRemoting -Force in an elevated PowerShell (mind the network-profile note below).
No encryption setup needed on the target. The gateway always speaks WS-Man over an encrypted channel. On plain 5985 it seals each message with the negotiated Windows security context — the same NTLM/SPNEGO message encryption the built-in Windows remoting tools use — so a default WinRM service works as-is: no AllowUnencrypted, no certificate, and no HTTPS listener to stand up. If the target already exposes an HTTPS listener on 5986, the gateway prefers it and TLS carries the encryption. Either way the WinRM traffic is encrypted on the wire. (Prefer to touch nothing on the target at all? An enrollment link needs no inbound WinRM whatsoever.)
Watch the network profile. On a network set to Public, Enable-PSRemoting -Force starts the WinRM service but refuses to open the firewall rule (“WinRM firewall exception will not work … set to Public”), so 5985 stays blocked and the deploy can't reach it. Either run Enable-PSRemoting -SkipNetworkProfileCheck -Force (opens 5985 scoped to the local subnet, even on Public), or set the adapter to Private first: Set-NetConnectionProfile -InterfaceAlias <name> -NetworkCategory Private, then re-run Enable-PSRemoting -Force.
The credentials you supply must be a local administrator on the target.
Local-account username format. For a local (non-domain) account, put the account name in Username and the target's computer name in the Domain field (e.g. Username Admin, Domain WIN-HOST01 — equivalent to WIN-HOST01\Admin). Do not use the .\Admin form: the leading . means “this local machine” and does not resolve when the gateway authenticates remotely.

Target — Linux

SSH must be reachable (port 22) with the credentials you supply.
If the account isn't root, tick Use sudo so the install script runs with elevation using the same password.

Account

A paid subscription with out-of-band management enabled, and the Operator role (or higher) in the organization.
A registration token for the target OS. You do not have to create one first: if you don't select a token and none exists for that OS, the deploy auto-mints a short-lived, single-use token (one agent, expires in about an hour) and uses it. To pin a specific long-lived token instead, create one under Agents → Tokens and select it in the deploy dialog.

Deploy to a single host

Open Systems → Network Discovery and pick the client in the organization dropdown.
On the Devices view, filter to Unmanaged only and find the target (use the search box to filter by IP, hostname, or MAC). Each row shows which gateway owns it (“via <gateway>”) — that's the gateway the deploy routes through by default.
Click Deploy agent on that row.
Confirm the operating system and the Deploy via gateway choice (it defaults to the endpoint's owning gateway; pick a different OOB gateway if one is better placed to reach the target), then enter the target's username and password, and (Windows) an optional domain — for a local account put the target's computer name here (HOST\Admin) — or (Linux) the sudo option.
(Windows, optional) Tick Auto-disable WinRM on the target after this push if you enabled WinRM only for this deploy. On a successful push the gateway registers a self-deleting scheduled task on the target that disables WinRM and removes its firewall rule about 30 minutes later. It runs as a delayed SYSTEM task, so it fires even if the deploy fails or the gateway never reconnects, and the window is long enough that it never interrupts the install. Enabling WinRM in the first place remains a manual step on the target (a push needs WinRM already running).
Click Deploy agent. The row shows Deploying… while the gateway works, then Deployed — enrolling, and finally flips to Managed after the agent checks in.

Deploy to many hosts at once

To roll out to several machines with the same credentials, tick the checkbox on each unmanaged row and click Deploy selected (N). Enter one credential set; it is applied once per host, sequentially (so the gateway isn't hammered), and each host shows its own live status. A host that needs the installer seeded to a hub first (see below) is skipped with a note — use the single-host Deploy agent flow to seed, then re-run the bulk push.

Where the installer comes from

The gateway needs the installer bytes to run on the target. There are two sources, chosen automatically:

Cloud download (default). The target fetches the current signed installer over TLS from ET Ducky's download endpoint. This is the normal path when data-residency isn't restricted.
Distribution hub (data residency). If your organization keeps artifacts on-premises, the installer is served from your own distribution hub instead, using a short-lived read grant — the bytes never leave your network.

The “seed to hub” prompt. When residency requires the hub but the current installer version isn't there yet, the deploy dialog stops and offers Seed latest agent to hub. Click it, wait for seeding to finish, and the deploy retries automatically. On residency-strict organizations with no reachable hub, the deploy is blocked with a message to configure one. See Distribution Servers.

Deployment state & monitoring

Each unmanaged row shows its current deploy state in the Status column:

Badge	Meaning
Deploying…	The gateway is installing the agent on the target right now.
Deployed — enrolling	The installer ran successfully; waiting for the new agent to check in. The row flips to Managed once it does.
Deploy failed — retry	The gateway reported a failure (the button changes to Retry deploy). Open the dialog again for the error message.

A deploy is not a patch job, so it does not appear under Patch Management — its state lives on the Network Discovery row.

Canceling or retrying a stuck deploy

If a deploy can't finish — the gateway went offline mid-install, or is on an older build that ignored the command — the row can sit at Deploying… A Cancel button appears next to it: click it to clear the state and expire the in-flight command so you can start over immediately.

Even without canceling, a deploy that has been in flight longer than 15 minutes is treated as abandoned, so clicking Deploy agent again will start a fresh attempt. A failed row simply shows Retry deploy.

Troubleshooting

Symptom	Likely cause	Fix
Row sits at Deploying… and nothing happens	The owning gateway is offline, or on an older build that doesn't poll for deploys yet — the command is queued, waiting to be claimed	Bring the gateway online / update it (it claims the queued command on its next poll), or Cancel and re-deploy through a different gateway
“A deployment is already in progress” when you retry	A previous attempt is still marked in-flight	Click Cancel on the row (or wait out the 15-minute staleness window), then deploy again
Fails with “Confirm WinRM (5985) is enabled … local admin”	WinRM is off on the target, or the account isn't a local admin	Run `Enable-PSRemoting -Force` on the target and use a local-admin account
WinRM service is on but 5985 is still refused / unreachable	`Enable-PSRemoting` couldn't open the firewall because the network profile is Public	Run `Enable-PSRemoting -SkipNetworkProfileCheck -Force`, or set the adapter to Private and re-run
Fails with “WinRM is set to reject encrypted messages” (HTTP 415)	The target has `AllowUnencrypted = true` — a non-default lab setting that makes WinRM refuse the encrypted push it would otherwise accept	Restore the default with `Set-Item WSMan:\localhost\Service\AllowUnencrypted $false` on the target, or deploy over HTTPS/5986. A stock host (`AllowUnencrypted = false`) needs none of this.
Fails with “Authentication failed” using a local account	The username wasn't scoped to the target's local machine (e.g. `.\Admin` was used)	Use Username `Admin` with the target's computer name in the Domain field (`HOST\Admin`), not `.\Admin`
Fails with “No reachable transport …”	The target exposes no usable management port (WinRM/SSH), or the gateway can't reach it	Enable WinRM (Windows) or SSH (Linux); confirm the gateway is on the target's segment
Target never appears in discovery, or the gateway can't reach it	The gateway is on the target VM's own host (bridged hairpin), or a host firewall blocks the probe	Move the gateway to a separate box/VM on the same subnet; allow the target's firewall
Deploy stops with a seed prompt	Data residency requires the installer on your hub, but it isn't seeded yet	Click Seed latest agent to hub, wait for it to finish, and the deploy retries

Security notes

Prefer enrollment links. Push (WinRM/SSH) is a remote-execution channel into the host — the same shape attackers use for lateral movement — and it requires an open management service on the target. An enrollment link avoids all of that: the host installs an outbound-only agent, with nothing listening for inbound connections. Use push only when you can't run a one-liner on the target.
The WinRM channel is always encrypted. On plain 5985 the push uses NTLM/SPNEGO message encryption (never cleartext); on 5986 it uses TLS. You do not need to enable AllowUnencrypted — and you shouldn't, since that setting makes WinRM refuse the encrypted channel. The operator-supplied target password is additionally protected by the one-time encrypted relay, independent of the transport.
Credentials are one-time and encrypted. The target password is stored only in a short-lived encrypted relay, delivered to the gateway once (over TLS, when it runs the install), held for the single install, and wiped afterward. It is never stored in the deploy command, never persisted after the deploy, and never logged.
This is remote code execution. A successful deploy runs an installer as an administrator on the target. Treat the credentials accordingly and prefer scoped, purpose-made accounts.
Validate in a lab first. Confirm the WinRM/SSH path and your credentials against a throwaway host before deploying to machines you care about.
Audit trail. Every deploy is recorded (with the password redacted) so you can see who pushed what, where, and when.

Network Discovery — find the unmanaged hosts you deploy to, and the filtering/sorting that makes targets easy to spot.
Out-of-Band Management — the OOB gateway the deploy runs through, and how to enable an agent-hosted gateway.
Distribution Servers — on-premises installer hosting for data-residency deployments.
Agent Management — managing agents once they enroll.