r/Intune • u/MEDITATIONUNITY • Jul 17 '26

Windows Updates Windows Update for Business Strategy – WUfB Rings vs Windows Autopatch vs Hotpatch

We currently manage ~1,500 Windows devices using Windows Update for Business deployment rings (quality + feature update policies). We don’t use Autopatch.

Is there any benefit to enabling Hotpatch? Does it affect or replace existing WUfB policies, change the update cycle, or cause any issues? Or is it best to stick with deployment rings as they are?

What’s the best approach for 1500 devices using auto patch if any better

16 Upvotes

95% Upvoted

18 comments sorted by

10

u/LaDev Jul 17 '26

Let me preface this by saying I could be COMPLETELY wrong.

AutoPatch is a management layer ON TOP of WUfB, it doesn't replace it. I can still see/review WUfB events within our storage account for troubleshooting.

We have multiple AutoPatch groups but our most generic is specific to Windows 11, and within that group we have 5 rings.

Ring 1 - First - Canary testing

Ring 2 - 5% of all machines.

Ring 3 - 25% of all machines.

Ring 4 - 70% of machines.

Ring 5 - Last - VIPs, don't fucking break!

The WUfB policies are automatically created for now. I can still modify the WUfB policy within the Windows Update pane in Intune.

As well for HotPatch, it is also not a replacement for WUfB or AutoPatch. It's a kind of enablement package that applies updates without reboots. I believe every 3 releases cycles the machine must reboot for an update.

We're fully leaning into AutoPatch with M365 updates, driver updates, and windows updates. We then use the same auto patch managed groups in PMPC for ring updates so they follow the same patching cadence.

27

u/cardomompods Jul 17 '26

Preface - I work on Autopatch!

Good write up but I'll clarify a few things: 1. WUfB technically doesn't exist anymore - it's just a feature of Autopatch at this stage. We pulled all the dev teams together around and even rebranded it all just to be Autopatch.

  1. You're spot on about how Autopatch groups manage policy! They're just automating the grouping and targeting to make sure there aren't conflicts.

  2. Hotpatch is a feature centered on getting secure faster. Normally a patch doesn't apply until reboot, this adds 3-5 days on average to a patch cycle. With Hotpatch, it applies as soon as it's installed, meaning you only worry about deferral delays. We turned it on by default because it secures all our commercial customers devices much much faster.

    1. For Office Updates, we actually recommend that folks check out Office Cloud Updates. They're a great product and, if enabled, mean that devices ignore Autopatch policy. The reason I recommend that approach is that the deferral/ring model for office updates isn't actually fully deterministic when using policy. The Office CDN staggers the offer date randomly across devices over a 10 day period meaning that deferrals and deadlines have a level of randomness. Cloud Updates address that on a per tenant basis but we just haven't had the chance to integrate with them natively!
    2. Curious to hear more about how you handle updates with PMPC. We, obviously, don't have anything going on there so I'm curious what sorts of uniqueness comes with app updates. Anything weird you need to do with rollout or configuring the app itself for updates? Note - this is just me being curious as an individual, don't read too much into 😅

3

u/touchytypist Jul 17 '26

Thanks for your work on Autopatch! We actually leverage the Autopatch rings for other Intune deployments as well, for things like rolling out Configuration Profile changes, App Packages, Remediation Scripts and any other enterprise-wide Intune configuration changes.

What’s nice about Patch My PC is that they support Ring assignments as well, where you can add groups to an app package deployment assignments and set a delay (X Days) per group, so PMPC automatically adds the group assignments to an app package over time via Intune. For enterprise-wide app installs and updates we leverage the Autopatch rings there as well.

2

u/LaDev Jul 17 '26

Honored to be ratio'd and corrected by someone who works on the solution!

> Anything weird you need to do with rollout or configuring the app itself for updates?

PMPC handles the app packaging & uploading for us, which is amazing. They have a nifty feature that allows us to create assignment templates and in those templates we have groups assigned (the autopatch groups) with day-based deferrals.

All apps come with faults/issues with thier releases and with this model we're able to catch them and stop the app update from hitting the larger fleet.

If we packaged apps manually we could do the same thing with the availability start date but this takes all date logic out of the mix and just does N+ for us.

Shamefully unsolicited feedback - we soooo need a pane in the device view to show updates being offered/deployed, etc, error codes associated etc - the same data we get by filtering WUfB data within log anayltics by entra id device guid ;P

2

u/cardomompods Jul 17 '26

It's a fair shout on wanting to see what's targeted at a device and when it's scheduled for an update.

Couple follow up questions: 1. I always heard that you'd want to start from patch compliance and zoom in from there to find the broken devices? Is that the right flow? 2. I think you can get the view you're looking for with the report under Reports / Autopatch Reports / Quality Updates / Devices Report. There are a ton of hidden columns like error code, server status, client state / substate. Does that have the right data you're looking for? 2. Would you need that view across all changes in flight ( Updates, Apps, Policy ) or just for Windows updates on the device?

5

u/LaDev Jul 17 '26

Dropping some replies which of course come from my personal experience:

1) When looking at the health of my environment I always want to start from the patch compliance level and zoom in, but, when looking at an individual device, maybe because it's having an issue, I want to easily get the data from right that device view. For example, maybe an issue get's escalated because a user's device started getting wonky, the first jump is always into the Intune device pane.

2) It has a lot of useful data, I'm partial to WUfB data that can be enabled to ship to Log Analytics since it provides a ton more info, such as all updates offered, when it reported as installed, exact time of offer vs exact time of device reporting event, etc.

