Create Your Own Windows Policy Using Registry Keys

If your team needs a Windows policy that isn't currently available in JumpCloud, you can use the JumpCloud Advanced: Custom Registry Keys Policy to manage the specific registry keys you need all in one place, and see which systems have the registry changes applied. Creating your own Windows policy has these additional benefits:

  • Makes the transition from AD to JumpCloud’s directory-as-a-service more seamless. If you’re used to managing systems in AD using GPOs, JumpCloud’s policies will seem very familiar.
  • Provides a higher level of assurance that your changes are applied compared to running a one-time command. If a system is offline and you run a command to configure a registry key, the changes won’t apply. However, if you create a policy and apply it to a system that’s offline, it’s applied as soon as the system comes online. Using a policy lets you easily verify that the systems needing policies are secured.
  • All of the registry keys you can set in this policy can also be set using the JumpCloud PowerShell module. To edit a registry programmatically, you must be experienced with coding. For advanced users, refer to the Microsoft documentation on Creating a Named Registry Value Using PowerShell and VBScript.
  • It is possible to have multiple custom Windows policies, as long as the registry keys are unique. For more information, see Windows Policy Conflicts.


This policy is only supported on Windows 10Windows 11Server 2016Server 2019, and Server 2022.


Windows operating systems cannot function without a registry. A registry with erroneous data can cause the system to perform poorly, incorrectly, or not at all. Because of the central role played by the registry, it’s essential that you’re familiar with managing Windows systems using registry keys before making any modifications. We don’t recommend you experiment with the registry or change any settings if you don’t understand them completely.

Disclaimer: JumpCloud isn’t responsible for damage to systems that you may cause with your custom policies. We recommend you carefully test your custom policies before applying them to live systems.

Anatomy of a Registry Key

The registry is a hierarchical database that stores the values of variables in Windows and the applications and services that run on Windows. Registry keys are the base unit of organization in the registry and can be compared to folders in File Explorer.

  • A key can have sub keys, just as a folder can have subfolders.
  • Each key can also have multiple values associated with it just as a folder can have multiple files in it.

Values are used to store the information - for example, information about an application installed on a system such as color settings, screen location and size, or recognized file extensions.

Let’s look at a key you can use to control if your users can install extensions for Chrome.


All keys have four components that you must specify, including:

Registry Key Components

Component   Description In our example

A valid root directory where the data is located within the registry structure.

All keys in this policy are in the HKEY_LOCAL_MACHINE (HKLM) hive and you don’t need to specify this.

  • We recommend referencing locations that start with SOFTWARE\Policies.
  • There’s a 255-character limit.
  • Key names are not case sensitive.


  • Software\Policies\Google\Chrome\BlockExternalExtensions
  • Software\Microsoft\Windows\CurrentVersion\Policies\System

HKLM is the root hive and is implied

    Software is the root key

      Policies is the sub key

       Google is the next sub key

         Chrome is the last sub key 


The name of the value for the registry key being modified.

  • You can’t leave this empty.
  • There’s a 99-character limit.
  • Key names are not case sensitive.

A description of how the Data is formatted.

You can select from the following types we support:

  • SZ
  • QWORD 

For a description of all types, refer to the Microsoft documentation on Windows registry information for advanced users.


Specifies that Data is a 4-byte long number (a 32-bit integer). This type is displayed in Registry Editor in binary, hexadecimal, or decimal format.


A number, text string, or array that you use to enable a setting or specify a value, dependent on the Type you select. Enter multi-string values as new lines of text.

  1. We recommend limiting the size of all data values to 2K.
  2. Learn about Microsoft’s formatting requirements.

0x00000001 (1)


0 = False (The user can install Chrome extensions.)

1 = True (The user can’t install Chrome extensions.)

How Do I Know Which Registry Key to Set?

Usually, when you make a change to a group policy object, Windows creates or modifies registry values. If you want to find out what registry settings are being changed for Windows policies you have in place, there are a few ways to do it:

  • Group Policy Search website. Under the Details section, you see the registry key that’s being modified right next to the Registry Key heading. The registry value name is specified right next to the Value heading. For the value data, you will find it at the bottom of the Explanation section.
  • Get-GPRegistryValue is a PowerShell cmdlet that retrieves one or more registry-based policy settings under either Computer Configuration or User Configuration in a Group Policy Object (GPO).

If you don’t have policies in place yet or aren’t sure what to use, you can find information on the registry keys in the following ways:

Keep in mind that you can also use Registry Editor to view and export keys to see what you should use when specifying the key location, value, data, and type.


We’ve also provided some examples of common registry keys at the end of this article for your reference.


Changing registry settings can produce unexpected, contradictory, or uninterpretable instructions in the operating system and application programs. Editing registry settings can also degrade the performance of your system, obscure the location of essential files, or invalidate your Windows licensing agreement.

