James McGoodwin

Thought I'd throw in on this too. This is precisely what we'd like to accomplish too.

A lot of the goals governing how I've designed our Deployment Solution set a priority on offloading as much as I can into centralized batch files. This means that if multiple jobs reference the same batch, a single update is reflected across all referencing jobs.

But, that's not the question here. The question is how to do the same thing with in the Altiris Deployment Solution Job structure.

So, something my coworker did in a flash of brilliance was to create a job, fill it with a series of "Run Script" tasks, each of which runs an internal batch command structured like this:

REM Install blahblahblahblah.

Then, we further configure that task by setting the Success field of the "Return Codes" section to chain over into the centralized job we want to call.

In theory, this all works. In theory What happens in practice is your "Mother" job runs, executes task one, chains in the referenced centralized job, and IMMEDIATELY moves on to the next task in the Mother job, rather than running that centralized task first.

The effect is it queues up a series of jobs that run after the Mother job is complete.

Unfortunately, this rather crude approach seems to have some quirks. For example, queued up centralized jobs may (or may not) queue out of order with respect to their listing in the mother job.

Also, if you call a referenced centralized job more than once in your mother job, the LAST time you call that job is the one that gets queued.

For example, say your Mother job is designed like this:
Task 1 = Reference Centralized Job for Installing Winzip
Task 2 = Reference Centralized Job for Installing Office 2003
Task 3 = Reference Centralized Job for Installing Winzip
Task 4 = Reference Centralized Job for Installing CarbonCopy

Never mind the obvious question "Why would you install Winzip twice??"

The resulting queue of jobs you'd get on the target computer would (at best) look like this:

Mother Job (scheduled 12:01 PM 04-07-08)
Office 2003 (scheduled 12:01 PM 04-07-08)
Winzip (scheduled 12:01 PM 04-07-08)
CarbonCopy (scheduled 12:01 PM 04-07-08)

You can see how this falls short of an ideal, truly centrally referenced list of atomic tasks called by some custom, application/department specific mother job.

But, so far that's the best we've been able to figure with out the need of a really violent flow-chart-worthy solution