Repository navigation
docs(validation): record that the agent is never sent to a Windows 11 Home device #47
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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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 | | ||
| |---|---|---| | ||
|
|
@@ -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 | ||
|
|
||
| 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 | ||
|
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
|
||
There was a problem hiding this comment.
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.