Best Practices

You should use the following procedures that our developers and testers prescribe because they produce the best results when working with Windows Custom policies. If you comply with these practices and encounter issues, refer to the Troubleshooting section.

Avoid conflicting policies. We recommend checking the policies that you’ve already applied to your systems before applying custom policies. For best results, and due to the complex nuances of registry keys, we recommend you choose to use either custom policies or the standard JumpCloud policies, but not both. This precaution ensures that your policies aren’t conflicting with each other or using the same registry key.

If you previously created a standard policy and then create a custom policy that conflicts, you experience the following behavior:

  • Standard policies override custom policy settings after about 10-20 minutes.
  • This timer starts when a custom policy is applied or whenever the agent is restarted on a system.

If there are no conflicts, all policies are applied.

Don’t create duplicate policies. If you’re using a standard policy that you think might be configuring the same registry key that you want to use in a custom policy, we recommend the following actions:

  • Choose between using a standard JumpCloud policy or a custom policy, not both
  • Remove the standard policy first, then apply a custom policy

Don't use the Security\ registry key location. At this time, JumpCloud doesn't support keys in this location with this policy. 

  • To better understand security policies, you can find more information on the Security Option settings in Local Security Policy editor (secpol.msc) in Microsoft’s documentation on Security Options.

Before you begin

  • Meet system prerequisites.
    • This policy works on Windows 10Server 2016 and Server 2019. Attempting to apply it to any other versions won’t work.
    • Enable Powershell – disabling pwsh prevents policies from being applied.
  • Plan on testing. We recommend you always test a newly created policy in a test environment before you apply it to your entire organization. If that isn’t possible, then test your custom policy on a single system before you apply it to all systems and system groups.
  • Enforcement at the system level. Custom policies are applied to systems, not users. When you apply a custom policy to a system, this policy is enforced no matter which user is logging in to use the system.
  • Deleting custom policies. When you delete a custom policy the behavior you see depends on the location of the key in the registry. The key value is either deleted or left intact. For details, see Deleting Custom Policies.

Create a custom Windows Policy

To create a custom Windows policy:

  1. Log in to the JumpCloud Admin Portal:
  2. Go to Policies.
  3. Click (+).
  4. On the Configure New Policy page select Windows.
  5. From the list, next to Advanced: Custom Policy click configure.
  6. On the New Policy panel, optionally enter a new name for the policy, or keep the default. Policy names must be unique.
  7. Under Settings, in Registry Key Location, type one of the following first: System\Software\Hardware\, or Sam\ and then add the location. For example, Software\Microsoft\Windows\CurrentVersion\Policies\System.
  8. Under Settings, in Value Name, type a string of characters for the registry key you want to modify. 
  9. Under Settings, in Type, select how the data is formatted.
  10. Under Settings, in Data, type in the string of characters, number, or array as specified in Type.
  11. Under Settings, to add additional values or keys, click add registry key.
  12. To add more registry keys, repeat steps 7-11.
  13. Click the System Groups tab. Optionally, select one or more system groups to apply this policy to. For system groups with multiple OS member types, the policy is applied only to the supported OS.
  14. Click the System tab. Optionally, select one or more system groups to apply this policy to.
  15. Click save policy.
  16. Restart all systems where you apply this policy before it takes effect.

Troubleshoot Custom Policies

Due to the number and complexity of registry keys that Windows provides, JumpCloud can’t detect if multiple policies are using the same registry keys. If you see errors, they probably won’t happen when creating, saving, or applying a custom policy.

  • It’s more likely to see errors only in the event log after the agent attempts to apply the policy on a system and finds conflicts.
  • You may not see errors in the Administrator Portal, and a policy can still have a status of successfully applied even if there are errors in the event log.

Replacing a corrupt registry.pol file

Corrupt registry.pol file
The Group Policy Object Editor stores registry-based configuration settings in the Registry.pol file. If a system gets into a bad state, you can re-create the file.

To replace a corrupt registry.pol file:

  1. Find the registry file: C:\Windows\System32\GroupPolicy\Machine\Registry.pol
  2. Rename or delete the registry.pol file.
  3. Restart the system or to re-create the file, run gpupdate /force

Checking the Administrator Portal for errors

To check the Administrator Portal for errors:

  1. Log in to the JumpCloud Admin Portal:
  2. Go to Policies.
  3. Select the custom policy you created.
  4. On the custom policy’s Settings screen, select the Status tab.

Checking the JumpCloud agent log file for errors

