ADMX Operations

The ADMX capability is designed first as an operations platform for SYSVOL PolicyDefinitions governance. The public ADMX explorer is useful for search and discovery, but it is only one consumer of the normalized ADMX cache.

The operational goal is to answer four questions:

1. Which ADMX/ADML packages do we trust and maintain?
2. Which versions are cached and validated?
3. How does the domain Central Store differ from those cached provider packages?
4. What exact update plan would bring SYSVOL back to the desired state?

Layers

Provider Catalog

Provider entries describe where ADMX templates come from. Some providers need built-in release discovery logic, while simpler providers can be described with release manifests, direct downloads, local mirrors, or manual-review placeholders.

The maintained public website source catalog starts in:

docs\admx\sources\website-public.sources.json

The strategy example catalog stays in:

docs\examples\admx-provider-source-catalog.example.json

Provider metadata should include:

• product and vendor name,
• version and release date,
• upstream download or documentation URL,
• languages included,
• extraction or PolicyDefinitions root,
• validation status and warnings.

Provider Cache

The provider cache stores normalized ADMX/ADML files outside SYSVOL. It lets operators validate and compare vendor templates before a Central Store is touched.

The cache should be safe to refresh automatically, because it is not the production policy definition store.

Central Store Comparison

Central Store comparison is read-only. It should report:

• files missing from SYSVOL,
• files present but different,
• files already current,
• provider-owned files that are stale,
• extra/orphaned files not owned by a known provider,
• missing or inconsistent ADML language folders,
• broken ADMX/ADML parsing or presentation references.

Update Planning

Update planning produces file actions without applying them. Plans should be deterministic and reviewable so administrators can see exactly what would be added, overwritten, skipped, or left alone.

Governed Apply

SYSVOL writes must be explicit. Any future apply path should require write intent, write confirmation, actor/reason metadata, and rollback material before replacing files.

Website Publishing

The website ADMX explorer consumes validated cache output. It should help people search policy metadata, registry mappings, source packages, and generated artifacts, but it should not become the source of truth for provider freshness or SYSVOL drift.

Public website data should include only safe public metadata. Domain-specific paths, Central Store drift history, maintenance profile paths, and private provider mirrors should stay out of public builds.

Current Commands

Refresh or compare provider caches through the maintenance surface:

Invoke-ADXAdmxProviderMaintenance -Provider Edge,Chrome,Firefox -Language en-US

Run a repeatable maintenance profile:

Invoke-ADXAdmxProviderMaintenance -MaintenanceProfile .\docs\examples\admx-maintenance-profile.example.json

Run from a data-driven provider source catalog:

Test-ADXAdmxProviderSourceCatalog -Path .\docs\examples\admx-provider-source-catalog.example.json

Invoke-ADXAdmxProviderMaintenance -ProviderSourceCatalog .\docs\examples\admx-provider-source-catalog.example.json `
    -DestinationRoot '\\contoso.com\SYSVOL\contoso.com\Policies\PolicyDefinitions'

Run only selected catalog source ids:

Invoke-ADXAdmxProviderMaintenance -ProviderSourceCatalog .\docs\examples\admx-provider-source-catalog.example.json `
    -ProviderSourceId windows,edge,chrome `
    -SkipRefresh

The provider source catalog is the next contract for scaling beyond built-in providers. It can describe built-in, release-manifest, direct-download, local-mirror, and manual-review sources in one file. Catalog validation returns summary counts for total, executable, manual-review, disabled, and invalid entries so CI can quickly show how much of the catalog will participate in maintenance.

Use the same catalog from TestimoX posture rules so operational reports and website publishing stay aligned:

DomainAdmxProviderMaintenancePosture
  AdmxProviderSourceCatalog = .\docs\examples\admx-provider-source-catalog.example.json
  AdmxDestinationRoot = \\contoso.com\SYSVOL\contoso.com\Policies\PolicyDefinitions
  AdmxRefreshCache = false

Generate website explorer data from maintained providers:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -SourcePackageCatalogProviderNames Edge,Chrome,Firefox `
    -AdmxDirectory 'C:\Windows\PolicyDefinitions'

Generate website explorer data from the maintained public source catalog:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -SourcePackageProviderSourceCatalog .\docs\admx\sources\website-public.sources.json `
    -SourcePackageProviderSourceIds edge,chrome,firefox,notepad,security-admx,adobe-reader,adobe-acrobat,brave,zoom,winget,office,fslogix,citrix-workspace-app `
    -SourcePackageRefreshCache `
    -SourcePackageAllowPartial `
    -SourcePackageCacheRoot .\.artifacts\admx\provider-cache

The cache root is intentionally untracked. It stores normalized vendor payloads, version manifests, and the provider catalog.json; the repository tracks source definitions and generated contract code, not redistributed vendor ADMX files.

Validate generated website data:

Test-ADXAdmxCatalogBundle -Path '.\Website\static\data\admx-explorer'

Roadmap

The implementation roadmap lives in:

docs\roadmaps\ADMX-Operations-Platform-Roadmap.md