Back Up and Restore Microsoft Entra ID with Veeam Backup & Replication v13

In this article, we shall dicuss “How to Back Up and Restore Microsoft Entra ID with Veeam Backup & Replication v13”. Please see Azure Resource Inventory (ARI) for Engineers: Improving Control and Compliance, and Azure Load Balancer: Configuring for SQL Server Always On Availability Group Listener on Azure Virtual Machines. Microsoft Entra ID is the identity plane for everything running in the Microsoft cloud. Identity objects, application identities, administrative scoping, Conditional Access, and related Intune policy configuration all depend on the same Microsoft cloud control plane.

When something in that layer goes wrong, whether a mass deletion, a compromised admin account making sweeping changes, a runaway automation script, or a bad PowerShell one-liner, the impact reaches every downstream service the tenant touches: Microsoft 365, Teams, Intune-managed devices, SaaS applications federated through Entra ID, and Azure resources with role assignments.

Microsoft provides service resiliency and some native recovery paths, but tenant configuration recovery is still something you need to plan and test. Microsoft describes recoverability as a shared responsibility between the cloud provider and your organization. Native restore exists for some recently deleted directory objects and is time-limited, but it is not point-in-time recovery and does not cover every configuration or rollback scenario. More on that below.

This walkthrough covers the full workflow with Veeam: configuring the tenant connection, setting up the backup job, protecting conditional access and Intune policies, and two restore scenarios that show up in the field. The first is a single deleted user recovery. The second is a bulk restore after a mass-delete event.

Veeam Backup & Replication v13 includes the Microsoft Entra ID protection capability introduced in the 12.x line and managed from the VBR console. It is not a v13-only feature. If you have been running it on 12.2 or later, the workflow here will look familiar, with the v13 console changes on top.

What Veeam protects in Entra ID

Per the current Veeam Backup for Microsoft Entra ID user guide, the following object types are protected:

Users
Groups
Administrative units
Roles
Applications
Service principals
Conditional access policies (optional tenant item, covered below)
Intune policies (optional tenant item, covered below)

Property-level restore is supported for these objects, and a metadata comparison view lets you see what changed between a restore point and current tenant state.

Two separate backup jobs exist, and they are configured and licensed differently:

Microsoft Entra ID Tenant backup: the tenant objects, stored in a dedicated PostgreSQL-based Entra ID repository.
Microsoft Entra ID Log backup: audit and sign-in logs, stored in a standard backup repository.

Keep these two straight, because they have different requirements and different restore workflows. A log backup will not run unless a recent tenant backup of the same tenant exists.

Please see Azure Virtual Desktop: Build Custom Session Host Images Using Image Builder Templates [Part 07], and Veeam Agent for Windows: VSS Error Caused by Old SQL Server References.

Native recovery vs backup

Before setting up a backup, it is worth being precise about what Microsoft already gives you natively, because the answer is more than some vendor material implies.

Microsoft Graph exposes a deletedItems restore path for recently deleted directory objects. Per Microsoft Learn, the supported types include users, Microsoft 365 groups, cloud security groups, application registrations, service principals, and administrative units, generally recoverable for up to 30 days. After that window they are permanently deleted.

Conditional access policies and named locations have their own deleted-items path in the Entra admin center, also on a limited window. So the common claim that applications, service principals, administrative units, or security groups have “no recovery path” is not accurate. Many of them do, within the window.

One nuance worth knowing: restoring an application does not automatically restore its associated service principal. You restore the service principal explicitly. Keep that in mind for any app plus service principal recovery, native or otherwise.

Native restore is real and worth using, but it is not a backup, for three reasons:

It is not point-in-time recovery. It restores the object as it was at deletion, not as it was at a chosen moment before a bad change.
It does not solve rollback after unwanted changes. If a policy or attribute was modified rather than deleted, there is nothing in the recycle bin to restore.
It is time-limited and object-dependent. The window is generally 30 days, some object types are hard deleted with no native recovery at all, and object relationships do not always survive a from-scratch recreation once the original IDs are gone.

Treat native soft-delete as your first move for a recent, simple deletion, and treat Conditional Access policies and broader configuration state as things that still need a backup or export and restore strategy. That is the gap Veeam fills: point-in-time restore points, restore after unwanted changes, and coverage for configuration objects and relationships that native soft-delete does not.

