Skip to content

fix(deployed): cite the experiments that back the assignment and file-rule evidence #43

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
fadwen merged 1 commit into from
Oct 15, 2026
Merged

fix(deployed): cite the experiments that back the assignment and file-rule evidence #43

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,17 @@ release notes.

## [Unreleased]

### Fixed

- `Test-IntuneDeployedScript` cited ASSIGN-INEX, round 9's remediation included and excluded for
the same group, as evidence that a policy without an include never runs. That policy has an
include: the service drops the exclusion, and the device has run it every hour since 28 September
(180 probe records by 15 October, Graph run state updated 13 October, the policy unchanged since
its creation). The evidence names ASSIGN-NONE and ASSIGN-EXCLONLY only, and
`Validation/Findings.md` records the corrected result; the command's verdict on such a policy,
silence, was already right. Its file `doesNotExist` finding cited `W32-FILE-NOTEXIST-PRESENT`;
the experiment is `W32-FILE-NOTEXIST-FALSE`.

## [0.33.0] - 2026-10-15

Fixes to the CI pieces, found by running the gate script, the workflow template, the suite template
Expand Down
4 changes: 2 additions & 2 deletions Public/Test-IntuneDeployedScript.ps1
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,7 +221,7 @@ function Test-IntuneDeployedScript {
Message = "${what}: no device resolves the policy, so it never runs anywhere"
Evidence = 'A remediation with no assignment and one with only an exclusion were absent ' +
'from every device''s resolved policies after an agent restart, while the same scripts ' +
'with an include assignment ran (ASSIGN-NONE, ASSIGN-EXCLONLY, ASSIGN-INEX)'
'with an include assignment ran (ASSIGN-NONE, ASSIGN-EXCLONLY)'

@fadwen fadwen Oct 15, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the evidence changes. The condition above fires on a policy with no include, and the include-plus-exclude policy has one (the service keeps only the include), so the command never warned about it; the device evidence now says that silence was the right verdict. No test asserted the evidence text, which is why this went unnoticed since round 9.

}
ConvertTo-PolicyFinding @noneSplat
}
Expand Down Expand Up @@ -353,7 +353,7 @@ function Test-IntuneDeployedScript {
Evidence = 'File doesNotExist: on a missing file the app was not detected ' +
'and the install ran; on a present file the detection ended "Invalid ' +
'detection rule or unable to parse detection rule" 0x87D30004 ' +
'(W32-FILE-NOTEXIST, W32-FILE-NOTEXIST-PRESENT)'
'(W32-FILE-NOTEXIST, W32-FILE-NOTEXIST-FALSE)'
}
ConvertTo-PolicyFinding @ruleSplat
}
Expand Down
8 changes: 5 additions & 3 deletions Validation/Findings.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -502,16 +502,18 @@ clock runs seven hours behind UTC) and VM 126 (Entra joined by Autopilot, in ISL
|---|---|---|---|
| No assignment | A policy must be assigned to apply (portal) | **Never resolved**: absent from both devices' `ProcessResolvedPolicies` lists and logs; no run, no probe record (ASSIGN-NONE) | ✅ |
| Only an exclusion | Not documented | The same: never resolved on either device (ASSIGN-EXCLONLY) | ⚠️ |
| Include and exclude of the same group | Exclusion wins over inclusion (Intune assignment docs) | **Graph shows only the include**: `POST /assign` with both accepted, `GET /assignments` returns one `groupAssignmentTarget`. VM 125 resolved the policy and inspected its schedule (`inspect hourly schedule for policy <INEX>`, queued with the others) but **the runner never executed it**: the 25 other resolved remediations ran in the following cycle, this one did not in 55 minutes, no probe record. The exclusion holds on the device while the API hides it, so there is nothing to detect after the fact (ASSIGN-INEX) | ⚠️ |
| Include and exclude of the same group | Exclusion wins over inclusion (Intune assignment docs) | **The exclusion is dropped and the policy runs.** `POST /assign` with both accepted, `GET /assignments` returns one `groupAssignmentTarget`, hourly. VM 125 resolved the policy at the restart and inspected its schedule, and the round's ten-minute read and a 55-minute watch saw no run, which this entry first recorded as the exclusion holding on the device. It did not hold: the device's probe file for the policy had 180 records by 2026-10-15 (120 detections, 60 remediations, all as SYSTEM), the first on the evening of 2026-09-28 and the last that morning, and Graph's `deviceRunStates` for it carry `lastStateUpdateDateTime` 2026-10-13. The policy was not changed after the round: `lastModifiedDateTime` equals `createdDateTime` and the audit log holds only its create and assign events. The service keeps the include, the device runs the policy every hour, and nothing of the exclusion survives for a tool to find (ASSIGN-INEX, corrected 2026-10-15) | ❌ |

@fadwen fadwen Oct 15, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marked with the cross rather than the warning sign because the documented behaviour, exclusion wins, is what does not hold: the exclusion is not stored at all. The row keeps the round 9 observation and says what it was misread as, since the tenant audit write-up and the earlier Findings text both relied on it.

| Run-once schedule in the past | `deviceHealthScriptRunOnceSchedule` date, time (GRAPH-HS) | A device fetching the policy two hours after the time **ran it once at the fetch**: resolved 16:57:55, `will try to execute now` 17:03:24, detection, remediation, detection, and no second run (ASSIGN-PAST2 on VM 126). VM 125 inspected the same shape of schedule as a future time on its slow clock (ASSIGN-PAST): a device clock decides | ⚠️ |
| SYSTEM remediation assigned to a user group | User-targeted policies apply where the user signs in (portal) | Resolved and run on VM 126 under the signed-in member's id (`"UserId":"c3b8cf61..."`, ran 17:02:55, 5 minutes after the fetch, as SYSTEM); never resolved on VM 125, where no member is signed in (ASSIGN-USERGRP) | ✅ |
| Fetch to first run | Not documented | Fetch at the agent start (16:57:55), first run 17:02:55, five minutes later, as in round 1 | ✅ |

**For the tool:** `Test-IntuneDeployedScript` warns about a policy with no assignment or only
exclusions (`IslAssignmentIssue`), notes a run-once schedule whose time has passed
(`IslScheduleIssue`, Information) and a user-context script assigned to a device group (skipped on
Entra registered devices, round 1). An include and an exclude of the same group cannot be seen
after the fact, so it is documented only.
Entra registered devices, round 1). An include and an exclude of the same group leaves only the
include in Graph and the policy runs on every device in the group, so there is nothing for the
command to detect; `IslAssignmentIssue` stays silent on it, which is the right verdict for a policy
that runs. Its evidence string cites ASSIGN-NONE and ASSIGN-EXCLONLY only.

## PowerShell 7 at run time, a built credential, and the drives SYSTEM sees

Expand Down
Loading