September 2012 – Virtual Engine Ltd

24th September 2012

VET v1.2 Released!

Virtual Engine are pleased to announce the general availability of version 1.2 of the Virtual Engine Toolkit (VET). The latest Windows installer and documentation is available for download now on the Virtual Engine web site.

We’ve put together a series of short videos demonstrating each new feature. In the “What’s New” video series we cover the following features:

Job Execution Tool (including JETCMD and JETPWD);
Migrating Group Policy Security Permissions (VET);
Group Policy Objects Wizard Search (VET);
Group Policy Migration Report (VET);
Enabling the Aero theme (PuU);
Importing International Settings (PuU).

For more videos on the Virtual Engine Toolkit, please check out our YouTube channel.

17th September 2012

RES Automation Manager Quick Tip – appending to existing registry values

I was recently asked (by one of our existing RES Automation Manager customers) how they go about adding to an existing registry value using RES Automation Manager. Well the answer is simple really – by using the @REGISTRY function. I’ll detail how you go about using this function in this blog post.

Firstly start the RES Automation Manager console;
Select “Modules” from the left hand pane, Right Click and select “Add”;
Give the module a suitable name then select the “Tasks” Tab, Right Click and select “Add”.
Select the task “Registry Setting (Apply,Query)” and select “Apply”.
You will now be presented with a dialogue where you can select various methods to add the required registry value you wish to append too. In my example I’m going to APPEND a new string to the START of the existing USERINIT registry value. Select “HKEY_LOCAL_MACHINE” from the left hand pane, Right Click and select “Open HKEY_LOCAL_MACHINE…”.
Browse to “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” and select “Userinit”, this will add this value to the current dialog box.
Now we are going to add the @REGISTRY function to the Userinit value by Right Clicking on “Userinit” in the right hand pane and selecting “Modify”.
In the “Value Data” field, Right Click and select “Insert Functions” >; “@[REGISTRY(;)]”.
RES Automation Manager now provides you with a nice GUI that allows you to browse to the registry value you wish to retrieve, when the job is executed on the agent. In my case this is going to be the registry value I selected in Step 6, as this is the value I’d like to append too.
Now I simply add the new value that I wish to append, before the @REGISTRY function or after, depending where I’d like my value to appear – in my case this value is “MyNewValuetoAppend” [code]MyNewValuetoAppend,@[REGISTRY(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon)][/code]
The resulted registry value now looks like this, once the job has been scheduled and completed [code]MyNewValuetoAppend,C:\Windows\system32\userinit.exe[/code]

That’s all there is to it! Smile

Nathan

5th September 2012

Introducing JETCMD

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!

3rd September 2012

Introducing the Job Execution Tool (JET)

We’re pleased to announce that we have beta copies of the new RES Automation Manager Job Execution Tool (JET) and Job Execution Tool Command Line (JETCMD) available. The premise of these two new utilities is to overcome a particular shortcoming in the RES Automation Manager product suite; unattended job scheduling. These new tools overcome the following problems:

When scheduling a job unattended you have to specify the target agent that you wish a job to run on as there is no way to flag the “local” machine.
When integrating RES Automation Manager jobs with RES Workspace Manager you have to supply parameter values up front. There is no way to prompt the user for parameter values from RES Workspace Manager.
When parameter values are required at run-time, jobs have to be scheduled via the RES Automation Manager GUI.

JET

The main JET utility is a graphical interface, dynamically built around an XML configuration file. Its initial intention was to be able to schedule RES Automation Manager jobs via managed RES Workspace Manager managed shortcuts with the ability to prompt for parameter values. Many customers have asked whether we can provide access to Run Books without granting access to the RES Automation Manager console. Unfortunately for us, there is no way to prompt for RES Automation Manager parameters when integrated with RES Workspace Manager. We can integrate parameters, but they’re a one-way operation and set in stone, i.e. they cannot be changed on the fly only configured up front.

JET overcomes this issue and permits execution of either Modules, Projects or Run Books on the local agent without having to know the local agent’s name, GUID or launch the RES Automation Manager console. If you don’t want the target job to run on the local agent, then it can all be predefined in the target Run Book.

Here are a couple of scenarios where we have used JET to-date:

Invoking AD object creation tasks (users etc) via managed desktop shortcut without requiring access to the RES Automation Manager console. This provides a simple to access self-service menu and reduces training as Helpdesk staff having to understand another console.
During imaging processes to allow the technicians to select the target department/application set for the end user. Otherwise, this would require the technician having to manually schedule a RES Automation Manager project on the target device. What is its name etc.

The graphical interface is fully customisable (within reason) so you can change all the wording and even the main graphic if required. This helps end-user adoption as it can be branded with the corporate imaging etc. Here’s an example we’ve used (customer artwork removed!) at the end of the imaging process. After deployment, the relevant departmental applications can be installed by selecting the department: