Deployment Solution

Hi,

 

We're running Deployment Solution 7.1 SP1 (on SMP 7.1).

 

I'm using return codes from some command scripts to determine the next step that a deployment job takes.

 

For example, a return code from one script might be 10001 or 10002, which refers to starting a VM build, or a Physical server build.

 

The problem is, that EVERY code, except for 0, shows as "Failed", so it looks like the majority of my jobs fail... which, in turn, will confuse the people using my build jobs.

 

Is there anywhere that I can add a list of all the return codes that I use, so that this specific list of codes will show as "Completed" or "Successful"?

 

 

Thanks,

Dan

You have to create this on a per job level using Conditions in the Client Job.  If you want to use success codes, you can list success and failure codes for software resources, but this isn't available for scripts.

Does this answer your question?

I'm a little confused... is the answer "no, you can't have a custom return code returned as a success, unless it's 0"?

 

Also - I'm assuming from what you're saying that the settings under "Software>Software Catalog and Software LibrarySettings>Installation Error Code Descriptions" will have no effect whatsoever on deployment tasks?

 

 

Thanks,

Dan

Can you add text descriptions to numeric error codes for software installations that will display in Altiris?

Yes.

Can you tell a software resource's command line that certain non-zero codes are still successes?

Yes.  For each command line defined for a particular software resource, you can tell Altiris to interpret a non-zero code as a success.  For example, maybe for an Office install a success code is either 0 or 3010 (a reboot is required to complete the installation).  Enter 0,3010 and it will view both as successful.  This is only if you use the command line to call the software resource.

Do the settings at Software Catalog and Software Library > Installation Error Code Descriptions have an impact on success/failure logic?

No.  The descriptions only add some helpful information to the codes; it doesn't change how Altiris interprets the codes.

If you want to use a Run Script task that has multiple codes and you want those codes to inform the next task, you need to use Conditions within a Client Job.  So you add a Task to a job, and then you add a Condition that says Where 'Dan's Script - Return Value' 'equals' '10002', then run this task and then end.  Otherwise, check this condition: if 'Dan's Script - Return Value' 'equals' 10001,' then run this task and then check this other condition, and so forth.

I don't recall if these still show as failures, but the conditions will properly use the return codes to advance your logic.

Does this make sense?

Yes, thanks for elaborating. I have jobs set up already with conditions, and those conditions work, and advance to the correct task/job based on the return codes. My problem is that these are just basic script tasks (not using software library at all), and these custom return codes always come back as "failed" simply because they don't return a code of 0. I guess there's only a way of setting custom return codes as "successful" if you're using software resources, but no way to do so with a simple script task such as "if /I %variable%==VM exit /B 10001" I was hoping there might at least be somewhere in the registry I could edit to set "task success codes".

You could make the script part of a software resource, so that you could work with the return codes and failure codes present for the command lines within the software resource.  So rather than run a Run Script task that includes the code for the script, you save the script as a file and upload it to a new software resource.  And the software resource has a Command Line called 'Execute Script' (or something) which has failure codes defined and success codes defined.  So in this case, you could end the script with "if /I %variable%==VM exit /B 10001" and list 10001 as a success code.

Hi,

Thanks for the software resource idea. I will look in to that.

 

I don't think this will work for my initial jobs that run in WinPE though, will it? Since the PECTagent loaded in WinPE is so basic - it probably doesn't include the ability to work with software resources.

 

I could probably use this approach later on in the job, for the tasks that occur after Windows is installed.

 

 

The other problem I'm seeing, is that conditions that are evaluated as false also show as "failures" in the count of successes and failures. This really doesn't make sense, since determining a path, and saying "I'm going to do A instead of B" doesn't necessarily mean "failure".

 

My main reason for all of this, is that when people are using my build jobs, they may look at the progress of their job, and the immediate reaction will be "uh oh, some of the jobs failed". They will not be regular users of Altiris - so they won't have a full understanding of why these are showing as failed.

 

You are correct in your assumption about WinPE.  We've run into the same issue.  For production scripts we've had to create software resources with just the script as the payload, and appropriate success codes.  For WinPE we have to live with 'failures' and unchecking 'Fail this job if any task fails', which I HATE to do. :(  Hopefully the devs expand the capability of specifying success codes from software resources to run script tasks in the future.

All the Altiris folks I've talked to about the issue always seem to respond with "it's no big deal, just uncheck the 'Fail if any task fails option' and it runs fine." I can't stress enough how bad of a solution this is.  This means that if any of your tasks fail that you do NOT expect to fail, you don't know about it unless you go in and inspect each and every run.  You can no longer rely on the return status of the job itself.  Worse, your job will happily go on executing other tasks even if a major task (such as deploying an image!) fails.

How I've handled it in our few WinPE jobs where we can't use software resources is that I separate out the condition logic into a separate job so that it has as few failure points as possible, then call it from another job that doesn't have the 'fail...' option unchecked.