Blog

I tested what Microsoft Graph returns for Intune backups. Here is what no tool can save.

Every Intune backup tool reads the same API. The community PowerShell scripts, the large Microsoft 365 backup vendors and TenuVault, the tool I build, all get Intune configuration from Microsoft Graph. So anything Graph does not return, no backup can contain. I wanted a list based on real responses instead of assumptions, so I queried my own lab tenant and wrote down what came back.

By Ugur Koc · Published 23 October 2026 · 7 min read

In short

Graph never returns Win32 app installer files, the Apple MDM push certificate, the Apple automated device enrollment token or Autopilot hardware hashes. Keep those outside Intune.
Script content, settings catalog settings, compliance actions, assignments and encrypted OMA-URI values only come back when a tool asks for them with extra calls.
In my lab I found two restored custom profiles whose secret value was the literal text ****, because an earlier restore had copied the masked value.
Tenant-wide compliance settings, Entra groups and Conditional Access sit outside the Intune policy lists that most backups read.

How I tested

On 23 October 2026 I sent read-only GET requests to the Microsoft Graph beta endpoint. Most Intune tools read beta, because many Intune settings only exist there. I used an app registration with read access to Intune configuration, apps and enrollment. Nothing was created, changed or deleted.

A lab tenant has limits. Mine has no VPP token, no Microsoft Tunnel and no certificate connector, so I list those separately as not tested instead of guessing.

What Graph never returns

These items have no download path in Graph. A backup can save their metadata, but not the thing you would need to recreate them.

Intune items Microsoft Graph does not return, tested on 23 October 2026
Item	What Graph returned	What to keep instead
Win32 and line-of-business app installers	The file list under `contentVersions/{id}/files` gives the name, size and commit state of the `.intunewin` file. `azureStorageUri` is null: a storage URL only exists while a file is being uploaded.	The original installers and packaged `.intunewin` files, in a source repository you control.
Apple MDM push certificate	`/deviceManagement/applePushNotificationCertificate` returns the Apple ID, topic, serial number and expiry date. The `certificate` field is null.	The Apple ID that created the certificate, and more than one person who can sign in with it.
Apple automated device enrollment token	`/deviceManagement/depOnboardingSettings` returns the token name, Apple ID, expiry date and sync status. The response has no token value.	Access to Apple Business Manager or Apple School Manager, so you can download a new token.
Autopilot hardware hashes	`windowsAutopilotDeviceIdentities` returns serial number, model and profile status. The type has no hash property: selecting `hardwareIdentifier` fails with Could not find a property.	The hash files you uploaded, or a reseller or OEM registration you can repeat.

The Apple items need the most care. Microsoft says to renew the push certificate with the same Apple account you used to create it, and the certificate is valid for 365 days with a 30-day grace period after it expires. If the person who owns that Apple ID leaves, a backup will not help you.

What only comes back if a tool asks

This is the part that separates backup tools. The data is in Graph, but a plain list call does not include it. A tool that saves only the list response produces a backup that looks complete and cannot be restored.

Intune data that Microsoft Graph returns only with extra calls
Data	In the list response	How to get it
PowerShell script content	`scriptContent` is null	Read each script on its own: `GET /deviceManagement/deviceManagementScripts/{id}` returns the content, base64 encoded.
Remediation scripts	`detectionScriptContent` and `remediationScriptContent` are empty strings	Read each remediation on its own: `GET /deviceManagement/deviceHealthScripts/{id}`.
Settings catalog settings	Only `settingCount`	`GET /deviceManagement/configurationPolicies/{id}/settings`
Compliance actions, including the block action	Not returned, even when `scheduledActionsForRule` is named in `$select`	`$expand=scheduledActionsForRule($expand=scheduledActionConfigurations)`
Assignments	Not returned	`GET .../{id}/assignments`, or `$expand=assignments` where the type supports it
Encrypted OMA-URI values	`****`, with `isEncrypted` set to true	`getOmaSettingPlainTextValue(secretReferenceValueId='...')` on the profile

Two rows deserve a second look. The remediation list returned empty strings, not null, which is easy to mistake for a script that really is empty. And a compliance policy needs its block action to be created again, so a backup without the actions cannot recreate the policy as it was.

The **** trap I found in my own tenant

The encrypted OMA-URI row is not theoretical. My lab has an older custom profile that sets a Windows Package Manager policy with an encrypted string value, and two later copies of it that an earlier restore created. All three show **** in a normal GET.

Asking Graph for the plain-text value shows the difference. The original returns <disabled/>, the value it was created with. Both restored copies return ****. The restore had copied the mask, so those profiles would send four asterisks to devices instead of the setting.

Both copies were unassigned, so no device ever received them. In production, a copy like that gets assigned, reports success and does nothing useful. The admin center does not flag it, because **** is what every encrypted value looks like there.

What lives outside the Intune policy lists

Entra groups. Assignments store group IDs. If a group is deleted and not restored, the assignment points at nothing. Groups are Entra objects, so an Intune backup does not contain them.
Conditional Access policies. They decide what a noncompliant device can reach, and they live in Entra ID, not Intune.
Tenant-wide compliance settings. GET /deviceManagement/settings returns them, including secureByDefault, the setting behind Mark devices with no compliance policy assigned as. They are not a policy, so tools that walk the policy lists can miss them. TenuVault backs them up and can restore them in place on Pro and MSP. With any other tool, check that your backup includes them, or write them down. Why that setting matters.
Partner and connector setup. The mobile threat defense connector returned its platform switches and last heartbeat, but the pairing itself is set up on the partner side. Managed Google Play returned its bind status and owner fields, and binding again means signing in with a Google account.
Device inventory. Enrolled devices are not configuration. Recovering configuration does not enroll a single device again.

Not tested in my lab

My lab has none of these, so I can't show you a response. Treat them as items to check in your own tenant:

Apple VPP tokens
Microsoft Tunnel sites and servers
Certificate connectors, and the private keys behind PKCS and SCEP certificates
Wi-Fi and VPN profiles with pre-shared keys or passwords

An offline kit for what no backup holds

Keep this somewhere that does not depend on your Intune tenant or your admin computer:

Installers and .intunewin packages for every Win32 and line-of-business app, with their install commands and detection rules.
The Apple ID behind the MDM push certificate, its expiry date and who can sign in with it.
Apple Business Manager or Apple School Manager access for the enrollment token and any VPP tokens.
Autopilot hardware hash files, or the reseller who registered your devices.
The Google account that binds Managed Google Play.
Partner connector setup: who owns the account on the partner side and how to pair it again.
Tenant-wide compliance settings and the Conditional Access policies that depend on them.
Recovery keys and admin access for your backup tool, stored away from the admin computer.

Questions to ask any backup tool

When you evaluate a tool, including mine, ask how it handles the second table. A tool that reads only list responses shows a green backup report and gives you scripts without content.

Does it read script and remediation content one item at a time?
Does it save settings catalog settings, compliance actions and assignments?
How does it handle encrypted OMA-URI values, and does it refuse to restore a **** mask?
Does it tell you which items it skipped and which ones it cannot restore?
Have you restored from it? A backup you have never restored is a guess.

TenuVault makes these extra calls, saves the plain-text OMA-URI value inside the encrypted backup and refuses to restore a masked value. What gets backed up and what cannot be restored list exactly what it does and does not do. Whatever tool you use, run a restore drill before you need it.