Please see Azure Virtual Desktop: Autoscaling Implementing and Monitoring Session Hosts [Part 05], and how to implement Azure Private Link for Azure Virtual Desktop [Part 06].

Licensing and feature notes

Veeam Backup for Microsoft Entra ID is licensed by the number of protected enabled member users. Each 10 protected users consume one Veeam Universal License (VUL) instance. A few specifics that matter for sizing:

Only enabled member users count toward license consumption.
Disabled users and guest users do not consume license instances, but they are still protected where applicable.
Logs do not consume the protected-user licensing that tenant backup uses.
All enabled member users in the organization must be licensed. Microsoft Entra ID does not allow partial user coverage.
Community Edition provides 10 instances, which allows protection of up to 100 enabled member users.

Tenant backup itself is available across license types. Log backup requires Veeam Data Platform Advanced or Premium, and conditional access and Intune policy protection are edition gated as well. Confirm the exact edition requirements for those optional items on the current Veeam licensing documentation for your build, and plan the edition around them, not just the base tenant backup.

Prerequisites and permissions

Before starting, confirm the basics:

Veeam Backup & Replication v13 installed and licensed.
Network access from the VBR server to Microsoft Graph.
A PostgreSQL-based Entra ID repository for the tenant backup, plus a standard backup repository if you also plan to protect logs.
The default general-purpose backup proxy left in place. Veeam Backup for Microsoft Entra ID uses that proxy, so do not remove or disable it.

Permissions split into two parts.

To create a new Entra application during tenant setup, the account you sign in with needs Application Administrator and Privileged Role Administrator, or Global Administrator as an alternative.

For restore, the account you use needs the roles appropriate to the object types you are restoring. Depending on what you restore, that can include Application Administrator, Conditional Access Administrator, Exchange Administrator, Groups Administrator, Privileged Role Administrator, Privileged Authentication Administrator, User Administrator, or Intune Administrator. As an alternative, Global Administrator plus Conditional Access Administrator (recommended) or plus Security Administrator covers the restore roles.

You do not need to memorize that list. The practical takeaway: use an appropriately scoped admin for the object types in play, and if you are restoring conditional access policies, make sure the restore account has Conditional Access Administrator or Security Administrator.

Also, see Azure Virtual Desktop: Manage Azure Virtual Desktop host pools and session hosts using the Azure portal [Part 02], Azure Virtual Desktop: How to set Up Azure Virtual Desktop Insights Monitoring [Part 03], and Azure Virtual Desktop: Connect to Session Hosts Using Entra ID [Part 04].

Add the Entra ID tenant

Tenant registration is a one-time step. Everything else (backup jobs, restores, log jobs) hangs off the tenant object.

VBR v13 console on the Inventory view with the Microsoft Entra ID node selected, showing a registered tenant and the tenant management options

In VBR, go to Inventory and select the Microsoft Entra ID node. The Data Source ribbon gives you Add Tenant, Edit Tenant, and Remove Tenant, and the same options sit on the right-click menu.
Enter the tenant ID and a clear description. Something like contoso-prod beats a blank field when you manage more than one tenant.
Configure the cache repository the wizard uses for temporary metadata staging.
Define the protection scope. Users, groups, administrative units, roles, and applications are core resources. The wizard marks them Essential and will not let you deselect them, because other resources depend on them. Logs sit in the default list as an optional item and can be removed. Conditional access policies and Intune policies do not appear in the default list; you bring them in with the Add option on this step. This is where you set what the tenant can protect, so decide about logs and policies here.
Choose the account type. You can have Veeam create a new Entra application, which registers an application in your tenant with the Graph permissions it needs, or you can specify a pre-created application if your organization requires app registrations to go through change control.
Complete authentication. With a pre-created application, the Authentication step takes the Application ID from your app registration plus a client secret or a certificate. If you let Veeam create the application instead, the wizard walks you through a Microsoft device login with an account that has consent authority.

Tenant wizard Protection Scope step. The core resources are marked Essential and cannot be deselected, logs are optional, and the Add option brings additional resource types into scope

Whichever path you take, review the Graph permissions on the application once and grant admin consent in the tenant. Revoking them later disables both backup and restore, so treat this application registration as part of your protected infrastructure.

Please see Azure Virtual Desktop: Deploy host pools and session hosts in the Azure [Part 01], Disaster Recovery Test Checklist: What to Capture Before You Start, and Upgrading Azure AD Connect to Microsoft Entra Connect Sync.

