Distribution Servers

Overview

Distribution Servers turn an ET Ducky agent into a LAN-local file hub. Instead of every machine pulling installers, packages, or shared files down from the cloud over the WAN, you nominate one agent on a site to host them and serve them to its neighbors over HTTPS on the local network. Large transfers stay on the LAN, where they are fast and don't consume internet bandwidth.

The cloud remains the control plane: it stores the file catalog and access rules, decides who may read or write what, and issues short-lived signed tokens. The file bytes never flow through the ET Ducky cloud on the normal path — they move directly between the requesting machine and the hub agent on your LAN.

How storage works

There are two halves to a Distribution Server: the hub agent's local cache (where the bytes live) and the cloud catalog (where the metadata and access rules live).

Hub cache. When a file is published to a hub, the agent stores it in a content-addressable cache on its own disk — deduplicated by SHA-256, so two files with identical content occupy space once. Each blob has a stable id and a relative path (for example /installers/agent-setup.exe).
Cloud catalog. The cloud keeps a lightweight record per blob — its relative path, size, SHA-256, and tags — plus the connection and access-control rules. It never holds the file contents.
Cache quota. Each hub has a quota you set when you enable it. It can either scale with free disk (use a percentage of whatever space is free) or be a fixed size. When the cache fills, least-recently-used blobs are evicted; they re-populate on demand the next time they're requested.

Because the catalog and the bytes are separate, a file can exist in the catalog before it has been cached on a given hub, and the hub reconciles what it actually holds against the catalog as it heartbeats to the cloud.

Publishing files to a hub

Beyond the drive-mapped WebDAV writes documented below (map a drive, then drag files in), there are two hub-native ways to get installer artifacts onto a hub — useful when you're staging content for Patch Management rather than sharing general files.

Catalog seed. A Software Catalog entry's Seed to hub action publishes that app's installer to your org's distribution hub programmatically — the hub fetches the installer from the entry's download URL (or, for a Windows app, from its winget Id) and caches it as a hub blob, so install-from-hub works with no manual copy step.
Browser-direct upload. For staging bundle files (below), the dashboard can upload straight from your browser to the hub over a signed write grant: it asks the control plane to mint a short-lived, ACL-checked grant (initiate-direct) and then PUTs the bytes directly to the hub — the bytes don't traverse the ET Ducky cloud.

These sit alongside the WebDAV path, which remains the general-purpose way to read and write hub files from a mapped drive.

Hub folder bundles (multi-file installers)

Some installers aren't a single file — they're a payload of several files (an .msi plus transforms, a setup .exe with a data folder, a script with its resources). A hub folder bundle lets you stage that whole payload on a hub and deploy it as one catalog entry.

Drop the payload into a hub /bundles/ folder. Copy the multi-file installer into a subfolder under /bundles/ on the hub — via a mapped WebDAV drive, or the browser-direct upload above.
ET Ducky discovers and indexes the files. The hub reports the files it holds under /bundles/ to the cloud, which indexes each one (path, size, SHA-256) so they become listable and deployable. (Discovery is confined to /bundles/.)
Pick an entry-point file. On the catalog entry, browse the discovered files in the bundle folder and choose the file ET Ducky should run to perform the install (the setup executable, MSI, or script).
Deploy it. Deploy to agents using the vendor_folder (Hub folder bundle) method — each agent pulls the whole folder from the hub over the LAN and runs your chosen entry point.

See Patch Management for the deploy step (selecting the method, approval, and per-agent results).

Before you begin

You are an organization admin (enabling a hub and editing access rules requires admin rights).
The agent you want to use as a hub is online and reachable by other machines on its LAN.
The hub's listen port is open to the LAN through the host firewall, and — if the hub runs in a VM — the VM uses bridged networking. See Make the hub reachable on the LAN below.

Step 1 — Enable an agent as a hub

Open Agents, click the agent you want to host files, and open its Properties. The properties panel includes a Distribution Hub section.

Tick Enabled. The configuration fields appear.
Listen port — the TCP port the hub serves on (default 8443).
Listen interface — LAN only (recommended) binds to the local network interface; All interfaces exposes it more broadly (only if you understand the exposure).
Cache quota policy — Scale with disk (set a % of free disk to use) or Fixed size (set a byte cap).
Click Apply.

The setting is saved in the cloud and delivered to the agent on its next heartbeat, so the listener starts (or stops) within a few seconds — no restart or re-install required. Once the agent reports its listener is ready, it appears in the hub picker when you create a connection.

