Intune Patching Part II: The Good, The Bad, The Ugly

In Part I of this pathetic little series I tried to cover enough of the technical details so that if you don’t currently patch your devices with Intune you could get a feel for it without actually having to do it. In Part II I want to get into the meat of the thing: can I, and by extension you, actually use this thing? I’m going to get full-on opinionated here so if you just want cold hard facts come back next time when I’m sure to over-think something to the n-th degree.

The Good

I’m not going to lie, I went into this fully expecting to hate everything about it. I’m a WSUS/ConfigMgr nerd if ever there was one and my previous look at Windows Update for Business (WUfB) left me unimpressed. In the end I came away not hating it. In fact, in certain situations I’d even go so far as to recommend it as a great fit. That’s getting ahead of myself though, more on that later. What did I like? Glad you asked.

WSUS = Dead To Me

One of the absolute greatest parts about using Intune (or WUfB really) to patch is that it does not use WSUS. Let that sink in for a second. Feel the pure joy and elation. That could all be yours.
Catalog maintenance? Not a thing.
Selecting newly unannounced product categories? Never.
Running some internet idiot’s PoSH scripts? Not for your precious snowflake of an environment.
Reluctantly assuming a WebAdmin Role to keep WSUS Alive? Not your bag baby.

You can patch your entire environment, at scale, without any dedicated on-prem architecture. Your clients can now scan successfully against the full update catalog instead of having to micro-manage it to within an inch of it’s life just to keep it afloat.

Another catalog side-benefit is that without ConfigMgr filtering them or WSUS crumbling under their weight you can now optionally have your clients grab updated drivers from Windows Update. Sure, you might already have a more controlled method for doing so but a lot of orgs just don’t do anything in this space. Intune patching reduces this to a single click to enable this option.

Servicing Stack Updates? Should I Care About Those?

In 2018 and again in May 2019 Microsoft did something that I’m sure was necessary on some level but was a huge PITA. I already talked about it at length here so I won’t try to re-litigate the whole thing again. The point is that sometimes order does matter and the only mechanism built into the Windows Update Agent, WSUS, or ConfigMgr to enforce order is prerequisites which can create the catch-22 I describe in the post above. (Side note: let’s fix that).

Windows Update, the thing you’re pointing your devices to with Intune, was a cloud service before highly paid consultants started buying fast cars using that word. Before it was cool you might say. The point being that Windows Update was updated long ago to handle SSU-before-CU order.

So no, you don’t need to care about SSUs. They’ll just do their thing without you having to know or really care.

Delivery Optimization, Making It All Possible

Now if you’ve been around a while you might remember the joy of configuring Windows Update via GPO thinking it was a great idea. You then watched in horror as your clients crushed your inbound pipe. A few internet searches later you became a WSUS admin for the first time. If so, you can’t be blamed for being concerned about content management with Intune patching.

The good news is that this is exactly what Delivery Optimization (DO) was created for. Instead of every device downloading their own copy they will P2P that data. DO is a whole topic unto itself and if you want to dig in then learn from the masters. You will want to configure DO so that it respects your network topology but that’s beyond the scope of this post. If you’re using ConfigMgr co-management it’s stupid-easy to do. The point is, you can scale this data across your org without being publicly flogged by your network team.

User-based Targeting

This is an interesting concept that I haven’t fully through the ramifications of. However, the fact is that Intune’s update rings can be targeted to user groups in addition to the more traditional device groups that we’re all familiar with. Rollouts are often by department and with ConfigMgr we’d jump through various hoops to tie a department’s AD group to a set of user objects and then to their primary devices. That all goes away here and you can directly patch by departments which are usually defined by users, not devices.

Scheduling: It Ain’t Half Bad

I initially had a dim view of the scheduling options but the more I thought about one specific combination the more excited I got. Specifically, I think the combination of the Quality Update deferral and the Auto Install and Restart at Maintenance Time options is compelling. The latter allows you to set a specific time on a specific day of the week on specific weeks of the month to install updates. That can be used to create a reliable monthly cycle where every needed update is installed regardless of product category, release date, or classification. The deferral allows you to make sure that only patches that have been released for X number of days are installed each month. Remember the ConfigMgr UserVoice to deploy only un-deployed updates? This combination is exactly that.