Create the tenant backup job

The Microsoft Entra ID Tenant Backup Job wizard is straightforward. What the job protects was already decided by the protection scope you set when you added the tenant, so the job itself is mostly tenant selection, retention, and schedule. There is no volume selection the way a VM job has.

Start a new Microsoft Entra ID Tenant Backup Job.
Name the job. Something like Entra ID Tenant - contoso-prod scales when you add a second tenant later.
Select the tenant you registered.
Set the retention policy on the Tenant step. The wizard defaults to 7 days. Veeam keeps the restore points created during the retention window you specify, and thirty days is a reasonable starting point, since it gives you at least one restore point older than the native 30-day soft-delete window. The same step offers secondary destinations if you want the job to copy its backups to another repository.
Configure encryption and notifications under the advanced settings. Turn on encryption. Point notifications at the same distribution list that gets the rest of your VBR alerts.
Set the schedule. Daily outside business hours is a common default. Some environments run more often to reduce how much identity change can happen between recovery points.
Finish the wizard, and optionally run the job immediately.

The tenant backup job running with per-step progress, from repository preparation through building the object list

Remember the dependency: a log backup job needs a recent successful tenant backup of the same tenant. Get the tenant job running and healthy first.

Please see PCI Driver Error: Connection to Deployment Share could not be made, Steps to Fix the “Invalid OS GUID” Error in MDT, and Faulting SecHealthUI: Resolve Windows Defender Notification.

Conditional Access and Intune policy protection

Conditional access policies (CAPs) and Intune policies are optional tenant items. They do not appear in the default protection scope; you opt in by adding them on the Protection Scope step when you add or edit the tenant. They are also edition gated, so confirm the requirement for your Veeam Data Platform edition on the current licensing page before you plan around them.

Conditional access policies protect the tenant’s authentication surface. Losing them is either a continuity problem, where users cannot sign in the way they should, or a security problem, where users can sign in in ways they should not. They are worth protecting.

How you turn CAP protection on depends on the version you are running:

On VBR v13, CAP backup and restore support is built in and needs no registry change. Add CAPs to the protection scope on the tenant, and if you let Veeam create the Entra application, the console can configure the required Graph permissions during tenant registration.
On 12.3.1 and 12.3.2, where the capability was backported from v13, it is off by default. Per Veeam KB4696 and the 12.x documentation, you opt in on the backup server by setting EntraIdBackupSupportsConditionalAccessPolicyRestore (DWORD, set to 1) under HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\, then grant the Graph permissions by hand. If you are still on 12.3.x, do that before expecting CAPs to show up in a backup.

The Graph permissions and roles are the same either way:

For CAP backup, the Entra application used for backup needs the Policy.Read.All (application) permission. For CAP restore, the application needs Policy.ReadWrite.ConditionalAccess (delegated) and Agreement.Read.All (delegated).
For restore, the account you sign in with needs the Conditional Access Administrator or Security Administrator role.

For Intune policy protection, the application needs the DeviceManagementConfiguration.Read.All (application) permission in addition to the base set.

If you let Veeam create the application when you add the tenant, and the protection scope already includes CAPs and Intune policies, Veeam grants the permissions the scope needs. The permissions above are the ones people most often have to add by hand when they turn on CAP or Intune protection later, against an application that was created before those items were in scope. Check the exact list on the current Veeam permissions page for your build before granting anything, since the permission set has changed across releases.

After the next successful tenant backup, verify the conditional access policies appear in the restore browser before you rely on them. Do not assume they are protected just because the tenant job is running.

Intune policy protection is edition gated the same way and, like the rest of the tenant objects, appears in the restore browser once a successful backup includes it. Validate visibility the same way.

Please see how to set up Veeam Backup for Microsoft Azure, how to install and configure Veeam Backup and Replication 11 Community Edition with its default SQL Server Express Edition.

Restore scenario 1: Recovering a single deleted user

The most common Entra ID restore is the individual user. Someone gets offboarded, the automation runs, and a couple of days later it turns out the account had a role on a project that still needs it. Now you need the account back.

If the user is still inside the native 30-day soft-delete window, native Entra ID restore is the first option and the least disruptive path. Reach for Veeam when native restore is not enough: past the soft-delete window, wrong state at deletion time, or an object type that did not land in the recycle bin.

To restore a single user from a Veeam backup:

