A Windows fleet has two update systems, whether anyone planned it that way or not. Windows Update, steered through Windows Update for Business or Windows Autopatch, keeps the operating system and Microsoft's own applications current. Everything else that is installed, the browsers, PDF readers, meeting clients and developer tools, is updated by nobody until someone builds and publishes a new package. This guide draws the line between the two and shows how Intune's Win32 app type covers the second half.
What Windows Update for Business and Autopatch cover
Windows Update for Business is a set of policies, delivered through Intune, that tell the Windows Update service on each device what to install and when: which quality and feature updates, after how many days of deferral, with what deadlines. Windows Autopatch is Microsoft operating those policies for you, in rings it manages, with its own reporting. Both end at the same place: Microsoft's update services and Microsoft's own updaters.
| What | Kept current by | Where you steer it |
|---|---|---|
| Windows quality and feature updates | Windows Update | Update rings and feature update profiles in Intune, or Autopatch's rings |
| Drivers and firmware | Windows Update, when the policy allows it | Driver update policies in Intune; Autopatch manages them for enrolled devices |
| Microsoft 365 Apps | The Office update channels (the apps update themselves) | Update channel and deadline settings in Intune; Autopatch manages the channel |
| Microsoft Edge | Edge Update, the browser's own updater | Edge update policies; Autopatch includes Edge |
| Microsoft Teams | The Teams client's own updater | Autopatch includes Teams for enrolled devices |
That is the whole list. The common thread is that every row is Microsoft software with a Microsoft update service behind it. Neither Windows Update for Business nor Autopatch knows anything about software from another vendor, and neither pretends to.
What they do not touch
- Third-party applications. Browsers other than Edge, PDF readers, meeting and chat clients, remote-support tools, archive utilities, media players, runtimes and developer tools. Each ships its own installer and, often, its own updater.
- The versions Intune already installed. A Win32 app published at version 1.2 stays at 1.2 on every device until someone builds and publishes a new package. Windows Update never upgrades it, however many patches the vendor has shipped since.
- Apps whose own updater you switched off. In a managed fleet that is most of them: an updater that pulls whatever the vendor released this morning is the opposite of a tested rollout, so admins disable it and take the job over. Taking it over is the part this guide is about.
Two Microsoft routes do reach some third-party software. Apps installed through the Microsoft Store app type update through the Store, and Intune's Enterprise App Catalog, an add-on, offers a curated set of pre-packaged third-party apps with their updates. Both cover a slice. Classic MSI and EXE setups, line-of-business installers and anything a vendor does not publish to the Store or the catalog remain the admin's job.
How Intune Win32 apps fill the gap
The Win32 app type is Intune's general-purpose installer. You wrap the vendor's setup in an .intunewin package, give Intune an install command with the installer's silent switches, an uninstall command, a detection rule that tells Intune whether the app (and which version) is present, and any requirements; then you assign it to groups. Updates ride on the same mechanism: a new version is a new Win32 app that supersedes the old one, so devices with the old version get the new one and devices with nothing get a fresh install. Done by hand, the loop looks like this:
- Notice that the vendor shipped a new version (release notes, a feed, a colleague).
- Download the installer and check its hash against the one the vendor publishes.
- Confirm the silent switches (usually the same installer family as last time) and wrap the installer with
IntuneWinAppUtil.exe. - Create the new Win32 app with a version-aware detection rule, so the old version is no longer detected once the new one is on.
- Set the new app to supersede the previous one in update mode and move the assignments across.
- Assign to a pilot group first and the rest later, watch install status, and keep the old package around in case you need to roll back.
Six steps, once per application per release. Twenty applications releasing monthly is two hundred and forty passes a year, which is why third-party patching so often ends up as a queue in a ticketing system rather than a policy.
Running the two side by side
| Responsibility | Mechanism | Rings |
|---|---|---|
| Windows, drivers and firmware | Windows Update for Business or Autopatch | Autopatch's rings, or your own update rings |
| Microsoft 365 Apps, Edge, Teams | Their own update channels, configured in Intune | Update channel and deadline settings |
| Every other application | Win32 apps with detection rules and supersedence | Your pilot, broad and all groups |
- Use the same device groups for the pilot ring in both systems. One group that sees every kind of change first is easier to watch than two.
- Do not land an OS update and a browser update on the pilot ring on the same day. When something breaks, you want to know which one did it.
- Rank third-party updates by what they fix. A CVSS score and the Known Exploited Vulnerabilities list tell you which of this month's twenty releases cannot wait for the next ring.
- Write down who owns each row of the table. The gap usually opens where nobody does.