I have an application plug-in that installs keys in HKCU that I need to get into HKCU of whoever logs in to use app. even if I import a reg file into HKCU it doesn't work. What I have found is that I need to put the entries into the HKEY_USERS\SID for the current user. How can I find the SID of the user logging in so that my script can copy the keys in?

Thanks in advance
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I HOPE I UNDERSTAND WHAT YOU ARE TALKING ABOUT.

HKCU ENTRIES GET AUTOMATICALLY POPULATED/REPAIRED/REINSTALLED WHENEVER A NEW USER LOGS ON TO THE SYSTEM.
Answered 11/12/2004 by: oofemioo
Blue Belt

Please log in to comment
0
oofemioo is right (or nearly).

The HKCU keys should be written when a user first uses an application assuming he uses a valid advertised entry point (shortcut), and that the component(s) containing the keys have a valid (non-existant) HKCU-based keypath.

If your application doesn't include an advertised entry point, you might want to create a dummy advertised shortcut in the "Startup" folder that advertises the feature that contains your HKCU component(s).
Answered 11/12/2004 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
WiseUser

Thanks for your suggestion, the question is how? As I understand it I can only create a shortcut in my MSI to a file that exists in the MSI. I created a new shortcut as suggested which triggers the cu registry bits I need but it also tries to launch the file I had to point to create the shortcut in the firstplace.

Suggestions on a postcard PLEASE!!

Gazza
Answered 11/17/2004 by: glwday
Orange Belt

Please log in to comment
0
Sorry Gazza, I'm fresh out of postcards!!

If you're talking about the "dummy" shortcut I referred to, you're right that it will launch the target file. The point is that the target executable shouldn't do anything. You can create an empty ".exe" with VB, or simply use a blank vbscript as the target file.
Answered 11/17/2004 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Wiseuser

Thanks for the e-postcard.

Your suggestion with a blank.vbs file works a treat

Cheers
Answered 11/18/2004 by: glwday
Orange Belt

Please log in to comment
0
Glad I could help.

The only potential issue with the empty vbscript is that you are relying on the scripting host engine and the ".vbs" file association. Some companies deliberately sabotage their scripting host as a precautionary measure.

You should know where your package will be deployed, and whether this will be an issue or not.

I like to keep a dummy ".exe" file in my collection of utilities for this purpose. If you're not a programmer, ask somebody you know to create one for you (it only takes a minute). All it needs is a main procedure that immediately ends the program - no forms required.

Another option might be to use an existing system executable that doesn't do much, and is protected so that you won't break it. Lights.exe seems to work well, and it's protected so you can't overwrite it or remove it. Be careful what you use though.
Answered 11/18/2004 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity