Complimentary to recently announced Job Execution Tool (JET) there is also a command line version. The purpose of this is tool is slightly different to the GUI version. Whilst the GUI version is all about passing parameters to modules, projects or run books chosen by the end user at run time, JETCMD is all about automation! Note: Just like JET, the RES Automation Manager (WMC.EXE) console must be installed to schedule jobs with JETCMD.
So how is JETCMD.EXE different from the standard WMC.EXE?! There are three big differences:
- To schedule a job via WMC.EXE you have to specify the target RES Automation Manager agent or team GUID. If you just want to schedule a job on the local agent there is no way to specify this. JETCMD allows you to simply specify the local agent without knowing its GUID or name in advance.
- There is no way to pass an encrypted password to WMC.EXE. JETCMD allows you to pass an encrypted password so it’s relatively safe to include in scripts.
- Parameters cannot be passed to a RES Automation Manager dispatcher without the use of a .CSV file. Therefore, it’s difficult to pass parameter values via the command line.
So why and where would you use it?! As always, we only develop additions to the Virtual Engine Toolkit when we or our customers need them! We primarily use JETCMD during Windows 7 (soon to be Windows 8) builds but I’m sure there are many other use cases…
As an example, during Windows 7 deployment we might wish to automatically schedule a RES Automation Manager module, project or run book post setup, e.g. in SetupComplete.cmd. Unfortunately, we have no way of specifying the job to run on the local agent via WMC.EXE as we don’t know its GUID – DOH! To get around this restriction we can just use JETCMD as a wrapper for WMC.
Another great example is when you’d like to schedule a RES Automation Manager module, project or run book as a logoff task in RES Workspace Manager i.e. delete any cached local profiles. The RES Automation Manager integration in RES Workspace Manager only allows for tasks to be scheduled at login or when launching managed applications – using JETCMD as an Execute Command at logoff can get around this drawback.
Here are some examples. To schedule a run book on the local agent using pass-through authentication we can use something like this (obviously the run book needs to exist!):
[code]JETCMD.EXE /type:runbook /jobguid:{5E5906A7-00D5-49E4-909B-CEB1810BF37} /agent:local[/code]
Or if you want/need to use RES Automation Manager authentication we could specify this instead:
[code]JETCMD.EXE /type:runbook /jobguid:{5E5906A7-00D5-49E4-909B-CEB1810BF37} /agent:local /username:RESAMUser /password:RESAMPassword[/code]
If you want to pass parameters to the same run book the command line would look something like this:
[code]JETCMD.EXE /type:runbook /jobguid:{5E5906A7-00D5-49E4-909B-CEB1810BF37} /agent:local /username:RESAMUser /password:RESAMPassword /paramname:”””MessageTitle”””,”””MessageBody””” /paramvalue:”””Job Successful”””,”””The target job has finished”””[/code]
You may ask why we don’t utilise team membership for this? The simple answer is if the RES Automation Manager agent is installed within an image (or how you identify RES AM agents), automatically invoking a job can be problematic. The detailed answer is that team membership rules won’t necessarily be triggered if the agent is not seen as a “new” agent. A classic example of this is when a machine is re-imaged and it’s already a member of the target team. Humans are rubbish at having to remember to remove a RES Automation Manager agent from a team before re-imaging (as well as removing a computer’s AD account!).
As we’re security conscious we also don’t like specifying the RES Automation Manager console username password in clear text if we can avoid it. Therefore, we allow you to obfuscate the password so users cannot manually open the RES Automation Manager console with credentials embedded in any scripts. Encoding the password is optional so the choice is entirely down to you.
If you do wish to obfuscate the password then you’ll need to use JETPWD.EXE (yet another tool!). This tool is used to generate obfuscated passwords for both JET and JETCMD.
These new tools will be included in the upcoming Virtual Engine Toolkit v1.2 release. Until then, if you’d like a copy please complete the Contact Us form or email me and we’ll happily send you a copy!
