Storage setup

Backups stay in your Azure subscription. MDO writes backup files to a storage account you own. MDO stores the storage app’s client ID and Object ID, the storage account and container names, and the client secret, encrypted with AES-256-GCM. It holds no storage account keys and no SAS tokens.

Open Settings › Storage and backup, with the tenant selected in the tenant switcher. The page is titled Backup Storage. Its wizard has five steps. Steps 1 to 4 set up policy and app metadata backups. Step 5 is optional and backs up Win32 installer files as well.

---

Step 1: Register the storage app

In the Azure portal for the tenant you are setting up:

1. Microsoft Entra ID → App registrations → New registration. Name it MDO Storage (or anything your team will recognize), choose Accounts in this organizational directory only, leave the redirect URI blank and click Register.
2. Certificates & secrets → New client secret. 24 months is a sensible expiry. Copy the secret Value straight away; Azure only shows it once.
3. Note the Application (client) ID from the app’s overview.
4. Find the service principal Object ID: Microsoft Entra ID → Enterprise applications, search for MDO Storage, then Overview → Object ID.

Use the Enterprise applications Object ID. The “Object ID” on the App registrations page is a different value. If you use it, the role assignment in step 2 points at the wrong principal and the connection test fails with AuthorizationPermissionMismatch.

Enter the client ID, the service principal Object ID and the client secret in the wizard. MDO encrypts the secret as soon as it is saved.

The wizard also asks you to grant the app the Microsoft Graph permission DeviceManagementApps.Read.All. Policy backups work without it. Step 5 uses it to download installer files from Intune.

Step 2: Deploy the template

1. Download mdo-storage-setup.json. It is an ARM template that already contains the Object ID you saved in step 1.
2. In the Azure portal, search for Deploy a custom template and choose Build your own template in the editor.
3. Paste the JSON, click Save, then Review + create and Create.

The template creates the storage account and its containers, and gives your storage app the Storage Blob Data Contributor role on it. A brand-new subscription may need the Microsoft.Storage resource provider registered first (Subscriptions → your subscription → Resource providers).

When Azure shows that the deployment is complete, return to MDO and continue.

Other setup methods, under the same step:

• PowerShell: download mdo-storage-setup.ps1. It takes the same parameters as the template and can be run again safely.
• Manual: create a storage account and a container, then add a role assignment on the storage account: Access control (IAM) → Add role assignment → Storage Blob Data Contributor, and select your MDO Storage app as the member.

Step 3: Connect storage

Enter the storage account name and the container name (mdo-backups unless you changed it). MDO runs a connection test: it uploads a small test file, reads it back and deletes it.

Step 4: Configure backup

• Backups enabled: backups are off until you switch this on.
• Cron expression: when backups run, in UTC. The default 0 2 * * * runs daily at 02:00 UTC.
• Retention (days): backup folders older than this are deleted at the end of each backup run. The default is 90.

Retest connection runs the step 3 test again.

The app backup options on this step set the default backup tier for apps: exclude, metadata or full. You can change the tier for each app on the Apps page.

Step 5 (optional): installer files

Policy and app metadata backups run from MDO and need nothing in your subscription beyond the storage account. To keep copies of the Win32 installer files as well (the full tier), step 5 deploys an Automation Account and an MDO runbook into your subscription. The runbook downloads each app’s content from Intune straight into your container, so the files never pass through MDO. Skip this step if metadata is enough.

---

Troubleshooting

Failure	Likely cause	Fix
AuthorizationPermissionMismatch	The role assignment is missing or hasn’t propagated yet.	Wait 60 to 90 seconds and retest. If it persists, check the role assignment on the storage account.
AuthorizationPermissionMismatch although the role assignment exists	The assignment uses the App registration Object ID instead of the Enterprise application Object ID.	Save the correct Object ID in step 1, download the template again and redeploy, or fix the assignment in IAM.
AuthenticationFailed	The client secret is wrong or has expired.	Create a new secret and enter it in step 1.
BadRequest: invalid storage account name	The name has uppercase or special characters.	Storage account names are 3 to 24 lowercase letters and numbers.
The connection test times out	The storage account’s network rules block MDO.	Under the storage account’s Networking, allow public network access, or ask us for MDO’s outbound IP addresses to allow.

Revoking access

Delete the storage app’s client secret in Azure, or delete the app registration. MDO has no other credential for your storage account.