TUNO — Intune Operations Tools

R01 🔐 AppLocker builder & validator live · build 3

Web-based AppLocker policy analysis after Spencer Alessi's AppLockerInspector: import the XML, get the weak/misconfigured/risky settings with severity, reason and recommendation — plus the check the PowerShell original does not have: a Microsoft app coverage table that verifies OneDrive (per-user!), Teams, Edge, WebView2, Office click-to-run, the Intune agent and friends are actually allowed to run for a standard user, with one-click publisher-first fixes and XML export back into the GPO.

R04 🔗 Group Analyzer live · build 4

Name an Entra group, get everything Intune sends to its members across nine surfaces and twenty Graph endpoints. The machinery is ENCA's T19 — source descriptors with their own scopes and runners, a flat hit shape, a failing source reported and never fatal, and ancestors rather than just the group itself. The Intune surface map and two behaviours come from Get Group Assignments (Ugur Koc). Exclusions are read as assignments: “this policy does not reach you” is the same question as “this policy reaches you”, and a report showing only inclusions is wrong half the time. Tenant-wide targets are a toggle — All Users and All Devices land on the group's members too, so the effective surface is larger than the group's own assignments; off by default because it is the same answer for every group, on the list because nothing else would say so. And the thing neither parent has, which the script's own notes call out as not evaluated: nested group inheritance, so an assignment reaching this group through a parent is included and names the parent it came through. A surface that could not be read is never shown as empty — it is shown as unknown, with the scope and the Intune RBAC role it would need.

The tenant sweep (beta 10319) asks the same question of every group at once. A sweep reads each surface once and matches every group against it, so three hundred groups is still twenty reads. The default scope takes the ids off the assignments themselves and enumerates nothing — the fastest scope, and the one that cannot find unused groups, which the screen says where the choice is made rather than leaving an empty list to read as a clean bill of health. The counted scopes enumerate and can. Dangling references — an assignment naming a group the directory no longer has — are kept and flagged, because nothing in the portal will tell you.

Shipped Intune-only, and that is a change from what this card used to promise. It said the Entra areas would stay as context. They cannot: Conditional Access, group-based licensing, directory roles and access packages need scopes TUNO's registration does not hold and has no reason to. Half-reading them with the permissions to hand would be worse than not reading them, so the tool says so and points at ENCA, which is signed in for exactly that.

R05 🕓 Change audit live · build 4

One tool over deviceManagement/auditEvents, two views, one read — after Ugur Koc's Policy Changes Monitor and Get Intune Audit Logs. Policy changes carries a severity read off the activity; all events filters by actor, activity, category and result with wildcards honoured as wildcards. The field-level diff is ENCA's T16, ported, and it is the reason to use this rather than the portal: modifiedProperties values arrive as JSON strings, sometimes double-encoded, sometimes wrapped in a one-element array, and the useful answer is a list of what moved — with assignment lists compared as sets, so you see added and removed rather than two blobs.

Three upstream bugs fixed. The two scripts window the same endpoint two different ways and a bare date means midnight, so “the last day” was anything between a minute and 24 hours — full ISO-8601 UTC in both. The fixed category list contains values Graph never emits, so choosing one returned nothing and read as a quiet tenant — the categories come from the tenant's own data. And the policy view is not capped at five rows after paging everything, which is what the original does. A fourth, smaller one: every resource on a record is inspected rather than only the first, because an assignment change puts the policy in slot 0 and the group in slot 1.

The windows stop at 30 days, and that is the honest limit rather than a shortcut. Intune keeps audit data for thirty days and then it is gone from the service. ENCA offers a ninety-day review window because the directory audit log holds longer; the same option here would return an empty answer for days thirty-one to ninety that looks exactly like a quiet tenant.

R08 📦 Backup Intune configuration live · build 5

After Ugur Koc's Backup Intune Configuration. Five areas over ten Graph endpoints, written to one .zip in the browser. The folder layout and file names are his, exactly — restore is driven by folder names in both his script and R09, so an archive written here restores with his and one written by his reads back here. Reads only, one scope. Three of the five areas cost an extra request per object because the list endpoint returns a count or a null where the content should be; those run several at a time rather than in series with a sleep, which is what the original does.

An object whose detail could not be read is left OUT of the archive, not written without it. A settings-catalog policy restored with the right name and no settings is worse than one that is visibly missing, because the first looks like it worked. An area that could not be read at all marks the whole archive partial, in the manifest and on screen.

The manifest says what the archive cannot do. It keeps the original's four fields so the shape stays familiar and adds an index of every file with its type, surface and whether it is restorable, plus the tenant it came from — six months later the question is “is this the right tenant”. Two limits are stated up front rather than found at restore: Graph never returns secret values, so encrypted OMA-URI settings, passwords and certificates are references that must be re-entered by hand; and a script saved without its body cannot be put back, which the original's own switch produces silently.

Five areas is a floor, not a ceiling, and an archive nobody can verify is a file you hope is a backup — R15 shipped in beta 10426: twenty-four areas, a SHA-256 per file with an offline verify, and assignments that export and import — R16 compares two of them without a tenant.

R06 📄 Configuration documenter live · build 5

