Every change in Intune and Entra, who made it, and the way back

One history of every change

Audit › Changes lists each change as one sentence: the object, the person, how they made it (in the Intune portal, by an app, or by MDO) and when. Open it to see every setting before and after.

MDO reads Intune's and Entra's audit logs every 15 minutes, so a change shows up about 15 minutes after it happens. The before and after come from MDO's copy of the policy, taken every night and whenever someone clicks Sync with Intune. Where Intune doesn't report who made a change, the row says so.

MDO also tracks assignments with their group names, Intune roles and scope tags, enrollment settings and Autopilot profiles, and Endpoint security setting by setting. Apps MDO manages show an edit made in the portal as MDO's version next to what is in Intune now.

The Entra changes that affect your devices

A Conditional Access edit or a group change can break devices as surely as an Intune policy can, so they sit in the same history, labelled Entra:

• Conditional Access policies and named locations, with the before and after;
• changes to the groups your Intune assignments use, with the assignments that use them;
• directory role assignments, including PIM;
• app consents, permission grants and app credentials;
• deleted devices.

Intune roles, scope tags and the Conditional Access before and after need two newer permissions, so they start once the tenant has re-consented in Settings › Connection.

Windows LAPS password views appear under Device actions, beside wipes, retires, resets and other device actions with who asked for them.

Revert from the change itself

Undo a bad change where you found it. Revert shows exactly what MDO will write, with the value now and after the revert, before anything happens. It covers device configuration and compliance settings, assignments, and deleted policies, which come back from the newest backup that has them.

MDO refuses what it can't put back safely and says why, for example secret values or Wi-Fi, VPN and certificate profiles. If the policy changed again since, nothing is written unless you confirm. Reverting Settings Catalog settings is switched off until it is proven on a test tenant. Reverting needs the Owner or Admin role.

On the same list you approve a change, dismiss it, or acknowledge expected changes for 30, 60 or 90 days or indefinitely. The Needs review filter shows what's left to decide.

Alerts on risky changes

Hear about a risky change soon after it happens. MDO alerts you by email or by webhook, for example to a Teams channel, when:

• a protected policy or app changes;
• a policy, app or Conditional Access policy is deleted;
• an assignment is removed or widened to All users or All devices;
• a compliance or Endpoint security policy is weakened;
• someone is given a directory role;
• a device is wiped, retired or reset;
• MDO flags a high-severity anomaly;

Each rule goes out straight away or in an hourly or daily digest. MSPs set defaults once for every client, and each tenant can change its own. MDO's own actions don't raise alerts unless you ask them to. Fired alerts are listed under Audit › Alerts and in the Inbox.

Protect the policies that must not change

Know at once when someone touches a policy you rely on. Mark a policy, an app or a Conditional Access policy as protected, with a reason, and by default any change to it raises a high-severity alert.

For policies, you can also turn on automatic revert, off by default. MDO then puts a protected policy back after a change, only where Revert can do it without asking, at most three times a day, and tells you what it did.

Unusual activity, in plain words

MDO flags activity worth a second look, each with a severity and one sentence saying why:

• a day with far more changes than usual;
• a day where many changes failed;
• changes outside a person's own usual hours;
• an operation the tenant hasn't seen in the last 60 days;
• a person or app making changes for the first time in 60 days.

MDO's own scheduled jobs are scored separately and never count toward the tenant's anomalies. Rules that compare with the past wait until MDO has 14 days of history.

Reports for auditors

Prove what changed, and who changed it. Audit › Reports builds a report by period, area, person and source, for example every change to compliance and Endpoint security policies last quarter. It comes as CSV or PDF, with the scope written at the top. Owners and Admins can generate it.

Restore a policy, even a deleted one

Intune has no undelete. Under Audit › Restore you start from the policy, not the date: Find a policy in your backups searches every run, and Recently deleted lists policies that disappeared from Intune. The restore wizard then asks:

• settings and assignments, settings only, or settings with groups you choose;
• the same name or a new one;
• for a policy that still exists, overwrite it or restore it as a new policy.

A deleted policy comes back with a new ID, because Intune gives it one. MDO links the old and new IDs so the change history stays connected, and syncs the tenant afterwards so MDO shows the restored policy.

Nightly backups in your own storage

Your backups stay yours. MDO writes each policy as a JSON file to a storage account in your own Azure subscription, with group names saved beside the assignments. Each run gets its own folder:

DeviceConfigurations/

Device configuration profiles

CompliancePolicies/

Compliance policies

ConfigurationPolicies/

Settings Catalog, including Endpoint security built on it

EndpointSecurity/

Endpoint security from the older templates

Apps/

App metadata

You set the schedule and how many days to keep (90 by default). Policy backups run from MDO, so your subscription holds a storage account and nothing that runs. MDO keeps an index of each run so it can find a policy for you, and no storage keys.

To back up the installer files for your packaged (Win32) apps too, the optional full tier adds an Automation Account in your subscription that copies them straight from Intune. Those bytes never pass through MDO.

Activity: what people did in MDO

Activity records what people did in MDO for the tenant: who, what and when, with the app, policy or person it touched, including changes MDO made on a schedule. Changes made in the Intune portal live in Audit, and the two pages link to each other.

When VirtualCaffeine staff open your tenant to help you, they must give a reason, the session expires, and your Activity shows who looked at which area. You see their name, not their email.

Customer admins and technicians can see Activity, and Owners and Admins can export it as CSV. Audit history and Activity are kept for 13 months. How MDO treats your tenant covers what else MDO keeps.

Read the Audit docs