Your own Intune export script or a backup app

Side by side

The table compares a typical export script that an admin or team maintains with TenuVault. Your script may do more or less than this; the rows are the questions worth asking of either one.

What a script does well

A script is transparent. You can read every request it sends, and nothing runs that you did not write or review. It costs nothing to license, needs no new software approved, and runs wherever PowerShell runs, including a server or a build pipeline with no one signed in.

Its output is plain JSON. Kept in a Git repository, that gives you history, pull request review of configuration changes and a diff of every edit, which is a good way to manage configuration as code. A script can also export what TenuVault leaves out, such as Entra groups and Conditional Access policies, and feed other systems you already run.

If your team already writes Graph code, maintaining an export script is a reasonable use of that skill, and nothing on this page says otherwise.

Why exporting is the easy half

A first export script is short: list each collection and save each object. A complete one needs more, because Graph does not return everything an Intune object needs in the first response.

• Settings catalog policies keep their settings and assignments in separate collections. Administrative Templates need their definition values and then the presentation values of each one. Compliance policies keep their actions for noncompliance in a separate collection.
• Collections are paged, and Graph throttles. For most Intune configuration areas Microsoft allows 2,000 requests per 20 seconds per tenant and 1,000 per app. A script that does not follow the next page link and wait as the Retry-After header says can save part of a tenant and still report success.
• Encrypted values in custom OMA-URI profiles come back masked. Reading them in plain text needs a separate getOmaSettingPlainTextValue request for each value.
• Built-in objects should be skipped, and some are hard to recognize. Microsoft provided remediations carry a flag, but built-in app categories can only be told apart by a placeholder modified date.
• Settings catalog policies, PowerShell scripts, remediations and endpoint security intents are only in Microsoft Graph beta. Microsoft supports the Intune beta APIs but says they change more often than v1.0. A script keeps working until a property or type changes, and then it fails or quietly skips data.

• Microsoft Graph throttling limits for Intune
• Intune beta API support (settings catalog policy resource)

Where restore gets hard

Most scripts are tested by exporting. The real test is putting a deleted policy back at a bad moment, and that is where a script needs the most code.

• Read-only properties such as IDs, version numbers and creation times have to be removed before an object can be created again.
• Order matters. Scope tags, assignment filters, Intune roles, app categories, notification templates and reusable settings have to exist before the policies that reference them, and policy sets have to come last.
• Every recreated object gets a new ID. References to it from other objects in the same restore have to be pointed at the new ID.
• Assignments are sent in a separate request after the object exists, and some types cannot have their assignments replaced in place: Windows Autopilot deployment profiles, Apple user enrollment profiles, terms and conditions and Intune roles.
• Tenant defaults, such as the default enrollment configuration and the default Company Portal branding, cannot be created. They have to be updated in place.
• When a create request times out, the object may or may not exist. A script that simply retries can create a duplicate, and an object created in several steps can be left half finished.

• Restore modes and assignments
• What cannot be restored

How TenuVault handles the same problems

TenuVault backs up 40 Intune object types in nine areas, with their assignments where Intune has them. Restore creates the objects others depend on first, such as scope tags, assignment filters and app categories, and points later items at the new IDs. A restore write whose response was lost is recorded and blocked until you check Intune, so a retry cannot create a duplicate. If an object built in several steps fails halfway and it is safe to resume, a retry repairs the remaining steps on the same object instead of creating another one.

Community restores one item at a time as a new, unassigned copy. Pro and MSP add restoring many items at once, replacing items in place, recreating deleted items under their original names and restoring assignments. Before anything is written, the restore review shows what will happen to each item, and on Pro and MSP a dry run can check that every file in a backup can be read, decrypted and turned into a restore.

Backups are encrypted with AES-256-GCM on the admin's computer and kept in a local folder or network share, or on Pro and MSP in your own Azure storage account. Any backup can be downloaded as a ZIP of plain JSON, so you can read or archive it without TenuVault. TenuVault signs in as the admin through an app registration in your own tenant with no client secret, so MFA, Conditional Access and the admin's Intune role apply.

• Restore Intune policies
• What gets backed up
• Encryption and recovery key

What TenuVault does not do

These limits matter most to someone who already has a working script. Each one links to the page that explains it.

• App installer files, Apple tokens and private keys, because Microsoft Graph does not return them. A script cannot export them either, but it can copy your packaging share or certificate store next to its export if you build that.
• TenuVault backs up Intune configuration only. Entra objects such as groups and Conditional Access policies are not in its backups. Assignments are saved as references to Entra groups; the groups themselves are not backed up.
• TenuVault has no command line or API, so it does not run inside a pipeline. Configuration-as-code workflows with pull requests stay with your script.
• Scheduled backups run in the desktop app while it runs on a signed-in computer: weekly on Community, daily on Pro and MSP. On Pro and MSP, cloud backups run the schedule in an Azure Automation account in your own subscription, so no computer has to be on.
• Restores and every other change run with your own sign-in. The read-only identities that scheduled backups can use never write to Intune.
• TenuVault can only import backups it made itself, so exports from your own scripts cannot be loaded into it. Your history in TenuVault starts with its first backup.

• What gets backed up
• What cannot be restored
• Backup Reader for scheduled backups
• Cloud backups in Azure

When you do not need TenuVault

Keep your script, and skip TenuVault, if most of these describe you:

• Your script exports every type you use, and you have restored a deleted policy from it in a drill, with its assignments.
• You manage Intune configuration as code, with pull requests and Git history, and want to keep it that way.
• Backups have to run headless on a server or in a pipeline, with no desktop app.
• You already export Entra groups and Conditional Access with the same tooling and want one process for all of it.
• You run one small tenant that rarely changes, and the person who maintains the script is staying.

When TenuVault saves you time

TenuVault is worth trying when these sound familiar:

• Restore has to work under pressure, by someone other than the script's author, with a review of each item before anything is written.
• Deleted policies should come back under their original names with their assignments, in the right order.
• You look after several tenants and want the same backups, schedules and restore steps in each.
• You want to see which settings changed between two backups without writing your own comparison.
• The person who wrote the script has left, or Graph changes keep breaking it.

Running both

Many teams do not have to choose. A script can stay the source for Git and configuration-as-code, while TenuVault covers restore. TenuVault uses its own app registration, so the two do not affect each other, and a TenuVault backup can be downloaded as plain JSON whenever you want to compare it with your script's output.

Try it next to your script

You can test TenuVault without changing anything your script does:

• Create the TenuVault app registration with the setup script and sign in with your own admin account.
• Run a first backup and compare its item count per type with your script's latest export.
• Restore one unassigned test policy as a copy, which is available on Community, and compare its settings with the original.
• Keep your script running until a restore drill from TenuVault has passed.

• Practice restoring an Intune policy
• Does Microsoft Intune have a built-in backup?
• Intune backup