Enterprise › ADMX / GPO Templates

Group Policy templates

Every MDE Toolkit setting in the Group Policy editor, with proper names, explanations and validation — instead of a list of registry values you have to script by hand.

Download

🏛️
MDE-Toolkit-ADMX.zip Contains MDE-Toolkit.admx, en-US\MDE-Toolkit.adml and a README. Free, and covered by the same MIT license as the toolkit.
Download .zip

Prefer the individual files? MDE-Toolkit.admx · en-US/MDE-Toolkit.adml · README.md

Why bother? Every setting the toolkit reads lives under one registry key. You can push those values with a script or a GPO preference. The templates simply mean you get real names, an explanation of what each one does, drop-down lists instead of magic numbers, range checking, and a record in the Group Policy Management Console of who set what.

Install the templates

Central Store — recommended for domain environments

Copy the two files into your domain’s Central Store. Every administrator who opens the Group Policy editor then sees the settings, with no per-workstation installation.

Destination paths
\\<your-domain>\SYSVOL\<your-domain>\Policies\PolicyDefinitions\MDE-Toolkit.admx
\\<your-domain>\SYSVOL\<your-domain>\Policies\PolicyDefinitions\en-US\MDE-Toolkit.adml
PowerShell — copy to the Central Store
$domain = $env:USERDNSDOMAIN
$store  = "\\$domain\SYSVOL\$domain\Policies\PolicyDefinitions"

New-Item -ItemType Directory -Path "$store\en-US" -Force | Out-Null
Copy-Item .\MDE-Toolkit.admx        -Destination $store          -Force
Copy-Item .\en-US\MDE-Toolkit.adml  -Destination "$store\en-US"  -Force
No Central Store yet? Create the PolicyDefinitions folder in SYSVOL and copy the entire contents of C:\Windows\PolicyDefinitions from a machine running your newest Windows build into it first. If you create the folder containing only these two files, the editor will show only these settings and every built-in Windows policy will disappear from view.

Single machine

For a lab, or where you administer policy from one workstation:

Destination paths
C:\Windows\PolicyDefinitions\MDE-Toolkit.admx
C:\Windows\PolicyDefinitions\en-US\MDE-Toolkit.adml

Local policy on a non-domain machine

After copying to C:\Windows\PolicyDefinitions, open gpedit.msc and browse to the same location. Note that gpedit.msc is not present on Home editions.

Where the settings appear

Group Policy Management Editor
Computer Configuration
  └── Policies
        └── Administrative Templates
              └── MDE Toolkit
                    ├── Background Collector
                    ├── Telemetry Upload
                    ├── Identity and Authentication
                    ├── Data Collection Scope
                    ├── Device Tagging
                    ├── Application Lockdown
                    ├── ASR Exclusion Guardrails
                    ├── Logging and Diagnostics
                    └── Page Visibility
FolderWhat it coversTypical use
Background Collector Enable collection, interval, cache folder, file count and retention. Turn on fleet reporting.
Telemetry Upload Function App URL and audience, blob storage destination, interval, timeout, retries. Point endpoints at your ingestion endpoint.
Identity and Authentication Tenant, preferred auth method, Azure cloud, authority override. Sovereign clouds and non-standard tenants. Usually leave alone.
Data Collection Scope Six switches for Defender status, Defender policies, firewall, App Control, enrollment and Device Guard. Reduce what leaves the device.
Device Tagging Device tag, organizational unit, environment. Slice fleet dashboards by business unit, site or environment.
Application Lockdown Block exports, restrict to local machine, force read-only mode, show preview features. Constrain what helpdesk staff can do with the tool.
ASR Exclusion Guardrails Allow permanent exclusions, allow temporary exclusions, maximum duration, duration menu. Stop long-lived ASR exclusions accumulating. More on ASR →
Logging and Diagnostics Log level, log file path, rotation size. Troubleshoot a deployment that is not reporting.
Page Visibility Twelve settings, one per page, each with Hidden / Administrators / Standard users / Both. Show only the pages a given audience needs.
Every setting is optional. Not Configured means the application uses its built-in default. You only need to configure the things you actually want to change, and clearing a setting later restores the default rather than leaving a stale value behind.

Common configurations

Four starting points. Each one is a handful of settings, not a wholesale lockdown.

📡 Fleet reporting only

  • Background Collector → Enable the background collector: Enabled
  • Telemetry Upload → Enable upload to an Azure Function App: Enabled
  • Telemetry Upload → Azure Function App endpoint: your URL and audience
  • Device Tagging → set the environment and organizational unit

👀 Helpdesk read-only

  • Application Lockdown → Force read-only mode: Enabled
  • Application Lockdown → Restrict the application to the local machine: Enabled
  • Page Visibility → ASR Rules events page: Both
  • Page Visibility → hide pages the team does not need

🔒 High-security workstations

  • Application Lockdown → Block data export: Enabled
  • Application Lockdown → Restrict to the local machine: Enabled
  • ASR → Allow permanent ASR exclusions: Disabled
  • ASR → Maximum ASR exclusion duration: 4 hours
  • Page Visibility → AI Analysis page: Hidden

🧪 Preview pilot group

  • Application Lockdown → Show preview features: Enabled
  • Page Visibility → Machine Investigator page: Administrators only
  • Scope the GPO to a pilot security group
  • What Machine Investigator does →

Verify a deployment

PowerShell — on a target machine
gpupdate /target:computer /force

# Everything the toolkit will read
Get-ItemProperty "HKLM:\SOFTWARE\Policies\MDE-Toolkit" | Format-List

# Which pages are policy-controlled
Get-Item "HKLM:\SOFTWARE\Policies\MDE-Toolkit" |
    Select-Object -ExpandProperty Property |
    Where-Object { $_ -like "Visibility*" }

Run gpresult /h gpreport.html for a report showing which GPO supplied each value — useful when two policies disagree.

Using Intune instead

ADMX templates are for Group Policy. If your devices are managed by Intune, deploy the same values as a settings catalog or OMA-URI policy against the same registry key.

Example — OMA-URI
OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/... (custom registry CSP)
Key:      HKLM\SOFTWARE\Policies\MDE-Toolkit
Value:    EnableBackgroundCollector
Type:     Integer
Data:     1

A PowerShell script deployed through Intune is often simpler for the initial rollout. The registry reference lists every value, its type and its default.

Notes and caveats

  • Computer scope only. There are no user-scope settings; everything applies to the machine.
  • Version awareness. Each setting declares which toolkit version introduced it under Supported on. Applying a setting to an older build is harmless — it is simply ignored.
  • Upgrades are safe. The MSI seeds each value at its built-in default but never overwrites an existing one, so policy-set values survive.
  • Two settings changed behaviour in 3.3.2. DisableExportButtons and DisableRemoteTarget were previously documented but had no effect. They are now genuinely enforced. If you set either speculatively and still want export or remote targeting, set them back to Disabled before rolling out 3.3.2.
  • Seven values were removed in 3.3.2. They are ignored if present, and are deliberately absent from these templates. See the 3.3.2 release notes.
  • English only for now. Only en-US resources are supplied. Copy the ADML into another language folder to have it load in that locale; the text will remain English.

Download ADMX (.zip) Registry reference