Chaining DS jobs

Ron_Lang · 10-15-2007, 03:37 PM

In our DS console, we have-
-Individual Jobs with Individual Tasks
-Individual Jobs with Multiple Tasks

My question is:
-How do I chain 2 or more individual jobs with individual tasks together?

What I would like is to have one job that is replicated or linked to other jobs in a sense that if that one job is changed, I don't have to go and edit all jobs that this one individual job exists in.

Hope this makes sense
r

jasoncordell · 10-15-2007, 04:45 PM

Let me take a stab at this and see if I am on the same sheet here. You want to have a common job that is used by multiple jobs. This common job could change from time to time and you only want to make the change in one central place rather that many "copies" of this job.

The problem with DS jobs is that once you chain to another job, you are forced to follow the exit/chaining rules of that job (if exit 0 jump to job 4, etc). If this were the last step in the various chained jobs, then this would reduce the risk, but would still probably cause you some grief at some point.

If this common job wasn't the last step in a chain of jobs, then you have to figure a way to get back out of the chain that you just joined so you can get back to your original chain. This can be accomplished with various dummy files created in the preceeding job and specific exit codes in the common job to get you back where you want to be, but this could easily grow to something that you would need to flowchart to keep track of. You also run the risk of losing your true exit code for the task completion by using non-standard exit codes to jump you to other jobs.

If you are trying to save a few minutes of time, then this approach is definitely not worth it. If this is going to save you a lot of time, and if you have time to design it, this is potentially doable.

Let me know if I am way off track, or if I lost you somewhere.

Thanks,
Jason

James McGoodwin · 07-03-2008, 12:16 PM

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

Quote:

Originally Posted by jasoncordell

Let me take a stab at this and see if I am on the same sheet here. You want to have a common job that is used by multiple jobs. This common job could change from time to time and you only want to make the change in one central place rather that many "copies" of this job.

<SNIP>

Thanks,
Jason

deemacgee · 07-04-2008, 01:49 AM

Quote:

Originally Posted by Ron_Lang

My question is:
-How do I chain 2 or more individual jobs with individual tasks together?

What I would like is to have one job that is replicated or linked to other jobs in a sense that if that one job is changed, I don't have to go and edit all jobs that this one individual job exists in.

I recently did this for my organisation. It was very much a hackjob, but you know what? It works!

Create a new Run Script task.

Run This Script:

Code:

rem Install Adobe Flash Player
rem This task is a placeholder for existing install jobs in the Console.
rem Update the next line as required.
\\SERVERNAME\EXPRESS\AXSCHED.EXE %NAME% "<Jobname>" /t %TIME:~0,5%

axsched.exe: command-line scheduler.
%NAME%: computer name in the Console.
"<JOBNAME>": the name of your job exactly as it appears in the Console.
/t: time to schedule
%TIME:~0,5%: The current time in 24 hour hh:mm format.

Script Run Location:
Locally on the Deployment Server

Client Run Environment:
Production
BE WARNED - even though the Client Run Environment section turns grey when you select Locally on the Deployment Server, those details are STILL APPLIED. Try Security Context as Default (local system account) and see if that works - you can test it with another account later.

Now you can populate that same job with as many different scripts as you need. Mine looks like this:

