Editing an app

The Apps page (under Apps in the sidebar) lists every app in the tenant’s Intune, whoever added it.

The Apps page

Columns: Name, Version, Source (MDO, Intune or Store), Verified, Assignments (shown as R n · A n · U n for Required, Available and Uninstall) and Backup.

An amber dot means the app changed in Intune and differs from MDO’s version.
Filters: managed by MDO, managed elsewhere, unassigned, platform, has drift and backup tier.
Show deleted lists apps deleted from MDO, read-only with their History. Show earlier versions lists the earlier Intune apps that newer packages superseded.

Click a row to open the app’s sheet.

The app sheet

Tabs: Overview, Details, Assignments, Install behaviour, Detection, Package and History. Install behaviour, Detection and Package are for Win32 apps. Package is also only for apps MDO manages.

Every save follows the same rules:

MDO first checks whether the app changed in Intune since you opened it, and stops if it did.
Before changing install commands, detection, return codes or the package, MDO backs the app up to your storage account. If the backup fails, nothing is changed.
After saving, MDO reads the app back from Intune.

Overview

Shows the app’s state and the actions: Edit, Open in Intune, New package, Roll back, Uninstall everywhere and Delete. For an adopted app that still uses groups you picked, Move to MDO groups moves its assignments to the app’s own groups without reinstalling.

Drift

If someone edits an MDO app in the Intune portal, the Overview shows MDO’s version next to In Intune now, field by field. Accept into MDO keeps the portal’s change. Push MDO’s version writes MDO’s back.

Details, Assignments, Install behaviour, Detection

Details: name, description, publisher, URLs, notes, categories and icon.
Assignments: every assignment with its group, filter, deadline, notifications and Delivery Optimization settings. For per-app groups, the members, with Add members.
Install behaviour: install context, restart behaviour, return codes, architectures and minimum Windows release.
Detection: rule editors for MSI, file, registry and script rules.

Package

Change the Winget version, PSADT options or pre and post scripts, then Review the change and upload. Two modes:

New app that supersedes (the default): MDO creates a new Intune app that supersedes the old one and moves the assignments to it. It keeps the last three versions in Intune and retires older ones.
Update in place: uploads a new content version to the same Intune app.

Roll back returns to one of the last three packages. In supersede mode that re-assigns the earlier Intune app. Intune doesn’t downgrade an installed app by itself, and some MSIs install side by side.

Uninstall everywhere and Delete

Uninstall everywhere turns every Required and Available assignment into Uninstall, for the same groups and filters. You can undo it from History.

Delete first checks what depends on the app (supersedence, dependencies, other versions) and can remove the assignments first. MDO backs the app up before deleting it, then keeps it findable under Show deleted. If MDO created the app’s groups and they’re empty, it offers to delete those too.

Adopt

Apps added in the Intune portal show as managed outside MDO. Adopt into MDO brings a Win32, Store or MSI line-of-business app under management. MDO suggests up to five Winget matches, which enable new packages later. Without a match you can still edit in place. Adopting writes nothing to Intune.

History

Every change, by whom and when, with the old and new values, plus package versions, deploy jobs and lab runs. Restore these assignments puts an earlier assignment set back.

Who can do what

Deployers, Admins and Owners can edit, repackage, roll back, uninstall and delete apps MDO manages. Bulk deletes are for Owners. Viewers see everything and change nothing.