Windows Update Management: Autopatch, Update Rings and Feature Updates Explained

M365 FM - Windows Update Management - Autopatch, Update Rings and Feature Updates Explained 00:00:00 Speaker: Most teams still treat patching like an event. Once a month someone runs it, someone approves it, someone watches it. But in reality, that's not how windows updates work anymore. Updates are a continuous system. They run on rules, rings, and consequences whether anyone is watching or not. In this video, we cover auto patch update rings, feature updates, expedited patches, drivers reporting, and failures. And if you want to catch the next release cycle, subscribe now. But first, the model that's quietly failing. Sponsor segment. Stellar. Migrator for exchange. Quick note before we get into it, updates break less when the estate underneath them is clean. Stale devices, half finished migrations and old configurations all show up later as failed installs and strange policy conflicts, migrations and patching share one problem unmanaged change. Someone moves a mailbox without a plan and you get support tickets. Someone leaves a device out of a ring and you get an exposure window. If you're running an exchange migration right now, there's a tool worth knowing about stellar Migrator for exchange. It's built to move mailboxes between exchange environments and into Microsoft three hundred sixty five, and it helps keep that change controlled instead of improvised. That's a fact about the tool, not a promise about your project. Check the details for your own setup because cleaner states don't happen by accident. Which brings us back to the core question who actually owns change on a windows device? The old model patching as an event. Let's start with how it used to work in the W s US era. Patching had four steps approve. Wait. Deploy. Hope Microsoft released updates. They landed on your server, and admin logged in and picked which ones to approve, then picked which computers got them. Then you waited. Devices checked in with the server on their own schedule. Some installed the update that night. Some took a week, some never reported back at all. And then you hoped. You hoped the update didn't break the finance app. You hoped the laptops actually restarted. You hope the report you pulled on Friday meant what you thought it meant. That's the loop. Approve. Wait. Deploy. Hope. Then there's Patch Tuesday. In most organizations, Patch Tuesday became a deadline. The second Tuesday of the month arrived, and the whole team treated it like a deployment date. Someone cleared their calendar. Someone wrote a change request. Someone sent the email that said patching this weekend. But Patch Tuesday was never meant to be a deadline. It was a signal. Microsoft was telling you that new updates were available and that the clock had started. The deadline was yours to set based on how exposed you were. Over time, the signal turned into a ritual, and the ritual hid the real question how long can we stay exposed? And underneath all of this, set one assumption. It controls timing by controlling the server. If you owned the W s US server, you owned the schedule. Nothing installed unless you approved it. Nothing reached a device unless the server allowed it. Control lived in one place and that place belonged to you. Now that assumption wasn't foolish. It held up for a long time and for a reason. Devices lived on the corporate network, desktops sat under desks. Laptops came back to the office every evening. Everything pointed at the same internal server because there was nowhere else to point. The network was the boundary and the server sat inside it, so control was real. You approved an update and within a day or two the whole estate could reach it. You could see which machines checked in. You could chase the ones that didn't. The model matched the environment, so the model worked. That's why it lasted so long. But a model only works while its assumptions stay true. And the assumption here wasn't about W, so it was about where devices live, who they talk to and who sets the pace. That world ended and the model didn't notice why the old model breaks today. Look at where your devices are right now, not where the asset list says they are. Where they actually are. A kitchen table, a hotel lobby, a train, a client's guest wifi. A home office with a router. Nobody has updated since twenty nineteen. Laptops don't come back to the office every evening anymore. Some come back twice a month, some never come back at all. And the VPN, the one thing that used to pull them toward your internal server is something people only open when they have to reach a file share. So think about what that means for a w s US server sitting inside the network. A device that never touches the network, never checks in, and a device that never checks in doesn't exist. As far as that server is concerned, you approve the update, the server is ready, the laptop is in a coffee shop, and the two of them will never meet. That's the first break. The server controls a place and the devices stopped living there. Now the second break volume. Under the old model, a human approved updates that worked when there were a handful of products and a calm rhythm. But look at what lands today. Monthly quality updates feature updates every year. Driver updates arriving from dozens of hardware vendors. Definition updates, daily out-of-band fixes whenever something gets exploited before the calendar says it should, nobody can read all of that, test all of that and approve all of that by hand. Not at a good pace anyway. So what typically happens is this the approval step becomes a bottleneck or it becomes a rubber stamp. Either someone sits on updates for three weeks because there's no time to review them, or someone clicks approve on everything because there's no time to review them. Both outcomes are the same failure a human step state in the process after it stopped being useful. And the third break is the one that costs real money. Exposure windows used to be measured in weeks. A vulnerability was found, a patch shipped, and attackers needed time to turn it into something usable. You had room. That room is gone. Once a patch ships, it can be compared against the code it replaced. That comparison shows exactly what was broken. Attackers do this routinely and they do it fast. The gap between update released and exploit in the wild now runs in days, sometimes less so every day your update sits in an approval queue is a day you're running software that the whole world knows how to attack. That's what the old model quietly turned into. Not a patching process. An exposure process. Now, I want to be fair here. There's a real argument on the other side. Updates can break things. Everyone in this field has a story about a patch that took down a line of business app, or a driver that turned screens black on one specific laptop model. Disruption is real and it lands on people who have deadlines, so the old instinct wait and watch isn't stupid. It's protecting something. But it prices the two risks. Wrong. The cost of disruption is visible. A ticket gets opened, someone complains. A manager asks what happened. The cost of delay is invisible. Nothing happens until it does. And when it does, it's not a ticket. It's an incident. So teams drift toward the risk they can see and away from the one that's bigger. That's the real flaw. It's not that WSU is old, it's that the model assumes someone can stand in the middle of all this, read every update and decide device by device when each one should land. Nobody can. Not anymore. Which means the question has to change. It was never really. How do we control updates? It's what outcome are we willing to live with? And who decides? And that's where things change. The new model desired state, not deployment. So what replaces it? Not a better server, not a faster approval process. A different question answered in a different place. The old model made you push updates. Pick the update. Pick the device. Pick the day. Every decision was a deployment decision and every deployment needed a person standing behind it. The new model asks you to describe an outcome. Instead, you write down what acceptable looks like. Quality updates installed within seven days of release. Feature updates on the version you chose. Restarts forced after a deadline, not before. That's it. That's the whole policy. And then something else does the work. This is what desired state actually means. Policy declares where a device should end up. The service figures out how to get it there. You stop scheduling the trip and start defining the destination. Now that sounds like marketing until you see where the work really happens. The engine here is Windows Update for business. It's not a server you install, it's not a console you log into. It's a set of capabilities built into windows itself backed by Microsoft's Cloud. The device talks straight to Windows Update over the internet wherever it is, and it evaluates your rules on its own which solves the first break from earlier. The laptop in the coffee shop doesn't need to find your network. It already knows how to find Microsoft. The rules travel with the device, not with the building. But rules need a place to live. That's where Intune comes in. Intune is the policy plane. It's where you write the rules, group the devices and assign one to the other. It doesn't carry the update. It doesn't download anything on behalf of the laptop. It tells the device what's allowed, how fast and by when. Windows Update is the delivery plane. It carries the bits. It decides what's offered, handles the download, runs the install, two planes, two jobs. And this split matters more than it looks in the old model. One box did everything it stored the updates, approved them, distributed them, and reported on them. Control and delivery were tangled together, so every change in one meant work in the other. Now they're separate. You change your policy in Intune and the delivery side doesn't care how you got there. Microsoft changes how updates are packaged and your policy doesn't care either. Each side can move without breaking the other. That's a structural gain, not a feature. Here's what it changes for the person who owns the outcome. You stop managing patches, you start managing risk tolerance. Think about how that conversation sounds in a leadership meeting. Under the old model, the question was, did we deploy this month's updates a yes or no about an activity someone did a thing or didn't. Under the new model, the question is how long are we willing to be exposed and for which devices? Dyson. That's a business question. A finance laptop and a conference room display don't carry the same risk, and they shouldn't carry the same deadline. A pilot group can move in two days. A clinical workstation might need two weeks and a written reason why. So the real work moves upstream, not into clicking a proof, into deciding once on purpose what each group of devices should tolerate. Then the system holds you to it. That's the shift. Fewer decisions per month, better decisions per year. But it only holds together if you understand what sits underneath. Because policy declares, service delivers is a clean sentence and clean sentences hide the parts that fail. Something has to notice that an update exists. Something has to decide what that update means for each device, and something has to carry it out. Watch it and stop it if it goes wrong. Three jobs, three layers. And once you see how they connect, you'll know exactly where to look when an update doesn't land. The architecture and audio event reasoning. Orchestration. Here's the whole system in three words event reasoning. Orchestration. Every update you will ever manage passes through all three. Skip one in your head and you'll look for the problem in the wrong place. Start with the event. An event is Microsoft releasing something, a monthly quality update, a feature update to a new windows version, a driver from a hardware vendor, or an expedited fix pushed out of band because someone is already attacking the flaw, it closes. Here's the thing about an event it doesn't know your estate exists. It's a release sitting in Microsoft's cloud, available to anyone who asks. It carries no opinion about your finance team or your factory floor. It just becomes available. That's all it does. It says this exists. Now then comes the reasoning. This is where your policy lives, and it's where every device answers one question. Should I take this update? And when the answer depends on rules you wrote, which ring is this device in? How many days is that ring allowed to defer a quality update? Is there a feature update policy pinning the version. What's the deadline and how long is the grace period after it? Notice what's happening here. No one is deciding anything in the moment. The decision was made weeks ago when you built the rules. The device just reads them, compares them to the event and works out its own answer. Two laptops, same update, same day. One is told to install tonight. The other is told to wait nine days. Neither answer is random. Each one is the output of the reasoning layer and then orchestration. This is the part that acts. Something has to deliver the update, trigger the install, handle the restart, and watch what happens. Something has to notice when a ring starts failing and stop the rollout before it spreads. That something is either in tune. Running the policies you wrote yourself, or auto patch a managed service that builds and runs that machinery for you. Same job, different owner orchestration. Executes it, monitors and when needed it pauses. Now let's walk one update through all three slowly. It's the second Tuesday of the month Microsoft releases a cumulative quality update. That's the event. Nothing has happened to your devices yet. The update simply exists. Next, a laptop in your pilot ring wakes up and checks Windows Update. This is a client side check the device reaching out on its own schedule. Windows update says there's a new update available now. The reasoning starts and it runs on the laptop itself. The device reads its policy. This ring has a quality deferral of two days. The update was released today, so the answer for now is not yet two days pass. The laptop checks again. The deferral has expired, so the update is now offered to this device. The laptop downloads it. It installs in the background outside active hours. Then it hits the restart and the policy has an opinion about that too. The deadline gives the user a set number of days to restart on their own. After that, windows forces it. Here's where orchestration steps in. While all this runs, the service is collecting results. How many pilot devices installed cleanly? How many reported errors? If the install failure rate crosses a threshold, orchestration doesn't wait for a human to notice. It pauses. The rollout and the broad ring never receives the update at all. If the pilot looks healthy, the next rings deferral expires on schedule. Same event, same reasoning, a different clock. So look at what each layer actually did. The event created the possibility, the reasoning decided who and when the orchestration carried it out and kept watch. And here's why this matters when something breaks, if a device never gets an update, the event probably isn't the problem. Microsoft released it. The question is whether the reasoning told the device to wait forever, or whether orchestration failed to deliver. Those are two completely different fixes, and teams burn hours mixing them up. Now, which layer do you check first? The reasoning layer. Because the event is out of your hands, an orchestration only does what the rules tell it to. Everything downstream depends on whether the rules are right. So that's where we start with the engine that evaluates those rules on every single device. Windows update for business. The engine under everything. Let's be exact about what this thing is. Windows update for business isn't a product you buy. It's not a server. It's a set of policy controls built into windows, wired into the Windows Update service every PC already talks to. That's the whole idea. The machinery already exists on every device. Windows update for business just lets you set the rules it follows. So what does it actually do? Three things it lets you delay. When updates are offered to a device. It lets you set a deadline, a point where the update stops being optional, and it lets you control how and when the restart happens. Deferral deadline restart everything else you'll configure in this video is a variation on those three. Now what doesn't it do? It doesn't store updates for you. There's no approval queue to review, no list of patches waiting for a click. It doesn't build your rings. It doesn't watch a rollout and stop it when things look bad. And it doesn't give you a nice report on its own. It's an engine, not a dashboard, not a driver. That distinction clears up a lot of confusion when people say Windows Update for business isn't working, they usually mean the layer on top of it isn't working. The engine is doing exactly what it was told. So let's look at how it gets told. Start with deferral. A deferral is a number of days. You say quality updates wait seven days after release before this device is offered them. Feature updates wait a different number of days set separately. Nothing is installed during that wait. The device knows the update exists and it ignores it on purpose. Then the deadline. This is the number that makes the policy real. After an update is offered, the deadline sets how many days the user gets before windows installs it anyway, without a deadline. A deferral is just a suggestion. With one, it has a hard edge and then restarts. Windows can wait for a good moment outside active hours and nudge the user with notifications, but the policy can also say after this many days, restart whether the user likes it or not. Those three controls in different numbers give you very different behavior for different groups of people, and nobody has to touch a single update by hand. Now here's the part that surprises people. Where does the decision actually get made on the device? A laptop doesn't wait for a signal from your management console on its own schedule. It reaches out to Windows Update over the internet and asks what's available for me. Windows update replies with what exists. Then the device turns to its own policy. It reads the deferral settings that Intune delivered earlier. It checks the release date. It does the math itself. Is this update old enough to be offered? Has the deadline passed? Is it inside active hours? All of that is evaluated locally. So the policy isn't a command. It's a set of instructions the device carries around and it consults them every time it checks for updates. Your management tool wrote the rules once the device applies them again and again, wherever it happens to be. That's why the coffee shop laptop works at all. It doesn't need your network or your console or a connection back to anything you own. It needs two things the policy it already has, and a route to Microsoft. And this is the structural point that separates the new model from the old one. This is a client side decision system, not a push system. In a push system, a central point decides and then sends. If the device can't be reached, the decision never lands. The control is only as good as your ability to reach the machine. In a client side system, the decision already lives on. The machine control doesn't depend on reaching it. It depends on whether the policy arrived and whether the policy is correct, which tells you something important about failure. If a device is behaving oddly, you don't ask whether your server could reach it. You ask what policy it's holding and what that policy told it to do. Now you've seen the three controls deferral, deadline, restart. The question is where you set them. And for most teams, the answer is the first thing they open. In Intune, the control surface everyone reaches for before they understand what's underneath. Update rings, update rings, explained what they actually control. Open Intune, go to devices, then windows, then update rings. You'll see a policy type called update rings for windows ten and later. That name is a little misleading. A ring isn't a group of devices. It's a policy, a bundle of settings that you assign to a group. So when people say ring, they mean two things at once the settings and the people who receive them. Keep those apart in your head. The settings live in one place. The membership lives in another. Now the settings that matter, the first two are the ones everybody finds quickly. Quality update deferral period, feature update. Deferral period. They sound similar. They behave very differently. A quality update is the monthly cumulative patch. Security fixes. Bug fixes, small changes. The deferral here runs from zero to thirty days. You set seven and the device waits seven days after release before it's offered the update. A feature update is a new version of windows. Different size, different risk. Different calendar. The deferral can run up to three hundred and sixty five days. Same idea, much longer leash. And here's why they're separate. A thirty day ceiling on quality updates is a hard limit, and it's short for a reason. Those patches close holes that attackers are already studying. A year of delay on a feature update is fine, because the version you're on is still supported. Waiting a year on the security patch is not. 00:17:06 Speaker: So the two numbers answer different questions. One asks how long do we wait to see if a patch is safe? The other asks, how long do we stay on this version of windows? Next deadlines. Inside the same policy, you'll find the deadline for quality updates, the deadline for feature updates, and the grace period. We'll spend real time on those later. For now, just know they sit in the same screen next to the deferrals. Then there's the user experience block. This is where policy meets a person. Active hours. You set a start and a stop and windows won't restart the device inside that window, the maximum range is eighteen hours. There's also a setting that lets windows adjust active hours automatically based on how the person actually uses the machine. Useful for laptops that don't follow a schedule, then restart behavior. Do you let the user schedule it? Do you force it after the deadline? How many days of reminders do they get and when do the reminders turn into a countdown? And then the quiet ones? Whether users can pause updates themselves, whether they can check Windows Update on demand, whether the update notification appears at all, or stays silent. These look like small preferences. They aren't. Each one decides whether the user has a hand on the policy or just a view of it. If you let users pause updates, some will add a pause. Device is a device your deferral math no longer describes. Now two settings that are easy to skip past servicing channel. For most organizations, the answer is the general availability channel, the normal release that everyone gets. It's the default for a reason. It's what Microsoft supports broadly. Then pre-release options. Intune can enroll devices into the Windows Insider channels Beta or Release Preview, so a small group sees changes before they reach everyone. That can be a smart early warning ring release preview in particular, lets you test the next quality update before it ships, but it's not a place for devices anyone depends on. Pre-Release builds can break. That's what they're for. So that's the whole surface. Two deferrals, deadlines and grace active hours and restarts. User controls, a channel. And honestly, none of it is hard. Every setting has a number or a toggle. You can read the whole policy in a few minutes and understand what it does. There's no mystery in the settings, but that's exactly why teams get a false sense of progress. They build one policy, they pick sensible numbers, they assign it to everyone, and they call it done. One ring, one clock, one bet placed on every device at the same time. The settings are easy. The ring design is where teams fail. Designing rings. Test pilot. Broad. Critical. A ring is a bet. Each ring places the same bet on a different group of devices at a different time. The first ring tells you whether the update is safe. The last ring is where you can least afford to find out it isn't. Ring design comes down to three questions at every stage how many devices are in it, how much damage can they take, and how good is the signal you get back? Size, risk and signal quality. Here's how they trade off. A small ring is cheap to break if ten devices fail, ten people have a bad afternoon, but ten devices is also a thin sample. If the update only breaks one laptop model and none of your ten has that model, the signal says all clear. While the problem sits, two rings away. A big ring gives you the opposite great signal because it covers every model and every app combination, but when it breaks, it breaks loudly so you don't pick one. You stack them. Each ring is bigger than the one before, and each one earns the next ring's. Trust. The structure most teams land on has four stages. Test pilot broad critical test is small, maybe one or two percent of the estate. Its job is to answer one question does this install at all? A short deferral, sometimes zero days. So it sees the update the moment it's released. Pilot is bigger, say five to ten percent, a few days behind test. Its job is different. It answers whether real work still works. Real apps, real peripherals, real habits. Broad is the bulk. Most of your devices a week or more behind. By the time an update reaches broad, two rings of evidence stand behind it and critical is last on purpose. We'll come back to who goes there now. Why four and not two? Because two rings give you one decision point early group everyone else. If the early group is clean, everybody gets the update at once. Your whole estate becomes the second test. That's not a ring model. That's a delay with extra steps. Two rings also force a bad compromise. The early group has to be small enough to be safe and big enough to be representative. Those goals pull against each other so you fail at one of them four rings. Let each stage do one job test checks the install pilot checks the work broad. Is the rollout. Critical is the protected group, which gets the most evidence of all. So who belongs where test is it the people who understand an error code. Don't panic at a restart and will tell you exactly what happened. That's the signal quality choice. A vague complaint from a busy salesperson is noise. A screenshot and a log from an engineer is data, but it alone isn't enough. It devices are tidy. They run few apps and carry few quirks, so the pilot Ring needs power users. People who live in the odd corners of your software. The analyst with the macro heavy workbook, the designer with three monitors and a docking station. They break things that clean, machines never touch, and hardware matters just as much as people pick pilot devices. So every major model in your estate has at least a few representatives. Same for drivers, same for security agents. Same for that one VPN client. Nobody wants to talk about a pilot ring that skips a hardware. Family is blind to it. Now the hard part. The people who ask to be somewhere else, executives. The instinct is to put them in the last ring to protect them from disruption. That sounds reasonable until you remember the exposure. Math executives hold the most sensitive data, and they're the favorite target for attackers. Delaying their patches the longest is exactly backwards. A better answer is to put them in broad, not early, not last close to the rest of the estate with a named contact if something goes wrong. Critical is for devices where a restart at the wrong moment costs real money or worse. Kiosks, point of sale terminals. Factory floor machines tied to a production line. Clinical workstations in a hospital. These devices need the most evidence and the most planning. A longer deferral gives them that. But a longer deferral doesn't mean no deadline. It means a deliberate window set with the people who run the line or the ward written down and honored. That's the design for rings. Different sizes, different jobs, different risks. But a ring is just a delay. On paper, it only works if the deadline behind it is real deadlines, grace periods and restart behavior. A deferral says when an update is offered, a deadline says when the offer expires. That's the difference between a suggestion and a rule. Without a deadline, a user can ignore the update forever, and your ring math describes nothing with one. There's a date on the calendar where windows stops asking quality updates and feature updates each get their own deadline. You set them separately in the same policy for quality updates. The deadline is a number of days from zero to thirty. It counts from the moment the update is offered to the device, not from the release date. So a ring with a seven day deferral and a two day deadline means this. The update is offered on day seven, and windows forces the install by day nine. Feature updates work the same way with the same range, but the risk is different. A quality update takes minutes and a single restart. A feature update can take much longer and the restart cycles are heavier, so most teams give feature updates a longer deadline, and they pair it with a clear message to users well ahead of time. Then there's the grace period. The grace period is extra time after the deadline. Before windows forces the restart. It runs from zero to seven days. Think of it as a buffer that only matters in one situation. When a device comes back online after being away. Here's what that looks like. A laptop sits in a bag for two weeks. The deadline passes while it's powered off. The user opens the lid on Monday morning without a grace period, windows can restart that machine within minutes of boot in the middle of a presentation prep with a grace period, the person gets a few days to restart on their own terms. And this is where trust gets made or lost. Users learn quickly what your policy feels like. If a forced restart ever lands during a client call, they remember it. Next time they'll hunt for the pause button, or they'll stop restarting at all because they've decided the machine can't be trusted to pick its moment. One bad restart teaches ten people to resist the next one. A grace period is cheap insurance. Against that, it costs you a few days of exposure on devices that were offline anyway. Now the restart itself. Windows tries to be polite. First it installs updates in the background, then waits for a restart. Outside active hours, it can restart on its own. Inside active hours it holds off. There's another protection that people forget. Engaged hours windows can detect that someone is actively working in a meeting or sharing their screen, and it delays the restart even outside the set active hours. The setting you'll find in the policy lets you define the engaged window, and the device respects it until the deadline forces the issue, and notifications matter more than people expect. You can configure reminders for the restart. How many days of warning, how many hours before it counts down on screen, and whether the user can snooze. A forced restart that arrives with three days of notice feels like a rule. A forced restart with no notice feels like an ambush. You can also tell windows to skip the polite phase entirely. Auto restart at the deadline with a short warning that's the right call for a kiosk. It's a harsh call for a salesperson. So here's the tension underneath all of it. Security wants the deadline short. Every extra day is a day. The patch isn't applied. Productivity wants the deadline long. Every forced restart costs someone, their flow, and sometimes their unsaved work. Both sides are right. The mistake is treating this as one global dial. Set it tight everywhere, and you create a quiet revolt among the people who can least afford interruptions. Set it loose everywhere, and you've built a very polite way of staying exposed. The better move is the one we've already described. Tie the numbers to the ring. Test gets a short deadline and no grace because those users are it and they expect it. Broad gets a moderate deadline, a grace period, and generous notifications. Critical gets a window negotiated with the people who run the line. Different groups, different tolerance, written down, defended, reviewed and that handles quality updates. But rings and deadlines only control the monthly patch cadence cleanly. Feature updates are a different animal. A new version of windows is bigger, riskier, and tied to a support calendar, so they need their own control feature update policies. Pinning the version update rings can defer a feature update, but they can't choose one. That's the gap. A ring says wait this many days and then take whatever Microsoft is offering. If a new windows version ships during that time, the ring doesn't care which version it is, it just counts. Days feature update policies fix that. You'll find them in Intune under devices. Windows ten feature updates a feature update policy does one job. It names a version windows eleven twenty four H2, for example, and it tells every device in the assigned group. This is where you stop. Not the latest, not whatever's available after ninety days. A specific version chosen on purpose. Here's why that matters. Without a pin, the target moves under you. Microsoft releases a new version once a year. A device that finishes its deferral could land on a version your apps were never tested against. Nobody decided that the calendar did. With a pin, the decision is yours. The device updates to that version and then it stays there. If a newer version comes out, nothing happens. Your devices keep running the one you chose, and they keep getting monthly updates on top of it. So the policy is really a statement about scope. This version is approved. Anything newer is not until someone says so. Now, what happens when a ring and a feature update policy both apply to the same device? The feature update policy wins when you assign one. The feature update deferral in the ring stops mattering for that device. Intune takes the feature update deferral settings in the ring and sets them aside, and the policy controls which version is offered and when the ring keeps handling everything else. Quality deferrals, deadlines, restarts, active hours. That split is actually clean. The ring governs the monthly rhythm. The feature update policy governs the yearly decision. Two controls. Two jobs. No overlap, but people miss it. They set a feature deferral of one hundred and eighty days in the ring, then assign a feature update policy with a start date next month. Then they wonder why the one hundred and eighty days is being ignored. It's not a bug. The policy replaced it. If you want a delay, you build it into the policy's rollout settings, not the ring. And that brings up the rollout options. First, the start date. You tell the policy when the version becomes available to the group. Before that date, nothing is offered on that date. Devices become eligible and their normal check ins pick it up. Second, gradual rollout instead of making every device eligible on the same day. You can spread it out. You pick an end date and a gap in days between groups, and Intune staggers eligibility across the window. A thousand devices don't all download several gigabytes on the same Tuesday. Your network and your help desk will notice the difference. Third group based waves rather than one big assignment, you create separate policies for separate groups, each with its own start date. It gets the version first pilot follows two weeks later. Broad follows a month after that. That's the same ring logic we built earlier. Applied to the yearly decision instead of the monthly one. Same groups. Same order. Longer time scale. It works because the pin keeps each group on a known target while the others catch up. There's one more thing to say about how a pinned device behaves. If a device is on an older version than the policy names, it moves up to the pinned one. If it's already on the pinned version, nothing changes. And if it's on a newer version than the PIN, the device doesn't roll back. The policy can hold a device in place. It can't undo a feature update that already landed, so the order matters. Assign the policy before the update arrives, not after. Now a PIN feels like safety. You chose the version. Nothing surprises you, but a pin is a decision and every decision has an expiry date. Windows versions don't live forever. Microsoft stopped servicing each one on a fixed schedule. The version you pin today has a last day of security fixes, and that day is already on a calendar somewhere. PIN a version and forget it, and you've created a device that's perfectly controlled and slowly going unprotected. Which means the real question isn't how to pin, it's how long the pin is allowed to hold windows life cycle and the support calendar. Every windows version has a birth date and a death date. The second one is the one people forget. Start with windows eleven. Microsoft ships one feature update a year in the second half of the calendar year, each release gets its own servicing clock. That clock is where your PIN comes from and where it runs out. Windows ten is different. It's the older model, and it's on its way out. The last feature release, version twenty two H2, has a fixed end date for free security updates, and after that date, the whole product line stops getting them anything. Still, running windows ten past that point is running without a safety net unless you pay for extended security updates. So when you pin a version, you're also choosing a deadline for yourself. Now, how long does each version actually last? It depends on the edition. Enterprise and education editions get thirty six months of servicing for the fall release. Thirty six months. Three full years of monthly security fixes. Home and pro get twenty four months and the spring releases where they exist get less edition decides the calendar, so check which one your devices actually run before you trust a date. You remember that gap matters more than it looks. A mixed estate, some enterprise, and some pro doesn't share one expiry. The pro devices on the same version run out a full year earlier. Same pin, different cliff. So what happens at the cliff? Nothing dramatic. That's the problem. The device keeps booting, apps keep opening. The user notices nothing but the monthly quality updates stop arriving for that version, and every flaw found afterward stays open forever. The machine becomes a slowly aging target that still looks healthy on a dashboard, and windows won't leave a device alone, either. Once a version reaches end of servicing, Windows Update can push the device toward a newer one, even against your wishes. Unless a policy holds it in place, a PIN can't hold a version past its expiry. At that point, you've lost the argument with the calendar, and you're either updating on your schedule or on Microsoft's. This is why feature updates can't be a project. A project has a start, a budget, and a finish. Someone stands it up, a team runs it for six months, and then it ends. Then twelve months later, the next version arrives and nobody remembers how the last one went. The life cycle doesn't work like that. It's a yearly rhythm. One version comes out each year. One version expires each year. There's always a version you're leaving and a version you're heading toward. So the planning looks like a loop. When a new release ships, your test ring takes it early. Using that release preview window we talked about, pilot follows within a couple of months, broad moves in the following half year, and by the time the version you're on is eighteen months from its end, the next one should already be proven. That timing gives you slack. Slack is what saves you when an app vendor is late with a compatibility fix, or a hardware model needs a driver that doesn't exist yet, teams that treat it as a project get the opposite. They discover the end date when it's six weeks away, and they push a feature update to the whole estate in a panic. With no pilot and no evidence. The same decision made once calmly, a year early or made under pressure. Now notice what we've built so far rings, deadlines, feature policies, a calendar. Every piece works. Every piece is something you design, tune, and review. And you do it again every month and every year. Some organizations want that control. Others want somebody else to carry it. That's the point where Microsoft's answer shows up. It's a managed service built on everything you just learned, and it's called auto patch. What Windows Auto Patch actually is auto patch is not a new update engine. That's the first thing to get straight. There's no second system hiding behind it. Auto patch is a managed service that sits on top of the two things you already know Intune for policy and Windows Update for business, for delivery. Same planes, same engine. A different person doing the driving. Think about what you've built so far in this video. Rings, deferrals, deadlines, a feature update policy, a calendar. Every one of those is a decision and everyone needs someone to create it, check it and keep it current. Auto patch takes a large share of that work and moves it to Microsoft. So what exactly does Microsoft take over? Start with ring creation. When a device joins the service, auto patch doesn't ask you to design the stages. It builds them. It creates the groups writes the update ring policies and assigns them. You don't open the update rings page and start from a blank screen. The rings are already there with numbers Microsoft chose next monitoring. This is the part that quietly matters most. Auto patch watches how each update behaves as it moves through the stages. Installs that succeed. Installs that fail. Devices that never report back. It reads that signal on your behalf around the clock. Instead of waiting for someone to open a dashboard on Thursday and then remediation when something goes wrong, the service doesn't only notice it acts. It can pause a rollout before the next stage receives the update. It can flag devices that are stuck, and in some cases, it nudges them toward a fix. We'll go deep on that machinery later. Ring creation monitoring, remediation. That's the handover. Microsoft runs the loop that, in a self-managed setup, belongs to a person with a spare calendar slot. But here's where teams get the wrong idea. Auto patch doesn't take the decisions. It takes the execution of decisions. What stays with you is the part that was always yours. Which devices are in the service at all, which ones you pull out and why? How much risk the business will carry for a given group. What happens when an update breaks a line of business app on a Tuesday afternoon? 00:34:17 Speaker: Policy decisions stay with you. Exclusions stay with you and accountability stays with you. That last one is worth sitting on for a second. If a patch lands late on an executive's laptop and that machine is breached, nobody will say Microsoft's service was supposed to handle it. The audit trail ends at your organization. Auto patch is a delegate, not an owner. You handed the work. You don't hand it the responsibility. So the right mental model is a contract with a clear split. Microsoft owns the mechanics. You own the outcome. Now a word on what it takes to use it briefly, because licensing details change, and you should always confirm them against Microsoft's current documentation. At a high level, auto patch is included with certain windows licensing. The enterprise grade plans like Windows Enterprise E3 and E5, and the Microsoft three hundred sixty five bundles that contain them. It's not a separate product you buy on top for those plans. Some business tier plans have since been added to, so the exact list is worth checking before you plan around it. Prerequisites sit one level below the license you need Intune as your management platform. You need devices joined to Microsoft Android either directly or as hybrid joined. You need supported windows versions and the right Windows Update policy settings left to auto patch rather than set by hand. That's the shape of it. A license that includes the service, a management platform that can host it. Devices that enter ID recognizes. Notice the pattern though? Everything on that list is about the device, not the service. Microsoft is ready the moment you turn it on. Whether your estate is ready is a different question. And that's the part nobody gets to skip because Autopatch can't manage a device it doesn't accept before a single update flows through those managed rings, each machine has to pass a check, and plenty of them fail it for reasons nobody wrote down. So the real question isn't what Autopatch does once it's running, it's what a device needs to look like before it's allowed in. Autopatch prerequisites and device registration. Autopatch runs a readiness check before it accepts anything. Not a formality. A real gate with real failures. It lives in the Intune Admin Center under Tenant administration, then windows auto patch. Before you register a single device, the service looks at your tenant and asks a short list of questions, and it asks the same questions about each device afterwards. Start with management. The device has to be enrolled in Intune, not planned for enrollment enrolled. Checking in, holding policy, then identity. The device has to be joined to Microsoft entry ID directly joined works hybrid joined. Works two. If the machine is also tied to your on premises directory and registered in the cloud, a device that only knows the old domain with no entry identity doesn't exist as far as the service is concerned. Then the windows version Auto patch only manages versions that are still in support and only on supported editions. A machine stuck on a retired version fails this check on the spot, which tells you something. The service won't pretend to protect a device that Microsoft itself has stopped patching. Three. Checks management identity version. Now there's a wrinkle for estates that still use Configuration Manager. Co-Management is where a lot of teams hit the wall in a co-managed device. Both Configuration Manager and Intune talk to the same machine, and each one can claim ownership of different jobs, which Microsoft calls workloads for auto patch one workload matters most Windows Update policies that workload has to point at Intune. If Configuration Manager still holds it, the client takes its update rules from there, and Auto Patch has no way to enforce anything. The slider has to move over along with it. The office click to run and device configuration workloads need to sit on the Intune side as well, or the service flags the device as not ready. And this is a decision, not a toggle. Moving that workload means every update rule on those machines now comes from the cloud. Your existing deployment rules stop applying. Plan the move, test it on a small group, then widen it. Okay, the device passes the checks. How does it actually get in? Through a registration group? When you set up the service, auto patch creates a Microsoft entry group for registration. Its job is simple. Any device that lands in that group gets picked up by the service, the service reads. The membership validates each device against the checks we just covered, and then registers the ones that pass. That means entry is a group operation. You don't register machines one at a time in a wizard. You add them to the group, wait for the service to sweep and watch the results, and you control membership however you like. A dynamic rule that catches all corporate windows devices. A static list for a first small batch either works. Starting small is smarter because the first sweep will teach you things about your estate that you didn't know. Which brings us to the blockers. Most failures come from two places. The first is conflicting policy. A device already holds an update ring policy you built yourself, or a group policy setting or a registry value pointing the client at a different update source. Auto patch wants to be the only voice on update behavior. When two voices disagree. The service marks the device as having a conflict, and it stays outside until someone clears the old setting. The second is unsupported configuration. A device with an addition. The service doesn't cover a machine that hasn't checked in with Intune in weeks and looks inactive. A device with a missing or mismatched identity. So the entry record and the Intune record don't agree on who it is. Here's what makes these painful. They're quiet. Nobody gets an alert saying a laptop was skipped. The device just sits there outside the service and looks fine. In every other dashboard. You only find it if you go and read the registration results. So read them every time you add a batch. The devices that pass don't wait around. They are sorted into the rings auto patch designed for you and you didn't draw a single one of them. Auto patch default rings test first fast broad auto patch gives you four groups. Test first fast broad. Same staged idea we built by hand earlier, but with Microsoft's names and Microsoft's numbers test is the smallest it's meant for it, and its job is to catch the obvious break before anyone else sees the update. First is a small slice of real users. Fast is a bigger slice where the update meets most of your hardware and app mix, and broad is everyone else. The bulk of the estate last in line with the most evidence behind it. Notice what's missing. There's no group for kiosks or factory machines, no group for devices that need a negotiated window. The service gives you four stages and every device lands in one of them. So how does a device land in one? Auto patch decides when the registration sweep accepts a machine, the service assigns it to a group on its own. You can add devices to test by hand if you want a specific person there. Everything else gets placed by the service and it places them by percentage. Each group has a target share of the estate. Test is small. A few devices or about one percent. First is around ten percent faster, around twenty, and broad takes the rest. Those targets matter more than they look. They set the size of every stage and size decides signal quality, which we already know. A first group that's too thin can miss a problem that only shows up on one laptop model. here's the part that catches teams out. The service keeps those shares balanced as devices come and go. Register a few hundred new machines, and some will shift between groups to restore the ratios. A device you thought was in broad can end up in fast after the next sweep. If someone on your team needs to know exactly where a machine sits. Check the group membership. Don't remember it now. Behavior. What do these groups actually do differently? The difference is time. Each group has its own deferral and deadline and both grow as you move down the line. Test takes the update with no deferral at all. It sees quality updates the moment they're offered with a very short deadline and the restart is forced fast. That's intentional. Test exists to break first. First waits a few days fast. Waits a few more broad waits. Longest close to a week, and gets a longer deadline, plus a grace period so users have room to restart on their own terms. I won't give you exact numbers for every setting because Microsoft adjusts them over time. Check the current documentation before you quote a figure to your security team, but the shape stays stable, short and sharp at the start, patient and gentle at the end. Feature updates follow the same staggering just across weeks instead of days with the service managing the version and the timing for each group. So where does this model fit? It fits an organization that has a typical office estate, a small IT team, and no appetite for building ring logic from scratch. For those teams, the defaults are better than what they'd have drawn themselves sensible stages, sensible delays, no blank page. And it fits the second job to a team that has never run staged rollouts. Gets one on day one. That alone closes a real gap, but the defaults frustrate people in a few predictable places. One is control over membership. You can't say these two hundred clinical workstations should always be last. The service balances, percentages, and your exceptions fight that logic. Another is speed. Some security teams look at the broad deadline and see a week of exposure. They never approved. They didn't pick that number. Microsoft did. And a third is trust admins who like to know exactly why a device updated when it did sometimes feel a step removed from their own estate. The reasoning layer still exists. It just lives in policies you didn't write. None of that makes the model wrong. It makes it a default and defaults aren't walls. Autopatch lets you adjust a good deal of this behavior from deferrals to extra rings to the exclusion of specific devices, but only inside guardrails the service sets for itself customizing auto patch without breaking it. So what can you actually change? More than people expect? Less than people want? The main lever is the custom update ring. Inside the auto patch release settings, you create your own rings. Next to the four defaults. You pick the deferral, the deadline, the grace period, and which devices belong to it. A ring for the clinical workstations, a ring for the factory floor. A ring that's always last no matter what the percentages say. That fixes the biggest frustration from the last section. The service stops balancing those devices because you've moved them out of the managed groups and into one you control. You can also adjust the behavior of the defaults, deferrals, deadlines, and restart settings for the standard groups can be tuned within limits. Some values have a floor or a ceiling. Some settings you can't touch at all because the service needs them to do its monitoring. And that's the line. Auto patch lets you change timing. It doesn't let you remove the parts that make the service work, the pause logic, the health signals, the group structure underneath those stay. Now the trouble starts somewhere else. It starts with the policies you already have. In most states. Intune isn't empty. When auto patch arrives, there's an update ring someone built two years ago. A feature update policy, maybe a group policy object that still sets the update source. Each one is a voice telling windows what to do. An auto patch brings its own voice. When two policies set the same value on the same device, Intune can't pick a winner. It reports a conflict, and on the device, a conflict doesn't mean the stricter policy wins. It means the setting often fails to apply at all. The machine falls back to something you never chose. What typically happens is quiet. A device is registered, it sits in fast, and everyone assumes fast. Rules are running, but your old ring is still assigned to the same group, and the deferral number on the laptop is the old one. The dashboard says fast. The behavior says something else. So you go looking in the right place in Intune, open the device and read its configuration status. Look for conflict and error states on update settings. And that's where the second voice shows up. Then you fix it by removing one of the voices, almost never by adding a third. Now sometimes the right move is removing the device itself. Auto patch lets you exclude a device from the service. The device stays in Intune, it keeps its apps and its compliance rules. It just stops receiving auto patches, update policies and stops being counted in its reports. When does that make sense? When a machine genuinely can't follow the model, a lab PC pinned to an old build for a test rig? A device running software that breaks on every feature? Update a system under a vendor contract that dictates the patch schedule. But exclusion has a cost, and teams forget it. An excluded device is an unmanaged risk. Nobody watches it. Nobody pauses a rollout for it. It needs an owner, a reason written down and a review date. Or it becomes the machine that's never patched because everyone assumed someone else had it. Treat every exclusion as a loan, not a gift. Which leads to the one rule that holds all of this together one owner per setting. For every update setting on a device, exactly one system is allowed to define it. Auto patch owns the rings. It creates your own policies. Own the rings you create. Group policy owns nothing. Once you've moved to the cloud. If you can't say which system owns a given setting, you already have a conflict. You just haven't seen it yet. Right? That ownership down a simple table does it setting owner reason. it takes an hour and it ends most of the arguments before they start. Once the settings have owners, the delivery side is predictable, and that's when you can see what auto patch is really for. It isn't the rings you could build rings yourself. The real product is the watching what the service does while an update moves through those stages and what it does when the signal turns bad, release management pauses, resumes, and safeguards. Here's what the service is actually doing while you sleep. Every update that moves through the rings produces data, installs that finish, installs that fail, devices that restart and come back healthy, and devices that restart and never check in again. Auto patch reads all of it ring by ring, and compares it against what it expects to see. When the numbers turn bad, it acts. It pauses the update for that ring and for any ring that hasn't received it yet. Devices already in the stage keep what they have. Everyone behind them waits. That's the whole trick of stage delivery finally doing its job test breaks. First, the signal reaches the service and the update stops before it ever reaches broad. The ring you didn't draw became the ring that saved you. Now what triggers a pause? Microsoft doesn't publish one clean threshold, and it adjusts the logic over time, but the inputs are familiar. Failure rates on install devices stuck in a pending state, widespread reports of the same problem across the windows ecosystem. Not only your tenant. A bad update gets noticed by a lot of people at once, and the service listens to that wider signal as well as yours. And a pause isn't a rollback. Nothing is removed. The service simply stops offering the update to the next group until someone decides it's safe again. There's a second kind of stop, and it happens before Autopatch gets involved at all. Windows itself can refuse to install an update on a specific device. These are called safeguard holds. Microsoft finds that a certain driver, a certain app, or a certain hardware combination breaks on a new update. So it flags that combination and any device matching it simply isn't offered the update. The device shows no error, no failure. It just sits on the older build and the update never arrives. That's a compatibility block, and it's a good thing. The hold protects the machine from a known problem, but it creates a trap. In your reporting, a held device looks like a device that's behind, and an admin who doesn't know about holds will assume the policy failed. It didn't. Windows made a decision on the device's behalf, so when a handful of machines refuse an update while the rest of the ring takes it, check the hold before you check the policy. Look at the device's hardware and drivers first. The hold usually lifts on its own once Microsoft or the vendor ships a fix. One warning here, some teams find a way to bypass safeguard holds through a policy that disables them. Don't. That setting exists for test machines on a production device. It turns a protection into a gamble. Now, the service isn't the only one who can pull the break. You can too. In the auto patch release settings, an administrator can pause an update ring by hand, pick the ring, pick the update type, and choose how long the pause holds for a fixed number of days, and then it expires unless you extend it. Resume works the other way whenever you decide the evidence looks clean. Why would you do this when the service already watches? Because your signal isn't Microsoft's signal. Maybe a line of business app broke on three pilot machines, and none of that shows up in global telemetry. Maybe your security team wants a freeze before a major launch. Maybe a vendor just warned you about a compatibility issue. The service sees patterns, you see your business, and that gap is the reason the manual control exists. Use it when the reason is specific and write the reason down. A pause with no note attached becomes a mystery. Six weeks later when someone asks why Brad hasn't moved. Which raises the question nobody asks until the audit. What does a pause do to your compliance numbers? It makes them look worse. Devices in a paused ring don't receive the update, so they stay behind the target version. Reports show them as not up to date or not yet offered, and the percentage patched drops while the pause is active. That's honest, but it needs context. A pause is a decision, so it belongs in the story you tell. If someone asks why eighty percent of the estate is behind, the ring is paused for a known issue approved on this date. Expiring on that date is a defensible answer. We don't know isn't, and the dashboard won't explain that for you. Somebody has to. But a pause only covers one kind of problem. It handles the update that's too risky to send. Some updates are the opposite. They're too dangerous to wait for expedited quality updates for zero day threats. Normal ring delivery runs on a schedule. An expedited update ignores it. Think about what a ring does. It waits. Seven days of deferral, a couple of days of deadline, a grace period on top. That patience is the whole point of staging, but patience assumes the threat is also patient, and sometimes it isn't. A flaw is already being used in the wild, and Microsoft ships a fix outside the usual cycle. Waiting for broad to reach its turn is a choice to stay exposed for two weeks, so Intune gives you a second path. It's called an expedited quality update. Here's what's different. A normal update waits for the device to check in, evaluate its ring, honor the deferral, and then offer the update when its turn comes. An expedited update skips most of that. You pick one specific update, and Intune tells devices to go and get it. Now the deferral doesn't apply. The usual deadline logic doesn't apply either. It's also narrower than people think. You aren't pushing a general patch cycle. You're naming one quality update by its release date, and the policy targets only that one, and it's still pulled, not pushed. The device has to hear about the instruction, so it needs to be online and reaching Intune. We covered that client side model earlier and expedite doesn't change it. It changes how urgently the client acts on what it hears. Now how do you create one in the Intune admin center, go to devices, then windows, then quality updates create a new expedite policy. You give it a name and then you choose the quality update to expedite. Intune lists the recent releases for you, so you pick the one that carries the fix. Next comes the setting that matters most the restart you choose how many days until the restart is forced. Zero means the device restarts as soon as the install is done with very little warning. A larger number gives users time to save their work and restart on their own first. After that, the forced restart lands. Then you assign the policy to a group and that's the whole policy. One update, one restart. Rule, one target, one detail catches people and expedite policy should be a temporary object. Once the fix has landed everywhere you remove it or let it age out. Leave old expedite policies assigned and you've left a standing instruction nobody remembers. Which brings us to the restart because that's where the business feels it. A forced restart is the cost of speed. The update can install quietly in the background, but the patch isn't active until the machine reboots, so the policy has to choose a moment and the user doesn't get a vote. For most laptops, that's an interruption, a document unsaved, a call, dropped, a presentation lost. A few people will be angry and a few will lose real work. 00:51:32 Speaker: For other devices, it's much worse. A restart on a point of sale terminal during trading hours is lost revenue. A restart on a machine controlling a production line can stop the line. A restart on a clinical workstation can pull a screen away from a nurse at the wrong time. That's why expedite is a blunt tool. It buys protection by spending user trust and it spends it quickly. So when do you use it? Use it when the facts say the risk is already real. Active exploitation confirmed a flaw that's reachable from the internet or needs no user action. A weakness in something your estate actually runs. In those cases, the cost of delay is higher than the cost of disruption, except the normal schedule. When the facts say otherwise. A vulnerability that needs physical access, a flaw with no known exploit in a feature, you've disabled a patch that's important but not urgent. Your rings were built for exactly this, and Test and Pilot will tell you something useful before broad ever sees it. There's a middle path as well. You can expedite for just the early rings, accelerate the evidence and let the rest follow their normal timing. But notice what the choice depends on. It isn't a technical skill. It's a judgment about severity, exposure, and business tolerance made with incomplete information. And that judgment has to happen fast. The update can reach a device in hours if the decision to send it takes a week of meetings. The speed of the tool means nothing. So the real design question isn't the policy, it's who decides and how quickly they can. An out-of-band response playbook. The playbook starts before the alert does. When the next out-of-band fix lands, nobody should be inventing the process. They should be running it. So here's what it looks like in order. First question how bad is it? Severity comes from the advisory itself. Microsoft publishes a rating and a score for every flaw, but the score is only a starting point because it describes the flaw in general, not in your estate. Read the details. Does it need a user to click something? Does it need to be on the same network, or can an attacker reach it from the internet with no help at all? Second question is anyone using it? Exploitability is the line between important and now the advisory says whether the flaw is publicly known and whether attacks have been seen. Active exploitation changes the clock. Everything before that point is planning. Everything after is response. Third question who in your estate is exposed? This one is yours alone, and it's the one teams skip. A flaw in a feature you've turned off doesn't touch you. A flaw in a service that only runs on servers doesn't touch laptops. So you check which devices run the affected component, which ones face the internet, which ones hold something an attacker would want. Severity Exploitability exposure. Three questions, and the answer decides whether this is an expedite or a normal ring. Now comes the part that actually costs time. Who says yes? In most organizations, nobody knows. The security team wants it. The endpoint team owns the tool, the business owns the disruption. And so a decision that should take an hour becomes a thread with nine people on it. Fix that. Now in writing, name one person who can approve an expedite and one backup. Give them authority to act first and report after. For a confirmed, actively exploited flaw. The approval should take minutes, not days. Then agree on a ceiling, maybe a decision within two hours of confirmation and the policy live within for whatever the numbers are, someone has to own them. A fast tool with a slow approval is just a slow tool. Next, the target you have two options. AIM the expedite at one ring or at everything. Aiming at one ring is the careful path. Send it to Test and Pilot first and let the install data confirm it doesn't break anything. That can cost you a day and sometimes less if the flaw is serious but not yet being used against you. That day is a fair price for evidence. Aiming at the whole estate is the blunt path. You take it when exploitation is confirmed, and when the exposed devices sit in every ring. Waiting for evidence now costs more than the risk of a bad patch. There's a hybrid, and it's often right. Expedite the highest exposure devices immediately. Internet facing machines, privileged admin workstations, anything that can be reached, let the rest follow a shortened schedule. Whatever you choose, scope it. Deliberately. Assign the policy to a group you picked on purpose, not one you inherited. And then comes the step that decides how people feel about all of this. Tell them a forced restart is a rule only if it arrives with warning. So before the policy goes live, send a message. Short plane specific what's happening, why it can't wait and when the restart will come, tell them to save their work. Tell them who to call. If something goes wrong, use more than one channel email gets ignored. Add a team's post and a note to the service desk so they aren't surprised by the calls and set the restart delay in the policy to match what you promised. If you said within a day, don't configure zero. Do that and an emergency feels like a managed event. Skip it. And every urgent patch teaches people to distrust the next one that covers the operating system. The one thing every device runs and the first place a fix usually lands, but there's a layer beneath it that doesn't follow the same rules. Software that talks directly to the hardware code that updates on its own path with its own risks. Drivers, driver and firmware updates. Drivers don't announce themselves. A quality update has a name, a date, and a release note. A driver update shows up inside Windows Update attached to a hardware ID, and most people never see it happen. Then a touchpad stops working. WiFi drops after sleep. A docking station that was fine on Monday is confused on Wednesday, and nobody connects it to an update because nobody remembers one. Here's how drivers reach a device. Windows update carries them. Hardware vendors publish drivers to Microsoft, Microsoft hosts them, and devices check for them the same way they check for everything else. The same client side model we covered earlier still applies the device asks, evaluates and installs, but drivers don't follow your rings. By default, an update ring has a setting that decides whether driver updates come along with quality updates. Leave it on and drivers arrive on whatever schedule windows decides, turn it off and windows Updates stops offering them. That's a blunt choice. Either everything flows or nothing does. Intune adds a better control. It's called a driver update policy and you'll find it under devices windows, then driver updates instead of an on or off switch. It gives you a catalog of drivers that Windows Update has found for your devices, and a decision for each one. The decisions come in three shapes approve, review, and pause. Approve means the driver goes out. You pick a date and eligible devices in the assigned group get it? Review means the driver sits in a waiting state. It's been found. It applies to your estate, but nobody has said yes. Pause means a driver that was approved gets held back because something went wrong. That middle state matters more than the other two. It turns driver updates from something that happens to you into something you can look at first. Now the policy itself has two modes, and this is where the real decision lives. In manual mode, nothing is approved until a person approves it. Every new driver lands in the review list. You read it, check the hardware it applies to, and choose a date. It's slow and it's safe. A bad driver never reaches a device unless someone let it through in automatic mode. Intune approves recommended drivers on its own. After a deferral you set, you might say, wait ten days after the driver is published, then deploy. Nobody reads each one. The policy just runs. Each mode has a cost. Manual approval costs attention. A busy estate sees dozens of driver updates a month, and someone has to look at each. That someone gets tired. Then the review list grows. Drivers sit unapproved for months and devices drift behind on fixes. The vendor shipped for good reasons. Slow can turn into stale automatic approval cost control. A driver with a flaw reaches the group on schedule, and the only protection is the deferral you picked and the pause button you remember to press. The risk isn't that automatic is reckless. It's that failure becomes invisible until a ticket arrives. So most teams end up splitting it automatic for the early rings with a deferral. So the test group acts as the canary manual for broad and critical devices, where a bad driver is expensive and a few weeks of delay is acceptable. Same ring logic you've already built applied to a quieter kind of update. And one more habit helps treat a driver that fixes a known problem differently from a routine one. If a vendor driver closes a security flaw, review it fast. If it adds a minor feature, let it wait. Now, firmware firmware is the code that lives below the operating system. The Bios or uEFI on a laptop, the controller inside a dock. The microcode on a storage device. Some of it arrives through Windows Update as a driver package, and a few vendors publish. This way, when it does, the same, driver policies handle it, but much of it doesn't. Many manufacturers ship firmware through their own tools a vendors update utility, a management console, a package you deploy yourself through Intune. That's a separate path with separate timing, separate testing, and a separate owner. Windows update has no idea it exists and your update rings. Don't touch it. That separation causes a gap in most estates. The operating system is patched on a clear schedule, and the firmware underneath quietly ages because it falls between two teams. Endpoint owns windows. Nobody owns the Bios worth fixing and worth deciding who holds it, but firmware and drivers share one trait when they go wrong, they don't fail loudly. A driver that misbehaves doesn't produce a clear error. It produces a laptop that's a little slower, a camera that's a little flaky. A restart that doesn't quite finish. Those are the quiet failures, and they're the ones that waste the most time because nobody knows where to look. So it's time to look at failure directly. Where updates fail, the failure taxonomy updates don't fail in one way. They fail in stages, and each stage has a different cause, a different symptom, and a different owner. Start with the simplest map an update has to download, then it has to install. Then the device has to restart three steps and a device can die at any one of them. Download failures come first. The device knows an update exists, but the bytes never arrive. Maybe the network drops mid-transfer. Maybe a proxy blocks the Microsoft endpoints. Maybe the device sleeps before the file finishes. The result looks like a laptop that's simply behind with no error. Anyone would notice. Install failures are louder, the files arrive, windows starts applying them, and something refuses. You get an error code, a rollback, and a machine that quietly puts itself back to where it began. The update tried the device, undid it, then restart failures. These are the sneakiest. The install finished, but the patch isn't active until the machine reboots. A user postpones for two weeks. A device never sits idle long enough. A kiosk never shuts down at all. The update is sitting there, fully installed, doing nothing. Download, install, restart. Now go one level deeper because most install failures come from the device itself, not the update disk space is the boring champion. A feature update needs many gigabytes of free room to stage files and keep a rollback copy. A laptop with a nearly full drive fails every time, and it fails the same way every time. No policy fixes that. Only space does. Next the servicing stack. This is the part of windows that installs updates. If it's outdated or broken, it can't apply the very update that would repair it. A device can get stuck in that loop for months, trying and failing on the same monthly patch. And then the component store windows keeps a store of system files it uses to build every update. When that store is corrupt, installs fail with errors that point nowhere useful. The machine looks healthy, apps run, but it can't take a patch. Those three share a trait. They're local and they're specific to one machine. You find them by looking at that device, not at your policy. Now, the other kind of failure, the one that has no error at all. Policy conflicts block updates silently. We touched on this with Autopatch, but it reaches wider than that. An old group policy points the client at a server that no longer exists. A registry value pins a version nobody remembers. Two. Intune policies set different deferrals and the device lands on neither. The update never fails because it never even starts. This is the worst category for one reason. Nothing breaks. A device that fails to install shows a failure. A device that was never told to install shows nothing and sits behind for months, while every dashboard calls it not yet offered. So here's the better way to sort all of this. Ask where the failure lives. Some failures live in the reasoning layer. That's the layer where policy rings. Deferrals and deadlines decide what a device should do. When reasoning fails, the device never gets the right instruction. A conflict, a wrong assignment, a missing group, a deadline set too far out. The device isn't broken. The decision was wrong or never reached it. Other failures live in the delivery layer. The device knows exactly what to do and it can't. Disk full servicing stack broken. Network blocked. Restart postponed. The instruction was perfect and the machine couldn't carry it out. That split changes. Who fixes what reasoning failures belong to whoever owns policy. You fix them once in one place and they clear across hundreds of devices. Delivery failures belong to whoever owns the endpoint. You fix them machine by machine, or you automate the repair, mix them up, and you waste weeks. A team sees a hundred devices behind, assumes each one is broken, and starts touching laptops. Meanwhile, one bad assignment was the real cause and the single change would have cleared the whole list. So before any fix, you need to know which layer you're in. And you can't know that by guessing. You can't know it from a user complaint or a hunch or a ticket that says my update didn't work. You need to see it. Which device has failed at which step, with which error in which ring. That means reporting comes first. Reporting in Intune and Auto Patch. Intune already has the reports. Most teams just never open the right one. Start with windows quality updates in the Intune admin center, go to reports, then Windows Updates. You'll find a tab for quality updates and another for feature updates. They answer different questions. The quality report shows where each device stands against the latest monthly release, which devices took it, which ones are still working, which ones failed, and with what error code. You can filter by ring, by group, by operating system version. That filter is the one you'll use most because a number for the whole estate hides everything useful. The feature update report works the same way, but the unit is the version. How many devices run the version you targeted? How many are still on the old one? How many are held back by a safeguard? If you built a feature update policy, this is where you check whether the PIN actually holds. Both reports also show per device detail. Click into one machine and you see the update. State the last check in and the error if there is one. That detail view is where reporting turns into troubleshooting. We'll use it properly in a few sections. Now the auto patch side auto patch has its own set of reports under reports, then Windows Auto Patch. They aren't a copy of the Intune ones. They are organized around the service. Which devices are registered, which ones are ready, how each ring is doing on the current update. The device report answers the entry question. First of everything you try to register what got in and what didn't. Failed registrations show a reason. That's the list you read after every batch. Like we said earlier, the ring view is the one that matters during a release. It shows each group tests through broad with its own progress on the current update. You can see test finished days ago first at ninety percent fast just starting. That's the staged rollout made visible. And if the service paused a ring, it shows up here with the reason attached. So what do the statuses actually mean for categories? Do most of the work up to date in progress? Not ready. Has issues up to date is the easy one. The device runs the latest release for its ring and nothing is pending in progress means the update is on its way. Downloading, installing, waiting for a restart. Every device passes through this state, so a few of them are always here. The question is how long not ready is the confusing one. It doesn't mean broken. It means the device can't be managed by the service right now. A failed readiness check, a policy conflict, a missing prerequisite. Those are the quiet blockers from earlier surfaced as a status treat each one as a reasoning layer problem until proven otherwise. Has issues means something went wrong on the device. An install error, a stuck restart. No check in for too long. That's your delivery layer list for buckets and each one points to a different owner. Now what does a healthy dashboard look like? Mostly green test and first close to fully updated fast and broad climbing on schedule. A small tale of in-progress devices and a short list of has issues that gets shorter each week. Registration failures near zero. But look closer because a healthy dashboard hides things. It hides devices that aren't in the report at all. Anything outside the service excluded or never registered doesn't count against your percentage. The number looks great because the problem machines left the denominator. It hides the age of the data. A device that hasn't checked in for a month may still carry its last known state up to date, according to a laptop that's been in a drawer and it hides pauses. A ring on hold can look calm because nothing is failing. Nothing is moving either. Percentages hide spread to ninety five percent. Patched. Sounds fine until the missing five percent are all executives or all servers or all the machines that matter most. So the dashboard is accurate and still incomplete. It tells you the state of devices, but the person asking you about patching isn't asking about devices. They're asking whether the business is exposed and for how long. That's a different question, and it needs a different number. Measuring patch compliance as a business metric percentage patched is the number everyone quotes. Ninety four percent. It sounds like a grade and it's a snapshot. A single frozen moment that says how many devices are done, not how long the others were open to attack. There's a second number and it tells the better story. Time to patch. Time to patch is the gap between the day Microsoft releases an update and the day a device actually runs it. One device, one gap. Add them up across the estate and you get a distribution instead of a score. The median. The slowest ten percent. The worst case. Here's why that matters. Two estates can both show ninety four percent today. In the first, most devices patched within three days, and a small tail is stuck in the second. Everything took three weeks and the last stragglers just crossed the line this morning. Same percentage. Completely different risk. The percentage can't see that difference. Time can. So when someone upstairs asks about patching, don't hand them a device count. They don't think in devices. They think in exposure. Exposure window is the better frame. How many days after a fix existed was a given group of machines still vulnerable? That's what an attacker cares about. That's what an auditor eventually asks. And that's something a board member understands without a glossary. Say it in their language. For the March release, our corporate laptops were exposed for an average of six days. Critical systems nine. That's a sentence a leader can act on. Compare it with. We're at ninety four percent. What do you do with that? Nothing. It invites a shrug, and a window can be argued with in a useful way. If six days feels too long, the conversation turns to deferrals, deadlines, and the restart rules we built earlier. The number points straight at the lever that moves it. Now you need targets, and one target for everyone is the wrong shape. Set them by ring and by risk. Group test should reach full coverage within a day or two because that's what test is for. Pilot a few days after that, broad can have a longer window because broad has the most evidence behind it. A single number across all four would punish the early rings for being early, and excuse the late ones for being late. Then lay a risk on top internet facing machines, privileged admin workstations, devices holding sensitive data. Those groups deserve a tighter window than the average laptop, even if they sit in the same ring and devices with a good reason to wait, like the clinical or factory systems get their own agreed target written down. So the delay is a decision and not a surprise. 01:08:47 Speaker: Keep the list short. Three or four targets people can remember B12 nobody checks and track misses. Honestly, a device that blows past its target isn't a failure of the report. It's the start of a question which we'll get to. Now, where does the trend data come from? iTunes built in reports show the present. They're good at telling you where things stand this week. Looking back across months takes more. That's where Log Analytics comes in. Windows update for business reports can send update data to a log Analytics workspace, which stores it over time. The workspace keeps records of which devices were on, which build, which updates they were offered, and how each deployment ended. Then you query it with that history, you can draw the line instead of the dot median time to patch month over month, whether the slowest devices are getting faster or drifting worse, which ring consistently misses its target. Where the last quarter's changed, the broad deadline actually shortened the window or just moved the complaints. That last one is the real value. A change you can't measure is an opinion. A change you can measure is evidence, and evidence survives the next budget meeting. One caution the workspace costs money to run and data collection takes setup. Start with a narrow set of questions you actually plan to ask and build outward. A dashboard nobody reads is the same as no dashboard, so you now have the right numbers, windows of exposure targets by ring and risk, a trend you can defend. And that's exactly when the uncomfortable part begins, because a good measurement doesn't fix anything. It just shows you clearly which devices are late. Troubleshooting playbook from reporter root cause. Start with the device. Not the policy, not the ring. The one machine that's late. Every failed update leaves a number behind an error code, usually a hex value that starts with zero x eight. It looks like noise, but it isn't. Search the code and you'll often land on a single cause. Not enough disk space, a corrupt download, a servicing stack that can't apply the patch. The code tells you which stage failed, and that tells you which layer you're in. Where do you find it? In Intune, open the device and look at the update. State. The quality update report carries the error for that machine on the device itself. Open settings, then Windows Update, then update history. Failed installs show up there with the same code, plus the name of the update that refused. Read the history as a pattern, not a single line. One failure is an event. The same failure on the same update three months running is a diagnosis. A device that fails on one specific patch and takes every other one points to that patch. A device that fails on everything points to the machine. Now. Widen the view. Intune keeps a device timeline and it's the part most admins skip. Open the device, find the timeline and you see what happened in order. Policy received. Update offered. Download started. Restart pending. Each event has a time next to it. That order matters because a gap tells you where to look. If the policy arrived but the update was never offered, the problem is upstream in the reasoning layer. If it was offered and the download never finished, it's the network or the disk. If everything finished and the restart never happened, it's a user or a device that never sits idle when the timeline runs out. Go to the logs. Windows keeps a detailed Windows Update log, but it doesn't make it easy. The raw files are in a format only a few people can read, so you ask windows to translate it. A PowerShell command called Get Windows Update Log merges the trace files into one readable text file. It takes a minute and the output is long. Don't read it top to bottom. Search for the error code you already have and read around it. You're looking for the line just before the failure. That line usually names the cause a file. It couldn't find a source. It couldn't reach a policy value it didn't expect. Which brings you to the quietest failures, the ones with no error at all. If the device never got the instruction, you need to see what it was actually told. That's the resultant policy view in Intune. Open the device and check the configuration status for update settings. Look for conflict and error states. Each one names the setting and the policies fighting over it on the machine. A different tool shows the same truth. Group policy has its own resultant report and the registry holds the update policy values the client is really using. Compare them against what you meant to deploy. When the numbers don't match, you've found the second voice, an old group policy, a leftover registry value, a ring you forgot was assigned. Fix that by removing one voice like we said earlier. Then sync the device and watch the setting change. Now suppose the policy is clean and the device still can't update. The problem is local. You have a short list of repairs and they go from light to heavy. First, reset the update components. Windows update keeps a cache of downloaded files when that cache is damaged. Installs fail in strange ways. Stop the update services, clear the cache folder, restart the services, and let the client download fresh copies. It fixes more machines than it should. Second, repair the servicing layer. Two built in tools handle this. TSM checks and repairs the components. Store the pool of system files. Windows. Builds updates from. Then system file checker verifies the files on disk against that store. Run them in that order because the second depends on the first. Third, the heavy option reinstall for a feature update that keeps failing and in-place repair. Install reapplies windows over itself and keeps apps and data. It takes an hour, and it clears almost everything short of failing hardware. If even that fails, the device needs a reset or a reimage, and at that point, the machine itself is the finding light to heavy stop at the first one that works. But look at what you just did. One laptop, one error, an hour of reading logs, and running repairs. That's fine for a single machine. It's a disaster for fifty. Every step in that playbook is repeatable. The same cache reset, the same repair commands, the same check for the same stack service. A fix you can describe in the list is a fix you can script. So the next move isn't getting faster at fixing. It's making the repeat ones fix themselves. Automating remediation and handling stragglers. Intune has a feature built for exactly this. It's called Remediations and it lives under devices, then scripts and Remediations. Each one is a pair of scripts. The first is a detection script. It runs on the device and answers a yes or no question. Is this machine in the bad state? The second is the remediation script. It only runs when detection says yes and it does the repair. That structure matters. The detection script is cheap and runs often daily. If you want the fix only fires on the machines that need it. Nobody touches the healthy ones. So what do you detect? Start with the repair list you just ran by hand. Is the Windows Update service disabled? Is the update cache bloated or corrupt? Is free disk space below the line a feature update needs? Is the device pending a restart for more than a week? Each of those is a one line check and each one has a known fix. Then you wire them together. Disk below twenty gigabytes. Clear temp files and the old update cache update service stopped. Set it to start and bring it up. Components store damaged. Run the repair commands and log the result. The machine fixes itself overnight and the ticket never gets written. One caution A remediation runs with real power, so test it on your test string first. Like any other. Change. A script that clears the wrong folder at scale is its own incident. Now, some devices don't respond to any of that. They miss the deadline month after month. Don't treat them as noise. Treat them as a list. Pull the devices that miss the target window in each of the last two or three cycles in log analytics. That's a simple query over the history you already collect. The repeat offenders will fall into a few shapes. A model with a driver problem. A department that never restarts. A handful of machines with full disks. A single site behind a proxy that blocks the update endpoints. Once you see the shape, you have a group, and a group is something you can target. Put those devices in their own assignment with a tighter deadline, a stricter restart rule, or a dedicated remediation fix. The cause for the group and the whole list shrinks at once, but some devices are late for a simpler reason they aren't there. A laptop in a drawer can't install anything. A salesperson who connects twice a month gives the service two chances. A field device on a weak cellular link downloads a few megabytes and loses the session. For these, the policy is fine and the delivery has no window to run in. Know who they are? First. Check the last check in date in Intune and sort by it. Anything silent for thirty days is a different category, and it shouldn't sit in your compliance denominator pretending to be a normal device. Handle it on its own track, then lower the barrier. Delivery optimization lets devices share update content with peers, which helps when bandwidth is thin. Shorter, smaller deadlines for rarely connected devices mean the update lands the moment they appear. Instead of waiting for a perfect window and a connected device rule can block access to company resources until the device catches up, which turns a quiet delay into a visible one. Which leads to the last piece. What happens when nothing works? The user can't be the answer. Telling someone to run Windows Update and restart is an instruction, and instructions get ignored. A stuck device needs a path that runs without them. Remediation fires first if the device is still behind after a set number of days, a ticket opens automatically with the error and the history attached. If it's still behind after that, the device loses access or goes to a re-image queue or lands in front of a named owner. Each step has a clock and a person write those steps down once. After that, a straggler isn't a surprise. It's a process. But you can have the best automation in the world and still fight an enemy that's invisible. The last risk is the one you create yourself. A second system, a forgotten policy, two controls telling the same device. Two different things mix the states and common design mistakes. Most estates aren't clean, they're layered. Someone built group policy. In twenty fourteen, someone else added Configuration manager. Then Intune arrived and nobody switched anything off. So three systems now hold opinions about the same device. Group policy sets the update. Source Configuration Manager has its own software update deployments. Intune pushes an update ring and the laptop has to follow all three at once. It can't. It follows whichever value lands last or whichever the whichever. The client trusts more, and that order isn't something you chose. The result is a device that behaves differently from every policy you wrote. Sometimes it reaches Microsoft directly. Sometimes it asks a server that was retired last spring, and the report says nothing because no single system sees the whole picture. If you remember one thing here, remember this. A left over group policy object is the most common silent blocker I know. It doesn't throw an error, it just keeps pointing the client somewhere else. Now co-management is where this gets formal. When a device is managed by both Configuration Manager and Intune, you get workload sliders. One slider per area, including Windows Update policies. Move it to Intune and Intune owns update behavior. Leave it on Configuration Manager and Configuration Manager does. That's the rule. The slider decides who wins, but people treat it like a suggestion. They move the slider for a pilot group, then forget it. And half the estate follows one system while the other half follows another, or they move it. But the old configuration manager deployments stay assigned. Still sitting there, still waiting for a reason to matter. An auto patch adds a requirement on top for the service to manage a device that. Windows Update workload has to sit with Intune not shared, not partly. If it doesn't, the device fails the readiness check and you're back to the not ready list. So treat the slider as a migration, not a toggle. Move it by group. Confirm the old deployments are unassigned. Check the devices real behavior, then move the next group that covers the tools fighting each other. The next problem is the design you put on top of them. Three mistakes show up again and again. The first is too few rings. Two rings, usually a small test group, and then everyone else. It feels simple, but the jump from a few dozen devices to the whole company is a cliff, and a bad update falls straight off it. There's no middle stage to catch the problem, so the first real signal arrives from ten thousand machines at once. The second is deadlines that are too long, a fourteen day deadline on every ring because nobody wanted complaints. Then the exposure window is two weeks wide by design, and you've built a system that's slow on purpose. We talked about measuring that earlier. The number you set here becomes the number you report. The third is no pilot ring at all. Updates go from its own laptops straight to general release. Its machines are the cleanest in the building. Fresh builds, no strange software, nobody running a twenty year old finance tool. A pilot needs people who look like your real users. Or it can't warn you about anything. Notice what these share. None of them is a technical failure. Each one is a decision someone made to avoid friction, and each one moves the risk somewhere you can't see it. And then there's the mistake that looks like success treating autopatch as set and forget the service runs well. That's the problem. It creates the rings, watches the rollout, pauses on bad signals, and for a few months nothing hurts. So attention drifts. Nobody reads the registration failures. Nobody checks the not ready list. Exclusions pile up with no review date, and the exclusion list quietly turns into a second estate that nobody patches. Auto patch manages the process. It doesn't own the outcome, the policy decisions, the exceptions, the accountability. All of that stayed with you and it stays with you whether anyone is looking or not. So you don't need more tools. You need someone to look on a schedule with the authority to act, which is a plan. And a plan needs roles, rhythms, and decisions written down an operating model you can run. Start with names, not teams names. Three jobs need an owner and each one needs a single person who answers for it. Policy is the first. Somebody owns the rings, the deferrals, the deadlines, the restart rules. When the setting changes, that person approved it. When two controls collide, that person decides which one stays. If nobody holds this job, every admin edits the policy a little, and in six months, nobody can explain why broad has a nine day deadline. Pilots are the second someone has to keep the early rings alive. That means real users, real hardware, and a way for them to say something broke. A pilot ring with no owner slowly fills with people who left the company. The owner checks membership every quarter and makes sure the group still looks like the estate it's supposed to warn you about. Exceptions are the third, and it's the one that gets skipped. Every estate has devices that can't follow the normal path the factory controller, the clinical workstation. The executive who refuses to restart each exception needs a name next to it, a written reason, and a review date. Without a date, an exception becomes permanent and the list quietly turns into the second state we talked about earlier. Policy pilots. Exceptions. Three owners, one backup for each. Now the rhythm. Because ownership without a calendar is just a title. The monthly cadence starts with Patch Tuesday, but not on Patch Tuesday. The day itself is for reading. What shipped. What's flagged as exploited, what Microsoft says about known issues. That's a short check by the policy owner, and it answers one question is this a normal month or does something need the expedited path? Then the rings take over. Test gets the update. A few days later, the pilot owner reviews the signal failures. Helpdesk calls anything strange from the early users. That review ends with a decision written down, released to the next ring. Hold or pause, then fast, then broad, each step with its own check. By the end of the cycle. The reporting we built earlier shows time to patch for the month and someone compares it to the targets. Notice what that is. It isn't a project. It's a loop that runs every thirty days with the same few people and the same few questions. The yearly cadence is slower and it matters just as much. Once a year the feature update comes around. The policy owner opens the lifecycle calendar, checks which version reaches end of servicing and picks the target. The pilot ring moves first well ahead of everyone else months ahead. Then the rollout waves follow. The same ring logic only stretched over weeks instead of days. That same review is when you read the exception list line by line. Does the reason still hold? Did the vendor finally support the new version? Can that device join the normal path? Some exceptions die here and they should plan it in the calendar a year out. A feature update that arrives as a surprise turns into a project. One that arrives on schedule is just the next step. Last piece the meeting. You need a review and it needs to produce decisions, not slides. Monthly. Thirty minutes. Quarterly. A little longer. The monthly review has a short agenda. Did we hit our time to patch targets by ring? Which devices missed twice? Is anything paused and when does it expire? Does any exception come due? Each question ends with an action and an owner or with a plain. No change. The quarterly review looks further out. Are the rings still the right size? Is the pilot still representative? Did a deadline change move the number it was supposed to move? That last one is the test of the whole system. If a change can't be seen in the data, it wasn't a change. If a meeting ends without a decision, cancel the next one and fix the agenda. Put it all together and something shifts. You aren't running updates anymore. You're running a loop with owners, a clock, and evidence, and that changes the question you ask in the first place. The shift from patching devices to governing change. The question was never did we patch? It was who decided and what did they know when they did? Think back to where this started, an update arrives. Someone approves it. Someone deploys it. Everyone hopes that was the old model patching as an event, a task with a start and an end owned by whoever happened to run it that month. What replaced it as a system? You declare the outcome. The service handles delivery windows update for business runs on the device. Intune carries the policy auto patch, watches the rollout and pauses it. When the signal goes bad, your job moved up a level. You stopped moving updates and started setting how much risk the business accepts and how fast. So which decision matters most? Not the deadline. A deadline is a number, and numbers are easy to change. Not even the ring design, though a bad design hurts. Ring structure is something you can fix in an afternoon once you see it's wrong. Ownership is the hard one. Every failure we walked through had the same root a conflict. Nobody owned a pilot ring. Nobody maintained an exception with no name and no date. A fast tool sitting behind a slow approval. The settings were fine. Nobody was accountable for them. Get ownership right and the rest gets corrected over time because someone is looking. Get it wrong and perfect rings decay into a shape nobody can explain. So here's your next thirty days. One step, not ten. Write down three names who owns policy? Who owns the pilot ring? Who owns exceptions. Then give each one a backup and put a monthly review on the calendar thirty minutes. With one rule it ends in decisions or it gets canceled. That's it. Before you touch a single setting, because the first time you run that review, something happens. You'll open the exception list and find devices nobody remembers approving. You'll look at the pilot group and find people who left last year. You'll check the not ready list and see the same machine sitting there since spring. None of that needs a new tool. It needs a person whose job is to look. Now go back to the opening assumption. The one we started with that patching is a monthly event. Someone runs it held for a long time because devices sat on a network you controlled and timing belonged to whoever controlled the server. That world is gone. Devices roam, updates never stop, and the window between a fix and an attack is measured in days. What replaced the assumption is a smaller idea and a harder one. Change is continuous, so governance has to be continuous too, not a heroic push. Once a month, a loop with owners, a clock and evidence do that, and patch Tuesday stops being a deadline. It becomes a signal you already know how to read. That's the model. Outro. If this changed how you think about patching. Leave a review. It helps other admins find a better model than approve. Wait and hope. Follow me. Mirko Peters on LinkedIn and tell me what topic you want next. Intune autopilot defender your call and share this with the team that's dealing with failed updates right now, today, not next month. The next patch Tuesday is already on the calendar. Make sure someone has a name next to it.