Managing Windows Update and Settings From Hexnode

TL;DR

Hexnode drives Windows Update through the Windows Update for Business (WUfB) policy channel, the same MDM CSP that Intune uses. You set deferral days for quality and feature updates, active hours, reboot grace periods and pause windows. It is not WSUS. It does not pick individual KBs. It is Microsoft’s MDM patching pipeline with a Hexnode console on top, and used well it is enough for almost every SME Windows fleet.

Patch Tuesday lands the second Tuesday of every month. Your Hexnode policy decides how long after that your users see it. That single field, the quality update deferral, is the most important number in this article.

What does Hexnode Windows Update management actually let you control?

Hexnode exposes the WUfB policy fields Microsoft publishes through the Policy CSP (Policy/Config/Update/*). The console wraps them in a “Windows Update Configuration” policy you target at a device group. The fields that matter:

• Quality update deferral period (0 to 30 days). Pushes the monthly cumulative back by N days after Microsoft ships it. The Patch Tuesday B-release on the second Tuesday lands here.
• Feature update deferral period (0 to 365 days). Pushes the next Windows feature release (24H2, 25H1) back by N days after GA.
• Pause quality / pause feature updates, with start dates. A 35-day quality pause, a 365-day feature pause, both calendar-dated so you know when they expire.
• Active hours, start hour and end hour. Auto-restart will not interrupt the user inside the window. Default 8 to 17.
• Auto-restart deadlines and grace periods. How many days after a pending reboot Hexnode forces the restart, and how many minutes of warning the user gets.
• Branch readiness level. Insider Preview, Beta, Release Preview, GA. Almost always GA. Set it explicitly.
• Driver update inclusion. Toggle for whether Microsoft Update delivers drivers alongside the OS cumulative.
• Update notifications. Suppress, default, or “show all”.

What Hexnode does not expose, because the WUfB channel does not expose it:

• Per-KB approve / deny. No equivalent of the WSUS approval list. If a specific KB is causing trouble, you pause everything or uninstall after the fact.
• Non-Microsoft apps. WUfB is Microsoft’s pipeline, full stop. Chrome, Adobe Reader, Zoom are out of scope. Patch management’s job, not Windows Update’s.
• Bandwidth controls in the WSUS sense. Delivery Optimisation has its own knobs, but you are not throttling at the WUfB layer.

This is the MDM channel, not Group Policy. Every policy lands as a CSP setting in the registry, applied by the Windows MDM client. If you also have a domain GPO setting Windows Update behaviour, you have a conflict and Windows will pick whichever provider it last evaluated. Decide where your truth lives.

What is the right deferral strategy in 2026?

Three numbers, three reasons.

Quality updates: 7 days. The Patch Tuesday cumulative on the second Tuesday. Defer 7 days, so it lands on your fleet the following Tuesday. Why 7 and not 0? The first 48 hours of any Patch Tuesday are when Microsoft pulls or supersedes a broken cumulative. April 2024’s KB5036893 print-spooler regression, the August 2024 SSH client break, the November 2024 Outlook classic launch-loop fix: all caught and re-released within a week. A 7-day defer skips the broken first cut. Why not 14? Cyber-insurance underwriters increasingly ask “are critical patches applied within 14 days of release,” and a 14-day defer with any reboot tail puts you over the line.

Feature updates: 90 to 180 days, reviewed quarterly. Microsoft ships 24H2 or 25H1, business apps lag, drivers wobble for 30 to 60 days, then it stabilises. 90 days is the floor. 180 is fine if you have a person whose job it is to remember to lift the deferral. Anything close to 365 risks missing a feature update entirely and falling off support.

Security updates: never deferred. Here is the gotcha. The WUfB “quality update” deferral includes security cumulatives. They are the same KB. You cannot defer non-security and patch security on a different schedule. For true zero-day patching, you reach for the out-of-band update path: when Microsoft ships an OOB cumulative for an actively-exploited bug (the September 2024 CVE-2024-43491 OOB), it bypasses the WUfB defer for that release only, but only if AllowTemporaryEnterpriseFeatureControl and the OOB-acceptance flags are wired up. Most Hexnode tenants have not. Worth setting once.

How does Windows Update for Business compare to WSUS, Bitdefender Patch Management, and Intune?

Four tools, four different jobs, often confused.

WSUS. On-prem, server-hosted, downloads updates centrally and approves them per-KB. It is dying. Microsoft has signalled deprecation, the console is unchanged since 2012, and it does not handle non-domain-joined or remote endpoints. If you are still on WSUS in 2026, the migration target is WUfB plus a third-party patcher for non-Microsoft apps. WUfB through Hexnode is the WSUS replacement for OS patching.

Intune. Same WUfB pipeline. Intune is Microsoft’s first-party MDM, Hexnode is third-party, both use the same Policy CSP under the bonnet. Intune adds Windows Update Rings, Update Compliance reporting, and Driver Update Catalog visibility that Hexnode does not match. If you are on Microsoft 365 Business Premium or E3 you already pay for it, and our Intune page covers the trade-off. Hexnode wins on cross-platform parity. Intune wins on Windows depth.

Bitdefender Patch Management. Different category. It does not touch the WUfB pipeline. It runs its own scanner against a vulnerability database covering Microsoft Updates and around 150 third-party apps (Chrome, Firefox, Adobe Reader, 7-Zip, Zoom, Notepad++, the usual suspects), and pushes patches over its own agent channel. It overlaps with WUfB on the Microsoft side, where you have to decide which one is authoritative, and it covers the gap WUfB cannot reach on the third-party side. The full setup walkthrough is in our Bitdefender Patch Management guide. The short answer: pick one tool to drive Microsoft updates (we usually pick WUfB through Hexnode or Intune), let Bitdefender drive third-party apps, and do not run them in conflict.

Hexnode + WUfB by itself. Covers Windows OS and Microsoft Office updates, full stop. Anything else, you need a second tool. That is the conversation most clients try to avoid having and most need to have.

What about driver updates?

Drivers are where it gets ugly. There are two pipelines: Microsoft Update drivers and OEM driver pipelines, and they do not agree.

Microsoft Update ships drivers signed and submitted to the Microsoft Update Catalog by the OEM. Toggle “include driver updates” in your Hexnode WUfB policy and they flow alongside the cumulative. In theory, easy.

In practice, the OEM has a parallel pipeline that ships drivers six months earlier, sometimes with critical fixes the Microsoft Update version does not include. Dell Command Update, Lenovo System Update (Vantage), HP Image Assistant, and Surface’s firmware-via-Windows-Update (which actually does work cleanly because it is Microsoft’s own hardware) all want to drive the driver story.

Common pain points we see:

• A laptop ships with a graphics driver from August 2024. Microsoft Update’s catalogued version is from June 2024. The user manually installs the OEM version, which fixes their flickering screen. Three weeks later WUfB pushes the older Microsoft Update version on top, the screen flickers again, the user calls the help desk.
• An Intel Wi-Fi driver pushed by Microsoft Update breaks captive-portal authentication on a hotel network. The OEM has a fixed version. Microsoft has not catalogued it yet. Your user is offline at a conference for two days.
• An NVMe firmware update from the OEM, distributed only through the OEM’s own utility, never appears in Microsoft Update at all. Skip it and you are running outdated SSD firmware on every device in the fleet.

The pragmatic answer: turn off WUfB driver delivery on devices where the OEM has a competent update tool (Dell, Lenovo, HP business lines, Surface). Run that tool either as a packaged deployment from Hexnode or scheduled on the device. Keep WUfB driver delivery on for the long tail (mixed-brand desktops, white-box machines, secondary devices) where there is no OEM tool worth running. It is a per-device-group call, not a tenant-wide one.

Reboot policies and active hours

The fight over reboots is the most user-visible part of Windows Update management. Get it wrong and you either ship an unpatched fleet or you reboot your CFO mid-board-presentation.

The defaults: active hours 8 to 17, auto-restart deadline 7 days after install, grace period 2 days, restart warning 15 minutes. That is the Microsoft baseline. It works for office workers. It does not work for a lot of other shifts.

Patterns we deploy:

• Office workers, 8-to-5. Active hours 7 to 19 (give yourself a buffer either side), 7-day auto-restart deadline, 2-day grace period. Reboots happen overnight, users see one warning the morning of the deadline, the deadline rarely fires.
• Night-shift workers (call centres, ops, 24/7 monitoring). Active hours flipped: 18 to 06. The default 8-to-17 is exactly when these users are sleeping, and the device reboots in the middle of their shift. Profile this group separately. Hexnode lets you target by device group, use it.
• Shared / kiosk devices. Active hours irrelevant if there is no user. Schedule reboots for 03:00, give a 0-minute grace period, deadline 24 hours. They reboot quietly overnight.
• Field laptops and travelling users. Longest grace period you can stomach. These devices are offline for days at a time, and a reboot deadline that fires while they are on hotel Wi-Fi mid-call is a support ticket. 7-day grace with explicit user opt-in to defer further is the kindest pattern.

The single setting most worth tuning: the restart warning lead time. Default is 15 minutes. We push it to 60. Users with five Excel windows, three Teams meetings queued, and a half-written email need more than 15 minutes to find a clean stopping point. The patch still lands. The user does not write you an angry email.

What other Windows settings can Hexnode manage?

Updates are one slice of a much larger Windows configuration surface. The fields Hexnode exposes through the same MDM channel:

• Windows Defender (now Microsoft Defender Antivirus). Real-time protection, cloud-delivered protection, attack surface reduction rules, controlled folder access, exclusion lists. Useful as a baseline for sites without a third-party AV. If you run Bitdefender, the AV-coexistence story is already handled by Bitdefender disabling Defender on install; you still want Hexnode reporting Defender state on the few endpoints where Bitdefender is not deployed.
• Windows Firewall. Per-profile (Domain / Private / Public) rules, default actions, allowed apps, allowed ports. Most fleets do not customise this. They probably should.
• BitLocker. Encryption method, recovery-key escrow target, removable-drive policy, requirement for startup PIN. The Hexnode-vs-Intune trade-off on BitLocker key escrow is its own debate. Cross-link to our companion piece on locking Windows, the screen-lock and password policy guide for Hexnode, which covers the broader Windows lockdown surface.
• Kiosk / assigned-access mode. Single-app kiosk for digital signage, multi-app kiosk for warehouse stations, shell-launcher configurations. Hexnode is good at this. Intune is workable. If your fleet has more than a handful of kiosks, Hexnode wins this argument outright.
• App installation control. AppLocker policies, Windows Defender Application Control (WDAC), Microsoft Store blocking, win32 app deny lists. Useful in regulated environments. Painful to deploy in unregulated ones.
• Removable storage policy. USB mass-storage block, write-only allowance, BitLocker To Go enforcement. The cyber-insurance question on USB controls is one most fleets cannot answer well. This is where you answer it.
• Browser configuration. Edge homepage, Edge sync policies, IE-mode site list (yes, still), proxy settings.
• Energy and power. Sleep timers, hibernate behaviour, lid-close action. Boring, but on a 200-laptop fleet a bad power policy is the difference between “battery dies in 2 hours” complaints and a quiet help desk.

The full settings surface is bigger than this. Hexnode exposes most of the Windows Configuration Service Providers Microsoft publishes, and any setting Microsoft adds to the CSP catalog typically appears in Hexnode’s “custom configuration” XML upload within a release or two of GA.

Common pitfalls

Five we run into repeatedly.

Hexnode and Group Policy fighting. A device joined to both an on-prem AD domain (with GPO managing Windows Update) and Hexnode (with WUfB CSP managing Windows Update) has two competing providers. Windows resolves this by picking the most-recently-evaluated source, which is non-deterministic from the admin’s perspective. The fix: pick one. If you are migrating to MDM, scope your domain GPO to exclude MDM-managed devices (the MDMWinsOverGP policy helps but is not magic). If you are keeping GPO, do not deploy a Hexnode update policy on top of it.

A user pausing updates indefinitely. Windows Update has a “pause for 7 days” button in Settings. Users discover it. Users pause. Users forget. We have audited fleets where 12% of devices were paused, with paused dates from over a year prior, and the admins had no idea. The fix: set the policy SetDisablePauseUXAccess to disable user-side pause entirely. Hexnode exposes it as “Disable pause Windows Update” in the WUfB profile. Tick it. Your users will live.

A 90-day defer that never gets reviewed. This is the January 2025 cumulative miss we see most often. Someone set a feature update defer to 180 days during a Windows 11 23H2 stability concern in 2023, the deferral ticked along, the admin who set it left the company, the new admin inherited a fleet still running 22H2 in early 2025 because the defer had silently expired and Microsoft stopped shipping further 22H2 cumulatives. The fix: a calendar reminder, every quarter, to review the deferral fields. Or push the review responsibility onto a managed-service partner whose job it is to remember.

Active hours covering the wrong shift. Default 8-to-17 active hours on a night-shift fleet. Devices reboot at 14:00 in the middle of a shift, the operations team writes you up. The fix is in §“Reboot policies and active hours” above, but the meta-point is: never accept the default active hours for a fleet you have not actually profiled.

Driver updates clashing with OEM tools. Covered above. The fix is per-device-group: WUfB drivers off where an OEM tool runs, on everywhere else. Do this once, do not revisit until the OEM-tool footprint changes.

Where this fits

Windows Update is the obvious place to start the Hexnode-on-Windows conversation, but it is one of about a dozen Windows policy surfaces Hexnode drives. The MDM page covers the platform choice itself, the Hexnode page goes deeper on the console, and the Intune page is the comparison if you are weighing Microsoft-native against Hexnode for a Windows-heavy fleet.

For non-Microsoft patching, Bitdefender Patch Management is the companion tool. For the screen-lock side of Windows hardening, the Hexnode passwords and screensaver lockdown article covers the rest of the password posture story.

Free patch posture audit for your Hexnode Windows fleet

We will pull your Hexnode Windows Update policy, your active deferral fields, your active hours, your reboot grace settings, and your current compliance state across the Windows fleet, and tell you in writing where the gaps are. Specifically: whether your quality-update defer is sane, whether anyone has pause access they should not, which device groups need different active hours, and where WUfB and your OEM driver tooling are likely fighting. No pitch. Written reasoning, fleet-specific.

Book the audit through our services page and reference “Hexnode Windows patch posture” in the form. Two-week turnaround.