/build/static/layout/Breadcrumb_cap_w.png

Active Setup

Hi I need help with Active Setup. I can create a key that goes into HKLM\SOFTWARE\Active Setup\Installed Components\ that runs a script to create the reg keys I need for each user logging in but I dont have a wise script to call. Anyone have one?

0 Comments   [ + ] Show comments

Answers (21)

Posted by: kardock 12 years ago
Second Degree Green Belt
0
why wise script? i always use a vbs.
Posted by: dmack 12 years ago
Senior Yellow Belt
0
The client says to use wise script only. Can I do this right inside the MSI?
Posted by: ogeccut 12 years ago
Black Belt
0
Can you call active setup from msi?
Posted by: dmack 12 years ago
Senior Yellow Belt
0
do someone have a vbscript?
Posted by: kardock 12 years ago
Second Degree Green Belt
0
go the easy road. have your active setup run "regedit /s your_reg_file.reg"

you do not need a script if your goal is only to create some reg keys.
Posted by: dmack 12 years ago
Senior Yellow Belt
0
you're right, I will have stubpath be like this "C:\Windows\reg.exe IMPORT (reg file path)
Posted by: andys0123 12 years ago
Orange Senior Belt
0
Put the HKCU entries in the MSI and use 'msiexec /fu {productcode} /qn' as the active setup StubPath to rewrite the user specific reg keys.
Posted by: anonymous_9363 12 years ago
Red Belt
0
The client says to use wise script only.Then they are clearly unaware that Wise is dead in the water. Yes, I know Flexera have subsumed Wise and will be supporting WiseScript at some point in the future (they say) but any fool can see the writing on the wall. It's your responsibility as the packaging "expert" to guide your client so that they do't end up -sorry, remain - in a technological back-water.
Posted by: dmack 12 years ago
Senior Yellow Belt
0
I agree with you VBScab. I did actually recommend vbscript (as a wrapper) and they said no to that too. Not much else I can do...anyway thanks for the responses.

Actually one more thing, how do you give permissions to for the active setup key to write to the reg if it is locked down? Setacl.exe was used before for win xp but what can i use for windows 7?
Posted by: anonymous_9363 12 years ago
Red Belt
0
Huh? The package will- should- execute at deployment time in System context and so shouldn't need any extra permissions. The HKCU element definitely doesn't need permissions since it is the logged-in user's hive.
Posted by: dmack 12 years ago
Senior Yellow Belt
0
Package wont always run with System account, sometimes it will be manually run by a technician....so I need to give permissions for the reg key to write to Local Machine to get the active setup stubpath in. Any ideas?
Posted by: dmack 12 years ago
Senior Yellow Belt
0
For the manual silent install the UAC prevents the reg key to be written to HKLM. UAC needs to be on for this client too so my question is, is there a way to bypass UAC?
Posted by: jmaclaurin 12 years ago
Third Degree Blue Belt
0
No, otherwise it would defeat the purpose. UAC should prompt to elevate permissions at the time the MSI it is run if run manually, otherwise put your command in a CMD file and you can run that as administrator. If the technician is an administrator on the machine, all they need to do is click yes when UAC prompts.

In the case of an active setup, I believe you should limit its contents to the user's profile and I'd also suggest you don't open up file/reg locations permissions in an attempt to bypass UAC. HKLM entries should be included in the original install.
Posted by: dmack 12 years ago
Senior Yellow Belt
0
Sorry it was being written but because it is win 7 64bit it gets written to wow6432node hive...

still is there an exe for win 7 that can give perms to registry? again i used setacl.exe before but it wont work on win 7...
Posted by: kardock 12 years ago
Second Degree Green Belt
0
try subinacl.exe
Posted by: andys0123 12 years ago
Orange Senior Belt
0
If being run manually, the technician will need elevated rights to write to keys under HKLM. Whether it's installing the MSI or running some program to grant permissions to a key under HKLM (to allow them to install the MSI!) they will still need elevated privileges.
Posted by: Matias M Andersen 12 years ago
Senior Yellow Belt
0
To set permissions on the ActiveSetup key in HKLM will still require elevated rights, and I wouldn’t recommend giving users write permissions to this key for obvious reasons.

As "andy0123" writes, build a MSI with the HKCU keys and add the ActiveSetup key in HKLM as well. One MSI to rule them all ;). Deploying in System context will work out of the box, hopefully technicians have permissions to bypass UAC and install the MSI. (Disable UAC is not an option).
Posted by: anonymous_9363 12 years ago
Red Belt
0
Disable UAC is not an optionWhy not? It was designed to prevent home users from inadvertently allowing programs that might be malicious to run. In a properly locked-down corporate environment, there will be controls and permissions in place which can be controlled centrally, making UAC redundant.
Posted by: Matias M Andersen 12 years ago
Senior Yellow Belt
0
A "properly locked-down corporate environment" should never have UAC disabled. UAC is a vital part of the "Properly locked-down" sentence. Get to know UAC, harness its powers, and it's going to be one of your most powerfull tools to protect your workstations.
Posted by: jmaclaurin 12 years ago
Third Degree Blue Belt
0
UAC = blame shifting

You clicked Yes, so now we don't have to fix the OS.
Posted by: Arminius 12 years ago
Second Degree Green Belt
0
Why not use an advertised shortcut? Rather than making something to script, let the MSI take care of it for you.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