TestimoX

ADMX Explorer Data

Edit on GitHub

Generate static ADMX explorer data from ADPlayground for website and prototype consumers.

ADPlayground can now generate a static ADMX explorer bundle that is suitable for website prototypes, GitHub Pages-style hosting, or local UI experiments. The explorer data is a publication output from the broader ADMX Operations workflow, where provider cache maintenance and SYSVOL PolicyDefinitions comparison remain the source of truth.

The export is designed around three layers:

  • manifest.json for top-level counts, category tree, and source routing
  • search.json for client-side policy search without loading every source payload
  • sources/*.json for per-ADMX policy details loaded on demand

Once that bundle exists, the website can also expose a fully static browser at /admx-explorer/ that reads those files directly in the client.

The manifest also groups individual ADMX files into source packages. A source package represents the upstream bundle that delivered the templates, such as Windows PolicyDefinitions, a Central Store, Microsoft Edge policy templates, Chrome policy templates, or Firefox policy templates. This keeps the UI source selector package-oriented while still preserving per-ADMX routing internally.

The data workflow now also includes a typed validator so we can prove the split bundle is internally consistent before a frontend consumes it.

By default, the website-oriented bundle trims duplicated payload content so the static frontend can stay lighter. If you need the richer diagnostic shape, use the full bundle mode.

The search index also carries lightweight preview and routing fields that static clients can use without loading a source payload first:

  • CategorySegments for breadcrumb-aware filtering without reparsing the category path
  • ExplainPreview for short list summaries
  • SourcePayloadPath for direct links back to the owning split JSON file
  • ElementTypes and ElementCount for richer policy previews in list views

Generate Website Data

Run the dedicated website helper script from the repository root:

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

This writes the bundle into:

Website\static\data\admx-explorer

That folder is copied as part of the website static assets, which makes it a good handoff point for a JavaScript explorer. By default, the helper script also runs Test-ADXAdmxCatalogBundle against the generated manifest and stops on validation errors.

The main PowerForge website pipeline now runs this generator automatically before the site build, so GitHub Pages and PR website builds do not depend on checked-in bundle files.

Common Options

Generate a website-optimized bundle:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -AdmxDirectory 'C:\Windows\PolicyDefinitions' `
    -BundleMode Website

Generate a full-fidelity split bundle:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -AdmxDirectory 'C:\Windows\PolicyDefinitions' `
    -BundleMode Full

Use Central Store discovery instead of an explicit path:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -Domain 'contoso.com'

Label the generated source package from a built-in ADMX provider:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -AdmxDirectory 'C:\Windows\PolicyDefinitions' `
    -SourcePackageProvider Windows

Generate from the maintained provider cache catalog. This uses the latest cached provider PolicyDefinitions folder as the ADMX input and labels the source package from catalog.json:

Update-ADXAdmxProviderCache -Provider Edge -Language en-US

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -SourcePackageCatalogProvider Edge

For custom/vendor packages maintained from release manifests or maintenance profiles, select the catalog entry by name:

Invoke-ADXAdmxProviderMaintenance -ReleaseManifest .\vendor\contoso-admx.json -SkipRefresh:$false

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -SourcePackageCatalogProviderName 'Contoso Browser'

Generate one website data bundle from several cached provider packages:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -SourcePackageCatalogProviderNames Edge,'Contoso Browser'

Or use the same reusable maintenance profile that drives SYSVOL comparison:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -SourcePackageMaintenanceProfile .\admx-maintenance.json

Or use the maintained public source catalog that can grow into an ADMScope-style source selector:

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 tracked catalog lives under docs\admx\sources. It is the EvergreenAdmx-style inventory for real vendor products. The downloaded or harvested ADMX/ADML files belong in an untracked cache such as .artifacts\admx\provider-cache, where ADPlayground writes provider/version folders, release metadata, and the cache catalog used for comparisons. Local C:\Windows\PolicyDefinitions input remains useful for parser smoke tests, but the public website dataset should be built from the catalog/cache path.

You can also override package metadata explicitly when you already know the package identity:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -AdmxDirectory 'C:\Windows\PolicyDefinitions' `
    -SourcePackageId 'windows-11-25h2' `
    -SourcePackageName 'Microsoft Windows 11 25H2' `
    -SourcePackageVersion '3.0' `
    -SourcePackagePublishedDate '2026-04-24' `
    -SourcePackageUrl 'https://aka.ms/admx'

Skip the post-export validation step when you only want raw generation speed:

pwsh.exe -NoLogo -NoProfile -File .\Website\build-admx-explorer-data.ps1 `
    -AdmxDirectory 'C:\Windows\PolicyDefinitions' `
    -SkipValidation

Validate an Existing Bundle

You can validate a previously generated bundle directly from PowerShell:

Import-Module ADPlayground.PowerShell

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

The validation result reports declared-versus-observed counts for sources, policies, and search entries, and includes typed issues when a manifest entry, search route, or per-source payload is inconsistent.

Integrate with Website Build

The main website build script now invokes the generator through the PowerForge pipeline automatically:

pwsh.exe -NoLogo -NoProfile -File .\Website\build.ps1

Useful parameters:

  • -AdmxDirectory chooses a specific PolicyDefinitions folder.
  • -AdmxDomain uses Central Store discovery when no explicit path is given.
  • -AdmxLanguage selects the preferred ADML language.
  • -AdmxBundleMode Website|Full chooses the payload shape for split source files.
  • -AdmxExplorerDataPath overrides the default output folder.
  • -AdmxSourcePackageProvider labels generated source packages from a built-in ADMX release provider.
  • -AdmxSourcePackageCatalogProvider uses the latest cached provider package from the maintained provider cache catalog.
  • -AdmxSourcePackageCatalogProviderName selects a custom/vendor provider name from the maintained provider cache catalog.
  • -AdmxSourcePackageCatalogProviderNames joins several cached provider packages into one generated bundle.
  • -AdmxSourcePackageMaintenanceProfile resolves cached providers from the same maintenance profile used for SYSVOL comparison.
  • -AdmxSourcePackageProviderSourceCatalog resolves cached providers from a data-driven source catalog.
  • -AdmxSourcePackageRefreshCache refreshes the maintenance profile cache before joining website bundles.
  • -AdmxSourcePackageAllowPartial keeps broad catalog website generation moving when one requested provider cannot resolve.
  • -AdmxSourcePackageCacheRoot points to a non-default provider cache root.
  • -AdmxSourcePackageEdgeChannel selects the Edge channel when the source package provider is Edge.
  • -IncludeAdmxExplorerData is kept as a compatibility switch, but the pipeline generates ADMX explorer data even without it.

Why This Matters

This generation flow proves the ADMX pipeline end to end:

  1. ADPlayground parses and types the ADMX repository.
  2. PowerShell cmdlets export a reproducible static bundle.
  3. The bundle can be validated end to end before it is published or consumed.
  4. The same typed policy definitions can now generate .reg, PowerShell, Intune proactive remediation, and inferred MDM/SyncML candidate artifacts with Get-ADXAdmxPolicyArtifact.
  5. The website has a stable folder and file contract for a future explorer UI.

That means the next frontend spike can focus on browsing and UX instead of re-solving parsing or data shaping.

If you want to prove a single policy end to end before building UI, start with Get-ADXAdmxPolicyArtifact. It reuses the same typed ADMX model and now emits:

  • Registry operations and .reg content
  • PowerShell remediation script content
  • Intune proactive remediation detection and remediation scripts
  • Inferred MDM/SyncML candidates for ADMX-backed Policy CSP scenarios

The MDM layer is intentionally cautious: OMA-URI and SyncML output are inferred from the typed ADMX policy source, scope, and element values. That makes it useful for proving parser completeness and shaping website data, but Microsoft-specific Policy CSP routes should still be validated against official documentation before production deployment.