I had a script that a packager I contracted with gave me, and I lost my backup data. He had a VBS script for writing "logged in user" HKCU keys , while installing under system context. Example: SCCM deployment(system) installing an msi that writes HKCU keys, and add the VBS script to add the keys to the current logged in user, NOT the system account.Any help appreciatedĀ 

thanks and regards,

Alex
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

1
The key may exist under HKey_Users even if the user is not logged in. Also, the solution may depend on whether the user has a local or roaming profile.  Are there no apps in production that use this script that you could recover the script from?

Finally, you don't actually need to log a user off to force active setup. Just kill the explorer tasks and restart explorer.  Generally doesn't get noticed too much by users unless they are actually navigating the file system with an explorer session when it happens.  However, as VBScab mentioned, if there is an advertised entry point in the app, you can use self healing to populate the user profile.  Even if there isn't, it's not that difficult to find a way of adding one.
Answered 05/13/2015 by: EdT
Red Belt

Please log in to comment

Answers

0
Scripts will only be able to write to users that already have profiles created.

The best way is to create a transform for the msi file with active setup:

Details can be found here: http://blogs.msdn.com/b/aruns_blog/archive/2011/06/20/active-setup-registry-key-what-it-is-and-how-to-create-in-the-package-using-admin-studio-install-shield.aspx

Answered 05/12/2015 by: GAKIS
Second Degree Green Belt

  • Right. But I am talking about handling a "logged in" user, assuming the user is logged in. This will avoid me forcing a log-off to trigger active setup, you see what I am saying?

    Back to the script... As I mentioned, I was ready using a .VBS script that could write HKCU keys as the current "logged in" user and not under the context (system account) that the script was running under.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

      That will give you a list of the GUID of all users who have ever logged on. You need to loop through each of those. If the key exists under HKUsers, then that user is currently logged in. Change their settings under that path (HKU\GUIDofcurrentuser is the same as HKCU).
      • This makes sense, have it scripted already by chance? Thx
Please log in to comment
0
"Must resist...can't...give...in..."
"No! Stop! Don't do it!
"I can't...stop...myself! www.lmgt....Nooooooooooooooooooo! Mustn't..."

Anyway, back to avoiding the script at all costs...

If the MSI contains even a single shortcut or other entry-point capable of being advertised, you can convert that to an advertised shortcut and use self-healing to propagate user data. Search for John McFadyen's excellent article on self-healing.

Do it the right way,not the kludged way!
Answered 05/13/2015 by: VBScab
Red Belt

  • "Do it the right way,not the kludged way!"

    Sure, sure, but we can't all run BSD. :p
Please log in to comment
Answer this question or Comment on this question for clarity