# Welcome ## What Is Intune Assistant? **Intune Assistant** is a community platform built for Microsoft Intune administrators. It gives you visibility, insight, and control over your Intune environment that simply does not exist in the native Microsoft Intune portal. Everything is designed to answer the questions you actually ask in your day-to-day work — faster and with less clicking. At its core, Intune Assistant is **free for all Intune administrators**. The community features have no limitations and no expiry date. Optional licensed extensions are available for organizations that need automation, scheduled actions, advanced reporting, or human support. ## Who Is This Documentation For? This documentation is written to be understood by everyone who works with or around Microsoft Intune, regardless of how technical their role is: | Role | How You Will Use Intune Assistant | | ----------------------------- | -------------------------------------------------------------------------------------------- | | **IT Administrator** | Day-to-day operations — checking assignments, troubleshooting user issues, auditing policies | | **Infrastructure Architect** | Designing and validating the structure of your Intune environment | | **Security Engineer** | Auditing configuration settings, detecting conflicts, reviewing Conditional Access | | **CISO / Compliance Officer** | Evidence of policy coverage, exportable reports, assignment and configuration audits | | **Helpdesk / Service Desk** | Looking up what applies to a specific user or device without needing Intune portal access | ## What Can Intune Assistant Do? Intune Assistant is organized into several sections. Here is a quick overview of what is available and documented. ### Jump right in

:rocket:

QuickstartGet started with Intune AssistantQuickstart
Security overviewGet security information about Intune AssistantBroken link

ExtensionsGo to the Intune Assistant ExtensionsBroken link
### Assignments The Assignments section is the most widely used part of Intune Assistant. It lets you answer the question *"what is assigned to whom, and how?"* across your entire tenant — for policies, configurations, and applications. Start getting insights using one of the features below. | Page | What It Does | | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | [All Assignments](/intune-assistant/assignments/all-assignments) | Tenant-wide view of every assignment across every resource type | | [App Assignments](/intune-assistant/assignments/app-assignments) | Application-only view with install type (Required / Available / Uninstall) | | [Group Assignments](/intune-assistant/assignments/group-assignments) | Pick a group and see everything assigned to it, including nested group resolution | | [Filter Assignments](/intune-assistant/assignments/assignments-with-filters) | Explore how assignment filters are used and where each filter is applied | | [User Assignments](/intune-assistant/assignments/user-assignments) | Landing page for user-centric assignment lookup | ### Configuration The Configuration section gives you complete visibility into your Intune configuration policies — at both the policy level and the individual setting level. It spans all three policy engines in Intune: the modern Settings Catalog, legacy Device Configuration profiles, and Group Policy ingested via ADMX. | Page | What It Does | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Configuration Overview](broken://pages/f875085d1850d78fe389ffcadfdd7fb21e094aaa) | Landing page explaining the two views and how they work together | | [Settings Overview](broken://pages/c6db0642daec8117849388262aa382ca0660a625) | Setting-by-setting breakdown across all policy types. Automatically detects and flags duplicate and conflicting settings across overlapping assignments | ### Conditional Access *(coming soon in docs)* Review and analyse Conditional Access policies across your tenant. Understand which users and conditions each policy targets, and export the full policy set for audit or documentation purposes. ### Devices *(coming soon in docs)* Monitor device compliance status, enrolled device inventory, and configuration state across all platforms (Windows, iOS, Android, macOS). ### Compare *(coming soon in docs)* Side-by-side policy comparison between tenants or between policy versions — useful for validating migrations, comparing environments, and identifying drift. ## How Intune Assistant Works Intune Assistant connects to your Microsoft Intune tenant using **Microsoft Graph API** with delegated permissions through your own Azure AD / Entra ID account. It does not store your data — every page fetches live data from Microsoft Graph at the time you request it. Authentication follows the standard Microsoft MSAL (Microsoft Authentication Library) flow: 1. You sign in with your Microsoft 365 work account 2. Intune Assistant requests only the Graph permissions it needs for the features you use 3. All data is fetched in real time and displayed in your browser session 4. Nothing is persisted on Intune Assistant servers {% hint style="info" %} **Multi-tenant:** If you manage multiple tenants (for example as an MSP or GDAP partner), you can switch between tenants using the tenant selector in the interface. All views automatically scope to the selected tenant. {% endhint %} ## Key Concepts Understanding a few core concepts will help you get more out of the documentation. ### Assignment Targets Intune assigns policies and apps to **targets**. A target can be: * **Entra ID Group** — a specific Entra AD group (included or excluded) * **All Users** — every licensed user in the tenant * **All Devices** — every enrolled device in the tenant ### Assignment Filters An **assignment filter** refines which devices within a target group are actually evaluated for a policy. Filters are based on device properties (OS version, manufacturer, ownership type, etc.) and can either **include** (only evaluate if the rule matches) or **exclude** (skip if the rule matches) specific devices. ### Nested Groups Azure AD supports group nesting — a group can be a member of another group. Intune Assistant resolves nesting automatically. When you look up a user or group, you see assignments that arrive via parent groups too, not just direct targeting. ### Policy Sources Intune has three engines for device configuration: | Source | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------- | | **Settings Catalog** | The modern, recommended way to configure settings. Covers thousands of individual settings per platform | | **Device Configuration** | Older profile-based configuration, including OMA-URI custom settings | | **Group Policy** | ADMX-based settings ingested into Intune via Administrative Templates or Group Policy Analytics | ## Getting Started If you are new to Intune Assistant, here is the recommended starting path: 1. **Onboard your tenant** (first time only) by following the [Quickstart](/getting-started/quickstart): open the [onboarding page](https://community.intuneassistant.cloud/onboarding/register/), sign in, create your account and grant admin consent for your tenant 2. **Sign in** at [community.intuneassistant.cloud](https://community.intuneassistant.cloud/) with your Microsoft 365 work account 3. **Select your tenant** from the tenant picker if you manage multiple environments 4. Navigate to **Assistant → Assignments → All Assignments** and click **Load Data** to see your full assignment landscape 5. Navigate to **Configuration → Policy Overview** and click **Load Policies** to see your policy inventory 6. Navigate to **Configuration → Settings Overview** and click **Load Settings** to run the duplicate and conflict analysis {% hint style="info" %} **Tip — Start with the assignment overview.** The most common use case for a new user is understanding the assignment landscape. The [All Assignments](/intune-assistant/assignments/all-assignments) page gives you the broadest view with the fewest clicks. {% endhint %} {% hint style="info" %} **Tip — For troubleshooting a specific user.** Go straight to [User Configuration Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-configuration-profiles) or [User App Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-apps) and search for the user by name or email address. {% endhint %} ## Feedback and Contributions Found something missing or unclear in the documentation? Spotted a bug in the product? * **Product feedback:** Use the feedback option in the app or visit [community.intuneassistant.cloud](https://community.intuneassistant.cloud/) * **Documentation:** Raise an issue or submit a pull request in the repository *Intune Assistant — built by the community, for the community.* ## Beta program Intune Assistant continues gets new features. Every feature is tested as much as possible in several different environments. If you want to early test features as well and join the beta program, send the builder a message using LinkedIn. You well get very early access to new features. # Quickstart This page has a brief description about how to get started. Welcome to **IntuneAssistant**! Thank you for choosing this tool to enhance your Microsoft Intune management experience. This guide will walk you through the onboarding process to get your tenant connected and ready to use all features. {% hint style="info" %} Onboarding connects your Microsoft tenant to IntuneAssistant by consenting our applications to access your Intune environment. This secure process enables the tool to retrieve and display your tenant data while maintaining strict privacy standards. {% endhint %} ### Why onboarding is needed Intune Assistant relies on its own API backend. Meaning that only authenticated users with the correct application can use that API backend. Also, the API backend itself relies on permissions.
Two Key Applications During onboarding, two applications will be registered in your tenant: 1. **IntuneAssistant Application (**3448bc04-cdbe-4a07-8e24-7e0e6f6980c1**)** - The main web interface you'll use 2. **IntuneAssistant API Application (**afe66ddf-67d4-4d61-8a51-beca7b799f52**)** - Handles secure data retrieval from your tenant {% hint style="warning" %} Privacy Commitment **No tenant or user data is stored in the backend database.** Only your tenant ID and domain are registered for licensing and security purposes. All Intune data shown in the application exists only in your browser session and is gone when you log out. {% endhint %} ## Onboarding Process Getting started with IntuneAssistant takes three steps, all on the onboarding page. The page shows which step you are on and will not let you continue until the previous one is done. {% hint style="warning" %} **You must sign in first.** The onboarding page asks you to sign in before you can create your account. If you open the page and are not signed in yet, you see a **Sign in with Microsoft** button instead of the account form — that is step 1, not an error. {% endhint %} {% stepper %} {% step %} ### Open the onboarding page Go to [community.intuneassistant.cloud/onboarding/register](https://community.intuneassistant.cloud/onboarding/register/), or click **Start here** on the home page. {% endstep %} {% step %} ### Step 1 — Sign in Click **Sign in with Microsoft** and sign in with the work account of the tenant you want to onboard. The first time, Microsoft asks you to accept the **IntuneAssistant** application (`3448bc04-cdbe-4a07-8e24-7e0e6f6980c1`). This is the sign-in app that the backend API trusts; it does not grant any permissions on your Intune data yet. After signing in you return to the onboarding page automatically. {% endstep %} {% step %} ### Step 2 — Create your account Enter your company or display name (it is pre-filled with your sign-in domain) and click **Continue**. This registers your organisation in the IntuneAssistant backend. Only your tenant ID and domain are stored. {% endstep %} {% step %} ### Step 3 — Connect your tenant Click **Grant admin consent**. A Microsoft consent window opens where you sign in as a **Global Administrator** and accept the **IntuneAssistant API** application (`afe66ddf-67d4-4d61-8a51-beca7b799f52`). These are the permissions the tool uses to read your Intune data on your behalf. {% endstep %} {% step %} ### Ready to use IntuneAssistant After successful consent you are redirected to the dashboard with your tenant connected. The next time you open IntuneAssistant, just sign in — the onboarding steps are only needed once per tenant. {% endstep %} {% endstepper %} {% hint style="info" %} Security & Privacy **No tenant data is stored in the backend database.** Only your tenant ID and domain are registered for licensing and security purposes. All Intune data shown in the application exists only in your browser session and is removed when you log out.\ For more details, please refer to the [Security page](https://intuneassistant.cloud/security/). {% endhint %} ### New Applications in Your Tenant Check your Azure AD App Registrations - you should see two new applications: * **IntuneAssistant** - Main application for user authentication * **IntuneAssistant API** - Backend service for data retrieval ## Next Steps Now that your tenant is onboarded, explore these key areas: * **Assignment Management** — Start managing your Intune assignments efficiently * **Device Overview** — Monitor and manage your enrolled devices ## Troubleshooting Having issues with onboarding? Check our troubleshooting guide: * **The page asks me to sign in, but I wanted to create my account**: signing in is step 1 of onboarding. Click **Sign in with Microsoft**; you come back to the same page to continue with step 2. * **Unauthorized (401) when creating the account**: your sign-in session has expired. Reload the page and sign in again. * **Consent errors**: Ensure you have Global Administrator permissions * **Application not visible**: Check Azure AD App Registrations after 5-10 minutes * **Access denied**: Verify your account has appropriate Intune permissions *** **Need help?** Visit the project's GitHub page and create an issue for community support, or [contact our support team](broken://spaces/AYRPLqjJYwEvPiJdZ7kR/pages/4Y6zZvOXfgqEThVnoexh) for personalized assistance. Visit GitHub Repository # Searching and Filtering Tables Every table in Intune Assistant has a search box above it. You can use it to quickly narrow down long lists of policies, devices, assignments, and other items. ## How to use it Type any word into the search box and the table instantly shows only the rows that contain it, anywhere in any column. To exclude rows instead of finding them, put an exclamation mark (`!`) directly in front of a word. Rows containing that word will be hidden. You can combine as many words as you like, separated by spaces. Every word you type without `!` must be present in a row, and every word with `!` must be absent, for that row to show up. ### Examples | You type | What you get | | ----------------- | ------------------------------------------------------ | | `compliant` | Only rows that contain "compliant" | | `!test` | All rows except those that contain "test" | | `compliant !test` | Rows that contain "compliant" but not "test" | | `!test !android` | All rows except those that mention "test" or "android" | ## What you'll see While you type, the table updates automatically. A counter above the table shows how many rows match out of the total, for example "3 of 5 results". Hover over the small info icon next to the search box for a quick reminder of this syntax. ## Requirements No special license or permission is needed. This works on every table across the app, for any user who can already see that table. ## Tips * Search is not case-sensitive. * Search looks at every column of a row, not just the ones currently visible on screen. * Clear the search box (using the "x" button) to see the full list again. # Frequently Asked Questions Common questions and answers about Intune Assistant Find answers to the most commonly asked questions about Intune Assistant.
What is Intune Assistant? Intune Assistant is a tool that helps Intune Administrators get insights into their Intune environment.
Is Intune Assistant free? Yes, Intune Assistant is free to use and build for the community. All features will stay free to use and are not limited.
But, I also see paid extensions That is correct, there are paid extensions. However, these are not extra features on top of the free community features.\ \ Extensions are fully supported (by humans) and build with business logic that took very much effort in cooperation with customers. They are highly scalable and ask much more effort to maintain.\ See it as a different product build on the same Intune Assistant backend. More information can be found at the [extension documentation](https://github.com/srozemuller/IntuneAssistant.Backend/blob/main/IntuneAssistant.Docs/public/extensions/README.md).
Who built Intune Assistant? Intune Assistant is built by [Sander Rozemuller](https://www.rozemuller.com/). He is a Microsoft MVP in the category Security (Intune) and Microsoft Graph API. You can find more information about him on his [LinkedIn](https://www.linkedin.com/in/srozemuller/) or check his [MVP profile](https://mvp.microsoft.com/en-us/PublicProfile/5004451?fullName=Sander%20Rozemuller).
Is using Intune Assistant safe? Yes, using Intune Assistant is a safe process. It works under user context and connects to a tenant on behalf of the user.
What about the data? Intune Assistant does **NOT** store any tenant sensitive data. It only reads the data from the tenant and displays it in the UI. If you log out and close the browser, the data is gone.
How does it work? Intune Assistant uses an app registration consented during the onboarding process. The app registration has only the needed READ permissions. When a user logs in, the app registration is used under user context to get the data from the tenant.
Do I need to sign in before I can onboard my tenant? Yes. The onboarding page has three steps: **sign in**, **create your account**, and **connect your tenant**. The first step signs you in with your Microsoft work account and asks you to accept the Intune Assistant sign-in application. Only after that can the account be created, because every call to the Intune Assistant API is made on behalf of the signed-in user. If you open the onboarding page and see a **Sign in with Microsoft** button instead of the account form, that is step 1 — sign in and you return to the same page to continue. See the [Quickstart](/getting-started/quickstart) for the full walkthrough.
I read something about the Intune Assistant API? That is great to hear! The Intune Assistant API is a sort of aggregation layer. The API harvests many Graph API endpoints and combines data to something that is useful. In fact, the Intune Assistant API is just a data shipper that streamlines Graph data to the web interface as well as the Intune CLI.
What permissions does Intune Assistant need? Intune Assistant relies on Graph API permissions in combination with the user's permissions. But always with Zero Trust in mind (least privilege). The permissions are basically READ permissions. For a full detailed overview, check [the permissions overview](broken://pages/a139ed7c655e2e59c794b1b67adf067eadaf6e06).
Can I see more about the source code? Yes, the web interface as well as the CLI source code is available on GitHub. You can find the repo [here](https://github.com/srozemuller/IntuneAssistant).
I want to request a feature That is great! In the repo there is a template available for requesting features. You can find it [here](https://github.com/srozemuller/IntuneAssistant/issues/new/choose). Use it also for bugs or other issues.
Why is Intune Assistant a web interface only? Intune Assistant is a web interface because it helps users get up to speed quickly. Also, not everyone has a subscription to store resources.
Will Intune Assistant become available as a single instance to run on my own platform? Yes, Intune Assistant will become available as a single instance to run on your own platform. It is on the roadmap but not yet available. Coming soon We are currently working on a direct restore functionality to avoid this extra step in the future.
### General
Where can I find the source code? The frontend project is completely open source and available on [GitHub](https://github.com/srozemuller/IntuneAssistant).
How does Intune Assistant work? It uses an Azure app registration (consented during onboarding) to call Microsoft Graph APIs on your behalf, aggregates and analyzes data client-side, then presents insights through an intuitive web interface.
What browsers are supported? Intune Assistant works best in modern browsers including Chrome, Firefox, Safari, and Edge. Internet Explorer is not supported.
### Support
How do I request a feature or report a bug? Open an issue or feature request on our [GitHub repository](https://github.com/srozemuller/IntuneAssistant/issues) using the provided issue templates. We actively monitor and respond to community feedback.
Do you offer enterprise support? For enterprise customers requiring dedicated support, custom integrations, or SLA agreements, please contact us through our [GitHub discussions](https://github.com/srozemuller/IntuneAssistant/discussions) or open a support ticket.
# Email notifications Intune Assistant only emails you about things you have turned on. Open your **account page** (your name in the sidebar → Account) and use the **Email notifications** card: 1. Enter the address to send to — your sign-in address is suggested. 2. Switch on the kinds of email you want: * **Settings impact alerts** — when Microsoft deprecates, removes or changes a Settings Catalog setting that is configured in your tenant's policies. Sent after the nightly catalog update, and only when something is new since the last mail. * **Product news** — new features and announcements. Occasional. 3. Save. Every email has an unsubscribe link at the bottom — for that kind of email or for all of them — which works without signing in. You can turn things back on from the account page at any time. Settings impact alerts are based on your tenant's usage harvest; see [Tenant impact](/intune-assistant/settings-library/tenant-impact). # Tenant Overview ## What Is This Page? The **Tenant Overview** page is the starting point of Intune Assistant. As soon as you sign in, Intune Assistant starts loading every configuration in your Intune tenant in the background — Settings Catalog policies, device configuration profiles, administrative templates, compliance policies, app protection and app configuration policies, scripts and remediations, Windows update profiles, enrollment configurations, Autopilot profiles, disk encryption policies, iOS app provisioning profiles and applications. While that happens, a small status window in the bottom-right corner shows each resource type being fetched, ticking them off one by one. When it is done, the overview page shows totals, how much of it is assigned, a breakdown per resource type and per platform, and a searchable inventory of everything that was found. The result is kept for **30 minutes**, so navigating around the app or reloading the page inside that window is instant — nothing is fetched again until you press **Refresh data** or the data goes stale. The **Configuration Assignments (all)** page uses the same data, so it opens already filled in, the **Backup** page uses it to know what exists before it starts exporting, and the **Search tenant** box in the sidebar (or **Ctrl+K** / **⌘K** anywhere) searches all of it without waiting. *** ## Why Would You Use This? * You want a single, instant answer to "what is in this tenant?" without opening every Intune blade * You want to spot configuration types that exist but are not assigned to anything * You are handing over or reviewing a tenant and need a quick shape of it: how many policies, of which types, for which platforms * You want to search across every configuration type at once by name, description, platform or type *** ## How to Load the Data {% stepper %} {% step %} ### Sign in Loading starts automatically the first time you sign in, and again whenever the data is older than 30 minutes. You do not have to open the overview page for this to happen. {% endstep %} {% step %} ### Watch the status window A panel appears in the bottom-right corner listing every resource type. A spinner means it is still loading, a green check means it is done (with the number of items found), and a red cross means that type could not be loaded. The panel folds itself away a few seconds after a clean run; if something failed it stays open so you can see what. {% endstep %} {% step %} ### Open **Intune Assistant → Tenant Overview** Everything that has already arrived is shown immediately, and the page fills in as the remaining types finish. {% endstep %} {% endstepper %} *** ## What You'll See * **Data collected … ago** in the top-right corner, with a **Refresh recommended** hint once the data is older than 30 minutes, and a **Refresh data** button to fetch everything again. * **Reset cache** next to it throws away everything collected for this tenant, in memory and on disk (including any backup content kept ready for the Backup page), and collects it again from scratch. Use it when you want to be certain nothing old is left over; **Refresh data** keeps the previous data visible until the new collection completes. * **Total configurations**, **Assigned** (with the number that is not assigned and the number of built-in tenant defaults), **Configuration types** and **Data loaded** cards. * **Changes since last collection** — what differs from the previous time this tenant was collected: configurations that were created, deleted, renamed or modified, and assignments that were added or removed. See [What changed](#what-changed-since-last-time) below. * **Resource types** — one bar per type showing how many items were found and how many of those are assigned. * **By platform** — a donut of where your configurations apply (Windows, iOS, macOS, Android, …). * **All configurations** — every item grouped by type. Expand a type to see each item's name, platform, sub-type, assignment state, last-modified date and how many settings or assignments it has. Use the search box to filter across every type at once; sections that contain a match open automatically. ### Item details Click any configuration name in the **All configurations** list to open its details on the right: * **Assignments** - every target with the group name, include or exclude, the filter applied (with its name) and any warning such as a deleted group. Click a group to open its details; **Open in Configuration Assignments** jumps to the assignments page filtered to this item. * **Configuration** - the item's settings as Intune stores them, shown as readable properties (nested settings fold open) or as raw JSON, with a copy button. For an Autopilot profile, for example, that is the device name template, language, out-of-box experience and enrollment status page settings and the hardware-hash setting; for a compliance policy the rules; for a script its schedule and run context. The configuration is fetched from Intune the first time you open an item and reused afterwards; when the Backup page's **Keep backup content ready** switch is on, it is already there. The small text next to the heading says where it came from, and the refresh icon fetches it again. Resource kinds without a configuration payload (connectors, roles, categories) show the assignments part only. ### Assignment states * **Assigned** — at least one assignment an administrator created. * **Not assigned** — the configuration exists but applies to nobody. * **Tenant default** — Intune's built-in "All users and all devices" enrollment defaults. They apply everywhere but nobody assigned them and they cannot be removed, so they are not counted as assigned. * **Not configured** — assigned but switched off (for example a Windows Hello for Business enrollment configuration set to *Not configured*), so it has no effect. ### What changed since last time Change history is part of the **Configuration Management** module. Without it, the overview page shows a small locked card in its place and the history page is unavailable; Intune Assistant still records the differences in the background, so the history is there from day one once the module is activated. Every time the overview is collected, Intune Assistant compares it with the previous collection of the same tenant and keeps the differences. The **Changes since last collection** card on the overview page shows them for the latest collection, with a coloured badge per kind: | Badge | Meaning | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Created** | A configuration exists now that did not exist in the previous collection | | **Deleted** | A configuration from the previous collection is gone | | **Renamed** | Same configuration, new name (the old name is shown) | | **Modified** | Same name, but Intune reports it was changed since the previous collection, or its scope tags changed (the added and removed tags are listed) | | **Assignment added** | The configuration now targets a group, all users or all devices it did not target before (or now excludes one) | | **Assignment removed** | A target it had before is gone | Assignment changes name the group and filter involved. Click a configuration name to find it in the overview, or a group target to open the group's details. The status window in the bottom-right corner also shows the number of changes when a collection finishes. **View history** (also under **Tenant Overview → Change history** in the sidebar) opens the investigation page: a timeline of every change of the last 24 hours, 7, 30 or 90 days on the left, grouped per collection, and the details of the selected change on the right. History is kept for 90 days. For every change Intune Assistant looks up the matching entry in the **Intune audit log** and shows: * **Who and when** - the user (or the application) that made the change and the exact time Intune recorded it, next to the time Intune Assistant detected it. The timeline shows the user next to each change, and **Everyone** at the top filters the log to one person. * **What changed** - the properties Intune reported as changed, with their value before and after. For assignment changes the target group and filter are named; for renames the old and new name. * **Audit record** - the audit event id (linked to the Audit Events page), the correlation id and the resource id, for when you need to follow up in Microsoft's own tooling. Intune publishes audit events with a delay of a few minutes, so a change detected right after it was made can show "No Intune audit event was found yet". Press **Check audit log** on that change to look again. A change without a matching event still shows everything Intune Assistant knows from the comparison itself. One limit to know: for each collection Intune Assistant reads at most the **5,000 newest audit events** between the two collections. That is far more than a normal 30-minute window holds, but a tenant that was not collected for days can exceed it. A change that could not be matched for that reason says so explicitly ("more than 5,000 audit events…") and offers a link to the **Audit Events** page, where you can search the resource id shown on the change yourself. Two things to know: * Changes are detected **when the overview is collected**, not the moment they happen in Intune. If nobody collects the tenant for a day, everything that happened in that day shows up in one batch at the next collection. Press **Refresh data** after making changes to see them right away. * The very first collection of a tenant is the baseline; it has nothing to compare against, so the card says so and the differences start with the second collection. * If a whole resource type came back empty while the previous collection had several items - typically a call to Microsoft Graph that was throttled or failed - that type is **not compared** and the card says so under "Not compared this time". You will not see a wave of "deleted" entries followed by "created" ones at the next collection. ### Searching from anywhere Press **Ctrl+K** (Windows) or **⌘K** (Mac) on any page, or click **Search tenant…** at the top of the sidebar. Type part of a policy, profile, app, or group name. Results are split into **Configurations** and **Assignments**; picking one opens the page that owns it with the search already filled in. The search runs on the collected data, so it is instant and works offline from Intune until you refresh. *** ## Requirements * An active Intune Assistant customer account on the **beta channel** — the tenant overview, the global search and change history are being rolled out to beta customers first. Other customers do not see the Tenant Overview entry; the assignment pages keep working for them the way they did before. * The **Configuration Management** module for [change history](#what-changed-since-last-time). * The same Microsoft Graph read permissions the assignment pages use. If a permission is missing, the consent banner tells you which one; grant it and press **Refresh data**. *** ## Common Questions **Does the overview show live data?** It shows what was collected at the time shown in the top-right corner. Press **Refresh data** to fetch the latest state; the 30-minute window exists to keep the rest of the app fast, not because the data cannot be refreshed sooner. **One resource type shows a red cross — is the rest of the data still correct?** Yes. Each type is loaded independently. The types that loaded are complete; the failed one is simply missing and listed in the amber notice on the overview page. Press **Refresh data** to try again. **Is the cached data shared with colleagues?** The copy in your browser is yours alone, per signed-in account and per tenant, and is cleared when you sign out. Intune Assistant also keeps one shared copy per tenant on the server for 30 minutes, so when a colleague has just collected the same tenant you get that copy instantly instead of collecting again; the collected-at time then shows "(shared tenant snapshot)". That shared copy holds the same information the overview shows - names, types, platforms, dates and assignment targets - never policy settings. **Refresh data** always collects anew. **Can I start from a blank screen, for a demo or a screenshot?** Open `/overview?demo=1`. That clears everything collected for the tenant (including backup content), switches **Collect automatically at sign-in** off, and shows a **Start collecting** button so you decide when the stream begins. Switch auto-collect back on afterwards using the toggle on that same screen; the setting is remembered per browser. **A change shows as "Modified" but I only changed a setting - can I see which one?** Not here. The overview holds names, types, dates and assignments, not settings, so it knows *that* Intune reported a change, not what the change was. Use a **Monitor** on the policy for setting-level drift, or compare the policy's backup with the current state. **A resource type failed to load - will its items show as deleted?** No. A type that failed in either of the two collections being compared is left out of the comparison entirely, so a temporary Graph error never produces a wave of false "deleted" and "created" entries. **I switched tenants and the overview reloaded — why?** The overview belongs to one tenant. Switching tenants restores that tenant's own cached overview if it is less than 30 minutes old, otherwise it loads it fresh. # Assignments View all resources and their assignments in one overview ## Overview The **Assignments** section of Intune Assistant gives you a powerful, unified workspace to understand, explore, and audit how Intune policies, configurations, and applications are distributed across your organization. Whether you are managing a small fleet or thousands of devices across multiple countries, assignments are at the heart of every deployment decision — and keeping them under control is critical. Microsoft Intune natively scatters assignment information across many different blades and resource types. Intune Assistant brings it all together in one place, with smart filtering, group-aware lookups, and user-centric views that are simply not available out of the box. ## Why Assignments Matter Every Intune object — a compliance policy, a configuration profile, an application, a script — only has effect when it is **assigned** to a target. Targets can be: * **Entra ID groups** (included or excluded) * **All Users** (every licensed user in the tenant) * **All Devices** (every enrolled device in the tenant) Without proper visibility, administrators face common challenges such as: * Not knowing which policies apply to a specific user or device * Accidentally overlapping or conflicting assignments * Applications targeted at the wrong group * No easy way to audit who has access to what Intune Assistant solves these challenges by providing dedicated, purpose-built views for each assignment scenario. ## Available Assignment Views The Assignments section is divided into the following pages, each focused on a specific perspective: ### [All Assignments](#all-assignments) A comprehensive overview of **every resource and assignment** in your tenant across applications, compliance policies, configuration profiles, and more. Use this view to get the full picture at a glance, apply cross-type filters, and export reports. It also shows the non-assigned resources. **Best for:** Tenant-wide audits, compliance reporting, and general inventory checks. ### [App Assignments](#app-assignments) A dedicated view focused entirely on **application deployments**. Track which apps are assigned where, filter by install type (Required, Available, Uninstall), and understand how apps flow across your organization. **Best for:** Application lifecycle management, deployment tracking, and license/install audits. ### [Group Assignments](#group-assignments) Select any **Entra ID group** and instantly see all Intune objects (policies, configurations, apps) assigned to that group. Includes group membership insights and highlights both included and excluded assignments. **Best for:** Group-level audits, change management validation, and troubleshooting over-assignment or under-assignment for a specific group. ### [Filter Assignments](#filter-assignments) Explore how **assignment filters** are used across your tenant. Assignment filters in Intune allow you to refine which devices within a group a policy applies to. This view shows which filters exist, how they are configured, and where they are applied. **Best for:** Filter governance, ensuring filters are correctly scoped, and auditing filter usage. ### [User Assignments](broken://pages/a6e1e845e8545c2342ad3779d459c008e4d39291) Search for a specific **user** and see all Intune assignments (configuration profiles, compliance policies, and more) that apply to them — both through (nested) group memberships. This view resolves group nesting and includes "All Users" targeting. **Best for:** End-user troubleshooting, helpdesk investigations, and proving policy application per user. ### [User App Assignments](#user-app-assignments) A focused sub-view of user assignments dedicated to **applications**. Enter a username and immediately see all apps assigned to that user via any targeting method (group membership, All Users). **Best for:** App entitlement verification, access reviews, and user-specific app troubleshooting. ### [User Config Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-configuration-profiles) A focused sub-view of user assignments dedicated to configuration profiles. Enter a username and immediately see all policies assigned to that user via any targeting method (group membership, All Users). **Best for:** Policy verification, access reviews, and user-specific app troubleshooting. ## Common Features Across All Assignment Views All assignment pages in Intune Assistant share a consistent set of capabilities: | Feature | Description | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Shared data** | Configuration assignments come from the tenant overview collected at sign-in (see the **Tenant Overview** page); group memberships and app assignments are read live. Press **Refresh data** on the overview page to collect everything again | | **Column filtering** | Filter results by any displayed column directly in the table | | **Global search** | Full-text search across all visible rows | | **Export** | Export any table to CSV for offline analysis or reporting | | **Pagination** | Handle large datasets without performance degradation | | **Dark / Light mode** | Consistent UI theme inherited from global settings | | **Tenant-aware** | All views automatically scope to your currently selected tenant | ## Getting Started 1. Navigate to **Assistant → Assignments** from the sidebar. 2. Choose the view that matches your current task (overview, app, group, user, etc.). 3. Use the search or filter controls to narrow down results. 4. Export the data if you need to share findings or create a report. {% hint style="info" %} **Tip:** If you are troubleshooting why a user is or is not receiving a policy, start with the **User Assignments** view and search for the user directly. {% endhint %} {% hint style="info" %} **Tip:** For a broad tenant-wide audit, start with **All Assignments** and use the export function to get a full snapshot. {% endhint %} ## Related Sections * [Conditional Access](broken://pages/89ff936de3c3268e12844cda622a391657bac0d4) * [Configuration Policies](broken://pages/e86fd38ca037a3f807da7172f0eadb3d4fbe4789) * [Devices Overview](broken://pages/8f58eca6123f0202a13e7abcf87dcee03d1c3cc5) # All Assignments ## What Is This Page? The **All Assignments** page gives you a complete, real-time snapshot of every assignment that exists in your Intune tenant — across every resource type, every platform, and every target group. Think of it as the "mission control" for your Intune assignment landscape. Whether you are a helpdesk administrator trying to understand why a policy applies to a device, an architect reviewing the overall assignment structure, or a CISO wanting an audit trail, this page is your starting point. *** ## Why Would You Use This? * You want to know **what is assigned, to whom, and how** — all in a single view * You are conducting a **compliance or security audit** and need evidence of policy coverage * You suspect **conflicting or missing assignments** and need to see the full picture * You want to **export a report** of all assignments for documentation or review purposes * You need to quickly check if a specific resource has an **assignment filter** applied *** ## How to Load the Data 1. Sign in — Intune Assistant starts collecting your tenant overview in the background straight away (see the status window in the bottom-right corner) 2. Navigate to **Assistant → Assignments → All Assignments** 3. The table is already filled from that overview; **Data collected … ago** in the top-right corner tells you how fresh it is 4. Press **Refresh** to fetch the assignments again from Intune. This reads only the resource types that carry assignments, so it is quick and does not touch the rest of the tenant overview; the top-right corner then shows **Assignments fetched … ago**. Data older than 30 minutes shows a **refresh recommended** hint 5. **Refresh everything** next to it collects the whole tenant overview again (every resource type, the search index and the change history) - use it when you changed more than assignments {% hint style="info" %} ⏳ **Large tenants:** Fetching can take longer if you have thousands of policies and apps. A loading indicator shows progress. {% endhint %} {% hint style="warning" %} ❌ **Cancel at any time:** If the load is taking too long, use the **Cancel** button to stop the request without losing your session. {% endhint %} *** ## Understanding the Table Once loaded, the data is displayed in a table with the following columns: | Column | What It Means | | ------------------- | ------------------------------------------------------------------------------------- | | **Resource** | The name of the Intune object (policy, configuration profile, app, script, etc.) | | **Type** | The resource category (e.g., Compliance Policy, Configuration Profile, Win32 App) | | **Sub Type** | A more specific classification within the resource type | | **Assignment** | How the resource is targeted — e.g., `Entra ID Group`, `All Users`, `All Devices` | | **Target** | The name of the group, user, or built-in target the assignment points to | | **Platform** | The device platform this resource applies to (Windows, iOS, Android, macOS, or All) | | **Status** | **Assigned**, **Not Assigned**, or **Assigned (Tenant Default)** — see the note below | | **Filter** | The name of an assignment filter applied (if any) — click to see filter details | | **Filter Type** | Whether the filter is **Include** or **Exclude** | | **Role Scope Tags** | Any RBAC scope tags associated with the resource | ### Tenant defaults Intune creates a handful of built-in enrollment configurations in every tenant — the enrollment restrictions, enrollment limit, Enrollment Status Page, Windows Hello for Business and Windows Restore defaults, all named **All users and all devices**. Nobody assigned them and you cannot remove or change their targeting; they apply as the lowest-priority fallback. The **Target** column shows the built-in target Intune reports for each one (for the enrollment defaults that is `All Devices`). Intune Assistant shows each of these as one row with the **Assignment** badge `Tenant Default` and the **Status** badge `Assigned (Tenant Default)`. They are counted separately from your own assignments: they are *not* included in the **Assigned** count, and they do not show up under **Not Assigned** either. The **Sub Type** column tells the five defaults apart (for example `Limit`, `PlatformRestrictions`, `Windows10EnrollmentCompletionPageConfiguration`). The Windows Hello for Business and Windows Restore configurations also carry a state (Enabled, Disabled or Not Configured). When that state is **Not Configured**, an amber `Not Configured` badge appears next to the assignment badge: the configuration is assigned, but it does nothing. This is the normal situation for those two tenant defaults in a tenant where nobody has switched them on. ### ⚠️ Warning Indicators If a row shows a small **amber triangle** icon next to the resource name, Intune Assistant detected a problem with that specific assignment. Hover over the icon to read the warning message. The two most common warnings are: * **The assigned group no longer exists** — the group this assignment targets has been deleted from Entra ID, but the assignment itself is still sitting on the policy. * **The assignment filter no longer exists** — the filter this assignment uses to include or exclude devices has been deleted. Both situations mean Intune can no longer evaluate the assignment correctly. In practice this usually shows up as **"tattooing"**: settings that were applied while the assignment still worked stay applied on the device forever, because Intune has nothing left to evaluate that would tell it to remove them — even after you unassign the policy elsewhere. Recreating the missing group or filter (or removing and recreating the assignment against a group/filter that does exist) is the fix. *** ## Grouping by policy By default the table shows one row per assignment, so a policy with five assignments takes five rows. Above the table, the **Flat** / **By policy** switch changes that: * **Flat** — one row per assignment, every column filled. This is the original view. * **By policy** — one row per resource, the same way the Intune portal lists policies. A collapsed row shows only the **Resource**, **Platform** and **Status** columns, plus a small badge with the number of assignments. Click the row to unfold it: the resource's assignments appear underneath as normal rows with the **Assignment**, **Target**, **Filter** and **Role Scope Tags** columns filled in, exactly as in the flat view. Click the row again to fold it. In the **By policy** view: * **Status** is `Assigned` when at least one of the resource's assignments is assigned, `Not Assigned` when none are, and `Assigned (Tenant Default)` for the built-in tenant defaults. * The **amber warning triangle** on a collapsed row means one of its assignments has a problem (a deleted group or filter). Unfold the row to see which one. * Every filter and both search boxes keep working. A resource is listed when at least one of its assignments passes the filters, and unfolding it shows only those assignments. Searching for a group name lists the resources that are assigned to that group. * Paging counts resources, not assignments. The line above the table shows both numbers. * Group and filter names inside an unfolded row are still clickable and open the same dialogs as in the flat view. Your choice is remembered in this browser and applies the next time you open the page. Exports are not affected by the view: both exports always contain one line per assignment. *** ## Filtering the Data The filter bar (click **Filters** to expand it) lets you narrow down results without losing the full dataset. All filters work together — each one you add further reduces the results shown. | Filter | What It Does | | ------------------- | ----------------------------------------------------------------------------------- | | **Assignment Type** | Show only specific targeting methods (e.g., only group assignments, only All Users) | | **Status** | Show only Assigned, only Not Assigned, only Tenant Default, or any combination | | **Platform** | Limit to a specific device platform | | **Resource Type** | Focus on a specific type of Intune resource | | **Filter Type** | Show only assignments using Include filters, Exclude filters, or no filter at all | | **Role Scope Tags** | Narrow by RBAC scope tags assigned to resources | To remove all active filters at once, click **Clear Filters**. *** ## Search Use the **Search** box at the top of the table to do a free-text search across: * Resource name * Target name * Assignment type * Resource type * Platform * Filter name This is useful when you know part of a name and want to find it quickly without setting up formal filters. *** ## Clicking on Groups In the **Target** column, group names are clickable. Clicking a group name opens a **Group Details dialog** that shows: * Group display name and description * Membership type (assigned or dynamic) * Number of users, devices, and nested groups * Member list (if available) This allows you to quickly understand who is affected by an assignment without leaving the page. *** ## Clicking on Filters In the **Filter** column, any filter name that is linked can be clicked to open a **Filter Details dialog** showing: * Filter display name and description * Platform the filter targets * The filter rule expression *** ## Exporting the Data Click the **Export** button to download the current view (including any active filters and search) as a CSV file. The export includes all visible columns plus Role Scope Tags. **Filename:** `assignments-overview.csv` {% hint style="info" %} 💡 Use the export for audit reports, change management documentation, or sharing with stakeholders who do not have access to the portal. {% endhint %} *** ## Summary Stats Above the table, a small stats bar shows key numbers at a glance: * **Total Assignments** — count of rows in the current filtered view * **Assigned** — how many are actively assigned * **Not Assigned** — resources that exist but have no assignment * **Tenant Default** — built-in defaults that Intune applies to everything (see below) * **Resource Types** — how many distinct resource categories are present * **Platforms** — how many platforms are represented *** ## Common Use Cases ### Audit: What policies are assigned to All Devices? → Set **Assignment Type** filter to `All Devices` ### Audit: Which resources have no assignment at all? → Set **Status** filter to `Not Assigned` ### Security review: Are there assignments without any scope tag? → Set **Role Scope Tags** filter — rows without tags will be visible when no tag filter is selected ### Troubleshooting: Find a specific policy quickly → Type the policy name in the **Search** box *** ## Related Pages * [App Assignments](/intune-assistant/assignments/app-assignments) — focused app-only view * [Group Assignments](/intune-assistant/assignments/group-assignments) — look up a specific group * [User Assignments](/intune-assistant/assignments#user-assignments) — look up a specific user * [Filter Assignments](/intune-assistant/assignments/assignments-with-filters) — understand how filters are used # App Assignments ## What Is This Page? The **App Assignments** page focuses exclusively on **application deployments** in your Intune tenant. It shows every app that Intune knows about, who it is assigned to, how it is installed, and on which platform. ## Why Would You Use This? * Verify which apps are deployed to which groups * Check the install type (Required, Available, Uninstall) for a specific app * Investigate why a user does or does not have an app on their device * Audit app assignments across platforms (Windows, iOS, Android, macOS) * Produce a report of all deployed applications for a compliance review ## How to Load the Data 1. Navigate to **Assistant > Assignments > App Assignments** 2. Click **Load Data** 3. Data is fetched from Microsoft Graph in pages 4. A progress counter shows how many pages have been loaded > **Paged loading:** Data loads in batches. You will see a counter like `Fetched 3 pages (300 records)` while loading is in progress. > **Cancel:** You can stop loading at any point. Records already fetched remain visible. ## Understanding the Table | Column | What It Means | | ---------------- | ---------------------------------------------------------------- | | **Resource** | The application name as it appears in Intune | | **Type** | App type (Win32App, iOS Store App, Android Enterprise App, etc.) | | **Assignment** | Targeting method: Entra ID Group, All Users, All Devices | | **Target** | The specific group or built-in target | | **Platform** | Device platform (Windows, iOS, Android, macOS) | | **Install Type** | How the app is deployed: Required, Available, Uninstall | | **Status** | Whether the app is Assigned or Not Assigned | | **Filter** | Assignment filter name applied (if any) | | **Filter Type** | Whether the filter is Include or Exclude | ### Install Types Explained | Install Type | Meaning | | ------------- | ------------------------------------------------------------------------------- | | **Required** | App is automatically installed on matching devices — no user interaction needed | | **Available** | App appears in the Company Portal — users can choose to install it | | **Uninstall** | App is actively removed from matching devices | > 📸 *\[Screenshot placeholder: App Assignments table showing Win32 apps with Required and Available install types across different groups]* ### ⚠️ Warning Indicators A small **amber triangle** icon next to the resource name means Intune Assistant detected the assignment's **target group** or **assignment filter no longer exists** in your tenant — it was deleted, but this assignment still references it. Hover the icon to read which one. Intune can no longer evaluate an assignment like this, which is a common cause of app install/uninstall states "sticking" on a device even after the assignment is changed or removed elsewhere. ## Filtering the Data Expand the **Filters** panel to narrow results: | Filter | What It Does | | ------------------- | --------------------------------------------------------------------- | | **Resource Type** | Limit to a specific app type (Win32, iOS, Android, etc.) | | **Assignment Type** | Show only group, All Users, or All Devices assignments | | **Status** | Show only Assigned or Not Assigned apps | | **Platform** | Focus on a specific device platform | | **Install Type** | Filter by Required, Available, or Uninstall | | **Filter Type** | Show assignments using Include filters, Exclude filters, or no filter | > 📸 *\[Screenshot placeholder: Filter bar expanded with Install Type dropdown open]* ## Clicking on Groups Group names in the **Target** column are clickable. A **Group Details** dialog opens showing membership type, member counts (users, devices, nested groups), and the group description. ## Clicking on Filters Filter names open a **Filter Details** dialog showing the filter rule expression and platform scope — so you know exactly which devices within the group will actually receive the app. ## Exporting the Data Click **Export** to download visible rows as a CSV file. **Filename:** `app-assignments.csv` The export includes: resource name and type, assignment type, target, platform, install type, status, filter name and filter type. ## Common Use Cases **Find all apps required on Windows devices**\ Set Platform to `Windows`, Install Type to `Required`. **Which apps are available in Company Portal?**\ Set Install Type to `Available`. **Apps with no assignment at all?**\ Set Status to `Not Assigned`. **Audit all iOS app deployments**\ Set Platform to `iOS/iPadOS`. ## Related Pages * [All Assignments](/intune-assistant/assignments/all-assignments) * [User App Assignments](/intune-assistant/assignments/user-assignments) * [Group Assignments](/intune-assistant/assignments/group-assignments) # Assignments with filters ## What Is This Page? The **Filter Assignments** page is about a specific Intune feature called **assignment filters**. If you are not yet familiar with filters, think of them as a precision layer on top of group assignments. When you assign a policy to a group, that policy normally applies to every device in the group. With a filter, you can refine this: *"Only apply this policy to Windows devices where the OS version is 22H2 or higher"* or *"Exclude personal devices from this compliance policy."* The filter evaluates each device individually at the time of policy evaluation — based on device properties — so you can be precise without creating endless groups. This page lets you explore all filters in your tenant and see exactly where each one is used. *** ## Why Would You Use This? * You want to know which assignment filters exist in your tenant * You need to verify that a specific filter is applied to the right policies * You are troubleshooting why a policy applies (or does not apply) to certain devices, even though the group looks correct * You are auditing filter usage as part of a security or compliance review * You want to find and clean up unused or misconfigured filters *** ## How to Use This Page ### Option 1: Load All Assignments with Filter Info 1. Navigate to **Assistant > Assignments > Filter Assignments** 2. Click **Load Data** 3. All assignments are loaded from the tenant overview collected at sign-in, including which filter (if any) is attached to each. Press **Refresh data** on the Tenant Overview page to collect everything again 4. Use the table filters to narrow down to assignments using a specific filter ### Option 2: Search by a Specific Filter 1. Use the **Select a filter** search box at the top 2. Type the filter name or browse the list 3. Select a filter 4. The table automatically narrows to show only assignments using that filter *** ## Understanding the Filters List The page shows all available filters in your tenant. Each filter entry shows: | Field | What It Shows | | ------------------- | -------------------------------------------------------------------------- | | **Filter Name** | The display name of the filter | | **Platform** | Which device platform the filter applies to (Windows, iOS, Android, macOS) | | **Management Type** | Whether it applies to MDM-managed or app-managed (MAM) devices | | **Rule** | The filter expression, e.g. `(device.osVersion -startsWith "10.0.19")` | *** ## Understanding the Assignments Table | Column | What It Means | | --------------- | --------------------------------------------------------- | | **Resource** | The Intune policy, app, or profile using this filter | | **Type** | Resource category (Compliance, Configuration, App, etc.) | | **Assignment** | The targeting method (group name, All Devices, All Users) | | **Target** | The group or built-in target | | **Platform** | Device platform | | **Filter** | The filter applied to this assignment | | **Filter Type** | Include or Exclude (see below) | | **Status** | Assigned or Not Assigned | ### Include vs Exclude Filters — What Is the Difference? | Filter Type | Effect | | ----------- | --------------------------------------------------------------------------------------------- | | **Include** | The policy only applies to devices in the group **where the filter rule is TRUE** | | **Exclude** | The policy applies to all devices in the group **except** those where the filter rule is TRUE | An important point: a filter does not replace or change the group assignment. It only refines which devices within the already-targeted group are actually evaluated for that policy. **Example:** A compliance policy is assigned to `SG-All-Employees` with an Include filter for `device.manufacturer -eq "Microsoft"`. Only Surface devices (Microsoft-manufactured) in that group will get the policy. All other devices in the group are skipped. *** ## Filtering the Table | Filter | What It Does | | ------------------- | ---------------------------------------------------------------------------- | | **Assignment Type** | Show only specific targeting methods | | **Resource Type** | Focus on a specific type of Intune resource | | **Status** | Show only Assigned or Not Assigned resources | | **Platform** | Focus on a specific device platform | | **Filter Type** | Show only Include filters, only Exclude filters, or resources with no filter | *** ## Clicking on Groups Group names in the results are clickable and open the **Group Details** dialog. *** ## Exporting the Data Click **Export** to download visible rows as a CSV. **Filename:** `filter-assignments.csv` *** ## Common Use Cases **Which policies use the "Windows-CorporateDevices" filter?**\ Select that filter from the dropdown and review all assignments in the results. **Are any policies using an Exclude filter on iOS?**\ Set Platform to `iOS`, Filter Type to `Exclude`. **Which resources have no filter applied?**\ Set Filter Type to `No Filter` — these assignments apply to all devices in the targeted group without any device-level refinement. **Audit all assignment filters in the tenant**\ Review the filter list — each entry shows the rule expression and platform scope. *** ## Related Pages * [All Assignments](/intune-assistant/assignments/all-assignments) * [Group Assignments](/intune-assistant/assignments/group-assignments) * [App Assignments](/intune-assistant/assignments/app-assignments) # Group assignments ## What Is This Page? The **Group Assignments** page answers one of the most common questions in Intune management: *"What is assigned to this group?"* You search for an Azure AD / Entra ID group, and Intune Assistant retrieves every policy, configuration profile, application, and script that is assigned to that group. Both direct assignments (include) and exclusions are shown. This is the go-to page when you need to understand the full Intune footprint for a specific group — whether that group represents a department, a device type, a location, or any other unit in your organization. *** ## Why Would You Use This? * You are onboarding a new department and want to verify the correct policies are assigned to their group * You need to review what a specific group receives before making configuration changes * You are troubleshooting why a device or user is getting unexpected settings * You want to validate that a group is correctly excluded from certain policies * You need to document all assignments for a group for an audit or handover *** ## How to Use This Page 1. Navigate to **Assistant > Assignments > Group Assignments** 2. Type a group name in the **Search for a group** box 3. Select the group from the results 4. Intune Assistant resolves the group's nested and parent groups, then picks every assignment targeting one of them from the tenant overview collected at sign-in (app assignments are read live) 5. The table populates with results. Because the configuration rows come from the tenant overview, they are as fresh as its **Data collected … ago** time; press **Refresh data** on the Tenant Overview page after changing assignments in Intune > You can search by group name or paste a group Object ID (GUID) directly into the search box. *** ## Group Info Panel Once a group is selected, a summary panel appears above the table: | Field | What It Shows | | ------------------- | ------------------------------------------------ | | **Display Name** | The group name in Azure AD / Entra ID | | **Description** | The group description (if set) | | **Membership Type** | Assigned or Dynamic | | **Membership Rule** | The dynamic rule expression (for dynamic groups) | | **Created** | When the group was created | | **Users** | Number of user members | | **Devices** | Number of device members | | **Nested Groups** | Number of nested group members | *** ## Understanding the Table | Column | What It Means | | --------------- | ----------------------------------------------------------------------------- | | **Resource** | The name of the Intune object (policy, app, profile, etc.) | | **Type** | Resource category (Compliance Policy, Configuration Profile, Win32 App, etc.) | | **Assignment** | How the group is targeted: Include or Exclude | | **Platform** | Device platform the resource targets | | **Status** | Whether the resource is Assigned or Not Assigned | | **Nested** | Whether the assignment reaches this group through a nested parent group | | **Filter** | Assignment filter applied (if any) | | **Filter Type** | Include or Exclude filter | ### Nested Assignments If a row shows **Nested: Yes**, the group is not directly assigned to that resource. Instead, the group is a member of another group that is the direct assignment target. Intune Assistant resolves this automatically so you always get the complete picture. > This is especially useful for dynamic groups or groups that are members of broader targeting groups. ### ⚠️ Warning Indicators A small **amber triangle** icon next to the resource name means the assignment's **filter no longer exists** — it was deleted from Intune, but this assignment still references it. Hover the icon to read the warning. An assignment like this can no longer be evaluated correctly by Intune, which is a common cause of "tattooed" settings that stay applied even after you change or remove the assignment elsewhere. *** ## Filtering the Data | Filter | What It Does | | ------------------- | ----------------------------------------------------------------- | | **Resource Type** | Show only a specific type (apps, compliance, configuration, etc.) | | **Assignment Type** | Filter by Include or Exclude targeting | | **Status** | Show only Assigned or Not Assigned resources | | **Platform** | Focus on a specific platform | | **Filter Type** | Show assignments with or without assignment filters | *** ## Clicking on Groups When a result row shows another group as the assignment target (nested scenario), that group name is also clickable and opens the **Group Details** dialog for that group. *** ## Clicking on Filters Filter names in the **Filter** column open a **Filter Details** dialog showing the filter rule expression and platform scope. *** ## Exporting the Data Click **Export** to download the current results as a CSV. **Filename:** `group-assignments.csv` *** ## Common Use Cases **What does the "SG-Windows-Devices" group receive?**\ Search for the group name and review the full list. **Is the group excluded from a specific policy?**\ Filter Assignment Type by `Exclude` to see all exclusions for this group. **Does this group receive assignments through nested groups?**\ Look for rows where Nested = Yes in the results. **Audit before deleting a group**\ Load the group and export all assignments before removing it — so you have a record of what will be affected. *** ## Related Pages * [All Assignments](/intune-assistant/assignments/all-assignments) * [Filter Assignments](/intune-assistant/assignments/assignments-with-filters) * [User Assignments](/intune-assistant/assignments/user-assignments) # User assignments ## What Is This Page? The **User Assignments** section answers the question every helpdesk engineer, architect, and auditor eventually asks: *"What does this specific user actually receive from Intune?"* Because Intune distributes policies and apps through groups, and users can be members of many groups, working out what applies to a single person is not straightforward in the native Intune portal. You would need to manually check every group a user belongs to, then cross-reference each group against every policy and app. That takes time and is error-prone. Intune Assistant does this automatically. You search for a user, and the tool resolves all group memberships (nesting included) and returns the full list of what applies to that person. ## What You Can Look Up The User Assignments section is split into two focused sub-pages: ### Configuration Assignments Covers all **policies and configuration profiles** assigned to the user — compliance policies, device configuration profiles, security baselines, scripts, and similar resources. [Go to User Configuration Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-configuration-profiles) ### Application Assignments Covers all **applications** assigned to the user — both Required apps (automatically installed) and Available apps (visible in Company Portal). [Go to User App Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-apps) ## Why Is This Split Into Two Pages? The volume of data can be large. A user in a managed organization may have dozens of configuration policies and a completely separate set of app assignments. Keeping the views separate makes each page easier to navigate and read. ## How Assignment Resolution Works The user's group memberships are read live each time you look a user up. The configuration assignments themselves come from the tenant overview collected at sign-in (see the **Tenant Overview** page); press **Refresh data** there after changing assignments in Intune. App assignments are read live. When you search for a user, Intune Assistant: 1. Looks up the user in Entra ID 2. Retrieves all groups the user is a member of — including nested group memberships 3. Queries all Intune assignments 4. Matches assignments targeting any of those groups, plus All Users assignments 5. Returns the complete, merged result This means you see the **effective** assignment picture — everything that reaches the user through any path. ## Common Use Cases **Why is this user getting a compliance policy they should not have?**\ Check their configuration assignments to see which group-based assignment is delivering it. **Does this user have the required apps deployed?**\ Check their app assignments and confirm Required apps are listed. **Pre-offboarding review**\ Check all assignments before disabling or deleting an account — document what the user had access to. **New joiner validation**\ After adding a user to the correct groups, verify the expected policies and apps now appear. ## Related Pages * [User Configuration Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-configuration-profiles) * [User App Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-apps) * [Group Assignments](/intune-assistant/assignments/group-assignments) * [All Assignments](/intune-assistant/assignments/all-assignments) # User assignments for apps ## What Is This Page? The **User App Assignments** page shows every Intune **application** that is targeted at a specific user — resolved automatically through all their group memberships, including All Users targeting and nested groups. You enter a name or email address, and Intune Assistant works out the complete app entitlement picture for that person. ## Why Would You Use This? * A user says an app is missing from their Company Portal — you need to find out why it is not appearing * You want to confirm that all required apps will be automatically installed for a new employee * You are doing an access review and need to document which apps a specific person can install * An app is installing on a user's device unexpectedly and you need to trace which group is responsible * You need to report on app entitlements for audit or compliance purposes * You want to verify that an app marked for uninstall is correctly targeted at a user ## How to Use This Page ### Search by User 1. Navigate to **Assistant > Assignments > User Assignments > Application Assignments** 2. The page opens with a welcome card and a search area 3. Make sure **Search for a User** mode is active 4. Type the user's display name or UPN (email address) — partial names work 5. Press **Enter** or click **Search** 6. If multiple users match, a list of user cards is displayed — each showing the display name, UPN, and account status 7. Click **View Assignments** on the correct user 8. Intune Assistant fetches all app assignments for that user 9. The results table appears > You can paste a user Object ID (GUID) directly into the search field. ## User Info Panel After a user is selected and assignments are loaded, a summary card appears above the table: | Field | What It Shows | | ------------------ | ----------------------------------------------------- | | **Display Name** | The user's full name as it appears in Entra ID | | **UPN** | The user principal name — their email / login address | | **Account Status** | Enabled or Disabled | | **User Type** | Member (internal user) or Guest (external / B2B user) | | **Created** | When the Entra ID account was created | ## Understanding the Table | Column | What It Means | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Resource** | The application name as it appears in Intune. The app type (Win32App, iOS Store App, etc.) is shown in smaller text below the name | | **Platform** | Device platform the app targets — shown as a coloured badge: blue for Windows, grey for iOS, green for Android, purple for macOS | | **Assignment** | How the app reaches the user — e.g., `Entra ID Group`, `All Users`. Shown as a badge. Exclude assignments are highlighted in red | | **Target** | The specific group or built-in target (`All Users`, `All Devices`). For group assignments, member counts (users / devices / nested groups) are shown below the group name. The group name is clickable | | **Install Type** | How the app is deployed — `Required`, `Available`, or `Uninstall` | | **Status** | **Assigned** (green badge) or **Not Assigned** (grey badge) | | **Filter** | The assignment filter applied (if any). Clickable to view the filter rule. Shows a green **Inc** badge for Include filters and a red **Exc** badge for Exclude filters | ### Install Types — What They Mean for the User | Install Type | What Happens on the User's Device | | ------------- | ---------------------------------------------------------------------------------------------------- | | **Required** | The app is **automatically pushed** to the user's enrolled device(s). No action needed from the user | | **Available** | The app appears in the **Company Portal** app. The user can choose to install it at any time | | **Uninstall** | The app is **actively removed** from the user's enrolled device(s) | > Understanding the difference between Required and Available is key when troubleshooting why an app is or is not present on a device. Required apps install silently; Available apps only install if the user requests them. ### ⚠️ Warning Indicators A small **amber triangle** icon next to the resource name means the assignment's **filter no longer exists** in your tenant — it was deleted, but this assignment still references it. Hover the icon to read the warning. Intune can no longer evaluate an assignment like this, which is a common cause of app install/uninstall states "sticking" on a device even after the assignment is changed or removed elsewhere. ## Dynamic Groups When a group in the **Target** column has a small **purple block icon** next to its name, it is a **dynamic group**. Dynamic groups are automatically maintained by Entra ID based on a membership rule (e.g., all devices with a certain OS version, or all users in a specific department). If the target group has **nested groups** inside it, a small **amber question mark icon** appears in the member count area. This means some devices or users in that group may themselves be groups. To fully understand the reach of that assignment, use the [Group Assignments](broken://pages/b0fd2c7920868043ea2882379c85262ee83ff8a9) page to drill into the specific group. ## Filters Panel Click **Filters** to expand the filter controls: | Filter | What It Does | | ------------------- | ------------------------------------------------------------------------------------ | | **Resource Type** | Focus on a specific app type (Win32App, iOS Store App, Android Enterprise App, etc.) | | **Assignment Type** | Show only specific targeting methods (e.g., only Entra ID Group, only All Users) | | **Status** | Show only Assigned or only Not Assigned apps | | **Platform** | Limit to a specific device platform | | **Install Type** | Show only Required, Available, or Uninstall assignments | | **Filter Type** | Show only assignments with an Include filter, an Exclude filter, or no filter | Use **Clear Filters** to reset everything at once. ## Clicking on Groups Group names in the **Target** column are clickable (highlighted in amber). Clicking opens a **Group Details** dialog showing: * Group display name and description * Membership type (Assigned or Dynamic) * Dynamic membership rule (if applicable) * Member counts: users, devices, and nested groups ## Clicking on Filters Filter names in the **Filter** column are clickable. A **Filter Details** dialog opens showing: * Filter display name and description * Platform scope * Management type (MDM or MAM) * The filter rule expression (e.g., `(device.manufacturer -eq "Microsoft")`) ## Stats Bar Above the results table, a stats strip shows: | Stat | What It Shows | | --------------------- | --------------------------------------------------------------- | | **Total Assignments** | Number of rows in the current filtered view | | **Assigned** | How many apps are actively assigned to the user | | **Not Assigned** | Apps that exist in the tenant but are not targeted at this user | | **Resource Types** | Number of distinct app types in the results | | **Platforms** | Number of distinct platforms represented | ## Exporting the Data Two export options are available via the **Export** button: ### Standard Export Exports all visible rows to CSV, PDF, or HTML. Includes: * Resource type and name * Assignment type and target * Platform * Install type * Status * Filter name and filter type **Filename:** `user-assignments-overview.csv` (or `.pdf` / `.html`) ### Export for Bulk Assignments A structured CSV for use in bulk assignment workflows. Includes: * PolicyName (the app name) * GroupName * AssignmentDirection * AssignmentAction (pre-filled as `Add`) * Filter name and filter type **Filename:** `rollouts-overview.csv` > 💡 The bulk export is useful when you want to replicate a user's app assignment set to a new group or test environment. ## Common Use Cases **Why does a user not see an app in Company Portal?**\ Search for the user. If the app is not in the results with Install Type = `Available`, no group is targeting the user for that app — check group memberships or add the user to the correct group. **Confirm a required app will install on a new hire's device**\ Search for the user after they have been added to onboarding groups. Look for the app with Install Type = `Required` — if it appears as Assigned, it will install automatically at next device check-in. **An app is installing on a device unexpectedly**\ Search for the user. Find the app with Install Type = `Required`. The **Target** column shows which group is pushing it — this is the group to investigate. **Access review: what apps can this user install from Company Portal?**\ Filter Install Type to `Available` and export the Standard Export to share with a reviewer. **Verify no apps are being uninstalled that should not be**\ Filter Install Type to `Uninstall` and review the list. **Pre-offboarding or licence review**\ Export the full Standard Export before the account is disabled — gives you a complete record of app entitlements. ## Related Pages * [User Configuration Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-configuration-profiles) * [App Assignments](/intune-assistant/assignments/app-assignments) * [Group Assignments](/intune-assistant/assignments/group-assignments) * [All Assignments](/intune-assistant/assignments/all-assignments) # User assignments for configuration profiles ## What Is This Page? The **User Configuration Assignments** page shows every Intune **configuration policy, compliance policy, security baseline, and script** that applies to a specific user — resolved automatically through all their group memberships, including nested groups. In the native Intune portal, finding what a single user receives means checking every group they are in and then cross-referencing those groups with every policy. That is tedious and error-prone. This page does all of that in one query. *** ## Why Would You Use This? * A user's device has unexpected settings applied — you need to trace which policy is responsible * You want to confirm a new employee is receiving all required configuration and compliance policies after being added to onboarding groups * You are conducting a compliance or security audit and need to document exactly which policies a specific person is subject to * A device is showing as non-compliant in the portal and you need to identify which compliance policy is triggering that * You want to check whether a user is correctly excluded from a sensitive policy * You need to hand over a user account and want to document everything that was applied to it *** ## How to Use This Page {% stepper %} {% step %} ### Search by User 1. Navigate to **Assistant > Assignments > User Assignments > Configuration Assignments** 2. The page opens with a welcome card and a search box 3. Make sure **Search for a User** mode is selected (toggle at the top of the search area) 4. Type the user's display name or email address (UPN) — partial names work 5. Press **Enter** or click **Search** 6. If multiple users match, a list is shown — click the correct user to select them 7. Click **View Assignments** next to the selected user 8. Intune Assistant fetches all configuration assignments for that user 9. The results table appears {% endstep %} {% endstepper %} {% hint style="info" %} You can also paste the user's Object ID (GUID) directly into the search box. {% endhint %} *** ## User Info Panel After a user is selected and assignments are loaded, a summary panel appears at the top of the results: | Field | What It Shows | | ------------------ | ---------------------------------------------------------------------- | | **Display Name** | The user's full name | | **UPN** | The user principal name — their email / login address | | **Account Status** | Enabled or Disabled — important when troubleshooting inactive accounts | | **User Type** | Member (internal) or Guest (external / B2B) | | **Created** | When the account was created in Entra ID | *** ## Understanding the Table | Column | What It Means | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Resource** | The policy name, with the resource type shown in smaller text below it | | **Assignment** | How the resource reaches the user — group name, All Users, or direct. Shows a **nested badge** (purple icon) if the assignment comes via a parent group the user's group is nested inside | | **Target** | The specific group or built-in target. For group assignments, shows member counts (users / devices / nested groups) below the name. Clickable for group details | | **Platform** | Device platform the policy targets (Windows, iOS, Android, macOS, or All) | | **Status** | **Assigned** (green) or **Not Assigned** (grey) | | **Filter** | The assignment filter applied to this assignment, if any. Clickable to see the filter rule. Shows a green **Inc** badge (Include) or red **Exc** badge (Exclude) | ### The Nested Badge — What Does It Mean? When the **Assignment** column shows a small purple group icon alongside the assignment type, it means the user is receiving this policy **indirectly**. Here is the chain: * The policy is directly assigned to **Group B** * The user is a member of **Group A** * **Group A** is a member of **Group B** * Therefore the user inherits the policy through that nesting Intune Assistant traces this automatically so you see the full effective assignment, not just direct targeting. This is one of the most common reasons users receive policies they were not intentionally targeted with. ### ⚠️ Warning Indicators A small **amber triangle** icon next to the resource name means the assignment's **filter no longer exists** in your tenant — it was deleted, but this assignment still references it. Hover the icon to read the warning. Intune can no longer evaluate an assignment like this, which is a common cause of settings staying applied on a device ("tattooing") even after the assignment is changed or removed elsewhere. *** ## Filters Panel Click **Filters** to expand the filter controls: | Filter | What It Does | | ------------------- | ------------------------------------------------------------------------------------------------------- | | **Assignment Type** | Show only specific targeting methods (e.g., only Entra ID Group, only All Users) | | **Resource Type** | Focus on a specific policy category (Compliance Policy, Configuration Profile, Security Baseline, etc.) | | **Status** | Show only Assigned or only Not Assigned resources | | **Platform** | Limit to a specific device platform | | **Filter Type** | Show only assignments with an Include filter, an Exclude filter, or no filter at all | Use **Clear Filters** to reset all active filters at once. *** ## Search Within Results Once assignments are loaded, a **Search** box is available above the table. It performs a free-text search across resource names, target names, assignment types, resource types, and platforms — useful for quickly finding a specific policy within a large result set. *** ## Clicking on Groups Group names in the **Target** column are clickable (highlighted in amber). Clicking opens a **Group Details** dialog that shows: * Display name and description * Membership type (Assigned or Dynamic) * Dynamic membership rule (if applicable) * Member counts: users, devices, and nested groups *** ## Clicking on Filters Filter names in the **Filter** column are clickable. A **Filter Details** dialog opens showing: * Filter display name and description * Platform scope * Management type (MDM or MAM) * The filter rule expression (e.g., `(device.osVersion -startsWith "10.0.19")`) *** ## Stats Bar Above the table, a stats strip shows at a glance: | Stat | What It Shows | | --------------------- | --------------------------------------------------------------------------- | | **Total Assignments** | Number of rows in the current filtered view | | **Assigned** | How many resources are actively assigned to the user | | **Not Assigned** | Resources present in the tenant but with no active assignment for this user | | **Resource Types** | Number of distinct policy categories in the results | | **Platforms** | Number of distinct platforms represented | *** ## Exporting the Data Two export options are available via the **Export** button: ### Standard Export Exports all visible rows to CSV, PDF, or HTML. Includes: * Resource type and name * Assignment type * Target name * Platform * Status (Assigned / Not Assigned) * Filter name and filter type **Filename:** `user-assignments-overview.csv` (or `.pdf` / `.html`) ### Export for Bulk Assignments A structured CSV designed to be used as input for bulk assignment operations. Includes: * PolicyName * GroupName * AssignmentDirection * AssignmentAction (pre-filled as `Add`) * Filter name and filter type **Filename:** `rollouts-overview.csv` {% hint style="info" %} The bulk export is useful when you want to replicate a user's assignment set to another group or tenant environment. {% endhint %} *** ## Common Use Cases **Why is this compliance policy applied to this user?**\ Search for the user, find the compliance policy in the results. The **Target** column shows which group delivered it. If the **nested badge** is shown, the delivery is through a parent group. **A user's device is non-compliant — which policy flags it?**\ Filter Resource Type by `Compliance Policy` and review the policies listed. **Verify a new joiner has the correct security baselines**\ Filter Resource Type by `Security Baseline` and confirm the expected baselines are listed as Assigned. **Pre-offboarding documentation**\ Export the Standard Export before disabling the account — this gives you a record of everything the user was subject to. **The user says a setting is being applied that they should not have**\ Look for the policy name in the results. If it shows a nested badge, expand the group chain to find the unexpected membership path. **Is the user excluded from a sensitive policy?**\ Search for the policy name in the results search box — if it does not appear at all, the user has no active assignment for it (either excluded or simply not targeted). *** ## Related Pages * [User App Assignments](/intune-assistant/assignments/user-assignments/user-assignments-for-apps) * [Group Assignments](/intune-assistant/assignments/group-assignments) * [All Assignments](/intune-assistant/assignments/all-assignments) * [Filter Assignments](/intune-assistant/assignments/assignments-with-filters) # Security # Intune Administrator Analyzer View Role Based Access overview from an Intune perspective. ## Intune Admin Analyzer ### Overview The **Intune Admin Analyzer** is a powerful security analysis tool that helps you identify over-privileged administrator accounts in your Microsoft Intune environment. By analyzing actual user activity patterns against assigned administrative roles, you can ensure that users have appropriate access levels based on their real usage. *** ### Why Use the Intune Admin Analyzer? Following the principle of **least privilege**, it's crucial to ensure that administrators only have the permissions they actually need. The Intune Admin Analyzer helps you: * **Identify inactive administrators** - Users with admin roles but no activity * **Detect over-privileged accounts** - Users with admin rights who only perform read operations * **Understand role membership** - See direct, group, and nested group assignments * **Make informed decisions** - Get data-driven recommendations for role optimization *** ### Getting Started #### Accessing the Analyzer 1. Navigate to the **RBAC** section from the main sidebar 2. Click on the **Intune Admin Analyzer** card #### Running an Analysis The analyzer scans your Intune environment to identify all users with Intune Administrator privileges and analyzes their activity. **Step 1: Configure Analysis Period** 1. In the **Analysis Configuration** section, set the number of days to analyze * **Default**: 60 days * **Minimum**: 1 day * **Maximum**: 90 days 2. The tool will look back through Intune audit logs for the specified period **💡 Tip**: For a comprehensive analysis, we recommend analyzing at least 30-60 days to capture typical usage patterns. **Step 2: Run the Analysis** Click the **Run Analysis** button to start the scan. The process includes: 1. Identifying all Intune Administrator role members 2. Analyzing audit events for the specified period 3. Categorizing user activities (read, write, delete operations) 4. Flagging over-privileged users *** ### Understanding the Results #### Summary Dashboard After the analysis completes, you'll see four key metrics at the top of the page **1. Role Analyzed** * **Displays**: The name of the role being analyzed (typically "Intune Administrator") * **Shows**: Truncated Role ID for reference **2. Total Users** * **Displays**: Total number of users with the Intune Administrator role * **Includes**: Direct members, group members, and nested group members **3. Over-Privileged Users** * **Displays**: Number of users flagged for review **4. Analysis Period** * **Displays**: Number of days analyzed * **Shows**: Date range (e.g., "Mar 1 - Mar 27, 2026") *** #### User Analysis Table The main results table provides detailed information about each administrator: **Column Breakdown** | Column | Description | | ------------------ | ---------------------------------------------------------------------------- | | **Status** |

Green checkmark = Appropriate privileges
Warning = Over-privileged

| | **User** | Display name and User Principal Name (email) | | **Membership** | How the user has admin access (see below) | | **Activity Level** | Overall activity classification (None/Low/Medium/High) | | **Total Actions** | Total number of Intune actions performed | | **Read** | Number of read-only operations (🟢 Green) | | **Write** | Number of write/modify operations (🟡 Yellow) | | **Delete** | Number of delete operations (🔴 Red) | | **Details** | Click to see detailed information | **Membership Types** The analyzer identifies three types of role membership: **Direct** * User is directly assigned to the Intune Administrator role * Most transparent form of role assignment **Group** * User inherited admin rights through membership in a security group * The source group name is displayed below the badge **Nested** * User inherited admin rights through nested group membership * Member of a group that's member of another group assigned the role * The ultimate source group is displayed > 📸 **Screenshot Placeholder**: *Table rows showing examples of each membership type with badges* **Activity Level Classification** The analyzer automatically classifies users based on their activity: * **High**: User has performed delete operations (highest risk actions) * **Medium**: User has performed write/modification operations * **Low**: User has only performed read operations * **None**: User has performed no actions *** #### User Details Panel Click on any user row (or the **Info** button) to see detailed information: > 📸 **Screenshot Placeholder**: *User Details panel expanded showing all sections* **Sections in the Details Panel** **1. Basic Information** * User Principal Name (UPN) * User ID (GUID) *** ### Table Features #### Searching and Filtering The User Analysis table includes powerful search functionality: 1. Use the **search box** at the top right to filter users 2. Search works across: * User display names * User Principal Names * Membership types > 📸 **Screenshot Placeholder**: *Search box with example search query and filtered results* #### Sorting Click any column header to sort the results: * **First click**: Sort ascending * **Second click**: Sort descending * **Third click**: Return to default order Particularly useful columns to sort: * **Status**: See all over-privileged users first * **Total Actions**: Identify most/least active admins * **Activity Level**: Group users by activity type > 📸 **Screenshot Placeholder**: *Table with sorted column (showing sort indicator)* #### Pagination For organizations with many administrators: * Results are paginated for better performance * Navigate using page controls at the bottom * Shows current page and total pages *** ### Interpreting Results & Taking Action #### What is "Over-Privileged"? A user is flagged as over-privileged when: 1. **No Activity**: They have an Intune Administrator role but haven't performed any Intune actions during the analysis period 2. **Read-Only Usage**: They only performed read operations, suggesting they don't need full administrative access #### Recommended Actions Based on the analysis results, consider these actions: **For Users with No Activity** * Verify if the user still needs Intune Administrator access * Check if they've recently joined the team (extend analysis period) * Consider removing the role assignment if no longer needed * Contact the user to understand their requirements **For Users with Read-Only Activity** * Assign a read-only Intune role instead (e.g., "Intune Read Only Operator") * Remove full Administrator access * Follow principle of least privilege **For Nested Group Members** * Review group membership structure * Document the access path for audit purposes * Be cautious - changes may affect other members #### Best Practices * **Run regular analyses** - Schedule quarterly reviews of admin roles * **Document decisions** - Keep records of why users need admin access * **Use longer periods** - 60-90 days provide better insight than shorter periods * **Cross-reference with HR** - Verify access aligns with job responsibilities * **Implement JIT access** - Consider Just-In-Time admin access for occasional needs (PIM) *** ### Common Scenarios #### Scenario 1: New Administrator **Situation**: User shows zero activity but was just added last week. **Action**: This is expected. Run the analysis again in 30-60 days to see their activity pattern. *** #### Scenario 2: Seasonal Administrator **Situation**: User has no activity for 60 days but performs annual cleanup tasks. **Action**: Extend the analysis period to cover their active period, or implement Just-In-Time access for their annual tasks. *** #### Scenario 3: Read-Only Auditor **Situation**: User only performs read operations for compliance auditing. **Action**: Perfect candidate for role optimization. Assign "Intune Read Only Operator" or similar read-only role. *** #### Scenario 4: High Activity Administrator **Situation**: User shows high activity with delete operations. **Action**: This is appropriate for active admins. Ensure activity aligns with their job responsibilities. Consider enabling additional monitoring. *** ### Troubleshooting #### No Data Returned **Problem**: Analysis completes but shows 0 users. **Solutions**: * Verify you have permissions to read Intune roles * Check that users are assigned to the "Intune Administrator" role * Ensure your tenant has active Intune licensing #### Analysis Takes Too Long **Problem**: Analysis runs for more than 2-3 minutes. **Solutions**: * Reduce the analysis period (try 30 days instead of 90) * Check if your tenant has a large audit log volume * Try running during off-peak hours #### Unexpected Over-Privileged Results **Problem**: Active administrators are flagged as over-privileged. **Solutions**: * Extend the analysis period - they may work in cycles * Verify their activities are logged in Intune audit logs * Check if they use other admin portals (Azure AD, etc.) *** ### FAQ **Q: How often should I run this analysis?**\ A: We recommend quarterly reviews (every 3 months) as part of your access review process. **Q: Will this analysis remove any users or permissions?**\ A: No, this is a read-only analysis tool. It only provides recommendations - you must take action manually. **Q: What's the difference between Direct and Group membership?**\ A: Direct = user is directly assigned the role. Group = user inherits the role through security group membership. Nested = user is in a group that's in another group. **Q: Can I export the results?**\ A: Use the export functionality in the table header to download results as CSV or Excel for further analysis. **Q: Does this analyze custom Intune roles?**\ A: Currently, the analyzer focuses on the built-in "Intune Administrator" role. Custom role analysis may be available in future updates. **Q: What actions are considered "read", "write", or "delete"?**\ A: * **Read**: Viewing configurations, policies, devices, reports * **Write**: Creating or modifying policies, configurations, assignments * **Delete**: Removing policies, wiping devices, deleting configurations **Q: Are guest users included in the analysis?**\ A: Yes, any user with Intune Administrator role permissions is analyzed, including guest accounts. *** ### Security & Privacy Notes **Data Handling** * Analysis is performed in real-time and not stored * All data retrieved follows your organization's security policies * Only audit logs within your specified timeframe are analyzed **Permissions Required** * You must have permissions to read Intune roles and audit logs * You must have permissions to read Entra RBAC roles * Results are limited to what your account can access **Audit Compliance** * All API calls are logged in Azure AD audit logs * The analysis itself is auditable * No changes are made to your environment *** ### Additional Resources * [Microsoft Intune RBAC Documentation](https://docs.microsoft.com/en-us/mem/intune/fundamentals/role-based-access-control) * [Principle of Least Privilege Best Practices](https://docs.microsoft.com/en-us/security/privileged-access-workstations/overview) * [Intune Built-in Roles Reference](https://docs.microsoft.com/en-us/mem/intune/fundamentals/role-based-access-control#built-in-roles) *** ### Need Help? If you encounter issues or have questions: * Check the troubleshooting section above * Review your Intune role permissions * Contact your organization's Intune administrator * Refer to the IntuneAssistant support documentation *** *Last updated: March 2026* # Analyzer The Analyzer section contains tools that inspect your Intune environment and surface actionable recommendations. * [Group to Filter Analyzer](/intune-assistant/analyzer/group-to-filter-analyzer) — Identifies which dynamic groups can be replaced by Intune Assignment Filters. * [Compliance Policy Coverage Analysis](/intune-assistant/analyzer/compliance-coverage-analysis) — Explains why devices with no compliance policy assigned actually hit that state, per assignment, per policy. * [Intune RSOP](/intune-assistant/analyzer/intune-rsop) — Compares a device's real, on-device settings against what Intune has actually assigned to it. # Group to Filter Analyzer ## What It Does The Group to Filter Analyzer helps you identify which Azure AD dynamic groups used in Microsoft Intune can be replaced — or supplemented — by Intune Assignment Filters. Assignment Filters are a more efficient way to target devices than dynamic groups. They evaluate at policy assignment time rather than requiring device group membership to update, which means faster targeting and less infrastructure overhead. This tool scans all your device-based dynamic groups, compares their membership rules against Intune filter properties, and tells you which ones are candidates for conversion. *** ## How to Use It 1. Navigate to **Analyzer → Group to Filter Analyzer** in the left sidebar. 2. The page loads automatically and fetches all device-based dynamic groups alongside your existing assignment filters. 3. Review the results table. Each row represents one dynamic group. 4. Use the **search bar** to filter by group name or membership rule text. 5. Use the **Convertibility** dropdown to show only groups that are fully convertible, partially convertible, or not convertible. 6. Use the **Filter match** dropdown to show only groups that already have a matching filter, or only those that don't. 7. Click any group name to open a detail panel showing the full analysis. *** ## What You'll See ### Summary Cards At the top of the page, five cards give you an at-a-glance overview: | Card | Meaning | | ------------------ | --------------------------------------------------------------- | | Dynamic Groups | Total device-based dynamic groups found | | Convertible | Groups whose full membership rule maps to filter properties | | Partial | Groups where only part of the rule can be expressed as a filter | | Not Convertible | Groups with no mappable properties | | Filter Match Found | Groups where a matching filter already exists in your tenant | ### Table Columns | Column | Meaning | | --------------------- | ----------------------------------------------------------------- | | Group Name | Clickable — opens the detail panel | | Convertibility | Badge showing Convertible / Partial / Not Convertible | | Existing Filter Match | Any existing filters that match, with Exact or Partial match type | | Mappable Properties | Which group rule properties can be expressed as filter properties | | Membership Rule | The full AAD dynamic group rule | ### Detail Panel Clicking a group name opens a dialog showing: * The full membership rule * The suggested Intune filter rule (if one can be built) * Each mappable property and its filter equivalent * Any unmappable properties and why they can't be converted * All existing filters that match, with their platform and match type *** ## Convertibility Explained | Status | What It Means | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Convertible** | Every clause in the membership rule maps to a supported Intune filter property. You can create a filter with an equivalent rule. | | **Partial** | Some clauses map to filter properties, but others don't. You can create a filter for the mappable part, but it won't fully replace the group. | | **Not Convertible** | None of the membership rule properties exist as Intune filter properties. The group cannot be converted. | ### Supported Property Mappings | AAD Group Property | Intune Filter Property | | ------------------------------ | ------------------------------ | | `device.displayName` | `device.deviceName` | | `device.deviceManufacturer` | `device.manufacturer` | | `device.deviceModel` | `device.model` | | `device.deviceOSVersion` | `device.osVersion` | | `device.deviceOwnership` | `device.deviceOwnership` | | `device.enrollmentProfileName` | `device.enrollmentProfileName` | | `device.deviceTrustType` | `device.deviceTrustType` | | `device.deviceCategory` | `device.deviceCategory` | *** ## Filter Match Types When an existing filter in your tenant matches the suggested rule: | Match Type | Meaning | | ----------- | -------------------------------------------------------------------------------------------- | | **Exact** | The filter rule is identical to the suggested rule (after normalizing whitespace and casing) | | **Partial** | The filter rule contains at least one of the suggested rule's clauses | *** ## Requirements * **License**: Active customer (any tier) * **Permissions required**: `Group.Read.All` and `DeviceManagementConfiguration.Read.All` — both delegated, admin-consented * The page only shows **device-based** dynamic groups (membership rules that reference `device.` properties). User-based dynamic groups are excluded because Intune Assignment Filters are device-scoped. *** ## Common Questions **Why don't I see all my dynamic groups?** Only groups whose membership rule references device properties are shown. User-based dynamic groups (e.g. `user.department -eq "IT"`) are not relevant to Intune assignment filters and are excluded. **Can I apply the suggested filter automatically?** Not yet — the analyzer is read-only. Use the suggested filter rule shown in the detail panel to manually create a filter in the Intune portal. **What if a filter already exists?** The **Existing Filter Match** column and detail panel show you any filters that already match. If there's an exact match, you may be able to switch your assignment to use that filter immediately. **Why is my group showing as Partial?** Part of the membership rule uses a property that Intune filters don't support (e.g. `device.extensionAttribute1`). You'd need to keep the group for that part of the targeting, or re-evaluate whether that clause is necessary. # Compliance Policy Coverage Analysis ## What It Does If your tenant has the Intune setting **"Mark devices with no compliance policy assigned as Not compliant"** turned on, devices that fall outside every compliance policy's assignment become noncompliant under a built-in rule. Intune tells you *that* a device has no compliance policy — it doesn't tell you *why*. The Compliance Policy Coverage Analysis answers that question. For every device Intune reports as missing a compliance policy, it works through each compliance policy in your tenant the same way you would by hand: does this policy's assignment reach the device or its user, does an exclusion apply, does an assignment filter let the device through? Every result is backed by evidence — a matched or unmatched group, a proven exclusion, a filter outcome — never a guess. It covers Windows, iOS, Android, and macOS devices. *** ## How to Use It ### Run the full analysis 1. Navigate to **Analyzer → Compliance Coverage** in the left sidebar. 2. Click **Run Analysis**. This schedules the real "devices without a compliance policy" report at Intune, waits for it to finish, and then checks every device it lists. 3. The page shows live progress while it runs — this can take anywhere from a few seconds to a few minutes depending on how many devices and compliance policies your tenant has. You can click **Cancel** at any point to stop it — this immediately removes anything gathered so far. 4. When it finishes, you'll see a summary of how many devices were found, broken down by result, followed by the full device list. 5. Click any device row to expand it and see the reasoning for every compliance policy that was checked against it. ### Investigate a single device 1. Go to **Devices → Overview** and open a device that shows as **Noncompliant**. 2. In the device details panel, find the **Compliance Policy Investigation** card and click **Why no compliance policy?** 3. The result appears inline within a couple of seconds — no need to run the full tenant-wide analysis first. *** ## What You'll See ### Summary cards * **Devices without a compliance policy** — how many devices Intune currently reports in this state. * One card per result type (see below), with a count. ### Per-device result Each device gets one overall result and a breakdown per compliance policy: | Result | What it means | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Should Apply But Missing** | A policy's assignment genuinely reaches this device — no exclusion, no filter blocking it — yet Intune isn't applying it. This is the case worth escalating: check the device's check-in history, enrollment state, or recent assignment changes. | | **Not Targeted** | Neither the device nor its user is in scope for any compliance policy's assignment. This is usually the real explanation — the device (or its user) simply isn't covered by any assignment yet. | | **Excluded** | An assignment would otherwise apply, but the device or user is a member of an exclusion group on that policy. | | **Filtered Out** | An assignment would otherwise apply, but an assignment filter attached to it doesn't permit this device. | | **Unknown** | Something couldn't be fully verified — usually a group membership check that failed, or an assignment filter that uses syntax this analysis doesn't yet support. Never silently treated as "not applicable." | A device with no primary user gets an additional note: assignments made to a user group can never reach a device with nobody signed in. If the device is meant to be shared, it needs a device-based assignment (a device group, or "All Devices") instead. *** ## Requirements * You need an active IntuneAssistant subscription — this analysis is included for every customer, it isn't a separate paid add-on. * Neither the tenant-wide run nor the single-device investigation needs a Worker set up — both work immediately for any active customer. * If you'd rather have this run automatically on a schedule and emailed to you, you can additionally set it up as a Worker job under **Worker → Jobs** — that path does require a registered Worker, same as any other scheduled job. *** ## Common Questions **Why does the tenant-wide run take a while the first time?** It has to read every compliance policy and its assignments, every assignment filter, and check group membership for every device (and its user) found in the "no compliance policy" state. Policies, assignments, and filters are only fetched once per run, not once per device. **A device shows "Unknown" for a policy — what should I do?** Usually this means one of the policy's assigned groups couldn't be checked, most often because it has hidden membership (which needs an extra permission we don't request by default). Re-run the single-device investigation from the Devices page for more detail. **Does this fix anything automatically?** No — this is a read-only, evidence-gathering tool. It never changes an assignment, group, filter, or device. **Does the tenant-wide run keep my device data afterward?** No. Results are shown to you while you're looking at the page and then discarded — nothing about which devices were found, or why, is kept in the backend. You can also cancel a run in progress at any time; doing so immediately stops it and removes anything gathered so far. # Intune RSOP ## What It Does Intune RSOP answers a simple but important question: **is a device really configured the way Intune says it should be?** Intune tells you what's assigned to a device. It doesn't tell you whether that device actually applied every setting correctly. Intune RSOP closes that gap: you export a settings snapshot from the device itself (using the IntuneAssistant tool, run locally on the device), upload it here, and the analyzer compares it setting-by-setting against what your tenant has actually assigned to that device — including its primary user, if it has one. The result is a clear match/mismatch report and a compliance score for that one device, right now. *** ## How to Use It 1. On the managed device you want to check, run the IntuneAssistant export tool to produce a settings snapshot (a `.json` file). 2. In IntuneAssistant, navigate to **Analyzer → Intune RSOP** in the left sidebar. 3. Drop the exported `.json` file onto the upload area, or click it to browse for the file. 4. The analyzer fetches what Intune actually has assigned to that device and compares it against the file you uploaded. 5. Review the compliance score, the summary counts, and the per-setting table. 6. Use the **status filter** to narrow the table down to just mismatches, missing settings, or unexpected ones. 7. Click **Analyze another device** to run a new comparison. Each file you upload must cover a single device — if it contains settings from more than one device, the analyzer will ask you to split it up. *** ## What You'll See ### Compliance Score A single percentage showing how many of the device's assigned settings actually match. Above the score, you'll see the device's name and its primary user (if it has one). ### Summary Cards | Card | Meaning | | ---------- | -------------------------------------------------------------------------------------------------------- | | Match | The device's reported value matches what Intune has configured | | Mismatch | Intune has this setting assigned, but the device reported a different value | | Missing | Intune has this setting assigned, but the device's export didn't report it at all | | Unexpected | The device reported a setting the analyzer couldn't match to anything currently assigned to it in Intune | ### Per-Setting Table Each row shows the setting name, the policy it comes from, the value Intune expects, the value the device actually reported, and a status badge. A small `*` next to a Match badge means the two values only agreed after ignoring minor formatting differences (like extra spaces or letter casing) — worth a quick look if you want to confirm it's a genuine match. Rows with an info icon next to the setting name can be clicked to expand — this shows exactly why the device gets that policy (which group it's a member of, an "All Devices"/"All Licensed Users" assignment, or a filter, along with the outcome for each). ### Recent Analyses Below the main results, a short list of your most recent RSOP analyses for other devices, each showing its device, primary user, when it ran, and its compliance score. *** ## Requirements * **License**: Active customer (any tier). Currently available to beta customers only while the feature is being rolled out. * **Permissions required**: your account needs read access to managed devices and configuration policies in your tenant — the same access already used by other device and analyzer tools in IntuneAssistant. If it's missing, you'll be prompted to grant consent. * The export tool must be run on the device itself, by someone with access to read its local policy state. * Keeping a history of past analyses ("Recent analyses") requires the Troubleshooter add-on. Without it, you can still run and view every analysis — it just won't be remembered afterward. *** ## Common Questions **Why does a setting show as "Mismatch" when I'm sure the device has the right value?** Intune and a device's local registry don't always represent a value in the exact same text format (for example, an option name versus a raw number). The table shows both raw values side by side so you can judge for yourself — a mismatch is always worth a look, but it isn't always a real configuration problem. **Why does a setting show as "Missing"?** Intune has this setting assigned to the device, but the exported file didn't include it at all. This can mean the device hasn't applied the policy yet, or the export tool didn't capture that particular setting. **Why does a setting show as "Unexpected"?** The device reported a setting that the analyzer couldn't tie back to anything currently assigned to it in Intune — often left over from a policy that used to apply but no longer does. **Is my data shared across devices or customers?** No. Each analysis is scoped to your own tenant, and the history list only ever shows analyses you've run in your own tenant. # Drift Monitor Take a snapshot of your Intune and Entra ID configuration as it should be, then let IntuneAssistant continuously compare live settings against that baseline — so you find out about unwanted changes before your users do. # Monitor Overview ## What Is This Page? **Monitor Overview** is the landing page of the Drift Monitor section, reached via **Drift Monitor > Monitor Overview** in the sidebar. It checks that the permissions Drift Monitor needs are in place, and then gives you three cards to jump into the rest of the feature. ## Permission Check Drift Monitor relies on a Microsoft-managed application called **Unified Tenant Configuration Management (UTCM)**. When the page loads, it automatically checks whether this application has been granted all the Microsoft Graph permissions it needs. * **Green card** — all required permissions are present. You are ready to create monitors. * **Red card** — one or more permissions are missing. The card lists which ones, and links to an external setup guide that walks through granting them. Click **Recheck** at any time to re-run the check, for example right after an admin has granted the missing consent. {% hint style="warning" %} If UTCM is not fully configured, Drift Monitor will not be able to detect any configuration changes. Fix any missing permissions here before creating monitors. {% endhint %} ## Where To Go From Here Three navigation cards take you deeper into the feature: | Card | Takes You To | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Global Overview** | [Global Overview](/intune-assistant/monitor/global-overview) — a dashboard summarising every monitor, its drifts, and recent run history | | **All Monitors** | [All Monitors](/intune-assistant/monitor/all-monitors) — the full list of configured monitors, with the option to add a new one | | **Drift Alerts** | [Drifts](/intune-assistant/monitor/drifts) — every configuration drift detected across all monitors | A closing section links out to the public documentation and the IntuneAssistant GitHub repository if you want to learn more or report an issue. ## Common Questions **Do I need to do anything on this page every time?**\ No. Once the UTCM permission check shows green, you can go straight to Global Overview, All Monitors, or Add Monitor from the sidebar without revisiting this page. **What if the permission check stays red after I've granted consent?**\ Click **Recheck**. Microsoft Graph permission changes can take a minute to propagate. ## Related Pages * [Global Overview](/intune-assistant/monitor/global-overview) * [All Monitors](/intune-assistant/monitor/all-monitors) * [Add Monitor](/intune-assistant/monitor/add-monitor) * [Drifts](/intune-assistant/monitor/drifts) # Global Overview ## What Is This Page? **Global Overview** is the main dashboard for Drift Monitor. It pulls together every monitor you have configured, every drift that has been detected, and the history of every monitor run, into one summarised view — with charts, stat cards, and a per-monitor table. ## Why Would You Use This? * Get a single-glance answer to "is anything drifting right now?" * See which monitors are active and which are inactive * Check how reliably your monitors are running (success rate of recent runs) * Drill into which specific properties changed on a drifted resource, without leaving the page ## How Data Loads Unlike most pages in IntuneAssistant, Global Overview does **not** load automatically. The first time you visit, you'll see a welcome card with a **Load Overview** button — click it to fetch your monitors, drifts, and run history. Once loaded, the data is cached for your session. Leaving the page and coming back shows the cached data instantly; the button changes to **Refresh** so you can pull the latest data on demand. {% hint style="info" %} You can cancel an in-progress load with the **Cancel** button. If the load fails, a red error card appears with a **Try Again** button. {% endhint %} ## Stat Cards | Card | What It Shows | | ------------------- | --------------------------------------------------------------------- | | **Active Monitors** | Number of active monitors, out of the total configured | | **Success Rate** | Percentage of monitor runs that completed successfully | | **Active Drifts** | Number of drifts currently unresolved, out of the total ever detected | | **Drifts Fixed** | Number of drifts that have been resolved | ## Charts * **Monitor Status** — a pie chart showing the split between active and inactive monitors. * **Run Outcomes** — a bar chart showing how many runs completed successfully, partially succeeded, or failed. ## Configuration Monitors Table Below the charts, a table lists every monitor with: * Name and description * Status badge (Active / Inactive) * Drift count — clickable when greater than zero * Last run status and date * Run frequency (shown as "Every Xh") * A **View** action linking to that monitor's [detail page](/intune-assistant/monitor/monitor-details) ### Viewing a Monitor's Drifts Clicking a non-zero drift count opens a dialog listing every drift for that monitor: the affected resource, when it was first reported, its status, and a side-by-side comparison of the current value versus the desired (baseline) value for each drifted property. ## Common Questions **Why is the page empty when I first open it?**\ Global Overview waits for you to click **Load Overview** rather than fetching automatically. Click it once and the dashboard fills in. **How current is the data shown here?**\ It reflects the latest results your monitors have already produced — click **Refresh** to pull the newest data from the server. ## Related Pages * [All Monitors](/intune-assistant/monitor/all-monitors) * [Monitor Details](/intune-assistant/monitor/monitor-details) * [Wall Dashboard](/intune-assistant/monitor/wall-dashboard) * [Drifts](/intune-assistant/monitor/drifts) # Wall Dashboard ## What Is This Page? The **Wall Dashboard** is a NOC-style display built to be shown on an office TV or a wall-mounted screen rather than viewed in a normal browser tab. It has a dark, high-contrast theme, large tabular numbers, a live clock, and a fullscreen toggle — and deliberately has almost no interactive controls, so nothing accidentally changes if someone taps the screen. ## Why Would You Use This? * Keep a permanent status board running in an operations room or team area * Give the whole team passive visibility into drift status and worker health without anyone needing to open IntuneAssistant * Spot a spike in drifts or a failed worker at a glance during an incident ## Auto-Refresh The dashboard refreshes itself automatically every **60 seconds**. A countdown ring in the header shows how long until the next refresh, and a **last updated** timestamp appears in the footer. ## Fullscreen Mode Click the fullscreen icon in the top-right corner to expand the dashboard to fill the entire screen (using your browser's native fullscreen mode) — useful when displaying it on a dedicated monitor. Click again to exit fullscreen. ## What You Will See ### Top Bar The IntuneAssistant logo, a live clock and date, a **Worker healthy / degraded / offline** status pill, the refresh countdown ring, and the fullscreen toggle. ### KPI Row Eight tiles: Active Monitors, Inactive Monitors, Active Drifts, Resolved Drifts, Successful Runs, Failed Runs, Success Rate, and Snapshot Jobs (with a note of how many are currently running). ### Active Drifts The 10 most recently detected, unresolved drifts — each showing the affected resource, its type, which monitor flagged it, and how long ago it was reported. When nothing is drifting, this panel shows "No active drifts detected — all monitored configurations match their baselines." ### Recent Run History The last 8 monitor runs, each with a status dot (green success, amber partial, red failed), the monitor name, a small bar indicating the drift count, and the completion time. ### Worker Instances Up to 6 background worker machines that execute drift checks, each with a health dot (healthy, stale, offline, unknown), its version, and status chips (Enabled, Accepting Jobs, Auto-Update). ### Monitors Up to 10 monitors with a status dot, name, active-drift count badge, and last run time. ### Recent Snapshot Jobs The last 5 baseline snapshot jobs with a status dot and timestamp. {% hint style="info" %} The Wall Dashboard shows the latest results your monitors have already produced — it does not trigger a live check against Intune itself when it refreshes. Freshness depends on how recently your monitors last ran. {% endhint %} ## Related Pages * [Global Overview](/intune-assistant/monitor/global-overview) — the interactive equivalent, with drill-down and filtering * [All Monitors](/intune-assistant/monitor/all-monitors) * [Drifts](/intune-assistant/monitor/drifts) # All Monitors ## What Is This Page? **All Monitors** is the management view for every configuration drift monitor you have set up. A monitor watches a chosen set of Intune configuration resources (its **baseline**) and periodically checks whether their live settings still match what was captured when the monitor was created. ## What You Will See Four stat cards summarise your monitors at a glance: Total Monitors, Active, Total Drifts (across every monitor), and Recent Runs. Below that, a table lists every monitor with: | Column | What It Shows | | ----------------- | ----------------------------------------------------------------------------- | | **Monitor Name** | Name and description | | **Status** | Active or Inactive badge | | **Active Drifts** | Number of unresolved drifts, highlighted red when greater than zero | | **Last Run** | Success / partially-successful / failed badge and timestamp, or "No runs yet" | | **Frequency** | How often the monitor runs, in hours | | **Created** | The date the monitor was created | If you have no monitors yet, the table is replaced with a call-to-action to add your first one. ## How to Use It * Click **Add Monitor** to open the [Add Monitor](/intune-assistant/monitor/add-monitor) wizard and create a new one. * Click **Refresh** to reload the list. * Click **View** on any row to open its [Monitor Details](/intune-assistant/monitor/monitor-details) page. * Click the trash icon on a row to delete a monitor. A confirmation dialog warns that this cannot be undone. {% hint style="warning" %} There is currently no way to pause a monitor, change its schedule, or edit which resources it watches from this page. To change what is being monitored, delete the monitor and create a new one with the resources you want. {% endhint %} ## Common Questions **What does "Active" vs "Inactive" mean?**\ Active monitors are currently being checked on their configured schedule. Inactive monitors exist but are not currently running checks. **Why does a monitor show "No runs yet"?**\ The monitor was created but has not completed its first scheduled check yet. ## Related Pages * [Monitor Details](/intune-assistant/monitor/monitor-details) * [Add Monitor](/intune-assistant/monitor/add-monitor) * [Global Overview](/intune-assistant/monitor/global-overview) * [Drifts](/intune-assistant/monitor/drifts) # Monitor Details ## What Is This Page? The **Monitor Details** page shows everything about a single monitor: its baseline, every resource it watches, and every drift it has detected. You arrive here by clicking **View** on a row in [All Monitors](/intune-assistant/monitor/all-monitors) or [Global Overview](/intune-assistant/monitor/global-overview). ## What You Will See ### Header The monitor's name and description, a **Refresh** button, a **Delete Monitor** button, and a **Back** button. ### Info Cards Four cards show: Status (Active/Inactive), Run Frequency, Mode, and whether the monitor runs as the app's own service principal or on behalf of a specific user. ### Stat Cards Total Resources, Active Drifts, Resources with Drifts, and Compliant Resources. ### Monitor Information Monitor ID, Tenant ID, when and by whom it was created, when and by whom it was last modified, and — if applicable — who it is running on behalf of. ### Baseline Configuration The name and description of the baseline this monitor checks against, collapsed by default to three summary tiles: Total, Compliant, and With Drifts. Expand it to see a searchable, paginated table of every monitored resource — its name, type, number of properties, and a drift-status badge. Click **View Details** on any resource to open a dialog with its full, raw property values. ### Detected Drifts One expandable card per detected drift, showing the resource name, an Active/Fixed status badge, how many properties drifted, the resource type, and when it was first reported. Expand a drift to see a side-by-side comparison of every drifted property: its **current value** versus its **desired value** (from the baseline). When there are no drifts, this section shows a green "No Drifts Detected" state. If a drifted change is actually correct, click **Accept Drift** on that card and provide a justification. This updates the monitor's baseline to match the current value and marks the drift resolved — see [Drifts](/intune-assistant/monitor/drifts#accepting-a-drift) for more detail. ## How to Use It * Click **Refresh** to reload the monitor's current state. * Expand or collapse the Baseline Configuration and Detected Drifts sections as needed. * Click **Delete Monitor** to remove it — a confirmation dialog warns this cannot be undone, and you'll be taken back to the monitors overview afterward. {% hint style="warning" %} This page does not offer a way to edit the monitor's schedule, mode, or which resources it watches. If you need to change what's monitored, delete this monitor and create a new one from [Add Monitor](/intune-assistant/monitor/add-monitor). {% endhint %} ## Common Questions **What's the difference between "Total Resources" and "Compliant Resources"?**\ Total Resources is everything the baseline captured. Compliant Resources is the subset that still matches the baseline exactly — the difference between the two is your active drift count. **Where do I see exactly what changed?**\ Expand the relevant card under Detected Drifts. Every changed property is listed with its current value next to its desired (baseline) value. **What does "Accept Drift" do?**\ It updates the monitor's baseline so the drifted properties now match the resource's current live values, and marks the drift resolved. Use it when the change was intentional and you want it to become the new expected state. ## Related Pages * [All Monitors](/intune-assistant/monitor/all-monitors) * [Global Overview](/intune-assistant/monitor/global-overview) * [Add Monitor](/intune-assistant/monitor/add-monitor) # Add Monitor ## What Is This Page? **Add Monitor** is a guided, five-step wizard for creating a new configuration drift monitor: **Template → Configure → Snapshot → Review → Done**. ## How to Use It ### Step 1 — Template Browse a gallery of monitor templates, filterable by category (All, Intune, Entra ID, Exchange) and searchable by name. Each card shows which resource types it covers. * Templates already in use show an **Active** badge and take you straight to that existing monitor instead of creating a duplicate. * Entra ID and Exchange templates are currently marked **Coming soon** and cannot be selected yet. * A **Custom Monitor** card lets you pick your own combination of resource types instead of using a template. This option requires an **Enterprise** license — on other plans the card is disabled with an "Upgrade to Enterprise" message. ### Step 2 — Configure Enter a **Monitor Name** (8–32 characters, letters, numbers, and spaces only) and an optional description. * For a template, the resource types are fixed and shown read-only. * For a Custom Monitor, pick any combination of resource types from a searchable list grouped into: Compliance Policies, Configuration Policies, Settings Catalog, Enrollment, Security & Roles, and Scripts & Remediations. At least one type is required. ### Step 3 — Snapshot Click **Create Snapshot & Review**. IntuneAssistant captures the current state of every resource of the chosen type(s) — this becomes the monitor's baseline. This can take a few minutes; the page polls automatically and shows progress until the snapshot succeeds, partially succeeds, or fails. ### Step 4 — Review The captured resources are shown grouped by resource type, with counts, and are searchable. Confirm everything looks right, then click **Create Monitor** — or go **Back** to adjust your selection. If the snapshot captured zero resources, **Create Monitor** is disabled instead — a monitor needs at least one resource as its baseline. The page tells you which of two things happened: either the snapshot genuinely found none of the selected resource type(s) in your tenant, or something went wrong while capturing them (in which case the reported error is shown so you can check the required Graph permissions in Step 2). ### Step 5 — Done A confirmation screen with buttons to go to **All Monitors** or straight to the new monitor's [detail page](/intune-assistant/monitor/monitor-details). {% hint style="info" %} The baseline is captured in Step 3, before the monitor is actually created in Step 4 — so as soon as you click Create Monitor, the monitor is already comparing live settings against that baseline. {% endhint %} ## What You Can Monitor Available now (Intune): Compliance Policies (Android, iOS, macOS, Windows), Windows Configuration Policies, Role Assignments, Assignment Filters, Enrollment Status Page, and Platform Restrictions. Coming soon: Entra ID Conditional Access Policies, Entra ID Group Memberships, and Exchange Transport Rules. Custom Monitors (Enterprise only) can combine any of: Compliance Policies, Configuration Policies, Settings Catalog, Enrollment, Security & Roles, and Scripts & Remediations. ## Requirements * An **Enterprise** license is required to create a Custom Monitor. All templates are available on any active plan. * The monitor watches by **resource type**, not by individual policy, group, or scope tag — every existing resource of the selected type(s) is captured into the baseline. ## Common Questions **How often does the monitor check for drift after I create it?**\ There's no schedule to configure in this wizard — checking cadence is handled automatically once the monitor is created. **Can I choose which specific policies to monitor instead of a whole resource type?**\ Not currently. A monitor covers every resource of the type(s) you selected in Step 2. **What happens if the snapshot in Step 3 fails?**\ The wizard shows the failure and lets you retry from the same step rather than losing your Step 2 selections. **What if the snapshot succeeds but finds no resources?**\ Create Monitor is disabled in that case. If it's just that your tenant doesn't have any resources of the selected type(s), that's expected — pick a different template or resource type. If you expected resources to be found, the Review step will show the reported error and point you to the required Graph permissions. ## Related Pages * [All Monitors](/intune-assistant/monitor/all-monitors) * [Monitor Details](/intune-assistant/monitor/monitor-details) * [Snapshots](/intune-assistant/monitor/snapshots) # Drifts ## What Is This Page? **Drifts** lists every configuration drift IntuneAssistant has detected across all your monitors. A drift is a difference between a monitor's saved baseline and the resource's current, live state in Intune or Entra ID. ## How to Use It Data is not loaded automatically — click **Load Drifts** to fetch the current list. You can cancel a load in progress, and click **Refresh** afterward to pull the latest results. Once loaded, use the filter bar to narrow the list by: * **Monitor** — show drifts from one monitor only * **Status** — Active or Fixed * **Resource Type** — the kind of Intune/Entra resource affected Click **Show Details** on any drift card to expand a full before/after comparison of every property that changed. ### Accepting a Drift If a detected change is actually correct — for example, someone intentionally updated a setting and the baseline should now reflect that — click **Accept Drift** on the drift card. You'll be asked to provide a short justification explaining why the change is being accepted; this is required and is recorded for audit purposes. Accepting a drift updates the monitor's baseline so the changed properties now match the resource's current live values. The drift is then marked resolved, since there is no longer a difference to detect. {% hint style="warning" %} Accepting a drift is different from fixing the underlying resource. It permanently changes what the monitor expects going forward — use it when the current state is the one you want to keep, not as a way to temporarily silence an alert. {% endhint %} ## What You Will See A stats row shows Total Drifts, Active Drifts, Fixed Drifts, Total Monitors, and Monitors with Drifts. Below the filter bar, each drift is shown as a card with: * The affected resource's display name * An **Active** / **Fixed** status badge * Which monitor flagged it * The resource type * How many properties changed * When it was first detected Expanding a card shows every drifted property with its **current value** and **desired value** (from the baseline) side by side. {% hint style="info" %} Before you click **Load Drifts**, the page shows a "Ready to view configuration drifts" prompt rather than an empty list — this is different from loading and finding zero drifts. {% endhint %} ## Common Questions **What does "Fixed" mean for a drift?**\ The resource's live configuration now matches the baseline again, so the drift is no longer active. **Can I accept a drift as the new expected state instead of reverting it?**\ Yes. Click **Accept Drift**, provide a justification, and the monitor's baseline is updated to match the current value. Use this when the change was intentional and you want the monitor to stop flagging it. **What's the difference between fixing a drift and accepting it?**\ Fixing a drift means changing the resource in Intune/Entra back to match the baseline — the monitor will then report it as Fixed on its next check. Accepting a drift instead changes the baseline to match the resource, keeping the new configuration going forward. ## Related Pages * [All Monitors](/intune-assistant/monitor/all-monitors) * [Monitor Details](/intune-assistant/monitor/monitor-details) * [Global Overview](/intune-assistant/monitor/global-overview) # Snapshots ## What Is This Page? **Snapshots** lets you capture a point-in-time copy of selected Intune/Entra resource configurations, independently of creating a monitor. A snapshot becomes available to use as a baseline the next time you create a monitor. A **snapshot job** is the run that produces the snapshot — it has its own status and timestamps. A **snapshot** is the resulting data: the list of resources captured. One successful job produces one snapshot. ## How to Use It 1. Click **New Snapshot** to open the creation dialog. 2. Give it a name and optional description, and choose which resource types to capture. 3. Submit — the snapshot job runs asynchronously and appears in the jobs table with a status of Not Started or In Progress. 4. Click **Refresh** at any time to update the table, or click the eye icon on a job to see its full details. Once a job succeeds, you can: * Click the monitor icon on that row to jump straight into [Add Monitor](/intune-assistant/monitor/add-monitor) using this snapshot as the baseline. * Click the trash icon to delete the job and its snapshot data. A confirmation dialog warns this cannot be undone. ## What You Will See Three stat tiles: Succeeded, In Progress, and Failed. The **Snapshot Jobs** table lists each job with: | Column | What It Shows | | ---------------------- | --------------------------------------------------------------------- | | **Name / Description** | What you named the snapshot | | **Status** | Not Started, In Progress, Succeeded, Partial, or Failed, with an icon | | **Resources** | Number of resource types requested | | **Created** | When the job was submitted | | **Completed** | When the job finished, if it has | | **Actions** | View, create monitor from this snapshot, and delete | The details dialog shows the job's status, snapshot ID, timestamps, the requested resource types, and — once complete — the actual captured resources (name and type), with a prompt to create a monitor from it. If you have no snapshots yet, the table is replaced with a call-to-action to create your first one. ## Common Questions **Why would I take a snapshot without immediately creating a monitor?**\ To capture a baseline now (for example, right after a change window) and decide later whether to turn it into an ongoing monitor. **What happens if I delete a snapshot job that a monitor is using as its baseline?**\ Deleting a snapshot job only removes the job and its standalone snapshot record — it does not affect a monitor that was already created from it, since the monitor stores its own baseline at creation time. ## Related Pages * [Add Monitor](/intune-assistant/monitor/add-monitor) * [All Monitors](/intune-assistant/monitor/all-monitors) # Policies ## What Is This Section? The **Configuration Management** section of Intune Assistant gives you a complete, unified workspace to understand every configuration policy in your Microsoft Intune environment. It goes far beyond what the native Intune portal shows you — surfacing not just what policies exist, but what settings they contain, whether those settings are duplicated across policies, and whether any of them actively conflict with each other. This section is built for everyone who needs to understand the configuration state of a managed environment: * **IT Administrators** who manage day-to-day Intune operations and need quick answers about which policies do what * **Architects** who design the policy structure and need to verify it is clean, consistent, and optimised * **Security Engineers** who need to audit that the correct settings are enforced and that no two policies are fighting each other * **CISOs and Compliance Officers** who need evidence that the right controls are in place, across all platforms and policy types *** ## Why Does This Section Exist? Microsoft Intune has grown to support several different ways of configuring devices: the modern **Settings Catalog**, the older **Device Configuration** profiles, and **Group Policy** ingested via ADMX or Group Policy Analytics. Over time, most organisations accumulate policies across all three of these systems — often without a clear overview of how they relate to each other. The result is a configuration landscape that is hard to audit: * The same setting might be configured in a Settings Catalog policy and again in an old Device Configuration profile — possibly with different values * Policies may have no assignments, meaning they exist in the tenant but apply to nobody * New policies may be created without checking whether a setting is already covered elsewhere Intune Assistant solves this by pulling all policies and their settings into a single view, running automated duplicate and conflict detection, and giving you the filters and export tools to act on what you find. *** ## What Is Available ### [Intune Policy Overview](/intune-assistant/policies/policy-overview) A full inventory of every configuration policy in your tenant. See the policy name, type, platform, assignment status, number of settings, and all assignment targets — including which groups are included and which are excluded. You can select multiple policies and export or delete them in bulk. **Use this when you want to know:** What policies exist? Are they all assigned? When were they last changed? *** ### [Policy Settings Overview](/intune-assistant/policies/policy-settings-overview) A granular, setting-by-setting breakdown across all three policy types: Settings Catalog, Device Configuration, and Group Policy. Each setting is shown with its name, value, source policy, platform, and assignment status. The page automatically detects **duplicate settings** (the same setting configured in multiple policies with the same value) and **conflicting settings** (the same setting configured with different values across policies that target overlapping groups). **Use this when you want to know:** What does each individual setting do? Are there any settings I have configured twice? Are any settings set to different values in different policies? *** ## How the Two Pages Work Together Think of the two pages as two layers of the same information: | Layer | Page | What It Answers | | ----------------- | ----------------- | ------------------------------------------------------------------- | | **Policy layer** | Policy Overview | Which policies exist, what type they are, whether they are assigned | | **Setting layer** | Settings Overview | What is inside each policy, and whether any settings clash | Start with the **Policy Overview** for a broad inventory. Drill into the **Settings Overview** when you need to understand what is actually being configured and whether it is consistent. *** ## Getting Started 1. Navigate to **Configuration** in the sidebar 2. Click **View Policy Overview** to load your policy inventory, or 3. Click **Explore Now** on the Settings card to load the granular settings view 4. Use the filter and export options on each page to work with the data {% hint style="info" %} **Tip:** Both pages fetch data in real time from Microsoft Graph. If you have a large number of policies, the settings page shows a progress bar with three steps — Settings Catalog, Device Configuration, and Group Policy — so you can see exactly what is loading. {% endhint %} *** ## Related Sections * [Assignments](broken://pages/fae346d4d64f082ee7acae5f94a7007c3320bd5d) — see which groups your configuration policies are assigned to * [Conditional Access](broken://pages/1a66996271ff3d3bce1157ee6830b086be5ef6be) * [Devices Overview](broken://pages/7062f4991a718adb0ce7447e9f743bbcde03a7ff) # Policy Overview ## What Is This Page? The **Intune Policy Overview** page is a complete inventory of every configuration policy in your Intune tenant. It fetches all policy types in a single request — Settings Catalog policies, Device Configuration profiles, Compliance policies, Security Baselines, Administrative Templates, and anything else that lives under configuration in Intune — and presents them in one filterable, searchable, exportable table. Beyond listing what exists, the page shows you whether each policy is assigned, which groups or built-in targets it is assigned to (including exclusions), how many settings it contains, and when it was last touched. You can select multiple policies and export or permanently delete them in bulk. *** ## Why Would You Use This? * You want a single, complete inventory of every configuration policy in the tenant * You need to identify policies that exist but have no assignment — they apply to nobody and are candidates for cleanup * You are preparing for a policy review, handover, or audit and need a structured export * You want to check when policies were created or last modified to understand whether they are current * You need to delete a batch of old or redundant policies safely, with a confirmation step * You want to see exactly which groups are included in or excluded from a policy's assignment without opening each policy individually in the Intune portal *** ## How to Load the Data {% stepper %} {% step %} ### Navigate to **Configuration → Policy Overview** Open the page in Intune Assistant. {% endstep %} {% step %} ### Click **Load Policies** Start loading the policy inventory. {% endstep %} {% step %} ### Wait for Intune Assistant to fetch the data Intune Assistant fetches all configuration policies from Microsoft Graph simultaneously with the group list and assignment filters. {% endstep %} {% step %} ### Review the populated table The table populates once all three data sources have responded. {% endstep %} {% endstepper %} > **Cancel:** A **Cancel** button appears while loading is in progress. Clicking it stops the request immediately and shows a retry card. > 📸 *\[Screenshot placeholder: Page in initial state showing the welcome card with a large Settings icon, a description, and the Load Policies button]* *** ## Understanding the Table Each row in the table represents one policy. The columns are: | Column | What It Shows | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Policy Name** | The policy name as it appears in Intune. If a description exists, it is shown in smaller muted text below the name — up to two lines, truncated if long. Click any row to open the full **Policy Details** dialog | | **Type** | The policy type, shown as an outlined badge — e.g., `Settings Catalog`, `Device Configuration`, `Compliance Policy`, `Security Baseline`, `Administrative Template` | | **Platform** | The device platform the policy targets. Colour-coded: blue for Windows (`windows10` / `windows10andlater`), green for Android, grey for iOS, purple for macOS | | **Assignments** | Up to 2 assignment targets shown directly in the cell. Each target is either a built-in label (`All Devices`, `All Users`) or a clickable group name. Groups excluded from the assignment are shown with a red **⊖** prefix. If there are more than 2 assignments, a `+N more` indicator appears. Click any group name to open the Group Details dialog | | **Scope Tags** | The Intune scope tags applied to the policy, shown as one badge per tag using the tag's display name. Shows a dash if no scope tags are set | | **Settings** | The number of individual settings inside the policy, shown as a plain number | | **Status** | **Assigned** (green badge) if the policy has at least one assignment target, or **Not Assigned** (grey badge) if it has none | | **Created** | The date the policy was created in Intune | | **Modified** | The date the policy was last modified | ### Assignment Target Types Assignments shown in the table and in the Policy Details dialog can be any of the following: | Type | What It Means | | --------------------- | --------------------------------------------------------------------------------------- | | **All Devices** | The policy applies to every enrolled device in the tenant regardless of group | | **All Users** | The policy applies to every licensed user in the tenant | | **Group name (blue)** | The policy is assigned to a specific Entra ID group — click to see group details | | **Group name (red)** | The group is **excluded** from the policy — devices and users in this group are skipped | > 📸 *\[Screenshot placeholder: Policy table showing several rows — Settings Catalog and Device Configuration types with blue and green platform badges, clickable group names and a red ⊖ excluded group in the Assignments column, green Assigned and grey Not Assigned status badges, and Created / Modified date columns]* *** ## Clicking on a Policy Row Clicking anywhere on a row (except on a group name link) opens the **Policy Details dialog**. This is a full-screen panel showing all information about the selected policy in one place. ### Policy Information | Field | What It Shows | | -------------- | -------------------------------------- | | Name | Full policy name | | Description | Full description text (untruncated) | | Type | Policy type badge | | Platform | Platform badge | | Settings Count | Total number of settings in the policy | ### Timestamps | Field | What It Shows | | ----------------- | -------------------------------------------- | | Created | Full date and time the policy was created | | Last Modified | Full date and time the policy was last saved | | Assignment Status | Assigned or Not Assigned badge | ### Assignments All assignment targets for the policy are listed. Each entry shows: * The group name (clickable, opens Group Details) or the built-in label (`All Users`, `All Devices`) * A prefix in red for excluded groups * Any **assignment filter** attached to the assignment — the filter name is shown in purple and is clickable, opening the **Filter Details dialog** with the filter rule expression, platform, and management type ### Settings The raw settings payload for the policy is displayed as formatted JSON. This is the exact data structure Intune uses to apply the settings to enrolled devices. > 📸 *\[Screenshot placeholder: Policy Details dialog open for a Settings Catalog policy. Left column shows name, type, platform, settings count. Right column shows created/modified timestamps and assignment status. Below: assignments list with two groups and one filter. Below that: JSON settings block in a scrollable code area]* *** ## Filters Five controls are available in the filter panel above the table: | Filter | What It Does | | --------------- | ------------------------------------------------------------------------------------------ | | **Search** | Free-text search across the policy name, policy type, platform value, and description text | | **Policy Type** | Multi-select — show only specific policy types from the values present in your tenant | | **Status** | Multi-select — show only `Assigned`, only `Not Assigned`, or both | | **Platform** | Multi-select — show only policies targeting a specific platform | | **Scope Tags** | Multi-select — show only policies that carry a specific scope tag, listed by display name | When at least one filter is active, a count is shown: `Showing X of Y policies`. Click **Clear All** to reset all filters at once. Each filter resets the table to page 1 automatically. > 📸 *\[Screenshot placeholder: Filter bar with four controls — a search box containing text, the Policy Type multi-select open showing checkbox options, Status and Platform selectors — and the Clear All button on the right]* *** ## Selecting Policies — Bulk Actions The table has a checkbox column on the left. Selecting one or more rows activates the **Bulk Actions bar**, which appears as a highlighted blue card above the table. The bar shows: * How many policies are currently selected (e.g., `3 policies selected`) * A **Clear Selection** link to deselect all * Two action buttons: ### Export Selected Downloads only the selected policies as a report file. You can choose CSV, PDF, or HTML format. The export content is identical to the standard export (see below) but scoped to only the selected rows. *** ## Exporting the Full List After policies are loaded, an **Export** button appears in the top-right area. Clicking it opens an export options menu. **Available formats:** CSV, PDF, HTML **Filename:** `configuration-policies` (with the appropriate extension) The export includes one row per policy with these columns: | Export Column | Content | | ----------------- | ---------------------------------------- | | Policy Name | The policy's display name | | Type | Policy type string | | Platform | Platform string | | Assignment Status | `Assigned` or `Not Assigned` | | Assignment Count | Number of assignment targets | | Settings Count | Number of settings in the policy | | Scope Tags | Scope tag display names, comma-separated | | Created | Creation date | | Last Modified | Last modified date | The export document also includes a stats summary block: * **Total Policies** — total count in the exported set * **Assigned** — number of assigned policies * **Not Assigned** — number of unassigned policies *** ## Common Use Cases **Find all policies that are not assigned to anyone**\ Set the **Status** filter to `Not Assigned`. These policies consume space in your tenant but do nothing. Review them and use **Delete Selected** to clean them up after confirming they are genuinely unused. **Which policies target Windows devices?**\ Set **Platform** to `Windows10` (or the Windows value used in your tenant). Combine with **Policy Type** to further narrow to, for example, only Compliance policies. **When was this policy last changed and by whom?**\ Click the policy row to open Policy Details. The full last-modified timestamp is in the Timestamps section. Note: Intune Assistant shows when the policy was last modified but not who modified it — for that, check the Intune Audit Log. **Clean up old Administrative Templates after migrating to Settings Catalog**\ Set **Policy Type** to `Administrative Template`, review the list, confirm they have been replaced, then select all and use **Delete Selected**. **Export a policy inventory for an audit**\ Apply any relevant filters (e.g., platform = Windows, type = Compliance Policy), then click **Export** and choose PDF or HTML for a formatted report with the stats summary included. **Verify a new policy is correctly assigned before rollout**\ Search for the policy name. In the **Assignments** column you can immediately see which groups are included and whether any are excluded — without opening the Intune portal. **Find all policies owned by a specific team or region**\ If your tenant uses scope tags to divide administration by team, region, or business unit, set the **Scope Tags** filter to that tag. Only policies carrying it are shown. *** ## Related Pages * [Policy Settings Overview](broken://pages/0ed429286ce78a1adc7a88f54ce45171c364d6de) — drill into the individual settings inside each policy * [Configuration Overview](broken://pages/512e33f954a2212348983ef8c4f37594c06dc942) — how the two configuration pages work together * [Group Assignments](broken://pages/2c08bd41b5789dc78c3411a2ca74de58cfeb2f83) — see all policies assigned to a specific group * [All Assignments](broken://pages/3a6b9c8e541a736156af2c5672901f2cc2889f85) — full assignment inventory across all resource types * [Filter Assignments](broken://pages/360c32429867e2e5b00ebb6c19104ece3413b7ba) — understand the assignment filters used on policies # Policy Settings Overview ## What Is This Page? The **Policy Settings Overview** page unpacks every configuration policy in your Intune tenant into its individual settings and shows them all in a single flat table. Where the [Policy Overview](/intune-assistant/policies/policy-overview) answers "which policies exist?", this page answers "what is each policy actually doing?" — right down to the setting name, the configured value, the source policy, the platform, and whether the policy is currently assigned. Compliance policies are included too — instead of their configuration rules, each row shows one of their **Actions for non-compliance** (mark non-compliant, grace period, message template, additional recipients), since that's the part of a compliance policy that's easy to lose track of across dozens of policies. The page also does something the Intune portal cannot do on its own: it automatically cross-references all settings across all policies and flags **duplicate settings** (the same setting configured to the same value in multiple policies targeting the same groups) and **conflicting settings** (the same setting configured to *different* values in policies that overlap in their assignment targets). This makes it the primary tool for configuration hygiene and security auditing. *** ## Why Would You Use This? * You want to understand your device configuration at the individual setting level, not just the policy level * You need to find settings that are configured in more than one place — common after tenant growth, migrations, or team changes over time * You need to detect and resolve **conflicting settings** before they cause unpredictable device behaviour * You are migrating from legacy Device Configuration profiles or ADMX Group Policy to the modern Settings Catalog and need to see exactly which settings are already covered * You need to audit the complete configuration state of a tenant for a security review, ISO 27001 assessment, or compliance framework * You want a structured export of all settings including values, sources, platforms, and conflict status *** ## How Data Is Loaded Clicking **Load Settings** fetches and analyzes everything in a single request: Settings Catalog, Device Configuration, Group Policy, and Compliance settings are combined and cross-referenced for duplicates and conflicts on the server before anything is sent back. A loading card is shown while this runs. > **Cancel:** A **Cancel** button appears during loading. Clicking it stops the request and shows a retry card. ### Categories to Check Above the **Load Settings** button, a row of checkboxes — **Settings Catalog**, **Device Config**, **Group Policy**, **Compliance** — lets you choose which categories to fetch. All four are selected by default. Unchecking a category skips it entirely on the server, so if you only care about, say, Settings Catalog, unchecking the others makes the load noticeably faster on large tenants. At least one category must stay checked — **Load Settings** is disabled otherwise. Changing the selection and clicking **Refresh** re-runs the load with the new selection. *** ## Understanding the Table Each row in the table is a single **setting** from a single policy. The columns are: | Column | What It Shows | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Policy Name** | The name of the policy this setting belongs to. Below the policy name, a coloured **source badge** shows the origin (see Source Badges below). If the setting has been flagged as a duplicate or conflict, an additional **clickable badge** appears here | | **Setting Name** | The display name of the setting. For Device Configuration OMA-URI custom settings, the OMA-URI path is shown in smaller muted text below the setting name. If the setting ID was used as the name (no display name resolved), the ID is shown. If the OMA-URI setting has a modern Settings Catalog equivalent, a blue **Migration Available** badge appears underneath — see [Settings Catalog Migration Suggestions](#settings-catalog-migration-suggestions) below. For **Compliance** rows, this shows `Non-compliance action: ` (e.g. `notification`, `block`, `retire`) instead of a configuration setting name | | **Setting Value** | The configured value for this setting, wrapping onto up to two lines — widen the column by dragging its border to see more, or hover for the full value. For settings flagged as **Conflict**, the value is highlighted in **red** to draw attention. For **Compliance** rows, this shows a compact list — Grace Period, Message Template, Additional Recipients — instead of one sentence, so it's readable at a glance; the same three items are also available under **Child Settings** in an expandable form | | **Platform** | The platform string of the parent policy (e.g., `windows10`, `iOS`, `Android`) | | **Assigned** | Whether the parent policy has at least one assignment. Shows a clickable green **Assigned** badge (opens the Assignments dialog) or a grey **Not Assigned** badge | | **Child Settings** | For Settings Catalog settings that have sub-options, shows a `N child settings` expandable link. This count includes settings nested at any depth (a sub-setting can itself have its own sub-settings, and so on). Click to expand the sub-settings inline — nested sub-settings are shown indented under their parent. Automatically expands the full path to any matching child, at any depth, and highlights the match in amber when a search term matches. **Compliance** rows use the same expandable breakdown to show Grace Period, Message Template, and Additional Recipients individually, instead of one dense line | *** ## Source Badges Every row has a source badge in the Policy Name cell indicating which Intune engine the setting came from: | Colour | Source | Description | | ------ | -------------------- | ---------------------------------------------------------------------------------- | | Blue | **Settings Catalog** | Modern policy settings — the recommended approach for new configurations | | Purple | **Device Config** | Legacy Device Configuration profiles — older approach, still widely used | | Green | **Group Policy** | ADMX-based Administrative Templates or Group Policy Analytics ingested into Intune | | Amber | **Compliance** | Actions for non-compliance from Compliance policies | *** ## Duplicate and Conflict Detection After all three sources are loaded, the page runs an automatic analysis across the full dataset. Every setting is checked against every other setting of the same name, looking for cases where: 1. The same setting appears in multiple policies 2. Those policies have **overlapping assignment targets** — meaning at least one group (or built-in target) is shared between them Only settings in policies that actually target the same devices or users are compared. A setting that appears in two policies assigned to completely different groups is **not** flagged. ### Duplicate (yellow badge) A **Duplicate** means the same setting is configured to the **same value** in two or more policies that overlap in their assignments. * This is not necessarily causing harm, but it is unnecessary and can create confusion * It commonly appears during migrations when a new Settings Catalog policy is created to replace an old Device Configuration profile but the old profile has not yet been removed * Click the yellow **Duplicate** badge to open the Duplicate Details dialog ### Conflict (red badge) A **Conflict** means the same setting is configured to **different values** in two or more policies that overlap in their assignments. * This means Intune is sending contradictory instructions to the same device * The device will apply one value or the other depending on policy conflict resolution precedence — which may not be the intended outcome * Conflicts should be investigated and resolved: either consolidate into one policy or ensure the conflicting policies target different groups * Click the red **Conflict** badge to open the Conflict Details dialog > ⚠️ **Conflicts represent a real configuration risk.** A device receiving conflicting settings may end up in an indeterminate state that does not match either policy's intent. Treat conflict badges as action items. **For Compliance rows**, duplicate/conflict detection works the same way but on non-compliance actions instead of configuration settings — for example, a **Conflict** on a `Non-compliance action: notification` row means two compliance policies with overlapping assignments handle non-compliance differently (different grace period, message template, or recipients). That's not a device-state risk like a Settings Catalog conflict, but it usually means non-compliant users get an inconsistent experience depending on which policy catches them first — worth reviewing. *** ## Settings Catalog Migration Suggestions Many legacy OMA-URI custom settings in Device Configuration profiles have a direct equivalent in the modern Settings Catalog. When that's the case, the row for that setting shows a blue **Migration Available** badge underneath the setting name. Click the badge to open the **Migration Suggestion** dialog, which shows: * The current OMA-URI setting name and path * The name of the equivalent Settings Catalog setting, with a **Copy name** button so you can search for it directly when creating a Configuration Policy in Intune * A description of what the Settings Catalog setting does * The full JSON for a ready-to-import Configuration Policy that reproduces the same configuration, with **Copy** and **Download** buttons — the downloaded file can be uploaded straight into Intune to create the migrated policy Migrating flagged settings to the Settings Catalog gets you improved reporting and Intune's built-in policy conflict detection, which OMA-URI custom settings do not support. The **N migrations available** badge in the [Clickable Stats Bar](#clickable-stats-bar) shows how many settings across the tenant have a migration suggestion, and the **Migration Available** status filter isolates just those rows. *** ## The Duplicate / Conflict Details Dialog Clicking a **Duplicate** or **Conflict** badge opens a detail dialog. The dialog is structured into two sections: ### This Policy Shows a highlighted card for the current row's policy with: * Policy name * Configured setting value The card is highlighted in **yellow** for duplicates and **red** for conflicts. ### Conflicting / Duplicate in N Other Policies Lists every other policy that has the same setting with overlapping assignments. Each entry shows: * Policy name * Source badge (Settings Catalog / Device Config / Group Policy / Compliance) * The setting value configured in that policy * A **red triangle icon** if the value differs from the current row's value * A short explanation of **why** the two policies were flagged together — the specific group, "All Devices", or "All Users" they both target (with the group's real display name, not just its ID). If assignment information could not be determined for one of the policies, this instead says the scope is unknown and the pair was flagged conservatively rather than silently hidden This gives you exactly what you need to decide which policy to keep and which to clean up or merge. *** ## The Assignments Dialog When a row shows a green **Assigned** badge in the Assigned column, clicking it opens the **Assignments dialog** for that policy. The dialog shows: * A section for **Group Assignments** — each assigned group is shown with its display name (fetched live), the GUID below it in small monospace text, and a **View Group** button * A section for **Other Assignments** — built-in targets (All Users, All Devices) shown as their raw odata type string * The total assignment count in the dialog header The display names of groups are loaded asynchronously while the dialog is open — a shimmer placeholder appears until the name resolves. Clicking **View Group** on any entry closes the Assignments dialog and opens the **Group Details dialog** for that group. *** ## Filters Panel The **Filters** header is a clickable toggle. Click it to expand or collapse the filter controls. When collapsed, any **active filters are shown as chips** in a summary row beneath the header — so you always know what is filtering the table even with the panel closed. The header also shows a badge like `2 active` when filters are set. | Filter | Options | What It Does | | -------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Source** | Settings Catalog, Device Config, Group Policy, Compliance | Show settings from one or more specific policy engines | | **Platform** | Values from your tenant | Limit to a specific device platform | | **Status** | OK, Duplicate, Conflict, Migration Available | Show only clean settings, only duplicates, only conflicts, only settings with a Settings Catalog migration available, or any combination | | **Assignment** | Assigned, Not Assigned | Show only settings from assigned policies, or only from unassigned ones | When filters are active, a count shows: `Showing X of Y settings`. Click **Clear All** to reset everything at once. *** ## Clickable Stats Bar Below the filters panel, a row of **clickable stat badges** is shown. Each badge both displays a count and acts as a shortcut to toggle a filter: | Badge | Click Action | | -------------------------- | ---------------------------------------------------------- | | **N total settings** | Clears all filters — shows the complete unfiltered dataset | | **N Settings Catalog** | Toggles the Settings Catalog source filter on/off | | **N Device Config** | Toggles the Device Config source filter on/off | | **N Group Policy** | Toggles the Group Policy source filter on/off | | **N Compliance** | Toggles the Compliance source filter on/off | | **N duplicates** | Toggles the Duplicate status filter on/off | | **N conflicts** | Toggles the Conflict status filter on/off | | **N migrations available** | Toggles the Migration Available status filter on/off | An active filter badge shows a **coloured ring** around it. Clicking again removes the filter. If both duplicates and conflicts are zero, those badges are not shown. When any filter is active, a text suffix shows: `— showing X of Y`. > 📸 *\[Screenshot placeholder: Stats bar showing six badges in a row: a dark total badge, blue Settings Catalog, purple Device Config, green Group Policy, yellow duplicates, and a red conflicts badge with a ring indicating it is currently active]* *** ## Search A search box is available at the top of the table. It searches simultaneously across: * Setting name * Policy name * Setting value Results update live as you type. You can exclude results by prefixing a word with `!` — for example `windows !conflict` shows Windows settings that are not flagged as conflicts. This works together with child-setting search below. **Child settings aware, at any depth:** Search also looks inside child sub-settings — and their own child settings, no matter how deeply nested (for example, a "OneDrive" setting group containing a "Tenant Restrictions" setting, which itself contains an "Allowed Tenant IDs" value). When a search term matches anywhere in that nested structure, the parent row is included in the results, the child settings panel automatically expands down to the matching entry, and the match is highlighted in **amber**. The match count next to the expand link reflects matches at every level: `4 child settings (1 match)`. *** ## Exporting the Data After data is loaded, an **Export** button appears in the top-right area. **Available formats:** CSV, PDF, HTML **Filename:** `policy-settings` (with the appropriate extension) The export respects all active filters — only the rows currently visible in the table are included. The export includes one row per setting with these columns: | Export Column | Content | | ------------- | ---------------------------------------------------------------------- | | Policy Name | Name of the parent policy | | Setting Name | Display name of the setting | | Setting Value | Configured value | | OMA-URI | The OMA-URI path (Device Config custom settings only, blank otherwise) | | Source | `catalog`, `deviceconfig`, `grouppolicy`, or `compliance` | | Platform | Platform string | | Assigned | `true` or `false` | | Status | `ok`, `duplicate`, or `conflict` | The export stats summary includes: * Total setting count * Settings Catalog count * Device Config count * Group Policy count * Compliance count * Duplicate count * Conflict count *** ## Common Use Cases **Are there any conflicting settings in my tenant?**\ Check the stats bar immediately after loading. If the red **Conflicts** badge shows any number greater than zero, click it to jump straight to a filtered view showing only conflicting rows. Click each Conflict badge to understand which policies are involved and what values they are each setting. **I am migrating from Device Configuration to Settings Catalog — what is already covered?**\ Enable both **Settings Catalog** and **Device Config** source filters, then set **Status** to `Duplicate`. Every row that appears is a setting that exists in both systems with the same value — those Device Config settings are safe to remove once you have confirmed the Settings Catalog policy is assigned correctly. **Full audit of all device configuration settings**\ Load the page with no filters active and click **Export → CSV**. This produces a complete, line-by-line manifest of every setting configured across your entire tenant. **A device has a setting applied that I cannot explain**\ Search for the setting name in the search box. All policies that configure that setting will appear. Check the source and the Assigned badge to understand which one is reaching the device. **Which ADMX / Group Policy settings have been imported into Intune?**\ Set the **Source** filter to `Group Policy`. **Which OMA-URI settings can be migrated to the Settings Catalog?**\ Set the **Status** filter to `Migration Available`, or click the **N migrations available** stat badge. Click each **Migration Available** badge to see the equivalent Settings Catalog setting and download a ready-to-import Configuration Policy JSON. **Check whether an unassigned policy contains any settings worth keeping**\ Set the **Assignment** filter to `Not Assigned`. Review the settings list — if the policy contains valuable settings, assign it or merge them into an existing active policy before deleting it. **Compare Windows and iOS configuration**\ Set **Platform** to `Windows10` first, export the result. Then reset and set **Platform** to `iOS`, export again. You now have a per-platform configuration manifest. **What does each compliance policy actually do when a device is non-compliant, without opening every policy?**\ Set the **Source** filter to `Compliance`. Each row shows the grace period, message template, and additional recipients for one non-compliance action — no more opening each compliance policy individually in the Intune portal to check. **I only care about Compliance actions right now — can I skip the rest to load faster?**\ Yes — before clicking **Load Settings**, uncheck the categories you don't need in the **Categories to check** row. Only the checked categories are fetched from Intune. *** ## Related Pages * [Intune Policy Overview](/intune-assistant/policies/policy-overview) — see the policies these settings belong to, and manage them in bulk * [All Assignments](/intune-assistant/assignments/all-assignments) — see which groups each policy is assigned to * [Group Assignments](/intune-assistant/assignments/group-assignments) — see all configuration policies assigned to a specific group # Policy Comparison ## What Is This Page? The **Policy Comparison** page lets you pick two Intune configuration policies and compare them setting by setting. Every setting that exists in either policy is listed, and for each one you can see the exact value configured in the **Source** policy and the exact value configured in the **Target** policy — side by side, in a colour-coded layout that makes differences immediately obvious. The page tells you not just that two settings are different, but *what* the difference is, and in the case of complex settings with sub-options (child settings), it drills into every sub-option individually so nothing is hidden. *** ## Important — Which Policy Types Can Be Compared? {% hint style="warning" %} **Only Settings Catalog policies are available for comparison.** {% endhint %} The comparison engine works with the structured data model of the **Settings Catalog**. Device Configuration profiles and Administrative Templates use a different data format and are not included in the policy picker on this page. When you click **Load Policies**, only your `SettingsCatalog` type policies are fetched and shown in the dropdowns. *** ## Why Would You Use This? * You created a policy for a new deployment ring and want to verify it matches your reference policy before assigning it * Two teams manage separate policies for similar device types and you want to understand what is different between them * You are migrating settings from one policy to another and need a detailed diff to track what has been moved * You want to confirm that a cloned policy is truly identical to its original after modification * You are doing a compliance review across environments (e.g., Production vs. Acceptance) and need a structured report of what differs * You need to document what changed between a policy in its current state and a peer policy used as a baseline *** {% stepper %} {% step %} ### Load Policies 1. Navigate to **Compare → Policies** 2. Click **Load Policies** 3. Intune Assistant fetches all Settings Catalog policies from your tenant 4. The number of available policies is shown below the dropdowns: `Found N configuration policies` > 📸 *\[Screenshot placeholder: Welcome card with a large GitCompare icon, a description, and the Load Policies button centred below]* > {% endstep %} {% step %} ### Select the Source Policy The **Source Policy** is the reference — the policy you are comparing *from*. Think of it as the baseline. 1. Click the **Source Policy** dropdown 2. A searchable list opens showing all available Settings Catalog policies 3. Each entry in the list shows the **policy name** on one line and the **policy type and platform** on the line below 4. Type in the search box to filter by name or policy type 5. Click a policy to select it Once a source policy is selected, the target policy dropdown becomes active. > 📸 *\[Screenshot placeholder: Source Policy dropdown open, showing a search box at the top and a list of policy entries each with a name line and a type/platform sub-line below]* > {% endstep %} {% step %} ### Select the Target Policy The **Target Policy** is the policy you are comparing *against*. > **The target dropdown is automatically restricted to policies on the same platform as the source policy.** If your source policy targets Windows, only other Windows Settings Catalog policies appear in the target list. The source policy itself is also excluded from the target options. This ensures you are always comparing policies that are intended for the same device platform — a Windows policy compared to an iOS policy would produce meaningless results. 1. Click the **Target Policy** dropdown 2. Search and select the policy you want to compare to {% endstep %} {% step %} ### Run the Comparison Once both policies are selected, a **Compare Policies** button appears centred below the dropdowns. 1. Click **Compare Policies** 2. A spinner shows while the comparison runs 3. The comparison results appear below > 📸 *\[Screenshot placeholder: Policy selection card showing both dropdowns filled in with policy names, and the Compare Policies button centred below them with a GitCompare icon]* > {% endstep %} > {% endstepper %} *** ## Reading the Results ### The Policy Header Bar A sticky bar at the top of the results section shows the two policy names in colour-coded panels that persist as you scroll: * **Blue panel — Source Policy** — the policy you are comparing from * **Green panel — Target Policy** — the policy you are comparing against This stays visible at the top of the results as you scroll through a long list of settings. > 📸 *\[Screenshot placeholder: Sticky header bar showing a blue Source Policy panel on the left with the policy name, and a green Target Policy panel on the right with the target policy name]* *** ### The Stats Bar The results header shows four summary counts: | Badge | What It Counts | | --------------- | ---------------------------------------------------------------------- | | **Same** | Settings that exist in both policies and have identical values | | **Different** | Settings that exist in both policies but have different values | | **Source Only** | Settings that exist only in the source policy — absent from the target | | **Target Only** | Settings that exist only in the target policy — absent from the source | The total count is shown in the card header: `Comparison Results (N settings)`. > 📸 *\[Screenshot placeholder: Results card header showing four coloured stat badges — green Same, red Different, blue Source Only, yellow Target Only — each with a count number]* *** ### Setting States — The Four Badges Every setting in the results list has a badge on the right side of its row: | Badge | Meaning | | --------------- | ----------------------------------------------------------------------------------- | | **Same** | The setting is configured in both policies with the same value | | **Different** | The setting is configured in both policies but the values do not match | | **Source Only** | The setting is present in the source policy but does not exist in the target policy | | **Target Only** | The setting is present in the target policy but does not exist in the source policy | *** ### What Each Setting Row Shows Each setting in the results list displays: **Setting name and status badge**\ The display name of the setting and its comparison badge, shown together at the top of the row. **Description**\ A plain-text explanation of what this setting controls, pulled from the Settings Catalog definition. **Keywords**\ One or more category tags associated with the setting (e.g., `Security`, `BitLocker`, `Firewall`, `Windows Update`). These are shown as small neutral badges and can be used to filter the results. **Source Value (blue) and Target Value (green)**\ A two-column layout showing the configured value in each policy. Values are shown as text. If a setting does not exist in one of the policies, `[Not Set]` is shown in that column. **Differences Summary (yellow, only for Different settings)**\ When a setting is marked **Different** and the API returns a structured description of the change, a yellow panel appears below the values. It contains a human-readable summary of exactly what changed — for example, `Value changed from 'Disabled' to 'Enabled'`. > 📸 *\[Screenshot placeholder: A single setting row showing a red Different badge, a description paragraph, keyword badges, a blue SOURCE VALUE panel and a green TARGET VALUE panel with different text in each, and a yellow DIFFERENCES SUMMARY panel below]* *** ### Child Settings Some Settings Catalog settings contain **sub-options** — for example, a Firewall setting may have child settings for inbound rules, outbound rules, notification behaviour, and so on. When a setting has child settings, they are displayed in a collapsible section below the main setting values. Each child setting shows: * The child setting name * A **SOURCE** value (blue) and a **TARGET** value (green) side by side * A red **Different** badge and red background highlight on any child where the two values do not match Child settings with identical values in both policies are shown with a neutral grey background. > 📸 *\[Screenshot placeholder: Child Settings section expanded showing three child settings — two with matching values on grey backgrounds, one with different values on a red background and a red Different badge]* *** ## Filtering the Results Three filter controls are available above the results list. All three combine — a setting must match all active filters to appear. ### Search A text input that filters results by **setting name** in real time. Type any part of a setting name to narrow the list. An × button appears to clear the search term. ### Comparison Status A dropdown with five options: | Option | What It Shows | | -------------------- | ----------------------------------------------------------------------------------- | | **All Settings** | No filter — show all comparison results | | **Different Values** | Show only settings with different values (`InBothDifferent`) | | **Same Values** | Show only settings that are identical in both policies (`InBothTheSame`) | | **Source Only** | Show only settings that exist in the source policy but not the target (`InSource`) | | **Target Only** | Show only settings that exist in the target policy but not the source (`InChecked`) | ### Filter by Keywords A multi-select dropdown populated from the keywords attached to the settings in the comparison results. The available keywords vary by policy content — you might see tags like `Security`, `BitLocker`, `Defender`, `Firewall`, `Update`, and so on. * Search within the keyword list by typing in the embedded search box * Select multiple keywords — the results show settings that match **any** of the selected keywords * Up to 2 selected keywords are shown as badges in the closed dropdown; additional ones show as `+N more` * Click × on any keyword chip to remove it individually ### Active Filter Chips When any combination of search, status, or keyword filters is active, an **Active Filters** section appears below the filter controls, showing each active filter as a removable chip. Click the × on any chip to clear that specific filter without affecting the others. A **Clear** button in the filter card header resets all three filters at once. > 📸 *\[Screenshot placeholder: Filters card showing a search box with text, the Status dropdown set to "Different Values", the Keywords dropdown showing two selected keywords as badges, and an Active Filters row below with three removable chips and a Clear button]* *** ## Stats Update With Filters The four summary badges in the results header (**Same**, **Different**, **Source Only**, **Target Only**) always reflect the **currently filtered** result set, not the full unfiltered comparison. When you apply filters, the counts update immediately to show how many settings of each type match your current criteria. *** ## Exporting the Comparison Once comparison results are loaded, an **Export HTML** button appears in the results card header. Clicking it downloads a **self-contained HTML file** — a fully formatted, interactive report that can be opened in any browser without needing an internet connection or an Intune Assistant account. **Filename format:**\ `policy-comparison-{source-name}-vs-{target-name}-{date}.html` For example: `policy-comparison-windows_security_baseline-vs-legacy_device_config-2026-04-27.html` ### What the HTML Report Contains * A formatted header with the report title and generation timestamp * A **stats summary** section with Same / Different / Source Only / Target Only counts * The full **Source Policy** and **Target Policy** names in colour-coded panels * Every setting as a card, with description, keywords, source value, target value, differences summary, and child settings * A built-in **interactive filter bar** with search, status dropdown, and keyword filter — so the recipient of the report can filter the results in their browser without needing access to Intune Assistant * A **no results** message when filters produce an empty list > 💡 **The HTML export is designed to be shared.** Send it to a colleague, a manager, or an auditor and they can explore the full comparison in their browser — no login, no dependencies, no special software. *** ## Common Use Cases **Verify a cloned policy before assigning it**\ Select the original as Source and the clone as Target. Filter Status to `Different Values` — if anything shows up, something changed during the clone or was edited afterwards. **Compare production and test environment policies**\ Select the production policy as Source and the test policy as Target. Export to HTML and share with the team doing the test environment review. **Find settings that are in one policy but missing from another**\ Filter Status to `Source Only` to see everything the target policy is missing. Filter to `Target Only` to see everything the source policy is missing. **Audit a specific security area across two policies**\ Use the Keywords filter to narrow to a category like `BitLocker` or `Firewall`. Then filter Status to `Different Values` to see only the security-relevant settings that differ. **Document what changed between a baseline and a current policy**\ Select the baseline as Source and the current policy as Target. Export to HTML and archive the report as evidence of drift or intentional change. *** ## Related Pages * [Policy Overview](broken://pages/3ee2eb86891b092cffa67be314cc52799176a9b5) — see all policies and their assignment status * [Policy Settings Overview](broken://pages/b6f1a8cef2b4ce280ce6387b84ee1d23629897f1) — find duplicate and conflicting settings across all policies * [Configuration Overview](broken://pages/4b3e4961766af1b0f38614670054976e1b1257f7) — the full configuration management section # Bulk Edit Policies Managing a large Microsoft Intune environment often means policies accumulate names that no longer match your current standards — after a baseline update, a tenant migration, or just over time. Renaming them one by one is slow and error-prone. Bulk Edit lets you apply naming changes and scope tag updates across many policies at once, safely. ## What you can do * **Add a prefix** — e.g. turn `Windows - BitLocker` into `LEGACY - Windows - BitLocker` * **Add a suffix** — e.g. turn `Windows - BitLocker` into `Windows - BitLocker - v1` * **Replace text** — e.g. change `DEV` to `PROD` across all selected policies * **Add scope tags in bulk** — assign one or more scope tags to a group of policies at once ## How to use it 1. Go to **Policies** and filter or search to find the policies you want to edit. 2. Select the checkboxes next to the policies you want to change. 3. Click **Bulk Edit** in the toolbar. 4. Choose your action: * For renaming: select **Add prefix**, **Add suffix**, or **Replace text**, then fill in the value. * For scope tags: select **Add scope tags** and pick from the available tags. If the tag you need does not exist yet, type its name in the **Create new scope tag** field and click **Create** — the tag is created in Intune immediately and selected automatically. If a tag with that name already exists, it is selected for you instead of creating a duplicate. 5. Click **Preview** to see exactly what will change before anything is saved. 6. Review the preview table — each row shows the current name and the proposed new name (or which scope tags will be added). 7. If everything looks right, click **Apply** to execute the changes. ## What you'll see in the preview The preview shows a table with one row per selected policy: | Policy | Current name | New name | Scope tags to add | Status | | ---------------- | ---------------------- | ------------------------------- | ----------------- | ---------------------- | | Settings Catalog | `WIN - Firewall - v1` | `LEGACY - WIN - Firewall - v1` | — | Ready | | Settings Catalog | `WIN - BitLocker - v2` | `LEGACY - WIN - BitLocker - v2` | — | ⚠️ Name already exists | Rows marked with a warning will be **skipped** during execution — the rest will proceed. You'll see a final result table after applying. ## Requirements * Available to all non-free customers (Standard with paid modules, Enterprise, MVP, NFR, MSP). * MSP admins can run bulk edits on their managed customer tenants by selecting the correct tenant from the tenant switcher. * You need the **DeviceManagementConfiguration.ReadWrite.All** Graph permission to rename policies and add scope tags. If IntuneAssistant hasn't been consented for this scope yet, you'll be prompted to consent first. * Creating a new scope tag requires the additional **DeviceManagementRBAC.ReadWrite.All** permission. If you do not have this permission, the Create button will return an error. ## Safety rules * You can only add a prefix, add a suffix, or replace specific text — you cannot overwrite the entire name to a fixed value (to prevent accidental mass-renaming to the same name). * If the proposed new name already exists in the tenant, that policy is automatically skipped. * Scope tags that are already present on a policy are not added twice. * All changes are recorded in the **Audit Log** so you can always see what was changed, when, and by whom. ## Tips * Use **Replace** to fix a typo or update a version number across all matching policies at once. * Run a preview first on a small selection to verify your pattern before applying to hundreds of policies. * If you need to undo a rename, just run Bulk Edit again with the reverse operation. # Settings Library The Settings Library is a searchable, versioned reference of every setting Microsoft Intune can configure — the full Settings Catalog, with its history, dependencies, and Microsoft's security baseline templates — combined with a view of how *your* tenant uses those settings. * [Explore by task](/intune-assistant/settings-library/explore) — Say what you want to do and see the settings involved, what they need first, what they unlock, and the Microsoft templates that already bundle them. * [Dependencies of a setting](/intune-assistant/settings-library/dependency-map) — Every setting as a map: what it needs first on the left, what it unlocks on the right, and a click to walk there. * [Tenant usage](/intune-assistant/settings-library/tenant-usage) — See which of your policies configure a setting, with the configured value and who it is assigned to, and filter the whole library down to the settings your tenant actually uses. * [Tenant impact](/intune-assistant/settings-library/tenant-impact) — Deprecated, removed, changed, unassigned and unsupported settings in your own policies, with replacements and optional email alerts. * [Baseline coverage](/intune-assistant/settings-library/baseline-coverage) — Your configuration laid over Microsoft's security baselines: matching, different, missing — setting by setting. # Explore by task ## What it does Explore by task is the front door of the Settings Library. Instead of scrolling a catalog of thousands of settings, you say what you want to do — *Edge favorites*, *BitLocker*, *certificates on iOS*, *hardened UNC paths* — and the page shows the settings involved, grouped by the area they live in, with what each one needs first, what it unlocks, and which of Microsoft's own templates already bundle it. ## How to use it 1. Open **Settings Library → Explore by Task**, or pick one of the example tasks. 2. Type the task in your own words and press **Explore**. Narrow to a platform with the chips next to the box. 3. The left column lists the **areas** the matches fall into (for example *Microsoft Edge › Favorites*). Click an area to focus on it; click **All areas** to see everything again. 4. Click a setting to open its **map**: what to configure first on the left, what it unlocks on the right, the templates that ship it above and its neighbours below (see [Dependencies of a setting](/intune-assistant/settings-library/dependency-map)). Click anything around it to walk there; **Back to results** returns to your search. 5. **Microsoft already bundles this** shows the security baselines and endpoint-security templates (Antivirus, Firewall, Attack surface reduction, …) that group the matching settings. Click one to see every setting it ships, grouped by area. ## What you'll see * **Needs first / unlocks** — counts on each setting, read from Microsoft's own dependency metadata. A setting that unlocks others lists first: configure it before the settings it gates. * **Template badges** — the baseline or endpoint-security template that ships the setting, with the value the baseline recommends. * **In your tenant** — after a [tenant usage](/intune-assistant/settings-library/tenant-usage) harvest, a green count on each setting says in how many of your policies it already sits, and each area counts how many of its matches you use. * **Watch out** — deprecated settings and their replacement, the minimum Windows build, user-scoped settings, Microsoft Entra join requirements, edition limits and Microsoft's risk level. * **Pointers outside the catalog** — some tasks are not settings at all. Ask for certificates and the page tells you they are certificate profiles (SCEP, PKCS, trusted root) with a link to Microsoft Learn, next to the trust-store settings the catalog does have. The same for Wi-Fi, VPN, email, drive mapping, app deployment, app protection, compliance, update rings and enrollment. ## Tips * Short words are matched whole: *unc* finds Hardened UNC Paths, not every setting that mentions "unchecked". Longer words match at the start of a word, so *favorite* finds *favorites* too. * Deprecated settings still appear, ranked below their live alternatives, so you can see what you would be replacing. * Dependencies never leave their own area in Microsoft's metadata, so the **Nearby** row on a setting's map is where related settings show up. # Dependencies of a setting ## What it does Every setting with dependencies is shown as a small map: the setting in the centre, what it **needs first** on the left, what it **unlocks** on the right. You see at a glance what to configure before it, what becomes available after it, and you can walk from setting to setting by clicking. ## Where you find it * In **Settings Library → Explore by Task**: click any setting in the results and the results make way for its map. **Back to results** returns you to your search. * On a **setting's own page**, in the *How this fits* card, whenever the setting has dependencies. ## What you'll see * **Needs first** (left) — settings that must be configured before this one has any effect. A thicker line means Microsoft marks it as required. * **Unlocks** (right) — settings that only apply once this one is set, and the members of a group setting. * **Stronger together** (above) — the Microsoft security baselines and endpoint-security templates that ship this setting, with the value a baseline recommends. Click one to see everything in that template. * **Nearby** (below) — settings in the same area and settings the library links to this one. * **On the card** — how many of your policies configure it (after a [tenant usage](/intune-assistant/settings-library/tenant-usage) harvest), and warnings: deprecated with a *Use instead* button, minimum Windows build, user scope, Entra join, edition limits. * **Legend** (under the map) — the line colour is the kind of dependency: *depends on*, *one option depends on*, *group member*, *lives inside* or *reusable setting*. Only the kinds on screen are listed. A thicker line is a required prerequisite, and ✓ *n* means the setting is in *n* of your policies. Hover a card for the exact reason. ## Tips * Click anything around the setting to walk there. In the explorer the **walked** trail keeps your last steps. * A side with more than seven settings scrolls inside its own column. The lines follow the settings you can see, and a small note says how many are above and below. * Every map has its own link, so you can share exactly what you are looking at. # Tenant usage ## What it does The Settings Library describes every setting Intune offers. Tenant usage adds the answer to the question that follows almost immediately: *do I use this, where, and who gets it?* After a harvest, every setting in the library shows whether one of your Settings Catalog policies configures it, and the setting's detail page lists those policies with the value each one sets and the assignments each one has — All devices, All users, group names, exclusions and filters. Combined with the library's other views this gives you things Intune itself cannot show: every deprecated setting you still have in a policy, or a setting that is configured in a policy that is not assigned to anything. ## How to use it 1. Open **Settings Library → Browse Catalog**. 2. Click **Harvest tenant usage** in the top-right corner. A progress bar shows the policies being read; a typical tenant takes well under a minute. 3. When it finishes, the header shows *Your tenant: N settings in use across M policies*, rows that your policies configure get an **In use** badge with the number of policies, and the **Only settings my tenant uses** filter becomes available. 4. Open any setting. The **Used in your tenant** card lists each policy that configures it — click the policy name to open it in the Intune admin center. Run the harvest again whenever you want the picture refreshed; the header and every card show when it was last taken. Harvesting reads your tenant, it never changes anything in it. ## What you'll see * **In use · 3 policies** on a row — three of your policies configure this setting. * **Configured: Block** — the value the policy sets. A setting that appears several times in one policy (for example one rule per row in a list) shows each value. * Assignment pills — **All devices**, **All users**, a group name, **Excluded: group** for exclusion groups, and the assignment filter with *include* or *exclude* where one is used. * **Not assigned — this policy has no effect** — the policy contains the setting but is not assigned to any device or user. * *Tenant usage not harvested yet* — nobody has run a harvest for this tenant; the filter and badges appear after the first one. ## Export — the settings bill of materials With Configuration Management, **Export CSV** / **Markdown** on the browse page downloads every configured setting in your tenant with its value, the policy and its assignments, the setting's lifecycle status, a known replacement if Microsoft names one, and — where a security baseline covers the setting — the recommended value and whether you match it. It is built from your last harvest and is the file auditors ask for. ## Requirements * Any active Intune Assistant customer can harvest and see the current state. With the **Configuration Management** module the harvest is also kept: badges and the impact report stay available without harvesting again, and email alerts become possible. Without it, what you see lasts for your browser session — harvest again next time. * The account running the harvest needs read access to Intune configuration and to groups — the same permissions the Tenant Overview uses, so no additional consent is normally needed. ## Common questions **Which policies are included?** Everything built on the Settings Catalog: Settings Catalog profiles, Endpoint security policies and catalog-based compliance policies. Classic device configuration profiles and Administrative Templates do not carry catalog setting ids and are not included yet. **Is the harvest live?** No — it is a snapshot from the moment you ran it, so the pages stay instant. Run it again after you change policies. **Can two people harvest at once?** Only one harvest runs per tenant at a time; a second attempt tells you one is already running. **Are secret values shown?** No. Settings that hold secrets show *(secret)* instead of the value. # Tenant impact ## What it does Tenant impact turns the Settings Library into an early-warning system for your own configuration. It answers: *which settings in my policies are deprecated or removed, what does that mean, is there a replacement, what changed since I last looked, which policies do nothing, and which settings can't apply to my devices?* — and it can email you when Microsoft's nightly catalog update changes the answer. Intune itself tells you none of this until something breaks on a device. ## How to use it 1. Open **Settings Library → Tenant Impact**. The box at the top right shows when your tenant was last harvested and how many devices it covers. **Harvest again** starts a new harvest and brings you back here when it is done. The first time, the same button harvests your tenant (see [Tenant usage](/intune-assistant/settings-library/tenant-usage)). 2. Start with **severity**. Click **High**, **Medium** or **Low** to keep only those findings. High means something is already gone or broken, Medium means it will break or deviates, Low is worth a look. 3. Click a **rule tile** to focus on one kind of finding. The numbers on the tiles follow your other filters, so you always see what is left. 4. Narrow down with the toolbar: search by setting or policy name, pick a platform or a single policy, and switch on **Assigned only** (skip policies that reach nobody), **Replacement known** (what you can fix today) or **New since harvest**. 5. Change the angle with **Group by**: * **Rule** — what kind of problem it is. * **Policy** — which policy needs work, worst first. This is the view to plan your changes from. * **Severity** — what to do first. 6. Click a group to open it and a finding to see the detail: Microsoft's own explanation, the replacement, the affected policies with their assignments, and a link to the setting. 7. **Export these** downloads exactly what you filtered as a CSV file, for a change ticket or a colleague. 8. To be notified, open your account page and switch on **Settings impact alerts** under Email notifications (see [Email notifications](/getting-started/email-notifications)). After each nightly catalog update you receive only what is new since the previous mail. ## What you'll see * **Deprecated settings in use** — with Microsoft's own sentence about what happens ("will be removed in a future release", "doesn't work after Edge 109") and, where Microsoft names one, a green **Use instead** box linking to the replacement setting. The same box appears on the deprecated setting's own page. * **Removed / missing settings in use** — settings that are gone from the catalog but still sit in your policies. * **Changed since your harvest** — a setting you use that Microsoft changed after you last harvested, with the changed properties. * **Baseline gap** — settings a Microsoft baseline recommends that you set differently or in no policy at all. Only for baselines you follow (see [Baseline coverage](/intune-assistant/settings-library/baseline-coverage)) and only for platforms you have devices on. Following a baseline with your own Settings Catalog policies is fine and never rates above Low; a deviation inside a baseline you adopted rates Medium. * **Unassigned policies** — policies whose settings reach no device or user. * **Devices below the minimum build / above the maximum build** — a setting that needs a newer (or older) Windows build than some of your devices run, with the count and the offending versions. Those devices silently ignore the setting while the policy reports success. * **Baselines not fully applied** — for each Microsoft security baseline: how many of its settings you don't configure and how many you set differently from the recommendation, with a link to the setting-by-setting view on the baseline's page. When Microsoft publishes a new baseline version, this is the gap against *your* configuration, not against the previous version. Each finding lists the policies involved with their assignments and links to the policy in the Intune admin center. ## Requirements * Any active Intune Assistant customer; no extra licence. * The harvest additionally reads your managed devices' OS versions (device names and identities are not stored — only how many devices run each version). If that read is not permitted, the build-version rules are skipped and the page says so. ## Common questions **Why does a finding say "since your harvest"?** Microsoft deprecated or changed the setting after you last harvested. Harvest again to refresh the rest of the picture. **Where does the replacement come from?** From Microsoft's own description of the deprecated setting. It is shown with *High* confidence because the sentence is Microsoft's while the match to a catalog setting is automatic — check it before you migrate. **Will I get an email every night?** Only when something new affects a setting you use — and only if you subscribed on your account page. Nothing new, no mail. **Why is a baseline I never rolled out not in the list?** Baseline gaps are only reported for baselines you follow, with a baseline policy or with your own Settings Catalog policies, and for platforms you have devices on. See [Baseline coverage](/intune-assistant/settings-library/baseline-coverage) for how that is decided and what it cannot see yet. # Baseline coverage ## What it does Microsoft publishes security baselines with a recommended value for each setting. Baseline coverage lays your tenant's configuration over the current version of every baseline and tells you, setting by setting, whether you configure it with the recommended value, with a different value, or not at all. ## How to use it 1. Harvest your tenant usage on **Settings Library → Browse Catalog** (requires Configuration Management, so the harvest is stored). 2. Open **Settings Library → Baseline Templates**. Each baseline shows a coverage bar: green matches, amber differs, and the missing count. 3. Open a baseline. **Your tenant against this baseline** lists every setting with what Microsoft recommends and what you configure (per policy), with filters for *Differs*, *Not configured*, *Matches*. Expand a setting to see its nested settings and every policy that sets it. ## Which baselines count Not every Microsoft baseline is meant for you, and you do not need a baseline policy to follow one. Each baseline therefore gets a label: * **Adopted** — a policy in your tenant is built from this baseline. * **Via own policies** — you have no baseline policy, but your own Settings Catalog policies configure a meaningful share of it with Microsoft's values. That is a deliberate and common way of working, and those settings count as configured. * **Not followed** — nothing is built from it and hardly anything matches. Baselines share settings, so a HoloLens baseline can show overlap just because you follow the Windows baseline. A baseline you do not follow raises no findings. Coverage always looks at every harvested Settings Catalog policy, not only baseline policies. *Not configured* means the setting is in none of them. Harvest again after this update so your baseline policies are recognised as **Adopted**. ## What you'll see * **Matches** — at least one policy sets the recommended value. * **Differs** — configured, but with another value (or a nested setting differs or is missing). * **Not configured** — no policy sets it. * **Configured** — configured, but the baseline has no comparable recommendation for it (some collections). Values are shown as you read them in the portal, with the raw id underneath so a difference can always be verified. ## Common questions **A new baseline version came out — what changed for me?** The impact report's *Baselines not fully applied* finding is recomputed against the new version, and if you subscribed to settings impact alerts you get an email with the gap against your configuration. **Why "Differs" when my value looks the same?** The comparison uses the stored value (for example the option id), not the label. Expand the row: the raw values are shown under the labels. **I configured this setting, why does it say "not configured"?** Coverage reads policies built on the Settings Catalog: Settings Catalog profiles, Endpoint security policies and catalog-based compliance policies. A setting you only configured in an older *Device configuration* template or an *Administrative templates (ADMX)* profile is not seen, so it shows as not configured here even though it reaches your devices. **When does "Via own policies" apply?** When you have no policy built from the baseline, but at least one in ten of its settings is configured with Microsoft's recommended value somewhere in your own policies. Below that the baseline is treated as **Not followed**. If a baseline you do follow lands on the wrong side of that line, let us know; the line is a starting point, not a rule from Microsoft. **I have no HoloLens or Cloud PC devices, why is that baseline still listed?** Every Microsoft baseline is listed, with its label. Findings are limited to baselines you follow and to platforms you have devices on, but the check is per platform (Windows, macOS, iOS), not per device type. A Windows-based baseline for a device type you do not own therefore drops out because you do not follow it, not because the device is missing. **My baseline policy is not recognised as Adopted.** Harvest your tenant usage again. Harvests from before this label existed did not record which baseline a policy was built from. # Conditional Access This section covers features for viewing and managing your Entra ID Conditional Access policies in IntuneAssistant. # Bulk Rename Conditional Access Policies When your Conditional Access policies accumulate names that no longer match your standards — after a baseline update, a tenant migration, or simply over time — renaming them one by one is slow. Bulk Rename lets you apply naming changes across many policies at once, with a preview before anything is saved. ## What you can do * **Add a prefix** — e.g. turn `MFA - All users` into `LEGACY - MFA - All users` * **Add a suffix** — e.g. turn `MFA - All users` into `MFA - All users - v1` * **Replace text** — e.g. change `DEV` to `PROD` across all selected policies ## How to use it 1. Go to **Conditional Access** and load your policies. 2. Select the checkboxes next to the policies you want to rename. 3. Click **Bulk Edit** in the selection toolbar that appears. 4. Choose your rename operation: **Add prefix**, **Add suffix**, or **Replace text**, then fill in the value. 5. Click **Preview Changes** to see exactly what will change before anything is saved. 6. Review the preview table — each row shows the current name and the proposed new name. 7. If everything looks right, click **Apply** to execute the changes. 8. After the changes are applied, you are automatically returned to the policy list after a few seconds. ## What you will see in the preview The preview shows a table with one row per selected policy: | Current name | New name | Status | | --------------------- | ------------------------------ | -------- | | `MFA - All users` | `LEGACY - MFA - All users` | Ready | | `Block - Legacy auth` | `LEGACY - Block - Legacy auth` | Conflict | Rows marked as a conflict will be skipped during execution — the rest will proceed. A final result table is shown after applying. ## Requirements * Available to all non-free customers (Standard with paid modules, Enterprise, MVP, NFR, MSP). * MSP admins can run bulk renames on their managed customer tenants by selecting the correct tenant from the tenant switcher. * You need the **Policy.ReadWrite.ConditionalAccess** Graph permission to rename policies. If IntuneAssistant has not been consented for this scope yet, you will be prompted to consent first. ## Safety rules * You can only add a prefix, add a suffix, or replace specific text — you cannot overwrite the entire name to a fixed value. * If the proposed new name already exists in the tenant, that policy is automatically skipped. * All changes are recorded in the **Audit Log** so you can always see what was changed, when, and by whom. ## Tips * Use **Replace** to fix a typo or update a version number across all matching policies at once. * Run a preview first on a small selection to verify your pattern before applying to all matching policies. * If you need to undo a rename, run Bulk Edit again with the reverse operation. # Backup & Restore Export your entire Intune configuration as a portable ZIP archive, or import configurations from a previous backup. # Backup & Restore ## What it does The Backup & Restore page has two independent tabs: **Backup** and **Restore**. The Backup tab exports all supported Intune and Azure AD configuration types to a ZIP archive you download in your browser. Each resource type gets its own folder inside the ZIP, and each item inside is a separate JSON file named after its display name. The format is compatible with the IntuneManagement open-source tool, so backups created in IntuneAssistant can be imported by either tool. The Restore tab lets you upload a backup ZIP and selectively re-import configurations into a tenant. You choose which resource types and individual items to restore, control whether assignments are applied, and whether Conditional Access policies are created in report-only mode first. The restore uses a guided three-step flow so nothing is imported by accident. *** ## Backup ### How to use it 1. Navigate to **Configuration > Backup & Restore** in the sidebar. The table already shows, per resource type, how many items exist and how many are ready locally (the **Ready** column) - Intune Assistant collects this in the background from the moment you sign in. 2. On the **Backup** tab, select the resource types you want to export using the checkboxes in the table header or per row, and optionally narrow by platform or scope tag. 3. Click **Download backup**. The text next to the button tells you whether everything is ready (the ZIP is built locally, instantly) or how many items still have to be fetched first. If anything is fetched, the table updates in real time and the ZIP is saved automatically when it is done. 4. Use **Save ZIP again** if you want the same archive a second time, or after retrying failed items. ### What you will see The status table has one row per resource type. Each row shows the resource type name, the **Ready** count (items available locally versus items that exist; "listed on download" for the few types the overview does not collect), the current status (Not started, Running, Done, or Error), and the item count once the export completes. If a type returns an error (for example because a Graph permission was not consented), the row shows the error and the remaining types continue. The downloaded file is named `IntuneBackup-YYYY-MM-DD.zip`. Inside, each resource type has its own folder containing one `.json` file per configuration item. ### Where the data comes from The Backup page works together with the tenant overview that Intune Assistant collects when you sign in: * **What exists** (the list of items per resource type) comes from that overview, so a backup starts immediately instead of asking Microsoft Graph for each type first. The note above the filters tells you when the overview was collected and offers a refresh. * **Item content** is fetched live the first time, and kept locally afterwards. A later backup reuses the content of items that have not been modified since, and only fetches what is new or changed. The row shows how many items came from that local copy (for example "312 / 320 · 300 cached"). * **Keep backup content ready** is on by default: the content is collected in the background as soon as the overview has loaded, so pressing **Start Backup** produces the ZIP without waiting for Microsoft Graph. It costs one Graph read per configuration item after every overview refresh; on a very large tenant, or if you rarely back up, switch it off and content is fetched only when you start a backup. The choice is remembered in your browser. **Clear content cache** throws the local copies away; **Reset cache** on the Tenant Overview page does the same as part of a full reset. The locally kept content lives in your own browser, per signed-in account and per tenant, and is removed when you sign out. *** ## Restore The Restore feature requires the Config Management module. Backup is available without it. ### Three-step flow **Step 1 — Upload** Drag and drop your backup ZIP onto the upload area, or click to browse. The file is processed in your browser; nothing is sent to the server at this point. **Step 2 — Configure** Set your import options before reviewing what will be restored: * **Skip assignments** (on by default) — creates policies without any group or user assignments. Recommended when restoring to a different tenant or when you want to review assignments before activating policies. Turn this off only when restoring to the same tenant and you are sure the group IDs match. * **CA report-only** — creates all Conditional Access policies in report-only mode so they do not enforce immediately. Recommended when restoring to a production tenant. * **Exclude scope tags** — if your backup contains scope tags, you can deselect specific ones so items that reference only those tags are excluded from the import. **Step 3 — Review and Import** The review table lists every resource type and item found in the ZIP. You can: * Expand a resource type to see individual items. * Deselect items you do not want to restore. * Use the select-all checkbox in the row header to select or deselect all items for a type. Items that cannot be restored are greyed out with an explanation (for example, Microsoft proprietary scripts). These cannot be selected. Click **Start Import** to begin. Each item shows its result inline: a check mark for success, an X for failure with the error message, or a warning where the policy was created but with caveats (such as a removed secret reference or a reset notification template). When the import finishes, a summary shows how many items succeeded and how many failed. You can retry failed items individually or click **Reset & Re-import** to start over with the same ZIP. *** ## Supported resource types The following types are supported for both backup and restore unless noted. | Type | Backup | Restore | Notes | | ---------------------------------- | ------ | ------- | ------------------------------------------------------------------------------ | | Settings Catalog | yes | yes | Secret/password settings are skipped on restore | | Device Configuration | yes | yes | | | Compliance Policies | yes | yes | Scheduled action configurations are expanded | | Conditional Access | yes | yes | Location and Terms of Use refs stripped; auth strength limited to built-in IDs | | Assignment Filters | yes | yes | | | Scope Tags | yes | yes | | | App Protection (iOS) | yes | yes | | | App Protection (Android) | yes | yes | | | App Protection (Windows) | yes | yes | | | Enrollment Restrictions | yes | yes | Built-in default restriction cannot be restored | | Autopilot Profiles | yes | yes | | | Device Health Scripts | yes | yes | Microsoft global scripts are skipped on restore | | PowerShell Scripts | yes | yes | Microsoft proprietary scripts are skipped | | macOS Shell Scripts | yes | yes | | | Administrative Templates | yes | yes | Definition values not included | | Feature Update Profiles | yes | yes | EOL Windows versions may be rejected | | Driver Update Profiles | yes | yes | | | Quality Update Profiles | yes | yes | | | Endpoint Security | yes | no | Restore not yet supported | | App Configuration (Managed App) | yes | yes | | | App Configuration (Managed Device) | yes | yes | | | Enrollment Status Page | yes | yes | | | Notification Templates | yes | yes | | | Intune Branding | yes | yes | | | Terms of Use | yes | no | Cross-tenant IDs cannot be resolved | | Named Locations | yes | yes | Location IDs stripped; recreated as new | | Authentication Strengths | yes | no | Custom strengths are tenant-specific | | Compliance Scripts | yes | yes | | | ADMX Files | yes | no | Binary content not supported | *** ## Requirements * The **Config Management** module must be enabled for your tenant to use Restore. Backup is available with any active subscription. * Your Microsoft account must have permission to read (for backup) or write (for restore) the relevant Intune and Azure AD resources. The application prompts for consent if any permission is missing. * For restore, the following Microsoft Graph permissions are required: `DeviceManagementConfiguration.ReadWrite.All`, `DeviceManagementApps.ReadWrite.All`, `DeviceManagementRBAC.ReadWrite.All`, `DeviceManagementServiceConfig.ReadWrite.All`, `DeviceManagementScripts.ReadWrite.All`, `Policy.ReadWrite.ConditionalAccess`. *** ## Common questions **Can I restore a backup from a different tenant?** Yes. Enable Skip assignments and CA report-only to avoid unintended enforcement. Review all policies after import before enabling them. **What happens to assignments when Skip assignments is off?** Group and user IDs from the backup are used as-is. If those IDs do not exist in the target tenant, Intune will reject the assignments with a 404. Only use this option when restoring to the same tenant. **Why are some items greyed out in the review table?** Those items cannot be created via the API. Common examples are Microsoft global scripts (built-in Intune content), built-in enrollment restrictions, and Terms of Use entries. They are included in the backup so you have a record, but the restore skips them automatically. **What are the warnings shown after a successful restore?** Some fields cannot be transferred across tenants and are cleared automatically. You will see a warning when secret settings were skipped, notification templates were reset to the default, or a custom authentication strength was nulled out. Review the warnings and re-configure those fields in the target tenant. **Can I import a ZIP created by IntuneManagement (Mikael Karlsson's tool)?** Yes. The ZIP format is compatible. Note that some IntuneManagement exports do not include the `@odata.type` field inside each JSON file. IntuneAssistant detects the platform for App Protection policies (iOS/Android/Windows) from the file name in that case. **What if an import fails partway through?** Failed items remain in the review table with their error messages. Use the Retry button next to a failed resource type to retry only the failed items, or click Reset & Re-import to start the whole import over. # 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. *** ## Permissions and consent ### 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). # Audits # Audit Events ## What Is This Section? The **Audit Events** section gives you a complete view of everything that happens inside your Intune tenant. It helps you creating a dynamic Intune change log. Every policy change, device enrollment, app assignment, compliance action, and administrative operation performed by any user or system process is recorded by Microsoft Intune as an audit event. Intune Assistant surfaces those events in a set of purpose-built pages that go far beyond the basic list you see in the Intune portal. This section is built for anyone who needs to understand *what happened*, *who did it*, *when it happened*, and *what exactly changed* — whether that is a daily operational check, an incident investigation, a security audit, or evidence gathering for a compliance framework. *** ## Why Is Audit Visibility Important? Microsoft Intune manages devices, applications, and configurations at scale. Any change to a policy, any modification of a compliance rule, any app that gets assigned or removed — all of these have a real impact on devices and users across the organisation. Without proper audit visibility: * Changes go unnoticed until something breaks * Security incidents are difficult to investigate because the trail is unclear * Compliance assessments cannot be evidenced with specifics * It is impossible to answer the basic question: "Who changed this and when?" Intune Assistant makes audit events actionable by presenting them visually, with context, with filtering, and with the ability to trace related events around any single change. *** ## What Is Available | Page | What It Does | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | [Audit Dashboard](broken://pages/430a00f3e330ef7bf6a74b33149d5dd150549d1a) | Real-time overview with charts, stats, most active users, and a live event feed | | [Advanced Event Search](broken://pages/b55474ff2ca38197341948f53a30379b13ac571a) | Full-featured search with cascading filters, date presets, saved filter presets, and CSV/JSON export | | [Event Details](broken://pages/235c984516a3ace2ebdd41bd8c0caed0775c5de7) | Full detail view for a single event: timeline, resource impact with before/after property values, event flow diagram, and related events | *** ## How the Pages Connect The four pages are designed to flow into each other: 1. **Start at the Dashboard** for a quick situational overview — how many events, what categories, who is most active, any failures? 2. **Go to Advanced Event Search** when you need to narrow down to specific events — filter by date, category, actor, component, or result 3. **Open Advanced Audit Search** when you want to browse events in a split view and understand the context around a specific activity 4. **Arrive at Event Details** for any individual event that needs full investigation — the complete timeline, every resource that was modified, every property that changed before and after, and links to related events Every event row in the Dashboard and Search pages is clickable and opens the Event Details page for that event. *** ## Key Terms Understanding these terms will help you navigate the audit event pages: | Term | Meaning | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Activity** | The specific operation that was performed — e.g., `Create`, `Update`, `Delete`, `Assign` | | **Category** | The area of Intune the event relates to — e.g., `DeviceConfiguration`, `MobileApps`, `CompliancePolicy`, `Enrollment` | | **Actor** | The user or service principal that performed the operation. Shows as a UPN (email address) for human actions, or `System` for automated/service operations | | **Component** | The Intune component or service that generated the event | | **Result** | The outcome: **Success** (green), **Failure** (red), or **Warning** (yellow) | | **Resource** | The specific object that was affected — a policy name, a device, an app — including the properties that changed | | **Related Events** | Other events within a 1-hour window that share the same actor or the same affected resources | *** ## Related Sections * [Configuration Policies](/intune-assistant/policies/policy-overview) — see what policies exist; use Audit Events to see when they were changed * [Assignments](/intune-assistant/assignments/all-assignments) — see what is assigned; use Audit Events to see when assignments were made # Audit Events Dashboard ## What Is This Page? The **Audit Events Dashboard** is the front door to the audit section. It loads automatically and shows a live, at-a-glance picture of activity in your Intune tenant: total events, success rate, failure count, number of active categories, a timeline chart, a category distribution pie chart, your most active users, and a live event table — all on one page. It is designed to answer the question "what is happening right now?" in seconds, without requiring you to build a query or set any filters first. Everything updates immediately when you switch between the time-range presets or enable auto-refresh. ## Why Would You Use This? * Morning check: has anything unusual happened overnight? * Incident triage: there is a complaint about a policy change — quickly see if anything happened in the last hour * Operational awareness: which categories are generating the most activity today? * Identifying who is making the most changes and in which areas * Spotting failures at a glance before they become support tickets ## How Data Loads The dashboard loads automatically when you navigate to **Audit Events**. Data is fetched from the Intune audit log API and cached in the page context. Subsequent visits in the same session use the cached data and do not re-fetch — unless you click **Refresh** or change the time filter. {% hint style="info" %} If you leave the page and come back, the cached data is used immediately so the dashboard is instant. Click **Refresh** to get the latest events. {% endhint %} ## Auto-Refresh A toggle in the top-right area enables **Auto-refresh (30s)**. When enabled, the dashboard silently re-fetches data in the background every 30 seconds and updates all counts, charts, and the event table without any visible loading state. This is useful when you have the dashboard open on a secondary screen during an active change window or incident. ## Time Range Quick Filters Three buttons at the top of the page control the time window for all data on the dashboard: | Button | What It Shows | | ----------------- | ---------------------------------------------------------------------------- | | **All Events** | All audit events available in the Intune audit log (typically up to 30 days) | | **Last Hour** | Only events from the last 60 minutes | | **Last 24 Hours** | Only events from the last 24 hours | Clicking any button immediately re-fetches data for that time range. All charts, stats, and the event table update together. > 📸 *\[Screenshot placeholder: Dashboard header showing the three time filter buttons (All Events selected), the Auto-refresh toggle, a Refresh button, and an Advanced Search button]* ## Stats Cards Four summary cards are shown at the top of the dashboard, each with a large number and a coloured gradient background: | Card | What It Shows | | ---------------- | -------------------------------------------------------------------------------------------- | | **Total Events** | The total number of audit events in the selected time range | | **Success Rate** | Percentage of events with a `Success` result — calculated as `(Success count / Total) × 100` | | **Failures** | The raw count of events with a `Failure` result | | **Categories** | The number of distinct event categories present in the selected time range | ## Charts ### Events Over Time (Bar Chart) A bar chart showing event volume broken down **by hour** over the last 24 hours. Each bar represents one hour of the day (labelled `HH:00`). Hover over any bar to see the exact count for that hour. This chart helps you spot activity spikes — an unusually tall bar at 02:00 might indicate a scheduled automation ran, while a spike at 14:30 might correspond to a team making bulk changes. ### Events by Category (Pie Chart) A pie chart showing the proportion of events in each category. Each slice is labelled with the category name and count. **Clicking a slice filters the entire dashboard** — the event table below updates to show only events in that category, and a `Clear Filter` button appears to reset. The unselected slices fade to 30% opacity so it is visually clear which category is active. ## Most Active Users A list of the top 5 users ranked by the number of audit events they generated in the selected time range. Each entry shows: * An **avatar** with the user's initials (first letter of each name part, max 2 characters) * The user's **UPN** (email address) * The user's **Object ID** in smaller text below * An event count badge on the right: `N events` This section is useful for spotting if a single administrator is making an unusually high volume of changes — which may be expected during a project but could also indicate a misconfigured automation or a compromised account. ## Activities by Category A collapsible accordion panel listing all event categories, sorted by total event count (highest first). Each category row shows: * A **rank indicator** (coloured circle: gold for 1st, silver for 2nd, bronze for 3rd, blue for the rest) * The **category name** * A sub-line showing `N events · M activities` * An event count badge on the right ### Expanding a Category Click the **chevron icon** on the left of any category row to expand it. The expanded view shows each individual activity type within that category, ranked by count, with a `Nx` badge showing how many times that activity occurred. ### Expand All / Collapse All A button in the panel header toggles all categories open or closed at once. ### Filtering by Category **Clicking the category row** (not the chevron) filters the Recent Events table below to show only events from that category. The selected category row turns blue. A **Clear Filter** button appears in the panel header to reset. ## Recent Events Table The bottom section of the dashboard shows a paginated table of recent events. The table respects any active category or activity filter set via the charts or the Activities by Category panel. ### Columns | Column | What It Shows | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Time** | Relative time since the event occurred — e.g., `Just now`, `3 minutes ago`, `2 hours ago`, `1 day ago` | | **Activity** | The activity type in bold, with the Intune component name in smaller text below | | **Actor** | The UPN of the user who performed the action, preceded by a user icon. Shows `System` in grey if no user was involved | | **Category** | The event category as an outlined badge | | **Result** | Green **Success**, red **Failure**, or yellow **Warning** badge with an icon | | **Actions** | An eye icon button — clicking it navigates to the full [Event Details](/intune-assistant/audits/audit-event-details) page for that event | ### Clicking a Row Clicking anywhere on a row navigates directly to the [Event Details](/intune-assistant/audits/audit-event-details) page for that event — same as clicking the eye icon. ### Load More If there are more events than the initial load, a **Load More Events** button appears below the table. Clicking it appends the next batch of events to the existing table without replacing the current results. ## Filter Interaction — How Everything Connects The category filter (set by clicking the pie chart or the Activities by Category panel) affects only the **Recent Events table**. Charts and stats always reflect the full dataset for the selected time range. Clicking **Show All Activities** or the **Clear Filter** button in either the chart or the panel resets the table back to all events. ## Navigation * **Advanced Search** button (top right) — navigates to the [Advanced Event Search](/intune-assistant/audits/audit-event-search) page * **View All** link in the Recent Events card header — also navigates to [Advanced Event Search](/intune-assistant/audits/audit-event-search) * Clicking any event row — navigates to [Event Details](/intune-assistant/audits/audit-event-details) * Eye icon in the Actions column — navigates to [Event Details](/intune-assistant/audits/audit-event-details) ## Common Use Cases **Quick daily health check**\ Open the dashboard, look at the Success Rate and Failures cards. If the failure count is unexpectedly high, click the red failure slice in the pie chart to filter the event table and see what is failing. **Something broke overnight — what changed?**\ Click **Last Hour** or **Last 24 Hours**. Look at the Events Over Time bar chart for any spike. Check the Most Active Users list. Filter the event table by the relevant category. **Who has been making changes today?**\ Look at the Most Active Users card. The top entry is the user with the most activity in the selected time range. **How many policy changes happened this week?**\ Click **All Events**, then click the `DeviceConfiguration` or `PolicySets` slice in the pie chart to filter. The event count badge in the Recent Events header shows the filtered count. **Monitoring a live change window**\ Enable **Auto-refresh (30s)** and keep the dashboard open. New events appear automatically every 30 seconds without any manual action. ## Related Pages * [Advanced Event Search](/intune-assistant/audits/audit-event-search) — filter events by date, category, actor, and more * [Event Details](/intune-assistant/audits/audit-event-details) — full detail for a single event # Audit Event Search ## What Is This Page? The **Advanced Event Search** page is the precision search tool for Intune audit events. Where the [Dashboard](/intune-assistant/audits/audit-events-dashboard) gives you a broad overview, this page lets you build an exact query: pick a date range, narrow by category, activity type, actor, component, and result outcome, add a free-text keyword, and run the search against the Intune audit API. The results are paginated at 25 events per page and can be exported to CSV or JSON. The page also supports **saved filter presets** — named combinations of filters stored in your browser that you can reload in one click for recurring investigations. *** ## Why Would You Use This? * You need to find all events where a specific user made changes in a given date range * You are investigating a failure and need to see only `Failure` result events in the last 24 hours * You want to know all times a specific policy category was modified in the past 30 days * You need to extract a structured CSV or JSON file of audit events for a compliance report * You regularly audit the same combination of filters and want to save them as a named preset *** ## How Data Works on This Page This page uses data in two modes: **From the shared context (instant):** If the Dashboard or Advanced Audit Search page has already loaded events in the current session, those events are immediately available in the filter dropdowns and the results table without waiting. **From a fresh API search (when you click Search):** Clicking **Search** sends your filter criteria to the Intune audit API as a POST request and returns a paginated result (25 per page) matching your precise query. The results header reflects the source: `X of Y events` or `X of Y events from cache`. *** ## The Filter Panel All controls are in the **Filters** card. The total number of active filters is shown as a blue badge: `N active`. ### Date Range Two calendar date pickers — **From Date** and **To Date** — set the time boundary for the search. **Quick Date Presets** set both dates at once: | Preset | Window | | ----------------- | ----------------------- | | **Last 24 Hours** | now minus 24 h → now | | **Last 7 Days** | now minus 7 days → now | | **Last 30 Days** | now minus 30 days → now | | **Last 90 Days** | now minus 90 days → now | ### Free Text Search Searches simultaneously across display name, actor UPN, category, activity type, and component name. Press **Enter** to also trigger the Search. ### Cascading Multi-Select Filters Four dropdown filters that are **cascading** — each filter's available options narrow based on what you have already selected in the others, preventing impossible combinations. | Filter | Filters On | | -------------- | --------------------------------------------------------------------- | | **Categories** | Intune area — e.g., `DeviceConfiguration`, `MobileApps`, `Enrollment` | | **Activities** | Operation type — e.g., `Create`, `Update`, `Delete` | | **Actors** | UPN of the user who acted | | **Components** | Intune component or service | Each filter supports multiple selections. Selected values appear as removable chips (with ×) below the dropdown. Chips that are no longer valid after another filter changes are removed automatically. ### Result Toggle Buttons Three toggle buttons for outcome: **Success**, **Failure**, **Warning**. Multiple can be active simultaneously. Click an active button to deselect it. *** ## Running a Search Click **Search** in the filter card header. A spinner shows while the API call runs. Results are returned sorted newest-first. Click **Clear All** to reset every filter and the results table at once. *** ## Filter Presets ### Saving 1. Set your filters 2. Type a name in the **Preset name** field 3. Click **Save** Presets are stored in `localStorage` and persist across browser sessions. ### Loading Click any preset badge to instantly restore all its saved filter values. ### Deleting Click the × on a preset badge to permanently remove it. *** ## Results Table | Column | What It Shows | | ------------- | --------------------------------------------------------------- | | **Time** | Full date on one line, time on the next | | **Activity** | Display name in bold, category in smaller text below | | **Actor** | UPN with a blue user icon, or `System` in grey | | **Component** | Outlined badge showing the Intune component | | **Status** | Green **Success**, red **Failure**, or yellow **Warning** badge | Clicking any row navigates to the [Event Details](broken://pages/235c984516a3ace2ebdd41bd8c0caed0775c5de7) page. A **Load More Events** button appears below the table when more pages exist. *** ## Exporting Results Both exports respect your active filters — only visible filtered results are exported. ### Export CSV `audit-events-{ISO timestamp}.csv` — columns: Timestamp, Activity, Actor, Category, Component, Result, Display Name. ### Export JSON `audit-events-{ISO timestamp}.json` — full event objects including all fields, resources, and modified properties. *** ## Common Use Cases **All failures in the last 24 hours** — click Last 24 Hours preset → click Failure → click Search. **Who changed device configuration policies this week** — Last 7 Days → Categories: DeviceConfiguration → Search → review Actor column. **All enrollment failures for a compliance report** — Last 30 Days → Categories: Enrollment → Failure → Search → Export CSV. **Recurring audit query** — set filters → type preset name → Save. Next time, click the preset badge → Search. *** ## Related Pages * [Audit Dashboard](/intune-assistant/audits/audit-events-dashboard) — high-level overview and charts * [Advanced Audit Search](/intune-assistant/audits/audit-event-search) — split-panel browsing with related event context * [Event Details](/intune-assistant/audits/audit-event-details) — full detail for a single event # Audit Event Details ## What Is This Page? The **Event Details** page is the deepest level of the audit section. It shows everything Intune recorded about a single audit event: who performed it, when, what the outcome was, which resources were touched, and — crucially — **exactly what changed** on each resource, with the old value and the new value shown side by side for every modified property. The page also calculates and displays **related events** — other events within one hour that share the same actor or the same affected resources — and visualises them in an **Event Flow diagram** that shows the full chain of activity in chronological order. You arrive at this page by clicking any event row in the Dashboard, Search, or Advanced Audit Search pages. *** ## Why Would You Use This? * You need to know exactly what changed on a resource — what the value was before and what it is now * You are investigating an incident and want the complete picture for a single event: who, what, when, outcome, and all side effects * You want to understand what other events happened around the same time involving the same person or the same resource * You need to produce evidence of a specific change for a compliance audit or change management record *** ## How to Get Here * Click any event row in the [Audit Dashboard](/intune-assistant/audits/audit-events-dashboard) Recent Events table * Click any event row in the [Advanced Event Search](/intune-assistant/audits/audit-event-search) results table * Click any related event link in the Event Flow Visualizer on this same page *** ## Event Overview Card A wide card spanning three columns of the layout shows the four key facts about the event at a glance: | Field | What It Shows | | ------------- | ------------------------------------------------------------------------------------------------------- | | **Activity** | The activity type — e.g., `Update`, `Create`, `Delete` — or the display name if no activity type is set | | **Category** | The Intune area as an outlined badge — e.g., `DeviceConfiguration`, `MobileApps` | | **Result** | Green **Success**, red **Failure**, or yellow **Warning** badge with an icon | | **Component** | The Intune component or service that generated the event | A subtitle beneath the page title shows the **relative time** of the event — e.g., `3 minutes ago`, `2 hours ago`, `1 day ago`. *** ## Performed By Card A smaller card to the right of the overview shows who performed the event: * A circular **avatar** with the user's initials (up to 2 characters, e.g., `JD` for John Doe) on a blue background * The user's **UPN** (email address) * The user's **Object ID** (GUID) in smaller text below If the event was performed by an automated system process rather than a human, the UPN will be absent or show the service account identity. *** ## Event Timeline {% stepper %} {% step %} ### Event Occurred * The exact date and time the event was recorded * The display name of the event {% endstep %} {% step %} ### Changes Made This milestone is only shown if the event has one or more associated resources. * Shows how many resources were affected: `N resource(s) affected` * Clicking this milestone **expands** a list of the affected resources inline, each showing: * Resource display name * Resource type badge * A `N properties modified` link — clicking it smoothly scrolls the page down to the **Resource Impact** section Clicking again collapses the list. {% endstep %} {% step %} ### Event Completed * Shows the result badge (Success, Failure, or Warning) confirming the final outcome {% endstep %} {% endstepper %} *** ## Event Flow Diagram Below the timeline card, an **Event Flow** card shows a visual representation of the selected event in context with its related events. The flow is a vertical sequence of event cards connected by a gradient line (blue → purple → pink): ### Current Event Card (blue) The selected event is displayed prominently at the top of the flow: * A blue circular icon * `Current Event` badge + result badge * Activity name in bold * Date, time, and actor UPN * Category badge ### Related Event Cards (green / red / grey) Each related event is shown below the current event, colour-coded by result: * Green — Success * Red — Failure * Grey — other Each related event card shows: activity name, category badge, component name, relative timestamp, and result badge. **All related event cards are clickable links.** Clicking one navigates to the Event Details page for that related event. **What counts as related:** events within **1 hour** of the current event that either share the **same actor** or share at least one **resource ID**. *** ## Related Events Sidebar A sticky sidebar on the right side of the page lists the same related events as a compact card list. This sidebar stays fixed while you scroll down through the timeline and resource impact sections. Each entry shows: * A result icon (green checkmark, red ×, or grey activity) * Activity name (truncated with ellipsis if long) * Relative timestamp with a clock icon * Category badge Each entry is a link to the Event Details page for that related event. A purple horizontal connector line on the left edge of each card visually connects the sidebar entries to the main content area. *** ## Resource Impact At the bottom of the page, a full-width **Resource Impact** card shows every resource that was affected by this event. This section is shown only when the event has associated resources. A header badge shows the total: `N Resources`. Resources are shown in a two-column grid. Each resource card has a coloured left border (blue for even-numbered resources, purple for odd-numbered) and contains: ### Resource Header * Resource **display name** in bold * Resource **type** as an outlined badge * Resource **ID** (GUID) in small monospace text * A `Resource N` badge if there are multiple resources ### Modified Properties For each resource, only the properties where `oldValue !== newValue` are shown — unchanged properties are silently excluded. Each changed property shows: | Section | What It Shows | | ------------- | ----------------------------------------------------------------------------------------- | | Property name | The display name of the configuration property that was modified | | **Before** | The old value in a red-tinted code block — `(empty)` if the property did not exist before | | **After** | The new value in a green-tinted code block — `(empty)` if the property was cleared | Values are shown in monospace code font and wrap correctly for long values (like JSON payloads or base64 strings). By default, only the first **2 changed properties** per resource are shown. If there are more, a link appears: `Show N more properties` Clicking it expands the full list. A `Show less` link collapses it back to 2. If a resource has no changed properties, `No properties were changed` is shown in italic. *** ## Reading the Before / After Values The property values shown in the Resource Impact section are the raw values as stored in Intune. Depending on the property type, they may appear as: * A plain string — `Enabled`, `Disabled`, `Required` * A number — `0`, `1`, `86400` * A JSON object — `{"value": true, "enabled": false}` * A serialised payload or base64 string (for complex settings) * `(empty)` — the property was not set before the change, or was cleared by the change For complex JSON values, the code blocks support horizontal scrolling to show the full content without truncation. *** ## Common Use Cases **What exactly was changed in this policy?**\ Look at the Resource Impact section. Every property that changed is listed with its before and after value. **Who made this change and when?**\ The Performed By card and the Event Timeline show the actor and the exact timestamp. **Was this change successful?**\ The Result badge in the overview card and the green dot in the Event Timeline both confirm the outcome. **Did anything else happen around the same time?**\ Check the Related Events sidebar or the Event Flow diagram. Any event within one hour involving the same user or same resource appears there. **Follow the chain of a multi-step operation**\ Click through related events. Each related event's detail page has its own related events, so you can walk the full sequence step by step. **Capture evidence of a change for an audit**\ The Resource Impact section provides the exact before-and-after values for every modified property on every affected resource. Screenshot or save the page as evidence. # Service Announcements Service Announcements shows the M365 Message Center announcements for your tenant directly inside IntuneAssistant — the same messages you'd see in the Microsoft 365 admin center, filterable by service, severity, category, and tag. {% hint style="info" %} Browsing Service Announcements is **free** for any active IntuneAssistant subscription — no module purchase or installed Worker required. Getting a scheduled **email digest** of new or updated announcements requires the **Reporting** module and an installed Worker; see [Getting notified by email](#getting-notified-by-email) below. {% endhint %} ## Viewing announcements 1. Sign in to the **IntuneAssistant portal** at [portal.intuneassistant.cloud](https://portal.intuneassistant.cloud/) 2. In the left navigation, click **Tenant Events** 3. Select **Service Announcements** You'll see a table of all current Message Center announcements for your tenant, including: * **Title** — with a **Major** badge for changes Microsoft flags as significant * **Category** — Prevent or fix issue, Plan for change, or Stay informed * **Severity** — Normal, High, or Critical * **Services** — which Microsoft 365 services the announcement affects * **Tags** — e.g. Admin impact, User impact, Retirement * **Rollout** — for messages tracking a staged feature rollout, where it currently stands for your tenant (see [Tenant rollout status](#tenant-rollout-status) below) * **Last Updated** — when Microsoft last modified the announcement Click any row to open the full message, including the complete announcement text as published by Microsoft. Up to 1,000 matching messages are loaded at once; if your tenant has more than that, narrow your filters to see the rest. ## Filtering Use the **Filters** panel to narrow the list: | Filter | Description | | ---------------------- | -------------------------------------------------------------------------------------------------- | | **Service** | Show only announcements affecting a specific service (e.g. `Microsoft Entra`) | | **Severity** | Normal, High, or Critical | | **Category** | Prevent or fix issue, Plan for change, or Stay informed | | **Tag** | Free-text tag match, e.g. `Admin impact` | | **Rollout status** | Scheduled, In Rollout, or Launched (see below) — only matches messages that track a staged rollout | | **Only major changes** | Show only announcements Microsoft has flagged as a major change | Filters apply immediately and can be combined. Use **Clear filters** to reset. ## Tenant rollout status Some announcements — typically ones tied to a Microsoft 365 Roadmap feature — track exactly where the rollout stands for **your** tenant specifically, not just when Microsoft announced it generally: * **Scheduled** — the feature is planned but hasn't started rolling out to your tenant yet * **In Rollout** — actively rolling out, often shown with a release ring (e.g. Standard Release) * **Launched** — fully rolled out to your tenant Open a message with a **Rollout** badge to see the breakdown per platform (e.g. iOS, Android, All) — a feature can be further along on one platform than another. Messages with no rollout badge don't track a staged rollout; the vast majority of Message Center posts fall into this category. ## Getting notified by email Browsing shows you what's happening right now, but you can also get proactively notified as new or updated announcements come in — configure a **Service Announcement Digest** job under **Worker → Job Management**. This requires the **Reporting** module. See [Manage Jobs](/extensions/worker/manage-jobs) for setup instructions. ## Requirements **To browse:** * An active IntuneAssistant subscription (no additional module required) * The signed-in user must have consented to the `ServiceMessage.Read.All` Graph permission (you'll be prompted automatically the first time you open this page if it's missing) **To receive the email digest:** * The **Reporting** module * An installed and approved Worker # Compare ## Overview The **Compare Module** in IntuneAssistant provides two powerful tools for analysing policy overlap, conflicts, and coverage in your Microsoft Intune environment: 1. **Compare Existing Policies** — Compare policies that already exist within your tenant against each other to identify coverage gaps, conflicts, and duplicate settings before enabling a new policy. 2. **External Policy Comparison** — Upload exported JSON policy files and compare their settings against what is already configured in your tenant. > 📸 **Screenshot Placeholder**: *Compare module landing page showing both tools* *** ## Why Use the Compare Module? Before deploying a new policy or importing a baseline configuration, it is important to understand how it relates to what is already in your environment. The Compare Module helps you: ✅ **Avoid conflicts** — Identify settings that are already configured with different values\ ✅ **Prevent duplication** — Find settings already covered by existing policies\ ✅ **Understand coverage gaps** — Discover settings in a new policy that are not yet in the tenant\ ✅ **Make safe deployment decisions** — Know what will change before you enable a policy\ ✅ **Audit external baselines** — Validate imported configuration files against your live tenant *** ## Tool 1: Compare Existing Policies ### Overview Navigate to **Compare → Policies** to compare Settings Catalog policies that exist within your tenant. You select a **source** policy (or multiple source policies) and compare them against **target** policies to understand the overlap. > 📸 **Screenshot Placeholder**: *Compare Existing Policies page with the Policy Selection card visible* ### Getting Started {% stepper %} {% step %} **Step 1: Load Policies** Click **Load Policies** to fetch all available Settings Catalog policies from your tenant. The total number of policies found is displayed in the selection card. > 📸 **Screenshot Placeholder**: *Policy Selection card showing "Load Policies" button* > {% endstep %} {% step %} **Step 2: Select Source Policies (Left Side)** Choose one or more **source policies** from the left panel. These are the policies you want to evaluate — typically a new or unassigned policy you are planning to enable. * Use the **scope tag filter** above the list to narrow down policies by scope tag. * The source policy list will exclude policies already selected on the right side. > 📸 **Screenshot Placeholder**: *Left side policy selector with scope tag filter* > {% endstep %} {% step %} **Step 3: Select Target Policies (Right Side)** Choose the **target policies** from the right panel. These are the existing policies already active in your environment. * When a source policy is selected, the target list is automatically filtered to show only policies with a **matching platform and type**. * Use the scope tag filter on the right side to further narrow down the target list. > 📸 **Screenshot Placeholder**: *Right side policy selector filtered by platform* > {% endstep %} {% step %} **Step 4: Run the Analysis** Click **Analyse Policy Overlap** to start the comparison. A progress banner shows the number of batches being processed. {% endstep %} {% endstepper %} ### Comparison Modes The tool automatically selects the comparison mode based on how many source policies are selected: | Source Policies Selected | Mode Used | Description | | ------------------------ | ----------------- | ----------------------------------------------------------------------------- | | **1 policy** | Single comparison | Compares the source policy setting-by-setting against each target policy | | **2+ policies** | Set analysis | Aggregates all source policies into a set and compares against the target set | ### Understanding Single-Source Results When one source policy is selected, the results are displayed in three tabs: {% tabs %} {% tab title="Overall Coverage" %} Shows each setting from the source policy and its status across all target policies. Settings are grouped and colour-coded: | Status Badge | Meaning | | -------------------------- | ------------------------------------------------------------------- | | 🟢 **Already covered** | Same value exists in an existing policy — safe to enable | | 🔴 **Conflict** | Different value exists — enabling may cause conflict or override | | 🔵 **New — not elsewhere** | Only in your new policy, no existing policy covers this setting | | ⚫ **Only in existing** | Only in an existing policy, your new policy does not configure this | Use the **search** and **status filter** to focus on the most important settings. > 📸 **Screenshot Placeholder**: *Overall Coverage tab with filtered settings and status badges* > {% endtab %} {% tab title="Per-Policy Detail" %} Shows a breakdown for each target policy individually. Each policy card displays: * A stacked bar chart (🟢 covered / 🔴 conflict / 🔵 new only) * A list of settings with their status and values side-by-side * Use the **Conflicts / new only** filter to hide fully-matching policies > 📸 **Screenshot Placeholder**: *Per-Policy Detail tab with one policy card expanded* > {% endtab %} {% tab title="Summary" %} Shows a per-policy overlap breakdown table with progress bars for each target policy including: * **Covered** — settings with the same value * **Conflict** — settings with different values * **New only** — settings only in the source policy * **Exist only** — settings only in the target policy > 📸 **Screenshot Placeholder**: *Summary tab with per-policy stacked progress bars* > {% endtab %} > {% endtabs %} ### Understanding Set Analysis Results (Multi-Source) When two or more source policies are selected, the **Set Analysis** mode runs. This aggregates all source policies into a **left set** and compares them against all target policies (the **right set**). Results are displayed as a list of settings with their status: | Status | Meaning | | -------------------- | ----------------------------------------------------- | | **Match** | Setting exists in both sets with the same value | | **Conflict** | Setting exists in both sets with different values | | **Duplicate** | Setting configured multiple times within the same set | | **Missing in Left** | Setting only in the right (target) set | | **Missing in Right** | Setting only in the left (source) set | | **New in Left** | Brand-new setting not seen in the right set | | **New in Right** | Brand-new setting not seen in the left set | | **Overlap** | Setting appears in multiple policies within a set | > 📸 **Screenshot Placeholder**: *Set Analysis results with summary counts and settings list* ### Actions | Action | Description | | -------------- | ----------------------------------------------- | | **Re-run** | Re-run the comparison with the same selection | | **Refresh** | Re-load policies and scope tags from the tenant | | **Export CSV** | Download all comparison results as a CSV file | | **Cancel** | Cancel an in-progress analysis | *** ## Tool 2: External Policy Comparison ### Overview Navigate to **Compare → Configuration** to compare **uploaded JSON policy files** against your live tenant. This is ideal for validating external baselines, CIS benchmarks, or policies exported from another tenant. > 📸 **Screenshot Placeholder**: *External Policy Comparison page with the upload zone visible* ### Getting Started {% stepper %} {% step %} **Step 1: Upload Policy JSON Files** Drag and drop one or more exported Intune policy JSON files into the upload zone, or click to browse. The tool supports: * **Settings Catalog** policies (`deviceManagementConfigurationPolicy`) * **Device Configuration** profiles (`deviceConfiguration` subtypes) * **Group Policy** configurations (`groupPolicyConfiguration`) The policy **type and platform are auto-detected** from the JSON content. Each uploaded file is shown with its detected name, type badge, platform badge, and the number of settings detected. > 📸 **Screenshot Placeholder**: *Upload zone with two uploaded policies listed* **💡 Tip**: You can upload multiple files at once. Tenant data is fetched once and reused — use **Refresh Tenant Data** to re-fetch without re-uploading. {% endstep %} {% step %} **Step 2: Run the Comparison** Click **Compare Against Tenant** to fetch matching tenant policies and run the analysis. The tool: 1. Fetches all tenant policies matching the **same platform and type** as the uploaded files 2. Resolves setting definition IDs to human-readable names 3. Compares each setting value from the uploaded file against tenant configurations A loading banner shows the current phase (fetching tenant data, resolving definitions, analysing). > 📸 **Screenshot Placeholder**: *Loading banner during analysis* > {% endstep %} > {% endstepper %} ### Understanding the Results Results are shown in two tabs: **Analysis** and **Summary**. {% tabs %} {% tab title="Analysis" %} For each uploaded policy, a results section shows every setting with its status: | Status | Colour | Description | | ----------------- | -------- | -------------------------------------------------------------- | | **Match** | 🟢 Green | The tenant has this setting configured with the **same value** | | **Conflict** | 🟡 Amber | The tenant has this setting but with a **different value** | | **Not in tenant** | 🔴 Red | No tenant policy covers this setting | Each row shows: * **Setting name** (human-readable, resolved from definition IDs) * **Uploaded value** — the value from your JSON file * **Tenant value** — the value found in matching tenant policies * **Source policy name** — which tenant policy contains this setting Use the **status filter** buttons to show only Matches, Conflicts, or Missing settings. Use the **search box** to find specific settings by name. > 📸 **Screenshot Placeholder**: *Analysis tab showing a policy with conflict and missing settings highlighted* **Assigned vs. Unassigned**: Tenant policies that are assigned (active/production) are indicated separately so you can prioritise conflicts with live policies. {% endtab %} {% tab title="Summary" %} The Summary tab gives an aggregated view across all uploaded policies: **Settings Coverage card** — An overall stacked bar showing what percentage of all uploaded settings are: * 🟢 Matched in the tenant * 🟡 Conflicting in the tenant * 🔴 Not found in the tenant **Per-Policy cards** — One card per uploaded policy showing: * Total settings count * Coverage percentage (matched + conflicting) * Three stat pills: Match / Conflict / Not in tenant with counts and percentages * Number of tenant policies matched by platform **Per-Policy Match Breakdown** — Progress bars for match, conflict, and missing percentages per uploaded policy. **Platform Filtering** — Shows how many tenant policies were considered after platform matching for each uploaded policy. **Top Conflict Hotspots** — Settings that conflict across the most uploaded policies, helping you identify the most impactful issues to address first. > 📸 **Screenshot Placeholder**: *Summary tab showing per-policy coverage cards and conflict hotspots* > {% endtab %} > {% endtabs %} ### Policy Type Detection The tool automatically determines the policy type from the JSON file: | Detected Type | Description | | -------------------- | ------------------------------------------------------------------ | | **Settings Catalog** | Modern policy using the Settings Catalog format | | **Device Config** | Classic device configuration profiles (OMA-URI, platform-specific) | | **Group Policy** | Administrative template (ADMX) based Group Policy configurations | | **Unknown** | Could not auto-detect — check the JSON format | ### Actions | Action | Description | | -------------------------- | ------------------------------------------------------- | | **Compare Against Tenant** | Run the analysis for all uploaded files | | **Re-run Analysis** | Re-run analysis with existing tenant data (no re-fetch) | | **Refresh Tenant Data** | Re-fetch all tenant policies (clears the cache) | | **Export CSV** | Download comparison results as a CSV file | | **Clear All** | Remove all uploaded files and reset the page | | **Cancel** | Cancel an in-progress fetch or analysis | *** ## Reading Setting Values Both tools resolve setting IDs to human-readable names where possible: * **Setting names** are resolved from Microsoft Graph definition metadata * **Setting values** show the friendly label (e.g., "Enabled" instead of `device_vendor_msft_policy_...`) * Where a value is an option ID, the human-readable option label is shown; the raw ID is displayed below in smaller text for reference > 📸 **Screenshot Placeholder**: *Setting row showing friendly name, human-readable value, and raw ID* *** ## Common Scenarios ### Scenario 1: Validating a CIS Benchmark Baseline **Situation**: You have downloaded a CIS Benchmark policy JSON and want to know how much of it is already configured in your tenant. **Action**: Use **External Policy Comparison**. Upload the JSON file, run the comparison, and review the Summary tab. Focus on "Not in tenant" settings to identify gaps and "Conflict" settings to review value differences. *** ### Scenario 2: Checking a New Policy Before Enabling **Situation**: You have created a new unassigned Settings Catalog policy and want to ensure it won't conflict with existing assigned policies. **Action**: Use **Compare Existing Policies**. Select your new policy as the source and all currently assigned policies as targets. Run the analysis and review the "Conflict" settings in the Overall Coverage tab. *** ### Scenario 3: Comparing Two Sets of Policies **Situation**: You have two groups of policies (e.g., different scope tags for different device groups) and want to understand the overlap between them. **Action**: Use **Compare Existing Policies**. Select all policies in group A as source, all policies in group B as targets. The **Set Analysis** mode will automatically activate and show you matches, conflicts, duplicates, and unique settings across both sets. *** ### Scenario 4: Migrating Policies from Another Tenant **Situation**: You have exported policies from a source tenant and want to import them into a new tenant. You need to understand what is already configured. **Action**: Export the policies as JSON, then use **External Policy Comparison** to compare them against the target tenant. Review the Summary tab and conflict hotspots before importing. *** ## Troubleshooting ### No Policies Load **Problem**: Clicking **Load Policies** returns no results. **Solutions**: * Verify you are signed in and have the correct tenant selected * Ensure you have Intune read permissions * Check that your tenant has Settings Catalog policies configured ### Policy Type Shows "Unknown" **Problem**: An uploaded file shows the "Unknown" type badge. **Solutions**: * Verify the JSON file is a valid Intune policy export * Settings Catalog exports are detected automatically even without an `@odata.type` field, as long as the file still has its `settings` array and `settingCount` * For Device Config or Group Policy exports, check that the `@odata.type` field is present in the JSON * Ensure the file was exported directly from Intune (not manually edited) ### Analysis Shows 0 Settings **Problem**: Analysis completes but shows no settings detected. **Solutions**: * For Settings Catalog policies: verify the JSON contains a `settings` array * For Device Config: verify the JSON contains platform-specific configuration keys * Try re-uploading the file — ensure it is a complete, unmodified export ### All Settings Show "Not in Tenant" **Problem**: External comparison shows no matches despite expected coverage. **Solutions**: * Verify the uploaded policy platform matches policies in your tenant * Check that tenant policies have been fully configured (not just created) * Use **Refresh Tenant Data** to ensure you have the latest tenant configuration *** ## FAQ
Q: What policy types are supported? A: Settings Catalog, Device Configuration (all platform subtypes), and Group Policy (Administrative Templates) are supported. Compliance policies and App Protection policies are not currently included.
Q: Does this tool make any changes to my tenant? A: No. Both tools are read-only. No policies are created, modified, or deleted.
Q: Why does the target policy list filter when I select a source? A: Platform matching is enforced to ensure meaningful comparisons. A Windows policy cannot conflict with a macOS policy, so only same-platform, same-type policies are shown as targets.
Q: Can I compare more than two policies at once? A: Yes. Both tools support multi-select. Selecting 2+ source policies activates Set Analysis mode, which compares all source policies as a group against all target policies as a group.
Q: What does "assigned" mean in the results? A: An "assigned" policy is one that has at least one device or user group assignment — meaning it is actively enforced in your environment. Conflicts with assigned policies are higher priority than conflicts with unassigned (staged) policies.
Q: Can I upload multiple JSON files at once? A: Yes. In External Policy Comparison, you can drag and drop multiple JSON files at once. Each file is analysed independently.
Q: Why do some setting values show a raw ID instead of a friendly name? A: Setting definition IDs are resolved from Microsoft Graph metadata. If a definition is not found (e.g., custom or preview settings), the raw ID is shown. The raw ID is always shown below the friendly name for reference.
Q: Can I export the results? A: Yes. Both tools have an **Export CSV** button that downloads all comparison results for further analysis in Excel or other tools.
*** ## Permissions Required To use the Compare Module, your account needs: * **Intune read access** — to fetch policies and settings from the tenant * **Settings definitions read access** — to resolve setting IDs to human-readable names No write permissions are required. *** *Last updated: May 2026* # Policy Compare ## What Is This Page? The **Policy Comparison** page lets you pick two Intune configuration policies and compare them setting by setting. Every setting that exists in either policy is listed, and for each one you can see the exact value configured in the **Source** policy and the exact value configured in the **Target** policy — side by side, in a colour-coded layout that makes differences immediately obvious. The page tells you not just that two settings are different, but *what* the difference is, and in the case of complex settings with sub-options (child settings), it drills into every sub-option individually so nothing is hidden. *** ## Why Would You Use This? * You created a policy for a new deployment ring and want to verify it matches your reference policy before assigning it * Two teams manage separate policies for similar device types and you want to understand what is different between them * You are migrating settings from one policy to another and need a detailed diff to track what has been moved * You want to confirm that a cloned policy is truly identical to its original after modification * You are doing a compliance review across environments (e.g., Production vs. Acceptance) and need a structured report of what differs * You need to document what changed between a policy in its current state and a peer policy used as a baseline *** ## Step 1 — Load Policies {% stepper %} {% step %} ### Load Policies 1. Navigate to **Compare → Policies** 2. Click **Load Policies** 3. Intune Assistant fetches all Settings Catalog policies from your tenant 4. The number of available policies is shown below the dropdowns: `Found N configuration policies` {% endstep %} {% step %} ### Select the Source Policy The **Source Policy** is the reference — the policy you are comparing *from*. Think of it as the baseline. 1. Click the **Source Policy** dropdown 2. A searchable list opens showing all available Settings Catalog policies 3. Each entry in the list shows the **policy name** on one line and the **policy type and platform** on the line below 4. Type in the search box to filter by name or policy type 5. Click a policy to select it Once a source policy is selected, the target policy dropdown becomes active. {% endstep %} {% step %} ### Select the Target Policy The **Target Policy** is the policy you are comparing *against*. {% hint style="info" %} **The target dropdown is automatically restricted to policies on the same platform as the source policy.** If your source policy targets Windows, only other Windows Settings Catalog policies appear in the target list. The source policy itself is also excluded from the target options. This ensures you are always comparing policies that are intended for the same device platform — a Windows policy compared to an iOS policy would produce meaningless results. {% endhint %} 1. Click the **Target Policy** dropdown 2. Search and select the policy you want to compare to {% endstep %} {% step %} ### Run the Comparison Once both policies are selected, a **Compare Policies** button appears centred below the dropdowns. 1. Click **Compare Policies** 2. A spinner shows while the comparison runs 3. The comparison results appear below {% endstep %} {% endstepper %} *** ## Reading the Results ### The Policy Header Bar A sticky bar at the top of the results section shows the two policy names in colour-coded panels that persist as you scroll: * **Blue panel — Source Policy** — the policy you are comparing from * **Green panel — Target Policy** — the policy you are comparing against This stays visible at the top of the results as you scroll through a long list of settings. > 📸 *\[Screenshot placeholder: Sticky header bar showing a blue Source Policy panel on the left with the policy name, and a green Target Policy panel on the right with the target policy name]* *** ### The Stats Bar The results header shows four summary counts: | Badge | What It Counts | | --------------- | ---------------------------------------------------------------------- | | **Same** | Settings that exist in both policies and have identical values | | **Different** | Settings that exist in both policies but have different values | | **Source Only** | Settings that exist only in the source policy — absent from the target | | **Target Only** | Settings that exist only in the target policy — absent from the source | The total count is shown in the card header: `Comparison Results (N settings)`. > 📸 *\[Screenshot placeholder: Results card header showing four coloured stat badges — green Same, red Different, blue Source Only, yellow Target Only — each with a count number]* *** ### Setting States — The Four Badges Every setting in the results list has a badge on the right side of its row: | Badge | Meaning | | --------------- | ----------------------------------------------------------------------------------- | | **Same** | The setting is configured in both policies with the same value | | **Different** | The setting is configured in both policies but the values do not match | | **Source Only** | The setting is present in the source policy but does not exist in the target policy | | **Target Only** | The setting is present in the target policy but does not exist in the source policy | *** ### What Each Setting Row Shows Each setting in the results list displays: **Setting name and status badge**\ The display name of the setting and its comparison badge, shown together at the top of the row. **Description**\ A plain-text explanation of what this setting controls, pulled from the Settings Catalog definition. **Keywords**\ One or more category tags associated with the setting (e.g., `Security`, `BitLocker`, `Firewall`, `Windows Update`). These are shown as small neutral badges and can be used to filter the results. **Source Value (blue) and Target Value (green)**\ A two-column layout showing the configured value in each policy. Values are shown as text. If a setting does not exist in one of the policies, `[Not Set]` is shown in that column. **Differences Summary (yellow, only for Different settings)**\ When a setting is marked **Different** and the API returns a structured description of the change, a yellow panel appears below the values. It contains a human-readable summary of exactly what changed — for example, `Value changed from 'Disabled' to 'Enabled'`. > 📸 *\[Screenshot placeholder: A single setting row showing a red Different badge, a description paragraph, keyword badges, a blue SOURCE VALUE panel and a green TARGET VALUE panel with different text in each, and a yellow DIFFERENCES SUMMARY panel below]* *** ### Child Settings Some Settings Catalog settings contain **sub-options** — for example, a Firewall setting may have child settings for inbound rules, outbound rules, notification behaviour, and so on. When a setting has child settings, they are displayed in a collapsible section below the main setting values. Each child setting shows: * The child setting name * A **SOURCE** value (blue) and a **TARGET** value (green) side by side * A red **Different** badge and red background highlight on any child where the two values do not match Child settings with identical values in both policies are shown with a neutral grey background. > 📸 *\[Screenshot placeholder: Child Settings section expanded showing three child settings — two with matching values on grey backgrounds, one with different values on a red background and a red Different badge]* *** ## Filtering the Results Three filter controls are available above the results list. All three combine — a setting must match all active filters to appear. ### Search A text input that filters results by **setting name** in real time. Type any part of a setting name to narrow the list. An × button appears to clear the search term. ### Comparison Status A dropdown with five options: | Option | What It Shows | | -------------------- | ----------------------------------------------------------------------------------- | | **All Settings** | No filter — show all comparison results | | **Different Values** | Show only settings with different values (`InBothDifferent`) | | **Same Values** | Show only settings that are identical in both policies (`InBothTheSame`) | | **Source Only** | Show only settings that exist in the source policy but not the target (`InSource`) | | **Target Only** | Show only settings that exist in the target policy but not the source (`InChecked`) | ### Filter by Keywords A multi-select dropdown populated from the keywords attached to the settings in the comparison results. The available keywords vary by policy content — you might see tags like `Security`, `BitLocker`, `Defender`, `Firewall`, `Update`, and so on. * Search within the keyword list by typing in the embedded search box * Select multiple keywords — the results show settings that match **any** of the selected keywords * Up to 2 selected keywords are shown as badges in the closed dropdown; additional ones show as `+N more` * Click × on any keyword chip to remove it individually ### Active Filter Chips When any combination of search, status, or keyword filters is active, an **Active Filters** section appears below the filter controls, showing each active filter as a removable chip. Click the × on any chip to clear that specific filter without affecting the others. A **Clear** button in the filter card header resets all three filters at once. > 📸 *\[Screenshot placeholder: Filters card showing a search box with text, the Status dropdown set to "Different Values", the Keywords dropdown showing two selected keywords as badges, and an Active Filters row below with three removable chips and a Clear button]* *** ## Stats Update With Filters The four summary badges in the results header (**Same**, **Different**, **Source Only**, **Target Only**) always reflect the **currently filtered** result set, not the full unfiltered comparison. When you apply filters, the counts update immediately to show how many settings of each type match your current criteria. *** ## Exporting the Comparison Once comparison results are loaded, an **Export HTML** button appears in the results card header. Clicking it downloads a **self-contained HTML file** — a fully formatted, interactive report that can be opened in any browser without needing an internet connection or an Intune Assistant account. **Filename format:**\ `policy-comparison-{source-name}-vs-{target-name}-{date}.html` For example: `policy-comparison-windows_security_baseline-vs-legacy_device_config-2026-04-27.html` ### What the HTML Report Contains * A formatted header with the report title and generation timestamp * A **stats summary** section with Same / Different / Source Only / Target Only counts * The full **Source Policy** and **Target Policy** names in colour-coded panels * Every setting as a card, with description, keywords, source value, target value, differences summary, and child settings * A built-in **interactive filter bar** with search, status dropdown, and keyword filter — so the recipient of the report can filter the results in their browser without needing access to Intune Assistant * A **no results** message when filters produce an empty list {% hint style="success" %} **The HTML export is designed to be shared.** Send it to a colleague, a manager, or an auditor and they can explore the full comparison in their browser — no login, no dependencies, no special software. {% endhint %} *** ## Common Use Cases **Verify a cloned policy before assigning it**\ Select the original as Source and the clone as Target. Filter Status to `Different Values` — if anything shows up, something changed during the clone or was edited afterwards. **Compare production and test environment policies**\ Select the production policy as Source and the test policy as Target. Export to HTML and share with the team doing the test environment review. **Find settings that are in one policy but missing from another**\ Filter Status to `Source Only` to see everything the target policy is missing. Filter to `Target Only` to see everything the source policy is missing. **Audit a specific security area across two policies**\ Use the Keywords filter to narrow to a category like `BitLocker` or `Firewall`. Then filter Status to `Different Values` to see only the security-relevant settings that differ. **Document what changed between a baseline and a current policy**\ Select the baseline as Source and the current policy as Target. Export to HTML and archive the report as evidence of drift or intentional change. *** ## Related Pages * [Policy Overview](broken://pages/283ea35cd02ca03b9decaa8f2bad2d604b04cfd7) — see all policies and their assignment status * [Policy Settings Overview](broken://pages/f335a77c752fe7a30900731ee89bcb23012e389d) — find duplicate and conflicting settings across all policies * [Configuration Overview](broken://pages/88fd087e7bc4ff7c298750c777512cbaf0b57966) — the full configuration management section # Devices Tools for working with your Intune-managed device fleet. * [Device Compare](/intune-assistant/devices/device-compare) — compare two devices side-by-side to see differences in assigned configuration, compliance, apps, filters, scope tags and Windows Update Ring membership. * [Duplicate Devices](/intune-assistant/devices/duplicate-devices) — find devices enrolled more than once under the same hardware identity and remove the stale duplicates. # Device Compare ## What it does Device Compare lets you pick two Intune-managed devices and see exactly where their configuration differs. It's built for the situation where two devices in the same fleet behave differently — for example, one has a shorter screensaver timeout, a different update ring, or a policy the other doesn't have — and nobody is sure why. The comparison covers: * **Configuration policies** — Settings Catalog, Device Configuration, Administrative Templates and Endpoint Security policies applied to each device, with their per-device status. * **Compliance policies** — assigned compliance policies and their compliance state. * **Enrollment configurations** — enrollment restrictions and Enrollment Status Page profiles applied to each device. * **Installed applications** — required apps and their install state. * **Group memberships** — which Entra groups each device belongs to. * **Assignment filters** — which assignment filters are in play for each device. * **Health scripts (proactive remediations)** — assigned scripts and their detection state. * **Windows Update Ring membership** — which Feature, Quality and Driver update rings each device falls under, resolved from group membership. * **Scope tags** — scope tags assigned to each device. ## How to use it 1. Navigate to **Devices > Device Compare** in the sidebar. 2. Use the **Left device** and **Right device** search boxes to find and select the two devices you want to compare — search by device name, user, or serial number. 3. Once both devices are selected, the comparison runs automatically. 4. Click **Export as documentation** to download the comparison as a Markdown file you can share with your team. ## What you'll see Each device gets a summary card showing its name, primary user, and scope tags. Below that, every comparison area (Configuration Policies, Compliance Policies, Applications, and so on) is shown as its own table with one row per item and four columns: the item name, the value on the left device, the value on the right device, and a status: * **Same** — present on both devices with the same value. * **Different** — present on both devices but with a different status or value. * **Only left device** / **Only right device** — assigned to one device but not the other. Each table is searchable and sortable, so you can quickly filter down to just the differences. For Configuration Policies and Compliance Policies, the left/right values are one of: **Compliant**, **Non-compliant**, **Error**, **Conflict**, **Remediated**, **Not applicable**, **Not assigned**, or **Unknown**. A **Conflict** status usually means the device is targeted by two overlapping policies of the same type (for example, two Windows Update Rings) — worth checking group assignments for that policy. ## Requirements Device Compare is available to any active IntuneAssistant customer — no additional license or module is required. Your account needs read access to Intune devices, configuration, compliance, apps, and Entra group membership; IntuneAssistant will prompt for consent if a permission is missing. ## Common questions and tips **Why does a policy show as "Different" instead of "Same" even though I think they're identical?** The status reflects Intune's own per-device deployment status (for example, whether the policy has been successfully applied), not a deep diff of the policy's settings. Two devices can have the same policy assigned but be in different states if one hasn't checked in recently. **Why do I see Update Ring entries that aren't in the Configuration Policies section?** Update Ring membership (Feature, Quality, and Driver update profiles) is resolved separately by checking whether each device belongs to one of the groups assigned to those profiles, since Intune does not report update ring assignment per device the same way it does for other policy types. **Can I compare more than two devices at once?** Not yet — Device Compare is built for side-by-side, two-device comparisons. If you need to compare more devices, run multiple comparisons. **What does the exported documentation look like?** It's a Markdown file with a summary table for both devices followed by one table per comparison area, matching what you see on screen. You can open it in any Markdown viewer or paste it into a wiki page. # Duplicate Devices ## What it does Duplicate Devices scans your Intune-managed device fleet and flags devices that are actually the same physical hardware enrolled more than once. This commonly happens after a device is re-imaged, re-enrolled, or renamed — Intune ends up with two (or more) managed device records that both belong to one laptop or phone. Detection is based on hardware identity, not the device name — a device can be renamed at any point without breaking detection. Devices are grouped together when they share the same: * **Serial number** * **Wi-Fi MAC address** Placeholder or blank values (for example a virtual machine's default serial number, or an all-zero MAC address) are ignored so they don't get lumped together as false duplicates. ## How to use it 1. Navigate to **Devices > Duplicate Devices** in the sidebar. 2. Click **Scan for Duplicates** to run the scan across your device fleet. 3. Devices that were matched to another device are tagged **Duplicate** in the list. Use the **Show duplicates only** toggle to hide everything else. 4. Click **View Duplicates** on a tagged device to open its duplicate group — a side-by-side view of every device that matched. 5. From the group view, click the trash icon next to a device to remove it. {% hint style="danger" %} Removing a device deletes its record from both **Intune** and **Entra ID**. This cannot be undone — make sure you're removing the stale duplicate, not the device that's actually still in use. {% endhint %} ## What you'll see The scan shows three summary numbers: total devices scanned, how many are duplicates, and how many duplicate groups were found. Each duplicate device is tagged with a **Duplicate** badge and a **Matched On** indicator showing whether it was grouped by serial number, Wi-Fi MAC address, or both. Opening a group shows every device in it with its compliance state, last sync time, serial number, and Wi-Fi MAC address, so you can tell which one to keep before removing the others. ## Requirements Scanning and viewing duplicate devices is available to any active IntuneAssistant customer — no additional license is required. **Removing** a duplicate device requires the **Configuration Management** module, since it's a write-side action that deletes data from your tenant. If your account doesn't have this module, the remove button is disabled and you can still see the full duplicate group. ## Common questions and tips **Why isn't a device I know is duplicated showing up?** Detection relies on the device reporting a serial number or Wi-Fi MAC address to Intune. Devices without either — or with only a placeholder value — can't be matched and won't be flagged, even if they're the same hardware. **Why is a device grouped with others that don't look related?** Matching is based purely on serial number and Wi-Fi MAC address, not device name. If two seemingly unrelated device names share a group, it usually means the same physical machine was re-enrolled under a different name. **What exactly happens when I remove a device?** The device's managed device record is deleted from Intune, and its corresponding device object is deleted from Entra ID. If you only want to stop seeing a device without deleting anything, don't use this feature — retire or wipe it from the regular Intune device actions instead. **Do I need to rescan after removing a duplicate?** No — the list and any open duplicate group update automatically after a removal. ## Related Pages * [Device Compare](/intune-assistant/devices/device-compare) # Reports ## What Is This Section? The **Scripts** section of Intune Assistant gives you visibility into the PowerShell scripts deployed to your Windows devices through Microsoft Intune. It focuses specifically on **Remediation Scripts** (also known as health scripts or proactive remediations) — the most powerful scripting feature in Intune because they can both detect and fix device state automatically. Beyond simply listing the scripts that exist in your tenant, Intune Assistant goes further: when a detection script outputs structured JSON data, the platform automatically parses that output and presents it as a full, filterable, exportable report per script. This turns your remediation scripts into a lightweight, Intune-native device inventory and data collection system. ## What Is Available | Page | What It Does | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | [Health Scripts Report](broken://pages/c9781f25df440f7f7082778feee74a62d9cb8c05) | Browse all remediation scripts in your tenant and open a per-script device run-state report with dynamic JSON output columns | ## Why This Matters Microsoft Intune's remediation scripts are commonly used for fixing configuration issues. But they can do much more than that. Because the detection script can return any data via `Write-Output`, IT administrators use them to collect: * Installed browser extensions across all devices * Registry key values * Installed software inventory * Hardware specifications * Custom compliance data not available via built-in compliance policies Until now, accessing that data meant building your own pipeline: Log Analytics, Azure Monitor, custom scripts to extract the data from Graph. Intune Assistant removes that friction — the JSON output is surfaced directly in the interface, no extra infrastructure required. For more information on how to use remediation scripts for data collection, see [this learning page](https://learn.microsoft.com/en-us/intune/device-management/tools/deploy-remediations).\ For more information on how to create remediation scripts, see [this learning page](https://learn.microsoft.com/en-us/intune/device-management/tools/ref-remediation-scripts#powershell-scripts-for-remediations). Also there are a lot of great resources where remediation scripts are shared by the community. Here are a few: * [Jannik Reinhard](https://github.com/JayRHa/EndpointAnalyticsRemediationScripts) * [Sander Rozemuller](https://github.com/srozemuller/IntuneAutomation/tree/main/RemediationScripts) # Health Script Output ## What Is This Page? The **Health Scripts** page lists every Intune Remediation Script in your tenant. Clicking any script opens its **Device Run-State Report** — a per-device breakdown of the latest detection result, including the structured JSON output that the detection script wrote to standard output. This report is designed around one key idea: **the parsed output is the most important information**. The UI puts the JSON data columns first, so you see your actual device data immediately rather than having to scroll past status columns to find it. ## Background: What Are Remediation Scripts? Remediation scripts are deployed to Windows managed devices through Microsoft Intune as paired PowerShell scripts: | Script | Purpose | Exit Codes | | ---------------------- | ------------------------------------------- | ---------------------------------------------- | | **Detection script** | Checks a condition on the device | `exit 0` = compliant, `exit 1` = non-compliant | | **Remediation script** | Runs automatically when detection exits `1` | Any | Common use cases include: * Enforcing a registry key value * Removing stale or unwanted software * Fixing misconfigured local settings * Collecting hardware or software inventory data back to Intune Intune runs the detection script on a schedule you configure (every hour, every day, or once). The detection result — including any output the script wrote — is stored by Intune per device and accessible via Microsoft Graph. ## JSON Output: Turning Scripts Into Inventory Tools The detection script can write any data to standard output using PowerShell's `Write-Output`. When that output is **valid JSON**, Intune stores it as structured pre-remediation detection output. Intune Assistant automatically parses this and displays each JSON key as its own column in the report. This pattern is powerful for lightweight inventory collection without external logging infrastructure: ```powershell # Collect all installed browser extensions and return as JSON $extensions = @() Get-ChildItem 'HKCU:\Software\Google\Chrome\Extensions' | ForEach-Object { $extensions += [PSCustomObject]@{ extensionId = $_.PSChildName name = (Get-ItemProperty $_.PSPath).name version = (Get-ItemProperty $_.PSPath).version } } Write-Output ($extensions | ConvertTo-Json -Compress) exit 0 ``` Each item in the array becomes a row in the **Script Output** tab. The keys `extensionId`, `name`, and `version` become table columns automatically — no configuration required. ### Requirements for JSON output to appear | Requirement | Detail | | -------------------- | ------------------------------------------------------------------------------------------- | | Valid JSON only | Must be a JSON object `{}` or array `[...]`. Mixed text or invalid JSON produces no columns | | `Write-Output` | Must use `Write-Output`, not `Write-Host` (host stream is not captured by Intune) | | Script must have run | The device must have executed the script at least once | | Assignment required | The script must be assigned to a group that includes the device | ## The Report: Two Views When you click a script on the Health Scripts page, you arrive at the Device Run-State Report. The report has two tabs: ### Script Output tab *(default)* This is the primary view. It shows **one row per output item** — if a device's detection script returned an array of 12 browser extensions, that device contributes 12 rows to this tab. | Column | Description | | -------------------------- | -------------------------------------------------------------------------- | | **State** | Detection state badge (success / failed) | | **\[JSON output columns]** | One column per key found in any device's JSON output — auto-generated | | **Device** | Device name, user principal name, and OS version in a compact stacked cell | | **Last Updated** | When the detection last ran on this device | Rows from the same device share an alternating left-border colour stripe so you can visually group them without repeating the device name on every row. If a row has a script error, clicking it expands an inline error panel below the row. ### Device Overview tab This tab shows **one row per device** — useful when you want a status overview rather than the full data. | Column | Description | | ------------------- | ---------------------------------------- | | **Device** | Device name, user, OS version | | **Detection State** | Success / failed badge | | **Remediation** | Remediation state | | **Output Items** | How many JSON output items were returned | | **Error** | Whether the script produced an error | | **Last Updated** | Timestamp of the last run | Expanding a row shows the full parsed output as an inline mini-table, plus any script error message. ## Filtering Every badge in the filter strip at the top of the report is clickable and toggles a filter on or off: | Badge | Filter Applied | | ----------------- | -------------------------------------------- | | **N devices** | Clears all active filters | | **N success** | Shows only devices where detection succeeded | | **N failed** | Shows only devices where detection failed | | **N with output** | Shows only devices that returned JSON output | | **N no output** | Shows only devices with no JSON output | | **N with errors** | Informational only — not filterable | Multiple filters can be active simultaneously. A **Clear filters** link appears when any filter is active. ## Export The **Export** button in the top-right of the report header offers two export datasets: | Export option | Contents | Formats | | -------------------------- | -------------------------------------------------------- | -------------- | | **Export Script Output** | One row per output item, dynamic output columns included | CSV, PDF, HTML | | **Export Device Overview** | One row per device, output item count and error flag | CSV, PDF, HTML | Exports respect the active filters — only the currently visible data is exported. ## Example: Tenant-wide Browser Extension Inventory A common real-world use of this feature is collecting all installed browser extensions across managed devices. **Detection script:** ```powershell $results = @() # Chrome extensions if (Test-Path 'HKCU:\Software\Google\Chrome\Extensions') { Get-ChildItem 'HKCU:\Software\Google\Chrome\Extensions' | ForEach-Object { $results += [PSCustomObject]@{ browser = 'Chrome' extensionId = $_.PSChildName name = (Get-ItemProperty $_.PSPath).name version = (Get-ItemProperty $_.PSPath).version } } } # Edge extensions if (Test-Path 'HKCU:\Software\Microsoft\Edge\Extensions') { Get-ChildItem 'HKCU:\Software\Microsoft\Edge\Extensions' | ForEach-Object { $results += [PSCustomObject]@{ browser = 'Edge' extensionId = $_.PSChildName name = (Get-ItemProperty $_.PSPath).name version = (Get-ItemProperty $_.PSPath).version } } } Write-Output ($results | ConvertTo-Json -Compress) exit 0 ``` **What you see in Intune Assistant:** The Script Output tab shows columns: `browser`, `extensionId`, `name`, `version` — one row per extension per device. You can search for a specific extension name or ID across all devices instantly, filter to only devices that returned output, and export the full list to CSV for a complete tenant-wide extension audit. ## Limitations and Notes * **Windows only.** Remediation Scripts are a Windows feature. iOS, macOS, and Android devices do not appear in this report. * **Detection output only.** The report shows pre-remediation detection output. Remediation script output is not captured by Intune. * **Single run state per device.** Only the most recent run state is shown. Historical runs are not available via this report. * **Output size.** Intune limits detection script output size. Very large JSON arrays may be truncated. Keep individual output objects small. * **Structured output only.** Only valid JSON arrays or objects are parsed into columns. Free-text `Write-Output` is not shown as columns but does not cause an error — the row simply shows no output columns. ## # Extensions Oveview IntuneAssistant started as a community-driven tool—built to make Microsoft Intune more transparent, understandable, and easier to manage. What began as a way to explore and visualize configurations quickly gained traction among administrators who wanted more than just insights. As adoption grew, so did the requests. Organizations started asking for support on existing features, while Managed Service Providers (MSPs) highlighted the need for multi-tenant capabilities such as GDAP support. At the same time, many Intune administrators were looking for ways to go beyond visibility—towards automation, consistency, and real operational efficiency in their day-to-day work. That’s where **IntuneAssistant Extensions** come in. Extensions expand the core capabilities of IntuneAssistant by introducing advanced functionality and business logic designed for real-world scenarios. They enable you to: * Automate repetitive administrative tasks * Manage configurations at scale (such as bulk assignments) * Implement structured and repeatable processes * Schedule reports and monitor changes over time * Support multi-tenant and MSP-driven environments In short, Extensions transform Intune Assistant from an insight tool into an **execution and automation platform**—helping you move from “understanding your environment” to actively improving and controlling it. It's not an additions on the free community features but complete separate products that use the same Intune Assistant backend. Whether you’re managing a single tenant or operating across multiple customers, Extensions provide the building blocks to scale your Intune operations with confidence. ### Jump right in

:user-robot:

WorkerRunning tasks at your sideWorker

:arrows-down-to-people:

Assignments ManagerBulk assign using update ringsAssignments Manager

:rectangle-history-circle-plus:

MSP SupportAdd GDAP to the productMSP Support
{% hint style="info" %} **Why Extensions exist**\ IntuneAssistant started as a free community tool—and it will stay that way. But supporting users, maintaining features, and building solutions with business logic that truly help in daily operations takes time and effort. Extensions make it possible to keep improving the platform for the community while offering support and advanced functionality where it matters most. {% endhint %} # Assignments Manager ## Assignments Manager {% hint style="success" %} **Enterprise Feature** — This extension is available exclusively on the Enterprise license. Once activated, it becomes available in your frontend. {% endhint %} ### Overview Microsoft Intune assignment management is built for MSP\`s and enterprises (single and multi tenant). Assignments Manager standardizes, monitors, and validates policy assignments at scale with bulk-driven automation. ## Assignment Manager Standardize Microsoft Intune assignments across multiple tenants or complex enterprise environments from a single desired state file. Deploy, monitor, and maintain consistent assignments at scale with CSV-driven automation. * Multi-tenant & enterprise scale\ Deploy consistent assignment patterns across customer tenants (MSPs) or business units (enterprises). * Continuous compliance monitoring\ Validate assignments against your desired state CSV and catch configuration drift before it impacts users. * Enterprise-grade automation\ Bulk operations, safety validations, and audit trails designed for production environments. Perfect for MSPs and Large Enterprises Keep all your customers (multi tenant) "between the lines" by checking assignments using desired state files. *** ### Primary use cases Many MSPs use 'shipping ' tools to send policies from a baseline tenant to an edge tenant.\ See Assignments Manager as an extension at the top of that 'shipping' tool. So there is a baseline tenant that sends default policies to a tenant.\ \ Assignments Manager allows you to be very flexible to assign the shipped policies at the customer level at the time you want. #### For Managed Service Providers (MSPs) * **Standardize Intune assignments** across multiple customer tenants * **Monitor assignment drift** across your customers' tenants * **Automate desired state configuration** for new customers * **Scale operations** without manual work that doesn't scale *** ### What makes this different Unlike traditional assessment tools that only report what exists, Assignment Manager helps you **maintain** the desired state: * **Deploy** standardized assignments from your CSV templates * **Monitor** assignments compliance against your desired configuration * **Correct** drift when assignments don't match expectations Beyond assessment tools Most tools tell you what's there. This tool ensures that what **should** be there actually **stays** there. *** ### Quick start workflow This workflow is a widely use process {% stepper %} {% step %} ### Create your CSV template Create a bulk export of the needed policies using the Assignments Overview page. {% endstep %} {% step %} ### Open Assignment Manager Go to **Extensions → Assignment Manager** {% endstep %} {% step %} ### Upload CSV Upload your CSV to see what needs to change {% endstep %} {% step %} ### Review comparison Review the comparison against current tenant state {% endstep %} {% step %} ### Apply changes Apply changes and validate results {% endstep %} {% step %} ### Reuse template **Reuse the same CSV** across other tenants or environments {% endstep %} {% endstepper %} Template-driven consistency Develop your assignment templates once, then deploy them consistently across your entire infrastructure. *** ### Screenshots *** *** ### Multi-Admin Approval (MAA) {% hint style="warning" %} If your tenant has **Multi-Admin Approval** enabled for configuration policies, compliance policies, or scripts, the Assignments Manager will show an amber warning banner and all write operations will fail until the IntuneAssistant enterprise app is excluded. {% endhint %} Microsoft Intune's Multi-Admin Approval feature enforces a four-eyes principle for policy changes — including changes made via the Graph API by automation tools. When MAA is active and the IntuneAssistant backend API enterprise app is not excluded, every assignment change attempted through the Assignments Manager is rejected by Microsoft Graph with: ``` Header 'x-msft-approval-justification' is required to request approval. ``` This is not a permissions error — it is MAA blocking the call entirely. The change is not queued for approval; it simply fails. **To fix it:** add the IntuneAssistant enterprise app (`afe66ddf-67d4-4d61-8a51-beca7b799f52`) to the **App Exclusions** list of each active MAA policy in **Tenant administration → Multi Admin Approval**. [Multi-Admin Approval — full guide and step-by-step instructions](/extensions/assignments-manager/multi-admin-approval) *** ### Next steps [Create assignments template\ Learn how to create standardized assignment templates from existing tenant configurations or craft new ones from scratch.](/extensions/assignments-manager/intune-assignments/create-assignment-templates) [How it works\ The workflow: template → deploy → monitor → maintain across environments.](/extensions/assignments-manager/intune-assignments/workflow) [Needed Permissions\ Complete guide to configuring granular permissions for Intune Assistant users](/security-and-compliance/needed-permissions) [Needed Permissions\ Complete guide to configuring permissions for the Intune Assistant Assignments Manager extension](/extensions/assignments-manager/intune-assignments/needed-permissions) [Multi-Admin Approval (MAA)\ How to handle MAA policies and exclude IntuneAssistant to keep the Assignments Manager operational.](/extensions/assignments-manager/multi-admin-approval) # Intune Assignments # Workflow ExtensionsAssignments Manager ## Workflow Upload → Compare → Select → Validate. A safe workflow for bulk Intune policy assignment changes. For details: Assignment Manager is built around a **safety-first workflow**. You always see what will change *before* you execute anything—and you always validate after. Four-step workflow Upload your desired state in CSV, compare it with the live tenant, choose what to apply, then validate and export results. {% stepper %} {% step %} ### 1) Upload CSV Provide a CSV describing the assignment changes. ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Windows Security Baseline;Finance Department;Include;Add;; iOS Compliance Policy;All Users;Include;Replace;Corporate Devices;Include Android App Protection;Sales Team;Include;Remove;; ``` During upload, the tool validates: * Required columns & data types * Obvious conflicts (duplicate rows, invalid actions, etc.) If the upload check finds issues, you get immediate feedback to fix them. Only the valid rows are processed in the next step.\ To fix the errors, update your CSV and re-upload. {% endstep %} {% step %} ### 2) Compare (Current vs Planned) Each row is evaluated against the live tenant state, so you get a precise preview. **Status compare indicators:** * **Ready for migration** – Row is ready to implement changes * **Already migrated** – Row is already in the desired state * **Check errors** - Row has issues that need fixing before migration. This can due an non existing policy/group, invalid filter, or duplicate policy names. Correct the CSV and re-upload to fix. That means, provide a group that actually exists in Azure AD, or a policy that is already created in Intune. If the group or policy doesn't exist, you can also choose to create it first. Then, after creation, upload the CSV again and start over. {% endstep %} {% step %} ### 3) Select changes (Selective Migration) You decide exactly what is applied. * Select/deselect operations * Batch multiple policies in one run Recommended for safety Start with a small pilot CSV, then scale up. {% endstep %} {% step %} ### 4) Migrate + Validate Did you reach the desired state? After migration, Assignment Manager validates the final state: * Assignments exist as expected * Filters are applied correctly * Conflicts are detected and surfaced * Results are summarized and exportable {% endstep %} {% endstepper %} *** ### Best-practice patterns #### Use Replace for clean migrations When moving from one target strategy to another, **Replace** avoids leftover assignments. #### Keep CSVs in version control Treat migrations as change-controlled artifacts. #### Use filters for exclusions (when possible) Excluding via filters is usually cleaner than managing parallel exclusion groups. *** Create Assignment Templates\ Learn how to create CSV templates for bulk assignment management - manually or by exporting from your reference tenant.\ Scenarios\ Bulk manage Microsoft Intune policy assignments using CSV files (add, remove, replace) across tenants.\ # Assignment Sessions ## Assignment Sessions Every time you run the Assignments Manager's Migrate step, Assignment Sessions keeps a permanent record of it: what you uploaded, what was compared, what you selected, what actually happened per row, and — once Intune's own audit log catches up — the real Microsoft Intune audit entry for each change. Before this feature, the results table at the end of a migration run was the only place to see what happened, and it disappeared the moment you left the page or refreshed. Assignment Sessions keeps it. *** ### How to use it {% stepper %} {% step %} ### Open Assignment Sessions Go to **Extensions → Assignment Manager → Assignment Sessions**. {% endstep %} {% step %} ### Browse the sessions list Every past Migrate run is listed with when it started, who ran it, how many rows it touched, and its success rate. {% endstep %} {% step %} ### Open a session Click any row to see the full detail: every policy/group change in that run, its result, and its Intune audit log match. {% endstep %} {% endstepper %} *** ### What you'll see **The sessions list** shows one row per Migrate run: * Start time and who ran it * Total rows in the run * Success rate * Overall status — Completed, Partially failed, or Failed **The session detail page** shows: * A summary of what was compared before you selected anything — how many rows were checked, how many were ready to migrate, and how many were already in the desired state * A summary of the post-migration verification, if you ran one * For every executed row: which policy and group were affected, and what action was taken (add, remove, replace) * Whether it succeeded or failed, and the error message if it failed * Its match against Microsoft Intune's own audit log — once found, you can see the exact activity Intune recorded (its activity type, result, and the properties it changed) {% hint style="info" %} A session covers one full run through Compare, Select, Migrate, and (if you run it) Validate — not just the Migrate step. If you compare a CSV but never migrate anything, that preview doesn't create an entry in the sessions list; nothing is recorded until you actually apply at least one change. {% endhint %} {% hint style="info" %} **The Intune audit match can take a few minutes to appear.** Intune Assistant checks for the matching entry in Microsoft's own audit log each time you open or refresh the session detail page — it isn't available the instant a migration finishes. A row shows "Checking..." for up to about 10 minutes after it ran, then "No match found" with a **Check again** button if nothing turned up by then. {% endhint %} *** ### Requirements Available to anyone who can use the Assignments Manager — no separate license or permission is needed beyond what Assignments Manager itself already requires. *** ### Common questions **Why doesn't a row have an Intune audit match yet?**\ Intune's audit log isn't instant — it can take a few minutes for a change to show up there after Intune Assistant makes it. Reopen or refresh the session detail page after a few minutes; each visit checks again automatically. **Why did a row never get an Intune audit match?**\ Occasionally Intune's own audit log doesn't retain a matching entry for a specific change, or the automatic check window (about 10 minutes) closed before anything showed up. The row's own result (success/failure) is still accurate either way — only the cross-reference to Intune's audit log is missing. Use the **Check again** button on the row to try once more at any time. **Does this replace the results I already see right after a migration?**\ No — it's the same information, just kept permanently. The in-page results at the end of a Migrate run are unchanged; Assignment Sessions is where that same information lives afterward. **Can I export a session?**\ Not yet — this first version is view-only. # Needed Permissions ## Needed Permissions Complete guide to configuring permissions for the Intune Assistant Assignments Manager extension [Permissions Overview](#permissions-overview) Learn how to configure the required permissions for the Intune Assistant Assignments Manager extension and how to set up granular permissions for users in your organization. ### [Required Graph API Permissions](#required-graph-api-permissions) The Assignments Manager extension requires the following Microsoft Graph API permissions to function properly: | Permission | Type | Description | | --------------------------------------------- | --------- | ---------------------------------------------------------- | | `DeviceManagementConfiguration.ReadWrite.All` | Delegated | Read and write Intune configuration profiles and baselines | | `DeviceManagementApps.ReadWrite.All` | Delegated | Read and write managed applications and app configurations | | `DeviceManagementServiceConfig.ReadWrite.All` | Delegated | Read and write device management service configuration | | `DeviceManagementScripts.ReadWrite.All` | Delegated | Read and write PowerShell and shell scripts | | `Group.Read.All` | Delegated | Read group memberships and properties | The Assignments Manager extension requires **ReadWrite** permissions to modify policy assignments, group assignments, and filters in your Intune tenant. ### [Configuring Granular User Permissions](#configuring-granular-user-permissions) Instead of giving users full Intune Administrator permissions, you can configure granular role-based access control (RBAC) permissions for the Assignments Manager functionality. #### [Understanding Intune RBAC](#understanding-intune-rbac) Microsoft Intune uses role-based access control to determine what actions users can perform. Each role contains: * **Permissions**: What actions can be performed * **Scope**: Which resources the role applies to * **Assignments**: Which users or groups have the role #### [Required Intune Roles for Assignments Manager](#required-intune-roles-for-assignments-manager) Users need roles with **read and write permissions** for the following categories: [**Policy and Profile Manager**](#policy-and-profile-manager) Allows reading and modifying device configuration profiles and compliance policies. **Required permissions:** * Device configuration policies: **Read, Create, Update, Delete, Assign** * Device compliance policies: **Read, Create, Update, Delete, Assign** * Device enrollment: **Read** [**Application Configuration Manager**](#application-configuration-manager) Allows reading and modifying application management data. **Required permissions:** * Mobile applications: **Read, Create, Update, Delete, Assign** * Mobile application management policies: **Read, Create, Update, Delete, Assign** [**Script Manager**](#script-manager) Allows reading and modifying PowerShell and shell scripts. **Required permissions:** * Device management scripts: **Read, Create, Update, Delete, Assign** [**Group Reader**](#group-reader) Allows reading group information for assignment purposes. **Required permissions:** * Groups: **Read** #### [Creating a Custom Role](#creating-a-custom-role) For optimal security, create a custom role with only the required permissions: {% stepper %} {% step %} ### Navigate to Microsoft Intune admin center * Go to [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) * Select **Tenant administration** > **Roles** > **All roles** {% endstep %} {% step %} ### Create new role * Click **Create** * Enter role name: `Intune Assignments Manager` * Add description: `Manage assignments for Intune policies, apps, and scripts` {% endstep %} {% step %} ### Configure permissions * **Device configuration policies**: Read, Create, Update, Delete, Assign ✓ * **Device compliance policies**: Read, Create, Update, Delete, Assign ✓ * **Mobile applications**: Read, Create, Update, Delete, Assign ✓ * **Mobile application management policies**: Read, Create, Update, Delete, Assign ✓ * **Device management scripts**: Read, Create, Update, Delete, Assign ✓ * **Organization**: Read ✓ {% endstep %} {% step %} ### Set scope and assignments * Define which users/groups should have this role * Set appropriate scope tags if needed {% endstep %} {% endstepper %} #### [Built-in Roles Alternative](#built-in-roles-alternative) If you prefer using built-in roles, assign users to: * **Intune Service Administrator** (full read/write access) * **Application Administrator** (for app-related assignments only) Recommended approach We recommend creating a custom role with only the required assignment permissions to follow the principle of least privilege. ### [Assignment Operations](#assignment-operations) The Assignments Manager extension performs the following operations: #### [Policy Assignment Management](#policy-assignment-management) * **Assign policies** to groups with include/exclude logic * **Remove assignments** from existing policies * **Modify assignment filters** and conditions * **Bulk assignment operations** across multiple policies #### [Application Assignment Management](#application-assignment-management) * **Assign applications** to users and devices * **Configure installation requirements** and deadlines * **Manage app protection policies** assignments * **Handle app configuration** policy assignments #### [Script Assignment Management](#script-assignment-management) * **Assign PowerShell scripts** to device groups * **Configure script execution** parameters * **Manage shell scripts** for macOS devices Assignment impact Changes made through the Assignments Manager directly affect your production environment. Always test in a non-production environment first. ### [Troubleshooting](#troubleshooting) Common permission issues: | Issue | Solution | | -------------------------- | -------------------------------------------------------------------- | | Cannot modify assignments | Verify user has ReadWrite permissions for the specific resource type | | Assignment operations fail | Check if user has "Assign" permission in their Intune role | | Cannot see target groups | Ensure `Group.Read.All` permission is granted | | Script assignments fail | Verify `DeviceManagementScripts.ReadWrite.All` permission | ### [Consent missing](#consent-missing) The Assignments Manager requires admin consent for the Graph API permissions. Ensure that a Global Administrator has granted consent for the application in your tenant. New features may require additional permissions. If required consent is missing, you will be notified. Then run the consent process again. For information about that process, check the [Managing Admin Consent](broken://pages/3285781e772e72eb9ead78862e26a5bfe729c13e) documentation. ### [Security Considerations](#security-considerations) When granting permissions for the Assignments Manager: * **Limit scope** using scope tags to restrict access to specific organizational units * **Regular auditing** of assignment changes through Intune audit logs * **Monitor usage** to ensure permissions are being used appropriately * **Implement approval workflows** for critical assignment changes ### [Additional Resources](#additional-resources) * [Microsoft Intune RBAC Reference](https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control-reference) * [Create custom roles in Intune](https://learn.microsoft.com/en-us/intune/fundamentals/create-custom-role) * [Scope tags for distributed IT](https://learn.microsoft.com/en-us/intune/fundamentals/scope-tags) * [Intune assignment filters](https://learn.microsoft.com/en-us/intune/fundamentals/filters) Best practice Regularly review assignment changes and audit logs to ensure the Assignments Manager is being used according to your organization's policies. [Overview\ \ Microsoft Intune assignment management built for MSPs and enterprises. Standardize, monitor, and validate policy assignments at scale with CSV-driven automation.](/extensions/assignments-manager) [Create Assignment Templates\ \ Learn how to create CSV templates for bulk assignment management - manually or by exporting from your reference tenant.](/extensions/assignments-manager/intune-assignments/create-assignment-templates) # Backup & Restore ExtensionsAssignments Manager ## Backup & Restore How to backup policy assignments before migration and restore them if needed using the Assignment Manager. ## [Backup & Restore Assignments](#backup--restore-assignments) Before making any assignment changes, Assignment Manager provides a built-in backup system to ensure you can always restore to the previous state if needed. {% hint style="info" %} Safety first approach The backup feature creates a complete snapshot of your current assignment state before any migration begins. {% endhint %} *** ### [Creating Backups](#creating-backups) {% stepper %} {% step %} ### Start the Backup Process Before any migration, click the **"Backup Ready Policies"** button in the Assignment Manager interface. This backs up ALL policies in your tenant The backup process will: * Export all policy assignments * Include assignment filters and targeting * Package everything into a downloadable ZIP file {% endstep %} {% step %} ### Download & Store the Backup Once the backup completes, download the ZIP file to a secure location. **Recommended naming convention:** ``` policy-backups_tenantID_-YYYY-MM-DD-HHMMSS.zip Example: intune-backup-2024-01-15-143022.zip ``` {% hint style="warning" %} Important Store backups in a version-controlled location or secure file share. You may need them weeks or months later. {% endhint %} {% endstep %} {% endstepper %} *** ### [Understanding Backup Contents](#understanding-backup-contents) The backup ZIP contains JSON files for each policy with complete assignment information. After extracting the ZIP, you'll see a folder structure like this: Each JSON file contains: * Policy metadata and settings * All current group assignments * Applied filters (include/exclude) * Assignment targeting details *** ### [Restoring Assignments](#restoring-assignments) {% stepper %} {% step %} ### Identify the Policy to Restore Extract the backup ZIP file and locate the specific policy you need to restore. **Navigate through the folder structure:** * `compliance-policies/` - Compliance policies * `configuration-profiles/` - Device configuration profiles * `app-protection/` - App protection policies {% endstep %} {% step %} ### Access the Microsoft Intune Portal Currently, restoration must be done through the Microsoft Intune admin center: 1. Open [Microsoft Intune admin center](https://endpoint.microsoft.com/) 2. Navigate to the appropriate policy section 3. Locate the policy you want to restore assignments for Why manual restoration? Direct restoration through Assignment Manager is planned for future releases. Manual import ensures you have full control over what gets restored. The exported policies are raw JSON data directly from Intune, making it easy to re-import. Be aware that when uploading the JSON file to the Intune Portal will create a new policy with a new policy ID. That means you have to remove the old policy after the new one is created. {% hint style="info" %} Coming soon We are currently working on a direct restore functionality to avoid this extra step in the future. {% endhint %} {% endstep %} {% endstepper %} *** ### [Best Practices](#best-practices) #### [Backup Strategy](#-backup-strategy) **Before every migration:** * Always create a fresh backup using the backup button * Store in a secure, accessible location #### [Recovery Planning](#-recovery-planning) **Document your restore process:** 1. Which policies were changed 2. What the previous state looked like 3. Who can perform emergency restores 4. How to validate successful restoration **Test your backups:** * Periodically validate backup file integrity * Practice restoration procedures in test environments * Ensure team members know the restoration process *** ### [Troubleshooting](#troubleshooting) #### [Backup Issues](#backup-issues) **Backup takes too long:** * Large tenants may require 10+ minutes * Don't close the browser during backup * Consider backing up policy types separately **Backup file is empty or corrupt:** * Check browser download settings * Verify sufficient permissions in Intune. Check the [permissions documentation](broken://pages/4ec5831c39215df186b8fa9c2ed2c53b73c620e0). * Try again during low-usage periods #### [Restoration Issues](#restoration-issues) **Can't find the right policy in backup:** * Search by display name in the JSON files * Check policy type folders carefully * Use the policy GUID if display names changed **Assignments don't match after restore:** * Verify group names haven't changed * Check if filters still exist with same names * Confirm you have the right backup version *** ### [Future Enhancements](#future-enhancements) Coming soon * **Direct restore functionality** - Import backup files directly through Assignment Manager without manual portal work. * **Selective restore** - Choose specific assignments to restore rather than full policy restoration. * **Automated validation** - Automatic comparison between backup and current state. *** ### [Related Documentation](#related-documentation) * [Assignment Migration Overview](/extensions/assignments-manager) * [How Assignment Manager Works](/extensions/assignments-manager/intune-assignments/workflow) * [CSV Format Reference](broken://pages/5b8e7f2b62f45e320eeecfec69208bdbd637881c) [Scenarios\ \ Bulk manage Microsoft Intune policy assignments using CSV files (add, remove, replace) across tenants.](/extensions/assignments-manager/intune-assignments/supported-scenarios) [Multi-Tenant Overview\ \ How Intune Assistant supports MSPs with GDAP-enabled multi-tenant management](/extensions/msp-support/overview) # Supported scenarios ## Scenarios Bulk manage Microsoft Intune policy assignments using CSV files (add, remove, replace) across tenants. ### Overview We have tested various common scenarios for managing Microsoft Intune policy assignments using the Assignments Manager. This guide provides detailed examples and explanations for each scenario, helping you understand how to effectively use the tool for your specific needs. Assignments Manager allows you to manage Microsoft Intune policy assignments in bulk using CSV files and reach a desired assignment state for your policies. You can add, remove, replace, or clear assignments for policies across different tenants. *** ### Supported Operations The tool supports four primary actions: * **Add** - Add new assignments to existing policies * **Remove** - Remove specific assignments from policies * **Replace** - Replace all existing assignments with new ones * **Update** - Updates the current assignment row * **NoAssignment** - Remove all assignments using the NoAssignment action ### Supported Resources Currently, the resources below are supported and tested by the team. The team tested these policies with the supported operations described above. | Platform | Intune Resource | | ------------- | ----------------------------------------------------- | | All platforms | Settings Catalog | | | Compliance Policiy | | Android | App Protection Policy | | | Android Enterprise - Device Restrictions Device Owner | | | Android Enterprise - Device Restrictions Work Profile | | | App Configuration Policy | | iOS & iPad OS | App Configuration Policy | | | App Protection Policy | | | Device Features Policy | | | Device Restrictions | | macOS | Custom Configuration Policy | | | Shell Scripts | | Windows | Autopilot Deployment Profiles | | | Custom Configuration Profiles | | | Device Restriction Profiles | | | Driver Updates | | | Feature Updates | | | Kiosk Profiles | | | Platform Scripts | | | Proactive Remediation Scripts | | | Quality Updates | | | Windows Health Monitoring Profiles | {% hint style="info" %} The team successfully tested the resources above.\ Missing resources in the list are **not** supported. They could work, but we are not responsible for any misconfiguration on that side.\ \ If they work, we are glad to hear so we can update our support list.\ We take new or unknown resources very seriously. We strive to get every resource in the product before you hit an unknown resource. If you are ahead, please let us know so we can add the resource.\ \ For both situations, please create a [GitHub issue](https://github.com/srozemuller/IntuneAssistant/issues) to add that resource to the list. {% endhint %} ### Assignment Types {% stepper %} {% step %} #### Group Assignments Assign policies to specific Entra ID groups. CSV Format: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;Finance Department;Include;Add;; ``` Result: Policy is assigned to all members of the "Finance Department" group. {% endstep %} {% step %} #### All Users Assign policies to all licensed users in your tenant. CSV Format: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Policy;All Users;Include;Add;; ``` Result: Policy applies to every user with an Intune license. {% endstep %} {% step %} #### All Devices Assign policies to all devices enrolled in Intune. CSV Format: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Device Compliance;All Devices;Include;Add;; ``` Result: Policy applies to all enrolled devices regardless of user. {% endstep %} {% endstepper %} *** ### Assignment Actions #### Add Action Adds new assignments **without removing** existing ones. **Scenario: Add Group Assignment** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Baseline;IT Admins;Include;Add;; ``` Before: * Policy has "All Users" assignment After: * Policy has "All Users" assignment * Policy has "IT Admins" group assignment *** **Scenario: Add Assignment with Exclusion Group** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType App Protection;All Users;Include;Add;; App Protection;Test Users;Exclude;Add;; ``` Result: * Policy assigned to all users * Test Users group included separately (can be excluded via filters) *** #### Remove Action Removes specific assignments **without affecting** others. **Scenario: Remove Included Group Assignment** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Old Policy;Finance Team;Include;Remove;; ``` Before: * Policy assigned to: "Finance Team", "Sales Team", "All Devices" After: * Policy assigned to: "Sales Team", "All Devices" * "Finance Team" assignment removed **Scenario: Remove Excluded Group Assignment** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Old Policy;Excluded IT Team;Exclude;Remove;; ``` Before: * Policy assigned to: "Finance Team", "Sales Team", "All Devices" and excluded "Excluded IT Team" After: * Policy assigned to: "Finance Team", "Sales Team", "All Devices" * "Excluded IT Team" exclusion removed *** **Scenario: Remove All Users Assignment** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Pilot Policy;All Users;Include;Remove;; ``` Before: * Policy assigned to "All Users" After: * Policy has no assignments *** #### Replace Action Removes **all existing assignments** and adds the new one(s). **Scenario: Replace Group with Another Group** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Policy;New Security Group;Include;Replace;; ``` Before: * Policy assigned to: "Old Group A", "Old Group B", "All Users" After: * Policy assigned to: "New Security Group" only *** **Scenario: Replace Multiple Assignments with All Devices** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Device Config;All Devices;Include;Replace;; ``` Before: * Policy assigned to: "Group 1", "Group 2", "Group 3" After: * Policy assigned to: "All Devices" only #### Update Action Updates the current assignment row. **Scenario: Replace filter for another** The current assignment at policy name Security Policy with group Security Group, no filter.\ To update that work to include a filter use **Update.** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Policy;Security Group;Include;Update;FilterForWindows;Include ``` Before: * Policy assigned to: "SecurityGroup (no filter)" After: * Policy assigned to: "Security Group" with filter include FilterForWindows **Scenario: Remove filter** The current assignment at policy name Security Policy with group Security Group, with included filter FilterForWindows.\ To update that work to include a filter use **Update.** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Policy;Security Group;Include;Update;; ``` Before: * Policy assigned to: "Security Group" with filter include FilterForWindows After: * Policy assigned to: "SecurityGroup (no filter)" #### Clear (NoAssignment) Action Removes **all existing assignments** from the policy. **Scenario: Clear All Assignments** CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Obsolete Policy;; ;NoAssignment;; ``` Before: * Policy assigned to: "Group A", "Group B", "All Users" After: * Policy has no assignments *** ### Assignment Filters Assignment filters allow you to include or exclude devices based on device properties. #### Filter Types * **Include** - Apply policy only to devices matching the filter * **Exclude** - Apply policy to all devices except those matching the filter #### Filter Platform Matching Important Assignment Filter platform must match the policy platform. | Policy Platform | Compatible Filter Platform | | -------------------------------------------- | -------------------------- | | Windows10AndLater, Windows8AndLater, Windows | Windows | | iOS | iOS | | Android | Android | | macOS | macOS | *** #### Scenario: Add Assignment with Include Filter CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Windows Compliance;All Devices;Include;Add;Windows 11 Only;Include ``` Result: * Policy assigned to all devices * Only applied to devices matching "Windows 11 Only" filter *** #### Scenario: Add Assignment with Exclude Filter CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Baseline;All Users;Include;Add;Test Devices;Exclude ``` Result: * Policy assigned to all users * Not applied to devices matching "Test Devices" filter *** #### Scenario: Remove Assignment with Specific Filter CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType App Config;Sales Team;Include;Remove;VIP Devices;Exclude ``` Before: * Policy assigned to "Sales Team" with "VIP Devices" (Exclude) * Policy assigned to "Sales Team" without filter After: * Only the assignment with the matching filter is removed * Assignment without filter remains *** ### Common Scenarios #### Scenario 1: Migrate Policy from One Group to Another Goal: Move policy from "Pilot Users" to "All Users" CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType New Feature Policy;All Users;Include;Replace;; ``` Result: All previous assignments removed, policy now assigned to "All Users" *** #### Scenario 2: Add Exclusion to Existing Assignment Goal: Keep current assignments but exclude test devices CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Compliance Policy;All Devices;Exclude;Add;Test Devices;Exclude ``` Result: Policy applies to all devices except those matching "Test Devices" filter *** #### Scenario 3: Change Filter Direction Goal: Change from excluding test devices to including only production devices CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Security Policy;All Devices;Include;Replace;Production Devices;Include ``` Result: All previous assignments removed, policy now applies only to production devices *** #### Scenario 4: Batch Migration Multiple Policies CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Policy A;Finance Team;Include;Replace;; Policy B;Finance Team;Include;Replace;; Policy C;Finance Team;Include;Replace;; Policy D;All Users;Include;Replace;; ``` Result: Multiple policies migrated to new assignments in one operation *** #### Scenario 5: Replace and Add Exclusion Goal: Replace assignment and immediately add exclusion group CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType App Protection;All Users;Include;Replace;; App Protection;Excluded Users;Exclude;Add;; ``` Processing Order: {% stepper %} {% step %} Replace removes all assignments and adds "All Users" {% endstep %} {% step %} Add includes "Excluded Users" group {% endstep %} {% endstepper %} Note This creates two assignments — you may want to use filters instead for exclusions. *** #### Scenario 6: Clear All Assignments from Multiple Policies CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Old Policy 1;; ;NoAssignment;; Old Policy 2;; ;NoAssignment;; Old Policy 3;; ;NoAssignment;; ``` Result: All assignments removed from specified policies *** #### Scenario 7: Implement new policies (Update ring 1) for Pilot Group only CSV: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Production policy - v1 ;Pilot Group;Exclude;Add;; New production policy - v1.1 ;Pilot Group;Include;Add;; ``` This will keep the existing production policy for all users but exclude the pilot group. The new production policy will be assigned only to the pilot group. *** ### Validation Rules #### Rule 1: Cannot Mix All Users/All Devices with Groups Invalid Cannot mix **All Users / All Devices** with group assignments in the same policy batch. ❌ Invalid: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;All Users;Include;Add;; My Policy;Finance Team;Include;Add;; ``` Error: "Cannot mix 'All Users' with group assignments" ✅ Solution (use Replace): ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;All Users;Include;Replace;; ``` *** #### Rule 2: Filter Platform Must Match Policy Platform ❌ Invalid: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Windows Security Baseline;All Devices;Include;Add;iOS Device Filter;Include ``` Error: "Filter platform 'iOS' does not match policy platform 'Windows'" ✅ Valid: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Windows Security Baseline;All Devices;Include;Add;Windows 11 Filter;Include ``` *** #### Rule 3: Cannot Have Conflicting Actions in Same Batch ❌ Invalid: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;Finance Team;Include;Add;; My Policy;Finance Team;Include;Remove;; ``` Error: "Conflicting assignment actions detected for the same assignment" Reason: Adding and removing the same assignment in one batch creates a conflict. *** #### Rule 4: Cannot Add Same Assignment with Different Filters ❌ Invalid: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;IT Team;Include;Add;Filter A;Include My Policy;IT Team;Include;Add;Filter B;Exclude ``` Error: "Conflicting filter types for the same assignment" Reason: Same group cannot have both Include and Exclude filters simultaneously. *** ### Best Practices #### 1. Test Before Production Always test your CSV with a small subset of policies first: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Test Policy 1;Test Group;Include;Add;; ``` #### 2. Use Replace for Clean Migrations When migrating policies, use **Replace** to avoid orphaned assignments: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Production Policy;Production Users;Include;Replace;; ``` #### 3. Verify Group Names Ensure group names match exactly (case-sensitive): ❌ `finance team` ≠ `Finance Team` ✅ `Finance Team` = `Finance Team` #### 4. Check Filter Names Filter names must exist in your tenant before migration: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;All Devices;Include;Add;Corporate Devices;Include ``` Verify "Corporate Devices" filter exists first. #### 5. Batch Similar Operations Group similar operations together: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Policy 1;Finance;Include;Replace;; Policy 2;Finance;Include;Replace;; Policy 3;Finance;Include;Replace;; ``` #### 6. Order of Operations When using multiple actions, they execute in CSV row order: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType My Policy;All Users;Include;Replace;; My Policy;Excluded Group;Exclude;Add;; ``` Result: {% stepper %} {% step %} Replace removes all assignments and adds "All Users" {% endstep %} {% step %} Add includes "Excluded Group" {% endstep %} {% endstepper %} *** ### MSP Scenario Examples #### New Customer Onboarding (MSPs) You have used other tools like Inforcer, Coreview or just added all those policies manually in a customer tenant. Now you can use the Assignments Manager to user your standardized assignment template from your pilot tenant and use it for future customers. ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Windows Security Baseline;All Devices;Include;Replace;; iOS Compliance Policy;All Users;Include;Replace;; Android App Protection;All Users;Include;Replace;; BYOD Compliance;All Users;Include;Replace;Corporate Devices;Exclude ``` *** #### Pilot to Production Migration You have new policies added to a tenant and want to test it in a pilot group first. ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Old Feature Policy;Pilot Group;Exclude;Add;; New Feature Policy;Pilot Group;Include;Add;; ``` *** ### Error Messages | Error Message | Cause | Solution | | ----------------------------- | ------------------------------------ | ------------------------------- | | "Policy not found" | Policy name doesn't exist | Verify policy name spelling | | "Group not found" | Group name doesn't exist | Check Entra ID group name | | "Filter not found" | Filter name doesn't exist | Verify assignment filter exists | | "Platform mismatch" | Filter platform ≠ policy platform | Use matching platform filter | | "Cannot mix assignment types" | Mixing All Users/Devices with groups | Use Replace action | | "Conflicting actions" | Same assignment has Add + Remove | Remove duplicate | *** ### Examples by Policy Type #### Configuration Policies ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Windows Update Policy;All Devices;Include;Replace;Production Devices;Include Windows Update Policy;Test Devices Group;Include;Add;Test Device Filter;Exclude ``` #### Compliance Policies ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Device Compliance - iOS;All Users;Include;Replace;; Device Compliance - iOS;Executives;Include;Add;VIP Devices;Include ``` #### App Protection Policies ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType MAM Policy - Android;All Users;Include;Replace;; MAM Policy - Android;BYOD Users;Include;Add;Personal Devices;Exclude ``` #### Security Baselines ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;FilterName;FilterType Windows Security Baseline v2;All Devices;Include;Replace;Managed Devices;Include ``` *** ### FAQ
Q: What happens if I add the same assignment twice? A: The operation is idempotent - only one assignment is created.
Q: Can I remove an assignment that doesn't exist? A: No, during compare phase it checks if the assignment exists. If it doesn't exist it is not ready for migration.
Q: Can I use Replace multiple times in one CSV? A: Yes, but each Replace overwrites the previous one for that policy.
Q: Can I migrate assignments between tenants? A: No, group and filter names must exist in the target tenant.
Q: What happens if a filter name is wrong? A: Error: "Assignment filter not found" - operation fails for that row.
*** ### Support {% stepper %} {% step %} Verify CSV format matches examples above {% endstep %} {% step %} Check validation rules section {% endstep %} {% step %} Review error messages table {% endstep %} {% step %} Contact your system administrator {% endstep %} {% endstepper %} # Create Assignment Templates ## ExtensionsAssignments Manager ## Create Assignment Templates Learn how to create CSV templates for bulk assignment management - manually or by exporting from your reference tenant. Assignment Manager uses CSV files to define your desired assignment state. You can create these templates in two ways: manually from scratch or by exporting from an existing reference tenant. *** ### Method 1: Manual CSV Creation Create your own CSV file from scratch using any spreadsheet application or text editor. Download Blank Template Start with a ready-to-use template: #### When to use manual creation * **New standardization projects** - Building fresh assignment patterns * **Custom requirements** - Need specific assignment combinations * **Template-driven approach** - Creating reusable templates for multiple tenants * **Precise control** - Want to define exact assignment states #### Getting started {% stepper %} {% step %} Create a new CSV file with semicolon separators (or download here: ) {% endstep %} {% step %} Add the required column headers {% endstep %} {% step %} Define your desired assignment states row by row {% endstep %} {% step %} Save and upload to Assignment Manager {% endstep %} {% endstepper %} *** ### CSV File Format #### Required Columns | Column Name | Description | Required | Example | | --------------------- | ------------------------------------- | -------- | ------------------------------------------ | | `PolicyName` | Name of the Intune policy | Yes | "Windows Security Baseline" | | `GroupName` | Azure AD group name or special target | Yes | "All Users", "All Devices", "Finance Team" | | `AssignmentDirection` | Assignment direction | Yes | "Include", "Exclude" | | `AssignmentAction` | Action to perform | Yes | "Add", "Remove", "Replace", "NoAssignment" | | `Filter` | Name of assignment filter (optional) | No | "Windows 11 Devices" | | `Filter Type` | Filter direction (optional) | No | "Include", "Exclude" | #### CSV Example ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Windows Security Baseline;Finance Team;Include;Add;; Windows Security Baseline;All Users;Include;Replace;; Compliance Policy 1;Sales Team;Include;Add;Windows 11 Devices;Include Compliance Policy 1;Marketing Team;Include;Add;Test Devices;Exclude Old Policy;Finance Team;Include;Remove;; ``` *** ### Method 2: Export from Reference Tenant Use this method to create templates based on existing, properly configured tenants. #### Navigate to Assignment Overview {% stepper %} {% step %} Go to in your reference tenant {% endstep %} {% step %} Click **Load Assignments** to fetch current assignment data This loads all current policy assignments from your tenant, including assignment filters and exclusions. {% endstep %} {% endstepper %} #### Export to CSV {% stepper %} {% step %} Click the **Export** button {% endstep %} {% step %} Under "Export for Bulk Assignments", choose **Export to CSV** {% endstep %} {% step %} The file downloads with all current assignments in the correct format {% endstep %} {% endstepper %} The exported CSV includes: * All current policy assignments * Assignment filters (if any) * Proper column formatting * Ready-to-use structure #### Review and Modify If needed, edit the downloaded CSV to match your target requirements: Example: Change assignment actions: * Change `Add` to `NoAssignment` for cleanup assignments from a policy * Add `Remove` actions for policies you want to unassign Update target groups: * Replace specific groups with `All Users` or `All Devices` for standardization * Add or remove exclusion groups Adjust filters: * Update filter names to match your target tenant * Remove filter columns if not needed #### When to use export method * **Existing reference tenant** - You have a properly configured tenant to model * **Quick standardization** - Want to replicate current assignments across tenants * **Incremental changes** - Need to modify existing assignment patterns * **MSP workflows** - Deploying proven configurations to customer tenants *** ### Template Modification Examples #### Converting Export to Standardization Template Scenario: You exported assignments from a pilot tenant and want to create a standardized template for all customers. Original export (multiple specific groups): ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Security Baseline;IT Admins;Include;Add;; Security Baseline;Finance Team;Include;Add;; Security Baseline;Sales Team;Include;Add;; ``` Modified for standardization: This replaces all specific group assignments with a single assignment to All Users. ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Security Baseline;All Users;Include;Replace;; ``` #### Adding Safety Exclusions Scenario: Add test user exclusions to prevent policies from affecting test accounts. Original assignment: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Compliance Policy;All Users;Include;Add;; ``` Modified with exclusions: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Compliance Policy;Test Users;Exclude;Add;; ``` #### Removing Unwanted Assignments Scenario: Remove assignments from legacy policies during cleanup. Template for removing all assignments: ``` PolicyName;GroupName;AssignmentDirection;AssignmentAction;Filter;Filter Type Legacy Policy;;;NoAssignment;; Old Compliance Policy;;;NoAssignment;; ``` Scenario-specific examples Check out the Scenarios page for detailed CSV examples for common use cases: *** ### Best Practices #### For MSPs * **Create master templates** for each customer type or service tier * **Use Replace actions** to ensure consistent state across customer tenants * **Test templates** on a pilot customer before wide deployment * **Version control** your templates for change tracking #### For Enterprises * **Export from production** reference environments when possible * **Modify gradually** - don't change everything at once * **Document templates** with clear naming and versioning * **Test in development** before applying to production #### General Guidelines * **Start small** - test with 1-2 policies first * **Validate before upload** - check policy names, group names, and filters exist * **Keep templates organized** - use descriptive filenames * **Plan rollback** - know how to reverse changes if needed (see Backup and restore guide) *** ### Template Validation Before uploading your template, verify: * **Policy names** match exactly (case-sensitive) * **Group names** exist in the target tenant * **Filter names** exist and match the policy platform * **Actions and directions** use valid values * **No conflicting operations** in the same batch Validation happens during upload Assignment Manager validates your template during upload and shows you exactly what issues need fixing before proceeding. *** ### Next Steps Ready to upload? Once your template is ready, head to **Extensions → Assignment Manager** to upload and preview your changes. Related links: * How it works — * Common Scenarios — * Needed Permissions — * Workflow — # Conditional Access Assignments ## Overview The **CA Assignment Migration** tool lets you bulk-manage group assignments on your Microsoft Entra ID Conditional Access policies using a simple CSV file.\ The process follows four sequential stages — **Upload → Compare → Migrate → Verify** — so you always know exactly what will change before anything is committed, and you can confirm the result afterwards. {% hint style="info" %} 🔒 **Access requirement**: This feature is available to **beta testers** with an **Extensions** licence. {% endhint %} *** ## Why Use CA Assignment Migration? When managing Conditional Access at scale (multiple tenants, policy migrations, post-merger consolidations) manually adding or removing group assignments one-by-one is error-prone and time-consuming. * **Bulk operations** — add or remove dozens of group assignments in one go * **Pre-flight check** — compare your desired state against live Entra ID before touching anything * **Safe-by-default** — only rows you explicitly select are migrated * **Full audit trail** — every row has a final status, batch number, and correlation ID * **Post-migration validation** — a dedicated endpoint re-checks each assignment was actually applied *** ## The Migration Workflow ``` Upload CSV → Compare → Select & Migrate → Results → Verify → Summary ``` | Step | What happens | | ----------- | ------------------------------------------------------------------------------- | | **Upload** | Parse and validate your CSV locally before any API call | | **Compare** | POST to `/assignments/ca/compare` — check each row against live Entra ID | | **Migrate** | POST to `/assignments/ca/migrate` — apply selected changes in batches of 20 | | **Results** | Review per-row migration outcome (Success / Failed / Skipped) | | **Verify** | POST to `/assignments/ca/validate` — confirm each assignment exists in Entra ID | | **Summary** | Collapsible statistics + full row changelog with filter buttons | *** ## CSV Format Create a plain `.csv` file with the following columns (header row required): | Column | Required | Allowed values | Description | | --------------------- | -------- | ---------------------- | ----------------------------------------------------------------------------------------- | | `PolicyName` | ✅ | Any string | Display name of the Conditional Access policy | | `GroupName` | ✅\* | Any string or empty | Display name of the group to assign. Leave empty only for `Include → All Users` scenarios | | `AssignmentDirection` | ✅ | `Include` or `Exclude` | Whether the group is in the include or exclude list | | `AssignmentAction` | ✅ | `Add` or `Remove` | Whether to add the group to, or remove it from, the policy | {% hint style="warning" %} ⚠️ Rows with missing or invalid values are flagged **CSV Invalid** and excluded from all subsequent steps. You can hover over the warning icon (⚠️) in the upload table to see the specific error. {% endhint %} ### Minimal example ```csv PolicyName,GroupName,AssignmentDirection,AssignmentAction CAD001-O365: Grant macOS access for All users when Modern Auth Clients and Compliant-v1.1,AAD_DA_AutoPilot-Devices,Include,Add Block Legacy Authentication,Sales Team,Include,Add Block Legacy Authentication,Guest Users,Exclude,Add Require MFA for All Users,AAD_UA_ConAcc-Breakglass,Exclude,Remove ``` *** ## Step-by-Step Guide {% stepper %} {% step %} ### Step 1 — Upload CSV 1. Navigate to **Extensions → Assignment Manager → Conditional Access Assignments** 2. Drag-and-drop your CSV onto the upload zone, or click **Select CSV File** 3. The tool validates every row immediately: * **Green check** — row is valid and will be sent to the API * **Orange triangle** — row has a validation error (hover to see details) 4. The upload summary shows the total counts of Add / Remove actions and invalid rows 5. When happy, click **Compare *****N***** Valid Rows** > 📸 **Screenshot Placeholder**: *Upload step showing the drag-drop zone, CSV stats grid (Valid Rows / Add / Remove / Invalid), and the Compare button* > {% endstep %} {% step %} ### Step 2 — Compare The Compare step calls `/assignments/ca/compare` with the valid rows and returns a pre-flight result for each one. Each row gets one of four statuses: | Status badge | Meaning | Can be migrated? | | ----------------------- | ------------------------------------------------ | ---------------- | | 🟢 **Ready** | Policy found, group found, assignment compatible | ✅ Yes | | 🔵 **Already Migrated** | Assignment already exists in Entra ID | ❌ No (skip) | | 🔴 **Not Ready** | Validation failure (see Details column) | ❌ No | | 🟡 **Warning** | Assignment exists but has warnings | Review first | Use the filter buttons (**All / Ready / Already Migrated / Compare Failed / Warnings**) to focus on specific subsets. The **Policy State** column shows whether the CA policy is `enabled`, `disabled`, or `Report Only` — useful for spotting policies that are not yet enforced. > 📸 **Screenshot Placeholder**: *Migrate step showing the comparison table with Status / Policy Name / Group / Direction / Action / Policy State / Details columns and the filter bar* > {% endstep %} {% step %} ### Step 3 — Select & Migrate 1. All **Ready** rows are pre-selected automatically 2. Use the **Select All Ready** button or the header checkbox to adjust your selection 3. You can also individually check/uncheck rows 4. Click **Migrate *****N***** Selected** Rows are sent in **batches of 20**. A live progress bar shows: * Current chunk / total chunks * Items processed / total items * Running count of Successful / Failed / Skipped results You can click **Cancel Migration** at any time — already-processed batches are not rolled back. > 📸 **Screenshot Placeholder**: *Chunk progress bar with spinner, percentage, processed/total counter, and the three live stat tiles* > {% endstep %} {% step %} ### Step 4 — Results After all batches complete you land on the **Results** step. Five stat cards give an instant overview: | Card | Colour | Meaning | | --------------- | ------ | ------------------------------------------------ | | **Successful** | Green | API returned `Success` | | **Failed** | Red | API returned an error — check the Message column | | **Skipped** | Grey | API returned `Skipped` (already exists / no-op) | | **Not Started** | Yellow | Sent to API but never processed (check portal) | | **Total** | Blue | Total rows sent in this migration run | Use the filter buttons above the table to narrow to any status, then click **Proceed to Verification**. {% endstep %} {% step %} ### Step 5 — Verify Verification calls the dedicated `/assignments/ca/validate` endpoint — this does a live re-check in Entra ID, not just a compare, so it confirms the assignment is genuinely present. | Verification badge | Meaning | | ------------------ | ----------------------------------------------------------------------------- | | ✅ **Verified ✓** | `hasCorrectAssignment: true` — assignment confirmed in Entra ID | | ❌ **Failed** | `hasCorrectAssignment: false` — assignment not found; check the Reason column | The **Reason** column shows the `message.reason` field from the API (e.g. `"Post-migration validation passed"` or a specific failure reason). > 📸 **Screenshot Placeholder**: *Verification table showing Status / Policy Name / Group / Direction / Action / Policy State / Reason columns* When done, click **View Summary**. {% endstep %} {% step %} ### Step 6 — Summary The Summary page has two cards: **Card 1 — Migration Statistics** * Attention boxes highlight any issues (CSV invalid / compare failed / migration failed / not verified / skipped) * A collapsible **Migration Statistics** panel shows the full funnel: Uploaded → Ready → Migrated → Verified **Card 2 — Row Changelog** * Every CSV row is listed with its **Final Status** * Filter buttons let you jump straight to any category * Columns: Batch #, Policy, Action, Group, Direction, Final Status, Notes > 📸 **Screenshot Placeholder**: *Summary page showing attention boxes, collapsed statistics panel, and the row changelog table with filter buttons* > {% endstep %} > {% endstepper %} *** ## API Reference ### Compare — `POST /assignments/ca/compare` **Request body** (array): ```json [ { "policyName": "Block Legacy Authentication", "groupName": "Sales Team", "assignmentDirection": "Include", "assignmentAction": "Add" } ] ``` **Key response fields per item**: | Field | Type | Description | | --------------------------------------------- | ---------- | ------------------------------------------------------------ | | `isReadyForMigration` | `boolean` | `true` if all checks pass | | `isMigrated` | `boolean` | Assignment already exists | | `migrationCheckResult.policyExists` | `boolean` | Policy found by name | | `migrationCheckResult.policyIsUnique` | `boolean` | No duplicate policy names | | `migrationCheckResult.groupExists` | `boolean` | Group found by name | | `migrationCheckResult.assignmentIsCompatible` | `boolean` | No conflicting assignments | | `policy.state` | `string` | `enabled` / `disabled` / `enabledForReportingButNotEnforced` | | `warnings` | `string[]` | Non-blocking warnings | *** ### Migrate — `POST /assignments/ca/migrate` **Request body** — same shape as Compare. **Key response fields per item**: | Field | Type | Description | | --------------------- | ---------------- | ----------------------------------------------- | | `status` | `string` | `Success` / `Failed` / `Skipped` / `NotStarted` | | `errorMessage` | `string \| null` | Failure detail when `status = Failed` | | `processedAt` | `ISO datetime` | When the item was processed | | `assignmentDirection` | `number` | `1 = Include`, `2 = Exclude` | | `assignmentAction` | `number` | `0 = Add`, `1 = Remove` | *** ### Validate — `POST /assignments/ca/validate` **Request body** — same shape as Compare. **Key response fields per item**: | Field | Type | Description | | ---------------------- | --------- | -------------------------------------------------- | | `hasCorrectAssignment` | `boolean` | `true` if the assignment is confirmed in Entra ID | | `message.status` | `string` | `Valid` or `Invalid` | | `message.reason` | `string` | Human-readable explanation | | `policy.state` | `string` | Current policy enforcement state | | `policy.conditions` | `object` | Full policy conditions snapshot at validation time | *** ## Scenarios & Examples ### Scenario 1 — Onboarding a new group to multiple policies **Context**: A new department group `AAD_Dept_Finance` needs to be included in three existing CA policies. **CSV**: ```csv PolicyName,GroupName,AssignmentDirection,AssignmentAction CAD001-O365: Grant macOS access for All users when Modern Auth Clients and Compliant-v1.1,AAD_Dept_Finance,Include,Add Require MFA for All Users,AAD_Dept_Finance,Include,Add Block Legacy Authentication,AAD_Dept_Finance,Include,Add ``` **Expected Compare result**: All three rows show 🟢 **Ready** (assuming the group exists and none of the assignments already exist). **Expected Migrate result**: All three rows show **Success**. *** ### Scenario 2 — Replacing one group with another **Context**: `AAD_DA_AutoPilot-Devices` is being decommissioned and replaced by `AAD_DA_AutoPilot-Devices-v2`. You need to add the new group and remove the old one. **CSV**: ```csv PolicyName,GroupName,AssignmentDirection,AssignmentAction CAD001-O365: Grant macOS access for All users when Modern Auth Clients and Compliant-v1.1,AAD_DA_AutoPilot-Devices-v2,Include,Add CAD001-O365: Grant macOS access for All users when Modern Auth Clients and Compliant-v1.1,AAD_DA_AutoPilot-Devices,Include,Remove ``` **What to watch**: On Compare, confirm `AAD_DA_AutoPilot-Devices` shows `assignmentExists: true` (otherwise Remove is a no-op). Then migrate and verify both rows. *** ### Scenario 3 — Adding a break-glass exclusion **Context**: Your `Require MFA for All Users` policy needs to exclude the break-glass account group so emergency access is never blocked. **CSV**: ```csv PolicyName,GroupName,AssignmentDirection,AssignmentAction Require MFA for All Users,AAD_UA_ConAcc-Breakglass,Exclude,Add ``` **Key point**: `AssignmentDirection` is `Exclude` — the group goes into the **Exclude users** list, not the include list. *** ### Scenario 4 — Post-merger tenant consolidation **Context**: After a merger you have 40 policies across two tenants. You export the desired assignment state from the source tenant and apply it to the destination tenant. **Approach**: 1. Export current assignments from the source tenant as a CSV (via your own tooling or a PowerShell export) 2. Review the CSV — remove any rows for assignments that already exist in the destination 3. Upload, compare (confirm all group names exist in the destination), migrate, verify 4. Use the **Row Changelog** on the Summary page to document what was applied **Tip**: Run the Compare step first with the entire file. Use the **Compare Failed** filter to identify groups that need to be created in the destination tenant before migration. *** ### Scenario 5 — Partial rollback after a failed migration **Context**: You migrated 30 rows but 5 came back as **Failed** due to a permissions issue. You fix the permissions, then re-run only the failed rows. **Approach**: 1. On the **Results** step, filter to **Failed** and note the policy/group/direction/action combinations 2. Export or recreate a CSV with only those 5 rows 3. Start a new migration session, upload the smaller CSV, compare and migrate again 4. The previously successful 27 rows will show **Already Migrated** on Compare — do not re-select them *** ## Troubleshooting ### "Policy not found" on Compare * Verify the exact display name in the Entra ID portal — names are **case-sensitive** * If the policy was recently renamed, update your CSV ### "Group not found" on Compare * Confirm the group display name in Entra ID * Groups created via Azure AD Connect may take 15–30 minutes to sync * Ensure the service account has `Group.Read.All` permission ### "Duplicate policy name" on Compare * Two CA policies share the same display name — the API cannot determine which one to target * Rename one policy in the Entra ID portal to make names unique ### "Assignment is not compatible" on Compare * The requested assignment type conflicts with an existing assignment (e.g. trying to add a group that is already excluded as a conflicting rule) * Review the `compatibilityErrors` array in the Compare response for details ### Verification shows "Failed" after a successful migration * Entra ID replication can take up to 60 seconds after a change * Wait a moment and click **Run Verification** again * If it continues to fail, check the Entra ID audit log for the policy ### Migration was cancelled mid-run * Batches already processed are **not rolled back** — those assignments are live * Use the **Row Changelog** to see which rows were processed (`migration_success`) and which were not started (`migration_notstarted`) * Re-run with only the unprocessed rows *** ## Status Reference ### Row final statuses (Row Changelog) | Status | Colour | Description | | ---------------------- | ---------- | ------------------------------------------------------- | | `CSV Invalid` | 🔴 Red | Row failed local CSV validation | | `Compare Failed` | 🔴 Red | Pre-flight check failed — not migratable | | `Ready (Not Migrated)` | ⚪ Grey | Passed compare but was not selected or not yet migrated | | `Already Migrated` | 🔵 Blue | Assignment already existed before this run | | `Migrated` | 🔵 Blue | Successfully migrated, not yet verified | | `Migrated (Verified)` | 🟢 Emerald | Successfully migrated and confirmed by validation | | `Migration Failed` | 🔴 Red | API returned an error during migrate | | `Skipped` | ⚪ Grey | API returned Skipped (no-op) | | `Not Started` | 🟠 Orange | Sent to API but never processed | | `Verify Failed` | 🔴 Red | Assignment not found after migration | *** ## Permissions Required The service principal / app registration used by Intune Assistant needs the following Microsoft Graph permissions: | Permission | Type | Purpose | | ------------------------------------ | --------- | ------------------------------ | | `Policy.Read.All` | Delegated | Read CA policies | | `Policy.ReadWrite.ConditionalAccess` | Delegated | Modify CA policy assignments | | `Group.Read.All` | Delegated | Look up groups by display name | | `Directory.Read.All` | Delegated | Resolve group IDs | {% hint style="info" %} 💡 If you see `403 Forbidden` errors during migration, ask your tenant administrator to grant the missing permissions and retry. {% endhint %} *** ## Best Practices 1. **Always run Compare first** — never skip straight to Migrate. Use the pre-flight result to catch naming errors and missing groups. 2. **Start small** — on a new tenant, test with 2–3 rows before uploading a 100-row CSV. 3. **Verify after every migration** — the Verify step is your receipt that changes landed correctly. 4. **Keep your CSV** — save the original CSV alongside the Row Changelog export for audit purposes. 5. **Use report-only policies for testing** — set policies to `enabledForReportingButNotEnforced` in Entra ID to test assignment changes safely before enabling enforcement. 6. **Unique policy names** — ensure all CA policy display names are unique. Duplicate names will cause a Compare failure. 7. **Check group existence first** — if you're adding brand-new groups created as part of the same change window, wait for Entra ID to finish provisioning before running Compare. # Multi Admin Approval {% hint style="warning" %} **Action required** — If this warning appears in the Assignments Manager, assignment changes will fail until the IntuneAssistant backend API enterprise app is excluded from the active MAA policy. {% endhint %} ## What is Multi-Admin Approval? Multi-Admin Approval (MAA) is a security feature in Microsoft Intune that enforces a **four-eyes principle** for policy changes. When MAA is active, any attempt to create, update, or delete a protected resource requires a second administrator to review and approve the change before it takes effect. Microsoft extended MAA beyond the Intune portal — it also applies to **application-authenticated Microsoft Graph API calls**. This means any backend service that modifies Intune policies on your behalf is subject to the same approval requirement. {% hint style="info" %} MAA applies per policy type. You may have it active for configuration policies but not compliance policies, or vice versa. {% endhint %} *** ## The Warning Banner When you open the Assignments Manager, IntuneAssistant automatically checks whether MAA is active for any of the following policy types: * **Configuration Policies** (`configurationPolicy`) * **Compliance Policies** (`compliancePolicy`) * **Scripts** (`scripts`) If MAA is active for one of these types **and** the IntuneAssistant backend API enterprise application is not listed as an exclusion, an amber warning banner appears at the top of the Assignments Manager page. {% hint style="danger" %} **Do not apply changes while this warning is visible.** Any assignment change you attempt will be blocked by MAA and will fail. The change will **not** be queued for approval — it will simply be rejected. {% endhint %} *** ## The `x-msft-approval-justification` Error If you attempt to apply changes while MAA is active without an exclusion, the Microsoft Graph API rejects the request with: ``` Header 'x-msft-approval-justification' is required to request approval. ``` {% hint style="warning" %} This is **not** a permissions error. It means MAA intercepted the API call. The change is not queued for approval — it is rejected outright. You must fix the exclusion first. {% endhint %} Unlike a human administrator making a change in the Intune portal — where MAA creates a pending approval request — an automation tool that does not explicitly send the `x-msft-approval-justification` header receives an error and the operation stops entirely. IntuneAssistant is designed to be excluded, not to participate in the approval workflow. *** ## How to Fix It — Exclude IntuneAssistant from MAA {% stepper %} {% step %} ### Open the MAA policy in Intune 1. Go to the [Intune admin center](https://intune.microsoft.com/) 2. Navigate to **Tenant administration** → **Multi Admin Approval** 3. Open the policy that covers `configurationPolicy`, `compliancePolicy`, or `scripts` {% endstep %} {% step %} ### Add the app exclusion 1. Inside the policy, locate the **App Exclusions** section 2. Click **Add** and search for **IntuneAssistant** (the enterprise application registered in your tenant during onboarding) 3. Select it and save the policy {% hint style="info" %} The IntuneAssistant enterprise app ID is `afe66ddf-67d4-4d61-8a51-beca7b799f52`. If the search does not find it by name, use this ID. {% endhint %} {% endstep %} {% step %} ### Verify the fix Reload the Assignments Manager page. The amber warning banner will disappear once IntuneAssistant detects the app is in the exclusion list. {% endstep %} {% endstepper %} *** ## What Happens in Each Scenario | Scenario | Result | | -------------------------------------------------- | ------------------------------------------------------------------- | | MAA active, IntuneAssistant **not** excluded | Every write operation fails — `x-msft-approval-justification` error | | MAA active, IntuneAssistant **excluded** | Assignments Manager works normally | | No MAA policy active for the relevant policy types | No warning shown, no impact | *** ## Security Considerations Excluding IntuneAssistant from MAA does **not** bypass human approval for human administrators. The exclusion applies only to the IntuneAssistant service principal (app identity), not to individual user accounts. * Changes made by IntuneAssistant still appear in the Intune audit log * Human administrators remain subject to MAA approval requirements * You can set an **exclusion expiry date** on the MAA policy if you want the exclusion to be time-limited {% hint style="success" %} Excluding a trusted automation identity from MAA is standard practice and recommended by Microsoft. It maintains security for human-initiated changes while keeping automation operational. {% endhint %} *** ## Further Reading * [PatchMyPC — Intune Multi Admin Approval: the x-msft-approval-justification error](https://patchmypc.com/blog/intune-multi-admin-approval-the-x-msft-approval-justification-error) * [Microsoft Docs — Use multi admin approval in Intune](https://learn.microsoft.com/en-us/mem/intune/fundamentals/multi-admin-approval) # MSP Support ## What Is This Page? The **Customer Information** page is the central hub for managing your organization's relationship with Intune Assistant — who you are, which tenants you manage, what licenses are active, and which tenant context is currently selected for all other pages in the application. For **MSP (Managed Service Provider)** accounts, this page is especially important. It allows you to register and manage **multiple customer tenants**, grant the required admin consent for each, assign licenses, and switch the active **tenant context** so that every other page in Intune Assistant operates against the correct customer environment. This is how an MSP engineer can move between managing one customer's Intune environment and another's without ever logging out. {% hint style="info" %} **MSP + GDAP is the combination that enables full multi-tenant management.** An MSP account with a GDAP relationship means you can add customer tenants, consent on their behalf, and manage their Intune environment through the delegated permissions Microsoft has granted you. {% endhint %} *** ## Account Types — What Is Yours? When you first open this page, look at the **Account Type** badges in the Customer Details card. There are three independent flags: | Badge | When It Shows | What It Means | | ------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------ | | **MSP** | Your account is registered as an MSP | You can manage multiple tenants and add customer tenants using GDAP | | **Direct** | Your account is not an MSP | You manage only your own home tenant | | **Active** | You have a paid license | Full feature access including licensed extensions | | **Community** | No paid license, or community tier only | Core features available, licensed extensions not accessible | | **GDAP** | Your account has a GDAP relationship configured | You can use Granular Delegated Admin Privileges to manage customer tenants on their behalf | | **No GDAP** | No GDAP relationship detected | You can only manage your own home tenant | *** ## The Page Layout The page is divided into three main areas: 1. **Customer Details** — your organization's profile information 2. **License Information + Summary** — your active licenses and tenant counts 3. **Tenant Management table** — all registered tenants with their status and actions *** ## Customer Details Card The left card shows your organization's profile: | Field | What It Shows | | ------------------- | ------------------------------------------------------------------------------------ | | **Customer Name** | Your organization's registered name in Intune Assistant | | **Address** | Your registered address, or `Not provided` if not set | | **Primary Contact** | The primary contact email for the account | | **Account Type** | The MSP/Direct, Active/Community, and GDAP/No GDAP badges described above | | **Home Tenant ID** | The Entra ID tenant ID of your own Microsoft 365 tenant — the one you signed in with | *** ## License Information Card This card is shown when you hold a **non-community** (paid) license. It lists every active customer-level license with: | Field | What It Shows | | --------------------- | ---------------------------------------------------------------- | | **License Type** | `Community`, `Standard`, or `Enterprise` | | **Active / Inactive** | Whether the license is currently active | | **Trial** | Shown as an extra badge if the license is a trial | | **Max Tenants** | The maximum number of customer tenants this license permits | | **Expires** | The expiry date of the license, or `Never` if it does not expire | ### Tenant Limit Warning {% hint style="warning" %} If the total number of registered tenants has reached the maximum allowed by your combined active licenses, an **amber warning banner** appears: > ⚠️ Maximum tenant limit reached (X/Y tenants) — Contact support to increase your tenant limit or upgrade your license. The **Add Tenant** button in the Tenant Management section is automatically disabled when this limit is reached. {% endhint %} *** ## Summary Card A two-number summary showing: * **Total Tenants** (blue) — all tenants registered on your account * **Enabled Tenants** (green) — tenants with `isActive = true` *** ## Tenant Management Table The main table lists every tenant registered on your account. The columns shown depend on your account type. ### Columns for Community-Only Accounts | Column | What It Shows | | ------------------ | ------------------------------------------------------------------------ | | **Display Name** | The tenant's display name | | **Tenant ID** | The Entra ID tenant GUID in monospace | | **Domain** | The primary domain of the tenant (e.g., `contoso.onmicrosoft.com`) | | **Consent Status** | The onboarding readiness of the tenant — see Consent Status States below | ### Columns for Paid (Non-Community) Accounts | Column | What It Shows | | ------------------ | --------------------------------------------------------------------------------------------------------- | | **Display Name** | The tenant's display name | | **Tenant ID** | The Entra ID tenant GUID in monospace | | **Domain** | The primary domain | | **Type** | `Primary`, `Trial`, or `Standard` badge | | **GDAP** | `Enabled` or `Disabled` badge indicating whether a GDAP relationship exists for this tenant | | **License Status** | Count of licenses assigned to this tenant, with an orange warning icon if any license is awaiting consent | | **Actions** | A pencil (edit) icon that opens the tenant's management page | ### Consent Status States For community accounts, the Consent Status column shows one of three states: | Status | Meaning | Action Available | | ----------------------- | ---------------------------------------------------------------------------- | --------------------------------------- | | **Consent Required** | The tenant's community license exists but admin consent has not been granted | **Grant Consent** button appears inline | | **Onboarding Required** | Consent was granted but onboarding has not completed | Complete onboarding | | **Ready** | Consent granted and onboarding complete — tenant is fully usable | No action required | > 📸 *\[Screenshot placeholder: Tenant Management table showing three tenants — one with a red "Consent Required" badge and inline Grant Consent button, one with a grey "Onboarding Required" badge, and one with a green "Ready" badge]* ### Clicking a Tenant Row Clicking anywhere on a tenant row **sets that tenant as the active context** for the entire application. A brief blue shimmer animation confirms the selection. After clicking, all other pages (Assignments, Configuration, Audit Events, etc.) operate against that tenant's data. The currently selected tenant is remembered in the application context and displayed in the tenant selector in the sidebar. *** ## Adding a Tenant (MSP Accounts Only) The **Add Tenant** button is visible in the Tenant Management card header only when: * Your account is an **MSP** (`isMsp = true`) * Your account is **Active** (`isActive = true`) * You have **not reached your tenant limit** Clicking it opens the **Tenant Onboarding Modal** — a guided flow for registering a new customer tenant. See [Tenant Onboarding](/extensions/msp-support/tenant-management) for the full walkthrough. After successful onboarding, the page automatically refreshes and the new tenant appears in the table. *** ## Editing a Tenant For paid accounts, clicking the **pencil icon** in the Actions column takes you to that tenant's own management page (rather than opening a popup) — a full-width page with everything for that tenant laid out in clear sections, so you can see the tenant's whole state at once instead of digging through tabs. ### Overview section Shows the tenant's display name, domain, and Tenant ID, along with status badges (Primary / Trial, GDAP Enabled / Disabled). **Set as Active Context** — sets this tenant as the active context for the entire application. When already selected, the button shows a green **Active Context** label with a checkmark. {% hint style="info" %} This is the primary way to switch between customer environments in MSP workflows. Set the context here, then navigate to any other section — all data will be scoped to that tenant. {% endhint %} ### Module Access section (MSP accounts only) Lists every module available to your MSP account, with an **Add** button for modules not yet enabled on this tenant, or enable/remove controls for modules that are active. Only modules your customer license actually permits are offered — see [License Management](/extensions/msp-support/license-management) for details on what happens if a module can't be added. ### Worker License section (MSP accounts only) Generates a license key for deploying the on-premise Worker for this tenant. Enter a contact email (required) and optional notes, then click **Generate**. The generated key is shown once with a copy button — save it immediately, as it cannot be retrieved again. ### Danger Zone section Click **Remove Tenant** to arm the confirmation, then **Confirm Remove** to permanently delete the tenant. See Deleting a Tenant below. {% hint style="info" %} **Direct (non-MSP) accounts** only see the Overview and Danger Zone sections here — module and license management is MSP-only. If you're on a Direct account and want a module enabled or want to change your plan, contact support; we'll update your account and add the modules you need. {% endhint %} *** ## Granting Consent for Community Tenants For community-only accounts, consent is managed directly from the **Consent Status column** in the main tenant table. When a tenant shows a red **Consent Required** badge: 1. Click the **Grant Consent** button that appears next to the badge 2. A consent popup opens (600×700 px) 3. Complete the Microsoft admin consent flow in the popup 4. The popup closes and the consent callback is processed automatically 5. The tenant's status updates to **Ready** (green) after a successful refresh {% hint style="warning" %} **Popups must be allowed** for the Intune Assistant domain. If your browser blocks the popup, you will see an error message. Add the site to your browser's allowed popups list and try again. {% endhint %} *** ## Deleting a Tenant In the Danger Zone section of the tenant's management page, click **Remove Tenant** to arm the action — the button is replaced with a confirmation: > ⚠️ Are you sure you want to remove **"Tenant Name"**? This cannot be undone. Click **Cancel** to back out, or **Confirm Remove** (red, destructive) to proceed. After deletion, the tenant is removed from the backend and you're returned to the customer overview page, where the tenant list refreshes automatically. {% hint style="warning" %} **Deletion is permanent.** There is no soft-delete or recovery option. Only delete tenants you are certain should be removed. {% endhint %} *** ## The Tenant Context — Why It Matters **Setting tenant context is the most important action on this page for MSP users.** Every other section of Intune Assistant — Assignments, Configuration, Audit Events, Compare, Devices, Conditional Access — scopes all its data to the **currently selected tenant context**. When you change context here, you are effectively switching which customer's Intune environment you are working in. The flow for an MSP engineer managing multiple customers is: 1. Come to the Customer page 2. Find the customer you need to work on 3. Click the tenant row (or use **Set as Active Context** on the tenant's management page) 4. Navigate to whichever section you need (Assignments, Configuration, etc.) 5. All data on those pages now comes from that customer's tenant via the GDAP permissions you hold 6. Return to the Customer page to switch to a different customer > 📸 *\[Screenshot placeholder: Tenant Management table with one row highlighted in blue showing the currently selected tenant, and the sidebar tenant selector showing the same tenant name]* *** ## GDAP — How It Enables MSP Management **GDAP (Granular Delegated Admin Privileges)** is the Microsoft framework that allows an MSP to manage a customer's Microsoft 365 and Intune environment without needing a user account in that tenant. When GDAP is configured between your MSP tenant and a customer tenant: * Your admin credentials in your own tenant gain delegated permissions in the customer's tenant * The specific permissions available depend on the GDAP roles your customer has granted you * Intune Assistant uses these delegated permissions to call Microsoft Graph on behalf of the customer tenant when that tenant is set as the active context In the tenant table, the **GDAP** column shows `Enabled` (filled badge) or `Disabled` (outlined badge) for each registered tenant. For GDAP to work correctly in Intune Assistant, admin consent must also be granted for the application in the customer tenant — which is what the consent flow in this page handles. *** ## Common MSP Workflows ### Onboard a new customer tenant 1. Ensure your account is MSP + Active 2. Click **Add Tenant** 3. Complete the Tenant Onboarding Modal — enter the customer's tenant ID or domain 4. The tenant appears in the table with a **Consent Required** or **Onboarding Required** status 5. Grant consent if prompted 6. Once **Ready**, click the tenant row to set it as context 7. Navigate to any section to start managing the customer's Intune environment ### Switch between customer environments 1. Come to Customer Information 2. Click the tenant row for the customer you want to work on 3. The context switches immediately 4. Navigate to the desired section — all data is now scoped to that customer ### Add a module to a customer tenant 1. Click the pencil icon on the customer's tenant row to open its management page 2. In the Module Access section, click **Add** next to the module you want to enable 3. The module appears active immediately — no consent popup is needed for module activation itself (consent for the underlying Graph permissions is handled separately, see [License Management](/extensions/msp-support/license-management)) ### Review all tenants at a glance The tenant table gives you a complete inventory at a glance. For paid accounts, use the **GDAP** column to verify which tenants have an active GDAP relationship, and the **License Status** column to spot any tenants that need consent attention. *** ## Related Pages * [Tenant Onboarding](broken://pages/04c98f47968fd455ebe0b2137599db25e6c5839a) — the full onboarding modal walkthrough * [Audit Events Dashboard](broken://pages/1ed8922c2d10239c59bee01d02a327a9e5aea276) — after setting context, view that tenant's audit events * [Configuration](broken://pages/bf8cfc1652defbb6e82da219af77961d27eab1b3) — after setting context, manage that tenant's policies * [Assignments](broken://pages/12bbf69a2dc58a504e36dcc069e64b5a29938bd0) — after setting context, review that tenant's assignments # Overview ## Multi-Tenant Overview How Intune Assistant supports MSPs with GDAP-enabled multi-tenant management ## [Multi-Tenant Overview](#multi-tenant-overview) Intune Assistant is designed to be a perfect fit for Managed Service Providers (MSPs) who need to manage multiple customer tenants efficiently. With support for GDAP (Granular Delegated Admin Privileges), you can securely access and manage all your customer environments from a single interface. ### [Perfect for MSPs](#perfect-for-msps) As an MSP, you face unique challenges when managing multiple customer tenants: * **Context switching** between different customer portals * **Inconsistent access** across various tenants * **Time-consuming** manual processes for similar tasks * **Difficult oversight** of configurations across customers Intune Assistant solves these challenges by providing: * **Unified dashboard** for all your customer tenants * **Consistent experience** across all managed environments * **Bulk operations** per tenant context in the same portal * **Centralized reporting** and insights ### [How Multi-Tenant Works](#how-multi-tenant-works) #### [Home Tenant Architecture](#home-tenant-architecture) Intune Assistant uses a **home tenant** approach where: 1. **Main tenant** serves as your primary management hub, the one where GDAP relationships are established 2. **Customer tenants** are added as additional managed environments 3. **Single sign-on** experience across all tenants 4. **Centralized user management** in your home tenant #### [GDAP Integration](#gdap-integration) Intune Assistant leverages Microsoft's GDAP (Granular Delegated Admin Privileges) for secure customer tenant access: * **Granular permissions** - Only request the specific permissions you need * **Time-bound access** - Set expiration dates for enhanced security * **Customer approval** - Customers maintain control over granted permissions GDAP Advantage GDAP provides more secure and granular access compared to traditional delegated admin privileges, giving customers better control over what MSPs can access. ### [Setting Up Multi-Tenant Access](#setting-up-multi-tenant-access) #### [Prerequisites](#prerequisites) Before setting up multi-tenant access, ensure you have: * **Partner Center access** with appropriate permissions * **GDAP relationships** established with customer tenants * **Required permissions** granted for Intune management * **Customer approval** for the necessary delegated privileges * **Intune Assistant installed** in your home tenant * **MSP license plan** enabled for Intune Assistant #### [Required GDAP Roles](#required-gdap-roles) For Intune Assistant functionality, request these GDAP roles: | Role | Purpose | Permissions | | -------------------------------- | ----------------------- | ------------------------------------------- | | **Intune Service Administrator** | Full Intune management | Read/Write access to all Intune resources | | **Cloud Device Administrator** | Device management | Manage device settings and compliance | | **Application Administrator** | App management | Manage application assignments and policies | | **Reports Reader** | Analytics and reporting | Access to usage and compliance reports | #### [Setting Up Customer Tenants](#setting-up-customer-tenants) 1. **Establish GDAP relationship** in Partner Center (see [GDAP Setup Guide](https://learn.microsoft.com/en-us/partner-center/customers/gdap-obtain-admin-permissions-to-manage-customer)) 2. **Request appropriate roles** for Intune management (see [GDAP Role Assignment](https://learn.microsoft.com/en-us/partner-center/customers/gdap-assign-microsoft-entra-roles)) 3. **Wait for customer approval** of the delegated privileges (see [GDAP Approval Process](https://learn.microsoft.com/en-us/partner-center/customers/gdap-customer-approval)) 4. **Add tenant** to Intune Assistant using the customer settings page (see [Adding Customer Tenants](/extensions/msp-support/tenant-management)) ### [Features Across Tenants](#features-across-tenants) #### [Tenant-Specific Views](#tenant-specific-views) Switch between tenants while maintaining context: * **Quick tenant switching** without re-authentication * **Tenant-specific configurations** and customizations * **Isolated data** ensuring customer privacy ### [Security and Compliance](#security-and-compliance) #### [Data Isolation](#data-isolation) Each customer tenant's data remains completely isolated: * **No cross-tenant data sharing** * **Separate authentication contexts** * **Individual audit trails** per tenant * **Customer-specific permissions** #### [Audit and Monitoring](#audit-and-monitoring) Comprehensive logging across all operations: * **GDAP activity logs** for compliance reporting * **Security event correlation** #### [Access Controls](#access-controls) Multiple layers of security: * **Just-in-time access** through GDAP * **Role-based permissions** per customer tenant * **Multi-factor authentication** enforcement * **Conditional access** policy compliance Security Best Practices Always follow the principle of least privilege when requesting GDAP roles. Only request the minimum permissions necessary for your management tasks. ### [Benefits for MSPs](#benefits-for-msps) #### [Operational Efficiency](#operational-efficiency) * **Reduced context switching** between customer portals * **Standardized processes** across all customer tenants * **Bulk operations** that scale with your business * **Centralized training** on a single platform #### [Customer Service](#customer-service) * **Faster issue resolution** with unified visibility * **Consistent service delivery** across all customers * **Proactive monitoring** and alerting * **Better reporting** and insights for customers #### [Business Growth](#business-growth) * **Scalable architecture** that grows with your MSP * **Standardized offerings** across customer base * **Automated processes** that reduce manual overhead * **Better resource utilization** across teams ### [Getting Started](#getting-started) {% stepper %} {% step %} ### Step 1: Prepare Your Home Tenant * Set up Intune Assistant in your primary tenant * Configure user roles and permissions * Establish your baseline configurations {% endstep %} {% step %} ### Step 2: Establish GDAP Relationships * Work with customers to set up GDAP in Partner Center * Request appropriate delegated admin roles * Document approved permissions for each customer {% endstep %} {% step %} ### Step 3: Add Customer Tenants * Use the tenant switcher to add customer environments * Verify access and permissions for each tenant * Configure customer-specific settings and branding {% endstep %} {% step %} ### Step 4: Train Your Team * Ensure staff understand multi-tenant navigation * Establish processes for cross-tenant operations * Implement security and compliance procedures {% endstep %} {% endstepper %} ### [Troubleshooting Common Issues](#troubleshooting-common-issues) | Issue | Solution | | -------------------------------- | -------------------------------------------------- | | Cannot access customer tenant | Verify GDAP relationship and approved roles | | Missing permissions in tenant | Check delegated admin privileges in Partner Center | | Tenant not appearing in switcher | Confirm customer has approved GDAP request | | Cross-tenant operations failing | Validate consistent permissions across tenants | ### [Additional Resources](#additional-resources) * [GDAP Introduction - Microsoft Learn](https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction) * [Partner Center GDAP Management](https://learn.microsoft.com/en-us/partner-center/enroll/overview) * [Backup & Restore How to backup policy assignments before migration and restore them if needed using the Assignment Manager.](/extensions/assignments-manager/intune-assignments/backup-and-restore) * [Multi-Tenant Permissions Required permissions for multi-tenant management including Partner Center and GDAP access](/extensions/msp-support/multi-tenant-permissions) {% hint style="success" %} MSP Success Tip Start with a small subset of customer tenants to validate your processes and permissions before scaling to your entire customer base. {% endhint %} # Tenant Management ## Add Tenant Step-by-step guide for adding customer tenants to your MSP home tenant ## [Add Tenant to MSP Account](#add-tenant-to-msp-account) Learn how to add customer tenants to your MSP home tenant using GDAP relationships and Partner Center integration. ### [Prerequisites](#prerequisites) Before adding a tenant, ensure you have: * **Active GDAP relationship** with the customer tenant in Partner Center * **Approved delegated admin privileges** for Intune management * **Customer onboarded** through the regular Intune Assistant onboarding process GDAP Requirement An active partner-tenant GDAP relationship must be established in Partner Center before you can add the tenant to your MSP account. ### Steps to add a tenant {% stepper %} {% step %} ### Step 1: Access MSP Customer Settings Navigate to your MSP account's customer management area: * **Log into your MSP home tenant** * Use your primary MSP account credentials * Ensure you're in the correct home tenant context * **Access customer settings** * Go to **Customer Settings** under your MSP account * This shows your current managed customer tenants A tenant can have these badges: | | | | ------------- | -------------------------------------------------------------------------- | | Onboarded | Tenant is detected in Intune Assistant database already | | Not onboarded | This is a complete new customer and tenant | | Linked | Tenant is linked to your MSP account. (Should be there in the tenant list) | | Not Linked | Tenant is not linked to your MSP account yet. | Scenarios that can happen: | | | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Onboarded not Linked | Tenant is onboarded already, the wizard will link the tenant to your MSP account | | Not onboarded and not linked | The customer and tenant is not in the system yet, the wizard helps you onboarding the tenant. Customer is created in the backend automatically | | Onboarded and linked | Not clickable, ready for use | | {% endstep %} | | {% step %} ### Step 2: Add New Tenant * **Click "Add Tenant" button** * Located in the customer settings interface * This opens the tenant addition dialog * **Partner Center Integration** * The dialog automatically fetches available partner tenants * Shows all tenants where you have active GDAP relationships * Displays tenant information from Partner Center * **Select Customer Tenant** * Browse the list of available partner tenants * Find the customer tenant you want to add * Click on the desired tenant to select it * **Confirm Addition** * Review the tenant details * Confirm the GDAP permissions available * Complete the addition process Simple Process That's it! Once you click on the tenant, it's automatically added to your MSP account with the available GDAP permissions. {% endstep %} {% endstepper %} ### [What Happens Next](#what-happens-next) #### [Automatic Integration](#automatic-integration) * **Tenant appears** in your MSP dashboard * **GDAP permissions** are automatically applied * **Access verification** is performed in the background #### [Available Features](#available-features) * **Tenant switching** becomes available * **Cross-tenant operations** are enabled * **Unified reporting** includes the new tenant #### [Permission Inheritance](#permission-inheritance) * **Delegated privileges** from GDAP are applied * **Role-based access** follows Partner Center configuration * **Security boundaries** are automatically enforced ### [Troubleshooting](#troubleshooting)
Tenant Not Appearing in Partner Center List Possible causes: * GDAP relationship not yet active * Customer hasn't approved delegated privileges * Partner Center sync delay Solutions: * Verify GDAP status in Partner Center * Contact customer to approve pending requests * Wait for Partner Center synchronization (up to 30 minutes)
Access Denied After Adding Tenant Possible causes: * Insufficient GDAP permissions * Customer revoked delegated privileges * Role assignments not synchronized Solutions: * Check delegated admin roles in Partner Center * Request additional permissions if needed * Contact customer to verify GDAP approval
Customer Not Found in Backend Possible causes: * Customer hasn't completed onboarding * Backend synchronization pending * Onboarding process interrupted Solutions: * Ask customer to complete onboarding first * Wait for backend processing * Retry the add tenant process
### [Best Practices](#best-practices) #### [Before Adding Tenants](#before-adding-tenants) * **Verify GDAP relationship** is fully established * **Confirm required permissions** are approved * **Document customer requirements** and scope #### [During Addition Process](#during-addition-process) * **Select correct tenant** from the list * **Verify tenant details** before confirming * **Note available permissions** for future reference #### [After Addition](#after-addition) * **Test access** to the new tenant * **Verify expected functionality** is available * **Document any limitations** based on GDAP roles Pro Tip Keep a record of which GDAP roles you have for each customer tenant. This helps troubleshoot permission issues and plan service delivery. ### [Related Documentation](#related-documentation) * [Multi-Tenant Overview](/extensions/msp-support/overview) * [Managing MSP Permissions](/extensions/msp-support/multi-tenant-permissions) * [Switch Tenants](/extensions/msp-support/switch-tenants) * [Frequently Asked Questions](/getting-started/frequently-asked-questions) # License Management Muti-Tenant Management (MSP) ## License Management How to add and remove licenses for customer tenants in your MSP environment ## [Tenant License Management](#tenant-license-management) Learn how to manage licenses for your customer tenants, including adding new licenses and removing existing ones through the customer settings interface. ### [Overview](#overview) License and module management is **MSP-only**: only MSP accounts can add or remove modules for the tenants they manage. Direct (non-MSP) accounts — whether on the free Community tier or a paid Enterprise plan — do not have any self-service license or module management. If a direct customer wants to change tier or add a module, they contact support; we update their account and add the modules they need. For MSPs, license management controls which features and capabilities are available for each customer tenant, through the Module Access section on that tenant's management page. Adding certain modules may separately require an admin consent process to grant the Graph API permissions that module needs. ### [Managing Tenant Licenses](#managing-tenant-licenses) #### [Accessing License Management](#accessing-license-management) {% stepper %} {% step %} Navigate to Customer Settings * Go to **Customer Settings** in your MSP account * View your list of managed customer tenants {% endstep %} {% step %} Access Tenant Actions * Find the customer tenant you want to manage * Click the **Actions** (pencil) icon in the tenant row * This opens the tenant's own management page {% endstep %} {% endstepper %} #### [Adding a Module](#adding-a-module) {% stepper %} {% step %} Click "Add" * In the Module Access section of the tenant's management page, find the module you want to enable * Click **Add** next to it — only modules your own customer license actually permits are shown; a module that isn't offered means your account needs to be upgraded first (contact support) {% endstep %} {% step %} Module Becomes Active * The module activates immediately for that tenant — no separate consent step for the activation itself * If the module requires additional Microsoft Graph permissions, those are requested the first time a feature that needs them is used, via the normal admin-consent flow {% endstep %} {% endstepper %} #### [Removing a Module](#removing-a-module) In the Module Access section of the tenant's management page, you can also remove an active module. {% stepper %} {% step %} Deactivate or Remove * Click the amber toggle icon next to an active module to deactivate it, or the trash icon to remove it permanently * Review the impact — the tenant immediately loses access to that module's features {% endstep %} {% endstepper %} Feature Impact Removing a module cannot be undone from the same screen — access to features provided by that module stops immediately. Re-adding it later starts a fresh activation. ### [Consent Management Process](#consent-management-process) #### [When Consent is Required](#when-consent-is-required) Consent is typically required when: * **Adding a new license** that requires additional permissions * **Upgrading license tiers** with expanded capabilities * **Enabling new features** that need extra Graph API access * **First-time setup** of advanced functionalities #### [Consent Workflow](#consent-workflow) {% stepper %} {% step %} Consent Request Triggered * System identifies required permissions for the new license * Consent dialog appears with permission details * Clear explanation of why permissions are needed {% endstep %} {% step %} Admin Consent Required * Global Administrator or appropriate admin role needed * Review of requested permissions and their impact * Decision to grant or deny the consent request {% endstep %} {% step %} Permission Activation * Once consent is granted, permissions are activated * License features become available immediately * User can access newly enabled capabilities {% endstep %} {% endstepper %} Consent Best Practice Review the permissions requested during consent carefully. Only grant permissions that are necessary for the intended license features. ### [License Status Indicators](#license-status-indicators) In the tenants list, license status is indicated with icons: * **No Consent needed**: - Indicates no license is assigned * **Consent needed**: - Indicates consent is required for the license #### [Consent license](#consent-license) If a license requires consent, you will see the red alert icon as show above. To provide consent go to the tenant using the action button and use the Grant Consent button. ### [Troubleshooting](#troubleshooting) #### [Module Addition Fails](#module-addition-fails) Possible causes: * Your MSP account's own customer license doesn't permit that module yet * You tried this from a Direct (non-MSP) account — module management is MSP-only Solutions: * Contact support to verify or upgrade your license #### [Consent Process Fails](#consent-process-fails) Possible causes: * Admin consent not properly granted * Permission conflicts with existing setup * Tenant policy restrictions, its not possible to grant the permissions Solutions: * Ensure Global Administrator grants consent * Review existing permissions for conflicts * Check tenant conditional access policies #### [Features Not Available After Module Addition](#features-not-available-after-module-addition) Possible causes: * Consent not completed successfully * Permission synchronization delay * License activation pending Solutions: * Complete the consent process if pending * Wait for permission synchronization (up to 30 minutes) * Contact support if issues persist ### [Related Documentation](#related-documentation) * [Permission Overview](/security-and-compliance/needed-permissions) * [MSP Permission Overview](/extensions/msp-support/multi-tenant-permissions) * [Switch Tenants](/extensions/msp-support/switch-tenants) * [Multi-Tenant Overview](/extensions/msp-support/overview) License Flexibility License management provides flexibility to scale features based on customer needs while maintaining security through proper permission management. [Multi-Tenant Permissions](/extensions/msp-support/multi-tenant-permissions) # Multi-Tenant Permissions Muti-Tenant Management (MSP) ## Multi-Tenant Permissions Required permissions for multi-tenant management including Partner Center and GDAP access ## Multi-Tenant Permissions Learn about the specific permissions required for MSPs to manage multi-tenant environments, including Partner Center integration and GDAP relationship management. ### Overview MSP multi-tenant management requires additional permissions beyond standard Intune management to support Partner Center integration, GDAP relationship access, and cross-tenant operations. ### Required MSP Permissions #### Partner Center Access Permissions For MSP multi-tenant functionality, your MSP account requires: | Permission | Type | Purpose | | ------------------------------------- | ----------- | ------------------------------------------------------ | | `DelegatedAdminRelationship.Read.All` | Application | Read GDAP relationships and partner tenant information | {% hint style="info" %} Special Permission Notice Please contact support if you want to enable this permission for your MSP account. {% endhint %} #### Partner Center Authentication Your MSP account must have: * **Partner Center access** with appropriate role assignments * **Ability to view partner tenants** in the Partner Center portal * **GDAP relationship management** permissions * **Multi-tenant app registration** in your home tenant {% hint style="warning" %} Partner Center Requirement You must be able to login to Partner Center and view partner tenants for the multi-tenant functionality to work properly. {% endhint %} #### Standard Permissions In addition to Partner Center permissions, each managed tenant requires a set of standard Microsoft Graph API permissions for Intune management. The basic Intune Assistant permissions can be found on the [needed permissions](/security-and-compliance/needed-permissions) page. After onboarding new customer (see [add tenant](broken://pages/b1de3e1808839ff9ac2a87daf5ab456639ef0d7b)), the correct permissions are set up automatically. When adding a tenant, the Intune Assistant license is added to the tenant, and the required API permissions are consented. When adding an extra license, a consent prompt is shown to consent the required permissions. ### Related Documentation * [Add Tenant](/extensions/msp-support/tenant-management) * [Switch Tenants](/extensions/msp-support/switch-tenants) * [License Management](/extensions/msp-support/license-management) * [GDAP Introduction](https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction) * [Partner Center Role Management](https://learn.microsoft.com/en-us/partner-center/permissions-overview) {% hint style="info" %} Permission Foundation Proper permission setup is the foundation for successful MSP multi-tenant management. Take time to configure these correctly for optimal security and functionality. {% endhint %} * Multi-Tenant Overview\ \ How Intune Assistant supports MSPs with GDAP-enabled multi-tenant management * License Management\ \ How to add and remove licenses for customer tenants in your MSP environment # Switch Tenants Muti-Tenant Management (MSP) ## Switch Tenants How to switch between customer tenants in your MSP multi-tenant environment [Switch Tenants](#switch-tenants) Learn how to quickly switch between customer tenants in your MSP environment to manage multiple customer environments from a single interface. ### Overview The tenant switching functionality allows MSPs to seamlessly move between different customer environments without losing context or requiring separate logins. This streamlines your workflow when managing multiple customer tenants. ### How to Switch Tenants {% stepper %} {% step %} ### Step 1: Navigate to Customer Settings * Access your MSP home tenant * Ensure you're logged into your primary MSP account * Navigate to the main dashboard * Go to Customer Settings * Click on **Customer Settings** in your MSP account menu * This displays all your managed customer tenants {% endstep %} {% step %} ### Step 2: Select Target Tenant * Locate the customer tenant * Browse through your list of managed customer tenants * Find the tenant you want to switch to * Access tenant actions * Click on the **Actions** button in the tenant row * This opens the available actions for that specific tenant {% endstep %} {% step %} ### Step 3: Switch to Tenant * Click "Select Tenant" * From the actions menu, click **Select Tenant** * The system will initiate the tenant switch process * Automatic context switch * The interface automatically updates to show the selected tenant * All subsequent operations will be performed in the selected tenant context Quick Switch That's it! You're now working in the selected customer tenant environment with all the appropriate GDAP permissions applied. {% endstep %} {% endstepper %} ### What Happens During Tenant Switch #### Authentication Context * **GDAP authentication** is applied for the selected tenant * **Delegated permissions** are activated automatically * **User context** is maintained throughout the switch #### Interface Updates * **Tenant indicator** shows current active tenant * **Data context** switches to the selected tenant * **Navigation menus** reflect tenant-specific options #### Permission Application * **Role-based access** is applied based on GDAP configuration * **Scope limitations** are enforced automatically * **Audit trail** records the tenant switch activity ### Current Tenant Indicator After switching tenants, you can identify your current context through: * **Tenant name** displayed in the interface header * **Tenant-specific branding** if configured * **Context indicators** throughout the interface * **Breadcrumb navigation** showing current tenant ### Best Practices #### Before Switching * **Complete current operations** in the active tenant * **Save any pending changes** to avoid data loss * **Note the target tenant** to ensure correct selection #### During Operations * **Verify tenant context** before making changes * **Use tenant indicators** to confirm active environment * **Be mindful of cross-tenant operations** #### Security Considerations * **Verify permissions** in the new tenant context * **Check GDAP status** if access issues occur * **Log out completely** when finishing work ### Switching Back to Home Tenant To return to your MSP home tenant: 1. **Access Customer Settings** again 2. **Look for "Home Tenant"** option in the interface 3. **Click to return** to your primary MSP context Or use the tenant selector if available in the main navigation. ### Troubleshooting
Cannot Switch to Tenant Possible causes: * GDAP relationship expired or revoked * Customer disabled delegated access * Network connectivity issues Solutions: * Check GDAP status in Partner Center * Contact customer to verify permissions * Refresh the page and try again
Tenant Not Responding Possible causes: * Tenant-specific service issues * GDAP permission synchronization delay * Network or authentication problems Solutions: * Wait a few minutes and retry * Check Microsoft service health * Verify internet connectivity
Wrong Tenant Context If you're in the wrong tenant: * Immediately stop any operations * Switch to the correct tenant using the same process * Verify current context before proceeding Double-Check Context Always verify you're in the correct tenant context before making any configuration changes. Operations in the wrong tenant can affect the wrong customer environment.
### Keyboard Shortcuts Some common shortcuts to improve efficiency: * **Quick tenant search** - Use search functionality in customer settings * **Recently accessed** - Some interfaces show recently accessed tenants * **Favorites** - Mark frequently accessed tenants for quick access ### Related Documentation * [Add Tenant](broken://pages/b1de3e1808839ff9ac2a87daf5ab456639ef0d7b) * [Multi-Tenant Overview](broken://pages/073f704ad110bef47686f7a9cb4cfa97aa5674b8) * [GDAP Management](broken://pages/b00b4a4f7483488cbc56226800581a2d63f2608f) * [MSP Best Practices](broken://pages/eb9c7c75814478d68771508fa6fe948d3cdc1f7e) Efficiency Tip Organize your customer list by priority or frequency of access to make tenant switching faster and more efficient. [License Management\ \ How to add and remove licenses for customer tenants in your MSP environment](/extensions/msp-support/license-management) [Add Tenant\ \ Step-by-step guide for adding customer tenants to your MSP home tenant](/extensions/msp-support/tenant-management) # Worker The IntuneAssistant Worker brings automation and continuous monitoring directly into your own Intune environment — so your Intune management never sleeps. {% hint style="success" %} **Enterprise Feature** — **Enterprise Feature** — This extension is available exclusively on the Enterprise license. Once activated, it becomes available in your frontend. {% endhint %} ## What is the Worker? Imagine having a dedicated assistant watching over your Microsoft Intune environment around the clock — checking for problems, generating reports, and sending you updates — all without you having to lift a finger. That's exactly what the **IntuneAssistant Worker** is. It's a lightweight service that you deploy once, directly into **your own Azure subscription**. From that moment on, it runs in the background, executing the tasks you configure, on the schedule you choose, and reporting back to you automatically. No manual checks. No logging in every morning to see if something changed. No surprises. ## Why You Need It Managing Intune manually is time-consuming. Policies drift. Configurations change. Audits are overdue. And by the time you notice, the damage is already done. The Worker eliminates that reactive cycle. Instead of you going to look for problems, **the Worker finds them and comes to you**. {% hint style="info" %} **Real-world example:** You set up a Configuration Drift Monitor on Monday. On Thursday, someone changes a security policy. On Friday morning, you receive a detailed email report listing exactly what changed, and what the original baseline was. You didn't have to do anything, just create a job. {% endhint %} ## What Can the Worker Do? The Worker executes jobs as a managed identity with the permissions you configure. You define the job, set the schedule, and the Worker takes care of the rest. {% tabs %} {% tab title="Audit Reports" %} #### Intune & Entra Audit Reports Automatically generate detailed audit reports for your Microsoft Intune and Entra ID environment and have them delivered directly to your inbox. * Schedule reports **daily, weekly, or monthly** * Receive them as formatted HTML reports via email * Always have an up-to-date audit trail without manual exports * Perfect for compliance reviews and management reporting {% endtab %} {% tab title="Configuration Drift Monitor" %} #### Configuration Drift Monitoring This is the Worker's most powerful feature. It continuously monitors your Intune configuration policies against a saved baseline and **immediately alerts you when something changes**. * Detects **unauthorized or accidental policy changes** * Shows exactly which settings drifted and what the original value was * Sends a rich HTML report directly to the recipients you configure * Can be configured to **only alert when drifts are found** — no noise, only signal * Gives you a full history of active and resolved drifts No more end-of-quarter surprises. Know the moment your environment changes. {% endtab %} {% tab title="🔧 Coming Soon" %} #### On the Roadmap The Worker is built to grow. Upcoming job types include: * **Compliance Reports** — Scheduled device compliance summaries * **Script analysis** — Checks scripts content and finds unwanted code * **Security Reports** — Automated security posture snapshots * **Automated Remediation** — Let the Worker fix common issues automatically New job types are added with every release and automatically available to your Worker through the auto-update feature. {% endtab %} {% endtabs %} ## Your Data Stays Yours This is important and sets the Worker apart from cloud-only solutions. The Worker runs **inside your own Azure subscription**. It uses your own managed identity to connect to Microsoft Graph. Your Intune data is fetched, processed, and reported on — all within the boundaries of your own environment in that worker. > **IntuneAssistant never sees your raw Intune data.** The Worker operates autonomously in your tenant using your own Azure permissions. This makes the Worker an excellent fit for organizations with strict data residency requirements or internal security policies around third-party data access. ## Deploy in Minutes from Azure Marketplace Getting started is designed to be as frictionless as possible. 1. **Deploy from the Azure Marketplace** — Select your Azure subscription, resource group, and pricing tier. That's it. 2. **The Worker registers itself** — On first start, it automatically contacts IntuneAssistant and registers for your account. 3. **Activate with your license key** — Enter your Enterprise license key in the Worker dashboard to activate it. 4. **Configure your first job** — Set up a scheduled job from the IntuneAssistant portal and the Worker picks it up automatically. From zero to automated monitoring in under 10 minutes. {% hint style="warning" %} **Important after deployment:** To ensure only users from your organization can access the Worker dashboard, enable Microsoft authentication in Azure Portal → App Services → your Worker → Authentication. This takes 30 seconds and is strongly recommended. {% endhint %} ## Always Up to Date The Worker keeps itself current. When a new version is released, it updates automatically during its next maintenance window — no manual intervention required. You can also control the update behaviour: * **Enable or disable auto-update** from the Worker dashboard * Choose between update rings for controlled rollouts * View the currently installed version at any time ## The Worker Dashboard Every Worker comes with a built-in web dashboard, accessible at your Worker's Azure URL. From there you can: | What you see | What it means | | ----------------------- | ------------------------------------------------------- | | **Registration status** | Whether your Worker is activated and ready | | **Last heartbeat** | When the Worker last checked in (should be minutes ago) | | **Scheduled jobs** | All configured jobs and their next scheduled run time | | **Sender email** | The email address used to send job reports | | **Worker version** | Currently installed version | ## Frequently Asked Questions
Do I need to keep the Worker running at all times? Yes — the Worker is a continuously running service hosted on Azure App Service. It polls for jobs every few minutes and sends heartbeats to confirm it's alive. As long as your App Service is running, the Worker is working.
What happens if the Worker goes offline? Scheduled jobs that were due while the Worker was offline will be picked up and executed shortly after it comes back online. The Worker is resilient to short outages. If it stays offline for more than an hour, IntuneAssistant emails your notification address to let you know. See [Set Up Notifications](/extensions/worker/installation#set-up-notifications-optional) to change who receives that email or turn it off.
Can I have multiple Workers? Each activated Worker is tied to one license. If you manage multiple tenants or need Workers in separate Azure regions, you can deploy and license additional Workers from your IntuneAssistant account.
How do I know a job actually ran? Every job sends you an email report upon completion. You can also view the last run time and next scheduled run for every job directly in the Worker dashboard.
What Azure resources does the Worker use? The Worker deploys an **App Service** with an App Service Plan into your Azure subscription. The size (and therefore cost) of the App Service Plan is chosen by you at deployment time. A Basic B1 plan (\~€11/month) is sufficient for most environments.
Do I need extra permissions? Yes, you need to be an active Intune Administrator
## Ready to Get Started? {% hint style="success" %} Don't have an Enterprise license yet? [Upgrade your plan](https://intuneassistant.cloud/plans) to unlock the Worker and all other Enterprise features. {% endhint %} # Installation This page describes how install the Intune Assistant Worker in your tenant. ### Prerequisites Before you install the Intune Assistant worker make sure you have this in place: * A valid Azure Subscription: the Intune Assistant consumes Azure credits, make sure you have a subscription with a valid payment method * Proper permissions, you deploy resources, you need at least contributor permission at subscription or existing resource group level {% hint style="warning" %} The Intune Assistant Worker is a paid service and will be charged above the Azure consumption. {% endhint %} {% stepper %} {% step %} ### Go to the Azure Marketplace The first step is going to the Azure Marketplace. This takes about 30 seconds: 1. Go to **Azure Portal** 2. Navigate to **Azure Market Place** 3. Search for Intune Assistant Worker 4. Select the plan 5. Click **Create** {% endstep %} {% step %} ### Fill in deployment values The values represents the following: * Subscription and resourcegroup: the place where you deploy the resources * Region: Normally you pick the nearest region. The Intune Assistant API itself runs in West Europe * Worker name: must be globally unique and is the name where you connect to later * Microsoft Tenant ID: Is your own tenant ID * Notification Email: Provide the email adress to get notified about when the installation is finished. {% endstep %} {% step %} ### Select Worker Configuration The worker uses an Azure App service. Select the wanted App Service plan. The basic plan B1 is enough for basic use like running tasks once a day. {% endstep %} {% step %} ### Start Deployment Click on the create button to start deployment. {% endstep %} {% endstepper %} That's it. From now on, only users signed in with your organization's Microsoft account can access the Worker dashboard ## Finish Installation After deploying the Worker from the Azure Marketplace, there are a few steps to complete before it's fully operational. None of them take long — most users are up and running within 15 minutes. {% hint style="info" %} **Where is my Worker dashboard?**\ You can find the URL in the deployment confirmation email, or go to the **Azure Portal → Resource Groups → your Worker resource group → App Service** and click the **Default domain** link. {% endhint %} {% stepper %} {% step %} ### Secure Your Dashboard (Recommended) Your Worker has a built-in web dashboard. By default, anyone with the URL can view it. We strongly recommend restricting access so that only users from your own organization can open it. This takes about 30 seconds: 1. Go to **Azure Portal** 2. Navigate to **App Services** → select your Worker 3. In the left menu, click **Authentication** 4. Click **Add identity provider** 5. Select **Microsoft** 6. Under **Tenant type**, choose **Workforce configuration (current tenant)** 7. Click **Add** That's it. From now on, only users signed in with your organization's Microsoft account can access the Worker dashboard. {% hint style="warning" %} Skipping this step means anyone who knows your Worker's URL can view its status. The dashboard is read-only and does not expose your Intune data, but securing it is still best practice. For more information about securing your web application check: {% endhint %} {% endstep %} {% step %} ### Set a Sender Email (Optional) When the Worker sends you job reports (audit reports, drift alerts, etc.), it sends them from an email address. By default, this is the **notification email you provided during deployment**. If you want reports sent from a different address — for example, a shared mailbox or a dedicated monitoring address — you can change it from the Worker dashboard in IntuneAssistant. 1. Go to IntuneAssistant and open the Worker page 2. Look for the **Settings** button 3. Enter the email address you want reports sent from 4. Save {% hint style="info" %} The sender address must be a valid mailbox in your Microsoft 365 tenant. Reports will be sent on behalf of this address using your organization's mail infrastructure. {% endhint %} {% endstep %} {% step %} ### Set Up Notifications (Optional) IntuneAssistant can email you if your Worker stops sending heartbeats — for example if the App Service is stopped, crashed, or can no longer reach IntuneAssistant. This is separate from the job report emails described above. By default, notifications are turned on and sent to the **notification email you provided during deployment**. You can change either setting from the Worker page in IntuneAssistant: 1. Go to IntuneAssistant and open the Worker page 2. Look for the **Settings** button 3. Turn **Notifications** on or off 4. Optionally enter a different **notification email** address 5. Save {% hint style="info" %} Use a shared mailbox rather than one person's individual address, for example `it-ops@yourcompany.com`. That way the alert still reaches your team if the person who deployed the Worker changes roles or leaves. {% endhint %} {% hint style="info" %} You will only receive one alert per outage every 24 hours, so a Worker that stays down will not repeatedly fill your inbox. If it recovers and later goes down again, you will be notified again. {% endhint %} {% endstep %} {% step %} ### Get Your License Key The Worker requires an Enterprise license key to activate. Without it, it will remain in a **Pending** state and won't execute any jobs. Better said, it won't have a connection at all and keeps waiting in this state. To request your license key, send an email to: **** Include the following in your email: * Your organization name * The Worker instance ID (visible on the Worker dashboard under **Registration Status**) * The email address associated with your IntuneAssistant account You will receive your license key by email, typically within one business day. {% hint style="success" %} **Already have a license key?** Skip ahead to Step 4. {% endhint %} {% endstep %} {% step %} ### Activate the Worker Once you have your license key, enter it in the Worker dashboard to activate: 1. Open your Worker dashboard * The URL is in your registration confirmation email, **or** * Go to **Azure Portal → App Services → your Worker → Default domain** 2. On the dashboard, find the **Activate License** section 3. Enter your license key (format: `INTUNE-xxxxxxxx-xxxxxxxxxxxxxxxx`) 4. Click **Activate** The Worker will validate the key and switch from **Pending** to **Active** within seconds. {% tabs %} {% tab title="✅ Activation successful" %} The dashboard will show: * **Registration Status:** Active * **Health:** Healthy * A green heartbeat indicator showing the Worker is connected You're ready to create jobs. {% endtab %} {% tab title="❌ Key not accepted" %} If the license key is rejected, check: * The key was entered exactly as received (no extra spaces) * The key hasn't already been used on a different Worker instance * Your Worker instance ID matches what you sent in your license request If the problem persists, contact **** with your Worker instance ID. {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Confirm the Worker is Healthy Before creating jobs, confirm that the Worker is fully operational. On the dashboard you should see: | Indicator | Expected value | | ----------------------- | ---------------------------------------- | | **Registration Status** | Active | | **Last Heartbeat** | Less than 10 minutes ago | | **Scheduled Jobs** | 0 (no jobs configured yet — that's fine) | | **Worker Version** | Current version number | If the heartbeat timestamp is not updating or the status shows anything other than **Active**, wait a couple of minutes and refresh. If the issue persists, check the App Service logs in the Azure Portal. {% hint style="success" %} **Heartbeat updating and status is Active?** Your Worker is healthy and ready. Move on to creating your first job. {% endhint %} {% endstep %} {% step %} ### Add Managed Identity Permissions After deployment, the worker has no permissions yet. Because we take security very serious, we let you handle all the workers permissions.\ Currently its not possible to handle those permissions nicely and we need a bit of code for that.\ \ Use the following document to add the correct permissions. {% content-ref url="/pages/67QP4gkG67bMNsPjs7pN" %} [Add worker permissions](/extensions/worker/add-worker-permissions) {% endcontent-ref %} {% endstep %} {% step %} ### Create Your First Job Now that your Worker is licensed and healthy, you can configure it to start doing actual work. Jobs are created and managed from the **IntuneAssistant portal** — not the Worker dashboard itself. The Worker automatically picks up any jobs assigned to it. {% endstep %} {% endstepper %} ## Setup Checklist Use this as a quick reference to confirm everything is in place: * [ ] Worker deployed from Azure Marketplace * [ ] Dashboard secured with Microsoft authentication *(recommended)* * [ ] Sender email configured *(optional)* * [ ] License key received from * [ ] License key entered and Worker status is **Active** * [ ] Heartbeat is updating — Worker is **Healthy** * [ ] Ready to create jobs 🎉 ## Need Help? If you run into any issues during setup, reach out to us: **** Please include your Worker instance ID (visible on the dashboard) in your message so we can help you faster. # Manage Jobs Once your Worker is active and healthy, you can create jobs to automate recurring tasks — audit reports, configuration drift monitoring, and more. Jobs are configured in the **IntuneAssistant portal** and picked up automatically by your Worker. {% hint style="info" %} **Prerequisite:** Your Worker must have a **Registration Status** of **Active** before jobs can be assigned to it. See [Finishing the Installation](broken://pages/e85be4ed15a18a8675ca88d66a19eca4f34be734) if you haven't activated your Worker yet. {% endhint %} ## Available Job Types
Job TypeDescriptionStatus
Intune Audit ReportPeriodic report of Intune audit events, delivered by emailAvailable
Configuration Drift MonitorDetects and reports policy drift from your established baselineAvailable (preview)
Configuration BackupBacks up your Intune configuration to your own Azure Storage account on a schedule, with a success rate email overviewAvailable (preview)
Service Announcement DigestEmails a digest of new or updated M365 Message Center announcements matching your filtersAvailable (preview)
{% stepper %} {% step %} ### Go to Jobs 1. Sign in to the **IntuneAssistant portal** at [portal.intuneassistant.cloud](https://portal.intuneassistant.cloud/) 2. In the left navigation, click **Worker** 3. Select **Job Management** You will see a list of all configured jobs and their current status. {% endstep %} {% step %} ### Create a New Job Click **+ New Job** to open the job creation form. Fill in the following fields: #### General Settings | Field | Required | Description | | ------------ | -------- | --------------------------------------------------------------------------------------------- | | **Job Name** | ✅ Yes | A descriptive name for this job (max 200 characters) | | **Job Type** | ✅ Yes | Select the type of job to run (see Available Job Types above) | | **Worker** | Optional | Target a specific Worker instance. If you only have one Worker, it is selected automatically. | | **Enabled** | — | Toggle to enable or disable the job. Enabled by default. | #### Schedule | Field | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Run every** | How often the job should repeat. Enter a value in hours. Minimum: 1 hour. Maximum: 8,760 hours (1 year). Default: 168 hours (weekly). | | **First run at** | Optional. Schedule the first execution at a specific date and time (UTC). If left empty, the job will be queued immediately. Must be set to a future time within 1 year. | **Common interval values:** | Interval | Hours | | ----------------- | ----- | | Every hour | 1 | | Every 6 hours | 6 | | Daily | 24 | | Weekly | 168 | | Monthly (approx.) | 720 | | {% endstep %} | | {% step %} ### Configure the Job Each job type has its own configuration. Fill in the fields relevant to your chosen job type. {% tabs %} {% tab title="Intune Audit Report" %} This job retrieves Intune audit events and sends them as an HTML report by email. | Field | Required | Description | | ------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Recipient Email** | ✅ Yes | The email address the report is sent to | | **CC Emails** | Optional | Additional recipients, comma-separated (e.g. `alice@contoso.com,bob@contoso.com`) | | **Tenant ID** | ✅ Yes | The Microsoft tenant ID to pull audit events from | | **Lookback Days** | — | Number of days of history to include in the report. Default: **7 days** | | **Categories** | Optional | Filter events by category, comma-separated. Examples: `Application`, `Policy`, `Device`, `Role`. Leave blank to include all categories. | | **Only report if events found** | — | When enabled, no email is sent if there are no audit events in the period. Default: **off** (always send). | | **Max Events** | — | Maximum number of events to include in the report. Default: **500** | The report is attached to the email as an HTML file named `Intune-Audit-Report-YYYY-MM-DD.html`. {% endtab %} {% tab title="Configuration Drift Monitor" %} This job compares your current Intune configuration against the stored baseline and reports any deviations. | Field | Required | Description | | ------------------------------- | -------- | ------------------------------------------------------------------------------- | | **Recipient Email** | ✅ Yes | The email address the drift report is sent to | | **CC Emails** | Optional | Additional recipients, comma-separated | | **Tenant ID** | ✅ Yes | The Microsoft tenant ID to monitor | | **Only report if drifts found** | — | When enabled, no email is sent if the configuration is in sync. Default: **on** | The report is attached to the email as an HTML file named `Configuration-Drift-Report-YYYY-MM-DD.html`. {% hint style="info" %} Configuration drift is measured against the baseline snapshots stored in IntuneAssistant. Make sure you have at least one snapshot captured before enabling this job. {% endhint %} {% endtab %} {% tab title="Configuration Backup" %} This job exports your Intune configuration (the same resource types as the manual **Backup & Restore** feature), packages it into a ZIP archive, and uploads it to **your own** Azure Storage account — one folder per day per run time. {% hint style="info" %} Requires the **Config Management** module in addition to the Worker feature itself. If your subscription doesn't include it, job creation will return an error. {% endhint %} | Field | Required | Description | | ------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Recipient Email** | ✅ Yes | The email address the backup overview report is sent to | | **CC Emails** | Optional | Additional recipients, comma-separated | | **Tenant ID** | ✅ Yes | The Microsoft tenant ID to back up | | **Storage Account Name** | ✅ Yes | The name of the Azure Storage account the backup ZIP is uploaded to. This is **your own** storage account, not IntuneAssistant's. | | **Container Name** | ✅ Yes | The blob container inside that storage account. Created automatically if it doesn't already exist. | | **Folder Prefix** | Optional | A folder name inside the container. Defaults to the Tenant ID. Useful for MSPs backing up multiple tenants into one shared storage account (one prefix per tenant). | | **Resource Types** | Optional | Comma-separated list of resource types to back up (e.g. `SettingsCatalog, CompliancePolicies`). Leave blank to back up everything. | {% hint style="warning" %} **Before enabling this job**, grant your Worker's managed identity the **Storage Blob Data Contributor** role on the target storage account (Azure Portal → Storage account → Access Control (IAM) → Add role assignment). Without this role, the job will fail to upload the backup. {% endhint %} Each run creates a new blob at `{container}/{folder prefix}/{yyyy-MM-dd}/{HHmmss}/IntuneBackup.zip`. The completion email includes the overall success rate, item counts per resource type, and any resource types that failed. {% endtab %} {% tab title="Service Announcement Digest" %} This job fetches M365 Message Center announcements from Microsoft Graph and emails a digest of the ones matching your filters. See [Service Announcements](/intune-assistant/audits/service-announcements) to browse the same announcements directly in the portal — browsing is free, but this job requires the **Reporting** module. {% hint style="info" %} Requires the **Reporting** module in addition to the Worker feature itself. If your subscription doesn't include it, job creation will return an error. {% endhint %} | Field | Required | Description | | ------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Recipient Email** | ✅ Yes | The email address the digest is sent to | | **CC Emails** | Optional | Additional recipients, comma-separated | | **Tenant ID** | ✅ Yes | The Microsoft tenant ID to fetch announcements for | | **Services** | Optional | Comma-separated list of M365 services to watch, e.g. `Microsoft Entra, Intune`. Leave blank to include all services. | | **Severities** | Optional | Comma-separated: `Normal`, `High`, `Critical`. Leave blank to include all severities. | | **Categories** | Optional | Comma-separated: `PreventOrFixIssue`, `PlanForChange`, `StayInformed`. Leave blank to include all categories. | | **Tags** | Optional | Comma-separated free-text tags, e.g. `Admin impact, User impact, Retirement`. Leave blank to include all tags. | | **Tenant Rollout Status** | Optional | Check any of `Scheduled`, `In Rollout`, `Launched` to only notify about messages tracking a staged feature rollout for your tenant at that stage. Leave all unchecked to include every message regardless of rollout status. See [Tenant rollout status](/intune-assistant/audits/service-announcements#tenant-rollout-status). | | **Only Major Changes** | — | When enabled, only announcements flagged as a major change are included. Default: **off** | | **Only Send If Messages Found** | — | When enabled (default), the email is skipped on runs where nothing new matched. Disable to get an email every run, including an empty digest confirming the job ran with nothing new to report. | {% hint style="info" %} The digest only includes announcements that are new or updated since the job's last successful run — nothing is sent twice. The first run after creating the job includes everything matching your filters. {% endhint %} The digest itself is attached to the email as an HTML file (`Service-Announcements-Digest-YYYY-MM-DD.html`), not shown inline in the email body. Open the attachment in a browser to search and further filter the messages it contains — by text, severity, category, or tenant rollout status — without needing to go back to the portal. {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Save the Job Click **Save** to create the job. The portal will confirm the job has been created and display it in your jobs list with: * The scheduled next run time * Status: **Pending** (waiting to be picked up by the Worker) Your Worker polls for new jobs every **30 seconds**. The job will be claimed and executed automatically when it is due. {% endstep %} {% endstepper %} ## Monitoring Job Runs After a job has run, you can review its execution history from the job detail page. ### Job Status Values | Status | Meaning | | --------------- | -------------------------------------------------------- | | **Pending** | Job is scheduled and waiting to be claimed by the Worker | | **Claimed** | Worker has reserved the job for execution | | **In Progress** | Job is currently running | | **Success** | Job completed successfully and report was sent | | **Failed** | Job encountered an error | | **Expired** | Job was not picked up within the allowed window | | **Cancelled** | Job was manually cancelled | ### Execution History On the job detail page, the **Execution History** tab shows past runs with: * Start and end times * Duration in seconds * Status (Success / Failed) * Error message (if failed) ## Trigger a Job Manually You can run any job immediately without waiting for the scheduled time: 1. Open the job in the portal 2. Click **Run Now** 3. The job will be queued with **Pending** status and picked up by the Worker within 30 seconds The **Run Now** button is disabled for jobs that are: * Currently disabled (toggle is off) * Marked as **poisoned** (see below) ## Cancel a Running Job If a job is queued (**Pending**), has been picked up by the Worker (**Claimed**), or is actively running (**In Progress**), you can cancel it before it finishes. A **Cancel** button appears next to the job whenever it is in one of those three states: * On the **Worker overview** page, hover the **Jobs** column of the worker running the job * On the **Worker detail** page, under **Connected Jobs** * On the **Job Management** list, next to the job's row * On the job's own detail page, in the **Execution Status** card Click **Cancel** and confirm. The job's status changes to **Cancelled**. {% hint style="info" %} Cancelling a job that is queued (**Pending**) takes effect immediately — the Worker never picks it up. Cancelling a job that is already **In Progress** takes effect on the Worker's next check-in, which happens every few seconds while the job is running, so there can be a short delay before it actually stops. {% endhint %} {% hint style="warning" %} A cancelled job keeps its normal schedule. If the job is enabled, it will run again at its next scheduled time — cancelling only stops the one execution in progress, it does not pause or disable the job itself. To stop a job entirely, disable it instead (see below). {% endhint %} Cancelling does not delete anything — the cancelled run stays visible in **Execution History** with a **Cancelled** status, the same as any other run. ## Editing and Deleting Jobs ### Edit a job Open the job and click **Edit**. You can update the job name, schedule, and all configuration fields. Changes take effect from the next scheduled run. ### Disable a job Toggle the **Enabled** switch off to pause a job without deleting it. The job will remain in your list but will not be scheduled. ### Delete a job Click **Delete** on the job detail page. This permanently removes the job and its configuration. Execution history is retained for audit purposes. ## Troubleshooting ### The job stays in Pending for a long time * Check that your Worker is **Active** and the **Last Heartbeat** is recent (within 10 minutes). * Verify the Worker is connected to the internet and not paused or stopped in the Azure Portal. ### The job status shows Failed * Open the execution record and review the **Error Message** field. * Common causes: * **Invalid Recipient Email** — verify the email address is correct and accessible. * **Tenant ID not found** — confirm your Worker has consent for the tenant being audited. * **Graph API permissions missing** — visit the consent page in IntuneAssistant to re-grant permissions. * **Configuration Backup: "Failed to upload backup archive"** — grant the Worker's managed identity the **Storage Blob Data Contributor** role on the target storage account. ### The job is marked as Poisoned A job is automatically marked as **poisoned** after repeated consecutive failures. Poisoned jobs are excluded from scheduling to prevent runaway error loops. To recover a poisoned job: 1. Identify and fix the root cause (check execution history for error messages) 2. Edit the job and re-save it — this clears the poisoned flag and reschedules the job Check [Poisoned jobs](/extensions/worker/manage-jobs/poisoned-jobs) for more information about poisoned jobs ## Need Help? If your job is not running as expected, contact support with: * Your **Worker instance ID** (visible on the Worker dashboard) * The **Job ID** (visible in the job detail URL or execution history) * The **error message** from the failed execution **** # Poisoned jobs ## What is a poisoned job? When a job fails, the Worker will try again the next time it is scheduled. But if a job **fails 3 times in a row**, IntuneAssistant concludes that something is structurally wrong — not just a temporary hiccup — and automatically marks the job as **poisoned**. A poisoned job is: * **Stopped** — it will not run again automatically * **Locked** — it cannot be triggered manually either * **Flagged** — it is visually marked in the portal so you can find it quickly This is a safety mechanism. Without it, a broken job would keep failing on every scheduled run, sending error notifications indefinitely and consuming Worker resources. {% hint style="warning" %} A poisoned job does **not** delete your configuration or data. Everything is preserved. You just need to fix the underlying issue and reset the job to get it running again. {% endhint %} *** ## How do I know a job is poisoned? In the IntuneAssistant portal under **Worker → Jobs**, poisoned jobs are shown with a red **Poisoned** badge instead of the normal Enabled/Disabled indicator. On the job detail page you will also see: * **Status:** Poisoned * **Consecutive failures:** 3 (or more) * **Last failure:** the date and time of the most recent failed run *** ## Why did my job get poisoned? Open the job in the portal and go to the **Execution History** tab. Look at the last 3 failed executions — each one has an **Error Message** field that describes what went wrong. Common causes: | Symptom in error message | Likely cause | | ------------------------------ | -------------------------------------------------------------------------------- | | `RecipientEmail is required` | The recipient email address is missing or was cleared from the job configuration | | `Failed to fetch audit events` | The Worker lost access to the tenant — consent may have expired | | `Graph API 403 Forbidden` | Missing Microsoft Graph permissions — re-grant consent in IntuneAssistant | | `Invalid job configuration` | The job configuration JSON is malformed or incomplete | | `No drifts baseline found` | Configuration Drift job has no baseline snapshot to compare against | *** ## How to fix a poisoned job {% stepper %} {% step %} ### Step 1 — Find the error 1. Open the job from **Worker → Jobs** 2. Click the **Execution History** tab 3. Open the most recent failed execution 4. Read the **Error Message** — this tells you exactly what went wrong {% endstep %} {% step %} ### Step 2 — Fix the root cause Fix the issue before resetting the job. If you reset without fixing, the job will simply fail again and become poisoned once more. {% tabs %} {% tab title="Wrong email address" %} 1. On the job detail page, click **Edit** 2. Update the **Recipient Email** field with a valid address 3. Save the job — this automatically resets the poisoned status {% endtab %} {% tab title="Consent / permissions expired" %} 1. Go to **Settings → Tenants** in the IntuneAssistant portal 2. Find the affected tenant 3. Click **Re-grant Consent** and complete the Microsoft sign-in flow 4. Return to your job and reset it (see Step 3) {% endtab %} {% tab title="Misconfigured job settings" %} 1. On the job detail page, click **Edit** 2. Review all configuration fields — check email addresses, tenant ID, and any filters 3. Correct the values and save {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Step 3 — Reset the job Once the root cause is fixed, reset the job to clear the poisoned status: 1. Open the job in the portal 2. Click **Edit** 3. Make any necessary corrections (or simply re-save if the fix was made elsewhere) 4. Save the job The job will return to **Enabled** status and be scheduled for its next run immediately. {% hint style="success" %} After saving, check the job detail page to confirm the status shows **Enabled** and a new **Next Scheduled Run** time is set. The consecutive failure counter will be back to 0. {% endhint %} {% endstep %} {% endstepper %} *** ## Frequently asked questions
Can I manually trigger a poisoned job? No. The **Run Now** button is disabled for poisoned jobs. You must reset the job first.
Will I lose my job history? No. All previous execution records are preserved, including the failed runs that caused the job to become poisoned.
What if the job gets poisoned again right after I reset it? That means the root cause has not been fully resolved. Go back to the execution history, check the new error message, and address the issue before resetting again.
Can I delete a poisoned job and recreate it? Yes, but resetting it is simpler — you keep your existing configuration and history. Only delete the job if you want to start completely fresh.
*** ## Need Help? If you cannot identify the cause from the error message, contact support with: * Your **Worker instance ID** (visible on the Worker dashboard) * The **Job ID** (visible in the job detail URL) * The **error message** from the failed execution **** # Add worker permissions To grand the corrects permissions to the created worker follow the steps below: Copy the script below into a file, save the file as add-permission {% stepper %} {% step %} ### Copy code and save file. Copy the code and save the file to grand-worker-permissions.ps1 ```ps1 #!/usr/bin/env pwsh <# .SYNOPSIS Assigns Microsoft Graph application permissions to a Worker's managed identity. .DESCRIPTION Uses Microsoft.Graph.Authentication module for interactive browser login (supports Conditional Access / MFA). All Graph calls use Invoke-MgGraphRequest. .PARAMETER TenantId Your Azure AD Tenant ID. .PARAMETER WorkerName The App Service name (matches the system-assigned managed identity display name). .PARAMETER Permissions Array of Microsoft Graph application permission names to assign. Defaults to the full set required by IntuneAssistant Worker. .EXAMPLE # Use defaults (all required permissions) .\grand-worker-permissions.ps1 -TenantId "6a80764a-..." -WorkerName "my-worker" .EXAMPLE # Assign only specific permissions .\grand-worker-permissions.ps1 -TenantId "6a80764a-..." -WorkerName "my-worker" ` -Permissions @('Mail.Send', 'Group.Read.All') .NOTES Requires: Application Administrator or Global Administrator role in Azure AD. #> [CmdletBinding()] param( [Parameter(Mandatory = $true, HelpMessage = "Your Azure AD Tenant ID")] [ValidateNotNullOrEmpty()] [string]$TenantId, [Parameter(Mandatory = $true, HelpMessage = "App Service name (= managed identity display name)")] [ValidateNotNullOrEmpty()] [string]$WorkerName, [Parameter(Mandatory = $false, HelpMessage = "Graph application permissions to assign")] [string[]]$Permissions = @( # Mail 'Mail.Send', # Identity & directory 'Group.Read.All', 'GroupMember.Read.All', 'User.ReadBasic.All', 'RoleManagement.Read.Directory', 'AuditLog.Read.All', 'Application.Read.All', 'AppRoleAssignment.Read.All', # Device management 'DeviceManagementConfiguration.Read.All', 'DeviceManagementScripts.Read.All', 'DeviceManagementRBAC.Read.All', 'DeviceManagementApps.Read.All', 'DeviceManagementServiceConfig.Read.All', 'DeviceManagementManagedDevices.Read.All', # Policy & monitoring 'Policy.Read.ConditionalAccess', 'ConfigurationMonitoring.ReadWrite.All' # non-standard — skipped if not found ) ) $ErrorActionPreference = 'Stop' # ───────────────────────────────────────────────────────────────────────────── # CONSTANTS # ───────────────────────────────────────────────────────────────────────────── $MsGraphAppId = '00000003-0000-0000-c000-000000000000' # Microsoft Graph $GraphBaseUrl = 'https://graph.microsoft.com/v1.0' # ───────────────────────────────────────────────────────────────────────────── # ENSURE MODULE (authentication only — not the full Graph SDK) # ───────────────────────────────────────────────────────────────────────────── $moduleName = 'Microsoft.Graph.Authentication' if (-not (Get-Module -ListAvailable -Name $moduleName)) { Write-Host "Module '$moduleName' not found. Installing..." -ForegroundColor Yellow Install-Module $moduleName -Scope CurrentUser -Force -AllowClobber Write-Host " ✓ Installed" -ForegroundColor Green } Import-Module $moduleName -ErrorAction Stop # ───────────────────────────────────────────────────────────────────────────── # HELPERS # ───────────────────────────────────────────────────────────────────────────── function Invoke-Graph { param( [string]$Path, [string]$Method = 'GET', [hashtable]$Body ) $params = @{ Uri = "$GraphBaseUrl$Path" Method = $Method OutputType = 'PSObject' } if ($Body) { $params.Body = ($Body | ConvertTo-Json -Depth 5) } return Invoke-MgGraphRequest @params } function Get-GraphAllPages { param([string]$Path) $items = [System.Collections.Generic.List[object]]::new() $uri = "$GraphBaseUrl$Path" while ($uri) { $resp = Invoke-MgGraphRequest -Uri $uri -Method GET -OutputType PSObject if ($resp.value) { $items.AddRange([object[]]$resp.value) } $uri = $resp.'@odata.nextLink' } return $items } # ───────────────────────────────────────────────────────────────────────────── # BANNER # ───────────────────────────────────────────────────────────────────────────── Write-Host "" Write-Host "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" -ForegroundColor Cyan Write-Host " Worker Managed Identity — Graph Permission Setup" -ForegroundColor Cyan Write-Host "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" -ForegroundColor Cyan Write-Host " TenantId : $TenantId" Write-Host " WorkerName : $WorkerName" Write-Host " Permissions: $($Permissions.Count) requested" Write-Host "" # ───────────────────────────────────────────────────────────────────────────── # STEP 1: INTERACTIVE LOGIN # ───────────────────────────────────────────────────────────────────────────── Write-Host "[1/5] Opening browser for interactive login..." -ForegroundColor Yellow Write-Host " (MFA and Conditional Access are fully supported)" -ForegroundColor Gray Connect-MgGraph ` -TenantId $TenantId ` -Scopes 'Application.Read.All', 'AppRoleAssignment.ReadWrite.All' ` -NoWelcome $ctx = Get-MgContext Write-Host " ✓ Signed in as : $($ctx.Account)" -ForegroundColor Green Write-Host " ✓ Tenant : $($ctx.TenantId)" -ForegroundColor Gray # ───────────────────────────────────────────────────────────────────────────── # STEP 2: FIND MANAGED IDENTITY SERVICE PRINCIPAL # ───────────────────────────────────────────────────────────────────────────── Write-Host "" Write-Host "[2/5] Searching for managed identity: '$WorkerName'..." -ForegroundColor Yellow $encoded = [uri]::EscapeDataString("displayName eq '$WorkerName'") $spResp = Invoke-Graph -Path "/servicePrincipals?`$filter=$encoded&`$select=id,displayName,appId,servicePrincipalType" $allMatches = @($spResp.value) if ($allMatches.Count -eq 0) { Write-Error @" No service principal found with displayName '$WorkerName'. Make sure: 1. The App Service exists in this tenant 2. System-assigned managed identity is ENABLED Azure Portal → App Service → Identity → System assigned → Status: On 3. The name matches exactly (case-sensitive) "@ Disconnect-MgGraph | Out-Null exit 1 } $managedIdentity = $allMatches | Where-Object { $_.servicePrincipalType -eq 'ManagedIdentity' } | Select-Object -First 1 if (-not $managedIdentity) { $managedIdentity = $allMatches[0] } Write-Host " ✓ Found: $($managedIdentity.displayName)" -ForegroundColor Green Write-Host " Object ID : $($managedIdentity.id)" -ForegroundColor Gray Write-Host " Type : $($managedIdentity.servicePrincipalType)" -ForegroundColor Gray if ($managedIdentity.servicePrincipalType -ne 'ManagedIdentity') { Write-Warning "Type is not 'ManagedIdentity' — verify system-assigned identity is enabled on the App Service." } # ───────────────────────────────────────────────────────────────────────────── # STEP 3: FIND MICROSOFT GRAPH SP + REQUIRED APP ROLES # ───────────────────────────────────────────────────────────────────────────── Write-Host "" Write-Host "[3/5] Finding Microsoft Graph service principal and app roles..." -ForegroundColor Yellow $graphFilter = [uri]::EscapeDataString("appId eq '$MsGraphAppId'") $graphResp = Invoke-Graph -Path "/servicePrincipals?`$filter=$graphFilter&`$select=id,displayName,appRoles" $graphSp = @($graphResp.value)[0] if (-not $graphSp) { Write-Error "Microsoft Graph service principal not found in tenant '$TenantId'." Disconnect-MgGraph | Out-Null exit 1 } Write-Host " ✓ Found Microsoft Graph (Object ID: $($graphSp.id))" -ForegroundColor Green $roleMap = [ordered]@{} foreach ($permName in $Permissions) { $role = $graphSp.appRoles | Where-Object { $_.value -eq $permName -and $_.allowedMemberTypes -contains 'Application' } if ($role) { $roleMap[$permName] = $role.id Write-Host " ✓ Located : $permName" -ForegroundColor Gray } else { Write-Warning " Skipped : '$permName' — not found as application permission in Microsoft Graph" } } if ($roleMap.Count -eq 0) { Write-Error "None of the requested permissions could be located in Microsoft Graph." Disconnect-MgGraph | Out-Null exit 1 } # ───────────────────────────────────────────────────────────────────────────── # STEP 4: CHECK EXISTING ASSIGNMENTS # ───────────────────────────────────────────────────────────────────────────── Write-Host "" Write-Host "[4/5] Checking existing assignments on managed identity..." -ForegroundColor Yellow $existing = Get-GraphAllPages -Path "/servicePrincipals/$($managedIdentity.id)/appRoleAssignments" Write-Host " Found $($existing.Count) existing app role assignment(s)" -ForegroundColor Gray # ───────────────────────────────────────────────────────────────────────────── # STEP 5: ASSIGN MISSING PERMISSIONS # ───────────────────────────────────────────────────────────────────────────── Write-Host "" Write-Host "[5/5] Assigning missing permissions..." -ForegroundColor Yellow $assigned = 0; $alreadyHad = 0; $failed = 0 foreach ($permName in $roleMap.Keys) { $roleId = $roleMap[$permName] $alreadyAssigned = $existing | Where-Object { $_.resourceId -eq $graphSp.id -and $_.appRoleId -eq $roleId } if ($alreadyAssigned) { Write-Host " ○ Already assigned : $permName" -ForegroundColor Cyan $alreadyHad++ continue } try { Invoke-Graph ` -Path "/servicePrincipals/$($managedIdentity.id)/appRoleAssignments" ` -Method POST ` -Body @{ principalId = $managedIdentity.id resourceId = $graphSp.id appRoleId = $roleId } | Out-Null Write-Host " ✓ Assigned : $permName" -ForegroundColor Green $assigned++ } catch { Write-Host " ✗ Failed : $permName — $($_.Exception.Message)" -ForegroundColor Red $failed++ } } # ───────────────────────────────────────────────────────────────────────────── # SUMMARY # ───────────────────────────────────────────────────────────────────────────── Disconnect-MgGraph | Out-Null Write-Host "" Write-Host "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" -ForegroundColor Cyan Write-Host " Summary" -ForegroundColor Cyan Write-Host "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" -ForegroundColor Cyan Write-Host " Worker : $($managedIdentity.displayName)" Write-Host " Object ID : $($managedIdentity.id)" Write-Host " Newly assigned : $assigned" -ForegroundColor $(if ($assigned -gt 0) { 'Green' } else { 'White' }) Write-Host " Already had : $alreadyHad" Write-Host " Failed : $failed" -ForegroundColor $(if ($failed -gt 0) { 'Red' } else { 'White' }) if ($failed -gt 0) { Write-Host "" Write-Host " Failures may indicate insufficient role." -ForegroundColor Yellow Write-Host " Required: Application Administrator or Global Administrator" -ForegroundColor Yellow } if ($assigned -gt 0 -or $alreadyHad -gt 0) { Write-Host "" Write-Host " IMPORTANT — Exchange Online step still required for Mail.Send" -ForegroundColor Yellow Write-Host " Connect-ExchangeOnline" -ForegroundColor White Write-Host " Test-ApplicationAccessPolicy -Identity -AppId $($managedIdentity.id)" -ForegroundColor White } Write-Host "" Write-Host " Done!" -ForegroundColor Green Write-Host "" exit $(if ($failed -gt 0) { 1 } else { 0 }) ``` {% endstep %} {% step %} ### Open a PowerShell window Run the PowerShell file using the example below. ``` .\grand-worker-permissions.ps1 -TenantId "6a80764a-..." -WorkerName "my-worker" ``` {% endstep %} {% endstepper %} # License management ## What Is This Page? The **License Management** page lets MSP administrators generate, assign, and revoke worker licenses. A worker license is the token that authorizes a specific worker instance to authenticate with the Intune Assistant backend and execute jobs against customer tenants. Each license is tied to a single worker. Once assigned, it cannot be reassigned to a different worker without revoking it first. {% hint style="info" %} **This page is only visible to MSP accounts.** If you are a direct (non-MSP) customer, your platform administrator manages worker licenses on your behalf — you do not need to interact with this page. {% endhint %} *** ## Key Concepts ### What is a worker license? A worker license is a cryptographic key in the format `INTUNE-{customerid}-{randompart}`. It is generated once, shown to you exactly once (copy it immediately), and then stored only as a hashed reference. When a worker registers or sends a heartbeat, it presents this key to authenticate itself. | Term | Meaning | | ------------- | ------------------------------------------------------------------------------------------------ | | **Generated** | License exists in the system but is not yet assigned to any worker | | **Assigned** | License is linked to a specific worker registration | | **Revoked** | License has been permanently deactivated; the worker using it will be rejected at next heartbeat | ### License quota Your license quota controls how many licenses you can generate. It is tied to your Intune Assistant subscription (`MaxTenants` on your customer license). The **quota bar** at the top of the page always shows: * Total licenses included in your plan * How many have been issued (generated) * How many are still available to generate {% hint style="warning" %} Once all quota slots are used, you must either revoke an existing license or contact Intune Assistant support to increase your quota before generating a new one. {% endhint %} ### Billing vs. deployment Licenses are billed under your MSP account regardless of which customer tenant the worker is deployed in. This is by design — you pay for your workers centrally, and you can deploy them into any of your customer environments. *** ## Page Layout The page has three main sections: | Section | Purpose | | --------------------------- | ------------------------------------------------------------------------------------- | | **Quota bar** | Shows issued vs. total licenses at a glance; changes colour as you approach the limit | | **Generate License button** | Opens the generation dialog | | **License table** | All licenses with status, assignment, and actions | *** ## Quota Progress Bar The bar at the top of the page displays `X of Y licenses used`. | Bar colour | When shown | What it means | | ---------- | -------------- | ---------------------------------------- | | **Blue** | Below 80% used | Healthy — plenty of quota remaining | | **Amber** | 80–99% used | Warning — you are running low | | **Red** | 100% used | Full — no more licenses can be generated | *** ## License Table Each row represents one license. | Column | Description | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **License Key** | The key, masked to the first 20 characters. Use the copy icon to copy the full key to the clipboard (only possible for un-revoked licenses where the key was shown at generation time). | | **Status** | `Active`, `Assigned`, or `Revoked` badge | | **Assigned To** | The worker registration ID the license is assigned to, or `—` if unassigned | | **Issued** | Date the license was generated | | **Expires** | Expiry date if set, or `Never` | | **Actions** | **Assign** (if unassigned), **Revoke** | {% hint style="info" %} After a license is assigned via the Assign action, the "Assigned To" column shows the worker's machine name (if the worker has already registered) or the registration ID. {% endhint %} *** ## Generating a License {% stepper %} {% step %} ### Click **Generate License** Click **Generate License** at the top right of the page. {% endstep %} {% step %} ### Fill in the form | Field | Required | Description | | ------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Recipient email** | Yes | Contact email for the person responsible for this worker (used for notifications) | | **Company** | No | The customer company name, for reference | | **Expiry date** | No | Set an expiry if you want the license to automatically become invalid on a specific date. Leave blank for a perpetual license. | | **Notes** | No | Internal notes visible only in this management page | | {% endstep %} | | | {% step %} ### Click **Generate** Click **Generate**. {% endstep %} {% step %} ### Copy the generated key The generated key appears in a highlighted read-only field. {% hint style="warning" %} **Save this key immediately.** It is shown only once and cannot be retrieved later. Copy it to a password manager or securely hand it to the person installing the worker. {% endhint %} Click **Copy** to copy the full key, then click **Close**. {% endstep %} {% endstepper %} *** ## Assigning a License to a Worker After generating a license, you can assign it to a specific worker registration. This step is optional at generation time — you can also assign later from the table. ### From the table {% stepper %} {% step %} ### Find the license row Find the license row with **Status: Active** (unassigned). {% endstep %} {% step %} ### Open the Assign action Click **Assign** in the Actions column. {% endstep %} {% step %} ### Select the target worker Select the target worker from the dropdown. The dropdown shows only workers that: * Have registration status **Approved** * Do not already have a license assigned {% endstep %} {% step %} ### Confirm the assignment Click **Assign License**. {% endstep %} {% step %} ### Assign license to worker Last step is to assign the license at at worker side. {% endstep %} {% endstepper %} ### Cross-tenant assignment If you are an MSP and the worker is deployed inside a customer tenant, you can still assign the license from your MSP account. The license remains billed under your MSP account; the worker validates it using the worker registration ID rather than the customer tenant ID. *** ## Revoking a License Revoking a license permanently deactivates it. The worker using it will fail authentication at the next heartbeat and stop executing jobs. {% stepper %} {% step %} ### Find the license row Find the license row in the table. {% endstep %} {% step %} ### Open the Revoke action Click **Revoke** in the Actions column. {% endstep %} {% step %} ### Enter a revocation reason Enter a **revocation reason** (required — this is logged in the audit trail). {% endstep %} {% step %} ### Confirm revocation Click **Confirm Revoke**. {% hint style="warning" %} Revocation is permanent. A revoked license cannot be re-activated. You will need to generate a new license and reinstall the worker. {% endhint %} {% endstep %} {% endstepper %} *** ## Worker Detail Page — License Card On the **Worker Detail** page (`/worker/{id}`), a **License** card shows the license status for that specific worker: | State shown | What it means | | ----------------------- | --------------------------------------------------------------------------------------------------- | | **License assigned** | The worker holds an active license. Shows the masked key and assignment date. | | **No license assigned** | The worker is registered but does not have a license. It cannot authenticate until one is assigned. | | **License revoked** | The worker's license has been revoked. The worker will stop functioning. | A **Generate License** button is also available directly on the worker detail page. This opens the same generation dialog pre-filtered for that worker, and after generating, immediately offers to assign it. 📸 \[Screenshot placeholder: Worker detail page showing the License card with an active license] *** ## MSP Workflow — End-to-End Here is the complete workflow from first deployment to an operational worker. {% stepper %} {% step %} ### Worker is installed at customer site The engineer installs the Intune Assistant Worker on a server in the customer tenant. The worker registers itself and appears in your Worker Overview with status **Pending**. {% endstep %} {% step %} ### Approve the worker Go to **Worker > Overview**, find the new registration, and click **Approve**. Set a default sender email and recipient email for the worker (used by scheduled jobs unless overridden per-job). {% endstep %} {% step %} ### Generate a license Go to **Worker > Licenses**. Click **Generate License**. Fill in the recipient email (use the customer's IT contact). Copy the generated key immediately. {% endstep %} {% step %} ### Assign the license Either: * Click **Assign** on the new license row and select the worker from the dropdown. * Or hand the key to the engineer and have them paste it into the worker configuration. The worker will self-register the key on next startup. {% endstep %} {% step %} ### Worker is operational The worker's status changes to **Approved + Licensed**. It begins polling for jobs and executing scheduled reports. 📸 \[Screenshot placeholder: License table with one Assigned license and green quota bar] {% endstep %} {% endstepper %} *** ## Frequently Asked Questions
Can I move a license from one worker to another? No. Revoke the existing license and generate a new one for the destination worker.
What happens if a license expires? The worker will fail its next license validation check and stop accepting jobs. It will not be automatically removed from the system. Generate a new license and assign it to restore operation.
I lost the license key after generating it. What do I do? Revoke the lost license and generate a new one. The key cannot be recovered.
A customer has set up a worker without my involvement. Who manages the license? For MSP customers, all worker licenses are managed centrally through your MSP account. A non-MSP customer's workers are licensed by the platform administrator — the customer does not have access to the license management page.
My quota is full but I need another license. What do I do? Revoke any unused or obsolete licenses first. If you still need more, contact Intune Assistant support to increase your quota.
*** ## Related Pages * [Worker Overview](broken://pages/56a499d8e55c9c169303c3e21c137ec164aec1ad) — view and approve registered workers * [Worker Detail](broken://pages/1537c51b6d41fb29020c3d9fdfd36ddf460044ff) — manage a single worker, view license status * [Customer Information](broken://pages/6aa99cd7b1c1d9b02a56dadbe25212138b4b89bf) — view your subscription tier and license quota settings # Worker Templates ## What Is This Page? The **Job Templates** page is where reusable packages of worker jobs are created, published, adopted, and applied. A template bundles one or more job definitions — each with a job type, name, schedule, and default configuration — so that the same set of jobs can be deployed consistently across many workers without configuring each one by hand. There are two distinct roles in the template system: | Role | What They Do | | ------------------ | --------------------------------------------------------------------------------- | | **Platform Admin** | Creates and publishes platform templates to the shared MSP Library | | **MSP Admin** | Adopts templates from the library, creates their own, and applies them to workers | {% hint style="info" %} If you are a Platform Admin, see the [Platform Admin section](#platform-admin) below. If you are an MSP, see the [MSP Admin section](#msp-admin). {% endhint %} *** ## Platform Admin ### What Are Platform Templates? Platform templates are curated job packages that the Intune Assistant platform team creates and maintains. They represent best-practice configurations for common worker job scenarios. A platform template: * Is visible to MSPs only after it has been **published** to the library. * Can contain one or more job definitions (items), each specifying a job type, schedule, and default configuration values. * Acts as a reference point. When an MSP adopts a platform template, they receive an independent copy. Changes you make to the platform template after adoption do not affect MSP copies. *** ### Creating a Platform Template {% stepper %} {% step %} ## Open the Templates page Navigate to **Admin > Templates** (`/admin/templates`). {% endstep %} {% step %} ## Start a new template Click **New Template** in the top-right corner. A side panel opens on the right. {% endstep %} {% step %} ## Fill in the template details | Field | Required | Description | | --------------- | -------- | ------------------------------------------------------------------ | | **Name** | Yes | A short, descriptive name visible to MSPs in the library | | **Description** | No | A longer explanation of what this template does and when to use it | | {% endstep %} | | | {% step %} ## Create the template Click **Create Template** at the bottom of the side panel. The template is saved with `Published = No`. It is not yet visible to MSPs. You can now open it to add jobs. {% endstep %} {% endstepper %} *** ### Adding and Editing Jobs on a Template All job management happens inside the template's edit panel. Changes are staged locally and only sent to the server when you confirm them. {% stepper %} {% step %} ## Open the edit panel Click the **pencil icon** on the template card, or click **Edit jobs** in the jobs section of the card. The edit panel slides in from the right. {% endstep %} {% step %} ## Add a job Click **Add job** in the Jobs section of the panel. An inline form appears directly in the panel. | Field | Required | Description | | ------------ | -------- | --------------------------------------------------------------------- | | **Job Type** | Yes | The type of automated job (e.g., compliance report, device inventory) | | **Job Name** | Yes | A human-readable label for this job slot | | **Interval** | Yes | How often the job runs. Common values: Daily, Weekly, Monthly. | Click **Add job** to stage the new job. It appears in the list with a green **New** badge — it has not been saved yet. {% endstep %} {% step %} ## Edit or remove existing jobs Each job row has a pencil icon (edit) and an X icon (remove). * **Edit** — opens the inline form pre-filled with the job's current values. Changes are highlighted with an amber **Modified** badge. * **Remove** — marks the job with a red **Removed** badge and strikethrough. You can restore it before saving by clicking **Restore**. {% endstep %} {% step %} ## Review and save When you are done making changes, click **Review & Save** at the bottom of the panel. The panel switches to a review screen showing a summary of every change: modified properties, added jobs, removed jobs. Review the list, then click **Confirm & Save** to commit. Click **Back** to return to editing without saving. {% endstep %} {% endstepper %} {% hint style="info" %} You can add multiple jobs to a single template. Each job can have a different type and schedule. {% endhint %} {% hint style="info" %} If you close the panel with unsaved changes, you will be asked whether to discard them or keep editing. {% endhint %} *** ### Publishing a Template Publishing makes the template visible to MSPs in the template library. A template must be published before any MSP can adopt it. {% stepper %} {% step %} ## Open the template card Find the template in the list at **Admin > Templates**. {% endstep %} {% step %} ## Publish it Click **Publish** in the template card header. {% endstep %} {% step %} ## Confirm the status change The template status changes to **Published to Library** with a green badge. {% endstep %} {% endstepper %} {% hint style="warning" %} **Publishing is immediate and visible to all MSPs.** As soon as you publish, the template appears in every MSP's library tab. If the template is not ready, keep it in draft (unpublished) until it is. {% endhint %} *** ### Unpublishing a Template Unpublishing removes the template from the MSP library. MSPs who have already adopted it are not affected — their copies are independent. {% stepper %} {% step %} ## Open the template card Find the published template in the list. {% endstep %} {% step %} ## Unpublish it Click **Unpublish** in the template card header. {% endstep %} {% step %} ## Confirm the status change The status badge changes back to **Draft**. {% endstep %} {% endstepper %} {% hint style="info" %} Unpublishing does not delete any MSP copies. It only prevents new MSPs from finding the template in the library going forward. {% endhint %} *** ### Editing a Template To change a template's name, description, active status, or jobs, click the **pencil icon** on the template card. The edit panel opens on the right. All changes — including property edits and job add/edit/remove — are staged locally inside the panel. Nothing is saved until you click **Review & Save** and confirm on the review screen. {% hint style="info" %} Editing a platform template does not change any MSP copies. MSP copies are taken at adoption time and are isolated from future platform changes. {% endhint %} *** ### Deleting a Template {% stepper %} {% step %} ## Find the template Find the template in the list at **Admin > Templates**. {% endstep %} {% step %} ## Open the delete panel Click the **trash icon** on the template card. A side panel opens asking you to confirm. {% endstep %} {% step %} ## Confirm the deletion Review the warning in the panel, then click **Delete Template**. {% endstep %} {% endstepper %} {% hint style="warning" %} Deleting a platform template is permanent. The platform template is removed from the admin view and from the library. However, any MSP copies that were created by adopting this template continue to exist and function normally. MSPs will not be notified that the source template was deleted. {% endhint %} *** ## MSP Admin ### The Template Library Tab The **Library** tab shows all platform templates that: * Have been published by the platform team. * Have not yet been adopted by your organisation. Once you adopt a template it moves out of the Library tab and appears in your **My Templates** tab. The Library tab only shows templates that are still available for you to adopt. *** ### Adopting a Template from the Library Adopting a template creates your own private copy of a platform template. Your copy is completely independent — the platform team cannot modify it after you adopt it. {% stepper %} {% step %} ## Open the Library tab Go to **Worker > Templates** and open the **Library** tab. {% endstep %} {% step %} ## Adopt the template Find the template you want and click **Adopt**. {% endstep %} {% step %} ## Wait for confirmation The button shows a loading spinner while the copy is created. When done, the view automatically switches to **My Templates** where your new copy appears with an **Adopted** badge. {% endstep %} {% endstepper %} {% hint style="info" %} You can only adopt each platform template once. If the Adopt button is not visible, you have already adopted this template. {% endhint %} {% hint style="info" %} After adopting, the template is yours to edit freely. Add jobs, remove jobs, change the name — none of these changes affect the original platform template or any other MSP's copy. {% endhint %} *** ### My Templates Tab The **My Templates** tab shows all templates owned by your organisation. This includes: * Templates you adopted from the library. * Templates you created from scratch. Each template card shows the template name, version, jobs, and status badges. *** ### Creating a Template from Scratch {% stepper %} {% step %} ## Open My Templates Go to **Worker > Templates** and open the **My Templates** tab. {% endstep %} {% step %} ## Create a new template Click **New Template** in the top-right corner. A side panel opens on the right. {% endstep %} {% step %} ## Fill in the fields | Field | Required | Description | | --------------- | -------- | ----------------------------- | | **Name** | Yes | Display name for the template | | **Description** | No | What this template is for | | {% endstep %} | | | {% step %} ## Create the template Click **Create Template** at the bottom of the panel. The template is created empty (no jobs). Open the edit panel to add jobs before applying it to a worker. {% endstep %} {% endstepper %} *** ### Adding and Editing Jobs on Your Template {% stepper %} {% step %} ## Open the edit panel Click the **pencil icon** on the template card, or click **Edit jobs** in the jobs section. The edit panel slides in from the right. {% endstep %} {% step %} ## Add a job Click **Add job** inside the panel. Fill in the inline form: | Field | Required | Description | | ------------ | -------- | ----------------------------------------------------- | | **Job Type** | Yes | The type of automated job | | **Job Name** | Yes | A human-readable label for this job slot | | **Interval** | Yes | How often the job runs (Daily, Weekly, Monthly, etc.) | Click **Add job** in the form to stage it. A green **New** badge marks it as pending. {% endstep %} {% step %} ## Edit or remove existing jobs Use the pencil icon to edit a job inline, or the X icon to mark it for removal. Removed jobs show a strikethrough and a red **Removed** badge — click **Restore** to undo before saving. {% endstep %} {% step %} ## Review and save Click **Review & Save**. The panel shows a summary of all staged changes. Click **Confirm & Save** to commit, or **Back** to keep editing. {% endstep %} {% endstepper %} {% hint style="success" %} **Auto-sync on add:** When you add a job to a template that is already applied to one or more workers, the new job is automatically pushed to those workers immediately. You do not need to re-apply the template. {% endhint %} {% hint style="success" %} **Auto-sync on remove:** Removing a job from a template automatically disables that job on all workers the template has been applied to. The job history on each worker is preserved — it is disabled, not deleted. {% endhint %} {% hint style="info" %} If you close the panel with unsaved changes, you will be asked whether to discard them or keep editing. {% endhint %} *** ### Applying a Template to a Worker Applying a template stamps it onto a specific worker — it creates one job configuration row on the worker for each job in the template. {% stepper %} {% step %} ## Open the template Find the template in **My Templates**. {% endstep %} {% step %} ## Start the apply flow Click **Apply** on the template card. A side panel opens on the right. {% endstep %} {% step %} ## Select a worker and optional overrides Select the target worker from the dropdown. The dropdown shows only approved workers belonging to your organisation. Optionally override the email settings: | Field | Description | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Recipient Email Override** | If set, all jobs from this template on this worker send reports to this address. | | **Sender Email Override** | If set, this address is used as the sender for all jobs from this template on this worker, overriding the worker's default sender address. | | {% endstep %} | | {% step %} ## Apply the template Click **Apply** at the bottom of the panel. The worker immediately receives the new job configurations. The panel shows a success confirmation when done. {% endstep %} {% endstepper %} {% hint style="warning" %} **Applying the same template to the same worker twice is blocked.** If the template is already applied to a worker (with at least one enabled job), the Apply action will return an error. To change job configurations on an already-applied template, use the edit panel to add or remove jobs — those changes auto-sync. {% endhint %} *** ### Template Status Badges Templates in the **My Templates** list show status badges: | Badge | Meaning | | -------------------- | ---------------------------------------------------------------------------------------- | | **Adopted** | The template was adopted from the platform library | | **Update available** | The platform template has been updated since you adopted it; you can sync the changes | | **Inactive** | The template is disabled; it cannot be applied but existing applied jobs continue to run | *** ## Versioning ## Frequently Asked Questions
Will platform template updates affect my adopted copy? No. When you adopt a template, you receive a complete independent copy. Any changes the platform team makes to the original template after your adoption — adding jobs, removing jobs, renaming it — have no effect on your copy.
Can I edit an adopted template? Yes. After adoption, the template belongs to your organisation. You can rename it, change the description, add new jobs, and remove jobs using the edit panel. There is no link back to the platform original.
What happens to worker jobs if I delete a template? If you delete a template from **My Templates**, the template definition is removed. However, the job configuration rows that were already created on workers are not automatically disabled at deletion time. Check your workers' job lists after deleting a template if you need to clean up running jobs manually. {% hint style="info" %} Contrast this with removing an individual job (item) from a template via the edit panel — that action does auto-sync and disables the matching jobs on affected workers. {% endhint %}
I added a job to my template but one of my workers did not receive it. Why? Auto-sync only pushes to workers that had the template applied before you added the job. If a worker was never given this template, it will not receive the new job. Apply the template to that worker separately.
Can I apply a template to more than one worker? Yes. Apply the template to each worker individually using the **Apply** action on the template card. Each worker gets its own independent set of job config rows, and each can have different email overrides.
Can I see which workers a template is applied to? Expand the **Workers** section at the bottom of a template card to see all workers the template has been applied to, along with their current job status.
What does the Sender Email Override do? By default, jobs use the sender address configured on the worker control record. The override lets you specify a different address for all jobs from this template on a particular worker without changing the worker's global sender address.
I closed the edit panel and lost my changes. What happened? When you close the edit panel with unsaved changes, a prompt asks whether to discard or keep editing. If you clicked **Discard**, the staged changes were cleared. Changes are only persisted when you complete the **Review & Save** → **Confirm & Save** flow.
*** ## Related Pages * [Worker Overview](broken://pages/800c082b6c3a4115dd5f7320b9a76d5f7d9713ce) — view and approve registered workers * [Worker Licenses](broken://pages/32f51ba6d4e454646e37cfc6d9b374a6f1db61f1) — manage worker licenses * [Job Templates Architecture](broken://pages/678f0a4a790420d6e0275858afdea9fcc409a804) — technical reference for developers # User Access Control & PIM Integration ## User Access Control & PIM Integration Configure secure multi-user access with role-based permissions and Privileged Identity Management ## [User Access Control & PIM Integration](#user-access-control--pim-integration) Intune Assistant supports secure multi-user environments through proper access control and integration with Microsoft Entra Privileged Identity Management (PIM). ### [Access Control Overview](#access-control-overview) #### [Default Behavior](#default-behavior) * Only the user who completes onboarding can initially access Intune Assistant, except when a user consents the app registrations for the whole organization. * The service principal is created with restricted access by default * Additional users must be explicitly granted access {% hint style="danger" %} However, Intune Assistant has delegated permissions and acts like the current logged in user, it is HIGHLY recommended to NOT consent the app registrations for the whole organisation. By default it is only consented for the user that runs the onboarding process.\ \ The builder is NOT responsible for any security related misconfiguration. {% endhint %} #### [Security Principles](#security-principles) * **Least Privilege**: Grant minimum required access * **Explicit Assignment**: Never rely on organization-wide consent * **Role-Based Access**: Use PIM for time-limited administrative access ### [User Assignment Methods](#user-assignment-methods) #### [Method 1: Direct User Assignment](#method-1-direct-user-assignment) {% stepper %} {% step %} ### Navigate to Microsoft Entra ID * Go to [Azure Portal](https://portal.azure.com/) or [Entra Admin Center](https://entra.microsoft.com/) * Select **Enterprise Applications** {% endstep %} {% step %} ### Locate Intune Assistant Service Principals * Search for "Intune Assistant" * You'll find two applications: * **Intune Assistant** (Main Application) * **Intune Assistant API** (Backend Service) {% endstep %} {% step %} ### Assign Users to Both Applications * Assign users to both the Intune Assistant and Intune Assistant API applications as needed. {% endstep %} {% endstepper %} [Managing Admin Consent\ \ Handle consent requirements when new permissions are added to IntuneAssistant](broken://pages/3285781e772e72eb9ead78862e26a5bfe729c13e) [Data & Privacy\ \ Our commitment to data privacy and security with minimal data storage and no data leaving your tenant](/security-and-compliance/data-and-privacy) # Role Based Access (RBAC) ## Overview Intune Assistant uses **role-based access control (RBAC)** to determine what each user can see and do inside the platform. Roles are assigned by your organisation's administrator and control access to features such as worker management, license handling, and job configuration. Roles are managed entirely through **Microsoft Entra ID** — there is no separate role management screen inside Intune Assistant itself. *** ## Available Roles Intune Assistant defines two roles for external organisations: | Role | Intended for | What it enables | | ----------------- | --------------------------------------- | ------------------------------------------------------------------------------ | | **MspAdmin** | Managed Service Provider administrators | Full management of workers, licenses, job templates, and customer environments | | **CustomerAdmin** | End-customer IT administrators | Read and manage the worker deployed in your own organisation | {% hint style="info" %} Role names are case-sensitive when assigned in Entra ID. Use exactly `MspAdmin` and `CustomerAdmin`. {% endhint %} *** ## Role Descriptions ### MspAdmin — Managed Service Provider Administrator This role is designed for administrators at an MSP or IT service provider who manage Intune Assistant on behalf of one or more customer organisations. **An MspAdmin can:** * View and manage all workers deployed across their customer environments * Generate, assign, and revoke worker licenses * Create and manage job templates for scheduled automation tasks * Configure default email settings for worker notifications * Approve and reject new worker registrations * Trigger jobs manually or adjust schedules **An MspAdmin cannot:** * Access platform-level administration (reserved for Intune Assistant internally) * Manage another MSP's workers or licenses *** ### CustomerAdmin — Customer Administrator This role is designed for IT administrators at an end-customer organisation who need visibility into and control over the Intune Assistant worker running in their own environment. **A CustomerAdmin can:** * View the worker deployed in their organisation * See job history and execution results * Manage job schedules and settings for their own worker * View license information for their environment **A CustomerAdmin cannot:** * Manage workers or licenses in other organisations * Create or modify job templates * Generate or revoke licenses *** ## How Role Assignment Works Roles are assigned through **Microsoft Entra ID** — specifically through the Enterprise Application for Intune Assistant in your tenant. ### If you are an MSP assigning roles to your own team 1. Sign in to the [Azure portal](https://portal.azure.com/) with a Global Administrator or Privileged Role Administrator account 2. Go to **Microsoft Entra ID** → **Enterprise applications** 3. Search for **Intune Assistant** and open it 4. Go to **Users and groups** → **Add user/group** 5. Select the user or group you want to assign a role to 6. Under **Select a role**, choose `MspAdmin` 7. Click **Assign** The user will have the role on their next sign-in. Existing sessions are not affected — they need to sign out and back in for the change to take effect. ### If you are a customer assigning roles to your IT team Follow the same steps above, but select `CustomerAdmin` as the role. Your organisation must have already completed the Intune Assistant onboarding and admin consent process before roles can be assigned. *** ## Role Hierarchy Roles are cumulative — a higher role includes everything a lower role can do: ``` MspAdmin └─ includes everything CustomerAdmin can do, plus MSP-level management ``` There is no need to assign both roles to the same user. *** ## Frequently Asked Questions
Can I assign roles to a group instead of individual users? Yes. In step 4 above, select a group instead of a user. All members of that group will inherit the role.
How long does it take for a role assignment to take effect? Immediately for new sign-ins. Users who are already signed in need to sign out and back in to receive the new role.
What happens if I remove a role from a user? The change takes effect on their next sign-in. Their current session continues to work until the token expires (typically within one hour).
Can a customer assign the MspAdmin role to themselves? A customer tenant administrator can technically assign any role visible in their Enterprise Application. However, the MspAdmin role only grants MSP-level access within Intune Assistant if the organisation is registered as an MSP in the platform. Assigning the role label alone has no effect for non-MSP organisations.
Who can see my role assignments? Only administrators in your own Entra ID tenant with access to Enterprise Applications can see role assignments. Intune Assistant does not display or expose role assignment information in the UI.
# Needed Permissions Intune Assistant ## Needed Permissions Complete guide to configuring granular permissions for Intune Assistant users ## [Permissions Overview](#permissions-overview) Learn how to configure the required permissions for Intune Assistant and how to set up granular permissions for users in your organization. ### [Required Graph API Permissions](#required-graph-api-permissions) Intune Assistant requests Microsoft Graph API permissions in stages: a core set the first time you sign up, and a couple of extra permissions the first time you use a feature that needs them. If you see a consent prompt again after your initial setup, it's one of these additional feature requests — not a repeat of something you already granted. #### Core permissions (requested when you sign up) | Permission | Type | Description | | ----------------------------------------- | -------------- | ----------------------------------------------------- | | `Group.Read.All` | Delegated | Read group memberships and properties | | `GroupMember.Read.All` | Delegated | Read group membership relationships | | `User.ReadBasic.All` | Delegated | Read basic user information like name and email | | `RoleManagement.Read.Directory` | Delegated | Read Microsoft Entra ID directory role assignments | | `AuditLog.Read.All` | Delegated | Read Microsoft Entra ID and Intune audit logs | | `Directory.AccessAsUser.All` | Delegated only | Access directory data on behalf of the signed-in user | | `DeviceManagementConfiguration.Read.All` | Delegated | Read Intune configuration profiles and baselines | | `DeviceManagementScripts.Read.All` | Delegated | Read PowerShell and shell scripts | | `DeviceManagementRBAC.Read.All` | Delegated | Read Intune role-based access control assignments | | `DeviceManagementApps.Read.All` | Delegated | Read managed applications and app configurations | | `DeviceManagementServiceConfig.Read.All` | Delegated | Read device management service configuration | | `DeviceManagementManagedDevices.Read.All` | Delegated | Read managed device inventory | | `Policy.Read.ConditionalAccess` | Delegated | Read Conditional Access policies | | `ConfigurationMonitoring.ReadWrite.All` | Delegated | Create and manage configuration drift monitors | Mostly read-only Most core permissions are read-only. Two exceptions: `Directory.AccessAsUser.All` lets Intune Assistant act on Microsoft Graph on your behalf using your own directory permissions, and `ConfigurationMonitoring.ReadWrite.All` is needed for Drift Monitoring, which is included free with every account. #### Drift Monitoring permissions (requested the first time you set up a monitor) Drift Monitoring is free and included with every account, but it needs two extra permissions the first time you configure a monitor, so it can create and manage the background service account that watches for configuration changes: | Permission | Type | Description | | --------------------------------- | --------- | -------------------------------------------------------------------------- | | `Application.ReadWrite.All` | Delegated | Create and manage the background service account used for drift monitoring | | `AppRoleAssignment.ReadWrite.All` | Delegated | Assign the permissions that background service account needs to operate | #### Assignments Manager permissions (requested if you purchase this module) Assignments Manager needs write access to manage and migrate policy assignments, in addition to the core permissions above: | Permission | Type | Description | | --------------------------------------------- | --------- | --------------------------------------------------------- | | `DeviceManagementConfiguration.ReadWrite.All` | Delegated | Create, update, and migrate Intune configuration profiles | | `DeviceManagementApps.ReadWrite.All` | Delegated | Create, update, and migrate app assignments | | `DeviceManagementServiceConfig.ReadWrite.All` | Delegated | Update device management service configuration | | `DeviceManagementScripts.ReadWrite.All` | Delegated | Create, update, and migrate PowerShell and shell scripts | | `DeviceManagementRBAC.ReadWrite.All` | Delegated | Update Intune role-based access control assignments | ### [Configuring Granular User Permissions](#configuring-granular-user-permissions) Instead of giving users full Intune Administrator permissions, you can configure granular role-based access control (RBAC) permissions. This follows the principle of least privilege. #### [Understanding Intune RBAC](#understanding-intune-rbac) Microsoft Intune uses role-based access control to determine what actions users can perform. Each role contains: * **Permissions**: What actions can be performed * **Scope**: Which resources the role applies to * **Assignments**: Which users or groups have the role #### [Required Intune Roles for Intune Assistant](#required-intune-roles-for-intune-assistant) Since Intune Assistant only reads data, users need roles with **read permissions** for the following categories: [**Device Configuration Reader**](#device-configuration-reader) Allows reading device configuration profiles and compliance policies. **Required permissions:** * Device configuration policies: **Read** * Device compliance policies: **Read** * Device enrollment: **Read** [**Application Reader**](#application-reader) Allows reading application management data. **Required permissions:** * Mobile applications: **Read** * Mobile application management policies: **Read** [**Reports Reader**](#reports-reader) Allows reading reports and analytics data. **Required permissions:** * Reports: **Read** [**Conditional Access Reader**](#conditional-access-reader) Allows reading Conditional Access policies. **Required permissions:** * Conditional Access: **Read** #### [Creating a Custom Role](#creating-a-custom-role) For optimal security, create a custom role with only the required read permissions: {% stepper %} {% step %} ### Navigate to Microsoft Intune admin center * Go to [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) * Select **Tenant administration** > **Roles** > **All roles** {% endstep %} {% step %} ### Create new role * Click **Create** * Enter role name: `Intune Assistant Reader` * Add description: `Read-only access for Intune Assistant users` {% endstep %} {% step %} ### Configure permissions * **Device configuration policies**: Read ✓ * **Device compliance policies**: Read ✓ * **Device enrollment**: Read ✓ * **Mobile applications**: Read ✓ * **Mobile application management policies**: Read ✓ * **Reports**: Read ✓ * **Organization**: Read ✓ {% endstep %} {% step %} ### Set scope and assignments * Define which users/groups should have this role * Set appropriate scope tags if needed {% endstep %} {% endstepper %} #### [Built-in Roles Alternative](#built-in-roles-alternative) If you prefer using built-in roles, assign users to: * **Intune Service Administrator** (full read/write - not recommended) * **Reports Reader** (limited to reports only) * **Global Reader** (read access across Microsoft 365) Recommended approach We recommend creating a custom role with only the required read permissions to follow the principle of least privilege. ### [Troubleshooting](#troubleshooting) Common permission issues: | Issue | Solution | | ----------------------------- | ---------------------------------------------------------- | | User cannot see any data | Check if user has required Intune role assigned | | Missing device configurations | Verify `DeviceManagementConfiguration.Read.All` permission | | Missing applications | Check `DeviceManagementApps.Read.All` permission | ### [Consent missing](#consent-missing) Intune Assistant requires admin consent for the Graph API permissions. Ensure that a Global Administrator has granted consent for the application in your tenant. New features may require additional permissions, if a required consent is missing you will get notified in the right bottom corner. (see the screenshot below) Then run the consent again. For information about that process, check the [Managing Admin Consent](broken://pages/3285781e772e72eb9ead78862e26a5bfe729c13e) documentation. ### [Additional Resources](#additional-resources) * [Microsoft Intune RBAC Reference](https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control-reference) * [Create custom roles in Intune](https://learn.microsoft.com/en-us/intune/fundamentals/create-custom-role) * [Scope tags for distributed IT](https://learn.microsoft.com/en-us/intune/fundamentals/scope-tags) Best practice Regularly review and audit user permissions to ensure they align with current job responsibilities and security requirements. # API Endpoint Authorization Matrix # Data & Privacy ## Data & Privacy Our commitment to data privacy and security with minimal data storage and no data leaving your tenant ## [Data & Privacy](#data--privacy) Intune Assistant is built with privacy by design. The core principle is that **your data stays in your tenant** - everything is processed in session memory and stored only the absolute minimum required for licensing and identification. ### [Our Privacy Commitment](#our-privacy-commitment) Zero Data Extraction **No data leaves your tenant.** All Intune and Graph API data is processed in browser session memory only and never stored or transmitted to external systems. ### [Data Storage & Processing Overview](#data-storage--processing-overview) #### [Minimal Data Storage Approach](#minimal-data-storage-approach) There is a very strict minimal data storage policy with complete transparency about what is stored and why: | Data Type | Stored | Purpose | Retention | | ----------------------------------- | ------ | ------------------------------------------------------------------------------------- | ---------- | | **Tenant ID** | ✅ Yes | Identify tenant and enforce fair-usage licensing. (Access can be denied by Tenant ID) | Persistent | | **Tenant Domain** | ✅ Yes | Display and licensing identification | Persistent | | **Session Data** (tokens, settings) | ❌ No | Stored only in browser session storage | Temporary | | **Intune Data** | ❌ No | Processed in session memory only, never persisted | N/A | | **Graph API Data** | ❌ No | Processed in session memory only, never persisted | N/A | | **User's Device Information** | ❌ No | Never accessed or stored | N/A | | **User Personal Data** | ❌ No | Never accessed or stored | N/A | ### [How We Process Your Data](#how-we-process-your-data) #### [Data Flow Principles](#data-flow-principles) {% stepper %} {% step %} ### Request Processing * API calls made directly to your tenant's Graph API * Data retrieved and processed in memory only * Results displayed immediately to your browser {% endstep %} {% step %} ### No Persistence * API responses processed and immediately discarded * No database storage of any tenant-specific data * No caching beyond browser session storage {% endstep %} {% step %} ### Session Management * Authentication tokens stored only in browser session * Session data cleared automatically on logout * No server-side session persistence {% endstep %} {% endstepper %} Browser session storage is used for temporary data like UI preferences and navigation state. This data is automatically cleared when you go to another page, close your browser or log out. ### [Data Security Measures](#data-security-measures) #### [Technical Safeguards](#technical-safeguards) * **HTTPS Encryption** - All communications encrypted in transit * **No Database Storage** - No persistent storage of tenant data, except tenant Id and tenant domain * **Memory-Only Processing** - All operations performed in volatile memory * **Automatic Cleanup** - Memory cleared after each operation * **Session Isolation** - Each session completely isolated from others #### [Access Controls](#access-controls) * **Microsoft Identity** - Authentication through your tenant's identity provider * **GDAP Compliance** - Granular delegated admin privileges for MSPs * **Role-Based Access** - Permissions enforced through your tenant's RBAC * **No Backdoors** - No administrative access to your tenant data #### [Compliance Standards](#compliance-standards) * **GDPR Compliant** - Privacy by design approach * **Microsoft Security Standards** - Built on Microsoft's security framework * **Industry Best Practices** - Following established security guidelines * **Regular Security Reviews** - Continuous security assessment and improvement ### [MSP Privacy Considerations](#msp-privacy-considerations) #### [Multi-Tenant Data Isolation](#multi-tenant-data-isolation) For MSP environments, we ensure complete data isolation: * **Tenant-Specific Processing** - Each customer tenant processed independently * **No Cross-Tenant Data** - No mixing of data between customer tenants * **GDAP Respect** - Only access data according to granted permissions #### [Customer Data Protection](#customer-data-protection) * **Customer Consent** - All access based on explicit GDAP permissions * **Limited Scope** - Only access data necessary for granted roles * **No Data Sharing** - No sharing of customer data between tenants or MSPs ### [Your Rights and Controls](#your-rights-and-controls) #### [Data Control](#data-control) * **Full Control** - You maintain complete control over your tenant data * **Access Management** - Control application access through Azure AD * **Permission Granularity** - Grant only necessary permissions * **Revoke Access** - Instantly revoke application access at any time #### [Transparency](#transparency) * **Open Source** - Application code (Webinterface) available for review * **Clear Documentation** - Complete transparency about data handling * **No Hidden Processes** - All data processing clearly documented * **Regular Updates** - Privacy policy updates communicated clearly #### [Technical Questions](#technical-questions)
How do you handle authentication tokens? Authentication tokens are stored only in your browser's session storage and are never transmitted to our servers or stored persistently.
Is my data encrypted? All communication is encrypted via HTTPS. Since we don't store your data, there's no data at rest to encrypt.
Can other users see my data? No, all data processing is isolated per user session. No data is shared between users or stored centrally.
*** Privacy Promise **Your data stays with you.** We're committed to keeping your Microsoft tenant data exactly where it belongs - in your tenant, under your control. # Intune Assistant Privacy Policy ## Privacy Policy – IntuneAssistant Worker ### 1. Introduction This Privacy Policy describes how IntuneAssistant ("we", "our", or "us") processes personal data in relation to the IntuneAssistant Worker and the IntuneAssistant platform. The IntuneAssistant Worker is deployed within the customer’s Azure environment and executes tasks locally within the customer tenant. This policy explains what data is processed, how it is used, and what responsibilities apply to both IntuneAssistant and the customer. *** ### 2. Roles and Responsibilities In the context of data protection laws (including GDPR): * The **Customer** acts as the **data controller** for data processed within their Microsoft 365 and Azure environment. * IntuneAssistant acts as a **data processor** for data processed as part of providing the IntuneAssistant platform and services. The IntuneAssistant Worker operates within the customer’s tenant and executes tasks on behalf of the customer. *** ### 3. Data Processing Overview #### 3.1 Data processed within the customer tenant The IntuneAssistant Worker executes tasks locally (Azure tenant) and may access data available through Microsoft Graph APIs, including: * Device and configuration data (Intune) * User and group information * Policy and assignment data * Audit and activity data This data: * Remains within the customer’s tenant during execution * Is processed under the permissions assigned by the customer * Is not accessed directly by IntuneAssistant systems unless explicitly required for functionality *** #### 3.2 Data processed by IntuneAssistant platform The IntuneAssistant platform may process limited data required to provide the service, such as: * Task metadata and execution status * Aggregated results of executed tasks * Configuration settings related to the service * Customer account and tenant identifiers * Diagnostic and telemetry data (e.g. errors, performance metrics) *** #### 3.3 Support data If the customer engages support, additional data may be processed, such as: * Logs provided by the customer * Error messages and diagnostic output * Configuration details relevant to the issue This data is only used for support purposes. *** ### 4. Purpose of Processing We process data solely for the purpose of: * Delivering the IntuneAssistant service * Executing automation, reporting, and monitoring tasks * Providing insights and visibility into Intune environments * Maintaining and improving service performance and reliability * Providing customer support *** ### 5. Legal Basis for Processing Processing of personal data is based on: * Performance of a contract (service delivery) * Legitimate interests (service improvement, security, diagnostics) * Compliance with legal obligations (where applicable) The customer is responsible for ensuring a valid legal basis for any data processed within their tenant. *** ### 6. Data Sharing and Subprocessors We do not sell or share customer data with third parties for marketing purposes. We may use subprocessors to deliver the service (e.g. cloud hosting providers). These subprocessors: * Are contractually bound to data protection obligations * Only process data as necessary to provide the service A current list of subprocessors is available upon request. *** ### 7. Data Transfers Data may be processed in regions where our infrastructure is hosted. Where applicable, we ensure appropriate safeguards are in place, such as Standard Contractual Clauses (SCCs), in accordance with GDPR requirements. *** ### 8. Data Retention We retain data only as long as necessary to provide the service, including: * Active subscription period * Reasonable period for support and diagnostics * Legal or regulatory requirements Customers may request deletion of their data where applicable. *** ### 9. Security Measures We implement appropriate technical and organizational measures to protect data, including: * Secure authentication using Managed Identity * Encryption in transit * Access controls and least-privilege principles * Monitoring and logging for security purposes The customer is responsible for securing their Azure environment and access configurations. *** ### 10. Customer Responsibilities Customers are responsible for: * Configuring permissions assigned to the worker * Ensuring compliance with applicable data protection laws * Managing user access and data within their tenant * Reviewing and approving automation tasks where applicable *** ### 11. Data Subject Rights Data subjects may have rights under applicable data protection laws, including: * Access * Rectification * Erasure * Restriction of processing * Data portability Requests should be directed to the Customer (data controller). IntuneAssistant will assist where required. *** ### 12. Changes to this Policy We may update this Privacy Policy from time to time. Updates will be published at the same URL. # Support ## Support Get help and report issues for Intune Assistant ## [Support](#support) Need help with Intune Assistant? We're here to assist you! ### [Getting Help](#getting-help) For support, bug reports, and feature requests, please visit our GitHub repository and create an issue. **GitHub Issues**: ### [What to Include](#what-to-include) When creating an issue, please provide: #### [For Bug Reports](#for-bug-reports) * **Description**: Clear description of the issue * **Steps to reproduce**: What you were doing when the issue occurred * **Expected behavior**: What you expected to happen * **Screenshots**: If applicable, add screenshots to help explain the problem * **Environment**: Browser version, operating system, etc. #### [For Feature Requests](#for-feature-requests) * **Description**: Clear description of the feature you'd like to see * **Use case**: Why would this feature be useful? * **Alternative solutions**: Any workarounds you've considered #### [For Questions](#for-questions) * **Context**: What are you trying to accomplish? * **What you've tried**: Any solutions you've already attempted This project is maintained by volunteers. Response times may vary based on availability and complexity of the issue. ### [Before Creating an Issue](#before-creating-an-issue) Please check if your issue already exists by searching through [existing issues](https://github.com/srozemuller/IntuneAssistant/issues?q=is%3Aissue). *** Thank you for using Intune Assistant! Your feedback helps make the project better for everyone. [Frequently Asked Questions\ \ Common questions and answers about Intune Assistant](/getting-started/frequently-asked-questions) # Message Center ## What Is the Message Center? The **Message Center** is where the IntuneAssistant platform communicates directly with you. It carries platform-wide announcements from the IntuneAssistant team — scheduled maintenance windows, newly released features, security-related warnings, and general information messages. Messages are **filtered by your license server-side**. This means you only ever see messages that are relevant to your subscription level and the features you have access to. There is nothing to configure — the right messages arrive automatically. Read and unread state is tracked **in your browser**. No personal preference data is sent to the server. When you mark a message as read or unread, that choice is stored locally and survives page navigation within the same session and across sessions on the same browser. ## Why Would You Use This? * You want to know whether the platform has scheduled downtime before you run a large bulk operation * You spotted a new feature in the navigation and want to understand what it does * You received a warning indicator on your avatar and want to see what it refers to * You are handing over a tenant to a colleague and want to make sure they are aware of any active notices ## How to Get There Navigate to **Message Center** using any of these routes: | Entry point | How | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Sidebar menu** | Expand the user section at the bottom of the sidebar and click **Message Center** | | **Avatar badge** | When unread messages exist, a pulsing orange dot appears on your avatar — click it to open the user menu, then click **Message Center** | | **User dropdown** | Click your name or avatar at the bottom of the sidebar → **Message Center** in the dropdown | ## The Unread Indicator Whenever you have unread messages, IntuneAssistant surfaces a visual indicator in three places simultaneously so you never miss an important notice: | Location | What You See | | --------------------------------------- | ------------------------------------------------------------------------- | | **Avatar (sidebar trigger)** | A pulsing orange dot at the top-right corner of your avatar circle | | **Display name row (expanded sidebar)** | A small orange pill showing the unread count next to your name — e.g. `3` | | **Message Center item in the dropdown** | A `Bell` icon with an orange count badge inline — e.g. `Message Center 3` | All three indicators disappear as soon as `unreadCount` reaches zero, which happens automatically when you mark all messages as read. > ## Page Layout The Message Center page is divided into three areas: the page header, the filter tabs, and the message list. ### Page Header The header shows the page title and the total unread count. When unread messages exist, an orange pill appears directly after the title text — for example, **Message Center `4`**. A **Refresh** button on the right re-fetches messages from the API immediately. This is useful if you have been told that a new message has been published and it has not appeared yet. ## Filter Tabs Six tabs let you narrow the list to exactly the messages you are interested in: | Tab | What It Shows | | --------------- | ----------------------------------------------------------------------------------------- | | **All** | Every message available to your account, regardless of read state or type | | **Unread** | Only messages you have not yet marked as read — the orange count matches the avatar badge | | **Maintenance** | Only scheduled maintenance notices | | **Feature** | Only feature announcements | | **Warning** | Only warning messages requiring your attention | | **Information** | Only general information messages | Each tab shows a live count badge next to the label. The **Unread** count badge is orange; all others are muted grey. Switching tabs clears any active selection. > ## Message Cards Each message is displayed as a card with a coloured left border that immediately communicates its type. The colour coding is consistent across the entire application: | Type | Left border | | --------------- | ----------- | | **Information** | Blue | | **Warning** | Amber | | **Maintenance** | Purple | | **Feature** | Green | ### What Each Card Shows | Element | Description | | --------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Title** | The message headline in bold | | **Type badge** | Small inline badge showing `Information`, `Warning`, `Maintenance`, or `Feature` | | **Description** | The full message body — multi-line text is preserved as written | | **Timestamp** | Relative time — e.g. `3 hours ago`, `2 days ago` | | **Expiry date** | If the message has an expiry, shown as `Expires 25 May 2026`. Warning expiry dates are highlighted in amber to draw attention | | **Unread dot** | A small filled orange circle at the top-right corner — present on unread messages, absent once read | > ## Selecting Messages Click anywhere on a card to select it. Click again to deselect. There is no separate checkbox — the entire card surface is the selection target. **Selected state** — a primary-coloured ring wraps the card and a small animated checkmark circle appears at the top-left corner. The unread orange dot is hidden while a card is selected to avoid visual conflict. **Select all** — a small square toggle in the toolbar (visible when the list is not empty) selects or deselects all currently visible messages at once. It reflects the current selection state: filled when all are selected, empty otherwise. > ## Toolbar Actions The toolbar appears below the filter tabs whenever the message list is not empty. It shows the selection toggle, a selection count, and the available actions. | Button | When It Is Enabled | What It Does | | -------------------- | --------------------------------------------------- | ------------------------------------------------------------------------ | | **Mark as read** | At least one selected message is currently *unread* | Adds the selected IDs to the read list — their orange dots disappear | | **Mark as unread** | At least one selected message is currently *read* | Removes the selected IDs from the read list — their orange dots reappear | | **Mark all as read** | `unreadCount > 0` (regardless of selection) | Marks every message in the current list as read in one action | Both **Mark as read** and **Mark as unread** can be enabled at the same time when your selection contains a mix of read and unread messages. After either action the selection is cleared automatically. ## How Read State Works Read and unread state is stored entirely in your browser's `localStorage` under the key `ia_message_center_read_ids`. The value is a JSON array of message UUID strings. **What this means in practice:** * Marking a message as read on your laptop does not affect how it appears on your phone or in another browser * Clearing your browser data resets all read state — all messages will appear unread again * The platform never knows which messages you have or have not read The unread count shown on your avatar, in your display name row, and in the Message Center dropdown item is always calculated live from this local list against the messages currently returned by the API. # Changelog Release history for IntuneAssistant. * [v1.26.09](https://github.com/srozemuller/IntuneAssistant.Backend/tree/main/IntuneAssistant.Docs/public/support/changelog/v1.26.09.md) — 🚧 Release Candidate — Duplicate Devices, Backup & Restore, Device Compare, Group to Filter Analyzer * [v1.26.05](/support/changelog/v1.26.05) — Message Center, assignment updates * [v1.26.04](/support/changelog/v1.26.04) — MSP support, Drift Monitoring, Policy Comparison Tools * [v1.26.03](/support/changelog/v1.26.03) — Configuration Drift Monitoring, Audit Events * [v1.26.02](/support/changelog/v1.26.02) — Group assignment endpoint, autopilot profile resources For the full release history, including pre-releases, see the [GitHub Releases page](https://github.com/srozemuller/IntuneAssistant.Backend/releases). # v1.26.09 ## v1.26.09 🚧 RELEASE CANDIDATE (v1.26.09-rc.3) Highlights for this release of IntuneAssistant. ## New * **Duplicate Devices Detection and Removal** * IntuneAssistant now finds Intune devices that are duplicates of each other (matched by serial number or Wi-Fi MAC address) and lists them on a new Devices > Duplicates page. Viewing duplicates is free for everyone; removing a duplicate from both Intune and Entra ID requires the Configuration Management module. * See: [Duplicate Devices](https://docs.intuneassistant.cloud/intune-assistant/devices/duplicate-devices) * **Backup & Restore** * You can now back up your Intune and Entra ID configuration to a single ZIP file, and restore it later through a guided three-step wizard (Upload, Configure, Review). Backup and restore are now also split into two separate pages for a clearer workflow. * See: [Backup & Restore](https://docs.intuneassistant.cloud/intune-assistant/backup-restore/backup-restore) * **Device Compare** * A new setting-level comparison lets you compare two devices and immediately see which configuration settings differ between them. * See: [Device Compare](https://docs.intuneassistant.cloud/intune-assistant/devices/device-compare) * **Group to Filter Analyzer** * A new analyzer shows which groups could be replaced by an assignment filter, helping you simplify assignment structures. * See: [Group to Filter Analyzer](https://docs.intuneassistant.cloud/intune-assistant/analyzer/group-to-filter-analyzer) * **Accept Drift** * Drift Monitor pages now have an Accept Drift button, so a detected configuration drift can be accepted as the new expected state directly from the monitor. * See: [Drift Monitor](https://docs.intuneassistant.cloud/intune-assistant/monitor) * **Multi Admin Approval for Assignments Manager** * Assignments Manager can now honor Multi Admin Approval policies, requiring a second administrator to approve sensitive assignment changes before they go live. * See: [Multi Admin Approval](https://docs.intuneassistant.cloud/extensions/assignments-manager/multi-admin-approval) * **Bulk Rename for Conditional Access Policies** * Conditional Access policies can now be renamed in bulk, with skeleton loading for a smoother experience while the list is loading. * See: [Bulk Rename Conditional Access Policies](https://docs.intuneassistant.cloud/intune-assistant/conditional-access/bulk-edit-ca-policies) * **Worker Job Templates: Versioning and Update Notifications** * Worker job templates now keep version history and notify you when an update is available, so scheduled jobs stay current. * See: [Worker Templates](https://docs.intuneassistant.cloud/extensions/worker/worker-templates) * **Scheduled Configuration Backups** * The IntuneAssistant Worker can now run configuration backups on a schedule, in addition to on-demand backups. * **License Management for MSPs** * MSP administrators can now create and manage worker licenses per connected customer tenant. * See: [License Management](https://docs.intuneassistant.cloud/extensions/msp-support/license-management) ## Improved * **Policy Settings Overview** * You can now search nested/child settings, and filter policies by Intune scope tag, making it easier to find the exact setting you're looking for. * See: [Policy Settings Overview](https://docs.intuneassistant.cloud/intune-assistant/policies/policy-settings-overview) * **Assignments Manager Filtering** * A filter-name dropdown is now available across assignment pages, and search fields support negative terms (excluding results that match a term), making it faster to narrow down large assignment lists. * **Assignment Existence and Policy Name Matching** * Policy name matching in Assignments Manager is now tolerant of leading/trailing spaces, with a warning shown whenever that fallback is used, reducing "policy not found" errors caused by stray whitespace. * **License Management** * License management has been reworked with a clearer structure, including bulk add/remove of licenses and an improved editing experience. * See: [License Management](https://docs.intuneassistant.cloud/extensions/worker/license-management) * **Customer Management** * Customer management now includes a billing overview and the ability to edit entitlements directly. * **Intune Audit Log Overview** * The audit log overview now shows which application performed an action, giving more context to each audit event. * See: [Audit Events](https://docs.intuneassistant.cloud/intune-assistant/audits/audit-events) * **Message Center** * Links inside Message Center announcements are now clickable, and expired messages no longer show up in the list. * **Worker Heartbeat Monitoring** * A dedicated monitor now checks worker heartbeat status separately, so worker health issues are detected faster. ## Fixed * **Policy Assignment Data Missing** * Fixed a bug where Graph API calls for Configuration, Group Policy, Device Configuration, and Compliance policies did not return assignment data at all, which could make policies appear unassigned when they weren't. * **Duplicate/Conflict Detection on Policy Settings Overview** * Duplicate and conflicting settings detection now runs server-side and only flags policies that actually target overlapping groups, instead of incorrectly flagging policies scoped to different groups. * **OMA-URI to Settings Catalog Migration Suggestions** * Migration suggestions for OMA-URI policies moving to Settings Catalog are now shown correctly in the frontend. * **Missing Group on Policy Assignments** * Fixed an issue where a group could be missing from a policy's assignment list. * **Consent Screen Permission Details** * The consent screen now shows the real permission details when consent is required, instead of a placeholder. * **Customer Onboarding Conflicts** * Onboarding a customer that was already registered now resumes onboarding instead of failing with a conflict error. * **Notification Templates for Backup & Restore** * Fixed an issue where notification templates for Backup & Restore were not created correctly; they are now created through a proper two-step process. * **Group Fetching for Assignments** * Fixed a bug where all Entra ID dynamic groups were fetched instead of only groups relevant to Intune. * **Migration Status Stuck at "Not Started"** * Fixed a bug where an assignment migration could remain stuck showing "Not Started" when Microsoft Graph throttled the request during batch execution. * **Partner Contracts Pagination** * Fixed an issue where not all partner contracts were retrieved for MSP tenants with a large number of contracts; pagination is now followed correctly. ## Technical Notes * The backend solution has been migrated to .NET 10. * A release candidate pipeline was added, allowing release candidates like this one to be promoted to production without rebuilding. * Internal version tracking updated. **This release focuses on device deduplication, backup & restore, richer policy and assignment insight, and MSP license management.** # v1.26.05 ## v1.26.05 ✅ PRODUCTION (v1.26.05) Highlights for this release of IntuneAssistant. *** ## New * **Message Center Support Added** * You can now access a message center within IntuneAssistant. This provides a central place for important updates and communications, helping you stay informed about changes and notifications relevant to your environment. * **Update Action for Assignments** * Assignments can now be updated directly, making it easier to manage and adjust device and group assignments without needing to recreate them. *** ## Improved * **Tenant Addition for Enterprise Customers** * The process for adding tenants has been updated to better support enterprise customers. This ensures that enterprise licensing is handled correctly and simplifies onboarding for larger organizations. * **Customer Creation Process** * Improvements have been made to prevent duplicate customer entries. This helps keep your customer records accurate and avoids confusion during onboarding or re-enrollment. *** ## Fixed * **Group Exclusion Issue** * Resolved a bug where it was not possible to add group exclusions when targeting all devices. You can now properly exclude groups as needed. * **Assignment Update Consistency** * Fixed issues where assignment updates did not always reflect correctly, especially when removing filters or comparing multiple policies. Assignment results are now consistent and reliable. * **Migration Check During Updates** * Addressed a problem where migration checks could fail during assignment updates. Updates now proceed smoothly without migration errors. * **Assignment Existence Checks** * Improved checks to ensure assignments exist for all actions, reducing errors and making assignment management more dependable. *** ## Technical Notes * Strict checking has been added for assignment updates to ensure only valid assignments are processed. * Internal version tracking updated. *** **This release focuses on improving assignment management, communication, and onboarding reliability for administrators.** # v1.26.04 ## v1.26.04 ✅ PRODUCTION (v1.26.04) Highlights for this release of IntuneAssistant. *** ## New * **Message Center**\ Under the user context menu a new page is available called message center. In the page announcements are published to keep you informed about all that happens around Intune Assistant. * **Bulk Assignments for Conditional Access Policies**\ You can now assign Conditional Access (CA) policies to multiple groups at once.\ *Why this matters:* Saves time and reduces errors when managing CA policies for large groups. * **Policy Comparison Tools**\ Added the ability to compare compliance, device configuration, and group policies, including bulk comparisons and one-to-many comparisons.\ *Why this matters:* Makes it easier to spot differences and ensure consistency across policies. * **External Policy Checks**\ You can now check policies from external sources for comparison.\ *Why this matters:* Useful for validating policies before importing or migrating them. * **JSON Upload Support**\ Policies can now be uploaded in JSON format.\ *Why this matters:* Simplifies importing policies from other tools or backups. * **Delete Worker Support**\ Administrators can now remove worker instances directly.\ *Why this matters:* Helps keep your environment clean and secure by removing unused workers. * **MSP (Managed Service Provider) Enhancements** * Initial onboarding process for MSPs is now supported. * Each tenant connected through MSP can have its own worker instance. * Additional permissions (`DelegatedAdminRelationship.Read.All`) are now included for MSP scenarios.\ *Why this matters:* Makes it easier for MSPs to manage multiple customers and their environments. * **Worker Email Notifications**\ Email notifications are now sent for worker registration and important events.\ *Why this matters:* Keeps administrators informed about worker status and actions. * **Marketplace Deployment Enhancements** * Added support for email addresses in marketplace deployments. * Improved handling for single and multiple marketplace deployments.\ *Why this matters:* Simplifies deployment and tracking of workers via the marketplace. * **RBAC Analysis for Intune Administrator Role**\ Added a tool to analyze role-based access control (RBAC) for Intune administrators.\ *Why this matters:* Helps review and audit administrator permissions. * **Intune Audit Report for Worker**\ Workers can now generate audit reports for Intune activities.\ *Why this matters:* Improves visibility and compliance tracking. * **Drift Monitoring and Alerts**\ Added monitoring for configuration drift and email alerts if drift is detected.\ *Why this matters:* Ensures your environment stays compliant with intended configurations. Added Windows Configuration Policies Monitor template.\ *Why this matters:* It simplifies creating a monitor for Intune Configuration policies. *** ## Improved * **Worker Management** * Worker overview now supports MSP scenarios. * Improved worker registration and approval process. * Workers now support auto-update and internal logging.\ *Why this matters:* Easier to manage and monitor worker instances, especially for MSPs. * **Policy Migration** * Improved handling of large migration files to reduce policy-not-found errors. * Checks for already migrated policies are now more accurate.\ *Why this matters:* Smoother and more reliable policy migrations. * **Group Monitoring** * Added support for monitoring specific groups in UTCM (Unified Tenant Configuration Monitor).\ *Why this matters:* Allows more targeted monitoring and alerting. * **Customer Identification** * Customer ID is now included for existing workers. * Improved customer check during onboarding.\ *Why this matters:* Better tracking and management of customer environments. *** ## Fixed * **Group Member Permissions**\ Fixed an issue where group members could not be fetched due to missing permissions.\ *Why this matters:* Ensures group-based assignments and monitoring work as expected. * **Duplicate Deployment Names**\ Fixed a bug causing duplicate deployment names during worker setup.\ *Why this matters:* Prevents confusion and errors in worker management. * **Multiple Worker Registrations**\ Fixed an issue where multiple registrations could occur for the same worker.\ *Why this matters:* Reduces duplicate entries and potential conflicts. * **Policy Name Handling**\ Improved handling of policy names with trailing spaces and added warnings.\ *Why this matters:* Prevents errors when searching for or assigning policies. *** ## Technical Notes * Added timeout for email address validation to prevent delays. * Updated documentation links for worker installation. * Various internal improvements to worker update mechanisms and logging. * Minor fixes to test processes and pipelines. *** **This release focuses on MSP enablement, drift monitoring, policy comparison, and worker management reliability.** # v1.26.03 ## v1.26.03 ✅ PRODUCTION (v1.26.03) Highlights for this release of IntuneAssistant. *** ## New * **Configuration Drift Monitoring Added** * You can now monitor changes in configuration settings, helping you detect unexpected or unauthorized changes in your environment. * **UTCM Onboarding Process with App Creation** * A new onboarding process for UTCM (Unified Tenant Configuration Monitor) is available, including automatic app creation. This makes it easier to set up monitoring for your tenant. * **UTCM Monitor Now Public** * The UTCM monitor is now available for general use, allowing all users to access configuration drift monitoring. * **Intune Audit Events API Endpoint** * You can now access Intune audit events directly, making it easier to review actions and changes within Intune. * **Directory Audit Log Support** * Directory audit logs are now supported, providing more visibility into user and admin activities. * **Permission Verifier Added** * IntuneAssistant now checks and verifies permissions, helping you ensure the correct access is set up. * **Setup Verification After First Login** * After your first login, IntuneAssistant will verify setup, helping you confirm that everything is configured correctly. * **Mobile App Configuration Migration Support** * Migration for mobile app configurations is now supported, simplifying the process of moving app settings. * **Sub Resource Type for Device Configuration Policies** * Device configuration policies now include sub resource types, giving you more detailed policy management. * **Audit Events available in IntuneAssistant** * IntuneAssistant now records important administrative actions. This helps administrators review what happened in the environment and investigate changes when needed. * **Scope tags included in assignment exports** * When exporting assignments, scope tags are now included. This gives a more complete overview of how policies and configurations are delegated across the environment. * **Assignments Manager migration summary page** * After completing a migration, a summary page now shows the results. This helps administrators quickly confirm what was migrated and whether anything requires attention. * **Intune sub-resource types shown in assignment overview** * Resources in the assignments overview now include their sub-resource type. This makes it easier to understand exactly which configuration or object you are working with. * **Resizable table columns** * Tables throughout the interface now support column resizing, allowing administrators to adjust views for better readability. *** ## Improved * **Graph API Performance and Assignment Migration** * Improved performance and reliability when using Microsoft Graph API and migrating assignments, reducing delays and errors. * **Audit Logging** * Enhanced audit logging for orchestrators and event endpoints, providing clearer records of actions and changes. * **Consistent Filter Output** * Filter responses are now consistent, making it easier to interpret results. * **Wait Time Optimization in Migration Service** * Migration processes now have optimized wait times, speeding up migrations. * **Additional Permissions for Scope Tags** * More permissions are now supported for scope tags, improving access control. * **Correlation ID Header Exposed** * The correlation ID is now visible in responses, helping with troubleshooting and tracking requests. * **Customer onboarding process simplified** * New customers can now sign in directly during onboarding. This reduces steps and makes getting started with IntuneAssistant easier. * **Assignments migration workflow improved** * The migration process in Assignments Manager now includes additional validation checks to reduce the risk of incorrect or incomplete migrations. * **Large assignment migrations handled more reliably** * Large migrations are now processed in batches. This improves reliability and prevents failures when working with environments that contain many assignments. * **Protection against API throttling during migrations** * Additional internal safeguards help prevent interruptions caused by Microsoft Graph throttling when running large migrations. * **Improved handling of large datasets in the browser** * When working with large data sets, the interface now keeps data available even after navigating away from the page. This reduces the need to reload information. *** ## Fixed * **Compliance Policy Test Fixed** * Compliance policy testing is now more reliable. * **Platform Property Selection Bug Fixed** * Issues with selecting platform properties in Graph API requests have been resolved. * **Scope Tag Selection Issues Fixed** * Missing scope tags in property selection have been addressed. * **Duplicate Fetch Removed for Targeted App Configuration** * Duplicate data fetches for targeted app configurations have been eliminated, reducing unnecessary processing. * **GDAP Onboarding Bug Fixed** * Errors during GDAP onboarding and conflicts with existing customers have been resolved. * **Customer onboarding conflict errors resolved** * In some cases an unfinished onboarding process could cause a conflict where a customer already existed but the backend consent was missing. This issue is now resolved. * **User assignments page filter issue fixed** * A filtering issue on the user assignments page could show incorrect results due to an incorrect filter type. Filtering now works as expected. *** ## Technical Notes * **Audit Logs Added for Orchestrators and Events** * More detailed audit logs are now available for orchestrators and event endpoints, improving traceability. * **Graph API Throttling System** * A custom throttling system for Graph API has been implemented to handle retry issues, improving reliability. * **Unit and Integration Tests Updated** * Tests have been updated to reflect changes in onboarding flows and resource fetching, ensuring consistency. *** **This release focuses on improved monitoring, audit capabilities, permission management, and migration support, making IntuneAssistant more reliable and easier to manage for IT administrators.** # v1.26.02 ## v1.26.02 ✅ PRODUCTION (v1.26.02) Highlights for this release of IntuneAssistant. *** ## New * **Group Assignment Endpoint:** Added a REST endpoint to fetch assigned group information in Assignments Manager. *Context:* Enables administrators to retrieve group assignment details for easier management. * **Apps Overview Pagination:** Introduced pagination to the apps overview and improved platform recognition. *Context:* Helps manage large app inventories and ensures accurate platform identification. * **User Assignment Support:** Added endpoints to check user assignments. *Context:* Allows administrators to verify which users are assigned to specific resources. * **Autopilot Profile Resources:** Assignment Manager now supports autopilot profile resources. *Context:* Facilitates assignment and tracking of autopilot profiles. * **Scope Tag Search API:** Added an API endpoint for searching scope tags. *Context:* Simplifies locating and managing scope tags. * **Assignment Search with Filters:** Introduced an API to search for assignments using specific filters. *Context:* Enables targeted assignment queries for improved oversight. ## Improved * **Pagination for Devices Endpoint:** Devices endpoint now supports pagination. *Context:* Makes device management more scalable. * **Migration Flow Refactor:** Migration process rewritten and assignments builder simplified. *Context:* Streamlines migration tasks and reduces complexity. * **Onboarding Process Refactor:** Onboarding flow updated for better performance. *Context:* Enhances onboarding efficiency. * **Graph SDK Update:** Updated to the latest Microsoft Graph SDK. *Context:* Maintains compatibility and leverages new SDK features. * **Batch Migration Cooldown:** Added cooldown phase between migration batches. *Context:* Reduces risk of throttling and improves stability during migrations. ## Fixed * **Targeted App Config Mapping:** Corrected mapping for targeted app configurations. *Context:* Prevents assignment errors. * **Assignment Finder in Migration Orchestrator:** Fixed assignment finder logic during migrations. *Context:* Ensures accurate assignment detection. * **License Onboarding Check:** License onboarding now checks only for consent granted. *Context:* Prevents false negatives in license validation. * **Resource Type Export:** Fixed resource type handling in export operations. *Context:* Ensures correct export of policies. * **IOS Managed App Protection Policy:** Fixed policy type handling for IOS managed app protection. *Context:* Prevents errors when managing IOS policies. * **Windows Update Mapping:** Updated Windows update mapping configuration to handle conflicts gracefully. *Context:* Reduces errors during update assignments. * **Policy Type URL Mapping:** Added missing policy types to correct URL mapping. *Context:* Ensures accurate policy management. * **Request Query Top Parameter:** Changed the maximum query parameter from 1000 to 200. *Context:* Complies with Microsoft Graph API limits and prevents errors. ## Technical Notes * **Logging Optimization:** Reduced logging verbosity and changed MSAL logging to error-only. *Context:* Minimizes log noise and focuses on actionable errors. * **Branding Configuration:** Branding moved to an external JSON file. *Context:* Allows easier updates to branding without code changes. *** **This release focuses on scalability, assignment management, and platform migration reliability.**