Intune backup to Azure storage

Separate the storage location from the runner

Selecting Azure storage changes where the tenant's backups are kept. It does not, by itself, move a desktop schedule into the cloud. Decide whether a reliably available admin computer is acceptable or whether the schedule needs an Azure Automation account and managed identity.

Both paths use the tenant's configured storage account. Backups are encrypted before upload and do not pass through a TenuVault server. Keep Azure resource access and costs with your organization's own operating arrangements, and keep the recovery key separately from the computer that initially configured the backup.

Choose and test the storage account

In Backup & Restore, open Schedule and choose Change storage in step 1. The chooser is also available in Settings beside the tenant. Select Your Azure storage account, encrypted, choose the account and use Check access before saving. TenuVault creates the intune-backups container if necessary and writes and deletes a test file.

Your signed-in account needs Storage Blob Data Contributor on the account. A management role alone does not provide blob data access. If the storage firewall restricts networks, use a network it allows. Role assignments can take time to apply, so read the access-check message before changing unrelated settings.

Save the current recovery key when prompted. Azure setup cannot continue until it has been saved, and TenuVault refuses the first encrypted upload without it. Changing a tenant's selected storage does not move old backups; they remain visible only when their original location is selected.

Know what storage access exposes

Backup contents are encrypted, but Azure blob names include object types and display names. Anyone who can list the backup container can therefore learn those names. Audit events stored in the separate audit-logs container are plain JSON. Review container access with these differences in mind.

The Backup Reader and cloud managed identity use the custom TenuVault Backup Writer role on the backup container. It allows reading and writing blobs without deletion or container creation. Their scheduled runs do not write the desktop audit-log container. Do not expand those identities' permissions merely to make a backup location resemble a full admin session.

Set up cloud backups when the computer cannot stay on

First confirm Azure storage in Schedule step 1 and the backup scope in step 2. In step 3 choose In Azure, no computer needed, then pick the frequency, day and time. The calendar shows upcoming runs. Use Deploy to Azure or the documented setup scripts to create the resources, then paste the printed setup output into the app.

Setup needs an Azure administrator able to create the Automation resources and assign the required resource roles, plus a Global Administrator for the managed identity's Microsoft Graph roles. It also needs the administrator's blob data access to check and create the container. Ask the relevant administrators to complete their parts rather than assuming a successful Azure sign-in covers every role.

The deployment includes an Automation account, runbook, schedule, managed identity and Key Vault recovery-key secret. The runbook reads the key at the start of a run and writes backups in the desktop format. Review who can actually read the vault secret, including inherited Azure roles: a reader of that recovery key can decrypt the backups it protects.

Verify the first run and its coverage

After pasting the setup output, inspect the cloud status and the last saved backup in TenuVault. Check Automation job output when a run fails. The managed identity needs the read roles for the selected types; optional device-inventory access controls whether reader-based runs include device categories and device clean-up rules.

Conditional Access is another explicit option: the cloud variable must enable it and the identity needs Policy.Read.All. A manual desktop backup may therefore contain types a cloud backup omits. Compare the actual scope and skipped-type information, not just the total count or the fact that a run completed.

Open a saved encrypted backup from the recovery device using the exported recovery key. This is a useful operational check before depending on the cloud runner during a lost-computer incident. Keep the Azure failure-alert decision from setup and test the monitoring arrangement that will tell you a future run stopped.

Maintain the schedule and retention

Cloud backups do not delete expired backups because the managed identity lacks delete permission. A later desktop backup made with an admin's sign-in applies retention with the usual protections. If a tenant uses only cloud captures, include an occasional admin-sign-in backup in the operating procedure and monitor storage growth.

Rerun setup to change the Azure schedule or scope and paste its updated output into TenuVault. Forget on this computer removes only the app's record; it does not stop the Automation schedule. Use the documented removal workflow when the cloud schedule itself must stop.

• Record the storage account, runner and permissions selected for the tenant.
• Keep a current recovery key and verify it on the recovery device.
• Check skipped types, failed jobs and the first scheduled result.
• Review retention, Azure costs and the actual removal procedure.