To check the JumpCloud agent log file for errors:

  1. Log in to the local system.
  2. Open the following file: C:\Windows\Temp\jcagent.log
  3. When a custom policy is causing errors, the event log lists the following Event IDs:
  • 1125: The processing of Group Policy failed because of an internal system error. Please see the Group Policy operational log for the specific error message. An attempt will be made to process Group Policy again at the next refresh cycle.
  • 1500: The Group Policy settings for the computer were processed successfully. There were no changes detected since the last successful processing of Group Policy.
  • 4657: A registry value was modified.
  • 4660: An object was deleted.
  • 4661: A handle to an object was requested.

Command Argument Limits

In PowerShell a limit of 31744 characters exists.  If this limit is exceeded, the custom policy will not work.
The following error message appears in the logs:

Failed to build command arguments for policy 'custom_registry_keys_policy_windows': Failed to create PowerShell arguments (length 64203) since they exceed the max length of 31744

Delete Custom Policies

When you delete a custom policy the behavior you see depends on the location of the key in the registry. Results can vary from a key existing with no set value, to the value set by the custom policy remaining intact even after deleting the policy

Best Practices

  • Reset rather than delete. We recommend you modify the key’s value to the default or the original, then reapply the policy. You get consistent results that work as expected. If you just remove the entry, you see more variable behavior.
  • You can create one policy instance with multiple unique keys or you can create multiple custom policy instances. If you apply more than one custom policy instance to a system or system group they must have unique registry keys, or they will conflict. For more information, see Windows Policy Conflicts.
  • Know that deleting an entire policy produces variable results.
    • For keys in Software\Policies – deleting the policy deletes the modified value(s) under a key. After you delete this policy, the key still exists but with no values set for the modified entries. For example, a key is added that has five values.
      • If you set two of those five values and then delete this policy, those two values are removed. The other three unmodified values remain in the registry under the key.
      • If you set all five values, the entire key is removed when you delete the policy.
    • For keys in Software\ (other than Software\Policies), System\, Hardware\, or Sam\ – deleting this policy leaves the registry key intact as it was set in the policy.
      • In this case, any values set by the policy are not reset.
      • If you’d like to reset the values, you need to do it manually. Either re-apply the policy with the original values for the key or edit the values in the Registry Editor.
    • Deleting a row entry.
      • For keys in Software\Policies – the entry is removed from the system. In this case, the key exists and may or may not have value(s). This depends on whether the key has multiple values and how many you set for the key. See the example in Deleting an Entire Policy.
      • For keys in anything other than Software\Policies – the modified row remains in the system’s registry as it was set in the policy.
        • If you’d like to reset the values, you need to do it manually. Either re-apply the policy with the original values for the key or edit the values in the Registry Editor.

Registry Key Examples

If you don’t have policies in place yet, you can use the following examples to see how some commonly used registry keys are set. For complete details on using a registry key, see the documentation linked in the key’s description.

Chrome Registry Keys

Extension management settings

This key maps an extension ID or an update URL to its configuration

  • A default configuration can be set for the special ID “*”, which will apply to all extensions that don’t have a custom configuration set.
  • Forced installation is limited to apps and extensions listed in the Chrome Web Store.

For details on schema and more, see Google’s Chrome Enterprise Resource documentation on Extension Settings.

  Registry Key Location  Software\Policies\Google\Chrome\ExtensionSettings
  Value Name  ExtensionSettings
  Type  SZ (text string)
  Data  Examples in Extension Settings documentation

Block External Extensions

Enabling this setting blocks external extensions from being installed and disabling this setting or leaving it unset allows external extensions to be installed.

  • External extensions and their installation are documented in Chrome’s Developer documentation on external extensions.

For details on schema and more, see Google’s Chrome Enterprise Resource documentation on Block​External​Extensions.

  Registry Key Location  Software\Policies\Google\Chrome\BlockExternalExtensions
  Value Name  BlockExternalExtensions
  Type  DWORD
  Data  0x00000001 (1)
  In this example, “1” means disabled
  and the user can’t install external extensions to their Chrome browser

Windows Registry Keys

Disable Automatic Restart Sign On

This key controls whether the user is automatically signed in and the session is automatically locked with all lock screen apps configured for that user when the device starts​.

  • This only occurs if the last interactive user didn’t sign out before the restart or shutdown.​
  • This policy is only applicable to Windows Update restarts. If you don’t configure this policy setting, it’s enabled by default.

For complete details on settings, see the Group Policy Search website documentation on DisableAutomaticRestartSignOn.

  Registry Key Location  Software\Microsoft\Windows\CurrentVersion\Policies\System
  Value Name  DisableAutomaticRestartSignOn
  Type  DWORD
  Data  1
  In this example, “1” means disabled
  and the device won’t sign in and lock the last interactive user
  automatically after a restart.
Back to Top

Still Have Questions?

If you cannot find an answer to your question in our FAQ, you can always contact us.

Submit a Case