Category filter
Patch delivery architecture in Hexnode UEM
This page describes the end-to-end pipeline Hexnode UEM uses to deliver and install patches on managed endpoints — from the centralized repository to the verified result on a device. It’s the canonical reference for how patch delivery works mechanically, independent of specific OS-level configuration guides.
Overview
Hexnode’s patch management is agent-native: the Hexnode agent installed on each managed endpoint independently scans for missing patches, stages the validated payload, performs the installation, and verifies the result. This pipeline does not depend on the Windows Update client cooperating, nor on interpreting hints passed through a Configuration Service Provider (CSP). The agent is the actor at every stage.
Patches are sourced from Hexnode’s centralized repository, where binaries are validated before being made available for delivery. From there, delivery to the endpoint follows one of two routes — direct from the cloud, or via a local Distributed Apps and Files Server (DAFS) — but the installation pipeline that runs on the device afterward is identical regardless of route.
The delivery pipeline
- Centralized repository: Every patch is made available to endpoints from Hexnode’s centralized repository. Binaries in this repository are validated before distribution — this is the single controlled entry point for what an agent is ever allowed to install.
- Delivery route: cloud-direct or DAFS: Once a patch is ready for a device, it reaches the endpoint by one of two routes:
- Cloud-direct — the agent downloads the validated binary directly from Hexnode’s cloud repository.
- DAFS (local distribution) — for sites configured with a Distributed Apps and Files Server, the binary is cached locally and served to devices over the local network instead of over the internet. This reduces bandwidth usage and speeds up delivery for sites with many devices or limited connectivity, but the file being served is the same validated binary retrieved from the centralized repository — DAFS is a caching and delivery optimization, not a separate content source.
- Agent-native execution: scan, stage, install, verify: Regardless of delivery route, the agent on the endpoint runs the same four-stage sequence independently:
- Scan — the agent determines which patches are missing or applicable to the device, based on its own inventory of installed software and OS state.
- Stage — the validated binary is prepared locally on the endpoint ahead of installation.
- Install — the agent applies the patch.
- Verify — the result is checked against the expected hash of the validated binary, confirming the installed payload matches what was distributed from the repository, unaltered.
Hash-verifiable chain
The chain from repository to endpoint is hash-verifiable at every hop: the binary validated in the centralized repository carries a hash that can be checked against what DAFS caches (if used) and against what the agent ultimately installs. This means the payload that lands on a device can be confirmed to be identical to what left the repository — not a substitute, a partial download, or a tampered file.
What Hexnode does NOT do
To be precise about the boundaries of this architecture:
- No winget in the delivery path. Hexnode does not rely on the Windows Package Manager (winget) to resolve, fetch, or install patch payloads. The agent handles the full pipeline itself.
- No reliance on vendor CDNs at install time. Once a patch is validated into Hexnode’s centralized repository, the install-time path does not reach out to third-party vendor content delivery networks. The endpoint’s source of truth at install time is Hexnode’s repository (directly or via DAFS) — not the original software vendor’s distribution infrastructure.
- No dependency on Windows Update client cooperation. The agent does not hand off scanning or installation decisions to the native Windows Update client.
- No reliance on CSP hints. The agent does not depend on Configuration Service Provider signals to determine what needs patching or to trigger installation.
Agent-native vs. CSP-hint patching models
| Agent-native (Hexnode) | CSP-hint model | |
|---|---|---|
| Scan authority | Hexnode agent scans independently | Relies on OS-reported hints via CSP |
| Payload source | Centralized, validated repository (cloud-direct or DAFS) | Often vendor CDN or OS update service |
| Install execution | Agent performs install directly | Delegated to native OS update client |
| Verification | Hash-verified against the validated binary | Dependent on OS-reported completion status |
| Dependency surface | Self-contained within the agent and Hexnode repository | Depends on OS client behavior and CSP fidelity |
| Offline/air-gapped support | Supported via DAFS local caching | Limited — typically requires connectivity to OS/vendor services |
The practical difference: a CSP-hint model asks the operating system to report what it thinks needs patching and to carry out the update itself, which means Hexnode’s visibility and control are only as good as what the OS chooses to expose. The agent-native model removes that intermediary — Hexnode’s agent is the one scanning, fetching, installing, and verifying, so the result doesn’t depend on OS-level cooperation.