Note: Make sure that your update rings’ deferral policies align so that their deferrals calculate backwards to the same date. Otherwise your rollout ring(s) might install something that your pilot ring(s) did not.

Uninstall! Sweet Goodness YES!

Microsoft’s track record for flawlessly publishing flawless patches is … sketchy. While I could talk all day about proper patch testing the cold hard reality is that you never really know until you start deploying at scale. If something goes wrong to the point of having to hit the abort button the story in ConfigMgr isn’t so great (let’s fix this too). In Intune though it’s as easy as right-clicking on the update ring and selecting Pause to stop the damage. If you need to rollback it’s as easy as clicking Uninstall.

Infrastructure-less Reporting. With Doughnuts!

In a future post I plan to dig into this deeper but unlike WSUS or ConfigMgr, Intune doesn’t have any built-in reporting. Luckily though Azure Analytics does: Update Compliance. By simply configuring your devices to send analytic data you get free (for the first 5GB/month global log analytics usage) reporting that looks more attractive than anything I’ve ever built.

Reboot Experience: It’s What Your Users Already Know

I talked about this in Part I but it’s worth highlighting again: I really like the user experience for Intune Patching. The ability to transition between automatic on-idle reboots to user driven restarts to forced reboots is compelling. The fact that you can configure the timing of those transitions is beautiful.

User experience got a very last-minute lunch session at MMSMOA where Avi Prasad (ConfigMgr Project Manager) and I got to talk to a packed room to get feedback and bandy about ideas. When we polled the room to see if people would like the option to use the standard Windows 10 user experience for reboot there was wide agreement. It was one of the few things that room was nearly unanimous about.

That user experience is yours with Intune Patching. The prompts, dialogs, and reminders should feel right at home for your users. They might hate them anyways but at least you can plausibly tell them that’s Microsoft’s fault and they just might believe you.

The Bad

Alas, not everything is rainbows and unicorns in Intune land. There are some downsides that you’ll either just have to get over or could end up being full-on deal breakers.

Update Selection: Not Even ‘In Name Only’

Let’s get this one out of the way early: you don’t really select updates in Intune. The words ‘select updates’ does not appear in the portal that I could find. Your only choices are the Windows 10 channel and whether to include non-OS updates and/or drivers.

Coming from WSUS and ConfigMgr this just seems a moral affront. However, with the cumulative update model of Windows 10 I’d argue there’s not a whole lot of value in granularly selecting updates every month. Personally, I’d happily trade granular selection for a WSUS-less system that just patches everything without hassle. That’s just me though.

Update Scheduling: The Other Half

The remaining scheduling options apart from Auto Install and Restart at Maintenance Time share a common flaw. As I’ve said before: Patch Tuesday is a lie. Every time Microsoft releases a patch a brand new patch cycle will kick off on all your clients. If I look at my own device’s update history I see several months that have two or more update installation dates. In some cases they were .NET which can require a reboot.

Keep in mind too that you don’t really have any central way of tracking or knowing what’s going to happen when. There’s nowhere in the Intune portal that lists the specific set of updates that are going to install or be available to install in a given ring on a specific date.

Third Party Updates: Dude! You’re Getting WSUS!

Remember the great Dual Scan debacles of 2017? Sigh. Those were good times. Well, believe it or not, Microsoft didn’t invent Dual Scan for the singular purpose of installing the latest version of Windows 10 without your express intent. Apparently they invented the whole thing so that you can configure the client to get all Microsoft content from Windows Update and everything else from WSUS. So yea, if you want to use the software updates mechanism to deploy third party updates you get to be a WSUS administrator again. Just what you wanted when you moved to Intune Patching!

Never Forget the Submarine Use Case

Intune is a cloud service. Cloud services are notorious for not being on premise (I know … I know … AzureStack). It’s kind of their thing. This makes internet connectivity non-negotiable. If you have clients that for a variety of reasons cannot reach the internet ever or at least regularly enough to patch themselves appropriately then Intune patching isn’t going to work for them.

