Group Policy Objects (GPOs) allow system administrators to control PowerToys settings across an organization. This document describes how GPOs are implemented in PowerToys.
GPO policies allow system administrators to control PowerToys settings. PowerToys ships GPO files as part of the release zip, not installed directly.
- Contains policy definitions
- Defines which versions support each policy
- Sets up folder structure
- Defines each policy with:
- Name
- Class (user scope or machine scope)
- Description
- Registry location where policy is stored
- Enabled/disabled values
- Contains localized strings for the ADMX file
- Contains revision number that must be updated when changes are made
- Stores strings for:
- Folder names
- Version definitions
- Policy descriptions and titles
- Currently only ships English US version (no localization story yet)
- Files need to be placed in:
C:\Windows\PolicyDefinitions\ - ADMX file goes in the root folder
- ADML file goes in the language subfolder (e.g., en-US)
- After installation, policies appear in the Group Policy Editor (gpedit.msc)
- Policies are stored as registry values
- Location:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerToysorHKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\PowerToys - Machine scope takes precedence over user scope
- Policy states:
- Enabled: Registry value set to 1
- Disabled: Registry value set to 0
- Not Configured: Registry value does not exist
- Policy keys defined in
common\utils\GPO.h - Contains functions to read registry values and get configured values
- WinRT C++ adapter created for C# applications to access GPO settings
- WPF applications cannot directly load WinRT C++ projects
- Additional library created to allow WPF applications to access GPO values
- Each module must implement policy checking in its interface
- Runner checks this to determine if module should be started or not
- When a policy disables a utility:
- UI is locked (cannot be enabled)
- Settings page shows a lock icon
- Dashboard hides the module button
- If user tries to start the executable directly, it exits and logs a message
- Most common type
- Controls whether a module can be enabled or disabled
- Shared description text for these policies
- Example: Run at startup setting
- Controls specific settings rather than enabling/disabling modules
- Custom description text explaining what happens when enabled/disabled/not configured
- Example: Mouse Without Borders service mode
- Only makes sense at machine level (not user level)
- Restricts functionality that requires elevated permissions
-
Update ADMX file:
- Increase revision number
- Add supported version definition
- Define the policy with registry location
-
Update ADML file:
- Increase revision number
- Add strings for version, title, description
-
Update code:
- Add to GPO.h
- Add to GPO wrapper for C# access
- Update module interface
- Modify settings UI to show lock when policy applied
- Add checks in executable to prevent direct launching
- Update dashboard helper to respect policy
-
Add to bug report tool to capture policy state
disable automatic update download- Prevents automatic downloadingdisable new update toast- Controls if toast notifications are shownsuspend new update toast- Suspends toast notifications for 2 minor releases
To test GPO settings locally:
- Run
regeditas administrator - Navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerToys - Create a new DWORD value with the name of the policy
- Set the value to 0 (disabled) or 1 (enabled)
- Restart PowerToys to see the effect
For user-scope policies, use HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\PowerToys instead.