Retiring WSUS and Moving 2,800 Devices to Windows 11 Without Breaking Shifts

Clear the old control plane first. WSUS is driven by GPO (or local policy) that sets the intranet update service location and the automatic-update behaviour. While those settings exist, an Intune update ring is advisory at best and ignored at worst - the device keeps talking to WSUS, or double-scans and gets updates from both sources.

Concrete steps:

1. Inventory which GPOs write Windows Update settings, and remove/disable them from the OU that contains these devices - not just delete WSUS.
2. Confirm on a test device that the WindowsUpdate policy keys under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate no longer point at the WSUS server.
3. Create Intune update rings: Ring 0 = the three test devices, Ring 1 = IT plus a site, Ring 2 = broad, Ring 3 = kiosks. Deferral and deadline settings differ per ring.
4. Let a ring report before starting the next; you want the Windows Update report to show devices actually pulling from Microsoft.

Delivery Optimization: with 20 Mbps shared links, set DO group IDs per site so peers share content locally and cap background bandwidth. Without this, moving off WSUS makes the first Patch Tuesday visibly worse than WSUS ever was - that is the failure mode to pre-empt.

Licensing note: E3 covers Windows Update for Business; there is no config-manager dependency to keep.

Detect before you deploy. The claim is 120 devices fail the hardware check, but nobody has proven which 120. Inventory hardware (TPM version, Secure Boot, CPU generation) and confirm against a readiness report before naming names; a device can fail on TPM or Secure Boot alone and be cheaply fixed.

Deploy: a feature update profile targeting Windows 11, version 24H2, with rollback enabled and rollout waves (Ring 0 test first, then waves by site). Keep a Windows 10 quality-update ring running in parallel - the devices you exclude still need patches through the quarter.

Incompatible devices: put them in an exclusion group and handle them as a procurement/refresh decision, not an update decision. Do not let them sit in a ring that will retry the upgrade forever; a device that cannot install 24H2 will burn bandwidth on every retry attempt.

Kiosks: separate ring. They are 24/7 and have no user to negotiate a restart, so they need an explicit, agreed maintenance window rather than aggressive deferrals. Pick a low-traffic window, set the deadline to land inside it, and document who is on the floor when it happens. Kiosks also usually warrant a longer quality-update deferral so a bad patch does not take out the warehouse in one night.

Judgement: 'Windows 11 everywhere by end of quarter' is not achievable for the 120; get that exception agreed in writing in week one rather than in week eleven.

Settings that actually control this:

• Active hours - set to the shift pattern per ring (warehouse days vs. nights). Windows will not auto-restart inside active hours.
• Restart deadline + grace period - the deadline forces installation; the grace period gives the user a window to pick their own moment.
• Auto-restart / restart checks - keep them enabled for kiosks, disabled or heavily deferred for user-facing devices, so a user with unsaved work is not surprised.
• Allow the user to schedule the restart, and show the snooze option - handover staff will use it if it exists.

Why 'just extend the deadline' fails: a long deadline does not move the restart, it moves the install. The update still lands, the deadline eventually expires, and the reboot happens later - often at an unpredictable moment, sometimes mid-shift, sometimes with weeks of unpatched exposure in between. You have traded a known 06:00 reboot for an unknown one.

The actual fix is to align active hours and the deadline with the shift rota so the forced restart lands inside a gap you chose. Active hours can cover at most 18 hours, so a genuine 24/7 kiosk can never be fully protected - for those, a stated maintenance window is the honest answer.

Measure it: once the rings are live, use the Windows Update compliance reports to check devices are actually installing, not just deferring.