Apps in Intune without a packaging machine

Tested before you deploy

A package that fails on a real device turns into helpdesk calls. So before a catalog app gets the Verified label, MDO runs the exact package a deploy would build on a clean Windows 11 VM that isn't enrolled in Intune:

1. Check the detection rule doesn't match before install.
2. Install as SYSTEM with Intune's own command line.
3. Check the detection rule matches.
4. Uninstall, and check it no longer matches.
5. Record leftover files and registry keys, then roll the VM back to its clean snapshot.

152 of the 157 deployable catalog apps have passed. Verified shows on the Apps list with the tested version and date.

Edge, WebView2 and PowerShell 7 can't be tested on a clean VM, because they ship with Windows or can't be removed. A pass shows the package installs, detects and uninstalls on a clean machine. Whether the app suits your devices is still your call.

Where apps come from

Most of what your users ask for is already in the catalog. Quick Deploy has 157 apps ready to go, 46 marked Core and 111 Catalog, plus Microsoft 365 Apps with its own wizard. Another 38 are listed as unavailable with the reason, for example a per-user installer or a zip-only download. Some of those install as Microsoft Store apps instead.

For anything else, search the community Winget index (about 11,900 apps), pick a Microsoft Store app, or upload your own .msi or .exe under Custom App.

See the package before it's built

No surprises in Intune, and nothing downloads until you agree. The last step of the deploy wizard, What MDO will build, lists the installer and file, the install and uninstall commands and the detection rule. MSIs are detected by their product code. Other installers get a script that checks both registry views.

MDO refuses what it can't deploy properly, and says why:

• per-user installers, which can't run as SYSTEM;
• MSIX packages outside the Microsoft Store;
• apps with no working uninstall, unless you tick Deploy without uninstall.

In the same wizard you pick the version, architecture, maximum run time and restart behaviour (exit codes 3010 and 1641 count as restarts). You can add pre- and post-install PowerShell scripts and name the apps to close before install. Desktop shortcuts the installer creates are removed unless you turn that off.

Change it after it ships

Editing an app in the Intune portal is easy to get wrong and hard to undo. In MDO, every app has a sheet where each save checks Intune first, so you don't overwrite a change someone made in the portal, and reads the app back afterwards.

• Drift. If someone edits an MDO app in Intune, the sheet shows MDO's version next to what is in Intune now. You accept the change or push MDO's version back.
• New package. Change the Winget version, PSADT options or scripts. By default MDO creates a new Intune app that supersedes the old one and keeps the last three. Updating in place is still an option.
• Roll back to any of the last three packages.
• Uninstall everywhere turns every Required and Available assignment into Uninstall, for the same groups. Delete can remove the assignments first.
• Adopt into MDO brings an app someone added in the Intune portal under management, with a Winget match if one exists.
• History lists every change with the old and new values. Assignment changes can be restored from there.

Before MDO changes an app's commands, detection or package, or deletes it, it backs the app up to your storage account. If that backup fails, nothing changes.

Microsoft 365 Apps, built the way you'd build it by hand

Office installs during Autopilot and is detected like any other app, with no XML to write. Deploy an app › Microsoft 365 Apps walks you through four steps:

1. Office. The edition, preselected from your tenant's licences, the update channel (Monthly Enterprise, Current or Semi-Annual), languages and which Office apps to include.
2. Add-ons. Visio, Project and language packs, each built as its own app, plus proofing tools under Advanced.
3. Assign. The same Required, Available and Uninstall step as every other app, for Core and each add-on, with groups, exclusions and a filter. Core starts Required to All devices.
4. Review. What MDO will install and remove, what happens if Office is open on a device (close it, try again later, or ask the user), and the configuration for each app.

MDO builds Office as a Win32 app. Before installing, it removes the consumer Office that some PCs ship with, without touching a business Office that's already there. Later, the app's Configuration tab changes the setup by creating a new Intune app that supersedes the old one.

Proven on a test device enrolled with Autopilot: Office installed during setup and activated as Microsoft 365 Apps for enterprise for an E5 user.

Groups that match each app

One place to see who gets what. With per-app groups on, MDO creates three Entra security groups for each app it deploys, one each for Required, Available and Uninstall, and nests the groups you pick inside them. The name pattern is set in Settings › Apps and defaults to App - {App} - {Intent}.

Apps you adopted can move to their own groups without reinstalling anything. Creating groups needs the Group.Create permission, so each tenant grants admin consent once more. Until then MDO assigns the groups you choose directly.