The report returned zero devices and a 401 Unauthorized on every deviceManagement endpoint it touched. That struck me as odd, so I went digging into what the problem actually was.

Table of Contents

• What I found
  • The error that sends you the wrong way
  • Running the checks
  • The chicken-and-egg problem
• Where Microsoft’s own docs disagree
  • What the admin center says instead
• The fix
• Conclusion
• Related
• References

What I found

The 401 was never about authentication, and nothing in the status line tells you that. Here is how the error actually reads, what the checks eliminate, and where they run out of road.

The error that sends you the wrong way

This is what the report printed, with the tenant-specific parts removed:

Starting device data collection...
Fetching Autopilot devices...
Processing 0 devices...
Processed 0 devices out of 0 total devices
Error: GET https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeploymentProfiles/
HTTP/1.1 401 Unauthorized

The useful part is not in that status line. It is in the response body, double-escaped, several layers deep. The real thing arrives as a single line; the indentation is mine:

{
  "error": {
    "code": "UnknownError",
    "message": "{
      \"ErrorCode\": \"Forbidden\",
      \"Message\": \"{
        \"_version\": 3,
        \"Message\": \"An error has occurred - Operation ID (for customer support): 00000000-0000-0000-0000-000000000000 - Url: https://proxy.msubXX.manage.microsoft.com/DeviceEnrollmentFE/StatelessDeviceEnrollmentFEService/deviceManagement/windowsAutopilotDeploymentProfiles?api-version=5025-11-25\",
        \"HttpHeaders\": \"{\"WWW-Authenticate\":\"Bearer\"}\"
      }\"
    }"
  }
}

Two signals in there change the diagnosis:

The nesting is hostile enough - a JSON string inside a JSON string inside a JSON string - that it is worth having something dig it out:

try {
    Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/beta/deviceManagement' -ErrorAction Stop
} catch {
    $outer = $_.ErrorDetails.Message | ConvertFrom-Json
    $inner = $outer.error.message     | ConvertFrom-Json
    $body  = ($inner.Message | ConvertFrom-Json).Message
    if ($body -match 'Url:\s*(https?://[^/?\s]+)') { $refusedBy = $Matches[1] }
    [pscustomobject]@{
        OuterCode = $outer.error.code
        InnerCode = $inner.ErrorCode
        RefusedBy = $refusedBy
    }
}

OuterCode    InnerCode  RefusedBy
---------    ---------  ---------
UnknownError Forbidden  https://proxy.msubXX.manage.microsoft.com

Honest, at least. It tells you who said no. It does not tell you why, and that is as far as Graph is going to take you.

Running the checks

So the next question is whether this is the token, the tenant, or the identity. Here is that as one read-only script - every call is a GET - which also installs the Graph authentication module if you do not have it.

#Requires -Version 5.1
# Intune access diagnostic. Read-only: every call is a GET.

if (-not (Get-Module -ListAvailable -Name Microsoft.Graph.Authentication)) {
    Write-Host 'Installing Microsoft.Graph.Authentication for the current user...' -ForegroundColor Yellow
    Install-Module Microsoft.Graph.Authentication -Scope CurrentUser -Force
}
Import-Module Microsoft.Graph.Authentication -ErrorAction Stop

# Fresh token: -Scopes is ignored on an existing session.
Disconnect-MgGraph -ErrorAction SilentlyContinue | Out-Null
Connect-MgGraph -NoWelcome -Scopes @(
    'DeviceManagementServiceConfig.Read.All'
    'Directory.Read.All'
    'Organization.Read.All'
    'User.Read'
)

function Get-Graph {
    param([Parameter(Mandatory)][string]$Uri)
    try { Invoke-MgGraphRequest -Method GET -Uri $Uri -OutputType PSObject -ErrorAction Stop }
    catch { $script:LastError = $_; $null }
}

function Get-IntuneRefusal {
    param($ErrorRecord)
    $out = [pscustomobject]@{ OuterCode = $null; InnerCode = $null; RefusedBy = $null }
    if (-not $ErrorRecord) { return $out }
    try {
        $outer = $ErrorRecord.ErrorDetails.Message | ConvertFrom-Json
        $out.OuterCode = $outer.error.code
        $inner = $outer.error.message | ConvertFrom-Json
        $out.InnerCode = $inner.ErrorCode
        $body = ($inner.Message | ConvertFrom-Json).Message
        if ($body -match 'Url:\s*(https?://[^/?\s]+)') { $out.RefusedBy = $Matches[1] }
    } catch {
        $out.OuterCode = $ErrorRecord.Exception.Message
    }
    $out
}

$ctx = Get-MgContext

$dm      = Get-Graph 'https://graph.microsoft.com/beta/deviceManagement'
$refusal = Get-IntuneRefusal $script:LastError

$skus  = (Get-Graph 'https://graph.microsoft.com/v1.0/subscribedSkus').value
$roles = (Get-Graph 'https://graph.microsoft.com/v1.0/me/transitiveMemberOf/microsoft.graph.directoryRole').value

$groupType = '#microsoft.graph.group'
$direct = @((Get-Graph 'https://graph.microsoft.com/v1.0/me/memberOf').value |
    Where-Object { $_.'@odata.type' -eq $groupType })
$trans = @((Get-Graph 'https://graph.microsoft.com/v1.0/me/transitiveMemberOf').value |
    Where-Object { $_.'@odata.type' -eq $groupType })

$result = [pscustomobject]@{
    Account         = $ctx.Account
    AuthType        = $ctx.AuthType
    ScopeInToken    = $ctx.Scopes -contains 'DeviceManagementServiceConfig.Read.All'
    IntuneReadable  = [bool]$dm
    OuterErrorCode  = $refusal.OuterCode
    InnerErrorCode  = $refusal.InnerCode
    RefusedBy       = $refusal.RefusedBy
    TenantHasIntune = [bool]($skus.servicePlans | Where-Object {
                          $_.servicePlanName -like '*INTUNE*' -and $_.provisioningStatus -eq 'Success' })
    AccountLicensed = [bool](Get-Graph 'https://graph.microsoft.com/v1.0/me/licenseDetails').value
    ActiveRoles     = $roles.displayName -join ', '
    InNestedGroup   = $trans.Count -gt $direct.Count
    TenantCreated   = (Get-Graph 'https://graph.microsoft.com/v1.0/organization').value.createdDateTime
}

$result | Format-List

if ($result.IntuneReadable) {
    $next = 'Intune is readable. Nothing to fix here.'
} elseif (-not $result.ScopeInToken) {
    $next = 'Reconnect: the scope never made it into the token.'
} elseif (-not $result.TenantHasIntune) {
    $next = 'No Intune service plan is provisioned in this tenant. Fix licensing, not RBAC.'
} elseif ($result.InNestedGroup) {
    $next = 'You reach your groups only through nesting. Nested members are excluded ' +
            'from unlicensed admin access: add a direct membership, or assign a license.'
} else {
    $next = 'Token and tenant are fine, so this is entitlement. Add this account to an ' +
            'Entra security group that carries an Intune RBAC role assignment. ' +
            'Read Only Operator covers read-only reporting.'
}

[pscustomobject]@{ Verdict = $next } | Format-List

Directory.Read.All and Organization.Read.All need admin consent on the Microsoft Graph PowerShell app. Without it those fields come back empty and the IntuneReadable verdict still works.

Against my tenant, with values redacted or shifted where they would identify it:

Account         : <upn>
AuthType        : Delegated
ScopeInToken    : True
IntuneReadable  : False
OuterErrorCode  : UnknownError
InnerErrorCode  : Forbidden
RefusedBy       : https://proxy.msubXX.manage.microsoft.com
TenantHasIntune : True
AccountLicensed : False
ActiveRoles     : Global Reader
InNestedGroup   : False
TenantCreated   : 8 March 2022

Verdict : Token and tenant are fine, so this is entitlement. Add this account to an
          Entra security group that carries an Intune RBAC role assignment.
          Read Only Operator covers read-only reporting.

That output rules out everything ordinary. The scope is in the token. Intune is provisioned in the tenant. The role is present and currently active - transitiveMemberOf/microsoft.graph.directoryRole returns only roles that are active right now, so a PIM-eligible role you have not activated will not appear there, which makes that line double as proof my activation landed. Nested group membership, the one exclusion Microsoft documents for unlicensed admin access on both the licensing page and the RBAC overview, does not apply.

Which leaves the last two lines standing on their own: no license, and nothing granting Intune access in its place.

The chicken-and-egg problem

The obvious next move is to ask Graph what Intune role assignments the account has:

Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/beta/deviceManagement/roleAssignments'

Which fails with the same Forbidden, because reading Intune RBAC requires Intune access. You cannot use Graph to diagnose the absence of the very thing that grants you Graph access here, and this is where the script stops being able to help.

There are two ways around it, both outside Graph. The admin center’s Tenant administration > Roles > My permissions renders the effective permissions for the signed-in account and needs no Intune permission of its own. And opening intune.microsoft.com as the same account separates an identity problem from a token or client problem, because the portal and Graph share one RBAC evaluation. It refused me there too, on every workload. At that point you can stop debugging code.

Where Microsoft’s own docs disagree

This is the part that cost the most time, and it is not one wrong sentence. It is three statements describing one feature three different ways.

Statement one, from the Intune licensing page:

“Administrators can sign in to and manage Microsoft Intune without an assigned Intune license. This access is enabled by default for tenants created after July 2021 and applies to all administrator roles, including Intune administrators and Microsoft Entra administrators.”

