Repository navigation
Conversation
26H2 ships as build 26300 (GA 2026-09-29) on the same servicing branch as 25H2, so it belongs in the supported build list.
Set-Content -Encoding UTF8 emits a BOM under Windows PowerShell 5.1, and AME then fails to load the playbook ('playbook.conf not found'). Write the staged file with UTF8Encoding(false) so local builds match CI output.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Declares Windows 11 26H2 (build 26300) support in
SupportedBuilds, and fixes local builds writing a UTF-8 BOM into the stagedplaybook.conf.Why 26300
26H2 reached GA on 2026-09-29 as build 26300. Like 25H2, it ships as an enablement package on the same servicing branch, so the platform is unchanged from 26200 and only the build number needs declaring. 26H1 (build 28000) is a separate branch and is deliberately not included here.
The BOM bug
local-build.ps1stages a modifiedplaybook.confwithSet-Content -Encoding UTF8. Under Windows PowerShell 5.1 that writes a UTF-8 BOM, and AME then refuses to load the resulting playbook:CI runs pwsh 7, which does not emit a BOM, so this only shows up on local Windows builds — exactly the builds made with
-Removals, i.e. every dev artifact. The staged file is now written withUTF8Encoding($false).Testing
-Removals:ProductCode=64kept, builds26100,26200,26300, XML parses, packagedplaybook.confstarts with3C 50 6C 61(no BOM).-Removals Verification:ProductCodestripped, builds26100,26200,26300, no BOM.-Removalsbuild had a BOM and AME rejected it; after the fix it loads.Not tested
No 26H2 machine was available, so the requirement checks (
UCPDDisabled,NoPendingUpdates) and the runtime behaviour of the tweaks on 26300 are unverified. This PR only makes the playbook accept the build; component/AppX data still needs validation on real hardware.