Intune policy version history

Define what a saved version means

A snapshot records the policy as it was when a backup read it. If an admin edits the same policy several times before the next backup, those intermediate versions do not exist in backup history. The next comparison shows the net difference between the saved points, not a separate revision for each save.

Begin by identifying the policy type and object ID, along with its name. A deleted policy recreated with the same display name is a different object. Keep the identity in the investigation record so a rename or recreation is not mistaken for continuous history of one policy.

• Compare recent changes across the tenant

Trace the policy through Backup History

Open Backup & Restore for the tenant and stay on Backup History. Backup Timeline lists the stored backups newest first. Note which backups bracket the change window, then select a backup and open View Changes in Backup Details. The Changes in this backup dialog names both saved points it compares.

This view compares the selected backup with the newest eligible older backup, rather than offering an arbitrary pair selector. Look for the policy by name and type among the changed, deleted or added items. Expand a changed item to inspect the old and new setting values, and repeat for adjacent saved points when you need to trace a longer sequence.

For a version inventory, inspect the policy JSON in a downloaded copy of the relevant backup where the archive qualifies for download. Keep a short record of the backup time, policy identity, reason for the change and whether you consider that saved configuration suitable for recovery. The record is your version-selection aid; it is not another built-in timeline screen.

Read gaps and comparison limits correctly

Failed and incomplete backups are skipped when choosing the preceding comparison point. Backups that completed with warnings can participate, but only types held completely in both backups are compared. A type excluded from one side is not reported as added or deleted just because its files are absent.

The setting view omits bookkeeping values such as modification timestamps and version counters. It shows details for the first 100 changed items, with up to 50 settings each, and shortens long values. Some properties, including descriptions, are not listed in the setting details, so Changed without a visible setting list does not necessarily mean the comparison is wrong.

Choose a version before restoring it

Decide whether you need the last version before an incident or a deliberately approved earlier configuration. Read the settings, not just the backup date: a backup taken shortly before a reported incident can already contain an unwanted edit. Use audit evidence and your change record to narrow the sequence.

Choose an older backup that actually contains the required policy and dependencies. If you need to see current configuration against the newest saved point, run a new backup first. TenuVault comparisons operate on saved data, so looking at an old backup does not automatically read the policy as it is now.

For the first recovery test, restore an unassigned copy and compare it with the saved version. Community supports one item at a time in that mode. Replacing supported items in place, restoring several items and restoring assignments need Pro or MSP; these are separate decisions from selecting an older version.

Keep enough history to make the next choice possible

In Settings, Background runner, choose Keep backups for. The setting applies across tenants on that computer. Community retains at most 30 days; Pro and MSP follow the selected longer period. Confirm that your retention choice covers the change-review window you actually need.

Retention normally runs after a backup that saved its selected scope successfully. A partial-scope backup does not remove the newest complete copy of types it left out. Azure backups made by the Backup Reader or cloud runner do not delete expired backups themselves; an admin sign-in backup applies retention later. If admins share storage, review their retention settings together.

• Storage, recovery keys and retention

Policy-history checklist

Finish the investigation with a record another admin can follow. State which saved version you chose and why, which settings you checked and what still needs to be supplied outside the snapshot. Keep the current destination backup until the recovery has been verified.

• Record the policy type, object ID and any name changes.
• List the saved points examined and any gaps in scope or completeness.
• Correlate audit events separately if you need the author and operation time.
• Test the selected version as an unassigned copy before wider use.