Multiple StubPath in AcitveSetup?
Heya guys,
Is it possible to have multiple stubpath key's in a single ProductCode with AcitveSetup? Here's the context. I have a package which i need to self heal in order to push a settings.xml file in each user profile. Also, when the user logs in, I want the configuration screen to pop up so they can set up their usernames and passwords.
How would one acheive this? I was thinking something along the lines of having one stubpath to rapair the missing file and one stubpath acting as a sort of RunOnce. I tought about populating the RunOnce itself, but that wouldn't be good since when the user logs in for the first time after the installation, the RunOnce key will be created in HKCU, and the second time he logs it'll be run, so that's not really efficient.
Feel free to pitch in a better idea! I'll keep on reading on possible methods in the meantime.
Thanks
Stephane
Is it possible to have multiple stubpath key's in a single ProductCode with AcitveSetup? Here's the context. I have a package which i need to self heal in order to push a settings.xml file in each user profile. Also, when the user logs in, I want the configuration screen to pop up so they can set up their usernames and passwords.
How would one acheive this? I was thinking something along the lines of having one stubpath to rapair the missing file and one stubpath acting as a sort of RunOnce. I tought about populating the RunOnce itself, but that wouldn't be good since when the user logs in for the first time after the installation, the RunOnce key will be created in HKCU, and the second time he logs it'll be run, so that's not really efficient.
Feel free to pitch in a better idea! I'll keep on reading on possible methods in the meantime.
Thanks
Stephane
0 Comments
[ + ] Show comments
Answers (11)
Please log in to answer
Posted by:
anonymous_9363
16 years ago
Your AS script could write its own registry entry to indicate that it's run (or simply detect the HKCU part) and then branch accordingly. That is, if there's no "I've already run" or HKCU entry (I'm not sure when the HKCU part gets written - at the beginning or on completion), then it would write the RunOnce entry. Windows itself removes the RunOnce entry after execution. Equally, you could avoid the RunOnce stuff if you were to set a "I've already run" entry, as the script could branch according to that setting.
Posted by:
nheim
16 years ago
Hi Stephane,
Self heal runs (hopefully) only once.
Therefore, you could use a custom action (conditioned to run not on install and remove) at the very end of the MSI to start the config screen.
To make it bulletproof, you could put an entry into AppSearch and run it only, if the settings.xml file does not exist.
Regards, Nick
Self heal runs (hopefully) only once.
Therefore, you could use a custom action (conditioned to run not on install and remove) at the very end of the MSI to start the config screen.
To make it bulletproof, you could put an entry into AppSearch and run it only, if the settings.xml file does not exist.
Regards, Nick
Posted by:
Fau
16 years ago
Hello nheim!
Thanks for your reply, unfortunatly, I especially need to run the Configuration screen when the user logs in since he will be the one who will fill in his username and password. So the idea of having it prompt via CA is good, but not exactly what I need (especially if we silent install it!)
what I would like is for my stubpath to look like this:
Name: stubPath
Value "command1";"command2"
Is it possible? If so, how?
Thanks for your reply, unfortunatly, I especially need to run the Configuration screen when the user logs in since he will be the one who will fill in his username and password. So the idea of having it prompt via CA is good, but not exactly what I need (especially if we silent install it!)
what I would like is for my stubpath to look like this:
Name: stubPath
Value "command1";"command2"
Is it possible? If so, how?
Comments:
-
It is possible: Value: cmd /c "command1 & command2 & command3" for example - IHoff 7 years ago
Posted by:
anonymous_9363
16 years ago
ORIGINAL: FauNo, it isn't. You could either go with my monolithic script suggestion or, you could have a literal stub script which then calls down to another script or scripts.
what I would like is for my stubpath to look like this:
Name: stubPath
Value "command1";"command2"
Is it possible? If so, how?
Posted by:
Fau
16 years ago
Your right my friend.
I think I'll go via the stub which calls another script... Not ideal but heh, it'll work!
Thanks!!
I think I'll go via the stub which calls another script... Not ideal but heh, it'll work!
Thanks!!
Posted by:
nheim
16 years ago
Hi Stephane,
i think you should get a closer view at the possibilities of an MSI installation.
This would be no problem with silent install, because you would set an condition to tell the CA not to run on installation and remove. This would make the CA run only in maintenance mode (more or less), which a self heal session is running in.
With this, AS would call the MSI wich then heals itself and at the very end, it would call the config screen.
Everything in the package, no extra script nessecary.
Regards, Nick
i think you should get a closer view at the possibilities of an MSI installation.
This would be no problem with silent install, because you would set an condition to tell the CA not to run on installation and remove. This would make the CA run only in maintenance mode (more or less), which a self heal session is running in.
With this, AS would call the MSI wich then heals itself and at the very end, it would call the config screen.
Everything in the package, no extra script nessecary.
Regards, Nick
Posted by:
jmcfadyen
16 years ago
so are you saying that the settings.xml file needs to be deployed.
then updated to contain the user / password settings (usually done as part of the config screen popup) ?
I would be hesitant to get users to write passwords into an xml file. The vendor needs to be shot if thats the case.
then updated to contain the user / password settings (usually done as part of the config screen popup) ?
I would be hesitant to get users to write passwords into an xml file. The vendor needs to be shot if thats the case.
Posted by:
Fau
16 years ago
ORIGINAL: jmcfadyen
so are you saying that the settings.xml file needs to be deployed.
then updated to contain the user / password settings (usually done as part of the config screen popup) ?
I would be hesitant to get users to write passwords into an xml file. The vendor needs to be shot if thats the case.
LoL
Yeah that's exactly it... You want to know to best part? The go-to guy for tech support...is also the president of the company!!! :-/
But yeah, the username and password is encrypted in the same settings.xml file. What I was hoping to do is *simplify* the users job to only entering is username and password and that's it...
Oh how we LOVE nicely done applications like this one huh? :)
Posted by:
jmcfadyen
16 years ago
i agree with TK and Nick, just for the record you can have as many ActiveSetup entries as you like for a single product.
It is recommended to use the ProductCode however you can put anything you want in there and it seems to work. documentation does differ from that, in actual practice it works fine. There is an active setup API which has a requirement for the GUID however.
It is recommended to use the ProductCode however you can put anything you want in there and it seems to work. documentation does differ from that, in actual practice it works fine. There is an active setup API which has a requirement for the GUID however.
Posted by:
EdT
7 years ago
If you need multiple actions via Active Setup then I would build a script that performs these serial actions and call that script via Active Setup. What you MUST bear in mind is that the Active Setup process is synchronous so if any active setup action hangs, then so does the machine boot process. The script therefore allows you to add error handling and recovery from failures that would otherwise bollix up the machine.
There is of course another simple solution if you are targetting 64 bit operating systems only. There are TWO active setup processes, one in the 32 bit area of the registry, and one in the 64 bit area of the registry. If I recall correctly, the 32 bit area runs first, but it's trivial to test this.
However, I consider having to use Active Setup to be the act of last resort, as you can achieve the same effect within the MSI using self healing.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.