Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
8 changes: 8 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,14 @@ release notes.

## [Unreleased]

### Changed

- `Validation/Findings.md` records an enrollment of the Windows 11 Home ARM64 device: in 75 minutes
and 11 syncs the service never sent the Intune Management Extension, so the agent's behaviour on
ARM64 stays a host survey until a Pro or Enterprise ARM64 device is available. The LAPS
settings-catalog policy failed on every node with `0x86000011` on Home, as the CSP's edition list
says.

## [0.34.0] - 2026-10-15

A correction to the evidence behind one finding, found while writing up the validation lab. Round 9
Expand Down
23 changes: 22 additions & 1 deletion Validation/Findings.md
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,9 @@ IME log evidence (registered device): `IsDeviceWPJ()` throws from `NetGetAadJoin

Not from an Intune run: a read-only survey of the in-box PowerShell hosts on a Windows 11 ARM64
device (Snapdragon X, build 26200), to know what "32-bit" and "64-bit" mean there. The Intune
agent's own behaviour on ARM64 is still ⏳.
agent's own behaviour on ARM64 is still ⏳: the one ARM64 device available runs Windows 11 Home, and
an enrollment of it on 2026-10-16 (below) showed that the agent is never sent to a Home device, so
no agent run on ARM64 has been observed.

| Fact | `System32` host | `SysWOW64` host |
|---|---|---|
Expand All @@ -134,6 +136,25 @@ Consequences: everything the 32-bit rules say applies unchanged to the x86 host
"64-bit" host is native ARM64, so `PROCESSOR_ARCHITECTURE -eq 'AMD64'` is false there; there is
no x64 PowerShell to run at all.

### Windows 11 Home: the agent is never sent

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.

Filed under the ARM section rather than as a round of its own because the device was enrolled for the ARM question; the Home result is what stopped that question being answered, and a reader looking for ARM evidence should find out here why there is none yet. The 75-minute window is longer than every assignment-propagation figure the README records (2 to 8 minutes, Win32 by push in seconds), which is what makes eleven syncs with no EnterpriseDesktopAppManagement command a result rather than a wait.


2026-10-16, the same ARM64 device (Surface Pro 11, Windows 11 Home 25H2, build 26200.9711), Entra
registered and MDM enrolled through Settings > Access work or school with a licensed (E5) user at
03:51 UTC, added to a device group of its own at 03:55, and 27 existing experiments (15 remediations,
4 platform scripts, 8 Win32 apps) assigned to that group at 03:56. Read from the device's MDM
diagnostic log (`DeviceManagement-Enterprise-Diagnostics-Provider/Admin`), the agent's install
locations and the tenant's reports; nothing on the device was changed beyond the enrollment.

| Documented | Observed | |
|---|---|---|
| The Intune Management Extension applies to supported Windows versions "excluding Windows Home and Windows devices running in S mode"; Win32 apps need Enterprise, Pro or Education; remediations need a joined device on one of those editions | **The agent is never delivered.** The device synced 11 times in 75 minutes (03:51 to 04:54 UTC, 44 MDM events) and the service addressed only `DMClient`, `NodeCache`, `Policy/ConfigOperations/ADMXInstall` and, until the group exclusion took effect, `LAPS`. Not one `EnterpriseDesktopAppManagement` command, which is how the agent's MSI arrives; no agent folder, service, log or `IntuneManagementExtension` registry key. The 27 policies have no run state for the device and the Win32 apps' device install report has no row for it, applicable or not. Intune lists the device as `skuFamily = Home`, Entra registered, compliant, and the policy evaluation stops there | ✅ |
| LAPS CSP: Pro, Enterprise, Education and IoT Enterprise only | Every LAPS node the All-devices policy carried (`BackupDirectory`, `PasswordAgeDays`, `PasswordComplexity`, `PasswordLength`, `PostAuthenticationActions`, `PostAuthenticationResetDelay`) failed with `0x86000011` on each of the four syncs before the exclusion reached the device; nothing was applied | ✅ |

**For the tool:** nothing changes. A Home device never gets the agent, so no script, remediation

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.

Stated explicitly because it is the only Findings entry whose observed behaviour has no rule behind it: the module analyzes scripts for where the agent runs them, and a device the agent never reaches is outside that. Get-IslHostArchitecture is named so the reader knows the ARM64 code paths still rest on the host survey above, not on an agent run.

or Win32 app is ever run on it, and the rules describe what the agent does where it runs. The
ARM64 observations above therefore remain a host survey until a Pro or Enterprise ARM64 device is
enrolled; `Get-IslHostArchitecture` and the rules that read it stand on the survey.

## Win32 requirement scripts

Round 4: seventeen Win32 apps (`W32-REQ-*`) sharing the same package, each with a PowerShell
Expand Down
Loading