How to Add, Edit and Remove Registry Keys Using Group Policy

7.9K

Group Policy (GPO) allows you to centrally create, modify, import, and delete registry keys and parameters on multiple computers joined to Active Directory domain. This article looks at typical operations for managing registry entries on domain computers using Group Policy Preferences (GPP).

Note. You should prefer a native policy whenever Microsoft provides one. In traditional AD environments, this usually means an Administrative Template policy through GPO. First, you should check the Settings Catalog and ADMX-backed policies for Intune-managed Windows devices. Use Group Policy Preferences/custom OMA-URI policies when the required setting isn’t available through a supported policy.

Important. Note that Group Policy Preferences (GPP) are not the same as Administrative Template policies. Administrative Template settings are managed policies that are continuously enforced by Group Policy and are typically removed when the policy no longer applies. Registry Preferences generally write values directly to the registry (“tattooing”). Unless additional options such as Remove this item when it is no longer applied are configured, the registry values may remain after the GPO is removed, and users/apps may be able to modify them. For security-sensitive settings, you should generally prefer Administrative Template policies whenever an equivalent policy exists.

Modern Windows management: GPO vs. Intune

Note that our article focuses on traditional AD environments where Windows devices are managed with Group Policy. For Microsoft Intune-managed Windows devices, Group Policy is not used. Instead, Windows config profiles use MDM policies and Configuration Service Providers (CSPs).

Before creating a Registry Preference, you should check whether the required setting is available through the Microsoft Intune Settings Catalog/ADMX-backed policy. If your organization is migrating from on-premises GPOs to Intune, Group Policy Analytics can import and analyze existing GPOs and identify settings that can be migrated to a Settings Catalog policy.

You should also check if Windows provides a dedicated management feature instead of configuring the registry directly. For example, you should use Windows LAPS to manage local admin passwords rather than deploying local admin password settings through Registry Preferences. For Microsoft Entra-joined devices, we recommend managing Windows LAPS through Microsoft Intune.

Consider migration before creating new Registry Preferences. In case your organization is moving from traditional Group Policy to Microsoft Intune, you should treat new Registry Preference items as a compatibility and migration decision rather than simply another way to config Windows.

You should check Microsoft Intune’s Settings Catalog and ADMX-backed policies first because many Windows settings that were historically configured through registry-based GPOs now have supported policy equivalents. Group Policy Analytics can help you to assess existing GPOs and identify settings that can be migrated to Intune.

Registry Preferences are different from Administrative Template policies and may require additional migration work because they write specific registry values rather than representing a supported policy setting. Some Group Policy Preference extensions (such as Registry, Drive Maps, Scheduled Tasks, and certain script-based configs), may require manual remediation/alternative Intune implementation.

As an enterprise recommendation, before adding a new Registry Preference to a GPO, you should check if the setting is available in the Intune Settings Catalog or through a supported ADMX-backed policy. If an equivalent exists, you should prefer the supported policy rather than creating a new registry-based dependency that may need to be remediated during a future GPO-to-Intune migration.

You should use Intune policies rather than relying on on-premises GPOs for cloud-native/cloud-only Windows devices. Hybrid environments may use both GPO and Intune, so you need to avoid configuring the same setting through both management systems unless the interaction has been tested.

Before diving into the config steps, we want to ensure you do understand when to use each method:

• Use Group Policy Preferences (GPP) when you need granular control over specific registry values, you want easy targeting (users, groups, devices), you need reversible and manageable settings
• Use REG file deployment in case you have a large number of registry settings, you already have an exported config, you need a quick bulk deployment
• Use GPO Security (ACLs) when you need to control access to registry keys, you want to prevent/allow modifications by users
• Use PowerShell in case you want automation/scripting, or you are managing GPOs programmatically

Security note. Group Policy Preferences have a history of security issues. Older versions of GPP allowed you to store passwords in preference items (such as local users, scheduled tasks, and drive mappings). These passwords were stored in SYSVOL using reversible encryption and could be recovered by authenticated domain users. Microsoft addressed this issue in security update MS14-025 and you are no longer allowed to config new passwords through those preference extensions. Although Registry Preferences themselves do not store passwords, you should review older GPOs and remove any legacy GPP password entries that may still exist.

