This article covers deploying registry changes from a Worklet, including the two behaviors that most often make a registry Worklet report success while nothing actually changes on the device, and a pure PowerShell import method for environments where the built-in registry handlers are blocked.
Start with reg.exe
In most environments you do not need a custom import script. Copy the .reg file to the device and import it with the built-in tool in your Remediation Code:
reg import "C:\ProgramData\amagent\YourFile.reg"
If you use regedit.exe instead, always include the silent switch, otherwise it waits for an interactive confirmation that never comes and the command eventually times out:
regedit.exe /s "C:\ProgramData\amagent\YourFile.reg"
Add your own error handling. These tools frequently return a success code even when the import did not apply, so a Worklet that only checks the exit code will report success regardless. Verify the value after writing it and fail explicitly if it is not there:
reg import "C:\ProgramData\amagent\YourFile.reg"
$check = Get-ItemProperty -Path "HKLM:\SOFTWARE\YourKey" -Name "YourValue" -ErrorAction SilentlyContinue
if ($null -eq $check) {
Write-Output "Import did not apply the expected value."
exit 1
}
Write-Output "Verified: value is present."Worklet reports success but the registry is unchanged
This is the most common outcome and it has two causes.
The 32-bit registry view
Worklets run PowerShell in 32-bit mode. On 64-bit Windows, a 32-bit process writing to HKLM\SOFTWARE is transparently redirected into HKLM\SOFTWARE\WOW6432Node. The write succeeds, the command returns success, and the key you were targeting in the 64-bit hive is untouched. A script that works when you run it yourself will fail this way as a Worklet.
To act on the 64-bit registry, wrap the code in a script block and run it through the 64-bit PowerShell:
$scriptBlock = {
# Registry code goes here
New-Item -Path "HKLM:\SOFTWARE\YourKey" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\YourKey" -Name "YourValue" -Value "Data"
}
if ($env:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
& "$env:WINDIR\SysNative\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -Command $scriptBlock
} else {
& $scriptBlock
}See Requested Registry Access is Not Allowed for more on this behavior.
HKCU resolves to the wrong user
Worklets run as the SYSTEM account. HKEY_CURRENT_USER is not a fixed location, it points at the profile of whichever account is running, so under SYSTEM it resolves to the SYSTEM account's own hive rather than the signed-in user's. A .reg file containing HKEY_CURRENT_USER entries imports cleanly and applies to nobody who will ever notice.
There are two established approaches:
- Write to the user's hive under
HKEY_USERSby resolving their SID, rather than relying onHKCU. See Modify registry key value under HKEY_USERS / HKCU workaround. - Have the Worklet create a scheduled task that runs in the user's own context at logon. See Create scheduled task to run at user log on as the user.
Both are community-contributed examples rather than Automox features, so review and test them before deploying broadly.
Evaluation code
Setting the Evaluation Code to exit 1 makes the Worklet report every device as non-compliant every time, so the remediation is always eligible to run. Prefer a check for the value you intend to set, so devices report compliant once the change is in place:
$value = Get-ItemProperty -Path "HKLM:\SOFTWARE\YourKey" -Name "YourValue" -ErrorAction SilentlyContinue
if ($value.YourValue -eq "Data") {
exit 0
} else {
exit 1
}Remember that evaluation code runs on every device scan, so a permanently non-compliant evaluation means the remediation is repeatedly re-applied.
Importing when the registry handlers are blocked
If reg.exe and regedit.exe are blocked from executing in your environment, the script below performs the import in pure PowerShell by translating the .reg file into registry commands.
Two things to be aware of before using it. It is third-party code included here for convenience rather than an Automox feature, so it falls outside the scope of Automox Support. It is also written as a standalone script that accepts a file path as a parameter, so pasting it directly into Remediation Code will not run against anything. Adapt it by setting the target path directly in the script body instead of relying on a parameter or on the script root, since neither is available in the Worklet execution context.
The same 64-bit and SYSTEM account behavior described above applies to this script as well.