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.