Thirteen configuration surfaces read once, then browsed and written down — two views over one read, because you browse what you are about to document. The list is the Tuesday tool: every policy in the tenant, filterable by name, setting, platform and whether it is assigned to anything, with the settings expandable underneath and assignments resolved to group names. The document is what an auditor asks for. Markdown for a wiki, a standalone HTML page that prints cleanly, and a Word document with real Word tables rather than a run of paragraphs somebody has to reformat. The filters apply to the exports, and every export header states how many of how many objects it holds — a narrowed document cannot be mistaken for a complete one.

Redaction is not a setting. This is the most widely circulated artefact TUNO produces — auditors, wikis, shared drives — and a script body, a certificate, a pre-shared key or an encrypted OMA-URI value in one of those is a disclosure that cannot be recalled. Every such field is replaced with a marker recording that a value is set without carrying it, and there is deliberately no switch to turn it off.

Reimplemented, not forked — the original is Elastic 2.0, which permits self-hosting but not offering the work as a service, so this is built from its published coverage list and shares none of its code. And unlike a backup, a policy whose settings could not be read is still listed, with the gap stated: a document that admits what it does not know is more useful than one missing the object entirely. PDF next

R03 🖥 Intune device analyzer live · build 5

R04 read from the other end. Name a device — by name, serial, or either of the two GUIDs every machine has — and the same assignment graph is walked backwards: the groups the device itself is in, the groups its primary user is in, and the tenant-wide targets that name no group at all. Every row says which of those put the policy there. The endpoint list is not a second copy: T06 builds a match set and hands it to the Group Analyzer's own source table, because the first time somebody added a surface to one and not the other, this tool would have started reporting a device as unaffected by a workload it never looked at.

Tenant-wide targets are ON here, and that is the difference from R04 rather than a preference. For a group, All Devices is the same answer every time and says nothing about the group you asked about. For a device it is the answer — All Devices reaches this machine whatever else is true — so leaving those rows out would produce a report missing policy the device is definitely getting. All Users lands on the person, so on a device with no primary user it reaches nothing, and the row says that rather than being quietly dropped.

Intended and actual are two columns, and the gap between them is the point. Everything read from an assignment is what Intune intends; what the machine has is whatever it collected at its last check-in, so the check-in time is the first thing on the page and the report states plainly that a policy assigned minutes ago has not applied. Where deviceConfigurationStates and deviceCompliancePolicyStates answer, the device's own verdict sits beside the assignment. Where they 403, come back empty, or cannot be matched to a policy with certainty — two policies sharing a name is enough — the state is unknown. Never “fine” by omission.

A filtered assignment is an open question and is shown as one. The filter rule is evaluated by the service against inventory a browser cannot see, and there is no Graph call that answers “would this filter include this device”. Those rows say may reach it and name the filter; they never say yes. Reads DeviceManagementManagedDevices.Read.All and R04's scopes, plus one new one: Device.Read.All, because the Entra device object is not the Intune enrolment record and only the directory can say which groups a machine is in.

R07 🛡 Intune role assignments live · build 5

After Ugur Koc's Get Intune Role Assignments (MIT), whose question this is. Every role definition, built-in and custom, each assignment under it, the users and groups in it resolved to names, its scope tags and what it is scoped over — one page instead of one portal blade per role, which is why nobody audits this. Names are resolved in one call rather than two per member: the original probes /users/{id} and then /groups/{id} for each principal, and directoryObjects/getByIds answers a thousand at once and says what type each object is, so there is nothing to probe.

Two things the original does not read, both of which change the answer. Scope tags, which are how a tenant gives a regional helpdesk a role over only its own devices — a report that omits them overstates every scoped assignment. And the scope itself: scopeType and resourceScopes are read together, so “all devices” and “Graph did not say” are different answers here. The original falls back to the literal string “All” when resourceScopes is empty, which is right often enough to be dangerous.

Empty roles are a toggle, not a hidden row. A role with nobody in it is one membership change from being a live grant. The toggle re-renders what has already been read and asks the tenant nothing.

Concentrations are OBSERVATIONS and there is deliberately no score. An assignment scoped to all devices; a broad built-in role with a lot of members, at a threshold that is stated on the screen because it is arbitrary; a role whose members are all one group, where whoever can change that group's membership can grant the role without holding it. Whether any of those is wrong depends on things this tool cannot see, and a number would invite somebody to chase it rather than read it.

And the sentence neither the script nor the portal says, which is on the screen and in all three exports: this is Intune RBAC only. Global Administrator and Intune Administrator are Entra directory roles, they grant full access to Intune, and they do not appear in deviceManagement/roleAssignments at all. An access review that takes this for the whole list is missing the accounts with the most access.

R13 ✏️ Assignment editor live · build 8 writes to the tenant

After Intune Toolkit by Maxime Guillemin (MIT) — a WPF application that does the thing every admin wants and the portal makes slow: add and remove assignments in bulk, across settings catalog, device configuration, compliance, administrative templates, endpoint security intents, Autopilot, app configuration, every application type and every script type. With filters and install intent. Plus backup and restore of the assignments themselves, which is a smaller and more useful thing than R08's full configuration archive: you can put assignments back without touching the policies.

