Install sequence: "Run another Program First" or task sequences
Hi,
I was hoping to get some experienced input into how to handle multiple application installations that must be installed in a particular sequence.
I'm pretty new to SCCM, but from what I've tested the only options available to do this is either creating task sequences or using the "Run another Program First" option when creating a package\program.
Any preferences?
Thanks,
I was hoping to get some experienced input into how to handle multiple application installations that must be installed in a particular sequence.
I'm pretty new to SCCM, but from what I've tested the only options available to do this is either creating task sequences or using the "Run another Program First" option when creating a package\program.
Any preferences?
Thanks,
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
Posted by:
Jsaylor
15 years ago
Neither option is perfect, they're both bad in various situations.
"Run Another program first" will have problems if the chained prerequisite you're running reports anything other than perfect success. In order to do these properly, you will have to write every one of your programs so that it properly detects success criteria, and reports 0 in almost all cases. As an example, if you're trying to remove an msi before installing another piece of software, and the one you're removing does not exist, the first program will fail if you attempt to call msiexec directly and the program was not actually installed, scuttling your whole program chain.
As mentioned, the Task sequencer can't handle unexpected reboots, so all of your explicitly called programs must have all reboots suppressed or you'll end up in some bad places. You can, however, call the "Restart Computer" task after a task that you would expect to require a reboot, and the task sequencer will not choke on it when the reboot is actually called.
"Run Another program first" will have problems if the chained prerequisite you're running reports anything other than perfect success. In order to do these properly, you will have to write every one of your programs so that it properly detects success criteria, and reports 0 in almost all cases. As an example, if you're trying to remove an msi before installing another piece of software, and the one you're removing does not exist, the first program will fail if you attempt to call msiexec directly and the program was not actually installed, scuttling your whole program chain.
As mentioned, the Task sequencer can't handle unexpected reboots, so all of your explicitly called programs must have all reboots suppressed or you'll end up in some bad places. You can, however, call the "Restart Computer" task after a task that you would expect to require a reboot, and the task sequencer will not choke on it when the reboot is actually called.
Posted by:
ChluainEois
15 years ago
Thanks for the responses,
We will definately be suppressing all reboots so this won't be a problem if we decide to proceed using task sequences.
One thing I have heard about using task sequences is that they cannot run programs that "Run another Program First" - or at least have trouble doing so... is this true?
Thanks again,
We will definately be suppressing all reboots so this won't be a problem if we decide to proceed using task sequences.
One thing I have heard about using task sequences is that they cannot run programs that "Run another Program First" - or at least have trouble doing so... is this true?
Thanks again,
Posted by:
Rheuvel
15 years ago
My previous employer used a VBScript that was launched to handle the prerequisites when run another program first was used.
I don't know what exactly was in the script, but it was basically used to filter all those return codes. The succes rate of the chain installs became a lot higher.
A VBScript is less sensitive. Basically if the script runs it reports success. So all you have to built in is some conditions to raise the error level in case of a failure that's worth aborting the chain.
I don't know what exactly was in the script, but it was basically used to filter all those return codes. The succes rate of the chain installs became a lot higher.
A VBScript is less sensitive. Basically if the script runs it reports success. So all you have to built in is some conditions to raise the error level in case of a failure that's worth aborting the chain.
Posted by:
Rheuvel
15 years ago
ORIGINAL: VBScab
I have just completed an exercise to cascade-install 3 products.
I found that the main drawback with Task Sequences is that they don't "survive" a client reboot. The 'Run Another Program First' option works very well for me.
Funny, I just got the responsibility to put some things in SCCM myself now. And I have a question myself about this particular subject.
Do you also have experience with chaining about 9 to 20 apps (a whole suite)?
Isn't that a bit of an overkill for 'Run Another Program First'?'
I've never tried it but I need to make the choice between task sequence or just chain linking them by run another program first.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.