Change Remote Registry | Gotchas using HKEY_CURRENT_USER

Change Remote Registry Warmer…warmer…hotter…oh, colder. Sorry.

PDQ Deploy is an excellent tool for not only deploying software but also “deploying” changes to target computers such as: Registry modifications, copying files or just running commands. There are a few gotcha’s, however.

We recently had a question that basically looked like this:

Hi Guys, I am able to locally change a registry via a reg file but when I deploy the change with PDQ Deploy it doesn't make the change. Why? Here is a snippet of the reg file...

One glance at the registry file told us why he was having a problem. The reg file was writing to HKEY_CURRENT_USER. In actuality, the deployment was working. The registry was being modifed it was just changing the HKEY_CURRENT_USER value for a different user than the administrator thought.

First of all, what is HKEY_CURRENT_USER? This is the registry hive which holds keys and values that are respective only the current user. Its values are contained in the hidden file NTUSER.DAT located in the root of the user’s profile directory. Anytime a profile is created on a computer (basically when a user logs on to a computer for the first time) this file is generated and loaded into the registry. When the user logs off, the hive is unmounted.

Let’s say that the user Tony is currently logged on to the machine Accounting12. When Tony logs on, any startup script or user level GPO that references HKEY_CURRENT_USER is referencing the NTUSER.DAT for Tony.

Now let’s say that you are running PDQ Deploy version 1.5 (currently in a public Beta). The account (credentials) that you are using to deploy software is your Administrative account, Dorene_Admin. You are deploying some registry changes by importing a .reg file called CompanyRegistryChanges.REG. 

Change Remote Registry

Dorene_Admin deploys the PDQ Deploy Installer to the computer Accounting12. After PDQ Deploy finds Accounting12 it creates a Windows Service called AdminArsenalRunnerService that loads the installer and begins executing the defined Actions (PDQ Deploy Pro Mode has the ability to run multiple Actions in sequence whereas PDQ Deploy Free Mode can run only one action per installer). But guess what? All the registry changes that affect HKEY_CURRENT_USER are being made against the NTUSER.DAT in…wait for it… the profile for Dorene_Admin. Why? Because according to the regedit.exe process (which is being called to import the registry file) the current user is Dorene_Admin. This is because regedit.exe was executed by the Dorene_Admin account therefore all “user” actions (such as HKEY_CURRENT_USER) or even referencing the variable %UserProfile% will all reference Dorene_Admin. 

So basically when I need to make changes to the HKEY_CURRENT_USER in the registry or the  %USERPROFILE% directory I try and utilize User Level GPO’s. You can, of course, write a script that traverses all the profiles on a target and then loads each NTUSER.DAT and make the changes there but I generally discourage that. It can be done and I have, myself, done this when a GPO wasn’t possible.

A good rule to remember is that PDQ Deploy is primarily meant to deploy changes (Software, Registry settings, commands) to a computer and not to specific users of a computer. Registry changes to HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT and HKEY_USERS are slam dunks.