This would be the second thing in TUNO that writes, and the first that writes at scale. T01 creates one profile after a read that refuses to overwrite. This changes what lands on real devices, in bulk, and the mistake it enables is not a duplicate policy but a policy reaching the wrong population — which is invisible until somebody's laptop behaves differently. It gets T01's rules and more: ReadWrite asked on the click and never at sign-in, a dry run listing every operation with the group NAME and its member count before anything is sent, removals confirmed separately from additions, and the assignment state captured to a file first so there is always a way back.

Two of its features are deliberately not on this card. It can hard-delete policies and rename them; both are behind its own “Advanced Actions” toggle and neither belongs in a browser tool whose whole argument is that it cannot do much harm. If TUNO ever deletes a policy it will be its own decision, not one inherited.

Shipped narrower than the card promised, on purpose. Four surfaces — device configurations, settings catalog, compliance, administrative templates — because they are the ones under the write permission the registration already holds. Scripts, applications, app configuration and endpoint security intents each need a write scope TUNO does not carry, and adding one is a decision to take in the open (the R18 rule), not a feature's side effect. The promised rules all arrived, plus two the card did not name: every write is preceded by a fresh read, so a policy edited by somebody else between plan and apply is skipped as drifted rather than overwritten; and every write is followed by a read-back, so “done” is the tenant's word. Filters on untouched assignments survive the round trip — the assign call replaces the whole list, and dropping one would silently widen an assignment nobody meant to touch.

R21 🧩 Assignment filters live · build 8 writes to the tenant

Also after IntuneShade, and both halves shipped together. The read half: every filter with its platform and rule, and per-filter usage — which assignments on which policies reference it — read through R04's own source table, exactly as the card promised, so a surface added there is counted here. The usage scan is optional and the used-by column is absent, not zero, until it runs; a surface that could not be read makes every zero a floor, and the screen says so.

The writes carry R13's rules, sized for one object: the write scope at the click, an edit preceded by a fresh read and refused as drifted if the filter changed since it was loaded, every write verified by read-back, delete confirmed by typing the name. And the rule the card was written for: delete is refused while usage is non-zero — checked against the tenant's own payload associations at the moment of the act, not against the session's cached scan, and “could not check” refuses too, because a filter deleted while in use silently widens every assignment that carried it. This is the first PATCH and the first DELETE in the application; both arrived in the Graph layer with the same no-retry rule writes have always had.

R09 📥 Restore Intune configuration live · build 8 writes to the tenant

After Ugur Koc's Restore Intune Configuration, living inside the 📦 backup tool — the file you load is the file the other half wrote, and the original script's archives load too, because the folder layout is shared. Pick a single policy, a selection, or everything; dry-run; apply. The dry run lists every operation, including the ADMX definition-value child writes the original's -WhatIf never shows, and every create is verified by read-back: “created” is the tenant's word.

TenuVault's two rules shipped exactly (Ugur Koc, MIT): create only — nothing of yours is patched or deleted, the single exception being an administrative template this restore half-created and failed to finish, which is rolled back as its own mess; and every object gets a name prefix, [Restored] by default, editable per row. The collision stop sits on top: a name that exists in the tenant skips that object, checked at dry run and re-checked fresh immediately before each create.

Two departures from this card's first draft, both deliberate. The card offered “overwrite, skip or rename” at a collision — overwrite is not offered: it is a patch wearing a restore's clothes, and create-only is the stronger rule; rename is the editable name column, skip is the default. And assignments are not restored at all rather than off-by-default: a source-tenant group GUID either does not exist in the target or, worse, names a different group — every object arrives unassigned and the result says so per row, which is also this card's promised TenuVault principle (nothing arrives already reaching people) applied the simplest way. Scripts saved without bodies cannot be selected and say why; secrets arrive as references to re-enter, as the backup's manifest always warned. Scopes at the apply click: the config write for four areas, the scripts write for platform scripts — both already declared.

R28 📋 Compliance coverage — the platforms nothing evaluates live · build 9

After Ugur Koc's Get Compliance Policy Coverage (MIT). The gap the compliance report itself cannot show, because every number it has comes from policies that exist: a platform with enrolled devices and no assigned compliance policy. Those devices are not failing anything — there is nothing to fail — and depending on one tenant setting they report compliant by default and sail through every Conditional Access check that requires a compliant device. The device count per platform is the priority order, and unassigned compliance policies are listed beside the gaps they would close.

Not a new tile — a section in the 📋 Compliance report, and that is the point. The script's two reads are exactly the two T13 already does: compliance policies with assignments, devices with their operating system. The R19 rule applies — a second question over one read asks the tenant nothing new — so this ships inside T13 with zero new Graph traffic and no new scope. Platform identity is the script's own mapping, kept: a compliance policy's OData type names its platform 1:1, and device operating systems normalise to T05's one vocabulary rather than three spellings of Windows. "Covered" is narrowed the R26 way: a policy whose only assignments are exclusions, or none, covers nothing by construction — group scoping within a platform stays unevaluated, said on screen.

And the sentence the original leaves as a footnote becomes a read. Its notes say "check the tenant's Mark devices with no compliance policy assigned as setting" — because that setting decides whether an uncovered platform is a nuisance or a hole: compliant-by-default means uncovered devices pass Conditional Access silently. TUNO reads the setting (deviceManagement/settings, on the config read it already holds) and states which way the tenant leans next to every gap; a setting that could not be read is said, with the portal path, rather than guessed.