In VBR, open the tenant backup and start the Microsoft Entra ID Tenant Restore wizard. This is a purpose-built restore interface, separate from the classic Veeam Explorer used for Active Directory.
Select the restore point closest to the last known good state. Objects are grouped by type.
Under users, find the account by UPN or display name and select it.
Choose the full restore action, since a deleted user has no live object to compare against.
Authenticate with the device code flow, using an account with the roles needed to recreate a user.
Set the restore options. A deleted user recreated from backup needs a default password. Set a temporary password that forces a reset at next sign-in per your policy. Choose how to handle the case where an object with the same identity already exists.
Enter a restore reason. It lands in the job log and the audit trail, so make it specific enough that a future reviewer understands why the restore happened.
Start the restore and track it in the job view.

A word of caution on what a restore does and does not bring back. Veeam restores supported properties and relationships captured in the restore point, such as user attributes and supported membership or assignment data, subject to Microsoft Graph and Veeam restore limitations.

One licensing dependency to know: per Veeam’s supported properties documentation, protection of role assignment data depends on the tenant having Microsoft Entra ID P2 and Governance licenses, so do not assume every tenant gets full role assignment protection. Plan for users to re-register authentication methods if the restored state does not include current MFA or passkey methods, or if tenant policy requires re-registration. Validate the account’s state after restore rather than assuming a given attribute or method came back.

After the restore, confirm the account in the Entra admin center and check that the properties you expected from that restore point are present.

To get Veeam Backup for Azure setup, please follow the steps described below and or get it from the following link “Veeam Backup for Microsoft Azure Free Edition“. You may also want to see “How to implement N2WS Veeam Cloud Protection Manager (CPM 2.3.0d), and how to recover backup via N2WS Veeam CPM.

Restore scenario 2: Bulk recovery after a mass deletion

The mass-delete scenario is the one where a backup does something native soft-delete cannot. A compromised admin credential, an automation misfire against a bad filter, or a service principal with too much Graph access can delete dozens or hundreds of objects in a short window. Some may still be inside soft-delete, some not.

The workflow is the same wizard, with a few limits that shape how you run it.

Identify the last known good restore point. Use the Entra ID audit log (or your Veeam log backup, if you have it) to find when the deletion started, and pick a restore point from just before that time.
Open the Microsoft Entra ID Tenant Restore wizard and select that restore point.
In the object browser, select the affected objects. Restore one object type per session. You cannot restore multiple item types (for example, users and groups) in the same restore session, so plan a pass per type.
Keep the per-session ceiling in mind. A single restore session can restore up to 1,000 items. If more than 1,000 objects of a type are affected, split the work into multiple sessions.
Run the full restore for the selected objects.
Authenticate with the device code flow using an account with the right roles for that object type.
Set the restore options at the batch level. For recreated users, the default password applies to the batch. Set a temporary password that forces reset. Choose conflict handling deliberately: if some objects were recreated by hand during incident response, decide whether the backup state or the manual state should win.
Enter a specific restore reason, including an incident ticket number if this is incident response.
Start the restore and watch the per-object status.

One relationship detail worth planning for: a service principal that represents an application should be restored together with its application, in the same restore session. If you restore the application separately, it can come back with a new application ID that the service principal will not recognize, and the service principal restore can fail.

Bulk restores are still API-driven operations, so time depends on object count, tenant load, throttling, and the object types being restored. Do not promise a fixed rate to stakeholders. The wizard shows per-object status, and failed objects can be retried.

After the restore, the follow-up is standard incident recovery: reset passwords for affected users, have them re-enroll authentication methods, spot-check that critical accounts can sign in, and record the actual recovery time and data currency in your postmortem.

You may want to see H ow to find Dfs Referral Path and clear Dfs referral Cache and how to install Veeam Backup and Replication 11 Community Edition with a dedicated SQL Server

Log backup: where it fits

Log backup is a separate job and a separate workflow from tenant backup.

The Microsoft Entra ID Log Backup Job protects audit and sign-in logs and writes them to a standard backup repository. It requires Veeam Data Platform Advanced or Premium, and it depends on a recent tenant backup of the same tenant existing first. Note the Microsoft side too: a free Microsoft Entra ID license allows audit log backup only, so sign-in log backup needs a paid Entra ID license tier.

Log restore is not the same as tenant restore. Logs are exported for review rather than pushed back into the tenant as live objects. If your reason for protecting logs is compliance, forensics, or incident timelines, that export model is usually what you want. Just do not expect a log restore to recreate tenant objects. That is the tenant restore workflow’s job.