How to Add or Modify Registry Keys via GPO

Use the Group Policy Management console (gpmc.msc) to manage domain GPOs:

1. Open the GPMC console;
2. Create a new GPO (or edit an existing), and link it to the appropriate Active Directory OU. Then right-click GPO and select Edit;
3. Depending on the target registry hive (HKEY_LOCAL_MACHINE / HKEY_CURRENT_USER), registry settings can be applied through the Computer or User Configurations GPO sections.
4. In this example, we are going to change the value of the SearchOrderConfig parameter under the HKLM\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ DriverSearching registry key. To do this, you need to expand the following GPO section: Computer Configuration > Preferences > Windows Settings > Registry. Select New > Registry Item;

   

5. Manually specify the hive name (see list below), key path, value name, type, and data;
   Important. The following registry hive names can be used:
   HKEY_CLASSES_ROOT (HKEY_LOCAL_MACHINE\ Software\ Classes);
   HKEY_CURRENT_CONFIG (HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Hardware Profiles\ Current);
   HKEY_LOCAL_MACHINE;
   HKEY_CURRENT_USER (HKEY_USERS\.Default will be used if you’ll set HKCU registry key using Computer Configuration Policy);
   HKEY_USERS — affects individual user profiles.
   

   

6. Select the GPP action.
   As mentioned earlier, GPP is the primary method for managing registry settings in most environments. There are four types of actions available, but in most cases you will use:
   Update (default) — updates the value if it exists or creates it if it doesn’t (most commonly used)
   Create — creates a value only if it doesn’t exist
   Replace — recreates the entire key/value (use with caution)
   Delete — removes the key or value
   

   

   Note. Registry Preferences are not enforced in the same way as Administrative Template policies. In most cases, preference items write values to the registry but do not prevent users/apps from changing them later.
7.  The Common tab allows you to configure other useful GPO options:
   Run in logged-on user’s security context — allows to create registry parameter with the current user permissions. If the user doesn’t have local admin permissions, the policy will only apply to the HKEY_CURRENT_USER hive (but not to the HKEY_LOCAL_MACHINE);
   Remove this item when it is no longer applied — if you unlink GPO from the AD Organizational Unit, the changed registry item reverts to its initial state;
   Apply once and do not reapply — apply policy only once to each computer;
   Item-level targeting — can be used to apply the registry value to users or computers at a granular level (according to computer settings, AD group membership, Active Directory site, time range, etc).
   

   

8. The final report with the registry settings in the GPMC console looks like this:
   

   

9. This registry parameter will be applied to all computers or users in the target OU after the next GPO update cycle. You can manually update the GPO settings on the client device using the gpupdate /force command.
   Note. Group Policy Preferences are not applied instantly. By default, domain computers refresh Group Policy in the background approximately every 90 minutes with a randomized offset. User-related registry preferences may require the user to sign out and sign in again, while some computer-related settings may require a restart. If you need to apply the changes immediately, run gpupdate /force on the target device.

When possible, you should avoid deploying security-sensitive Windows settings directly through registry preferences if an equivalent Administrative Template policy exists. Keep in mind that Administrative Template policies provide better reporting, policy enforcement, and long-term maintainability.

Security note. Group Policy Preferences registry settings are stored as XML files (for example, Registry.xml) within the SYSVOL folder on DCs. By default, SYSVOL contents are readable by authenticated domain users. Because of this, you should never use Registry Preferences to deploy sensitive info (such as passwords, API keys, access tokens, private keys, connection secrets, or other confidential data). Any user with domain authentication may be able to read the deployed values from SYSVOL.

Using the Registry Wizard for Legacy or One-Time Tasks

Enterprise note. The Registry Wizard relies on the Remote Registry service. Because Remote Registry is normally disabled on modern Windows systems, we don’t recommend you enabling it solely for occasional Registry Wizard operations as a general enterprise administration practice. You should use the Registry Wizard mainly for one-time/legacy admin tasks. For centrally deploying registry settings, use Group Policy Preferences/another supported endpoint-management solution instead.