Shipped as carded, one refinement found in the building: a platform is three answers, not two. Devices and no covering policy is the gap; devices and a covering policy is covered — with a filter capping the claim at may, worn on the verdict; and a platform whose policies exist but whose devices do not is context, not a gap, listed so an unassigned macOS policy in a Windows-only tenant does not read as a hole. When either half of the read fails, coverage says unknown, not uncovered — a gap table computed from half a read would be the confident overstatement the section exists to prevent.

R29 🔑 Windows LAPS audit live · build 9

After Ugur Koc's Get Windows LAPS Audit (MIT). Windows LAPS escrows each machine's local administrator password into Entra; this reads the escrow metadata — which devices have a backed-up password and how old it is — and cross-references every Intune Windows device: not escrowed and stale beyond the rotation threshold are the two shapes of the same finding, a LAPS policy that is not applying, found before the day somebody needs the password that is not there.

This is the first new permission since the Device analyzer, and it goes on in the open — the R18 rule. DeviceLocalCredential.ReadBasic.All, and ReadBasic deliberately: Graph cannot return a password value through it, only device name and backup time. The full Read.All, which does return passwords, is what R10's helpdesk viewer would need and is deliberately not asked for here — auditing that escrow works and reading a password are different acts, and the smaller one should not carry the larger one's scope. The registration script and SECURITY.md take the scope in the same build; every customer tenant pays one more admin-consent round trip, said here rather than discovered. And a second gate the consent cannot open: Graph answers this endpoint only for accounts holding specific directory roles — Intune Administrator among them — so a signed-in reader without one gets a refusal, and the screen says why before the run rather than printing a bare 403.

Two honesty rules past the original. A device whose enrolment record carries no Entra device id cannot be matched to the escrow store — the original counts it not escrowed, which accuses a machine it never looked up; here it is unmatchable, unknown, its own bucket. And escrow records matching no enrolled Windows device — retired machines whose passwords are still held — are listed as their own answer rather than silently ignored, because credential metadata that outlives the machine is worth a look. Reads only; passwords are never retrieved, and there is no switch that would.