(link because it won't embed)

It's split for easy reading, but you could theoretically stick all your AXSCHED.EXE commands into one script file.

EDIT: Background.

The SOE that I inherited originally had the sane set of app deployment scripts (embedded as conditions) for each device model - 7/8 for desktops and another 7/8 for laptops, as well as another, identical set of jobs for machines being put onto the network for the first time. This meant that when Adobe updated their Flash Player (for example), I had to update about 15 sets of conditions in each of the four (or six, depending) different deployment types. I took four of the six deployment scenarios, re-wrote the scripts to process server-side where possible, merged the deployment conditions, added conditional tasks specific only to laptops or desktops, and migrated the whole shebang to WinPE.

There's now ONE job which queues up all necessary tasks to build any laptop or desktop, be it for the first time or as a rebuild, and adding or updating applications in the SOE build sequence is a question of changing one associated script in one location.

ALSO, there's no guesswork with applications on new PCs; the original SOE sequence would say "Deploy SOE". This one will tell you, at a glance, exactly what's been installed on any given machine from the second it's finished imaging.

Hope this helps.

James McGoodwin · 07-04-2008, 06:44 PM

Quote:

Originally Posted by deemacgee

Code:

rem Install Adobe Flash Player
rem This task is a placeholder for existing install jobs in the Console.
rem Update the next line as required.
\\SERVERNAME\EXPRESS\AXSCHED.EXE %NAME% "<Jobname>" /t %TIME:~0,5%

That is utterly BRILLIANT!

I didn't even know there was a command line function to schedule a job in DS

Quote:

Originally Posted by deemacgee

I recently did this for my organisation. It was very much a hackjob, but you know what? It works!

Hack or not, you have no idea how much better this works than what we came up with

Now might be a good time to say what sort of environment we're running

We have CMS Level 1 with Deployment Solution 6.8.206 and Notification Server 6.0.6074

Here's how we're using it. Same goal, centralized, atomic jobs referenced by a series of these axsched tasks.

But I thought I'd echo back with what we've done with it. Part of my MO is to log my jobs. Extensively. Possibly to the point of stupidity. But I've found that the DS auditing on job and script events is just not sufficient enough. So most of the batch scripts we make around here are coded for the following goals:

Quote:

1) Log the scripts payload to a log file hierarchy on the target computer.
2) Run the script ON the local computer to make this logging easier and to offload processor crunch to the masses rather than brutalizing our Altiris server during office wide deployments of multiple job sequences.

Goals (1) and (2) synergize for me with respect to your warning about the Client Run Environment. I prefer to run the jobs on the local machines, which gives me the additional option of choosing the user to run the script (since Security Context wont be greyed out in this configuration)

However, axsched.exe does not inherit the creds of the user running it, at least not in our environment. We had to call axsched with explicit /lu and /lp flags in the command...now that ain't cool if we're logging the event to the local computer

Nor is it particularly good form even if the scripts are stored up in DS embedded job.

So we threw a layer of obfuscation over every thing. It hides the altiris service account's password, allows the local computer to execute the script under any creds with domain admin powers, and allows us to log the event to the machine all at once.

The trick was finding a VBScript Class for the axsched.exe over on Juice.

We pulled the VBS files down, made some tweaks to them and then encrypted them with Microsoft's Script Encoder to transform them from VBS to VBE's.

The two files from Juice are

Quote:

AltirisJobScheduler.vbs
ScheduleJob.vbs

The AltirisJobScheduler.vbs is the class file, and the ScheduleJob.vbs is the actual script you configure for your environment.

Now, because I want to run these scripts on local machines, and these computers don't have System DSN's for our Altiris server, these scripts fail when they call axsched because axsched.exe util requires the eXpress System DSN to be defined on the machine it's running on.

Ok, but axsched also has switches for Altiris Server name ("/d") and Altiris Database Name ("/db"). With these defined, your executing computer doesn't need a system DSN for eXpress.

Out of the box, the VBScript class doesn't handle these two switches. So I rolled up my sleeves and fleshed the class out. I've attached a copy of our final scripts to this post.(with the appropriate Juice license file) Here's a quick rundown of what was changed:

Quote:

1) Now accepts specifications for DS Server Name and DS database name.
2) Additionally, accepts command line arguments for target computer and specified job from command line.
3) Human interface for these inputs has been removed.
4) Crude error checking for these two command line arguments is done. If any more or any less than 2 arguments are passed to this script, script barfs error code 111.

SO! Fine, with that modified VBS class/execute and the MS script encryptor we packaged the whole shebang into a tool called from our embedded tasks when ever we want to reference an atomic package. We based the script off of your initial code Dee. You're commenting about it being a place holder was so precise I sort of lifted it

Code:

REM This task will schedule <INSERT EXACT JOB NAME HERE!!>. 
rem This task is a placeholder for existing install jobs in the Console.
rem Update the next line as required.
::----------------SET REFERENCED JOB HERE!!------------------
set ReferencedJob=<INSERT EXACT JOB NAME HERE!!>
::----------------SET REFERENCED JOB HERE!!------------------


:: start logging output
if not exist "C:\documents\logs\AltirisLogs\CMDLineJobInjectionLogs" mkdir "C:\documents\logs\AltirisLogs\CMDLineJobInjectionLogs" 
call :startscheduler > "C:\documents\logs\AltirisLogs\CMDLineJobInjectionLogs\%ReferencedJob%.log" 2>&1
goto :end

