Blog
What an Intune restore drill finds that a backup report never will
A backup report tells you that a job ran and how many items it saved. It cannot tell you whether those items come back. The only way to know is to restore something, look at the result and write down what you had to fix. Here is what that usually turns up, including two things I found in my own lab tenant while writing these posts.
By Ugur Koc · Published · 4 min read
In short
- A backup report proves a job finished. A restore drill proves you can recover.
- Drills find masked secrets, missing compliance actions, missing installers, expired Apple certificates and tokens, and assignments to groups that no longer exist.
- My own lab had restored copies with **** as their secret value, and an Apple push certificate and enrollment token that had expired months earlier.
- Start with one unassigned policy restored as a copy. It changes nothing in production and still tests the whole path.
Why a green report is not enough
Backups fail quietly in ways a status page cannot show. A job can finish while a script was saved without its content or a compliance policy without its block action, because the API returned what it was asked for and nothing more. I tested which Intune data Microsoft Graph only returns on request, and the list is longer than most people expect.
A drill turns that unknown into a list. Not a benchmark, and not a promise about rebuilding a whole tenant: a list of what worked, what needed manual steps and who had to be involved.
Five things a drill finds
| What the drill finds | Why the report missed it | Fix |
|---|---|---|
| Secrets restored as **** | Encrypted OMA-URI values read as **** unless the tool asks for the plain-text value. Restoring the mask succeeds. | Check restored custom profiles with getOmaSettingPlainTextValue, and restore only from backups that saved the real value. |
| Compliance policies without a block action | A list call does not return actions for noncompliance. | Make sure backups expand scheduledActionsForRule, then restore again. |
| Apps that cannot come back | The app record restores, but Graph never returns the installer. | Keep installers and .intunewin packages in your own repository. |
| Expired Apple certificates and tokens | They are not policies, so no backup report mentions them. | Track expiry dates and the Apple ID that owns them. |
| Assignments to deleted groups | Assignments store group IDs. The backup saves the ID, not the group. | Check that target groups exist before you restore assignments. |
What I found in my own lab
My lab tenant is where I test TenuVault, so it sees more restores than most production tenants. While writing the Graph post, I found two things.
First, two custom profiles created by an earlier restore hold the literal value **** instead of their encrypted setting. The original profile returns <disabled/>. Both copies were unassigned, so no device received them, but nothing in the admin center would have warned me.
Second, the Apple MDM push certificate expired in March 2026 and the automated device enrollment token in April. Microsoft gives a 30-day grace period after the push certificate expires. Neither shows up in a backup report, because neither is a policy. A drill that includes a look at Apple certificates and tokens catches both.
A drill you can run this week
- Pick one unassigned test policy, such as a settings catalog policy with a few settings you can recognize.
- Back it up and open the backup. Check that the settings are really there, not only the policy name.
- Restore it as a copy, with assignments off. Nothing in production changes.
- Compare the copy with the original setting by setting, and note anything you had to fix by hand.
- Write down the time it took, the tool version and every manual step. That record is the evidence behind your recovery plan.
- Delete the test copy through your normal change process.
The step-by-step restore drill guide walks through this with TenuVault, but the steps work with any tool. Once the copy restore works, plan separate drills for in-place restores, assignments and cross-tenant copies, because a copy test does not cover them.
Add what no backup holds
Once a quarter, extend the drill to the items outside the backup:
- Apple MDM push certificate: the expiry date and the Apple ID that renews it.
- Automated device enrollment and VPP tokens: expiry dates and who can sign in to Apple Business Manager or Apple School Manager.
- App installers: pick one Win32 app and confirm you can find its installer and package it again.
- Recovery keys and admin access: confirm that a second admin can open a backup without your computer.
- Tenant-wide compliance settings and the Conditional Access policies that depend on them. Why they matter.