P3-9: Windows MSI, signing, and GPO/Intune deployment #38

New issue

Open

opened 2026-09-10 17:45:19 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-10 17:45:19 +00:00

Owner

Depends on P3-8, P0-3 (certificate) and P0-4 (Windows runner). This is where the operator story ships.

Files

Create: .forgejo/workflows/release-windows.yml, build/windows/product.wxs, build/windows/Cairn.admx, build/windows/Cairn.adml

MSI, not just an .exe

An MSI is what makes fleet deployment possible at all — GPO, Intune and SCCM all consume MSIs. Build it with the WiX Toolset.

Nextcloud gates its MSI and branding behind a paid tier. Ours is free. That is a deliberate competitive position from docs/design-spec.md §5, not an oversight.

Public properties for silent install

Expose these so an administrator can pre-configure at install time and the user never sees the setup wizard:

msiexec /i Cairn.msi /qn SERVERURL="https://cairn.example.org" FOLDERPATH="%USERPROFILE%\Cairn" AUTOSTART=1

Document the full property list in the README — an administrator should not have to read the .wxs to find them.

ADMX template

Ship Cairn.admx + Cairn.adml so the policy keys from P3-1 appear in the Group Policy editor as real, documented settings rather than raw registry values. This is the difference between "supports GPO" and "an admin can actually use it in ten minutes".

Cover at minimum: server, localPath, autoUpdateEnabled, errorReportingEnabled, allowUserToChangeServer.

Signing

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a Cairn.msi

Always timestamp (/tr). Without it, every signature becomes invalid the moment the certificate expires — including on machines that already installed it.
Sign both the .exe and the .msi.
The key lives on a hardware token or HSM (P0-3). Verify signing works unattended on the CI runner; a token that demands an interactive PIN per operation cannot be automated.
SmartScreen reputation still starts from zero and builds with downloads, regardless of OV or EV. Expect warnings on early downloads and do not panic — this is not a signing failure.

Steps

Write the WiX definition with public properties.
Write and test the ADMX/ADML template in a real Group Policy editor.
Wire signing into the release workflow on the Windows runner.
Test silent install with /qn and properties, then verify the app starts already configured.
Test a GPO-deployed install in a test domain, or at minimum an Intune assignment.
Test upgrade-in-place from a previous MSI version (UpgradeCode must be stable across versions).
Commit: git commit -s -m "build: Windows MSI with signing and GPO deployment"

Acceptance criteria

Silent install with properties produces a working, pre-configured client.
The MSI is signed and timestamped; properties show Swiss Cairn GmbH.
ADMX template loads and the settings apply.
Upgrade-in-place preserves configuration and sync state.

Depends on P3-8, P0-3 (certificate) and P0-4 (Windows runner). **This is where the operator story ships.** ## Files - Create: `.forgejo/workflows/release-windows.yml`, `build/windows/product.wxs`, `build/windows/Cairn.admx`, `build/windows/Cairn.adml` ## MSI, not just an .exe An MSI is what makes fleet deployment possible at all — GPO, Intune and SCCM all consume MSIs. Build it with the **WiX Toolset**. **Nextcloud gates its MSI and branding behind a paid tier. Ours is free.** That is a deliberate competitive position from `docs/design-spec.md` §5, not an oversight. ## Public properties for silent install Expose these so an administrator can pre-configure at install time and the user never sees the setup wizard: ``` msiexec /i Cairn.msi /qn SERVERURL="https://cairn.example.org" FOLDERPATH="%USERPROFILE%\Cairn" AUTOSTART=1 ``` Document the full property list in the README — an administrator should not have to read the `.wxs` to find them. ## ADMX template Ship `Cairn.admx` + `Cairn.adml` so the policy keys from P3-1 appear in the Group Policy editor as real, documented settings rather than raw registry values. This is the difference between "supports GPO" and "an admin can actually use it in ten minutes". Cover at minimum: `server`, `localPath`, `autoUpdateEnabled`, `errorReportingEnabled`, `allowUserToChangeServer`. ## Signing ``` signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a Cairn.msi ``` - **Always timestamp** (`/tr`). Without it, every signature becomes invalid the moment the certificate expires — including on machines that already installed it. - Sign **both** the `.exe` and the `.msi`. - The key lives on a hardware token or HSM (P0-3). Verify signing works **unattended** on the CI runner; a token that demands an interactive PIN per operation cannot be automated. - **SmartScreen reputation still starts from zero** and builds with downloads, regardless of OV or EV. Expect warnings on early downloads and do not panic — this is not a signing failure. ## Steps - [ ] Write the WiX definition with public properties. - [ ] Write and test the ADMX/ADML template in a real Group Policy editor. - [ ] Wire signing into the release workflow on the Windows runner. - [ ] **Test silent install with `/qn` and properties**, then verify the app starts already configured. - [ ] **Test a GPO-deployed install in a test domain**, or at minimum an Intune assignment. - [ ] Test upgrade-in-place from a previous MSI version (`UpgradeCode` must be stable across versions). - [ ] Commit: `git commit -s -m "build: Windows MSI with signing and GPO deployment"` ## Acceptance criteria - Silent install with properties produces a working, pre-configured client. - The MSI is signed and timestamped; properties show `Swiss Cairn GmbH`. - ADMX template loads and the settings apply. - Upgrade-in-place preserves configuration and sync state.