Moving from WSUS to WUfB - check the steps I've Ai'd together to help me on the journey :)

[kennysarmy]

 

1. Understand what you’re changing (important mindset shift)

Before touching anything, align stakeholders on this:

• WSUS = you approve individual updates and control distribution centrally

• WUfB = Microsoft hosts updates, you control policies, rings, and deferrals

• No update approvals

• No on-prem update content

• Reporting is done via Intune / Update Compliance / Azure Monitor, not WSUS

👉 If leadership expects “Approve KBs like before,” reset expectations now.

2. Prerequisites & readiness checks

Identity & management

• Devices are Hybrid Azure AD joined ✅

• Decide how you will manage policies:

  • Intune (recommended)

  • Group Policy (supported but legacy)

• Ensure devices can reach:

  • windowsupdate.microsoft.com

  • *.windowsupdate.com

  • *.delivery.mp.microsoft.com

• Check firewall / proxy rules (very common blocker)

Licensing

• WUfB itself is free, but good reporting requires:

  • Windows Update for Business Reports (via Intune)

  • Or Update Compliance (Log Analytics)

3. Inventory your current WSUS setup

Document this before dismantling anything:

• OS versions in use (Win 10 / Win 11, builds)

• Current update cadence

  • Monthly patch timing

  • Feature update frequency

• WSUS policies applied via GPO:

  • Specify intranet Microsoft update service location

  • Do not connect to Windows Update Internet locations

• WSUS cleanup status (declined/superseded updates)

This helps you recreate the intent in WUfB.

4. Design your WUfB update rings

For ~1000 devices, keep it simple:

Example ring structure

Ring	%	Purpose
Pilot	5%	IT & early adopters
Broad	85%	Main workforce
Critical	10%	Execs, kiosks, production

Decide per ring:

• Quality update deferral (e.g. 0 / 7 / 14 days)

• Feature update deferral (e.g. 0 / 30 / 90 days)

• Deadline + grace period

• Active hours

• Auto-restart behavior

Write this down first. Don’t build policies ad-hoc.

5. Configure WUfB policies (Intune route – recommended)

Create Update Rings

In Intune → Devices → Windows → Update rings for Windows 10 and later:

For each ring:

• Enable:

  • Quality updates

  • Feature updates

• Set deferrals per your design

• Configure deadlines (strongly recommended)

• Assign Azure AD device groups

💡 Use dynamic device groups where possible.

6. Remove WSUS enforcement (critical step)

This is where most migrations fail.

Identify WSUS GPOs

Look for policies setting:

• Specify intranet Microsoft update service location

• Do not connect to any Windows Update Internet locations

Options:

Option A – Modify existing GPO

• Set WSUS policies to Not Configured

Option B – New “WUfB” GPO

• Explicitly disable WSUS settings

• Link higher in OU structure

Key setting to remove:

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate WUServer WUStatusServer

⚠️ If these remain, devices will never use WUfB.

7. Pilot phase (do NOT skip)

Scope

• 20–50 devices

• Mix of:

  • Laptops

  • Desktops

  • Different sites

  • VPN vs non-VPN

Validate:

• Settings → Windows Update shows “Managed by your organization”

• Updates come from Microsoft, not WSUS

• Feature updates are offered correctly

• Reboots respect deadlines

• VPN traffic doesn’t spike unexpectedly

Use:

 

Get-WindowsUpdateLog

and

 

reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

8. Configure reporting & monitoring

Option 1 – Windows Update for Business Reports (best)

• Enable in Intune

• Uses Azure Monitor + Log Analytics

• Near-real-time visibility

Option 2 – Update Compliance (legacy but useful)

• Log Analytics workspace

• More complex setup

Track:

• Update compliance %

• Devices stuck on old builds

• Restart pending failures

9. Gradual rollout to remaining rings

• Move Broad ring devices in batches

• Monitor:

  • Patch success rate

  • Helpdesk tickets

  • VPN / WAN bandwidth

If needed:

• Use Delivery Optimization

• Configure DO Group / Cache servers

10. Decommission WSUS

Only after:

• 95%+ devices updating successfully via WUfB

• No critical systems dependent on WSUS

Steps:

• Decline all approvals

• Stop WSUS service

• Monitor for 30 days

• Decommission server

• Remove WSUS GPOs entirely

 

 

 

If anyone can add anything to the above before I make a start it would be appreciated.

 

J

[3s-gtech]

44 minutes ago, kennysarmy said:

 

1. Understand what you’re changing (important mindset shift)

Before touching anything, align stakeholders on this:

• WSUS = you approve individual updates and control distribution centrally

• WUfB = Microsoft hosts updates, you control policies, rings, and deferrals

• No update approvals

• No on-prem update content

Just note that you probably want to do peer-to-peer updating (caching), or come patch Tuesday your network traffic may go nasty. 

[jthompson]

2 hours ago, 3s-gtech said:

Just note that you probably want to do peer-to-peer updating (caching), or come patch Tuesday your network traffic may go nasty. 

Agree that this is worth considering. Take a look at https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization

We have various different buildings here, so I've created some Delivery Optimisation groups and applied those via GPO, so that p2p sharing of Windows update files doesn't traverse too many switches (i.e. not only avoiding every computer downloading all updates individually, but also having loads of large update files being copied from one end of the network to the other). Each group has a handful of machines that are used regularly and get the updates sooner, so that they can have the files available to p2p to the rest of the group a few days later.

 

Whilst "Windows Update for Business reports" is a thing that works, for free, I find it not especially useful: it has a tonne of reporting lag built into it. I prefer to monitor the OS build number of client machines, as reported by an inventory tool (GLPI), since that tells you whether a computer has successfully applied the latest monthly CU, which it 99% of what matters. Other methods of gathering OS build number from your computers will be available.

 

