kms-website/layouts/index.keys.json

{{- /* Machine-readable GVLK list for the activation scripts. Served at /keys.json. */ -}}
{{- dict "windows" .Site.Data.products.windows "windows_server" .Site.Data.products.windows_server "office" .Site.Data.products.office | jsonify (dict "indent" "  ") -}}
kms-website: auto-fetch + auto-install GVLKs (no manual key lookup) Scripts now detect the running edition and fetch the matching GVLK from a published key list instead of requiring the user to copy one from the table. - data/products.yaml: add editionid to every Windows/Server entry, plus build numbers where an EditionID spans releases (LTSC, Server). Azure Edition left unmapped on purpose (collides with Datacenter; KMS may fail there anyway). - /keys.json: Hugo KEYS output format renders products.yaml as JSON (single source of truth). layouts/index.keys.json. - setup-kms.ps1: when no VL key is installed, read registry EditionID (+build/ProductType for server) -> fetch /keys.json -> slmgr /ipk the match -> activate. Only acts when not already licensed (never clobbers retail). - kms-bootstrap.ps1: same for Windows; for Office/Project/Visio, read Click-to-Run ProductReleaseIds -> ospp /inpkey the matching GVLK -> /act. - $env:KMS_KEYS_URL overrides the key-list URL. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> 2026-06-01 10:12:03 +00:00			`{{- /* Machine-readable GVLK list for the activation scripts. Served at /keys.json. */ -}}`
			`{{- dict "windows" .Site.Data.products.windows "windows_server" .Site.Data.products.windows_server "office" .Site.Data.products.office \| jsonify (dict "indent" " ") -}}`