ci(installer): skip MSI ICE validation only when the Windows Installer service is unreachable #23

Closed
forge-recovery wants to merge 1 commits from ci/msi-validation-fallback-20261110 into main
pull from: ci/msi-validation-fallback-20261110
Owner

Why

Every Windows CI run on the shared native runner fails at the very last step (the MSI build) even though all 559 tests pass:

wix.exe : error WIX0217: Error executing ICE action 'ICE01' ... The Windows Installer Service could not be accessed.
MSI build failed.   (build/Build-Installer.ps1)

WiX validates the MSI through the Windows Installer service (msiserver). The shared native runners on Lore log on as batch accounts, and Windows' security descriptor on msiserver only lets SYSTEM, Administrators, interactive users and service-logon users start it, so every ICE action fails.

What

Before the MSI build, Build-Installer.ps1 now tries to reach the service:

  • reachable -> validation runs exactly as before (the project's documented ICE policy is untouched);
  • not reachable -> build with -p:SuppressValidation=true and print a loud warning;
  • a signed release build (with -CertificateThumbprint) never skips validation: it fails instead, so releases must be built where validation works (for example the full Windows VM runner).

Test

This PR's own Windows CI job runs on the shared Lore runner, which is exactly the environment that was failing.

Not a substitute for fixing the host: if the runner accounts are later given access to the Windows Installer service, validation simply starts running again with no change here.

## Why Every Windows CI run on the shared native runner fails at the very last step (the MSI build) even though all 559 tests pass: ``` wix.exe : error WIX0217: Error executing ICE action 'ICE01' ... The Windows Installer Service could not be accessed. MSI build failed. (build/Build-Installer.ps1) ``` WiX validates the MSI through the Windows Installer service (`msiserver`). The shared native runners on Lore log on as **batch** accounts, and Windows' security descriptor on `msiserver` only lets SYSTEM, Administrators, interactive users and service-logon users start it, so every ICE action fails. ## What Before the MSI build, `Build-Installer.ps1` now tries to reach the service: - reachable -> validation runs exactly as before (the project's documented ICE policy is untouched); - not reachable -> build with `-p:SuppressValidation=true` and print a loud warning; - a **signed release build** (with `-CertificateThumbprint`) never skips validation: it fails instead, so releases must be built where validation works (for example the full Windows VM runner). ## Test This PR's own Windows CI job runs on the shared Lore runner, which is exactly the environment that was failing. Not a substitute for fixing the host: if the runner accounts are later given access to the Windows Installer service, validation simply starts running again with no change here.
forge-recovery added 1 commit 2026-11-10 17:54:46 +00:00
WiX validates the MSI through the Windows Installer service (msiserver). The shared native
Windows runners log on as batch accounts, which Windows does not allow to start that service,
so every ICE action fails with WIX0217 and the whole MSI build fails after all tests pass.

Try to reach the service before the MSI build. When it is reachable, validation runs exactly as
before. When it is not, build without validation and warn loudly. A signed release build (one
with a certificate thumbprint) refuses to skip validation and fails instead, so it must be built
on a host where validation works.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
forge-recovery closed this pull request 2026-11-10 20:21:07 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.