Reporting: Shallow and Slow

While reporting is generally in the win column there are two major drawbacks to be aware of.

First, the Update Compliance dashboard I discussed above only reports on Feature and Cumulative Updates. If you need reporting on things like .NET patches or Flash updates you need to seek elsewhere. Note that there are other Azure-based update monitoring solutions. While I plan to dig into them at some point I do not believe any them are ‘free’ like Azure Analytics is.

Second, the reporting cycle for some of the data is sloooooooow. The worst case scenario for the main data table (WaaSDeploymentStatus) is up to 48 hours for the data to be calculated. So you’re getting what you’re paying for on that front.

The Ugly: Feature Updates

If there’s one thing that’s an absolute show-stopper for Intune/WUfB patching it’s how it handles Feature Updates. Or as I like to call them: FUs.

In Intune/WUfB your normal monthly update policies are handcuffed to your FU policies as well. So whether you like it or not you are scheduling FUs if you patch with Intune. Now, this might not be the end of the world. If you hate the servicing model (and many rightfully do) you have 365 days to update the OS in some other way.

That being said, I know a lot of organizations are planning to standardize on the Fall release of Windows 10 because of its 30-month lifespan. Their intent being to skip the Spring release. That isn’t going to fly in Intune where skipping releases isn’t an option. Remember that everything in your Intune policies is tied to the release date and that FUs have no set release dates. Heck, if 1809 taught us anything it’s that they might not stop at just one release date.

I simply do not think the industry is ready to automate FUs based on some nebulous date they can’t plan around. To get there would take an enormous amount of trust that must be earned over time with a unbroken record of flawless releases. That record, if it even existed, was reset with 1809.

I believe that the next step for Intune/WUfB has to be to separate the CU and FU policies. Ideally we would have a manual FU option so that organizations could chose not to use the servicing model at all. At least for now. When they’re ready to try it out they can start a small manual roll-out totally separated from their day-to-day patching processes. After a series of rock solid releases then and only then might they consider moving to a full automated model. No one in their right might is going to implement a set-it-and-forget-it model until they have complete faith in the servicing model. I don’t know anyone who’s a true believer yet though I’m sure they’re out there.

Intune Patching: What or Who Is It Good For?

Patching with Intune sits alongside several other patching options: straight-up WUfB, WSUS, or ConfigMgr. To say nothing of solutions from other vendors. Now that you know a bit about how it works and what the pros and cons are … where does it fit?

First, you really need to be ‘modern’ by Microsoft’s standards which basically means Windows 10 joined to AzureAD running Office 365. The Win 10 requirement will soon be a moot point: No one deployed Win 8 and Win 7 is about to stop getting patches entirely. Similarly, being joined to AzureAD is what Microsoft is slowly but surely pushing everyone towards so it’s more or less an eventuality.

I think the easiest, most clear-cut, use case for Intune as a whole is small to medium businesses. If you don’t have any enterprise level management solution similar to ConfigMgr then using Intune and its patching configuration is just a no-brainer. If you’re using stand-alone WSUS and aren’t using it to deploy third party updates then put the WSUS down and get Intune.

Using Intune patching in a large organization isn’t out of the question mind you. I just think it’s a more nuanced discussion. The larger your organization the more likely they’re doing things that Intune isn’t good at such as internet-segregated PCI/HIPPA devices. You might be able to move part of your organization, say your office workers, to Intune while keeping everyone else on your existing solutions. That could make sense but there’s a bunch of factors involved that could swing the final decision either way.

The end result is that Intune patching isn’t for everyone and if you’re already using ConfigMgr it’s a bit of a hard sell to move that way. However, as you adopt pieces of the cloud that make sense for your org I’d suggest keeping an eye on this. Keep watching this space as it continually improves. If we get the Quality/Feature policy split I think that could really change the calculus.

Done, Finished, I’ll Go Away Now

There you have it, a bunch of opinion about patching with Intune. If I do a part III here it’ll be to dig into some of the reporting options. I have a few other ideas piling up though that I want to get to first. As always, tell me about the multitude of ways that I have gone astray here.