Restore image edition metadata lost during export (fixes #583)

[maged909]

The problem

On some source images the exported install.wim comes out missing the EDITIONID, INSTALLATIONTYPE, PRODUCTTYPE, PRODUCTSUITE and LANGUAGES elements from its XML metadata block.

Windows Setup matches ei.cfg's EditionID against the image's EDITIONID. When that element is absent, no image matches, and Setup aborts with:

Setup has failed to validate the product key

This happens both when a product key is supplied (via autounattend.xml or typed in) and when the user clicks "I don't have a product key", which makes it look like a licensing problem when it is really an edition-resolution problem. Reported in #583.

Diagnosis

Dumping the XML block out of a failing install.wim shows the <WINDOWS> element reduced to:

<WINDOWS><ARCH>9</ARCH><PRODUCTNAME>Microsoft® Windows® Operating System</PRODUCTNAME><VERSION>...</VERSION><SYSTEMROOT>WINDOWS</SYSTEMROOT></WINDOWS>

versus the same index in the untouched Microsoft ISO:

<WINDOWS><ARCH>9</ARCH><PRODUCTNAME>...</PRODUCTNAME><EDITIONID>Professional</EDITIONID><INSTALLATIONTYPE>Client</INSTALLATIONTYPE><PRODUCTTYPE>WinNT</PRODUCTTYPE><PRODUCTSUITE>Terminal Server</PRODUCTSUITE><LANGUAGES>...</LANGUAGES><VERSION>...</VERSION><SYSTEMROOT>WINDOWS</SYSTEMROOT></WINDOWS>

<FLAGS>Professional</FLAGS> does survive, which is presumably why this went unnoticed for a long time — that was the field older Setup versions matched on.

The fix

• Read the edition metadata off the source image before servicing begins.
• After the final /Export-Image, check the resulting WIM and restore the elements if they were dropped.

The XML block is written last in the WIM, so it can be rewritten in place and the file retruncated; the header's XML resource entry is repointed and the integrity table cleared. The repair is a no-op when the metadata survived, so images that build fine today are unaffected.

Scope and caveats

This restores the metadata rather than preventing the loss — I could not determine what in the servicing pass drops it, and the repair is deliberately conservative: it bails out with a warning (rather than touching the file) if the XML block is not at EOF, and reports any failure without aborting the build.

Testing

• Verified against a real affected image: applying the same transformation to a failing ISO made Get-WindowsImage report EditionId: Professional, InstallationType: Client, ProductType: WinNT, Languages: {en-US}, and Setup then installed to desktop without the error.
• The repair function passes a self-check covering restoration, XML well-formedness, header/size/TOTALBYTES consistency, integrity-table clearing, idempotency on a second run, and the not-at-EOF refusal path.
• I have not re-run a full end-to-end build with this patch in place, so a maintainer sanity check on the build path is worthwhile.

🤖 Generated with Claude Code