> For the complete documentation index, see [llms.txt](https://docs.intuneassistant.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.intuneassistant.cloud/intune-assistant/backup-restore/health-scan.md). # Backup health scan The health scan checks a backup against your tenant before you restore it or start a new process in Assignments Manager. It shows which groups, assignment filters and policies from the backup already exist in the tenant, which are missing, and which exist but differ. The scan itself only reads from your tenant. Creating missing groups and filters is a separate step you start yourself (see below). ## Comparing with another tenant instead of a backup You do not need a backup file. Next to the drop zone, **Your own tenant** compares the tenant you are working in with another tenant, for example your own consultancy tenant when you are working in a customer's tenant. 1. Choose **Connect a tenant**. A Microsoft sign-in window opens. Choose the account of the tenant to copy from. 2. If that tenant is not onboarded in IntuneAssistant yet, the page says so and offers **Onboard this tenant**, which opens onboarding in a new tab. When it is done, choose **I have onboarded it, check again**. 3. The tenant is read once, only read, and compared with the tenant you are working in. From here the page works as it does with a backup: the guided flow, connections and gaps, and, with the Config Management module, creating and deploying into the tenant you are working in. A banner shows which tenant is the reference and when it was read. **Refresh** reads it again, so you compare with its current state. **Disconnect** forgets the sign-in. The sign-in for the reference tenant lives in this browser tab only. Nothing about that tenant is stored on our servers, and closing or reloading the tab ends it. The reference is never written to, and the tenant you work in stays the only place anything is created. Choosing the same tenant you are working in is refused, because that would compare a tenant with itself. ## How to use it 1. Open **Configuration Management → Health scan**. 2. Drop a backup ZIP on the page, or click to choose one. 3. Wait for the scan. Each type in the backup is checked in turn and the results appear as they come in. 4. Use the filter buttons to show only Missing or Differs, or search by name. 5. Open a row with an arrow to see why it differs. ## What you'll see At the top are counts for Exists, Missing, Differs and Not checked. Below them the items are grouped by type. Each row shows how the item was found, its status and the object id in the tenant. | Status | Meaning | | ----------- | ------------------------------------------------------ | | Exists | The tenant has the item. | | Missing | The tenant has no item with this name. | | Differs | The tenant has the item, but its content is different. | | Not checked | The scan can't check this type yet. | * **Filters** are compared on their rule and platform, not only the name. A filter with the same name but a different rule shows as Differs, with the backup rule on the first line and the tenant rule on the second. * **Groups** are compared on the group type and, for dynamic groups, the membership rule. Only the group itself is in the backup, never its members. * **Names** are matched exactly first. If only extra spaces differ, the item still counts as found and the row says so. ## Create missing groups and filters With the Config Management module, missing groups, assignment filters and scope tags can be created straight from the scan. 1. Tick the missing rows you want, or choose **Select all missing** on a type. 2. Choose **Create selected** and confirm. 3. Each row updates: created items now show as Exists, items that could not be created show the reason when you open the row. * Items that exist already, or exist but differ, are never changed. * The tenant is checked again right before creating, so running it twice never creates anything twice. * A created group gets a **new id**. It is created empty, without members. Policies restored later that point at the old id don't point at the new group. * Role-assignable groups are not created from a backup. Create them manually. * Creating groups needs `Group.ReadWrite.All` and creating scope tags needs `DeviceManagementRBAC.ReadWrite.All`. Both are part of the Config Management permissions: the permission check shows them as missing until an admin consents, and creating those items asks for consent until then. ## Settings of existing policies For Settings Catalog policies that exist in the tenant, the scan also looks inside the policy, setting by setting. A policy is **Differs** when a setting from the backup is missing in the tenant policy, or has a different value. Open the row to see each setting by its name and description, with the value in the backup and the value in the tenant (choices show their label, such as Enabled, instead of an id). The technical setting id is shown under the name. Under **What differs** only the values that are really different are listed, such as "Wake on LAN on is in the backup but not in the tenant", with the group they belong to for settings that hold several groups (power plans, for example). **Show all values** reveals the complete setting. Settings that only exist in the tenant are not reported, and settings with secret values are left out because Microsoft never returns them. With the Config Management module you can set single differences back to the backup value: 1. Open a Differs row and tick the settings (or the filter rule) you want to restore. **Select all in this policy** ticks every setting of that policy at once. 2. Choose **Restore selected** and confirm. 3. Restored differences disappear from the row. If the tenant refuses one, the reason is shown under it and the others are still restored. * A missing setting is added, a different one is set to the backup value. Nothing is ever removed from the policy. The settings you tick for one policy are saved together: if the tenant refuses the save, none of them is changed and the reason is shown. * The tenant is checked again right before restoring, so a value that already matches is left alone. * A filter with the same name but a different rule can have its **rule** restored. The platform of a filter can't be changed, so that difference is shown without a checkbox. * Policies that don't exist yet are not repaired here. Restore them with Restore. * Other policy types are matched by name only for now. ## The virtual tenant After the scan, **Get this tenant ready** is a guided flow. It starts with one line (how much of the backup is in place, how much is to do, how much waits) and a progress bar, then the steps a restore has to take, lowest level first: scope tags, groups, assignment filters, other resources (named locations, authentication strengths, terms of use, notification templates, compliance scripts), policies and Conditional Access. Only one step is open at a time: the first step with work left, marked **Start here**. Click another step to look at it, or use Previous and Next step. A step lists at most six things at first (**Show all** for the rest), says what is to create, change, choose or do by hand, and links an item that waits to the step it waits for. * **What every id is here.** A backup refers to scope tags, groups, assignment filters, named locations, authentication strengths and terms of use by id, and ids only mean something in the tenant they came from. The plan maps each one to your tenant: first by the same id (for ids that are globally unique), then by the same name, then by the name ignoring extra spaces and case. Scope tags are only ever matched by name, because tag 2 in one tenant is not tag 2 in another. If several of your items have the same name, it says **Ambiguous** and lists them, instead of picking one. The mapping table is folded under the steps. * **What each step says.** Every item is something to create, change, choose, do by hand, something that **waits** for an earlier step (a policy that needs a scope tag that doesn't exist yet), or already done. Terms of use can't be created from here (the backup holds no PDF), and neither can items the backup holds no definition for; they are listed so you can create them by hand. * **Do this step.** With the Config Management module, a step with missing items has a button that creates exactly those items, never changing existing items, and then scans again so the next step opens with an up-to-date state. Policies and Conditional Access are restored from Restore. Without the module the flow is read-only, and **Copy checklist** puts the step's to-do list on the clipboard so it can be done by hand. * **Details.** The Details button on an item opens its connections and gaps below; the summary numbers, the connections and the full resource list are all folded under the flow. ## Connections and gaps **Connections and gaps** shows the same virtual layer one thing at a time, as cards joined by dashed coloured lines, in the style of the Settings Library "How this fits" view. The card in the middle is the item you picked; on the left is what it **needs first** (its scope tag, groups, filters, locations, templates), on the right what it **unlocks**. For a policy the right side shows its **assignments**, one card each, from the backup or the reference tenant: whether it is an include group, an exclude group, All devices or All users, the group, the filter with its type (include or exclude), and for apps the intent. An assignment says **Blocked** when its group or filter is not in your tenant yet (or several are called the same), and otherwise that the group and filter exist. Click any card to move there (an assignment card takes you to its group or filter), or click **Connections** on a row of the plan. The page opens on the **core parts**; **Advanced** (above the plan) switches to everything. The core view narrows the whole page: the plan shows only the scope tag, group and filter steps, the counts and the list cover only those, and Connections and gaps connects only core parts to each other (a group and its nested groups; the policies that use a group show under Advanced). The dot on a card says what is the case in your tenant: | Colour | Meaning | | ------ | -------------------------------------------------------- | | Green | In place, or exists in your tenant | | Yellow | Differs from your tenant's copy | | Blue | Missing, and ready to create | | Orange | Blocked by something that is missing | | Red | Missing in your tenant (a scope tag, group, filter, ...) | | Purple | Ambiguous: several of your items have this name | | Grey | The backup does not say what this id is | Under the cards, the **gap view** puts the virtual layer next to the real tenant for the picked item: for each difference, what it should be (the backup) against what it is (your tenant), what it is waiting for (with a button to go to it), and, for a policy missing by name, how much of it your tenant already configures elsewhere. The list of all resources sits below, folded. ### Restoring from the connections With the Config Management module, the cards that are missing from your tenant and can be created from the backup have a checkbox. Tick one or more, then **Create selected**. They are created lowest level first (scope tags, groups, filters, building blocks, policies, Conditional Access), so a policy is only sent after the scope tag it needs exists. **Select this and what it needs** ticks the card in the middle and everything it needs that can be created, so one click gets an item to the point it can be restored. Each of those cards also has its own **Deploy** button, to create just that one without ticking anything. The card is updated in place: it turns green, and the cards that were blocked by it turn ready straight away. If it could not be deployed, the reason shows under the card and the button stays so you can try again. When a selection has been created the page checks the tenant again: the cards that were waiting for what you just created turn from blocked to ready, and can be ticked next. The page shows what was created and, for anything that was not, the reason. Nothing that already exists in the tenant is changed, and creating the same selection twice creates nothing twice. Policies are created with the tenant's own scope tags, groups and filters, translated by name. A policy that still needs something the tenant does not have is not created and says what it is waiting for. Conditional Access policies are always created in report-only mode, whatever state the backup has them in. Applications, uploaded ADMX files and terms of use cannot be created from here. Without the module there are no checkboxes. ## What is checked for each type The scan asks the same two questions for every type in the backup: 1. **Is there an item with this name, and is its content the same?** If not, the row shows exactly which values differ, grouped per property (for example "Password minimum length: 12 in the backup, 8 in the tenant"). 2. **If there is no item with this name, is the content already there under another name?** The row shows **Similar · NN%** and the closest existing item. | Type | Content compared | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Settings Catalog | Every setting, including nested settings and groups of settings | | Device configuration, compliance, app protection, app configuration, enrollment restrictions and status page, Autopilot, update profiles, scripts, administrative templates, endpoint security, notification templates, branding, terms of use, Conditional Access, named locations, authentication strengths | Every configured value | | Assignment filters | Rule and platform | | Groups | Group type and, for dynamic groups, the membership rule | | Scope tags, applications, uploaded ADMX files | Name only | Ids, dates, assignments, scope tags and description text are ignored, the order of lists doesn't matter, and secrets Microsoft never returns (encrypted values, masked XML) are left out. A value counts as configured when it is set and isn't just a default such as false or 0. Group and scope tag ids inside a policy differ between tenants, so a Conditional Access policy that names groups can show those as differences. ## Scope tags are compared by name A scope tag on a policy is only a number, and the same number is a different scope tag in another tenant. Tag 2 can be "26H2" in the tenant the backup came from and "WINDOWS" in yours. The scan therefore translates the numbers with the scope tags that are in the backup (the **ScopeTags** folder) and compares by name. A policy that carries "26H2" in the backup but "WINDOWS" in the tenant shows a **Scope tags** difference, even though both have tag 2. A policy whose tag has another number but the same name is not a difference. If the scope tag from the backup doesn't exist in your tenant at all, the row says so. Backups without a ScopeTags folder, and types that don't support scope tags, are not compared on scope tags. ## Assignments are compared by name An assignment is made of ids: a group id and sometimes a filter id. Those ids only mean something in the tenant they came from. The scan translates them into names, using the **Groups** and **AssignmentFilters** folders of the backup for the backup side and your tenant for the other side, and compares what the assignment means: "Include group SG-Win-Pilot with filter Windows 11 (include)". The same group under different ids is not a difference. The same id for a different group is. Include versus exclude, all devices, all users and the filter type all count. The row lists the assignments that are in the backup but not on the policy, and the ones on the policy that aren't in the backup. When the group or filter from the backup doesn't exist in your tenant at all, it says so, because that needs a different fix (create the group first) than an assignment that is simply missing from this policy. Assignments are compared only when the backup holds its Groups folder. Older backups without it can't be translated, so their assignments are not compared; make a new backup to get this. Assignments are shown but can't be restored from the scan yet. ## Conditional Access is compared by name too A Conditional Access policy refers to groups, named locations, authentication strengths and terms of use by id, and those ids differ between tenants. The scan translates them to names before comparing, using the backup's **NamedLocations**, **AuthenticationStrengths** and **TermsOfUse** folders and your tenant. The same location under another id is not a difference, and a different location behind the same kind of condition is. The three built-in authentication strengths are recognised in every tenant. Two things can't be translated, and the row says so instead of showing differences that aren't real: * **Groups** whose name is neither in the backup (it only holds groups that Intune assignments use) nor known to your tenant by the same id. * **Specific users.** A user is an id with no name in a backup, so specific users are never compared. Keywords such as All users and Guests or external users are. ## Policies that exist under another name A policy that is **Missing** by name may already exist in your tenant under a different name, or be spread over several policies. For every missing policy the scan therefore also checks its settings against everything configured in your tenant. The row shows **Similar · 94%** in the *Found by* column, and the details show: * how many of its settings are already configured with the same value somewhere, how many with a different value, and how many are not configured at all; * the closest existing policy and how many settings it shares. At 90% or more the details warn that the policy may already exist under another name, so check before restoring it to avoid a duplicate. This only gives information: nothing is linked or changed, and it is available without the Config Management module. A setting counts as the same when its value is identical; secret values and Microsoft's template bookkeeping are ignored. ## After you create or restore With the Config Management module, the page scans the affected types again after **Create selected** or **Restore selected**, so you see the real state: new ids, and the differences that remain. New groups can take a moment to appear in Entra, so the page waits a few seconds before it checks again. If something could not be created or restored, the reason stays on its row. ## Groups in your backups New backups contain a **Groups** folder (the **Groups (placeholders)** row in the backup list, on by default; untick it to leave groups out) with a placeholder for every group that an Intune assignment targets (include or exclude). Groups that are only used in Conditional Access are not included. A placeholder holds the group's name, type, description and dynamic rule. It never holds members or owners. Backups made before this release have no Groups folder. For those the scan still checks the groups its policies are assigned to, listed as **Groups (found in assignments)**: the backup only knows their ids, so each group is shown as found (under its real name) or missing. Such a group can't be created from the scan, because the backup holds no name or type for it. The folder also holds the groups that are direct members of an assigned group (nested groups, one level only: users, devices and deeper levels are not read, and dynamic groups are skipped), each as a placeholder of its own; the placeholder of the group lists them. In **Connections and gaps** the view is from the main group: select a group and its nested groups show as small rows under it, joined by a pink line; select a nested group and the main group shows as a full card above it. Each says whether it is a member in your tenant, with **Add to group** when it is not; click a card to move there. The scan also reads the groups that are direct members of the matching group in your tenant (compared by name, because ids differ between tenants): the row says **member in your tenant** or **not a member yet**, and a group that lacks a nested group shows as different. With the Config Management module, **Add to group** on a nested group that is not a member yet makes it a member of its parent in your tenant (the group must exist, a dynamic group cannot have groups as members, and a membership that already exists is never written twice). Backups made before this have no nested groups, and creating missing groups still creates empty placeholders: it does not add a nested group to its parent; use **Add to group** for that. ## Requirements * An active customer. * Permission to read groups in the tenant (`Group.Read.All`). If your tenant hasn't granted it yet, you're asked to consent the first time. * To create missing items: the Config Management module, with its permissions approved. The setup is on the **Modules** tab under **Customer Settings**, in the **Configuration Management** card; see [After a module is activated](/intune-assistant/modules/getting-started.md). ## Common questions **Does the scan change my tenant?** No. Only the **Create selected** action does, and only for the rows you ticked. **Why is a group shown as missing when I restored into another tenant?** Group ids differ between tenants. The scan looks for the id first, then for the name. A group is only missing when neither exists. **Why is a folder shown with "Scan failed"?** A request for that folder failed (the error is shown in the banner). The rows that did come back are kept and **Retry** scans the folder again. **Why does a policy of another type not show differences?** Only Settings Catalog policies are compared setting by setting. Other types are matched by name. **Why is an app or other type "Not checked"?** The scan doesn't support that type yet.