Testing restores

Having Entra ID backups and being able to restore Entra ID under pressure are two different things. Test the restore path before you need it.

Read-only verification is quick. Open a recent restore point in the wizard, browse the object tree, confirm the expected users and groups are present, and close without restoring. This tells you the backup is browseable and the wizard works, which covers a lot of what a real restore needs.
Metadata comparison is the middle ground. Compare a restore point against current tenant state for a selected object without executing anything. This confirms the backup holds the object state you expect.
Non-production tenant testing is the only way to exercise the write path end to end. If you have a test tenant, connect it as a second Veeam tenant, back it up, delete some objects, and run a full restore. This is what surfaces the failure modes that only appear at restore time: a missing Graph permission that was fine for backup but blocks a write, or a conditional access policy that references something no longer present.

Here are some exciting articles: How to uninstall Veeam Backup and Replication from your server, how to fix Failed to connect to Veeam Backup & Replication Server: No connection could be made because the target machine actively refused it, how to Fix critical Veeam Backup and Replication 9.5, 10, and 11, and how to fix Veeam Agent Vulnerability: Fix Veeam Agent vulnerability for veeam agent.

Practical considerations and limits

A few things worth knowing before you go live.

Licensing counts enabled member users only. Guests and disabled accounts do not count. Size the license for your enabled member population, not your total directory.

Tenant backup data is stored in the PostgreSQL-based Entra ID repository, not a standard VBR backup repository, so protect the PostgreSQL repository and the VBR server as part of the overall DR design. If you lose the VBR server and the Entra ID repository, you lose the ability to restore even if the tenant backup data existed.

Log backups use standard backup repositories and should follow your normal repository hardening, copy, and immutability design where supported.

Note the current documented limits that shape a design:

One tenant backup job per tenant, and one job protects only one tenant. You cannot protect multiple tenants with a single job, and you cannot point multiple jobs at the same tenant.
China, Azure Government, external tenants, and Azure AD B2C tenants are not supported for this feature.
Veeam does not support restore of Entra built-in roles, distribution groups, or mail-enabled security groups.
A restore session handles one item type at a time and up to 1,000 items. Plan passes accordingly.
Restore a service principal together with its application in the same session when the relationship matters.
Tenant backups go to the PostgreSQL-based Entra ID repository, so standard backup-repository features like immutability apply to log backups rather than the tenant backup. Protect the PostgreSQL repository directly.
Conditional access policy and Intune policy protection are edition gated. Verify the requirement for your edition on the current Veeam licensing page.
Log backup requires Advanced or Premium and has its own separate limitations. With a free Microsoft Entra ID license you can back up audit logs only, not sign-in logs.

On the Microsoft side, remember that native soft-delete already covers the recent, simple deletion for supported object types, as covered earlier. What a backup adds is point-in-time restore, rollback after unwanted changes, and coverage for configuration state and relationships beyond the recycle bin. Document the group type for the groups that matter in your environment, since native recovery behavior differs by group type.

Restore may not bring back current authentication method registrations. Plan for affected users to re-register MFA or passkey methods after a restore if the restored state does not include them or if tenant policy requires re-registration, and put that step in the runbook.

Please see these related guides: Active Directory Forest – Trees and Domain and Sites, and how to replicate MDT Deployment Share: How to create a Selection Profile and a Linked MDT Deployment Shares.

Wrap-up

Veeam Backup & Replication v13 carries forward the Entra ID protection introduced in the 12.x line and manages it from the VBR console. It gives you point-in-time backup and restore for users, groups, administrative units, roles, applications, service principals, and, with the right edition and setup, conditional access and Intune policies.

The two scenarios that matter most operationally, single-user recovery after the soft-delete window closes and bulk recovery after a mass delete, run through the same Microsoft Entra ID Tenant Restore wizard, with a few limits to design around: one item type per session, 1,000 items per session, and service principals restored alongside their applications.

Know what a restore does not bring back (authentication method registrations and sign-in history), confirm optional items like conditional access policies actually appear in the restore browser, and test the write path against a non-production tenant before you have to trust it. Do that, and you have real recovery for the identity layer that everything else depends on.

I hope you found this article on “Back Up and Restore Microsoft Entra ID with Veeam Backup & Replication v13” very useful. Please feel free to leave a comment below.