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.

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:

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:

• Group Policy Administrative Templates Catalog
• Group Policy Settings Reference for Windows and Windows Server. You can download spreadsheets that list the policy settings for computer configurations included in the Administrative template files delivered with Windows operating systems.

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.

• How to view the system registry by using 64-bit versions of Windows

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 10, Server 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: https://console.jumpcloud.com/login.
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: https://console.jumpcloud.com/login. 
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:

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.

Display All Local Users on the Login Window

This policy setting will display all local user accounts on the Windows login screen. See ADMX: Enumerate local users on domain-joined computers to learn more.

Registry Key Location	Software\Policies\Microsoft\Windows\System
Value Name	EnumerateLocalUsers
Type	DWORD
Data	1   In this example, “1” means enabled   and the device will enumerate all local users on the login window.