You can also use the Registry Wizard to browse the registry on a remote computer and select the registry keys that you want to apply via GPO. This requires the reference remote computer to be online and running the Remote Registry service. Otherwise, you will receive the Network Path not found error. You can run the service manually or with PowerShell:

$remoteservice=Get-Service RemoteRegistry -ComputerName PC2212ba

$remoteservice| Set-Service -StartupType Manual

$remoteservice| start-service

If Remote Registry was enabled specifically for importing the required registry settings and was not previously required by the system, you need to return the service to its previous state after completing the task:

Stop-Service -Name RemoteRegistry -ComputerName PC2212ba

1. Select New > Registry Wizard;
   

   

2. Specify the remote computer name (or IP address). Use the Registry Browser tree to locate and select an existing registry key/parameter;

You can create multiple registry items that you want to apply in a single GPO. If two GPP items change the same registry setting, the item with the higher precedence order will be applied last. You can change the order of the registry items using the up and down buttons at the top of the GPO editor console.

Important. The precedence order described above applies only to Registry Preference items within the same GPO. In real-world AD environments, multiple GPOs may configure the same registry setting. In that case, the resulting value depends on standard Group Policy processing rules (including GPO link order, inheritance, enforced policies, and OU hierarchy). If a registry value is not applied as expected, you should use Group Policy Results (gpresult) or the Group Policy Results Wizard in GPMC in order to determine which GPO ultimately configured the setting.

Note that registry Preferences are processed by the Group Policy Preferences Client-Side Extension (CSE). By default, preferences are refreshed during normal Group Policy processing and periodically in the background.

Troubleshooting Group Policy Preferences

In case a Group Policy Preference does not apply as expected, first you need to run the following command:

gpupdate /force

Then you need to use gpresult/Group Policy Results Wizard in GPMC in order to check if the GPO is in scope and that the expected User or Computer Configuration settings were processed.

On Windows 11 24H2 and later systems with the January 2026 or newer updates, Group Policy Preferences also provide you with more detailed diagnostic info through Event ID 4117. Event 4117 supplements the older Event ID 4098 and identifies the specific preference operation and the resource involved in the failure.

For example, Event ID 4117 can provide details such as:

• the source and destination path when a GPP file operation fails;
• the registry or file operation that encountered an access-denied error;
• the folder involved in a failed delete operation;
• the UNC path involved in a failed Drive Maps preference.

You can check Group Policy Preferences diagnostic events in Event Viewer. For Event ID 4117, check Event Viewer > Windows Logs > Application and look for the relevant Group Policy Preferences event source (such as Group Policy Registry, Group Policy Files, Group Policy Folders, or Group Policy Drive Maps).

For registry preference problems, you need to also verify that:

• The GPO is linked to the correct OU.
• Security filtering and item-level targeting include the affected computer/user.
• The preference is configured under the correct User or Computer Configuration.
• Another GPO is not configuring the same registry value.
• The target registry key and value can be accessed by the security context in which the preference runs.

Keep in mind that Event ID 4117 does not change how Group Policy Preferences are processed. It provides additional diagnostic info when a preference item fails to apply.

Configure Registry Settings in GPO PowerShell

If you prefer automation or need to manage GPOs at scale, you can use PowerShell instead of the GUI. This can be done using the GroupPolicy module installed with the GPMC console.

First, check that the module is installed:

Get-Module GroupPolicy -ListAvailable

Specify the name of your GPO in the following command:

$myGPO=Get-GPO -Name 'gpoW10RegistrySettings'

To create a new registry entry in the GPO Preferences, use the Set-GPPrefRegistryValue cmdlet. If you want to create a registry parameter in the User Configuration section, specify -Context User. If you want to create a registryparameter in Computer Configuration then specify -Context Computer. For example:

Set-GPPrefRegistryValue -GUID $myGPO.Id -Context Computer -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" -ValueName "SearchOrderConfig" -Value 0 -Type DWord -Action Update

