For many years I have been organizing jobs in the Deployment console by putting them into folders. Placing jobs into folders makes it easy to deploy a set of jobs "as one". For example, we have a set of Standard Installs that are all in a folder and are applied to each PC as it is imaged. But some of the component jobs (like Symantec Antivirus) can occasionally be applied to machines that are managed in the console but are not being imaged at that time. In the past that meant having two jobs for the SAV install, one in the Standard Installs folder and another filed under the more general "Symantec" folder.
Having two jobs that do the same thing leaves you open for issues down the road. If you craft the job just so you can control the script behind the job and then by updating the script you end up updating all jobs that point to that script. But if the job does anything else - places down an image, gets inventory, or branches due to logic (lab machines vs. staff machines) the different jobs that perform the same function can drift apart and introduce uncertainty over time.
One day I stumbled across the solution: create alias (pointer) jobs that all point to the "main" job. You can then put these pointer jobs in any folder, and they will always do the same thing because they all just call one central job. If you make changes to the central job then all pointer jobs are updated (in effect).
This example was done on a Deployment Solution 6.9 (build 164) console, but the methods mentioned should work the same on older consoles as well.
Using the method I outline in the steps below, you will create alias jobs that, once run, will cause a second job to be scheduled right after the alias job. To get started:
First create a job like you normally would, and give it a name. You may want to add a description which states that the job you are creating is a pointer job. See image below.
For our example we are going to use the Default condition. You could get more sophisticated and use different conditions to point to different jobs depending on your needs. The same basic principal will apply to each condition, just make sure (like always) that there is a default condition to fall back to.
Now add a Script action to the Job you just created. Choose Run this script: as the action choice, and enter a Remark in the scripting body. I like to Remark that this is a Pointer Job by entering
REM Pointer Job
then clicking on Next.
See the example in the image below.
In the Script Information dialog box, leave most of the defaults as they are:
Script Run Location: On the client computer
Client Run Environment: Production - Client-installed OS
Security Context: Default
One change that I do recommend is to change the Script Window under Script Options to run the script Hidden. The short REM script that we wrote will not be on the screen for very long, but popping windows up for end users is never a good thing for the service desk staff. Click on Next when you are done.
Now for the most important step. In the Return Codes dialog box, choose Select a Job…. under the Success (0) return code choice. Since the REM script we wrote is so simple it will ALWAYS return a 0 if run under the system default user the result of the script will be to… select another job!
The Select a job dialog box should open. You can point to any job in your Deployment Console EXCEPT the job you are currently running. This is the main job, the job which will now run immediately following the execution of the pointer job. See the image below for a simple example.
Any number of pointer jobs can point to the same main job, and you can make copies of the pointer jobs to put them into other folders - no need to change anything other than the "copy of" at the front of the job name.
One last tip: Even with the description being set and the remark in the script for the job, it can be hard at times to determine the difference between a "real" job (the main job) and a pointer job. I like to put the text "(a)" at the end of the name for each pointer job. That makes it easier to tell which is which when viewing a history of jobs for a computer. It is also nice to name the job something that indicates what the job points to (not as we did in this example - the pointer job in this example might have been better named "DIR Command (a)").
Below is what a pointer job calling a main job will look like in the console:
The DIR Command job was scheduled for this machine by the Pointer Job (a) job.