KACE Product Support

Are you running the script as the logged in user (I'm assuming so given the success of 2/3's)? The agent runs as the local system. One other option I could think of is timing; the current user may not have loaded far enough yet to allow writing to HKCU.

Casey

I had actually thought of the possibility of HKCU not being loaded. So I waited until late afternoon when I knew these users had been logged on for hours. I singled out a few of these systems to use as test systems and made sure the users were logged on for long periods of time.
Right now we dont have the ability to run as the logged on user. We'll need an upgrade to the kbox which we are unable to do at this time. So all of the machines have been running scripts as the local system. When I import the registry files or use reg.exe /add on the local machines, the keys and values are added correctly.
Im wondering if its possible that there are hidden permissions in the registry preventing the local system from writing to some of the machines and not to others?

All users have permission to write to their own HKCU, but if the script is being run as the local system, as far as it is concerned, it (local system) is the current user. Without impersonating the current (human) user, I'm not sure HKCU could be written to. One item that might be worth while would be to see if the correct values are being written to the keys on those systems that are reporting success.

Casey

If there is a user logged in then any script can set it. If not then you'll need to use the 5.1 features of running as the current user.

If you really can't go to 5.1 then you could explore a more complicated script to set it when the user logs in -- example set a batch file to "runonce" when the user does eventually log in. Or set a periodic scehdlue on the script combine with only run when the user is logged in and put a verify clause to ignore machines that have already been set.

If that's greek to you then I do recommend an upgrade to 5.1.

Thanks for the replies. Not greek by any means.
Some new veggies to add to the soup: if a different user logs onto one of the failing machines, the script runs and sets the key. Log the original user back on and of course the script fails to write the key. This led me to think it was possibly a profile issue. so we tried blowing out the profile and re creating it by logging the user on. Still fails. I would use a batch file in their logon scripts but I'll still need to solve this using the kbox.
I have followed these directions to mimic running commands as the local system account and it fails there too when run from the local machine.
How to mimic running a script as Local System User
This doesnt seem like a Kbox issue anymore but more of a problem with the users that are logged on that is preventing the local system account from writing to the hkcu hive. I can write to hklm just fine.

when it fails what do you see when you run this script:
http://www.kace.com/support/kb/index.php?action=artikel&cat=5&id=698&artlang=en

Is fast-user switching on?

No fast user switching. These are all member workstation of a windows 2003 domain.

I have found a graceful solution with only one drawback. Some background first.
Apparently, my issue that I am having is not isolated to our organization. The sheer number of newgroup and forum posts that I have found with people having the same issue(not with kbox but with other managing software and scripting as well.)is staggering. Most of the solutions I have found are very complex requiring a substantial amount of code written in VB or other scripting languages, none of which me or my team are familiar with. It appears that there is no real support of the local system account writing to the HKCU hive either from Microsoft.
My solution was to use Microsoft's own Active Setup. Here is how Active setup works:

Active Setup runs every time a user logs on.
This utility compares registry values written in HKLM to those in HKCU. If it does not exist in the logged on users HKCU hive, it writes a copy of the key to the same location in HKCU and runs the executable or batch file specified by the stubpath key value. In this case, stubpath is calling reg.exe with add value switch Parameters. Normally I would include a /f to force the value to be re-written but in this case, I do not want that to happen so that the timestamp for the key and value in the registry is preserved.
The other benefit of running it this way will ensure that it gets written to any new users hive that logs onto the machine.
The drawback to this method is that the final objective(the call from the stubpath value) does not get written to the users hive until the next log on after the script writes the initial stubpath value in HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\NoAutosigOnCustomForms. Again, the upside is, the key will be written to any new users that log onto the machine automatically by Active Setup.
They full registry entry looks like this and was applied using KBox's set registry key and set registry value in remediation.: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\test] "StubPath"="c:\\windows\\system32\\reg.exe ADD HKCU\\Software\\Microsoft\\Office\\11.0\\Outlook\\Options /v NoAutosigOnCustomForms /t REG_DWORD /d 00000001"

I found this information at Bonemans Blog