Troubleshooting

Backup issues

A resource type shows Error during export

The most common cause is a missing Graph permission. The error message in the status row will usually say Forbidden or 403. Click the consent link that appears (or navigate to Settings > Permissions) and consent to the missing scope. Then retry the export.

If the error says Not Found or 404, the resource type may not be provisioned for your tenant (for example, Intune Branding requires a specific Intune license tier).

A resource type exports 0 items but items exist in Intune

Some resource types use list endpoints that do not support the roleScopeTagIds field in the $select parameter. IntuneAssistant handles this automatically for Conditional Access, Assignment Filters, Scope Tags, Named Locations, Authentication Strengths, Terms of Use, and Intune Branding. If you see 0 items for another type, check whether the account used has read permission for that resource in Intune.

The ZIP download is empty or very small

If all resource types errored, the ZIP still downloads but the folders will be empty or absent. Review the error messages in the status table before downloading.

Restore issues

Import fails with "HTTP 400: Requested value 'X' was not found"

This error comes from the Microsoft Graph / Intune backend rejecting an enum value in the policy JSON.

App Protection Policies: This almost always means the policy is being sent to the wrong endpoint. IntuneAssistant detects the platform (iOS/Android/Windows) from the @odata.type field in the JSON. If @odata.type is missing (common in backups from external tools such as IntuneManagement), the detection falls back to the file name. Make sure the file name contains iOS, iPadOS, or Android for the correct routing to apply.

If @odata.type is present and routing is correct, the field value may be a deprecated enum member that the current Intune backend no longer accepts. Common deprecated values include managedApps in appGroupType (the backend removed this value; IntuneAssistant maps it to selectedPublicApps automatically). If you see a value not listed in this table, open a support request.

Windows App Protection: The Windows App Protection endpoint uses different enum types than iOS and Android. Values such as managedApps or managedAppsWithPasteIn are valid for iOS/Android but not for Windows. If iOS or Android policies are failing with Windows-style errors, the platform detection may have failed. Check the file name.

Import fails with "Must have one and only one block scheduled action"

Compliance policies require at least one scheduled action in the scheduledActionsForRule array, and each action must include at least one scheduledActionConfigurations entry. If the backup was created without expanding this relationship, IntuneAssistant injects a default block action automatically. If this error still appears, the backup JSON may have an empty or malformed scheduledActionsForRule array that was not created by IntuneAssistant. Edit the JSON file directly to add a valid configuration before re-importing.

Import fails with "Cannot create abstract class" or "Unknown entity type"

This error means the @odata.type field is missing or incorrect in the JSON payload. IntuneAssistant preserves @odata.type in the backup output and strips other OData annotations. If you are importing from an external tool that omits @odata.type, the resource type cannot be restored for types where Graph requires a concrete subtype (Compliance Policies, Named Locations, Device Configuration). There is no automatic workaround; you need to add the correct @odata.type value to the JSON file manually.

Import fails with "SecretReferenceValueId is not valid for create"

Settings Catalog policies can contain settings backed by key vault secret references. These references are tenant-specific and cannot be restored to a different tenant. IntuneAssistant detects and removes these settings automatically, then shows a warning in the import result. The policy is created without the affected settings. You must re-configure those settings manually in the target tenant.

Conditional Access import fails with error 1010 "At least one include rule required"

Graph rejects a Conditional Access policy where includeUsers, includeGroups, and includeRoles are all empty. This happens when the original policy targeted only groups that were removed before the backup, or when Skip assignments is on and the policy did not target All Users. IntuneAssistant sets includeUsers to ["none"] in this case to satisfy Graph validation. The imported policy will show as targeting "None" and must be reconfigured.

Named locations are missing after import

Named location IDs are tenant-specific GUIDs. Any Conditional Access policy that references named locations will have those references stripped on import because the IDs do not carry over to the target tenant. After import, open each Conditional Access policy that uses location conditions and reassign the correct named locations.

Terms of Use are missing after import

Terms of Use IDs are tenant-specific. References to Terms of Use are stripped automatically from Conditional Access grant controls on import. Re-assign Terms of Use to the relevant policies after import.

Custom authentication strength is missing after import

Only the three Microsoft built-in authentication strength IDs are preserved on import. Any custom strength reference is nulled out because the ID does not exist in the target tenant. The import will succeed and show a warning. Re-assign the custom authentication strength after importing it separately.

"Microsoft proprietary script — cannot be created via API"

Some Device Health Scripts are managed by Microsoft globally (isGlobalScript: true) and cannot be created, modified, or deleted through the API. These items are greyed out in the review table and excluded from the import automatically. There is nothing to do; the script is already present in every Intune tenant.

"All users and all devices" enrollment restriction cannot be restored

The default enrollment restriction (All Users, All Devices) is a built-in Intune policy that exists in every tenant. It cannot be created through the API. Any attempt to import it will fail. IntuneAssistant does not currently detect this automatically; you will see a 403 or conflict error. Exclude this item from the import manually.

Notification templates are reset after import

Notification template IDs are tenant-specific. If a compliance policy references a custom notification template, IntuneAssistant resets the reference to the default empty template GUID on import. A warning is shown in the import result. Re-assign notification templates to compliance policies after import.

Administrative Template definition values are missing after import

Definition values (the actual GPO settings) require separate API calls after the Administrative Template object is created. IntuneAssistant creates the template object (name, description, assignments) but does not restore the individual settings. This is a known limitation. Configure the settings manually after import.

Feature Update Profile fails with "unsupported version"

If the backup contains a Feature Update Profile targeting a Windows version that has reached end of life (for example, Windows 11 22H2), Intune will reject the create request. There is no workaround; update the version field in the JSON file before importing.

The import button is disabled or shows a 401

Restore requires write permissions that are separate from the read permissions used for backup. If you consented only to read permissions, the restore will prompt for additional consent. Follow the consent link and approve the write scopes.

I see "IDW10502" in the error

This is an MSAL token acquisition error. Sign out of IntuneAssistant and sign back in, then retry the operation.

Compatibility with external backup tools

IntuneAssistant can restore backups created by the IntuneManagement tool (also known as IM). Key differences to be aware of:

IntuneManagement exports may not include @odata.type in each JSON file. IntuneAssistant falls back to file-name-based detection for App Protection policies.
The folder structure must match: one folder per resource type, with the folder name matching the IntuneAssistant resource type name (for example, AppProtection, SettingsCatalog).
Items backed up with IntuneManagement may contain deprecated field values from older API versions. IntuneAssistant maps known deprecated values automatically (see App Protection section above).

Last updated 8 days ago