:startscheduler 
cscript \\toralti2\express\Tools\AltJobSched\ScheduleJob.vbe "%COMPNAME%" "%ReferencedJob%"
@echo off
if %errorlevel%==111 exit 111
goto :end

:end

The only thing to do after all that is to add error code 111 into the master list of codes, saying something like "Too many or too few command line arguments being passed to ScheduleJob.vbe" in case someone pops along and munges up your scripts later on.

GAH! Wow...how did I get side tracked doing all that...like I said, sometimes the desire to log stuff and have things remain off loaded to client computers makes me do weird things...

Again, if I haven't said it yet, thank you Dee! That was the absolute coolest tip in the world

Hopefully someone out there might find these modified vb scripts useful too.

deemacgee · 07-21-2008, 11:58 PM

Quote:

Originally Posted by James McGoodwin

That is utterly BRILLIANT!

Aww, shucks.

Must say I rather like your solution - you can never have too much logging!

Very nicely done... might even see a bit of use here.

DMcG

Petrucci914 · 05-22-2009, 05:07 PM

I want to do this, the thing is.....you can have multiple jobs with the same name if you've created a hierarchy of system jobs (much like an OU structure).

Does this just mean that I need the axsched job to be in the same 'group' as the jobs it references?

deemacgee · 05-22-2009, 11:24 PM

Quote:

Originally Posted by Petrucci914

I want to do this, the thing is.....you can have multiple jobs with the same name if you've created a hierarchy of system jobs (much like an OU structure).

Does this just mean that I need the axsched job to be in the same 'group' as the jobs it references?

Axsched.exe refers to jobs by name, not sure there's a way around that (though to be honest, I can't check because I don't have access to a DS server at the moment).

EDIT: Depending on your configuration, it might be possible to use axched.exe to trigger a handler job of some sort, with different scheduling outcomes based on various input conditions (instead of trying to queue up the jobs directly). How are your target PCs arranged in the Console?

Petrucci914 · 05-23-2009, 11:51 AM

Everything is set up in a hierarchy.

We are a large school district so our machines are arranged by building, labs, etc.

The same is with our System Jobs. Our jobs are arranged by:

1. Base Installs
2. High School Software
3. Middle School Software
4. Microsoft Products
5. etc.

So occasionally I may take a common job and copy it to other folders.... I don't know what axsched would do in that case.

I don't think you can create a same job in one folder/group, but you can create another in another folder with the same name.

deemacgee · 05-23-2009, 12:33 PM

Quote:

Originally Posted by Petrucci914

Everything is set up in a hierarchy.

We are a large school district so our machines are arranged by building, labs, etc.

The same is with our System Jobs. Our jobs are arranged by:

1. Base Installs
2. High School Software
3. Middle School Software
4. Microsoft Products
5. etc.

So occasionally I may take a common job and copy it to other folders.... I don't know what axsched would do in that case.

Out of curiosity, what happens when one application install replaces another? For example, if you were to go from (say) Adobe Reader 7.x to Adobe Reader 8.x, would you need to update all the jobs individually?

Also, is the naming convention for your PCs related at all to their location or purpose?

Quote:

I don't think you can create a same job in one folder/group, but you can create another in another folder with the same name.

You can do - jobs are stored as database entries with individual record numbers; names are irrelevant. It's entirely possible to have two identically-named jobs in the one folder... of course, it can be pretty confusing for Console users (or axsched.exe).

Petrucci914 · 05-23-2009, 12:38 PM

In that case I would create a new folder entitled 'Adobe Reader 8' and create a new job there. We try to create separate folders for software packages in case we ever need to add scripts, permissions, or registry settings that are needed for a certain program.

Right now I have a job set to run after an image completes to add some settings and install our Antivirus. So I basically just create a new job for that and copy all the tasks from the jobs it needs and paste them in there.

deemacgee · 05-24-2009, 01:43 AM

Think I follow what you're saying. There is an axsched.exe switch - for DS 6.5, at least, which is the only reference I could find online - which queues up a job kept in a particular folder.

Have a look at axsched.exe /? and see if the /f option is available to you. It might help in this circumstance.