Windows - System Preferences - Modify HKEY_USERS

What the HKEY_USERS registry modifier does

This Automox Worklet™ writes a registry value into every active user's hive under HKEY_USERS on a Windows endpoint. Most per-user policies target HKEY_CURRENT_USER, which only resolves for the account running the script. This Worklet works one level up: it enumerates local user profiles from Win32_UserProfile, mounts each profile's ntuser.dat under HKEY_USERS\<SID>, and applies the configured value, so the setting takes effect for every profile on the endpoint rather than only the account that happened to be signed in when the policy ran.

The script reads four policy parameters: the registry sub-path relative to the user hive (no leading SID), the value name, the desired value, and the value type (String, ExpandString, MultiString, Binary, DWord, or Qword). The Worklet then walks the local profile list, loads each user's ntuser.dat into the registry, writes the value, and reports any per-profile failure separately so an admin can isolate which account rejected the write.

Offline profiles are handled by mounting each user's ntuser.dat from C:\Users\<name>\ntuser.dat with reg load HKU\<SID>, then writing the value through the HKU PSDrive. The script avoids the common HKEY_USERS pitfall where an offline profile silently misses a change and drifts back to the old value the next time the user signs in, because the Worklet reaches the dormant hive directly from SYSTEM.

Why enforce per-user registry values from a central policy

Per-user registry keys control Outlook security warnings, Edge and Chrome managed preferences, Office macro trust settings, OneDrive sync defaults, the Run and RunOnce auto-start lists, Explorer view options, and most vendor-specific configuration paths under HKCU\Software. When those settings live only in HKEY_CURRENT_USER, a Group Policy preference or login script only fires for accounts that actually sign in, which leaves every dormant local account, every shared kiosk profile, and every service account holding a stale value. CIS Benchmarks for Windows 10/11 and Server 2019/2022 explicitly call out HKCU paths in the user-policy section, and the audits expect the value to be present for every profile, not just the one running the script.

Per-user keys drift hardest because each profile is its own surface, and an installer or end user setting change can revert a CIS-required HKCU value silently. A weekly Worklet cadence catches that drift on the next evaluation, applies the value to every loaded SID, and reaches the offline ntuser.dat hives that a Group Policy preference cannot touch until the user signs in. A shared kiosk profile, a service account hive, and a developer workstation with three dormant local accounts all land on the same HKCU value within a single policy run.

How HKEY_USERS enforcement works

1. Evaluation phase: The Worklet queries Get-WmiObject Win32_UserProfile filtered to Special -eq $false and LocalPath -ne $null to identify local user profiles, then registers an HKU PSDrive against HKEY_USERS. For each profile, it checks whether C:\Users\<name>\ntuser.dat exists, runs reg load HKU\<SID> against that hive, and reads the configured sub-path with Get-ItemProperty under Registry::HKEY_USERS\<SID>\<sub-path>. Any profile whose value does not match the desired value is added to a non-compliant list, and the endpoint is flagged for remediation with Exit 1. The propertyType parameter is accepted for parity with remediation but is not evaluated by the evaluation script.

2. Remediation phase: The remediation script walks the same profile list. For each profile, it loads HKU\<SID> from C:\Users\<name>\ntuser.dat, creates the registry sub-path with New-Item -Force when missing, and writes the value with New-ItemProperty -Force -PropertyType <type> -Value <value>. Per-profile failures are caught with try/catch, logged with the resolved username, and increment a failure counter. If any profile failed, the script writes to stderr and exits 2839 so the endpoint stays flagged in Automox activity logs until the underlying issue is fixed.

HKEY_USERS modification requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025 with the Automox agent running as SYSTEM

• PowerShell 5.1 or later (PowerShell 7 supported); reg.exe available on the default Windows PATH for hive load and unload

• Registry sub-path entered relative to the user hive without a leading SID, for example Software\Policies\Microsoft\Office\16.0\Common\Security

• Value type matches the registry expectation: DWord for boolean and integer policies, String or ExpandString for text, MultiString for REG_MULTI_SZ, Binary for REG_BINARY, Qword for 64-bit integers

• Values containing spaces or special characters wrapped in quotation marks so PowerShell parses them as a single argument

• Roaming or redirected profiles are handled by their local copy; for fully roaming environments, pair this Worklet with the Group Policy logon-side equivalent so the change persists at next sign-in

Expected registry state after enforcement

After a successful run, the target value is present and matches the desired data under HKEY_USERS\<SID>\<sub-path> for every local profile on the endpoint that has a ntuser.dat under C:\Users, including profiles that were not signed in at policy run time. Verify with Get-ChildItem Registry::HKEY_USERS to list resolved SIDs, then Get-ItemProperty Registry::HKEY_USERS\<SID>\<sub-path> for each entry. Cross-reference SIDs to usernames with Get-WmiObject Win32_UserProfile | Select-Object SID, LocalPath. The next evaluation pass walks the same profile list, finds the value on each one, and exits 0 without invoking remediation, so the policy can sit on the scheduled patch cycle as a drift guard against installers that rewrite HKCU defaults.

If specific profiles fail, the most common causes are an in-use profile that is holding an exclusive handle on ntuser.dat, a profile with corrupted ACLs on the registry sub-path, or a redirected hive on an unreachable file share. The Worklet logs the failing username so the admin can target that single profile rather than the whole endpoint. Exit code 2839 from the remediation script keeps the endpoint flagged in Automox activity logs until the underlying profile issue is resolved and the next evaluation pass confirms the value across every loaded hive.