unfortunately your question is not simple to answer. This is because there are different ways to handle such topics. Basically the question is, what exactly do you need / want? To be more precise, should the error handling happen inside of the executed package or should it be handled outside? Both Options have it's own pro's & con's.
A typical way of an package internal handling would be to use commands which are creating return values. Those values are written to a variable which needs to be evaluated after the execution of the package (e.g. RunAsEX, ExecuteEX). Using an IF Condition you can precisely verify which kind of error happened and what to do. this could be to run a specific application or script. You can even run a separate script (RuneScript command).
For an external handling, you have to create a Job. Jobs are installations which are triggered by special events. You can specify a job condition which runs the script in case of an failed package installation. Be aware that job scripts can only be executed in computer context.
I know about the job policy option, but want a package execution specific to only one package failure, not all of them.
Specifically, if I have a command MSIApplyPatch that fails, then the entire package aborts. How can I get DSM to continue execution of subsequent commands after an MSI or MSP install fails (so I can do my error handling)?
2 of 2 people found this helpful
you can flag a script command as "Continue script despite error". a command that is flagged this way will not abort the script if an error occurs so you can handle the error yourself
Perfect. I have occasionally seen this flag over the years, but never used it - So didn't remember about it. Thanks so much!