I would also suggest specifying a 'Target Version' in your WUfB GPOs. Use Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update → Windows Update for Business → Select the target Feature Update version. This would hold computers off upgrading automatically from, say, 25H2 to 26H2, until you decide that you're happy to move on to that target version.

 

When we ran WSUS, we didn't do driver or BIOS updates via it. When we moved to WUfB, we allowed those to come through, so it was another element of things to test and monitor.

Edited February 9 by jthompson

[Davit2005]

25 minutes ago, jthompson said:

Agree that this is worth considering. Take a look at https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization

We have various different buildings here, so I've created some Delivery Optimisation groups and applied those via GPO, so that p2p sharing of Windows update files doesn't traverse too many switches (i.e. not only avoiding every computer downloading all updates individually, but also having loads of large update files being copied from one end of the network to the other). Each group has a handful of machines that are used regularly and get the updates sooner, so that they can have the files available to p2p to the rest of the group a few days later.

 

Whilst "Windows Update for Business reports" is a thing that works, for free, I find it not especially useful: it has a tonne of reporting lag built into it. I prefer to monitor the OS build number of client machines, as reported by an inventory tool (GLPI), since that tells you whether a computer has successfully applied the latest monthly CU, which it 99% of what matters. Other methods of gathering OS build number from your computers will be available.

 

I would also suggest specifying a 'Target Version' in your WUfB GPOs. Use Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update → Windows Update for Business → Select the target Feature Update version. This would hold computers off upgrading automatically from, say, 25H2 to 26H2, until you decide that you're happy to move on to that target version.

 

When we ran WSUS, we didn't do driver or BIOS updates via it. When we moved to WUfB, we allowed those to come through, so it was another element of things to test and monitor.

Not sure I would trust to let it update drivers, I've known it to bork some i.e. Intel cards that you have created sub interfaces on using the intel driver/software not good on a server which you then lose access to and have to re-install the driver from USB stick, lol.

Edited February 9 by Davit2005

[garethEds]

3 hours ago, jthompson said:

Agree that this is worth considering. Take a look at https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization

We have various different buildings here, so I've created some Delivery Optimisation groups and applied those via GPO, so that p2p sharing of Windows update files doesn't traverse too many switches (i.e. not only avoiding every computer downloading all updates individually, but also having loads of large update files being copied from one end of the network to the other). Each group has a handful of machines that are used regularly and get the updates sooner, so that they can have the files available to p2p to the rest of the group a few days later.

 

Whilst "Windows Update for Business reports" is a thing that works, for free, I find it not especially useful: it has a tonne of reporting lag built into it. I prefer to monitor the OS build number of client machines, as reported by an inventory tool (GLPI), since that tells you whether a computer has successfully applied the latest monthly CU, which it 99% of what matters. Other methods of gathering OS build number from your computers will be available.

 

I would also suggest specifying a 'Target Version' in your WUfB GPOs. Use Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update → Windows Update for Business → Select the target Feature Update version. This would hold computers off upgrading automatically from, say, 25H2 to 26H2, until you decide that you're happy to move on to that target version.

 

When we ran WSUS, we didn't do driver or BIOS updates via it. When we moved to WUfB, we allowed those to come through, so it was another element of things to test and monitor.

 

Quick question.... if we do the 'Target Version' as noted by @jthompson above, would update 23H2 to 25H2 is we let it and keep all the settings and software?

Thanks

G

[jthompson]

12 hours ago, garethedmondson said:

 

Quick question.... if we do the 'Target Version' as noted by @jthompson above, would update 23H2 to 25H2 is we let it and keep all the settings and software?

Thanks

G

I'm going to say yes. That's how we have gone from 23H2 -> 24H2 -> 25H2. Once we were happy with the update on some test machines, and worked out any newly required Group Policy options to turn off any new cruft, etc, we just updated the target version in the GPO(s) and let Windows Updates do the rest. Whether it would do 23H2 directly to 25H2 idk: it may well do.

 

In-place feature updates are not offered to the computer if the hardware isn't officially supported, though, so even if you raise the target version on a computer that's not officially supported, it will just keep applying the monthly CUs thereafter for whatever release it's already on, and it won't be offered the upgrade. I only know that because my cousin did it, but you don't know him and he lives in America now. 😐

[kennysarmy]

22 minutes ago, jthompson said:

I'm going to say yes. That's how we have gone from 23H2 -> 24H2 -> 25H2. Once we were happy with the update on some test machines, and worked out any newly required Group Policy options to turn off any new cruft, etc, we just updated the target version in the GPO(s) and let Windows Updates do the rest. Whether it would do 23H2 directly to 25H2 idk: it may well do.

 

In-place feature updates are not offered to the computer if the hardware isn't officially supported, though, so even if you raise the target version on a computer that's not officially supported, it will just keep applying the monthly CUs thereafter for whatever release it's already on, and it won't be offered the upgrade. I only know that because my cousin did it, but you don't know him and he lives in America now. 😐

 

How does upgrading from say 24H2 to 25H2 cope with student computers that might get switched on a 8.40 for ten minutes then go off, come back on again for an hour mid morning, then off again, then on again for another lesson, then off again, then on again for 5 minutes at tutor time etc etc.

 

 

[jthompson]

Just like with any other Windows updates that involve a restart, I guess. The download phase would work like with any other updates, resuming as necessary after interruptions, and then if a shutdown was begun during installation, the computer would extend the shutdown phase to allow the installation to do what it needs. You'd then get the completion steps during the next start-up, before the login screen is shown.

 

It would make sense to coordinate things to happen after hours as much as possible. They're not necessarily much bigger of an update than a regular CU, I don't think.

Edited February 10 by jthompson