Edit Registry for Current User

The following code used to edit the registry for the current user fails when there are multiple users logged on. What is the best way to edit the current user registry for all logged on users?

regset “[HKEY_USERS{(if version of operating system >= “6.0” as version then (name of key whose (value “USERNAME” of key “Volatile Environment” of it as string as lowercase = name of logged on user as string as lowercase) of key “HKEY_USERS” of registry) else (name of key whose (value “Logon User Name” of key “Software\Microsoft\Windows\CurrentVersion\Explorer” of it as string as lowercase = name of logged on user as string as lowercase) of key “HKEY_USERS” of registry))}\Software\Kakapo\Unity]” “AutoStart”=“False”

You should look at the current user key https://developer.bigfix.com/relevance/reference/logged-on-user.html#user-key-of-logged-on-user-registry-key of logged on users and this will allow you to get all the keys for all the logged on users.

The best method to modify the registry for all users is to use Local GPO deployed by BigFix.

See this example: https://bigfix.me/fixlet/details/3741

There are newer tools from Microsoft for working with GPO than in this example, but I don’t have an example using those yet as far as I can remember.

Using Local GPO is nice because it doesn’t require a policy action to be enforced once it has been set on a system. It will be enforced ongoing. It is also the best way to set a setting in such a way that the user can’t change it even if they wanted to, which avoids the problem of the user thinking they can change settings, but then having BigFix flip it right back again, which is confusing to the user.

Local GPO is the only option that will work when a brand new user logs into a system for the first time and have the setting already applied. You can use other methods with a policy action, in which case the new user will not have the setting until the policy action runs for the first time since that user logs into the system. One nice thing though is that the policy action will trigger even if the client is offline / off network, so it does work.

Another great thing is that Local GPO will not conflict with Network GPO. You could get in a situation where BigFix is setting the setting one way, but something else, like Network GPO is setting it a different way. This can cause the BigFix policy action to run over and over again indefinitely.


Another option is to have a task that is a policy action that iterates over all of the user keys that have the setting that needs to be changed, and using relevance, change it every 15 minutes until all user keys are changed.


Another option is to create a BAT file that is generated using relevance with the command to change every registry key that needs to be changed, with relevance so that it only runs when needed. This is a way to change many keys at once without the ability to do loops in relevance.


Another option is to use VBScript or PowerShell or something else that can do looping in a more native way.

More options for the list:

For a one-time edit, use Active Setup to launch a script for each user, one time, on their next logon. https://blogs.msdn.microsoft.com/aruns_blog/2011/06/20/active-setup-registry-key-what-it-is-and-how-to-create-in-the-package-using-admin-studio-install-shield/

(I think this is an under-appreciated method)

To run at every user logon:
Add a script to HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Or

Add a script to the Startup folder beneath the start menu

Or use a Logon Script

1 Like

####Here is a new example task that uses Local GPO using the new Microsoft tools:

https://bigfix.me/fixlet/details/22386

You will notice that this does look for logged in users and in at the logged in users registry hives (even if there are multiple) but this is ONLY to validate that the Local GPO has or has not taken effect. This task does not edit the registry directly and instead applies a Local GPO that will affect all users going forward. I also trigger a gpupdate so that it affects the currently logged in user right away, indirectly changing the current user registry.

The example should only ever need to run on a computer 1 time since every user that logs in after will get the settings applied. If it is taken as a policy action, then it will affect all users, including the first time a user logs in to a newly imaged machine because it should run very early on and only needs to run once.

If I can figure out a better way to check for the RSOP for user Local GPO even when no user is logged in, then I will no longer need the check for users and user registries.

Using a method like this is what I would recommend strongly.

The example item is also available on github: https://github.com/jgstew/bigfix-content/blob/master/fixlet/Internet%20Explorer%20AdBlocking%20with%20EasyList%20TPL%20-%20LGPO%20-%20Windows.bes.xml

1 Like