25H2 tiny11 - Setup has failed to validate the product key

[Karl-WE]

Issue:
Tiny11.iso will fail to install bare metal. No remediation possible. Maybe it's missing the license terms file?

Original W11 25H2 ISO is doing fine.

Error:
Setup has failed to validate the product key

Repro:
Download 25H2 from Microsoft, language English (US)
Mount
Apply tiny11maker (as of 09-07-2025)
Tiny11maker -iso D -scratch c
Select Windows 11 Pro Image
Will execute without any errors
Create bootable from ISO or use ventoy
Execute setup

[MegaSuite]

same issue.
target: windows 11 pro.
source: 26200.6584.250915-1905.25h2_ge_release_svc_refresh_CLIENT_CONSUMER_x64FRE_zh-cn.iso.
install: ventoy.

[MegaSuite]

same issue. target: windows 11 pro. source: 26200.6584.250915-1905.25h2_ge_release_svc_refresh_CLIENT_CONSUMER_x64FRE_zh-cn.iso. install: ventoy.

I tried this, and it works.

[maged909]

I hit this too and tracked down what is actually happening. It is not a licensing problem and it is not a missing license terms file — the sources folder of the built ISO is byte-for-byte complete compared to the official Microsoft ISO. The problem is inside install.wim.

What is wrong

The exported image loses part of its XML metadata. Dumping the XML block out of a failing install.wim:

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

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><LANGUAGE>en-US</LANGUAGE><DEFAULT>en-US</DEFAULT></LANGUAGES><VERSION>...</VERSION><SYSTEMROOT>WINDOWS</SYSTEMROOT></WINDOWS>

EDITIONID, INSTALLATIONTYPE, PRODUCTTYPE, PRODUCTSUITE and LANGUAGES are gone. Setup matches ei.cfg's EditionID against the image's EDITIONID, so nothing matches and it aborts with "Setup has failed to validate the product key".

That misleading message is why this is confusing: it fires whether you supply a key or click "I don't have a product key", because neither path can resolve an edition. Adding an ei.cfg, injecting a generic product key, or trying a different key all fail for the same underlying reason.

Note <FLAGS>Professional</FLAGS> does survive — that is the field older Setup versions matched on, which is probably why this went unnoticed for so long.

How to confirm it on your own build

$m = Mount-DiskImage -ImagePath "C:\path\to\your\tiny11.iso" -PassThru
$d = ($m | Get-Volume).DriveLetter
Get-WindowsImage -ImagePath "${d}:\sources\install.wim" -Index 1 |
    Format-List ImageName, EditionId, InstallationType, ProductType, Languages
Dismount-DiskImage -ImagePath "C:\path\to\your\tiny11.iso"

Run elevated. If EditionId comes back blank, this is your issue.

Fixing an ISO you already built

You do not need to rebuild. The XML block is the last thing in the WIM, so it can be rewritten in place. wimlib-imagex can do it in one command, but wimlib.net is offline at the moment (which also breaks the Chocolatey package, since it just downloads from there), so here is a pure PowerShell version. Extract the ISO contents to a folder first, run this against sources\install.wim, then repack with oscdimg:

$wim = "D:\extracted\sources\install.wim"
$fs = [System.IO.File]::Open($wim, 'Open', 'ReadWrite')
$hdr = New-Object byte[] 208
$null = $fs.Read($hdr, 0, 208)
$xmlSize   = [int]([BitConverter]::ToUInt64($hdr,72) -band 0x00FFFFFFFFFFFFFF)
$xmlFlags  = $hdr[79]
$xmlOffset = [long][BitConverter]::ToUInt64($hdr,80)
if ($xmlOffset + $xmlSize -ne $fs.Length) { $fs.Close(); throw "XML block is not at EOF" }
$buf = New-Object byte[] $xmlSize
$null = $fs.Seek($xmlOffset, 'Begin'); $null = $fs.Read($buf, 0, $xmlSize)
$xml = [System.Text.Encoding]::Unicode.GetString($buf).TrimStart([char]0xFEFF)

# adjust these to match your edition if you did not build Pro
$restore = '<EDITIONID>Professional</EDITIONID><INSTALLATIONTYPE>Client</INSTALLATIONTYPE>' +
           '<PRODUCTTYPE>WinNT</PRODUCTTYPE><PRODUCTSUITE>Terminal Server</PRODUCTSUITE>' +
           '<LANGUAGES><LANGUAGE>en-US</LANGUAGE><DEFAULT>en-US</DEFAULT></LANGUAGES>'
$xml = $xml -replace '(</PRODUCTNAME>)', "`$1$restore"

for ($i = 0; $i -lt 6; $i++) {
    $bytes = [byte[]](0xFF,0xFE) + [System.Text.Encoding]::Unicode.GetBytes($xml)
    $upd = $xml -replace '^<WIM><TOTALBYTES>\d+</TOTALBYTES>', ('<WIM><TOTALBYTES>' + ($xmlOffset + $bytes.Length) + '</TOTALBYTES>')
    if ($upd -eq $xml) { break }
    $xml = $upd
}
$bytes = [byte[]](0xFF,0xFE) + [System.Text.Encoding]::Unicode.GetBytes($xml)
$null = $fs.Seek($xmlOffset, 'Begin')
$fs.Write($bytes, 0, $bytes.Length)
$fs.SetLength($xmlOffset + $bytes.Length)
$sizeField = [BitConverter]::GetBytes([uint64]$bytes.Length); $sizeField[7] = $xmlFlags
[Array]::Copy($sizeField, 0, $hdr, 72, 8)
[Array]::Copy([BitConverter]::GetBytes([uint64]$bytes.Length), 0, $hdr, 88, 8)
for ($i = 124; $i -lt 148; $i++) { $hdr[$i] = 0 }   # integrity table is now invalid
$null = $fs.Seek(0, 'Begin'); $fs.Write($hdr, 0, 208)
$fs.Close()

Verify with the Get-WindowsImage command above before repacking — EditionId should read Professional. Repack with the same oscdimg line the script uses so the ISO stays bootable on both UEFI and BIOS.

After this my build installed straight through to the desktop with no key prompt at all.

One thing to expect: on a 25H2 source the finished install reports build 26100 (24H2), because 25H2 is an enablement package on top of 24H2 and the servicing pass removes it. The install is fine, just a version behind.

I opened #628 with a fix for the script itself, which captures the source image's metadata before servicing and restores it after the export if it went missing.