Registry edit that can call an individual user's SID in Windows?
February 21, 2008 3:28 PM   Subscribe

How do I change a registry value that is user-specific? The location is different on every computer, due to the use of the SID in H_Key Users. Look inside for boring specifics.

Here's what I'm working on, and I'm surprised it takes this much effort to accomplish. We're rolling out Office 2007. What we've decided to do is use the Quick Access Toolbar as a small substitute for simple commands that our users would not like to have to hunt down. That part's figured out.

What's stumped me is a registry edit that I'd like to make. Office 2007 has an option that will put the Quick Access Toolbar beneath the ribbon. I tried to make this option change from the Office Customization Tool, but it doesn't list it as an option.

What I need to do is change the value of:
HKU\(user's SID)\Software\Microsoft\Office\12.0\Common\Toolbars\Word\QuickAccessToolbarStyle

The problem is, each user's SID is different, and I can't find an environment variable for the SID so that every user's computer would modify that registry key.

I've written a batch file that can call the SID and manually change it, but I'd like to integrate it into the OCT setup so the end user doesn't have to run the batch file to set the option.

Any ideas?
posted by Psionic_Tim to Computers & Internet (7 answers total) 1 user marked this as a favorite
GPO to the rescue?

You can definitely disable user customization of QAT, but I'm not sure if that helps you.
posted by mrbugsentry at 3:50 PM on February 21, 2008

I might be misunderstanding the question, but if an environment variable that contains the current SID is available, you should be able to just use HKEY_CURRENT_USER instead of HKU\blahblahblah\
posted by aubilenon at 4:29 PM on February 21, 2008

er I mean, if an environment containing the SID would solve your problem
posted by aubilenon at 4:29 PM on February 21, 2008

I agree with aubilenon.
If you're trying to change registry settings of the current user, you just need to change HKCurrentUser.

If you're trying to do a batch change of all HKU's as part of the installation, that's harder, and I think some kind of batch file (e.g. a bit of vb script) is your best bet. You can add a batch file to the AllUsers startup folder to set this registry setting at logon.

Otherwise, you have to be aware that the SIDs you see in HKU may not include all users for a machine. The Registry for each user is held somewhere in c:\documents and settings\username. I believe (but you may need to check this) that it's in a file called ntUser.dat

this thread on google groups asks something similar to you and contains details on loading and updating other users registrys.
posted by seanyboy at 5:01 PM on February 21, 2008

I think aubilenon is onto it, and barring that, you can also load the default user hive and make a change to that, unload it, and then every new profile that is created on a machine will have the setting in question. It's a bit odd to do, but I've used this a couple of times to great effect.

If making the change in Current User doesn't do the trick, take a look at this, and ignore the actual fix, but pay attention to how you load the test hive, make change X, and unload the hive. The link refers to Windows 2000, but I've used the same method in XP.
posted by Richat at 8:45 PM on February 21, 2008

If your script is running while the user whose user registry entries you want to change is logged on (e.g. as a logon script), just change HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Toolbars\Word\QuickAccessToolbarStyle.

If your script is running from an admin account, and you want to change registry entries belonging to a user that isn't logged on, and you can't find a way to do it using Group Policy, do this:

1. Find the user's profile directory. If it's a machine-local user, this will most likely be C:\Documents and Settings\username. If it's a domain user with a roaming profile, it will be that user's profile directory on the server.

2. Edit the user's registry hive file in your script, like so:

set username=whatever
set profdir=C:\Documents and Settings\%username%
set key=Software\Microsoft\Office\12.0\Common\Toolbars\Word
set val=QuickAccessToolbarStyle
set type=REG_DWORD (or REG_SZ for string data, I didn't look it up)
set data=1 (or "1" for string data)
reg load "HKU\%username%" "%profdir%\NTUSER.DAT"
reg add "HKU\%username%\%key%" /v "%val%" /t %type% /d %data%
reg unload "HKU\%username%"

When the user next logs on, the altered value will be loaded under HKEY_USERS\{sid} and HKEY_CURRENT_USER along with the rest of their user registry hive. Note that the reg load step will fail if the user is already logged on to the machine that's running that script. Note also that if the user is logged on somewhere else and you edit the hive file in the server copy of their profile using the above technique, your edit will almost certainly be overwritten when they log out, since their locally cached copy of the hive file will get written back to the server profile when that happens.

If you want to take a stab at this using Group Policy, and you can't find an existing policy setting that does the job, you may need to create a custom Administrative Template. I just did this recently because I had a need for several of the workstations in the school library to auto-logon when started, so the details are still fairly fresh in my mind. Post back if you're interested in following up that approach. It's not terribly hard, and the only tools you need are the existing Group Policy management console and a text editor.
posted by flabdablet at 1:49 AM on February 22, 2008

By the way: for my own automated rollouts, I use a very simple batch file technique. I have two batch files: machine_update.bat, which gets called from the Windows startup script, and user_update.bat, which gets called from the logon script (I use the same logon script for all users).

Near the start of machine_update.bat, I create a flags folder if it doesn't already exist:

set mflags=C:\StMary
if not exist %mflags% mkdir %mflags%
set run=start "Waiting..." /wait

The rest of machine_update.bat is in stanzas with very similar structures to each other. For example, the stanza that installs Microsoft Office 2000 looks like this:

if exist %mflags%\Off2k goto FoxtRdr2
rem Installing Microsoft Office 2000...
set msi=P:\Installers\Microsoft\Office\2000\Disc-1\DATA1.MSI
%run% msiexec /i "%msi%" /qn
%run% regedit /s P:\Installers\StMary\Off2K\kill-outlook-icon.txt
set msi=P:\Installers\Microsoft\Office\2000\Disc-2\DATA2.MSI
%run% msiexec /i "%msi%" /qn
del /q "C:\Documents and Settings\All Users\Start Menu\Programs\Startup\Microsoft Office.lnk"
type nul >%mflags%\Off2k

if exist %mflags%\FoxtRdr2 goto MozDef
rem Installing Foxit Reader 2.0 PDF reader...

etcetera. The idea is that each stanza in machine_update.bat tests for the existence of a particular zero-length file in the machine's flags folder, skipping the guts of the stanza if the file already exists, or Doing Stuff and then creating the file if it doesn't. To roll out new software, I just add more stanzas to machine_update.bat. I prefer this to using Software Update Service because (a) I can see it working (b) I can use any installer or none, not just MSI (c) all my workstations are supposed to be configured the same way and I have no need for more complexity.

user_update.bat is structured very similarly, except that it knows about two flags folders: %mflags% is the same folder as in machine_update.bat, and %uflags% is in the user's own local profile. The stanzas in user_update.bat check for the existence of %uflags%\specificfile and skip if it's already there, then check %mflags%\specificfile and skip if it's not there, then do whatever user-profile-related first-time configuration is needed, then create %uflags%\specificfile.

If I needed to do what you're doing, I'd just have to put a stanza in user_update.bat that uses the reg command to add the value I wanted under HKCU\Software... provided this hadn't already been done.
posted by flabdablet at 2:21 AM on February 22, 2008

« Older Is it ever okay to directly contact the other...   |   healthy ears Newer »
This thread is closed to new comments.