Open your GPO in the GPMC graphical console. Check to see if the new registry entry is displayed in the appropriate section of the GPP.

To view the registry settings set by the specified Group Policy Object, use Get-GPPrefRegistryValue:

Get-GPPrefRegistryValue -GUID $myGPO.ID -Context Computer -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching"

Remove a registry entry from a GPO:

Remove-GPPrefRegistryValue -GUID $myGPO.ID -Context Computer -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" -ValueName "SearchOrderConfig"

Delete Registry Keys Using Group Policy

GP Preferences can be used for the removal of a specific registry key or parameter on domain computers.

1. Create a new registry GPP entry in User (or Computer) Configuration > Preferences > Windows Settings > Registry;
2. Use the Registry Browser to select a registry parameter or key you want to remove;
3. Expand the registry key in the GPO console. Open the parameter properties, and change the Action to Delete;
   

   

4. The specified reg parameter will be removed from target computers.

How to Deploy a Windows Registry (REG) File Using GPO

If you have a REG file that contains a large number of registry settings that you want to apply to computers/users, you can deploy it via GPO startup script. This allows you to quickly apply a large number of registry entries from the REG, rather than creating each one manually in GPP.

1. First, export the registry key on the reference computer to a REG file. Open the registry editor (regedit.exe), right-click on the registry key, and select Export. Specify the name of the REG file you want to save the registry key;
   

   

2. You can edit REG file manually using any text editor. Remove empty registry keys, edit parameter values (if necessary), and add new keys or parameters;
   To delete a registry key using a REG file, put a hyphen (–) in front of the registry path. For example:
   [-HKEY_LOCAL_MACHINE\Software\…]
   

   

3. Go to the GPMC console, create a new GPO, and link it to the OU with computers (if you want to apply the parameters from the HKLM registry hive);
4. Go to Computer Configuration > Windows Settings > Scripts (Startup/Shutdown);
5. Click the Add button to add a new Startup script;
6. Click on the Browse button and copy your REG file into this directory (\\domain-name\Sysvol\domain-name\Policies\…);
   

   

7. Specify the following logon script options:
   Script Name: regedit.exe
   Script Parameters: /s your_reg_file.reg
   

   

   This command imports the REG file on each target computer at startup.
   
8. Save changes to the policy;
9. The registry settings from your REG file will be applied to the target computers after the reboot.

In modern environments, you should prefer Group Policy Preferences over REG file deployment because they provide item-level targeting, reporting, easier troubleshooting, and granular management of registry settings.

Change Registry Key Permissions with Group Policy

You can also use Group Policy to assign permissions (ACLs) to registry keys. This feature may be useful if you want to grant a user permission to system-protected registry keys, or if you want to prevent non-administrator users from modifying some keys.

Note that this method is fundamentally different from others: it does not configure values, but controls who is allowed to modify them.

1. Open the GPO;
2. Expand Computer Configuration > Windows Settings > Security Settings > Registry;
3. Right-click and select Add key;
4. Use the built-in Registry Browser to select the local registry key on which you want to modify an ACL. If you want to set permissions for a registry key that is missing on the current computer, install the GPMC snap-in and edit the GPO from the computer that has that key;

   

5. The Database Security dialog will open. Here you can configure the reg key ACL. For example, grant the Full Control (Read + Write + Change) permissions to the registry key for the caWKSPowerUsers Active Directory group. By default, this ACL is not inherited to nested subkeys. Click Advanced > Enable Inheritance to enable permission inheritance;
   

   

6. Save the changes. In the Template Security Policy Settings dialog window, you can force ACL to apply to all subkeys of the target key (Propagate inheritable permissions to all subkeys) or force new ACL only on subkeys that inherit from the target key (Replace existing permissions on all subkeys with inheritable permission). Or, you can enable the “Do not allow permissions on this key to be replaced” option to prevent changing ACL on this registry entry;
   

   

7. Close the GPO editor window and wait for the new permissions to be applied to computers.