Make the hub reachable on the LAN

The hub serves files directly to clients over the network. Unlike remote control or live sessions — which run over the agent's outbound connection to the ET Ducky cloud — a client connects inbound to the hub's IP:port, and the bytes travel directly client↔hub, never through the cloud. So the hub machine itself must accept inbound connections on its listen port. (This is also why an agent you can already remote-control may still be unreachable as a hub: those are different network paths.)

Open the host firewall on the listen port. On a Windows hub, add an inbound allow rule and scope it to all profiles — a freshly-networked machine is often classified Public, which blocks unsolicited inbound by default, so a rule limited to the Private/Domain profile won't apply:
```
New-NetFirewallRule -DisplayName "ETDucky Hub" -Direction Inbound -Protocol TCP -LocalPort <port> -Action Allow -Profile Any
```
On a Linux hub: sudo ufw allow <port>/tcp (or firewalld: sudo firewall-cmd --permanent --add-port=<port>/tcp && sudo firewall-cmd --reload).
If the hub runs in a VM, use bridged networking. A NAT'd VM's IP isn't reachable from other devices, so clients can't mount it. Set the VM's network adapter to Bridged (VMware/VirtualBox) or attach it to an External virtual switch (Hyper-V) so it gets a real address on your LAN, then re-confirm the hub config so the agent advertises the reachable IP.
Verify before mounting. From a client, run Test-NetConnection <hub-ip> -Port <port> (PowerShell). TcpTestSucceeded : True means the path is open; a timeout means a firewall is dropping it (or the VM isn't bridged), while "actively refused" means the listener isn't running yet.

Step 2 — Create a connection

A connection is the addressable share that clients talk to. It binds one hub agent and carries the access rules.

Go to Integrations → Distribution Servers.
Click Add Connection.
Pick the hub agent you enabled in Step 1 and give the connection a name.
Save. A sensible default access rule is seeded for you, which you refine in Step 3.

Each connection row exposes actions to edit its access rules, create a personal mount key (and manage/revoke existing ones), view its reach state, and delete it.

Step 3 — Grant privileges (access control)

Access is governed by a list of rules on each connection. A rule grants a set of permissions to a principal on a path prefix.

Field	Meaning
Path prefix	The folder the rule applies to, e.g. `/` for the whole share or `/installers` for one folder. Rules apply to that prefix and everything beneath it.
Principal type	Everyone in org (all members), Role (an organization role such as `org:admin`), or User (one specific user).
Principal ID	Required for Role and User — the role name or user id the rule targets. Not needed for "Everyone in org".
Permissions	Any combination of `list`, `read`, `write`, `delete` (comma-separated). Defaults to `list,read`.

The four permissions:

list — see the names of files in a folder (browse / PROPFIND).
read — download file contents.
write — publish or overwrite files.
delete — remove files.

Most-specific rule wins. When more than one rule could apply to a path, the one with the longest matching prefix is used. This lets you grant broad read access at / and a narrower write grant deeper in the tree.

Worked example. A common setup is: Everyone in org gets list,read on / (so anyone can browse and download the share), and the org:admin role gets write,delete on /installers (so only admins can publish installers). Note these are independent grants — with exactly those two rules an admin can write to /installers but, because the most-specific rule there is write/delete only, would need a read or list grant added on /installers to browse it back. When in doubt, grant a single test principal list,read,write,delete on one path to confirm a round trip, then tighten.

Step 4 — Map a drive

Clients reach a connection over WebDAV at https://<hub-lan-ip>:<port>/dav/<label>/. Authentication uses HTTP Basic, where the username is a mount key id and the password is the mount key's secret — a short, long-lived, revocable credential scoped to your permissions. Because it's stable and compact, a mapped drive keeps working across reboots, and you can cut off access at any time by revoking the key.

The <label> is derived from the connection's name, and it's what the mapped drive is named on the client (e.g. a connection named FS-ETDUCKY mounts as a drive called FS-ETDUCKY). The mount details shown when you create a key include the exact URL. In the examples below, replace <hub-ip> with your hub agent's LAN address and <port> with the hub's configured listen port (the exact URL, with the right port, is shown in the mount-key details when you create a key).

Create a mount key

In Integrations → Distribution Servers, click New mount key on the connection's row (optionally give it a label, such as your device name). You'll get a username and a one-time secret, along with the hub's address. The secret is shown only once — use the Copy button and save it where your OS stores the mapped-drive credential. To review or revoke existing keys later, use Manage keys.

Trust the hub certificate (one-time)

The hub serves a self-signed certificate. WebDAV clients won't mount until that certificate is trusted by the operating system — this is a one-time step per device. On machines running the ET Ducky agent this is handled for you automatically; on other devices, download the certificate from the connection and install it:

Windows: install into Local Machine → Trusted Root Certification Authorities (requires admin once). Either double-click the .crt → Install Certificate → Local Machine → place in Trusted Root Certification Authorities, or in an elevated PowerShell: Import-Certificate -FilePath hub.crt -CertStoreLocation Cert:\LocalMachine\Root. Trusting it only in your user store will not work — the Windows WebDAV redirector validates against the machine store.
macOS: open the certificate in Keychain Access, add it to the System keychain, and set it to Always Trust.
Linux (davfs2): copy it to /usr/local/share/ca-certificates/ and run sudo update-ca-certificates (or set trust_server_cert in the davfs2 config).

Windows

Windows maps WebDAV through the WebClient service. If it is stopped, the map fails with System error 67 (the network name cannot be found). From an elevated prompt, start it and set it to start automatically (one-time):

sc config WebClient start= auto
net start WebClient

Then map from a normal (non-elevated) prompt so the drive appears in File Explorer — a drive mapped from an elevated prompt is hidden from the regular Explorer view by Windows (UAC). Username = the mount key id, password = the secret:

net use Z: https://<hub-ip>:<port>/dav/<label> /user:<mount-key-id> <mount-key-secret> /persistent:yes

Or via Explorer: This PC → Map network drive, enter https://<hub-ip>:<port>/dav/<label>/, tick Reconnect at sign-in, and supply the mount key id and secret when prompted.

macOS

In Finder, choose Go → Connect to Server (⌘K), enter https://<hub-ip>:<port>/dav/<label>/, then provide the mount key id and secret. The share mounts in the sidebar.

Linux

First install the WebDAV mount helper davfs2 (sudo apt-get install -y davfs2 on Debian/Ubuntu, sudo dnf install -y davfs2 on RHEL/Fedora, or sudo zypper install -y davfs2 on SUSE), then mount:

sudo mount -t davfs https://<hub-ip>:<port>/dav/<label>/ /mnt/etducky
# enter the mount key id (username) and secret (password) when prompted

Or, on a GNOME desktop, open davs://<hub-ip>:<port>/dav/<label>/ in Files (Nautilus).

A mounted drive is read-write: you can browse, open, create, edit, rename, and delete files and folders directly in it, subject to your permissions. Each operation is checked against your ACLs — you need list/read to browse and open, write to create/edit/rename, and delete to remove. An action on a path you lack the permission for fails cleanly (e.g. "access denied") rather than silently.

Data residency (require a distribution hub)

The Team → Workspace setting Maintain Data Residency By Requiring a Distribution Hub turns the hub from an optimization into a requirement. When it's on, file transfers, hub-backed scripts, and app installers must come from a reachable distribution hub on your network — ET Ducky never falls back to the cloud or a direct internet download, and enforcement is fail-closed on both the cloud and the agent.

For patch deploys this means hub-resident sources (hub folder bundles, seeded vendor binaries, hub-backed install scripts) are served from the hub, while winget, package-manager, and Windows Update installs — which pull from public/vendor sources — are blocked. To make such an app comply, seed its installer to the hub (from a download URL or a winget Id) or package it as a hub folder bundle. See Patch Management → Data residency for the full breakdown.

For step-by-step instructions on enabling strict mode (Team → Workspace) and making an app comply, see Patch Management → Data residency.

Step 5 — Reach a hub from outside the LAN (optional)

By default a hub is reachable only on its own local network. To let a device off the LAN (a laptop working remotely, another site) map the same share, enable WAN reach on the hub. The bytes still travel directly between the client and the hub — they never pass through the ET Ducky cloud.

Enable WAN reach

On the connection's row, open Reach state.
Tick Enable WAN reach and Save. The setting is delivered to the hub on its next heartbeat (about 30–40 seconds), after which the hub probes its network and re-registers.
Re-open Reach state. You should now see the hub's NAT type, its public egress IP (the address the internet sees your network as), and one or more WAN candidates — the endpoints a remote client can try.
Click Test reachability now to verify on the spot. The cloud immediately probes the hub's WAN endpoints (the same TLS + certificate check the background sweep uses) and reports whether it's reachable — so a freshly added hub doesn't have to wait for the periodic re-check. If it reports not reachable, confirm the port-forward and host firewall, then test again.

WAN candidates come from three sources, in order of preference:

Manual — a public endpoint you enter yourself (host:port) that maps to the hub via a router port-forward. The most reliable option, and the only one that works in corporate networks where automatic mapping is disabled.
UPnP — a port mapping the hub requested from the router automatically (where supported).
STUN-reflexive — the hub's public IP discovered via STUN, combined with its listen port. Works when the port is forwarded or the NAT preserves it.

Make the port reachable

WAN reach only succeeds if the hub's listen port (default 8443) is actually reachable from the internet. In most networks that means adding a port-forward on the router: forward inbound TCP 8443 to the hub machine's LAN address. If you forward a different external port, enter the resulting public-host:port as the manual public endpoint in the Reach state panel so the dashboard advertises the correct address.

Setting up the port-forward

Port forwarding is configured on your edge router or firewall — the device that holds your public IP. Switches (managed or unmanaged) operate inside the LAN and do not forward ports. Router interfaces differ, but the steps are the same everywhere:

Give the hub a fixed LAN address. Set a static IP on the hub, or create a DHCP reservation for it on the router, so the forward keeps pointing at the right host after a reboot or lease renewal.
Create the forward. In the router admin page (often under Port Forwarding, NAT, Virtual Server, or Applications & Gaming), map external TCP 8443 to the hub's LAN IP on port 8443. Use TCP, not UDP. If you forward a different external port, point it at the hub's 8443 and enter the external public-host:port as the manual public endpoint in Reach state.
Open the host firewall on the hub for inbound TCP 8443 if it isn't already.
Test from off the LAN. Verify from a network outside your own — a phone hotspot works. Testing from a machine on the same LAN usually fails even with a correct forward, because most routers don't support NAT hairpin (reaching your own public IP from inside).

Network topology. On a flat network (a plain unmanaged switch, single subnet) clients reach the hub directly and only the one router forward is needed. On a segmented network (managed switch with VLANs) where the hub and its clients are on different VLANs, also ensure the clients' VLAN is permitted to route to the hub's IP:8443 (inter-VLAN routing / ACLs on the L3 switch or gateway); the WAN port-forward still lives on the edge router.

When a port-forward can't work. If your ISP uses CGNAT (your “public” IP is shared and not routable from outside), no port-forward will reach the hub — you'd need a static public IP from the ISP, or the planned peer-hub relay. Symmetric NAT has the same effect on automatic candidates, though a manual forward still works when the public IP is routable.

Security note. A port-forward exposes the hub's HTTPS port to the internet, and you'll see scanner traffic hit it within minutes — that's normal background noise, not a breach: every request without a valid mount key gets a 401, and the key is a 256-bit secret stored only as a salted hash. The hub also drops obvious abuse before the TLS handshake (connection-rate limiting and temporary IP bans for floods and repeated bad-credential attempts), and the connection's Reach state panel shows a running count of blocked attempts.

To shrink the exposure further, set a WAN source allowlist in the Reach state panel — one or more IPs/CIDRs that are allowed to connect from the internet (LAN clients are always allowed). With an allowlist set, the hub drops every other public source before TLS, which eliminates the scanner noise entirely. Note that the cloud reach-probe will then read “unverified” because it, too, is blocked — that's expected; verify from an allowed client instead. The strongest option remains not exposing the port at all: reach the hub over a private overlay/VPN, or (when available) the peer-hub relay. As always, keep the agent updated and revoke mount keys you no longer need.

Install the certificate on the remote device

A remote, non-agent device still has to trust the hub's self-signed certificate (see Step 4). Because it isn't on your LAN, get the certificate from the dashboard and hand it to the device. There are two ways, depending on whether the person setting up the device has a dashboard login.

If you (a logged-in admin) are setting it up: create or open a mount key, click Download hub certificate (.crt), and copy the downloaded file to the remote device. This download is private — it uses your dashboard session and never creates a public link.

If someone without a dashboard login needs it: click Create public link… and confirm. This is optional and off by default — it mints an unguessable, no-login URL you can send to whoever is setting up the device, with Copy URL and Revoke controls. Until you create a link, the certificate is not publicly reachable; the public URL only works while a link exists, and Revoke cuts it off immediately. (The certificate's public part is not sensitive — it's sent in every TLS handshake — and the mount key secret, the actual credential, is never part of the link.)

On the remote device, install the .crt into the OS trust store exactly as in Step 4 (Windows: Local Machine → Trusted Root).

Map the drive over WAN

The mount dialog shows an Off-LAN command alongside the LAN one, using the hub's WAN endpoint instead of its LAN address. It's otherwise identical — same mount key, same label:

net use Z: https://<public-host>:8443/dav/<label> /user:<mount-key-id> <mount-key-secret> /persistent:yes

Things to keep in mind:

Enabling WAN regenerates the hub certificate once (it adds the public address to the certificate). Any device that already trusted the old certificate must re-trust the regenerated certificate the next time it connects (the fingerprint changes).
Always test from a genuinely off-LAN network (e.g. a phone hotspot) — most routers don't hairpin, so a same-LAN test of the public address can fail even when the forward is correct.
Revoke mount keys you no longer need. Each key is independently revocable from the Manage keys panel, which cuts off WAN (and LAN) access immediately.

Network / firewall egress

When you route patching through a Distribution Hub, the hub host is the one machine that needs broad outbound internet access; every other agent only needs to reach ET Ducky's control plane and the hub itself over the LAN. Allow the endpoints below outbound from the hub host (and the hub port inbound on the LAN), then you can lock the rest of the fleet down. The Microsoft and Linux sets are broad and change over time — verify them against current vendor documentation.

Most of this allowlist exists specifically to support Patch Management. Each group below is marked (all agents) when it applies fleet-wide, or (Patch Management — hub host only) when it's only needed on the hub host to download and cache installers.

ET Ducky control plane — all agents

Every agent, including the hub host, needs this to reach the cloud. Not Patch Management–specific — it carries config, heartbeats, AI, and patch grants.

etducky.com — 443/TCP — API, config, heartbeats, grants

Distribution Hub — all agents (LAN only)

Agents fetch cached installers from the hub host over the local network. Open this on the hub host to the agent subnets, not to the internet.

<hub host LAN address> — 8443/TCP — hub blob fetch (cert-pinned)

Windows: winget & Microsoft — Patch Management, hub host only

The hub host needs these to download winget- and Microsoft-sourced installers. This set is broad and changes over time; verify against current Microsoft documentation.

cdn.winget.microsoft.com — 443/TCP — winget source / manifests
*.delivery.mp.microsoft.com — 443/TCP — Delivery Optimization
*.do.dsp.mp.microsoft.com — 443/TCP — Delivery Optimization
*.dl.delivery.mp.microsoft.com — 443/TCP — installer content
*.windowsupdate.com — 443/TCP — Windows Update (if WUA patching is used)
*.update.microsoft.com — 443/TCP — Windows Update (if WUA patching is used)

Linux package mirrors — Patch Management, hub host only

Exact mirrors depend on each host's distribution and repo configuration. These are common defaults; confirm against your hosts.

archive.ubuntu.com, security.ubuntu.com — 443/80 TCP — apt (Ubuntu)
deb.debian.org — 443/80 TCP — apt (Debian)
mirrors.fedoraproject.org — 443/TCP — dnf (Fedora/RHEL family)
download.opensuse.org — 443/TCP — zypper (openSUSE)
*.snapcraftcontent.com — 443/TCP — snap
dl.flathub.org — 443/TCP — flatpak (Flathub)

Vendor installer hosts — Patch Management, hub host only

These come from the download URLs on your Software Catalog entries — the hub host needs outbound access to each one to fetch and cache the installer before agents pull it over the LAN. Because they're specific to the apps you've added, they aren't listed here; collect them from your catalog's download URLs (one host per distinct URL).

Copy-paste starting point

A minimal allowlist to adapt (append your own vendor installer hosts from the Software Catalog, and trim the Windows/Linux groups to the platforms you actually patch):

# ET Ducky Distribution Hub egress allowlist
# Verify the Microsoft/Linux sets against current vendor docs.
etducky.com:443                      # control plane (all agents)
<hub host LAN address>:8443          # hub blob fetch (LAN, all agents)
# --- Patch Management, hub host only ---
cdn.winget.microsoft.com:443
*.delivery.mp.microsoft.com:443
*.do.dsp.mp.microsoft.com:443
*.dl.delivery.mp.microsoft.com:443
*.windowsupdate.com:443
*.update.microsoft.com:443
archive.ubuntu.com:443
security.ubuntu.com:443
deb.debian.org:443
mirrors.fedoraproject.org:443
download.opensuse.org:443
*.snapcraftcontent.com:443
dl.flathub.org:443
# --- vendor installer hosts (from your Software Catalog download URLs) ---
# example.vendor.com:443