Configuration Policies
Configuration policies let you manage Windows device settings using ADMX-based Group Policy templates. Define settings once and deploy them to targeted groups of endpoints.
What Are ADMX Policies?
ADMX (Administrative Template XML) policies are the same Group Policy settings used in Active Directory environments. They control everything from Windows Update behavior to BitLocker encryption, Defender settings, and user restrictions.
TridentStack Control brings this capability to cloud-managed endpoints without requiring Active Directory infrastructure. You get the same granular control over device configuration, delivered through the TridentStack Control agent instead of a domain controller.
Creating a Policy Object
- Navigate to Configuration Policies in the sidebar.
- Click Create Policy.
- Enter a descriptive name for the policy (e.g., "Security Hardening - Windows 11" or "Remote Desktop - Enable for IT").
- Optionally add a description to document the policy's purpose.
- Click Create to open the policy editor.
Choose names that clearly communicate what the policy does. When you have dozens of policies, descriptive naming makes management significantly easier.
Configuring Settings
Each policy object contains one or more settings from the ADMX template catalog. Use the setting browser to find and configure the settings you need.
Available Categories
The ADMX catalog organizes settings into categories that mirror the Group Policy Management Editor:
- Windows Components: Windows Update delivery and deferral, BitLocker drive encryption, Microsoft Defender Antivirus, Microsoft Edge browser settings
- System: Power management, Remote Desktop Protocol, audit and logging, device installation restrictions
- Network: DNS client configuration, Windows Firewall profiles, Wi-Fi and wireless networking
- Security: Password policies, account lockout thresholds, User Account Control (UAC) behavior
Setting States
Each setting in a policy object can be in one of three states:
| State | Behavior |
|---|---|
| Enabled | The setting is actively enforced. Some settings accept additional configuration values when enabled (e.g., specifying a minimum password length). |
| Disabled | The setting is explicitly turned off. This is different from "Not Configured" because it actively disables the feature. |
| Not Configured | The default state. TridentStack Control does not manage this setting, leaving whatever value the endpoint currently has in place. |
When you enable a setting that accepts values, the editor displays the relevant input fields. For example, enabling "Minimum password length" reveals a numeric input where you specify the required length.
Targeting
Configuration policies are assigned to agents using tags, the same targeting mechanism used by update policies. This provides a consistent and flexible way to control which endpoints receive which settings.
Tag-based targeting means:
- New agents that receive the tag automatically get the policy applied on their next check-in.
- Removing a tag from an agent stops that policy from being enforced on future check-ins.
- Multiple policies can target the same tag, and a single agent can receive settings from multiple policies.
Policy Evaluation
Policies are evaluated during the agent check-in cycle. The process works as follows:
- The agent checks in with the TridentStack Control server.
- The server resolves which configuration policies apply to the agent based on its tags.
- Any new or updated policy settings are sent to the agent.
- The agent applies the settings locally using the Windows policy engine.
- The agent reports the applied settings back to the server for verification.
Configuration policies complement your existing Group Policy infrastructure. They do not conflict with AD-delivered GPOs, but TridentStack Control-managed settings take precedence when there is overlap.
Best Practices
- Start small. Begin with a few critical settings (e.g., password policies, Windows Update configuration) and expand as you gain confidence.
- Use descriptive names. A policy named "CIS L1 - Account Policies" is far more useful than "Policy 1."
- Test before broad deployment. Assign new policies to a small test tag first, verify the settings apply correctly, then expand to production tags.
- Document your intent. Use the policy description field to record why the policy exists and what compliance requirement it addresses.
Custom Registry Settings
In addition to Administrative Templates, policy objects can include custom registry settings for direct Windows Registry key and value management. Use custom registry settings for third-party application configuration, advanced Windows tuning, and any scenario not covered by the ADMX catalog.
Where to find registry settings
Open a policy object and look for the Registry Settings node in the left sidebar tree. This is a top-level node, separate from the Administrative Templates tree. Click it to view and manage all custom registry settings for that policy object.
Creating a registry setting
Click Add Registry Setting to open the configuration form. Fill in the following fields:
| Field | Required | Description |
|---|---|---|
| Hive | Yes | The registry hive to target: HKEY_LOCAL_MACHINE (HKLM) or HKEY_CURRENT_USER (HKCU) |
| Action | Yes | What to do with the registry value: Create, Replace, Update, or Delete |
| Key Path | Yes | The registry key path without the hive prefix (e.g., SOFTWARE\MyCompany\MyApp). Intermediate keys are created automatically if they do not exist |
| Value Name | Yes | The name of the registry value. Leave empty to target the (Default) value |
| Value Type | Yes (except Delete) | The data type: REG_SZ, REG_DWORD, REG_QWORD, REG_BINARY, REG_MULTI_SZ, or REG_EXPAND_SZ |
| Value Data | Yes (except Delete) | The data to write. The expected format depends on the value type (see below) |
| Description | No | An internal note explaining why this setting exists. Not deployed to endpoints |
| Enabled | Default: on | Toggle to enable or disable the setting without deleting it |
Registry actions
Each setting uses one of four actions:
| Action | Behavior |
|---|---|
| Create | Creates the value only if it does not already exist. If the value is already present, no changes are made |
| Replace | Deletes the existing value first, then writes the new value. Creates it if it does not exist. Use this when you need to change the value type |
| Update | Writes the value directly, overwriting if it exists or creating if it does not. This is the recommended default for most use cases |
| Delete | Removes the value entirely. Only requires Hive, Key Path, and Value Name. Value Type and Value Data are ignored |
Value types and data entry
| Type | Input Format | Example |
|---|---|---|
| REG_SZ | Plain text string | C:\Program Files\MyApp |
| REG_EXPAND_SZ | Text with environment variables (expanded on the endpoint) | %SystemRoot%\System32 |
| REG_DWORD | 32-bit integer in decimal or hexadecimal | 1 or 0x00000001 |
| REG_QWORD | 64-bit integer in decimal or hexadecimal | 4294967296 |
| REG_BINARY | Space-separated hex byte pairs | 0A FF 3C 00 |
| REG_MULTI_SZ | Multiple strings, one per line | Each line becomes one entry in the multi-string array |
HKLM vs HKCU
HKEY_LOCAL_MACHINE (HKLM) settings are computer-wide. They are applied once per machine and affect all users. This is the recommended hive for most deployments.
HKEY_CURRENT_USER (HKCU) settings are per-user. They are applied to all users on the endpoint, not to individual users. The agent reapplies HKCU settings on each policy sync to cover users who log in after the initial deployment.
HKCU registry settings apply to all users on the endpoint. Individual user targeting is not supported. If you need per-user configuration, consider using User Configuration Administrative Templates instead.
Safety protections
TridentStack Control prevents modifications to sensitive registry paths:
- Blocked paths cannot be saved. These include
SOFTWARE\Policies(reserved for Administrative Templates) and system-critical paths such as SAM, SECURITY, and boot execution entries. The editor displays a red warning and prevents saving. - Warned paths can be saved but display an amber warning. These include system control settings, Windows service configurations, OS version keys, and startup program entries. Review these carefully before saving.
All settings are validated before saving. Key paths are checked for length limits and invalid characters. Value data is validated against the selected type (for example, REG_DWORD values must be valid 32-bit integers).
Do not use custom registry settings for paths under SOFTWARE\Policies. Those paths are managed by Administrative Templates. Use the ADMX editor for any setting in the Policies subtree.
Managing registry settings
The registry settings table shows all settings for the policy object. Each row displays:
- An enabled/disabled toggle to activate or deactivate the setting without removing it
- The action as a color-coded label (Create, Replace, Update, or Delete)
- The full key path including the hive prefix
- The value name, value type, and a preview of the value data
- Edit and Delete buttons
Click the edit button to reopen the form with the setting's current values. Click delete to remove the setting permanently (a confirmation dialog is shown first).
Viewing applied settings
After a policy object is deployed, you can verify that registry settings were applied correctly. Navigate to an agent's detail page and open the Effective Policy tab. Custom registry settings appear with a "Custom Reg" type label. You can filter the effective policy list by this type to see only registry settings.
Each entry shows the configured action and value data so you can confirm the setting matches your policy object.