That one is checkable, and the script above already did it. (Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/organization').value.createdDateTime returned 8 March 2022 for this tenant - comfortably after the cutoff. So by this page, unlicensed admin access has been on by default since day one here, nobody ever had to flip a toggle, and the documented “up to 48 hours for access changes to take effect” clock is not running either.

Statement two, from the RBAC overview, about the same feature:

“In June 2021, Intune began supporting unlicensed admins. User accounts created after this change can administer Intune without an assigned license.”

That is not the same gate. One keys off when the tenant was created, the other off when the user account was created, and the two dates are a month apart.

Statement three is two paragraphs apart on that same licensing page:

“An Intune license is required for any user or device that benefits directly or indirectly from the Microsoft Intune service, including access through a Microsoft API.”

“Unlicensed admin access grants sign-in and management access to the Microsoft Intune admin center.”

Read together, those say unlicensed admin access covers the admin center and that API access needs a license - a significant thing to leave implicit on a page whose headline sentence is “applies to all administrator roles”. It still does not explain my case, because the portal refused me too.

What the admin center says instead

The Intune admin center has its own wording for the same feature, under Tenant administration > Roles > Administrator Licensing:

“All unlicensed admins have access to Intune. To revoke access from an unlicensed admin, remove them as a member from their Microsoft Entra group assigned to Intune role.”

That names a mechanism none of the Learn pages state: entitlement is carried by group membership, not by holding an admin role.

One documented fact sits behind it. An Intune role is never attached to a person - the assignment always targets a group:

“Both Intune custom and built-in roles are assigned to groups of users.” - RBAC overview

So “a group that carries an Intune role” is the only shape an Intune role assignment can take, and being in that group is the only way to be on the receiving end of one. The licensing page then counts unlicensed admins per security group rather than per admin, with a documented limit of 1000, which is what you would expect if the group is what the entitlement travels through.

Which matches what I measured. No such group, no entitlement, so Intune fell back to requiring a license the account did not have.

The fix

Two options, and only two.

For read-only reporting, Read Only Operator is the right role. Microsoft describes it as “Read Only Operators view user, device, enrollment, configuration and application information and cannot make changes to Intune”, and its permission table grants Enrollment programs | Read profile - exactly what the Autopilot call needed - alongside Read device and Read token, and nothing at all that can write. This is also the role I would have picked over Global Reader in the first place, if the tenant had offered me the choice.

Three details that are easy to get wrong. You cannot assign an Intune role to a user, so you are creating or reusing a group whether you wanted to or not. Direct membership only: members of nested groups are excluded and still need a license. And give it time: Microsoft documents up to 48 hours for unlicensed admin access changes to take effect, so a refusal in the first minutes after adding the group proves nothing yet.

ADVICE: do not take the license option. Admin accounts should be clean: no mailbox, no OneDrive, no Teams presence. That is blast radius, not bureaucracy. An admin account with a mailbox can be phished, can have inbox forwarding rules quietly added to it, shows up in address lists, and gives an attacker who lands on it somewhere to stage data. Most Intune-bearing bundles light all of that up. It trades a five-minute RBAC fix for a permanent increase in what that account is worth to an attacker.

Conclusion

Intune refusals through Graph lie to you twice. The status line says authentication when the problem is authorization, and the error body hides the one detail that matters - a manage.microsoft.com host, meaning your token was accepted and the Intune service is what turned you away. Get past those two and the diagnosis takes minutes: ask for /beta/deviceManagement on its own, open the portal as the same account, and if both turn you away, stop looking at your code and start looking at role assignments.

The deeper trap is that “applies to all administrator roles” reads like a guarantee. Across three Learn statements it is not a consistent one, and none of them mention the mechanism the admin center states outright: entitlement rides on membership of an Entra security group carrying an Intune RBAC role assignment. An Entra admin role on its own buys you nothing in Intune. Give the account a group with Read Only Operator, not a license, and keep your admin identities free of mailboxes.

Related

• RKSolutions PowerShell Module - the module whose Get-IntuneAnomaliesReport cmdlet hit this 401, alongside the Entra admin roles, license assignment, and enrollment reports.
• Intune Anomalies Report - the report itself, now shipped as part of the RKSolutions module.
• Bulk Intune Reporting with the Graph Export API - another corner of deviceManagement where documented behavior and service behavior do not line up.
• How to secure your Enterprise Application via PIM - more on using PIM for just-in-time privileged access.

References

• Microsoft Learn - Microsoft Intune licensing
• Microsoft Learn - Role-based access control with Microsoft Intune
• Microsoft Learn - Built-in role permissions for Microsoft Intune
• Microsoft Learn - Network endpoints for Microsoft Intune
• Microsoft Learn - Assign a role to Intune users
• RFC 9110 - HTTP Semantics, 401 Unauthorized and 403 Forbidden

Not necessarily. Company Portal knows that the 4.3 application is not detected. It does not automatically know whether its install command upgrades 4.2, replaces it, installs next to it, or fails because the old installation used a different product code, path, or context.

Publishing a newer app keeps the Intune up to date, but it does not define what should happen on a device that already has an older version. That needs an explicit app relationship or installation logic that handles the old state.

The three versions of the truth

The same device can describe Northstar Workspace in three valid but different ways:

“4.3 is not detected” means only that the 4.3 application’s own detection rule has not passed. It says nothing about an earlier version or related product that may already be on the device.

Detection answers whether this application is installed. Supersedence answers what the new application must do with the old one.

Available is an offer, not an update plan

Available for enrolled devices is self-service. Without further configuration, Company Portal shows the new app and the user must choose Install.

Publishing 4.3 does not change that. The new app can be offered to the user, but it does not automatically replace or update 4.2.

Let detection tell the truth

For this example, configure the 4.3 application’s registry detection rule in the portal as follows:

On this device, 4.2.0 >= 4.3.0 is false. That is correct: 4.3 is missing and Company Portal will offer Install again.

Warning: Do not weaken version-aware detection just to make Company Portal look friendlier. A rule that accepts every old version hides the fact that the target version is absent.

A correct failed detection does not make the request a safe upgrade. Intune runs the 4.3 installation process exactly as it was configured. If that process was built only for a clean 4.3 installation, it can run into an existing 4.2 installation with no upgrade, replacement, or removal logic.

Supersedence makes the transition explicit

On the 4.3 Win32 app, create a supersedence relationship to 4.2. Then decide whether this is an update or a replacement:

• Update: the 4.3 installer upgrades 4.2 itself. Leave Uninstall previous version off.
• Replacement: Intune removes 4.2, then installs 4.3. Enable Uninstall previous version and test both commands in their intended context.

Available Auto-update

Configure the no-click path on the newer Win32 application, following Microsoft’s documented flow:

1. In Apps > All apps, add or open the newer Win32 application, such as 4.3.
2. On its Supersedence step, add the older application, such as 4.2.
3. On Assignments, create or open the intended Available for enrolled devices assignment. Its target can be a group, All users, or All devices.
4. In that assignment’s Auto-update column, select Auto-update, then save the assignment and application.
5. Keep the original Available assignment and its scope in place. The original Company Portal user must still be signed in, and the device or user must remain in scope, whether that is through a group, All users, or All devices. Changing the assignment or intent after the original Company Portal install removes the consent state that Auto-update relies on.

This applies when the user originally installed 4.2 from Company Portal. With that state intact, Intune requires 4.3 without another Company Portal click.

When an app-management platform publishes your apps

An app-management platform adds real value when it can keep this lifecycle intact as it publishes a new release: reliable version detection, supersedence, the correct update or replacement behaviour, and the Available Auto-update assignment. That removes repetitive configuration work and makes the intended transition consistent.

Do not assume it does this just because it publishes a newer version. Verify what the platform creates in Intune. If it only publishes the next package, Intune sees a new application rather than a known successor. The platform must either support supersedence and Auto-update, or ensure the package handles legacy state before it installs.

Test the lifecycle, not just a clean install

Use an enrolled test device and publish version 2 exactly as production automation will. Do not test only a clean installation. Test these two paths:

1. Known Company Portal install: install version 1 through Company Portal, then verify that supersedence with Auto-update moves it to version 2 without another user action.
2. Existing unmanaged installation: start with an old manual, user-context, or unrelated installation. Verify that the version-2 package safely upgrades, replaces, removes, or stops when it encounters that state.

In both cases, confirm that version 2 is detected and that a device without version 1 does not receive an unwanted first install. If the result is unclear, inspect AppWorkload.log and AppActionProcessor.log.

The practical rule

Available supersedence with Auto-update solves the central Company Portal problem when the earlier version is a known Intune application installed from Company Portal. It gives Intune both the relationship and the instruction to install the successor.

Important: Supersedence links Intune applications. It does not make HKLM and HKCU equivalent. A System-context installer uses the System account’s HKCU; user-context logic can miss a device-wide HKLM installation. If both histories are possible, the installer or wrapper must check the relevant contexts and deliberately upgrade, replace, remove, or stop.

References

• Add Win32 app supersedence and use auto-update with app supersedence
• Add and assign Win32 apps in Microsoft Intune
• Understand the Intune Management Extension

InforcerCommunity MCP connects an AI tool to the Inforcer REST API, so you can ask about your own tenant data in plain language:

“Which of my tenants are furthest from their baseline?”
“In Contoso, which policy controls password expiry?”
“Do all of my customers block legacy authentication?”

Your AI tool cannot normally see any of that, and this connects the two.

InforcerCommunity MCP was created by me for the community. It is an independent, community-driven project to make the Inforcer REST API easier to reach from the AI tools you already work in, and it is not owned, endorsed, or maintained by Inforcer.

Table of Contents

• What is an MCP server?
• What you can ask about your Inforcer tenants
• Finding a setting when you do not know the policy name
• Read-only by default
• Where your data goes
• Installing the InforcerCommunity MCP server
• MCP or the PowerShell module: which one do I use?
• Links

What is an MCP server?

MCP stands for Model Context Protocol. It is a standard way of giving an AI tool access to a system it would otherwise know nothing about. You install a small “program”, your AI tool discovers what it can do, and from then on it can fetch real data instead of guessing at it.

That is all this is, and on your side it is really just configuration: one block in your AI tool’s settings, pointing at something that speaks the Inforcer REST API on one side and MCP on the other. There is nothing to download by hand, and you never call it yourself. You ask your AI tool a question, it works out which part of the Inforcer REST API answers that question, and the answer comes back in the conversation.

It runs on your own machine. Your AI tool starts it when it launches and stops it when you close it, so there is nothing hosted and no address to connect to.

What you can ask about your Inforcer tenants

Most of what Inforcer holds is reachable: tenants, baselines, policies, alignment scores and details, users, groups, roles, secure scores, the activity log, reports and assessments.

Worth setting expectations on first: the MCP only supports what the Inforcer REST API supports. It is a wrapper, not a second source of data. If something is visible in the portal but has no API endpoint behind it, you cannot ask about it here either.

Within that, you never have to learn a command or look up an ID. Use tenant names like “Contoso” and ask for what you want:

What makes it useful is that it hands your AI tool the actual numbers and policy data, not a pre-written answer. The tool does the interpreting, so a follow-up question about the same data gets you something genuinely different back rather than the same paragraph reworded.

Ask it to list your tenants with their alignment scores, and you get the numbers:

Then ask which three you should review first, and it reasons over the data it already has: Northwind first, because 57.9% is the widest gap in the portfolio, then Fabrikam, which has drifted since its last alignment run. No second round of API calls, and no answer you could have written in advance.

It is also multilingual, and that comes for free rather than as a feature. Because what comes back is data rather than finished sentences, your AI tool answers in whatever language you asked in. A question in Dutch gets a Dutch answer. Policy names stay exactly as Inforcer reads them.

There are more examples, and the awkward cases, in the examples guide.

Finding a setting when you do not know the policy name

You do not need to know what a policy is called to find it. Describe the setting you are after and ask whether anything in the tenant configures it:

“Is there anything in Contoso that controls password expiry?”
“Which policy in Fabrikam blocks legacy authentication?”

Phrased that way, your AI tool searches inside the policy settings and comes back with whichever policy holds it, whatever name it happens to have.

That is the useful habit to get into, because policy names rarely describe what is inside them. A policy that turns off passkeys might be called anything at all. So if you search by name and get nothing back, the only thing you have learned is that no policy has that name - not that the setting is missing. Ask what a policy does rather than what it is called, and you get a real answer.

Read-only by default

The MCP ships read-only. Everything that could change something in a tenant is refused, so there is nothing you can accidentally reconfigure by phrasing a question badly.

There is also nothing to switch on today. The Inforcer REST API offers no way to change a client’s settings, so neither does this. The setting that would permit writes exists and is listed in the setup guide, but until the API grows those endpoints it does nothing - and enabling it would stay a human decision at a file on your own machine rather than something an AI tool could choose for itself.

Where your data goes

Nothing is hosted, and the only outbound calls are to the Inforcer REST API.

How your API key is stored depends on how you set it up. The VS Code one-click button hands it to VS Code’s own password store rather than writing it into a file, and it never reaches your browser history either. With the JSON block the key lives in your AI tool’s settings file, and the accounts file option exists for keeping it out of the file most likely to get synced between machines or pasted into a support ticket.

The part worth understanding is the path your client data travels, because there is no anonymisation anywhere along it. When you ask a question, the MCP calls the Inforcer REST API, Inforcer pulls the data from the tenant at that moment, and it comes back through the MCP into your AI tool’s context. From there it goes on to your AI provider and into your AI tool’s own saved conversation history on disk. Real tenant names, real user names, real email addresses, at every one of those hops.

The full detail, including what is not promised, is in SECURITY.md.

Installing the InforcerCommunity MCP server

You need two things: an Inforcer API key from the portal, and the region that key belongs to (uk, eu, us or anz). A key works in exactly one region, and the wrong region fails in a way that looks identical to a wrong key, so check that first if nothing works. It runs on every platform.

In VS Code it is a one-click button in the README. For Claude Code it is one command:

claude mcp add inforcer -s user \
  -e INFORCER_API_KEY=your-api-key \
  -e INFORCER_REGION=uk \
  -- npx -y inforcercommunity-mcp@latest

For Claude Desktop, Cursor and more it is one block in the settings file:

{
  "mcpServers": {
    "inforcer": {
      "command": "npx",
      "args": ["-y", "inforcercommunity-mcp@latest"],
      "env": {
        "INFORCER_API_KEY": "your-api-key",
        "INFORCER_REGION": "uk"
      }
    }
  }
}

Then restart your AI tool, because it only reads its settings when it starts, and ask it to run inforcer_status. If that comes back with "state": "ok", you are done. Ask it to list your tenants and you should see them.

You do not have to maintain any of this. Because the config points at @latest, every new version I ship is picked up on its own the next time your AI tool starts, so fixes and newly supported endpoints arrive without you touching the file. Updates land at startup rather than mid-session, so if you have had the same session open for days, restart it to get the newest one.

Everything past that point lives in the repo: which AI tools are supported and where each one keeps its settings, the optional settings, the per-platform notes, and how to run two Inforcer accounts side by side are all in the setup guide.

MCP or the PowerShell module: which one do I use?

The MCP answers questions. The PowerShell module produces artefacts. Full tenant documentation, a side-by-side Intune comparison, a multi-tenant assessment matrix or a scheduled csv are all module jobs, and the MCP will tell you so rather than trying.

The rough rule: if the output belongs in a conversation, ask the MCP. If it belongs in a file you hand to somebody else, run the module.

Links

• GitHub: https://github.com/royklo/inforcercommunity-mcp
• PowerShell module: blog post and repo

Bugs and feature requests go in the issues. Issues are public, so never paste your key, and strip client names first. The most useful report you can send is a question that got a bad answer, because that almost always means a tool description is wrong.

Related

• InforcerCommunity: A PowerShell Module for the Inforcer REST API - the other half of this idea, for when you need a file rather than an answer.

The real strength is that filters do not replace groups, they stack on top of them. Assign to a dynamic group and filter within it. Or assign to a group of users and filter on device properties, so a policy follows people around but only ever lands on the hardware you meant. That is an extra layer of flexibility over everything you already have.

Every filter is also bound to a platform. That boundary turns out to live in exactly one place: the dropdown you pick it from.

Table of Contents

• What an assignment filter gives you
• The one thing the picker will not offer
• How a mismatched filter breaks your targeting
• The portal shows it, then writes it back
• Finding it in your own tenant
• The screenshots
• Conclusion

What an assignment filter gives you

A filter is a rule over device properties, written once and reused on as many assignments as you like. You point a policy at a group, then layer the filter on that assignment to narrow it: include only the devices matching the rule, or exclude the ones that do.

What makes it powerful is that the group and the filter answer different questions. The group says who, the filter says on what. So you can say things like:

• Apply this to everyone in Marketing, but only on their personal devices, so it never lands on a shared or kiosk machine
• Apply this only to devices from one enrollment profile, so everything enrolled through the others is left alone
• Keep Cloud PCs out of an assignment that would otherwise sweep them up

None of those need a new group. You are not restructuring anything, you are adding a condition to an assignment you already have.

Every filter carries a platform, set when you create it. That platform is not cosmetic: it decides which properties the rule editor offers you, and it decides which filters appear when you assign a policy.

Screenshot 1 - Both filters in the tenant list, with their Platform column.

For this post I built a small scaffold in a lab tenant: two filters, two empty groups and two Settings Catalog policies. The macOS filter matches (device.manufacturer -eq "Apple") and the Windows one matches (device.manufacturer -eq "Dell Inc."). Both rules deliberately use device.manufacturer. Remember that.

The one thing the picker will not offer

Open the Windows policy, go to its assignment, and open the filter picker. Only the Windows filters are listed. The macOS filter is not there and there is no way to select it. That is correct, and it is clearly intentional: the Microsoft admin center is deliberately shielding you from a combination that should not exist.

Graph does not participate in that. It never receives the constraint in the first place, so it has nothing to check against and simply carries out the request. An assignment expresses a filter as two properties on the target, an ID and a mode, and nothing in the payload mentions a platform at all:

$body = @{
    assignments = @(
        @{
            target = @{
                '@odata.type'                              = '#microsoft.graph.groupAssignmentTarget'
                groupId                                    = $groupId
                deviceAndAppManagementAssignmentFilterId   = $macOSFilterId
                deviceAndAppManagementAssignmentFilterType = 'include'
            }
        }
    )
}

# $policyId here is a policy with platforms = windows10
Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies/$policyId/assign" `
    -Body ($body | ConvertTo-Json -Depth 100) -ContentType 'application/json'

It is on Microsoft Intune to check whether that filter belongs on that policy. It does not check. The call returns success, and more importantly the value is still there when you read it back. That distinction matters, because an API that accepts a value and silently drops it is its own kind of bug and looks identical from the outside.

Screenshot 2 - Four cross-platform assignments, all accepted, all still there after a read-back.

Here is one of the two assignments on FilterDemo - Windows Security Baseline, a policy whose platforms value is windows10, where 983bb135-... is the macOS filter:

{
  "@odata.type": "#microsoft.graph.groupAssignmentTarget",
  "deviceAndAppManagementAssignmentFilterId": "983bb135-92ad-4155-8807-7664008466ec",
  "deviceAndAppManagementAssignmentFilterType": "include",
  "groupId": "83bdd559-ae02-44f4-a31e-a0f3df155234"
}

How a mismatched filter breaks your targeting

It would be easy to shrug this off. A macOS filter can never match a Windows device, so surely it is inert?

It is not, and this is the part I found most interesting. Graph will tell you which properties each platform supports, through getPlatformSupportedProperties, and the two lists almost completely overlap:

Nine of the ten properties a macOS filter can use also exist on Windows. The platform value on a filter is not a constraint on the rule language, it is metadata that drives the picker. A rule written for one platform is, in the vast majority of cases, perfectly valid syntax on the other.

That changes the failure mode. A cross-platform filter is not dead weight Intune ignores, it is a real scope control sitting on your assignment where you cannot see how it got there. And the two modes fail in opposite directions:

• An include filter narrows an assignment to whatever its rule matches. Aim one at the wrong platform and there is nothing for it to match, on a policy that still reports as assigned.
• An exclude filter carves devices out of an assignment. Aim one at the wrong platform and there is nothing to carve, on a policy you believe has an exception in place.

Neither announces itself.

The portal shows it, then writes it back

This is where it stops being an API curiosity. Here is that Windows policy with two assignments: a correctly matched Windows filter on one group, and the macOS filter on another.

Screenshot 3 - Platform reads Windows. One row carries a Windows filter, the other a macOS filter. Same table, same presentation, both Active.

It renders as a healthy assignment

No warning, no badge, no greyed-out row. Both are listed by name with a status of Active. Nothing in the admin center distinguishes the assignment you are allowed to make from the one you are not.

Open the filter panel on that second assignment and the whole contradiction fits on one screen. The mode radio is correctly pre-selected from the API value. The list below it does not contain the filter that is currently applied. And at the bottom the portal holds the macOS filter in its Selected filter box, offering only Remove.

Screenshot 4 - The picker lists only Windows filters, while the Selected filter box below it holds a macOS filter, offering only Remove.

Look at the rules in that panel. The offered Windows filter reads (device.manufacturer -eq "Dell Inc.") and the retained macOS filter reads (device.manufacturer -eq "Apple"). Same property, same syntax, same rule language. The only thing separating them is a platform label that the picker honours and nothing else does.

It writes the mismatch back

So the next thing to test was what the portal does if you simply re-apply that assignment from the UI. Not editing it, not fixing it, just walking the same path an admin walks on any normal change: open the assignment, open the filter panel, leave everything as it is, Select, then Review + save.

Screenshot 5 - Saving a Windows policy whose assignment carries a macOS filter. The portal is satisfied.

That was not a UI-only no-op. The audit log records a write, attributed to the portal itself:

Screenshot 6 - The audit event for that save. Every old and new value is identical, and the write is attributed to the Microsoft Intune portal extension.

Every property in that event has an identical old and new value. Nothing changed, nothing needed changing, and the portal patched it anyway. I ran the harder version on a throwaway policy too, changing only the mode from include to exclude, and there the audit event showed the macOS filter’s own ID re-submitted on both sides. The portal does not merely tolerate the value, it hands it back to the API.

Finding it in your own tenant

This is trivially detectable, just not from the admin center. There is no column, filter or report that surfaces it, so you have to ask Graph: pull every policy with its assignments, pull every filter, join them on the filter ID and compare the two platform values.

I wrapped that up as a read-only script. It creates nothing, changes nothing and deletes nothing, it just reports. It handles the two things that trip up a first attempt: filter platforms and policy platforms use different vocabularies, so a plain string comparison reports false positives on perfectly healthy assignments, and a deleted filter leaves its ID behind on the assignment so the lookup misses rather than resolving.

Download Find-IntuneCrossPlatformFilters.ps1

./Find-IntuneCrossPlatformFilters.ps1

It needs the Microsoft.Graph.Authentication module and the DeviceManagementConfiguration.Read.All scope. Worth adding to whatever tenant health check you already run.

The screenshots

Use the arrows or dots to step through, and the expand icon for a full-screen view.

‹ ›

1. Both filters in the tenant list, with their Platform column.
2. Four cross-platform assignments, all accepted, all still there after a read-back.
3. Platform reads Windows. One row carries a Windows filter, the other a macOS filter. Same table, same presentation, both Active.
4. The picker lists only Windows filters, while the Selected filter box below it holds a macOS filter, offering only Remove.
5. Saving a Windows policy whose assignment carries a macOS filter. The portal is satisfied.
6. The audit event for that save. Every old and new value is identical, and the write is attributed to the Microsoft Intune portal extension.

Conclusion

The lesson is not really about filters. The admin center is a shell around an API, and a fair amount of what looks like a rule of Intune turns out to be a rule of that shell. Pull the two apart and the safeguards do not come with you: the API underneath accepts what the portal would have refused, and says nothing about it. So read “the UI does not offer it” as “nobody checked this below the UI”. No automation inherits those safeguards for you, which makes them yours to build.

Run the script against your own tenant. Not because you certainly have one of these, but because you cannot see it if you do.

References

• Create assignment filters in Microsoft Intune
• Assignment filter properties and operators reference
• Platforms and policy types supported by assignment filters
• getPlatformSupportedProperties function - Microsoft Graph beta
• deviceManagementConfigurationPolicyAssignment resource type - Microsoft Graph beta

Table of Contents

• The problem it solves
• What the Export API does
• What it can replace
• How it works

The problem it solves

The operational Graph endpoints are great at answering one small question at a time: the state of a device, the settings on a policy. The trouble starts when you want the whole picture across the tenant. You end up nesting loops - devices, then their policies, then their settings - and the number of calls multiplies until you are firing off tens of thousands of requests per run. You spend more time fighting throttling and retries than actually using the data. And the frustrating part is that it is not the amount of data that is slow, it is the sheer number of round trips.

What the Export API does

The Export API flips the model. Instead of you pulling raw pieces and stitching them together, you ask Intune to build the finished report on its side and hand you the file. It is the programmatic version of the Export button in the admin center: the same reports, generated server-side and delivered as a single file, a zipped CSV or JSON. One request kicks off the job, and once Intune has built it you download that one file, whatever the size of the tenant.

What it can replace

Anywhere you are looping Graph to build a bulk report, the Export API can replace the whole loop. Compliance per setting, app install status, device inventory, Defender health, Windows update rollout - if you can see it in the admin center, there is almost certainly a report name for it. Microsoft’s own example took a compliance export from roughly 100,000 calls and 2.5 hours down to about 15 calls and 15 minutes (source). In a small test tenant of my own, the same compliance report came back in three Graph calls and about eleven seconds. Same data, a fraction of the effort, and it barely grows as the tenant does.

The best part is that it is one endpoint for the entire Intune reporting catalog. Change the report name and you are exporting something else, using the exact same flow.

How it works

Under the hood it is three simple steps: ask for a report, wait for it to finish, download the result. In PowerShell that is only a handful of lines with the Microsoft.Graph.Authentication module:

# Install the only module we need if it is not already there
if (-not (Get-Module Microsoft.Graph.Authentication -ListAvailable)) {
    Install-Module Microsoft.Graph.Authentication -Scope CurrentUser -Force
}

Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
$uri = 'https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs'

# 1. Ask Intune to build the report
$job = Invoke-MgGraphRequest -Method POST -Uri $uri -Body @{
    reportName = 'DeviceStatusSummaryByCompliancePolicySettingsReportV3'
    format     = 'csv'
}

# 2. Wait for the job to finish
do {
    Start-Sleep -Seconds 5
    $job = Invoke-MgGraphRequest -Method GET -Uri "$uri('$($job.id)')"
} until ($job.status -eq 'completed')

# 3. Download the finished file (a zipped CSV)
Invoke-WebRequest -Uri $job.url -OutFile 'report.zip'

That is the whole idea. Kick off a job, poll until it is done, download one file. So the next time you catch yourself writing a loop over every device in the tenant, stop and check whether a report already exists. There is a good chance it does, and the Export API will hand it to you in a single shot. And if you like turning raw Intune data into something you can act on, take a look at my Intune anomalies report next.

That is the part administrators need to notice. You can review the visible Registration campaign and System-preferred authentication settings in the Entra admin center and still miss the control over Microsoft’s automatic rollout. The temporary opt-out is a Microsoft Graph property named optOutSettings.passkeyDynamicMigration.

This is not an article about a new switch to turn on. It is about avoiding two bad surprises: users receiving passkey prompts before your support and communication plan is ready, or an organisation assuming that an opt-out keeps Microsoft-provided SMS working after February 2027.

Table of Contents

• Start with the change Microsoft is making
• The hidden control: passkey dynamic migration
• The portal controls: registration and sign-in preference
• How the settings work together
• What should my tenant do?
• Four checks before you change anything

Start with the change Microsoft is making

The timeline explains why the Graph property matters.

The September action does not silently create a passkey. It changes policy and campaign scope. At a later MFA sign-in, the user is nudged to register the credential themselves. The February prompt is different: it cannot be skipped.

The hidden control: passkey dynamic migration

Microsoft publishes the temporary opt-out for the September rollout through Microsoft Graph. Put plainly: this control is not a portal setting alongside Registration campaign or System-preferred authentication. It is a tenant-wide property on the authentication methods policy.

Do not treat it as a third three-state policy. Its useful values are simpler:

Use the property when you need to control the timing of Microsoft’s automatic passkey rollout while you move SMS and voice users to the authentication method you selected. That might be passkeys, a different registration-campaign target such as Microsoft Authenticator, or a customer-managed telecom provider for a defined population.

Check the current value

It requires Policy.Read.AuthenticationMethod and either the Global Reader or Authentication Policy Administrator role.

Connect-MgGraph -Scopes 'Policy.Read.AuthenticationMethod' -NoWelcome

$policy = Invoke-MgGraphRequest `
    -Method GET `
    -Uri 'https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy'

$policy.optOutSettings | Format-List

An absent property or a value other than true means the tenant has not used this temporary opt-out. It does not say that SMS and voice are safe after February 2027.

Apply the temporary opt-out

If you want to temporarily opt out, use Policy.ReadWrite.AuthenticationMethod. Authentication Policy Administrator is the least-privileged built-in role.

Connect-MgGraph -Scopes 'Policy.ReadWrite.AuthenticationMethod' -NoWelcome

$body = @{ optOutSettings = @{ passkeyDynamicMigration = $true } } |
    ConvertTo-Json -Depth 4

Invoke-MgGraphRequest `
    -Method PATCH `
    -Uri 'https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy' `
    -ContentType 'application/json' `
    -Body $body

The endpoint is under Graph /beta. Recheck Microsoft’s retirement guidance before making a production change, and record the approval, response, and exit plan.

The portal controls: registration and sign-in preference

The Graph setting decides whether Microsoft temporarily performs its automatic rollout. The following portal settings have different jobs and their own states.

Registration campaign: ask users to register

A registration campaign is an adoption tool. After a targeted user completes MFA, Entra can prompt them to register a passkey or Microsoft Authenticator. For a passkey campaign, passkeys (FIDO2) and self-service setup must already be enabled.

A campaign asks a user to register. It does not create a passkey, make it their default sign-in choice, or remove SMS and voice. Microsoft’s registration-campaign guidance has the exact prerequisites and nudge behaviour.

System-preferred authentication: offer a method that exists

System-preferred authentication is a sign-in selection rule. If a user has a password, Authenticator, and a passkey, Entra can offer the passkey first. If they have not registered a passkey, there is nothing to offer.

Users can choose Sign in another way. Conditional Access and authentication strengths still take precedence. Microsoft documents the current ordering and limitations.

How the settings work together

These are the three user paths that matter:

1. A deliberate rollout: You set Registration campaign to Enabled for a pilot group. The user completes MFA, sees the passkey prompt, and registers a passkey. With System-preferred authentication enabled, that passkey can be offered first at a later sign-in.

2. Microsoft-managed migration: The user is still enabled for SMS or voice on September 1, 2026 and the tenant has not opted out. Entra enables passkeys for the user and brings them into a Microsoft-managed passkey campaign. At their next qualifying MFA sign-in, they see the nudge and choose whether to complete registration. System-preferred authentication can only offer the passkey after it exists.

3. Temporary opt-out: passkeyDynamicMigration is true. Microsoft does not perform the automatic September policy and campaign rollout for the tenant during the opt-out period. Your own campaign and system-preferred settings remain separate decisions. The February retirement date does not move.

Dynamic migration changes policy and campaign scope → the campaign prompts registration → system-preferred authentication changes a later sign-in experience

What should my tenant do?

Four checks before you change anything

• “Our users already have Authenticator, so the September rollout does not apply.” Not necessarily. Microsoft scopes the automatic rollout to users who are enabled for SMS or voice in the Authentication Methods Policy or legacy MFA settings. Authenticator registration alone does not remove that scope.

• “System-preferred authentication will create the passkey.” No. It offers the strongest suitable method the user has already registered. Use a Registration campaign when you need users to create a new method.

• “The Registration campaign migrates users.” It asks them to register after MFA. The user still completes passkey registration, or postpones the prompt where the campaign allows it.

• “Opting out means SMS will still work after February 2027.” It only delays Microsoft’s September automatic passkey enablement and campaign rollout. It does not extend Microsoft-provided SMS or voice.

References

• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• System-preferred authentication in Microsoft Entra ID
• Get authenticationMethodsPolicy - Microsoft Graph beta
• Update authenticationMethodsPolicy - Microsoft Graph beta

Two years ago, I solved that with a PowerShell Win32 app. It worked, but every new country meant working out the values, detection, packaging, and targeting again. Language Pack Deployer lifts that solution into a web app: define the state, choose the Intune method, set targeting, and download or publish the deployment.

Table of Contents

• The problem it solves
• Three Windows deployment methods
• Win32 app: enrollment and rollback
• Platform Script: direct configuration
• Remediations: ongoing state
• Device state, user state, and targeting
• From browser to Intune
• A practical rollout
• Conclusion
• Related

The problem it solves

Language configuration includes the pack, keyboard behaviour, date and time format, decimal separator, region, system locale, and time zone. Two users can share a display language while needing different keyboard behaviour for accented characters.

The manual answer becomes a folder of almost-identical scripts. Language Pack Deployer replaces that repetition with 100 locale presets and defaults you can override.

Three Windows deployment methods

Windows gives you three valid delivery models. They are not interchangeable: a successful script run, a successful installation, and a device that remains in the intended state are different outcomes.

The same workflow can also create a macOS shell script.

Win32 app: enrollment and rollback

Choose a Win32 app when language configuration belongs in Autopilot enrollment or a required-app lifecycle. Before changing the device, it records the original language state with a deterministic configuration ID. On uninstall, the generated script restores that state. Language packs can remain on disk, but the device returns to its previous configuration.

Detection can also adopt a device that is already correct, rather than reinstalling language packs. The .intunewin package is built in the browser, while its final upload runs from the generated Deploy-Win32App.ps1 on your own device. A browser-only app cannot upload Win32 content to Intune without a relay service.

Platform Script: direct configuration

Choose a Platform Script when you need to apply a configuration directly but cannot use Remediations in the tenant. It is the practical option for a one-time change when scheduled detection and correction are not available.

A successful run proves that Intune ran the script, not that a user or policy did not later change the state. Use Remediations when you must prove and correct the state over time.

Remediations: ongoing state

Choose Remediations when Intune needs to enforce the intended language state. Its separate, read-only detection script evaluates installed languages, system UI language, system locale, and time zone. If the actual state does not match the configuration, the remediation script corrects it.

You can run the policy once for a controlled correction, or schedule it hourly or daily when the device should be checked for drift over time.

Unlike a Win32 receipt, this checks the current state, not only whether an installer completed.

Before publishing a Remediations policy, the flow checks Windows license verification. Intune can accept a policy that will never run if verification is off, so Language Pack Deployer requires that setting to be enabled before the deployment continues. Microsoft documents the wider Remediations licensing and scheduling model.

Device state, user state, and targeting

For Platform Scripts and Remediations, choose device scope, user scope, or both:

• Device-wide and new-user defaults run as SYSTEM and prepare language packs, system settings, the welcome screen, and future profiles.
• Existing logged-on users update the active profile’s language list, keyboard, culture, display-language override, and home region.

Selecting both creates separate policies and makes the user policy wait for device preparation. You can create one deployment per language with its own assignment, or bundle several languages and choose the primary display language. Every artifact supports its own scope tags, groups, assignment filters, and Remediations schedule.

From browser to Intune

When you sign in, Language Pack Deployer uses delegated Microsoft Graph permissions directly against your own tenant. It acts as your Entra ID account, so every action respects the Intune RBAC roles and Entra permissions that account already has. It does not use a client secret or an app-only identity with its own standing access.

The app reads groups, scope tags, and assignment filters, then creates and assigns the Intune artifact through these Graph routes:

The requested delegated permissions are scoped to that workflow:

You can build and review every artifact without signing in. If you prefer not to grant a browser access to the tenant, download the files instead: scripts are generated in the correct format for manual Intune upload, Remediations are exported as Detect-LanguagePack.ps1 and Remediate-LanguagePack.ps1, and the Win32 bundle includes the .intunewin, deployment script, and README. The Win32 route keeps the same privacy boundary even when publishing, because the final upload runs from your own PowerShell session.

A practical rollout

1. Select the operating system and required locales, then confirm keyboard behaviour, region, and time zone.
2. Choose separate output for per-language targeting, or a bundle for shared devices.
3. Select Win32 for enrollment and rollback, Platform Script for a direct action, or Remediations for enforcement.
4. Choose device state, existing-user state, or both.
5. Review the output, set scope tags and pilot assignments, then validate a user session after a sign-out or restart.

For a returned device that has been wiped, this replaces the hunt for an old country-specific script. Reapply the intended configuration and target it the same way you would any other managed state.

Conclusion

Language Pack Deployer turns an error-prone international configuration task into a reviewed Intune deployment. Build the language state once, choose the method that matches the lifecycle, and publish it with the targeting already in place.

Open Language Pack Deployer and download an artifact before you connect a tenant.

Related

• MacPPPC: Build and Deploy macOS PPPC Profiles to Intune from Your Browser - another browser-based Intune tool that creates and targets policies directly from the browser.

The profile is fine. The setting applied. It just does not do anything anymore. OneDrive’s OpenAtLogin managed preference has been deprecated since sync app 24.113 and is a no-op on current builds - yet macOS baselines everywhere still set it and assume OneDrive launches at login. Even Microsoft’s own end-to-end guide for macOS endpoints still tells you to set Open at login: True. And the setting that looks like the obvious replacement - a Managed Login Items profile - can’t do the job either, for a reason worth understanding on its own.

This post is a snapshot of behavior I verified on-device in July 2026, on OneDrive sync app 26.113 and macOS 26.x. Re-check the referenced pages against your own builds before rolling anything out.

Table of Contents

• The setting every baseline still ships
• Managed, allowed, and still disabled
• Allow is not enable: the BTM mental model
• The fix: /createloginitem, as the signed-in user
• Deploying it: a ready-made Intune script
• Verifying on a device
• What this does not fix
• Conclusion
• Related
• References

The setting every baseline still ships

For years, making OneDrive start automatically on a managed Mac was one managed preference - Microsoft Office > Microsoft OneDrive > Open at login in Intune’s Settings Catalog:

<key>OpenAtLogin</key>
<true/>

Microsoft’s OneDrive for Mac deployment documentation now carries this note on the setting:

“The OpenAtLogin setting will be deprecated with Sync app 24.113. Please refer to Background services to configure the appropriate profile for enabling OneDrive to start automatically when the user logs in.”

The background is macOS 13 (Ventura): Apple moved login items and background services under Background Task Management (BTM), the framework behind the “Login Items & Extensions” pane in System Settings. Since then, OneDrive listens to the macOS login item system instead of its own preference. The pref still applies cleanly - defaults read will happily show you OpenAtLogin = 1 under /Library/Managed Preferences - it just no longer does anything. Nothing errors, nothing reports non-compliant, the profile shows green in Intune. OneDrive simply is not there after login.

One important scoping note: Macs that have been in use for a while do not show this. Their login item was registered long ago - back when the pref still worked, or the first time the user flipped the toggle - and that registration persists across OneDrive updates and reboots. This is purely a fresh-enrollment problem, which is exactly why it slips through: the longtime devices in your pilot group look fine while every newly provisioned Mac comes up wrong.

Managed, allowed, and still disabled

The deprecation note points at the “Background services” profile as the replacement, and that is where the second trap sits. That profile is a Managed Login Items payload (com.apple.servicemanagement) - typically an allow rule for Microsoft’s team identifier UBF8T346G9 - and on my baseline it was already deployed.

So: managed preference applied, Managed Login Items rule applied, and OneDrive still absent from System Settings > General > Login Items & Extensions after enrollment. Time to ask BTM itself, with its forensics tool sfltool:

% sfltool dumpbtm | grep -A8 "Name: OneDrive Launcher"
                 Name: OneDrive Launcher
       Developer Name: Microsoft Corporation
      Team Identifier: UBF8T346G9
                 Type: login item (0x4)
          Disposition: [disabled, allowed]
    Bundle Identifier: com.microsoft.OneDriveLauncher

(Output trimmed; the exact field layout varies a little between macOS builds. The Disposition line is what you are after.)

That disposition line is the smoking gun: [disabled, allowed]. The profile did its job - the item is allowed, the user cannot toggle it off, no nag notification. But it is still disabled, because nothing ever enabled it. Two different flags, owned by two different parties.

Allow is not enable: the BTM mental model

This is the mental model that makes the whole thing click, and it applies to far more than OneDrive:

On macOS Ventura and later, an MDM profile approves login and background items - it never enables them.

Apple’s MDM documentation describes the Managed Login Items payload as making an item “automatically approved”. What the payload does not contain is any mechanism to register a login item the app has not registered itself. Registration goes through Apple’s SMAppService API, and that call has to come from the app side, in a user context.

Under the old model, OneDrive registered its own launcher because the pref told it to. Under the new model, it registers the login item when the user flips the toggle in OneDrive’s preferences - and on a freshly provisioned Mac, nobody has flipped it. Every layer the MDM admin controls is green, and the one layer that actually starts the app is untouched.

The fix: /createloginitem, as the signed-in user

Microsoft closed this gap in OneDrive 26.027 with two command-line arguments that programmatically register or unregister the login item:

# Register OneDrive as a login item
open -a OneDrive --args /createloginitem

# Unregister OneDrive as a login item
open -a OneDrive --args /removeloginitem

These are fire-and-exit commands: OneDrive performs the registration and immediately terminates without launching the full sync client. On my test device, /createloginitem flipped the BTM disposition from [disabled, allowed] to [enabled, allowed], and it persisted across a reboot.

Two constraints matter for deployment:

• OneDrive 26.027 or later, macOS 13 or later. Older sync builds do not know the argument (and pre-24.113 builds still honor OpenAtLogin anyway).
• It must run as the signed-in user. open -a targets the user’s GUI (Aqua) session. Run it as root or another local account and it fails - on my device, running it as the local admin produced a blunt Unable to find application named 'OneDrive', even though the app was right there in /Applications.

Deploying it: a ready-made Intune script

You could deploy the one-liner as-is, but on real fleets the timing is against you: the script can land before OneDrive does, the installed build can be too old, and a recurring Intune script should not keep poking OneDrive after the job is done. A guarded, idempotent version is published in Microsoft’s Intune My Macs repo as scr-app-108-onedrive-openatlogin.zsh, which:

• No-ops until OneDrive is installed - handles the enrollment race, and means OneDrive does not need to be a required app. The script self-heals whenever OneDrive lands, by any install path.
• No-ops below 26.027 - older builds still honor the legacy pref, so the script stays out of the way rather than launching the full app.
• Runs the enable exactly once - a per-user marker file makes every subsequent scheduled run a cheap no-op that never re-launches OneDrive. Delete the marker to force a re-run.

Deploy it under Devices > macOS > Shell scripts with Run script as signed-in user = Yes, execution frequency every 15 minutes, 3 retries. The cadence exists purely to win the enrollment race; once the marker is down, it costs nothing.

Keep your Managed Login Items profile alongside it: the script enables the login item, the profile is what stops the user from disabling it again. You want both halves.

Verifying on a device

After the script has run for the signed-in user, check the BTM disposition (works without sudo for your own session):

% sfltool dumpbtm | grep -A8 "Name: OneDrive Launcher"
                 Name: OneDrive Launcher
       Developer Name: Microsoft Corporation
      Team Identifier: UBF8T346G9
                 Type: login item (0x4)
          Disposition: [enabled, allowed, notified]
    Bundle Identifier: com.microsoft.OneDriveLauncher

[enabled, allowed] is the healthy end state: enabled by the registration command, allowed (and locked) by the profile. OneDrive now shows up in Login Items & Extensions with the toggle greyed out, and it opens at login on the next reboot without anyone touching anything. One reading tip: OneDrive also registers developer-group (0x20) and app (0x2) entries that can legitimately show [disabled] - the login item entry, type 0x4, is the one that matters.

What this does not fix

Login-item registration gets OneDrive launched at login. It does not remove the one-time first-run experience: the user still signs in once, and macOS still asks the user to enable OneDrive’s File Provider the first time. That consent is an Apple user-privacy gate - no MDM payload, profile, or script automates it, by design. Budget for it in your onboarding communication instead of hunting for a setting that does not exist.

Conclusion

If your macOS baseline sets OneDrive’s Open at login and you are on a current sync build, that setting is doing nothing - and the Managed Login Items profile that the deprecation note points you toward can only allow the login item, never enable it. The only mechanism that actually enables it is OneDrive’s own /createloginitem command (26.027+), run as the signed-in user - deployed most easily via the ready-made scr-app-108 script in the Intune My Macs repo.

The broader lesson travels beyond OneDrive: on macOS Ventura and later, Background Task Management splits login items into an allow flag the MDM owns and an enable flag only the app (in user context) can set. Any baseline that assumes a profile alone gets an app running at login is making a bet that Apple has already voided. Audit yours with sfltool dumpbtm - [disabled, allowed] is the tell.

Related

• macOS LAPS vs. Intune Password Compliance Policy: Why It Breaks - another macOS-via-Intune behavior where a policy that looks passive quietly changes device state.
• MacPPPC: Build and Deploy macOS PPPC Profiles to Intune from Your Browser - more macOS payload plumbing where Apple’s MDM rules bite if you get the details wrong.

References

• Microsoft Learn - Deploy and configure the OneDrive sync app for Mac - the OpenAtLogin deprecation note, the Background services profile, and the /createloginitem / /removeloginitem command-line arguments.
• GitHub - Intune My Macs, SCR-APP-108 - the guarded, run-once deployment script.
• Microsoft Learn - OneDrive Sync Release Notes - the sync app builds that shipped the login-item command line support.
• Apple Platform Deployment - Manage login items and background tasks - Apple’s documentation of the approve-not-enable behavior (“When an item matches a rule, the item is automatically approved”).

The password is correct. It is the exact value Intune generated and stored. macOS is rejecting it anyway, because something told Open Directory that this account needs to change its password before it can authenticate. Unless you deliberately turned on “Change at next authentication” (in which case this is expected), that “something” on current macOS is almost always a compliance policy carrying password settings.

This post is a snapshot of behavior I have reproduced in test environments running macOS 26.5.x. Apple’s Open Directory enforcement can change between releases, so re-test on your own build before assuming any of this still applies.

Table of Contents

• What macOS LAPS actually does
• How you notice the problem
• Why it happens: compliance policies enforce, they don’t audit
• The catch even Microsoft flags
• Is the admin account even there?
• The fix that works today
• Conclusion
• Related
• References

What macOS LAPS actually does

When a Mac enrolls through an Automatic Device Enrollment (ADE) profile that has the local admin account option turned on, Intune provisions a managed administrator with a strong random password, stores it encrypted, and rotates it automatically on the schedule you configure. You retrieve the current password from the Intune admin center under Devices > macOS devices > the device > Passwords and keys.

That managed admin sits on top of Open Directory (OD), the macOS subsystem that owns local accounts and their password policy. This matters, because OD does not treat the LAPS admin as special. Any passcode rule that lands on the device applies to every managed account, the LAPS admin included. That single design fact is the root of everything below.

How you notice the problem

There is no error popup that says “your compliance policy invalidated the LAPS password.” You find out the hard way: an admin authentication prompt rejects the stored password. Installing a package, changing a protected setting, unlocking a system preference, anything that elevates, fails as if you typed the wrong thing.

To confirm it is the account and not your typing, open Terminal on the Mac and authenticate directly against Open Directory:

% dscl . -authonly <admin-name> '<password-from-intune>'
<dscl_cmd> DS Error: -14161 (eDSAuthNewPasswordRequired)

A healthy account returns nothing and exits 0. The error name is the tell: eDSAuthNewPasswordRequired means Open Directory recognizes the credential but will not let the account authenticate until its password is changed. That is what separates this bug from a genuine typo, where you would instead get eDSAuthFailed (-14090). The password is correct; the account is flagged.

Why it happens: compliance policies enforce, they don’t audit

Here is the mental model that trips people up. A compliance policy looks like a read-only health check: it inspects the device and reports a verdict back. It is not. When a compliance policy contains password settings, Intune pushes those rules to the device and macOS enforces them. The compliance engine is policy-applied, not policy-read.

Microsoft says this plainly in its macOS LAPS documentation:

“Password settings configured through compliance policies or device restriction templates enable Change at next authentication by default and can cause sign-in issues for newly created LAPS accounts.”

Microsoft Learn - Configure macOS ADE local account configuration with LAPS

So a compliance policy that merely checks for a password also flips on Change at next authentication, and OD enforces that flag against the LAPS admin. The freshly rotated password is, from OD’s point of view, a password that must be changed before it can be used.

What makes this so easy to miss is that most admins mirror their password requirements in a Settings Catalog configuration profile as well. The compliance policy and the config profile look consistent, the same length, the same complexity, so nothing looks like it is in conflict. The compliance policy’s hidden side effect never draws attention until the managed admin stops authenticating.

This is the shape that causes it, expressed as the macOS compliance policy resource:

{
  "@odata.type": "#microsoft.graph.macOSCompliancePolicy",
  "displayName": "macOS - Passcode Compliance",
  "passwordRequired": true,
  "passwordBlockSimple": true,
  "passwordMinimumLength": 8,
  "passwordRequiredType": "alphanumeric"
}

Every password* key here is enforced, not audited. The moment this policy reaches the Mac, OD applies the rules to all managed accounts.

Because the cause lives in Apple’s Open Directory rather than in Intune, this is not strictly an Intune problem. The same symptom has been reported on other MDM platforms too (see the references at the end), which is exactly what you would expect from an Apple-side cause. Switching management platforms does not move the wall.

The catch even Microsoft flags

You might assume that turning Change at next authentication off makes you safe. It is the right thing to do, but Microsoft documents a known issue where it was not enough:

“There is a known issue that affects devices running macOS versions earlier than macOS 26.4. When a macOS device enrolls via ADE with a configured local admin account and a targeted passcode profile, it prompts for an admin password reset, even if Change at next auth is not enabled or if a value is set for Max Age (days). This does not affect the standard account.”

Microsoft Learn - Configure macOS ADE local account configuration with LAPS

Microsoft’s documented workaround and fix are these:

“As a workaround, manually rotate the admin password after the reset on the device to keep the Intune and device password state in sync. Upgrade your device to macOS 26.4 to resolve this issue.”

Microsoft Learn - Configure macOS ADE local account configuration with LAPS

None of this makes compliance password settings wrong to use, the trade-off is just worth being honest about. Rotating the password by hand when you take over a device is a perfectly fine approach, and if it suits your workflow there is nothing wrong with it. Just know who ends up doing it: if your Intune RBAC roles do not let the helpdesk rotate the macOS LAPS password, every reset escalates to whoever holds that permission, which is often you.

Is the admin account even there?

Before you blame the bug, rule out a simpler explanation: maybe the account was never created in the first place. ADE enrollment can hiccup - a network drop during Setup Assistant, a profile that lands late - and a half-finished enrollment can leave the device without a managed admin at all. From the prompt, that looks identical to a rejected password, so confirm the account actually exists before going further.

Run these on the Mac:

% id <admin-name>
uid=503(<admin-name>) gid=20(staff) groups=20(staff),80(admin)

% dseditgroup -o checkmember -m <admin-name> admin
yes <admin-name> is a member of admin

If id returns “no such user”, the account was never delivered, investigate the enrollment, not the password. If the account exists but is not in admin, the profile bound the record without the group membership. If both look healthy but dscl . -authonly still fails, you are looking at the enforcement bug.

On the tenant side, the Passwords and keys pane shows whether Intune is holding a password for this device and when it last rotated. If the pane is empty or the rotation date is old, Intune is not managing the credential the way you think it is, and that is a device or MDM-channel problem rather than the Open Directory bug.

The fix that works today

The fix is to stop letting the compliance policy carry the passcode rules and deliver them declaratively through DDM instead. Two steps:

1. Remove the password settings from your macOS compliance policy. Take passwordRequired and its companions out so the policy stops implicitly enabling Change at next authentication.
2. Recreate the requirement in a Settings Catalog passcode profile. The Settings Catalog is applied declaratively through DDM, not enforced the way a compliance policy is, so it sets your rules without flipping the forced-change flag against managed accounts. The one setting that clears the lockout is Change at next authentication, set explicitly off (shown here as the single setting fragment, not a complete policy you can import on its own):

{
  "settingDefinitionId": "passcode_changeatnextauth",
  "choiceSettingValue": { "value": "passcode_changeatnextauth_false" }
}

Moving to DDM costs you no enforcement. The same declarative profile still lets you require and shape the passcode: demand it exists, force alphanumeric complexity, set a minimum length, lock out after failed attempts, expire passwords on a schedule, and block reuse. Set the values to match your own baseline; the only one that matters for this bug is passcode_changeatnextauth, kept off. Here are a few examples:

With the requirement delivered this way, rotate the admin password once more from Intune and confirm it authenticates before you need it under pressure:

% dscl . -authonly <admin-name> '<password-from-intune>'
%

No output, exit 0. That is the only proof that matters. Make this check part of your routine after every rotation and on every new macOS release.

Conclusion

The lesson is smaller than the symptom suggests: a compliance policy is enforcement, not an audit. On the Mac that distinction is expensive, because Open Directory applies password rules to every managed account and the LAPS admin gets caught in it. This is not a reason to avoid compliance policies, it is a reason to be deliberate about where the password requirement lives. If rotating the admin password by hand when you take over a device fits your workflow, that is a valid choice, just be clear on who in your RBAC model actually holds that permission. My own preference is to push the requirement declaratively through DDM (the Settings Catalog), with Change at next authentication off, so the forced change never happens and there is nothing to rotate after the fact. Either way, verify with dscl . -authonly after each rotation.

This is a snapshot of macOS 26.5.x behavior. The ADE enrollment variant is resolved in macOS 26.4 (per Microsoft Learn), but the underlying enforcement still comes from Apple’s Open Directory, so re-test whenever you move to a new major release.

Related

• OneDrive Open at Login on macOS: Why It Stopped Working - another green-in-Intune macOS setting that silently stopped doing anything.
• MacPPPC: Build and Deploy macOS PPPC Profiles to Intune from Your Browser - another corner of macOS-via-Intune management where Apple’s MDM rules bite if you get the details wrong.
• Forgotten Features, Part 4: Intune Custom Compliance Policies - more on what Intune compliance policies can and cannot do, and how to extend them with custom checks.

References

• Microsoft Learn - Configure macOS ADE local account configuration with LAPS
• Microsoft Learn - macOS device compliance settings in Intune
• Omnissa KB 89299 - Managed Admin Passwords Fail to Authenticate macOS Devices (Workspace ONE - same symptom)
• Jamf community - admin LAPS password not working (Jamf Pro - community report of the same symptom)
• IntuneSettingsCatalogData - passcode setting definitions
• man dscl and man dseditgroup (local macOS reference)

Table of Contents

• What is InforcerCommunity?
• Requirements
• Installation
  • Option 1: From PowerShell Gallery (recommended)
  • Option 2: From source (GitHub)
• Quick Start
• Reports
  • Discovering Report Types
  • Running a Report
  • Execution Modes
  • Pipeline and Bulk Runs
• Assessments
  • Single-Tenant Assessment
  • Multi-Tenant Assessment Matrix
  • Assessment Export Options
• Tenant Documentation
• Environment Comparison
• Key Cmdlets and Use Cases
• Output Formats and Filtering
• How to Contribute
• How to Report Bugs
• How to Request a Feature
• Conclusion

What is InforcerCommunity?

InforcerCommunity is a PowerShell script module that talks to the Inforcer REST API.

What it gives you:

• Connect once, query everything: Authenticate with your Inforcer API key and region, then run cmdlets to list tenants, baselines, policies, alignment details, users, and audit events.
• Consistent behavior: All Get-* cmdlets support -Format, -OutputType (PowerShellObject or JsonObject), and -TenantId for filtering. TenantId accepts a numeric ID, Microsoft Tenant ID (GUID), or tenant name.
• No secrets in scripts: The API key is stored as a SecureString in the session; you can pass it once via Connect-Inforcer and then run as many commands as you need.
• Tab completion and help: Every cmdlet has comment-based help; Get-Help Connect-Inforcer -Full and tab completion on parameters (e.g. -EventType on Get-InforcerAuditEvent) work out of the box.
• Pipeline support: Pipe tenants into other cmdlets - e.g. Get-InforcerTenant | Get-InforcerUser or Get-InforcerTenant | Get-InforcerTenantPolicies works out of the box.

Where to find it:

• Source code and issues: https://github.com/royklo/InforcerCommunity
• PowerShell Gallery: https://www.powershellgallery.com/packages/InforcerCommunity

Community project notice: InforcerCommunity was created by me for the community. It is not owned, endorsed, or maintained by Inforcer. It is an independent, community-driven project to make the Inforcer API easier to use from PowerShell. You use it at your own responsibility.

For per-version detail, see the CHANGELOG in the repository. This post focuses on what the module does and how to use it.

Requirements

• PowerShell 7.0 or later (Windows, macOS, or Linux).
• An Inforcer API key from your Inforcer tenant (Configure > REST API > New API Key).

Installation

Option 1: From PowerShell Gallery (recommended)

Install-Module -Name InforcerCommunity -Scope CurrentUser

Option 2: From source (GitHub)

git clone https://github.com/royklo/InforcerCommunity.git
cd InforcerCommunity
Import-Module ./module/InforcerCommunity.psd1 -Force

Important: When loading from source, always run Import-Module from the repository root and use the path ./module/InforcerCommunity.psd1. If you see errors about a missing file or wrong path, make sure you are in the InforcerCommunity repo root.

Quick Start

After installing the module:

# Connect with your API key (region: uk, eu, us, or anz)
Connect-Inforcer -ApiKey "your-api-key" -Region uk

# List all tenants you have access to
Get-InforcerTenant

# Get alignment details in table format
Get-InforcerAlignmentDetails

# Get users for a tenant (by name, numeric ID, or GUID)
Get-InforcerUser -TenantId "Contoso"

# Get policies for a specific tenant
Get-InforcerTenantPolicies -TenantId 482

# Disconnect when done
Disconnect-Inforcer

You can use Get-Help <CmdletName> -Full for parameters and examples (e.g. Get-Help Get-InforcerUser -Full).

Reports

Inforcer’s Reports API generates ready-made tenant reports - Active User Count, Tenant Audit Report, Copilot Adoption, and more. InforcerCommunity wraps the full lifecycle (discover, queue, poll, download) in four cmdlets, with Invoke-InforcerReport doing the heavy lifting end-to-end.

The two API scopes you need are Reports.Read (to discover types and download outputs) and Reports.Run (to queue runs). If you target a tenant by GUID or name instead of its numeric Client Tenant ID, you also need Tenants.Read. Connect-Inforcer accepts any valid API key regardless of scope, so a Reports.Read-only key works fine for read-only workflows. On HTTP 401 it reports a meaningful message instead of a raw status code, and every API error surfaces field-level detail from the server’s errors[] array along with the x-correlation-id header for support tickets.

Discovering Report Types

Start by listing what’s available. The catalog is cached after the first call, so this is instant on repeat and powers tab completion on -ReportType:

# List every available report type
Get-InforcerReportType

# Filter to a single type by key
Get-InforcerReportType -Key CopilotAdoption

# Only types that support PDF output
Get-InforcerReportType -OutputFormat pdf

# Only types tagged 'security'
Get-InforcerReportType -Tag security

Running a Report

The simplest run queues a report, waits for it to finish, and saves the output to your current directory:

# Queue, wait, and save ActiveUserCount.csv to the current directory
Invoke-InforcerReport -ReportType ActiveUserCount -OutputFormat csv -TenantId 482

# Save somewhere specific and open it as soon as it lands
Invoke-InforcerReport -ReportType TenantAuditReport -OutputFormat html -TenantId 482 -OutputPath ./reports -Open

While it works, you get a three-phase progress bar - queue, then poll (with elapsed time and poll count), then download. The cmdlet accepts a tenant as a numeric Client Tenant ID, a Microsoft Tenant GUID, or a tenant name, and resolves it before submitting. If you reference a report type that isn’t in your cached catalog, it refreshes the catalog once before failing, so newly shipped report types work without a reconnect.

Some report types take a period. CopilotAdoption and ShadowAiDetection default to 30 days when you omit it; pass -ReportPeriod to override. To run a saved assessment as a report, use -ReportType Assessment with an -AssessmentId (tab completion accepts the friendly name and inserts the opaque ID):

Invoke-InforcerReport -ReportType Assessment -AssessmentId l1f8wd29pl44pp1j66r9 -OutputFormat pdf -TenantId 482

Execution Modes

Invoke-InforcerReport has three modes depending on how much you want it to do:

• Default - sync and save. Polls until each run is terminal, downloads every output, and emits one result object per saved file.
• -NoWait - fire and forget. Returns the run IDs immediately so you can check back later with Get-InforcerReportRun.
• -NoSave - poll until complete but write nothing. Returns the outputs metadata, ready to pipe into Save-InforcerReportOutput when you decide where the files should go.

# Fire and forget: returns RunIds immediately
Invoke-InforcerReport -ReportType CopilotAdoption -OutputFormat csv -TenantId 482, 139 -NoWait

# Poll without saving, then download on your terms
Invoke-InforcerReport -ReportType ActiveUserCount -OutputFormat csv -TenantId 482 -NoSave |
    Save-InforcerReportOutput -OutputPath ./reports

Get-InforcerReportRun lists recent runs and, with -RunId -Wait, polls a single run to completion - handy because freshly queued runs take about four minutes to appear in the list endpoint, while the polling path sees them as soon as they finish.

Pipeline and Bulk Runs

Because Get-InforcerReportType emits a Key alias that binds to -ReportType, you can discover and run in one line. The same OutputFormat broadcasts across every piped type:

# Run every security-tagged report type for a tenant, all as CSV
Get-InforcerReportType -Tag Security | Invoke-InforcerReport -OutputFormat csv -TenantId 482

# Pair report types to formats by index
Invoke-InforcerReport -ReportType TenantAuditReport, ActiveUserCount -OutputFormat pdf, csv -TenantId 482

# Bulk-download every output from every visible run
Get-InforcerReportRun -IncludeOutputs |
    ForEach-Object { $_.outputs } |
    Save-InforcerReportOutput -OutputPath ./bulk

A few client-side guards keep you out of known API edge cases: duplicate (type, format) pairs are removed before the request (the server would otherwise render duplicates in the wrong format), -Collate is rejected on report types the catalog marks as non-collatable, and unknown -Parameter keys are rejected up front instead of being silently ignored.

Assessments

Inforcer provides compliance assessments that evaluate your tenant against industry frameworks and readiness checks - things like Copilot Readiness, CIS Microsoft 365 Foundations Benchmark, CIS Microsoft Intune for Windows 11 Benchmark, and Essential Eight Maturity Level 1. With InforcerCommunity, you can run these assessments from the command line and get structured results you can automate with.

Single-Tenant Assessment

Run an assessment against one tenant and see every check with its pass/fail status:

# List available assessments
Get-InforcerAssessment

# Run Copilot Readiness against a tenant (by name)
Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness"

The output shows a compliance summary followed by each check as a pipeline object:

  Copilot Readiness - 76.2% compliant (16/21 checks passed)

Status           : Pass
name             : Enable Conditional Access policies to block legacy authentication
category         : Entra
subCategory      : Conditional Access
importance       : High
ObjectsEvaluated : 13
FindingsMessage  : 1 out of 13 object(s) are fully-compliant with this check
Scores           : {@{objectId=de66f385...; score=100; objectName=Core - Block - Legacy Authentication; ...}, ...}

Each check includes a Scores property with per-object detail - which Conditional Access policy passed, which failed, and why. You can drill into this:

$results = Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness"

# See only failed checks
$results | Where-Object Status -eq 'Fail'

# Table view
$results | Format-Table Status, name, category, importance

# Drill into violations for a specific check
$results[1].Scores | Where-Object { $_.violations.Count -gt 0 } | Select-Object objectName, score, violations

Generate an interactive HTML report with one parameter:

Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness" -OutputPath ./copilot-report.html

The HTML report includes a navy cover banner, compliance score ring, collapsible check cards grouped by category (Entra, Exchange, M365, Purview, SharePoint), per-object expandable cards showing violations and passes, and markdown-rendered description and remediation steps. Everything is self-contained - no external dependencies, works offline.

Multi-Tenant Assessment Matrix

The real power comes when you run an assessment across all your tenants at once:

# Run against all tenants
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant -OutputPath ./matrix.html

# Or pick specific tenants by name
Invoke-InforcerAssessment -TenantId "Contoso","Fabrikam","Woodgrove" -AssessmentId "Copilot Readiness" -OutputPath ./matrix.html

The cmdlet runs each tenant sequentially with progress updates:

Multi-tenant assessment: 'Copilot Readiness' across 10 tenant(s)

[1/10] Running 'Copilot Readiness' against Contoso...
  Still running... 10s elapsed
  Completed in 14s.
[2/10] Running 'Copilot Readiness' against Fabrikam...
  Still running... 3m 10s elapsed
  Completed in 3m 16s.
...

All assessments complete. 10 tenant(s) processed in 16m 18s.
  Contoso - 76.2% (16/21)
  Fabrikam - 42.9% (9/21)
  Woodgrove - 38.1% (8/21)
  ...

The matrix HTML report is a full-viewport interactive dashboard: a sticky left column with check names that stays visible while you scroll horizontally across tenant columns, each showing a pass/fail indicator. A tenant filter dropdown lets you show or hide specific tenants (useful when you have 100+ tenants and want to focus on a subset). Click “Details” on any check to open a slide-out panel with the description, impact, and rationale. Category rows group checks by Entra, Exchange, M365, Purview, and SharePoint. Search and status filters (All, Has Failures, All Passed) work across the entire matrix.

Assessment Export Options

All export formats work for both single-tenant and multi-tenant:

# HTML report (single or matrix)
Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness" -OutputPath ./report.html

# CSV for Excel or automation (multi-tenant includes Tenant column)
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant -OutputPath ./matrix.csv

# JSON for webhooks, APIs, or further processing
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant -OutputType JsonObject

# Pipeline for PowerShell automation (each check has TenantName in multi-tenant mode)
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant |
    Where-Object Status -eq 'Fail' |
    Group-Object TenantName |
    Select-Object Name, Count

Tenant Documentation

Export-InforcerTenantDocumentation generates comprehensive documentation for an entire tenant in one command:

# Generate HTML documentation (opens in browser automatically)
Export-InforcerTenantDocumentation -TenantId "Contoso" -Format Html

# Generate HTML and Excel, with Graph enrichment for group/filter names
Connect-Inforcer -ApiKey "your-api-key" -Region uk -FetchGraphData
Export-InforcerTenantDocumentation -TenantId "Contoso" -Format Html,Excel -OutputPath C:\Reports

# Export only policies from a specific baseline
Export-InforcerTenantDocumentation -TenantId 139 -Baseline "Inforcer Blueprint Baseline - Tier 1" -Format Html

# Filter by tag
Export-InforcerTenantDocumentation -TenantId "Contoso" -Tag "Production" -Format Markdown

HTML output is a self-contained file with no external dependencies - you can email it, archive it, or open it offline. It includes:

• Collapsible Product > Category > Policy navigation in a sidebar
• Real-time search with text highlighting
• Dark/light mode toggle (persisted in localStorage)
• Tag filter pills with AND/OR logic
• Hide empty fields and show metadata toggles
• Collapsible long values and a back-to-top button

Excel output creates a workbook with one sheet per product area. Each row is a policy with columns for category, name, description, platform, settings, and assignments - ready for filtering and analysis.

Markdown output generates a GFM-compatible document with a table of contents and per-policy tables - useful for including in wikis or version-controlled documentation.

Settings Catalog resolution: Both the documentation and comparison cmdlets translate raw Settings Catalog IDs into friendly names using data sourced from IntuneSettingsCatalogData. The dataset (~65 MB) is downloaded and cached automatically on first use at ~/.inforcercommunity/data/settings.json with a 24-hour refresh, so the first export is slower and every subsequent one is instant.

Environment Comparison

Compare-InforcerEnvironments compares two tenants’ Intune configurations and generates an interactive HTML report:

# Compare two tenants in the same Inforcer account
Compare-InforcerEnvironments -SourceTenantId "Contoso" -DestinationTenantId "Fabrikam"

# Compare across different Inforcer accounts with Graph enrichment
$src = Connect-Inforcer -ApiKey $key1 -Region uk -PassThru
$dst = Connect-Inforcer -ApiKey $key2 -Region eu -PassThru
Compare-InforcerEnvironments -SourceTenantId 482 -DestinationTenantId 139 `
    -SourceSession $src -DestinationSession $dst -FetchGraphData

You can also scope either side to a single baseline with -SourceBaselineId and -DestinationBaselineId, so the comparison covers only the policies in that baseline rather than the whole tenant:

# Compare only the policies in a baseline against a full tenant
Compare-InforcerEnvironments -SourceTenantId "Contoso" -SourceBaselineId "Tier 1 - Foundations" `
    -DestinationTenantId "Fabrikam"

# Compare one baseline against another
Compare-InforcerEnvironments -SourceTenantId "Contoso" -SourceBaselineId "Tier 1" `
    -DestinationTenantId "Fabrikam" -DestinationBaselineId "Tier 2"

When you pass a baseline ID without its matching tenant ID, the cmdlet resolves the baseline’s owner tenant automatically, so -SourceTenantId / -DestinationTenantId can be omitted on that side.

The HTML report includes four tabs:

• Comparison - flat table of all Settings Catalog settings with sortable columns, status filter pills (Matched/Conflicting/Source Only/Dest Only), category dropdown, and advanced column filters with AND/OR logic
• Manual Review - non-Settings-Catalog policies (compliance, enrollment, scripts) in a 50/50 source/destination layout grouped by platform. Matching policy names are aligned side-by-side. Scripts and compliance rules are shown as collapsible code blocks with syntax highlighting
• Duplicates - settings configured in two or more policies with different values, with automated conflict analysis
• Deprecated - settings flagged as deprecated by Microsoft, grouped by source and destination

Cross-category reconciliation: A setting delivered as Endpoint Security on one tenant and as a Settings Catalog policy on another would normally show up as two separate items - one “source only” and one “destination only”. The comparison matches by DefinitionId instead of policy category, so the same underlying setting lines up as a single row regardless of which Intune template type each tenant used to deploy it. This is what lets you compare a tenant on the older Endpoint Security flow against one that’s migrated to Settings Catalog without a wall of false-positive drift.

The report also features an animated configuration match score (with confetti at 100%), dark/light mode toggle, column resize handles, and a responsive layout. Like the Export report, the HTML is fully self-contained with no external dependencies.

Key Cmdlets and Use Cases

Typical workflows:

• Tenant and policy overview: Connect-Inforcer -> Get-InforcerTenant -> Get-InforcerTenantPolicies -TenantId "Contoso" to inspect a specific tenant’s policies.
• Alignment and drift: Get-InforcerAlignmentDetails for score summaries; Get-InforcerAlignmentDetails -BaselineId "Tier 0" for per-policy detail.
• User overview: Get-InforcerUser -TenantId "Contoso" for a user list; Get-InforcerUser -TenantId 139 -UserId "8e61ce11-..." for full detail including groups, roles, devices, and risk.
• Audit and compliance: Get-InforcerAuditEvent with optional -EventType (tab completion for event types), -DateFrom, -DateTo, and paging parameters.
• Tenant documentation: Export-InforcerTenantDocumentation -TenantId "Contoso" -Format Html,Excel to generate a complete configuration snapshot.
• Environment comparison: Compare-InforcerEnvironments -SourceTenantId "Contoso" -DestinationTenantId "Fabrikam" to see every difference between two tenants.
• Group and role lookup: Get-InforcerGroup -TenantId 139 -Search "Finance" for groups, Get-InforcerRole -TenantId 139 | Where-Object IsPrivileged -eq $true for privileged roles.
• Compliance assessment: Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness" to check a single tenant, or add -MultiTenant -OutputPath matrix.html for a cross-tenant matrix report.
• Reports: Get-InforcerReportType to see what’s available, then Invoke-InforcerReport -ReportType ActiveUserCount -OutputFormat csv -TenantId "Contoso" -Open to queue, download, and open it; pipe Get-InforcerReportType -Tag Security | Invoke-InforcerReport -OutputFormat csv -TenantId 482 to run a whole category at once.
• Pipeline: Get-InforcerTenant -TenantId 139 | Get-InforcerUser to list users for a piped tenant.

For full parameter details and example output, see the Cmdlet Reference in the repository.

Output Formats and Filtering

• -Format: Most Get-* cmdlets support Table or Raw (e.g. for alignment details).
• -OutputType: PowerShellObject (default) or JsonObject (JSON with depth 100) for piping into other tools or export.
• -TenantId: Accepts a numeric Client Tenant ID, a Microsoft Tenant ID (GUID), or a tenant name (case-insensitive match). Use it on Get-InforcerTenant, Get-InforcerTenantPolicies, Get-InforcerAlignmentDetails, Get-InforcerUser, and others.

# Example: export all tenants as JSON for use elsewhere
Get-InforcerTenant -OutputType JsonObject | Out-File tenants.json -Encoding utf8

# Example: search users by name
Get-InforcerUser -TenantId "Contoso" -Search "Adele"

# Example: get full user detail as JSON
Get-InforcerUser -TenantId 139 -UserId "8e61ce11-a45b-42a6-8ca4-1d881781566d" -OutputType JsonObject

How to Contribute

Contributions are welcome. The project uses a standard fork-and-pull-request workflow:

• Fork the repository on GitHub: https://github.com/royklo/InforcerCommunity.
• Clone your fork and create a branch (e.g. feature/your-feature-name or fix/bug-description).
• Make your changes under module/ (see CONTRIBUTING.md for code style and the consistency contract - parameter order, -Format/-OutputType, property names, etc.).
• Run tests from the repo root: Invoke-Pester ./Tests/Consistency.Tests.ps1.
• Commit and push to your fork, then open a pull request against the main repository. Fill in the PR template (summary, how to test, related issue if any).

New cmdlets must be added to module/Public/, registered in FunctionsToExport in the manifest, and documented in docs/CMDLET-REFERENCE.md. The consistency tests must be updated if you add or change exported cmdlets or key parameters.

How to Report Bugs

If something doesn’t work as expected:

• Go to New issue.
• Choose Bug report.
• Fill in:

Description: What went wrong?

• Steps to reproduce: Exact commands or steps.
• Expected behavior: What you expected.
• Actual behavior: What happened instead (including any error messages).
• Environment: PowerShell version, OS, and module version (e.g. Get-Module InforcerCommunity | Select-Object Version).
• Additional context: Logs, screenshots, or other details.

This helps maintainers and the community reproduce and fix issues quickly.

How to Request a Feature

Have an idea for a new cmdlet, parameter, or behaviour?

• Go to New issue.
• Choose Feature request.
• Describe:

The feature you’d like (e.g. a new endpoint, a new parameter, or a different output shape).

• The use case (why it would help you or others).
• If you have one, a proposed solution (e.g. cmdlet name, parameters, example usage).

Not every request can be implemented immediately, but all are read and considered; they also help others discover and discuss ideas.

Conclusion

InforcerCommunity turns the Inforcer API into a set of PowerShell cmdlets you can use interactively or in scripts: connect once, then list tenants, baselines, policies, alignment details, users, groups, roles, and audit events with consistent parameters and output. Generate Inforcer reports like Active User Count, Tenant Audit, and Copilot Adoption straight to disk with a single cmdlet that queues, polls, and downloads for you. Run compliance assessments like Copilot Readiness and CIS Benchmarks against one tenant or all of them at once, with interactive HTML matrix reports that let you compare compliance across your entire estate. Generate complete tenant documentation in HTML, Markdown, or Excel. Compare two tenants’ Intune configurations side-by-side with an interactive report that shows every difference, duplicate, and deprecated setting. Use tenant names instead of IDs, pipe results between cmdlets, and export to CSV or JSON for integration with other tools and automation pipelines. It’s a community project, not owned or maintained by Inforcer; feedback, bug reports, and feature requests from users like you shape what comes next. Install it from the PowerShell Gallery, try the quick start, and if you hit a bug or have an idea, open an issue or send a pull request.

Related

• InforcerCommunity MCP: Ask Your AI Assistant About Your Inforcer Tenants - the same API, reached from an AI assistant instead of the command line.
• The MSP License Ladder #1: The Hunting Gap - why MSPs need Defender for Endpoint Plan 2, with a multi-tenant hunting script.
• RKSolutions PowerShell Module - another PowerShell module for M365 reporting across Intune, Entra ID, and license management.