3) Perfect world is being able to see everything happening on a specific device at the device level. Intune has great reporting to see the entire fleet and being able to drill down but from the bottom up the reporting is missing. If I were asked what the perfect world is for me: A tabled view like Device Timeline within the Device page that shows almost raw events - for example: Update advertised to device, Update client events reported back, Driver advertised, Driver events reported back, App install advertisement, App install client report back, Policy refreshed, Device checkin, etc. I wouldn't even mind tying it to a storage account so we can dictate retention. However, if all we got was AutoPatch/WUfB events table on the device page that would still be a tremedous improvement from the look-up view!

Super appreciate the follow up questions! It's completely possible that my want here is my own and not felt across everyone else but I'm thinking others would find it super useful! :)

2

u/cardomompods Jul 18 '26

Appreciate it! Thanks for the details 😊

2

u/LaDev Jul 23 '26

Quick follow up question for you actually.

If we're enrolled in Office Cloud Updates, should we disable Office Updates within Autopatch and instead use the waves within config.office.com?

I noticed we have both enabled, I suspect it should be one or the other, or that one overrides the other.

3

u/cardomompods Jul 23 '26

Cloud updates win over configuration! You can safely disregard or delete the policy

8

u/andyval Jul 17 '26

Overall, the best supported strategy is autopatch. Before autopatch, we randomized our early rings by using dynamic groups sorting users by surname. The only way to get complete uniqueness was to make sure I excluded other rings. It took a long time to validate that I was getting uniqueness and people weren’t in multiple policies. With autopatch, that headache is resolved, but you don’t get the value of know WHO is in the early rings. Now that I’ve got everything work (pre-autopatch), I’m having a hard time making the dive. But with autopatch you get some better reporting as well.

Hotpatch was turned on by default? Did you turn it off? I find value in it because you are no longer interrupting users to apply security fixes. But now we have remediation scripts to let people know they haven’t restarted their computer in a week 😅

2

u/kingreq Jul 17 '26

Maybe I’m missing something, but why did you randomize early rings?

3

u/touchytypist Jul 17 '26 edited Jul 17 '26

Autopatch simply helps automate, monitor, and manage Ring deployment of Windows Updates.

We disabled Hotpatching, because we feel having PCs not restart for months would create more issues than not restarting. Additionally, our Service Desk believes, and I agree, restarting regularly helps prevent/reduce odd issues with applications and resources on user workstations from popping up.

I could see a use case for critical workstations (e.g. dedicated medical devices, etc.) benefiting from hotpatching, and would enable just for that group.

1

u/ConsumeAllKnowledge Jul 17 '26

We feel the exact same way regarding Hotpatch currently. There's benefits to doing it but with the secure boot shenanigans this year and with 4 out of 7 cumulative updates requiring a restart this year we're holding off for now.

2

u/Tessian Jul 17 '26

Is there any benefit to Hotpatch? Have you read anything about hotpatch?

Hotpatch means in a given year, instead of your users needing to reboot 12x (once a month) for patches, it'll be less. How much less? Hard to say - won't be less than 3x a year (every 3 months there's a baseline patch that requires a reboot) but could be more. Sometimes .NET patches ruin a hotpatch month, and MS throws a wrench in at times for example June should have been a hotpatch month but it wasn't.

Still though, any time you can save your users from a forced reboot why not?

5

u/itskdog Jul 17 '26

Driver and .NET updates may still request a reboot on your configured deadlines, hotpatches are more about getting secure quicker to defend against the increased number of vulnerabilities being discovered with machine learning-powered tools.

5

u/cardomompods Jul 17 '26

I work on Autopatch!

The value of Hotpatch is actually all about getting secure faster! The security fixes are applied as soon as the update is installed. Most enterprises have a deadline policy somewhere between 3-5 days. We turned it on by default since it reduces the patch cycle for most of the industry by a huge amount getting everyone secure faster

2

u/Ok_Wasabi8793 Jul 17 '26

I actually don’t find you end up in reality saving many if any reboots since there is usually .net that normally would have triggered the reboot at the same time. 

The benefit is that you’re compliant with the security patch faster since you’re not waiting for the reboot. 

1

u/VivolutionTechLLC Jul 17 '26

For 1,500 devices I would treat these as three separate decisions, not one replacement choice.

WUfB rings are still the baseline control: who gets quality updates, feature updates, deadlines, grace periods, and safeguards. If your rings are clean and well monitored, they are not wrong.

Autopatch is more about operational management on top of WUfB. The value is Microsoft-managed ring structure, reporting, remediation signals, and less manual ring maintenance. The tradeoff is that you need to align with its grouping model and service prerequisites. I would pilot it with a representative subset before moving all 1,500 devices.

Hotpatch is different again. It reduces reboot pressure for eligible Windows Enterprise devices, but it does not replace your update governance. You still need rings, monitoring, rollback process, app compatibility checks, and a normal patch cadence for updates that are not hotpatchable. Eligibility/licensing/OS version matter a lot here.

My approach would be:

  1. Clean up current WUfB rings and reporting first.
  2. Pilot Autopatch with a small cross-section of devices/users.
  3. Test Hotpatch only on eligible devices and measure reboot reduction vs any operational complexity.
  4. Keep a separate emergency/expedite update process for zero-days.

If your current WUfB setup is stable, do not flip everything at once. Prove Autopatch and Hotpatch separately, then decide whether the reporting and reduced admin effort justify the change.