Shipped as carded, one addition found in the building: escrowed-with-no-timestamp is its own bucket. A record whose backup time cannot be parsed is neither healthy nor stale — calling it either would be a guess, so it reads age unknown, counted and listed. The role-gate refusal is detected and named on screen — "this is about who you are, not what TUNO may do" — and the stale threshold is yours (default 60 days, the original's).

R15 📦 Backup, widened and checkable live · build 9

After Ugur Koc's TenuVault TUI (MIT), which backs up twenty-seven policy types where R08 covers five. The missing twenty-two are not obscure: security-baseline intents, Autopilot profiles, enrolment configurations, feature, quality and driver update profiles, macOS custom-attribute scripts, assignment filters, scope tags, device categories, terms and conditions, notification templates, app configuration for devices and for managed apps, app protection for iOS, Android and Windows, Windows Information Protection, and app categories. Most of them TUNO already reads somewhere — R06 documents thirteen surfaces — so the gap is the archive, not the plumbing.

And an archive you can check. TenuVault writes a SHA-256 per policy file and a verify that reports modified, missing and untracked files — entirely offline, no tenant. An archive nobody can verify is a file you hope is a backup. Its atomicity trick is worth copying exactly: metadata.json is written LAST, so its presence is what marks a backup complete, and a folder without one is hidden rather than offered. TUNO builds its zip in memory and hands it to the browser in one act, so a half-written archive is less likely — but "less likely" is not "cannot", and a manifest that only exists when the run finished is a better guarantee than a promise.

Assignments captured optionally with a groups.json beside them, read-only and for auditing rather than restore — group ids are tenant-specific and copying them across tenants is meaningless, which TenuVault says plainly and R09 already agrees with.

Shipped inside 📦 Backup configuration (R08's tool, T04, v0.3) — one screen, not a second tool. Nineteen new export areas joined the interop five; the five keep the PowerShell original's folder names exactly, the new folders are TUNO's own, because TenuVault is a Go binary with its own layout and claiming byte-interop with it would be a claim nothing verifies — what is TenuVault's here is the coverage, the checksum per file and the manifest-written-last rule, credited. Every file carries a SHA-256 in the manifest; verify runs offline in the tab — modified, missing and untracked named, no manifest called what it is, an older archive called unverifiable rather than quietly passed.

And one departure from this card, decided by Mihai: assignments are exportable AND IMPORTABLE. The card said assignments.json would be read-only for auditing. It is now also a restore path — same tenant only (the archive carries the tenant's id and a mismatch is refused outright, no override; cross-tenant is R17's problem, deliberately unbuilt), the four surfaces under the held write scope, targeting the same policy ids never a namesake, all-or-nothing per policy when a group in the archived list has since been deleted — writing the list without it would change its meaning, and a dropped exclusion widens. The write runs through the assignment editor's own machinery: dry run, drift skip, read-back verify. groups.json stays what it was — names resolved at backup time, for the audit question the directory can no longer answer.

R11 🔮 Assignment what-if live · build 9

After Ugur Koc's Intune Assignment Checker (MIT). Before you add somebody to a group, what will they receive — and if you take them out, what will they lose? Pick a user or a device, name a group, and get the delta against what they have today: policies gained, policies lost, applications that will install, applications that will be uninstalled. Then the comparison the portal cannot do at all: put two or more groups side by side and see what each receives that the other does not.

This is the one capability of his suite that TUNO has nothing like. The reading half is already here — R04 answers “what does this group receive”, R03 answers “why did this device get that”, and both already show exclusions, inheritance and filters. What neither answers is what would happen if, and that is the question asked at the moment a change is still cheap to reverse. It also brings the third subject: TUNO can start from a group or a device, not yet from a person.

It reads only, and it is a simulation rather than a promise. Group membership rules, assignment filters and per-device applicability all sit between an assignment and a device, and a browser can evaluate none of them with certainty — so the answer will say which parts are computed and which are inferred, the same way R03 already refuses to claim a filtered assignment applies.

Shipped as promised, with the mechanics stated rather than implied. Joins carry the group's own parents; leaves rebuild the closure from the remaining direct memberships, so a policy still reachable through a second group is not reported lost; a membership held only through nesting says so instead of simulating a removal the portal does not offer. The delta's third state is the reason to run it: joining a group can take policy away, and an uninstall intent that starts to apply reads "will be uninstalled" rather than "gained". Person-subject support arrived with it — the third subject the card asked for.

R12 🩺 Assignment health live · build 9

Also after Intune Assignment Checker. The assignments that exist and reach nobody, in one place. Empty groups — a policy assigned to a group with no members is configuration that has never applied and never will, and nothing in the portal surfaces it. Failed assignments — deployments Graph reports as failed rather than pending. Unassigned policies, which R06 can already filter for but does not treat as a finding. Each is the same shape of problem: something that looks configured and is not.

Distinct from what R04's sweep already finds. That reports dangling references — an assignment naming a group the directory no longer has. An empty group still exists; it simply has nobody in it, which is a different fault with the same symptom.

Shipped with three findings the card did not promise: excluded-only policies (every assignment an exclusion — nothing to carve from), one group included and excluded on the same policy (the exclusion wins; the include reads as reach), and deleted-group references listed per assignment. Deployment failures are read where Graph keeps a cheap per-policy status, and the surfaces that keep theirs behind the reports API are named as unchecked rather than passed off as healthy. Enrolment defaults are exempt from the unassigned finding — unassigned is their normal state.

R14 🔦 Settings search live · build 9

The last piece of Intune Assignment Checker worth having: search across setting definitions rather than policy names. “Which policies configure BitLocker, and to what value?” — answered against the settings-catalog definition catalog, roughly seventeen thousand definitions, with the abbreviations and near-misses an admin actually types. R06 searches the settings of the policies it has already read, which finds a setting only if you already know which policy holds it; this searches the other way round.

A separate card because it needs a separate thing: the definition catalog itself, which is large, changes as Microsoft ships settings, and has to be fetched and cached rather than derived from the tenant. That is a different problem from reading assignments and it should not be smuggled into a tool that does not have it.

Shipped, with one departure from this card's own caution. The card said the catalog "has to be fetched and cached rather than derived from the tenant" — it is fetched per session and held in memory, not persisted: seventeen thousand definitions store fine in a tab and go stale on disk. Tenant usage is a second, separate read, and until it runs the "set by" column is absent, not empty. Values pass the documenter's redaction gate — the same implementation, because a second copy would be a second place for a pre-shared key to escape.

R19 🧮 Assignment matrix live · build 9

After IntuneShade by Alper Atar (MIT), whose single best screen this is: every group down the side, every policy surface across the top, one grid instead of one portal blade per policy. TUNO had already paid for the data — R04's tenant sweep reads each surface once and matches every group against it — so this shipped as a second view over the sweep's one read: a Table/Matrix switch that re-renders what was read and asks the tenant nothing, and a group click that lands in single-group mode through the tile's own pipeline.

A cell is a claim, and the grid does not overstate it. Includes are the count; exclusions are their own red −n, counted per surface and never folded in, because “this policy does not reach you” drawn as coverage is the exact overstatement a matrix invites. A dangling reference wears the sweep's own deleted flag instead of counting as coverage, and the sweep's scope caveat travels with the view.

The empty-group check is opt-in and absent-not-empty — one $top=1 membership probe per group, batched twenty a trip (R12's technique), behind a button that says what it costs. Until it runs, the grid says plainly that empty and populated look the same; after it, a group nothing can reach says empty, and a probe that failed says reach? — unknown, never passed off as either.

R20 ⚔️ Setting conflict scan live · build 9

Also after IntuneShade: the same setting configured to different values in two policies. R12 finds assignment-shaped contradictions; this finds value-shaped ones, and the read is the 📄 documenter's own collect() — same surfaces, same redaction, same failure honesty — because a second copy of thirteen-surface reading is how two tools start disagreeing about one tenant.

The step past the original arrived as promised: a collision is only a conflict if the two policies can meet on a device. Every finding carries a verdict from the assignments — can collide (a shared included group, or tenant-wide reach meeting anything), may collide, cannot collide. And “cannot” is narrower than the card first said, on purpose: it is claimed only where one policy reaches nobody by construction — no include, no tenant-wide target. “Disjoint populations” cannot be claimed from group ids, because two different groups can share members and a browser cannot see membership: different groups are may, an assignment filter caps any verdict at may (the filter id now rides along on the documenter's assignment rows for exactly this), and may means may — the R03 rule.

Identity is exact or it is not claimed — a departure from this card's own first draft. The card said R14's catalog would recognise a setting “across settings catalog, device configuration and ADMX”. It cannot: a legacy device configuration's typed property carries no definition id, and matching it to a catalog setting would be display-name matching wearing a canonical hat. Shipped instead: definition id within the settings catalog, definition-plus-category within ADMX, typed property within one policy type for device configurations — and a cross-surface collision on the same CSP is stated as not detected rather than half-detected. Redacted values are never compared: two secrets are not known to be equal, and a conflict row printing them would be a disclosure. Findings, not a score. Reads only, no new scope.

R22 📈 Compliance report live · build 9

Also after IntuneShade. The tenant's compliance story on one page: the estate rolled up — compliant, non-compliant, in grace, unknown — every policy with its verdicts, and which setting is failing where Graph keeps a per-setting summary, worst first. Stale is its own column, not a flavour of compliant: the threshold is on screen (default 30 days), and a compliant-but-stale device sits in both columns with the tension stated, because a verdict is as old as the check-in that produced it.

No new scope, as promised — the estate rides R03's device read, the policies ride the config read. The R12 honesty rule arrived with it: the numbers are Graph's cheap per-policy rollup, refreshed on Intune's schedule and labelled so; a policy whose statuses could not be read is listed with the gap stated, never absent; and per-device drill-down for one machine is named as R03's job rather than half-done here. Exports Markdown, CSV, and a stale-devices CSV. HTML export next

R24 ⚙ Self-host branding live · build 9

ENCA's mechanism, ported whole: the ⚙ gear next to Sign out, on any non-production host — product and organisation names, logos, login text and light/dark identity colours, through the same override mechanism as the hosted per-audience looks. Chrome only; exports keep the neutral product credit. Apply keeps the look in this browser; Download produces selfhost-branding.json, Import reads one back into the form for review — and serving that file next to index.html gives every visitor the branding and softens the red BETA ribbon to a neutral SELF-HOSTED one, because a deliberately configured instance is not a test site. What the gear will never configure is the canonical host: that drives the production check and the export credit, and a settings dialog must not be able to make a copy claim to be production.

R25 🦠 Defender status report live · build 9

After Ugur Koc's Get Defender Status Report (MIT), whose question is the one that becomes an incident ticket later: on which machines is Defender silently off or outdated? The tenant's own protection rollup (deviceProtectionOverview) for immediate context, then every Windows device's windowsProtectionState — real-time protection, tamper protection, malware protection, signature currency, overdue quick and full scans, a pending reboot, a device state that is not clean — with each device carrying its list of findings rather than one traffic light, because "tamper protection off" and "signatures three weeks old" are different conversations. Reads only, and no new scope: both endpoints sit under the device read T06 already brought in. Both are beta surfaces — that is where Graph keeps protection state, and the card says so rather than leaving it to be found.

The per-device read is the whole cost, and the original pays it one device at a time — protection state fetched in series with a sleep between requests, which on a large tenant is minutes of a terminal doing nothing. Folded into $batch, twenty a trip, with progress on screen — the same technique R12 and R19 already use for exactly this shape of read.

A device that never reported protection state is its own bucket, never healthy by omission. The original lists these separately and that instinct is kept and sharpened: no state is a finding, not an absence — a machine Defender has never reported on is exactly the machine this report exists to find. And the tenant rollup and the per-device sums can disagree, because Graph refreshes the overview on its own schedule; both are shown, labelled as what they are, and never quietly reconciled.

Shipped as carded, with one distinction the card only implied. The original counts a protection flag the device did not report the same as one that is off; here not reported is its own answer, per flag, on the row and in both exports — accusing a machine of running without tamper protection when it simply did not say is the kind of overstatement audits repeat. A state that could not be read lands in the no-state bucket with its error stated, because unknown is not clean.

R26 🧱 Firewall & ASR coverage live · build 9

After Ugur Koc's Get Firewall and ASR Status (MIT). Whether the Windows fleet actually has firewall and attack-surface-reduction enforcement, or just policy objects: every endpoint security policy — settings catalog policies whose templateReference.templateFamily starts with endpointSecurity, plus the legacy security intents older tenants still carry — grouped into the portal's own disciplines (firewall, attack surface reduction, antivirus, disk encryption, EDR, account protection), each with a three-way verdict: covered, policies exist but none is assigned, or no policy at all. The template-family filter runs client-side because the server-side filter is unreliable on this surface — the script's own note, kept. The Windows device count is the denominator on purpose: a gap on firewall or ASR is not an empty table row, it is that many devices running on local defaults.

"Covered" is a claim, and this card narrows the original's. At least one assigned policy per discipline is what the script means by coverage, and per-device applicability is not evaluated — its own note, which belongs on the screen rather than in a comment. One step past it, for free: assignments arrive $expand-ed, so "assigned" is checked by construction the R20 way — a policy with no include and no tenant-wide target, or whose every assignment is an exclusion, reaches nobody and does not count as coverage. Whether an included group is empty is R12's finding, and the page points there rather than half-repeating it. Reads only, no new scope: the policy read rides the config scope, the device count rides T06's.

Shipped with one departure from the original that the card did not promise: legacy intents are classified, not dumped. The script lists deviceManagement/intents under a "Legacy Intent" pseudo-discipline, so a tenant enforcing firewall through an intent reads as a firewall gap — an overstatement in the dangerous direction. Here the intent's template is resolved (one read of deviceManagement/templates) and the intent counts toward its discipline; one that cannot be classified counts toward nothing and says so. The legacy surface only answers assigned-or-not — no assignment detail — and the row carries that caveat rather than pretending the reach was checked.

R27 🤝 Multi-admin approval live · build 9

After Ugur Koc's MAA Compliance Dashboard Report (MIT). Multi-admin approval is the Intune control where changing an app, a script, a settings catalog policy or a role — or running a device action — needs a second administrator to say yes, and nothing in the portal shows whether it is protecting anything. One page: every approval policy (operationApprovalPolicies) with what its type gates; the requests of a chosen window (operationApprovalRequests) — pending, approved, rejected, cancelled, and how long approval actually takes; and coverage per resource category computed the way MAA actually works: an approval policy gates an operation type tenant-wide, so one policy of type app protects every app, and a category with no policy has no gate at all — which is the finding.

The admins half carries R07's sentence, because the original needs it and does not say it. Its "admins without MAA approval rights" list is counted from deviceManagement/roleAssignments — Intune RBAC only — so Global Administrator and Intune Administrator, the accounts that can change the most, are not in it. Said on screen and in every export, verbatim from R07. Approvers are resolved from the approval policies' approver groups transitively, and names arrive through directoryObjects/getByIds — R07's one-call technique, not the original's two probes per member.

Fewer scopes than the original asks for. The script connects with six, Directory.Read.All among them; everything here rides scopes the registration already holds — the MAA surface and role assignments under the RBAC read, the app, script and configuration inventories under reads earlier tools brought in, group members under the group read. And "no MAA policies" is distinguished from "could not read": a tenant that has never configured multi-admin approval gets a page that says so plainly, with the uncovered categories reading as the finding they are rather than an error. Reads only.

Shipped with two findings the card did not promise. A policy whose approver groups hold no members is flagged as a gate nobody can open — every operation it gates will sit pending until someone is added, and the emptiness is checked transitively, not read off the group list. And approved requests whose timestamps cannot be parsed are counted outside the approval-time numbers with their count stated, because an average quietly missing its slowest members reads better than the truth.

R30 🗂 Policy overview live · build 12

The sister tool ENCA's list-policies view, Intune-side-out: every configured object as clickable cards, the thirteen surfaces on top as stat cards that double as filters — Option B of a two-option mockup round. The read is the 📄 documenter's own collect(), one implementation so two tools cannot disagree about one tenant, and a card click opens the documenter's own popout, extracted in the same build so the policy template exists once. Verdicts are the house claims: Assigned = reaching somebody by construction, excluded-only its own finding, a filter caps reach at may. A surface that could not be read is a named ⚠ card and deliberately not a filter. Reads only, no new permission, no exports — the document is the documenter's job, one click away.

R31 🧭 Endpoint security posture live · build 12

The portal's Endpoint security blade, mirrored — Option B of a two-option mockup round: a rail of the portal's own nodes, plus two the portal does not have (settings-catalog policies configuring Defender or Edge, found by their setting definition ids), and two analyses in the same rail. 🗣 The impact brief is the sister tool ENCA's T32 translated from sign-ins to devices: what people will notice, in end-user language, exportable as Markdown or Word. 🎓 Best practice wears ENCA's MSLearn check shape — severity, requirement, remediation, the learn.microsoft.com page per check — pointed at MDE and Edge, with not reaching as its own verdict when the right setting sits in a policy reaching nobody. The read is the 📄 documenter's collect() (which carries templateFamily since this build), disciplines split by 🧱 T16's own classifier, verdicts the house claims. Cross-checked against ShadowDeploy MDE's defId families — BUSL-licensed, so checked against, not ported; every check stands on its Learn page.

A third analysis arrived with R02 (beta 10500): 📊 Secure Score gaps. These checks read policy — what is configured and whether it reaches anybody. Microsoft Secure Score reads the estate — what devices actually report. They disagree constantly and the disagreement is the finding, which neither reading produces alone: a check that passes while Microsoft still withholds the points is almost never the policy, it is machines that never onboarded, a licence the control needs, or devices that have not reported since it was written. Four buckets — both agree, configured-but-unscored, Microsoft-only, this-tool-only — and every pair prints both names, so a wrong match is visible rather than load-bearing; a control that matches no check is listed under Microsoft's own title, so a miss can only under-correlate. It is a separate button because it costs SecurityEvents.Read.All, and the posture read itself still costs no new permission.

R32 🔎 Filter rules, counted live · build 12

Every tool here could say a filter narrows an assignment and none could say by how much — at most, may reach it, ⚑ filter — may. js/filterrules.js parses the documented rule grammar and evaluates it against the enrolled inventory, so 🧩 Assignment filters can say 312 of 9969. A count is offered only where the whole rule is understood — not best-effort with a confidence marker, because a wrong count renders exactly as confidently as a right one. A rule outside the grammar says not evaluated and names what stopped it: deviceOwnership because Personal/Corporate against personal/company would be a guessed translation, operatingSystemSKU because Graph does not return it, app.* because it is not about devices. The number is a reading of today; the service evaluates the rule at assignment time, against inventory that moves.

R02 📊 Secure Score visualizer live · build 12

The tenant's Microsoft Secure Score over Graph — security/secureScores and the control profiles — as the card promised: score over time, per-category breakdown with Microsoft's own comparison figures as ticks on each bar, what changed across the window, and the improvement actions that buy the most points for the least user pain. That last ordering is TUNO's, not Microsoft's, and says so wherever it renders: points still available weighted down by the userImpact and implementationCost Microsoft publishes, with a control declaring neither treated as moderate — calling an unstated impact low is how a quick win becomes Monday's incident. Markdown for the monthly report, CSV for the controls and the history. SecurityEvents.Read.All on the click, reads only.

Two things the card did not promise. Graph keeps about ninety days, so "what changed since last month" runs out at a quarter — the tool exports a versioned snapshot carrying the readings and the catalogue they were read under, and uploads them back, so the timeline reaches as far back as somebody kept files. Uploaded points are drawn as their own marks, a same-day clash resolves to the live reading and says how many it dropped, and a snapshot from a different tenant is refused by tenant id rather than merged with a caveat. And 🧭 T20 correlates against it: Secure Score reads the estate, the posture checks read policy, and a check that passes while Microsoft still holds the points is the finding neither tool could produce alone.

R33 🔄 Group migration live · build 12

The sister tool ENCA's ⑦ Migrate, Intune-side-out. A group is made role-assignable for one side effect: only Global Administrator or Privileged Role Administrator may change its members. A restricted management administrative unit does that job better — it lets you name who may manage the group — and drops the costs role-assignable carries: the 500-per-tenant cap, no dynamic membership, no nesting control. The two can never be combined, because a restricted unit blocks exactly the two roles a role-assignable group admits, so a group that is both is a group whose members nobody can edit.

The new group has a new object id, and the tool can only move half the references. isAssignableToRole is immutable, so this is a recreate rather than a patch. The four surfaces R13's assignment editor already writes are repointed with that tool's own engine — the fresh-read drift check and the verify read-back come along rather than being written a second time. Applications, scripts, app protection and configuration, enrolment restrictions, Autopilot and update rings are read and named, never moved: each would need a write scope this registration does not declare, and adding one is a decision taken in the open rather than a side effect of a feature.

And the sentence the tool says out loud rather than leaving to be discovered: everything outside Intune is invisible to it. Conditional Access, group-based licensing, Azure RBAC and app role assignments all address a group by object id. The original is renamed aside and never deleted — it keeps its members, stays role-assignable, and is the rollback until those have been checked.

R34 🛡 Restricted AUs live · build 12

The other half of R33. A restricted management administrative unit is the only place in Entra where membership can be put out of reach of every tenant-wide role — inside one, only a principal holding a role scoped to that unit may change the members, and Global Administrator and Privileged Role Administrator can manage the unit but not what is in it. R33 files migrated groups into these; this creates and manages them. List, create, rename, delete, members, scoped administrators.

Three of Entra's rules, not ours, shape the screen. The restricted flag is immutable, so there is no convert and the editor says so. A unit with no scoped administrator is a vault nobody can open — creating one without naming a keyholder is refused, and the field is prefilled with you, because whoever creates the unit is its administrator by default. And a role-assignable group inside a restricted unit is 🧊 frozen: it admits only GA/PRA, the unit blocks exactly those two, and nobody at all can change its members — R33 is the way out.

Ported from ENCA's T27 and deliberately narrower. ENCA's version is wound through its Conditional Access baseline — persona vaults named from CA numbers, a baseline checklist, a group-to-persona map, prefix scans over its own naming. None of that came across: it answers a question TUNO does not ask, and importing it would have meant a vocabulary this tool cannot honour.

R35 🍎 macOS baseline live · build 13 writes to the tenant

The sister tool ENCA's Baseline Policies machinery, Intune-side-out and pointed at macOS. The name is the identity: baseline policies start with MACOS, carry a permanent R26.xx release number and end with a version — matched by number, compared by version, corroborated by the rest of the name so a number clash is a finding, not a silent match. The catalog is the cloudfellows.dev reference export, authored there and only there (the cfdev convention): the baseline tenant exports the file — names, numbers, versions and raw policy bodies — and every other tenant identifies against it and can import what is missing, create-only through the Backup tool's restore pipeline, canonical names kept, everything arriving unassigned.

R36 🧹 Entra device cleanup live · build 13 writes to the tenant

Stale directory devices staged out in two deliberate steps — disable at 30 days of silence, delete at 90, and only what is already disabled. A device with no recorded sign-in is unknown, not stale, and gets no action offered. Every write is preceded by a fresh per-device read (a device that woke up or was re-enabled is refused, not overruled) and verified by read-back; deletes arm only after typing the word, because the BitLocker recovery keys go with the object. Carries the registration's first directory-device write scope, Device.ReadWrite.All, taken in the open — and Graph's own directory-role gate on device writes is named before the run. One Markdown report: the estate, the actions, and everything deliberately not done.