I'm trying to modify registry entries within HKCU at logoff. The corresponding script works okay when invoked manually. I was afraid there might be issues with a loopback policy kicking in, but according to rsop.msc this is not the case, i.e. the script should be executed. However, the desired effect in the registry is not there upon next login.

Is there a general problem simply because the script runs "too late"? If so what can be done? What else could this be?

EDIT: I should have specified what my logoff.vbsscript looks like (minimalized):

const HKCU = &H80000001

Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
' ...
oReg.SetStringValue HKCU,"SOFTWARE\Foo","Bar", "Baz"

3 Answers 3


I use Logoff Scripts fairly frequently. The user's registry is still loaded when the script runs and modifications can be made to their registry. Logoff scripts run synchronously, by design. I have logoff scripts that read from the user's registry but I've never had occasion to write. Even so, I expect it would work fine.

I took your code snippet above, put it in a file and assigned it as a Logoff Script in Local Group Policy on a Windows XP SP3 VM, and obtain the desired result. I set HKCU\Software\Foo\Bar equal to xxx, logged-off, logged-on again, and found that the value had been changed to Baz, as-expected.

I think you're having some other kind of problem, aside from script execution. I added a MsgBox call to the code so I could "see" the code running on logoff. Adding the MsdBox did not change the registry-related behavior but did give me a visual indication the code was running (and held-up logoff until I dismissed the dialog).

(I can go ahead and test on Windows 7, too, if you'd like but I anticipate no change in functionality.)

  • OK, I'll test with MesgBox (was afraid because of the registry problems that the skript might run after the user loses GUI) Mar 1, 2013 at 17:02

I imagine you are using reg.exe for modify registry entries. The problem is that reg.exe runs in a separate process, and logoff script only wait for itself to finish. So it's likely that registry hive gets unloaded before the edit gets done.

I think you can solve the issue using two rows of WScript, like the following example:

Set objShell = CreateObject("WScript.Shell")
objShell.Run "REG ADD HKCU\key ...",,true

The third parameter of objShell.Run, called bWaitOnReturn, tells the script to wait for the external process to complete before continuing the execution.

  • Thanks, but I guess (see my edit) I don't run a separate process anyway Feb 26, 2013 at 12:19

There were actually two problems.

Firstly, in the presence of loopback policy one must be careful with rsop.msc because just using the default (i.e. ticking "jump to the last page of the wizard without collecting more data" right after selecting user and computer containers) may not reflect the true policy results. One must at least tick loopback on the second page (and replace or merge) to obtain realistic results. Being careful here helps diagnozing correctly if the script would be run at logoff.

Secondly, SetStringValue creates values if they don't exist before, but it does not create non-existing keys. Therefore,

oReg.CreateKey HKCU,"SOFTWARE\Foo"

must be issued in the script (for the record, CreateKey does create non-existing keys recursively, but of course "HKCU\SOFTWARE" is already there).

  • In the future, I suggest you use gpresult or Group Policy Management Console (GPMC) rather than RSOP.msc. RSOP is no longer updated since Vista and is not aware of many settings. Either use gpresult /h outputfile.htm or GPMC's Group Policy Results for more accurate output. See blogs.technet.com/b/askds/archive/2011/02/11/… Mar 3, 2013 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .