Intune Patch Management, Automated

Apps ready for patching

Robopack can start patching most of the software already on your devices today. One click per app puts it under management — or tick several and add them together — and from then on it picks up new versions on its own.

It is also the first honest inventory most teams get to see. Alongside the software you deployed on purpose, you will find what your users installed themselves: a second browser, an AI assistant, a screenshot tool, a packet sniffer, a games launcher. All of it real, all of it sitting on managed hardware, none of it updating.

You do not install anything to get this. Robopack Radar reads what Intune already collects from your enrolled devices, so the list is populated the day you connect a tenant. It refreshes daily, or on demand when you want it now.

The apps Intune installs but never updates

Intune installs software. It does not keep it updated. So most estates carry a backlog of apps nobody patches — driver software that came with the hardware, engineering tools a few people depend on, Microsoft components that arrived alongside something else, commercial apps sitting on two or three versions at once.

The costly ones are the apps somebody already packaged by hand and deployed properly. Those install perfectly and then never move again, because every new version means building the package from scratch a second time.

Upload the installer once instead. Robopack packages it, proves it on a clean VM, and from then on new versions roll out through the same rings as everything else you patch.

Patch multiple apps at once in patch groups

A patch group is the policy, written once. Which devices go first, how long each stage runs, what counts as success, what happens to the old version. Every app you put in the group follows it.

That is the part that is hard to do by hand. In Intune, each app gets its own assignment groups, its own supersedence rules, its own cleanup — so the policy lives in somebody’s head rather than in the system. Six months later no two apps are set up quite the same way. Nobody decided that; it just accumulated.

Here you decide once. Switch on Start new versions automatically and every app in the group picks up new releases on its own, so nobody has to notice that a vendor shipped something. Keep three superseded versions and you always have a version to fall back to, without your Intune app list growing forever. MSIX apps get wrapped and published as Win32 rather than line-of-business, because that is what most estates actually want.

Then adding an app is one drop-down. It inherits the whole policy — same staged rollout, same success thresholds, same handling — whether it came from the catalog, from a Radar scan, or from an installer you uploaded yourself.

Package your own custom apps with drag and drop

Every packaging job starts the same way. Someone hands you an installer — from a vendor, or built by your own team — and you have to work out what it wants. Which silent switches it takes. What its uninstall string is. How to detect that it actually installed. Then you wrap it, push it to a test machine, and find out whether you guessed right.

Drop the file in here instead and Robopack reads it before asking you anything. It identifies the installer technology straight from the binary — a WiX Burn executable, an MSI, whatever it happens to be — along with the file set and the size. That is the part that matters, because the installer type is what dictates everything downstream: the switches, the exit codes, the way it has to be called.

Then you pick the output. IntuneWin, if you are deploying through Intune the usual way. MSIX, expandable to VHD, VHDX and CimFS if you need it. Or App-V. Same source installer, whichever format your environment actually runs.

Four steps, and the middle two are mostly you reading back what Robopack already worked out. No command line, no IntuneWinAppUtil, no test deployment into a spare Intune group to find out whether it installs.

Built for people who manage more than one Intune tenant

Connecting a tenant is a Microsoft sign-in and a consent prompt. Robopack creates an app registration and a service principal, the permissions are listed in front of you before you accept, and the tenant appears in the list. Nothing to install, no certificate to exchange.

From then on each tenant keeps its own state — authorized, single sign-on enabled, or not connected — along with its device count and its own catalog and policy configuration. One patch group can publish to more than one tenant, which is how an MSP gets a single rollout policy running across every customer instead of rebuilding it per environment.

Delegation without shared logins

Tenant permissions go to individual users or to Entra ID groups, at three levels: Read, Write and Config. Organization administrators and security writers keep access to every tenant; everyone else sees only what they have been granted. Entra ID group assignment applies when the user signs in with an Entra account.