RES AM Passing Values Between Scripts

You don’t need to be told how great RES Automation Manager, but there are some things that we can only achieve via scripts; be it VBscript or PowerShell. In my example, it is scripting XenDesktop and XenServer for the demo showcase platform (more on this at a later date). There is currently no way to automate these products without using scripts. Unfortunately (for me) it’s always been problematic to pass values in and out of scripts to other modules. We can certainly pass a value into a script, but then we can’t return it to be used elsewhere.

My problem required creating an AD user (not via the built in task) in one script and then passing the username/password into another script. To overcome this particular issue, I started down the route of temporarily writing the information to the registry so that it could be read by the other script later in the Project. This is where I stumbled across a little gem hidden in RES Automation Manager. I don’t know whether it’s intentional and/or undocumented, but it certainly works!

I attempted to use a Parameter using the built-in @[REGISTRY] Function. In essence this instructs the RES Automation Manager agent to populate the Parameter with the contents of the registry key. This bit is simple to understand and you probably already knew this. However, what I didn’t realise is that this Parameter is updated/re-evaluated at every task within a Module. I assumed that it would only be evaluated when the Module is invoked by the RES AM agent. I’m certainly glad that this is not the case as we can now write values to the registry and AM will automatically pass the updated value to the next Task(s).

Here is an example building block that contains a single module with a single registry-based, emtpy Parameter value. The first script writes the current date to temporary location in the registry (just so happens to be where RES Automation Manager is reading the Parameter value from). The second script receives its Parameter value from RES AM (not directly from the registry within the script), adds a day (in US format!) and writes it back to the registry. The final task displays a pop-up message with tomorrows date from the RES AM Parameter.

What this does prove is that the Parameter is re-evaluated before each task is executed and therefore passed through all tasks. Never in this example module do we enter the date. Here is the status of the parameter before and after each task.

Task 1 – BEFORE: <Empty>, AFTER: <Empty> (We write today’s date to the registry, but it’s not re-evaluated until the next task)
Task 2 – BEFORE: <Current Date>, AFTER: <Current Date> (We write tomorrow’s date to the registry, but it’s not re-evaluated until the next task)
Task 3 – BEFORE: <Tomorrow’s Date>, AFTER: <Tomorrow’s Date>

I’m sure you can think of more ingenious ways of using this functionality. Enjoy! Iain

RES Workspace Manager and 32/64 File Paths

With deployments of x64 Windows Operating Systems (Windows 2008 R2 RDS and Windows 7) on the significant increase, you will discover over time that you need to support the same applications in the RES Workspace Manager management console but with two differing file paths. For example, Adobe Reader 9 on a 32-bit OS will typically be located in the ‘C:\Program Files\Adobe\Reader 9.0’ directory (or ‘%ProgramFiles%\Adobe\Reader 9.0’). The same application installed on a 64-bit OS will generally reside in the ‘C:\Program Files (x86)\Adobe\Reader 9.0’ directory (or ‘%ProgamFiles(x86)\Adobe\Reader 9.0’). On x64 system the ‘C:\Program Files\’ (or %ProgramFiles%) is used for native 64-bit applications. Now, if only Mickeysoft had chosen an alternative path the native 64-bit apps life would have been a whole lot easier…

Historically when deploying RES Workspace Manager on x64 Operating Systems you would have to update all your applications within the management console to reference the ‘%ProgramFiles(x86)%’ location as the installation paths are different. RES Workspace Manager attempts to fix problem this with on-the-fly redirection. That’s to say that it’ll automatically detect it’s running on a x64 OS and attempt to launch the executable in the %ProgramFiles(x86)% location instead of the defined %ProgramFiles% path. In turn this creates a problem for the 32-bit OSes as the ‘%ProgramFiles(x86)%’ system environment variable does not exist – DOH!

When I originally set out about writing this post, my understanding was slightly different from what I’ve ended up with. However, the findings are still valid so please continue to read. From the testing performed in preparation for this post with RES Workspace Manager 2011 SR2, it all appears to work correctly (shock/horror!). What I mean is, that not only does Workspace Manager appear to automatically redirect on 64-bit OSes, but also appears to attempt it on 32-bit OSes too.

The purpose of the “Disable folder redirection on 64-bit platforms” option (on a per application basis) stops RES Workspace Manager from redirecting entries defined with %ProgramFiles% to ‘C:\Program Files (x86)\’. Using Wordpad as an example, if you have the application entry defined as ‘%ProgramFiles%\Windows NT\Accessories\wordpad.exe’ Workspace Manager will automatically attempt to launch “C:\Program Files (x86)\Windows NT\Accessories\wordpad.exe” by default (the 32-bit version) on a 64-bit OS.

Checking the ‘Disable folder redirection..’ check box forces Workspace Manager to launch the actual process defined in the executable path, i.e. the 64-bit version. Obviously, this example only works if both 32-bit and 64-bit versions of the application are available. If you use Microsoft PowerPoint 2007 as an example, checking the ‘Disable folder redirection..’ option will break the 32-bit application on 64-bit OSes.

Caveat #1

The on-the-fly folder redirection only works when using system environment variables, i.e. %ProgramFiles% and/or %ProgramFiles(x86)%. If you have hard coded paths such as ‘C:\Program Files\’ or ‘C:\Program Files (x86)\’ it doesn’t work. So get updating all your applications to use these variables!

As previously mentioned, RES Workspace Manager appears to redirect on 32-bit OSes too. For example, Workspace Manager will launch an application defined with the executable path as ‘%ProgramFiles(x86)%’ successfully on a 32-bit OS even though the environment variable does not exist. I was not aware of this and can only assume that it’s a recent addition. Unfortunately this is different from what we’ve seen happening in the field and hence why we earmarked the subject for a blog post! What we have seen are applications failing to appear and/or launch correctly when updated to point to ‘%ProgramFiles(x86)%’ on 32-bit Operating Systems.

Caveat #2

Once you’ve updated all your applications with environment variables it should just work. To circumnavigate this issue we put the following simple workaround in place. Note: from the above diagnosis you should no longer have to do this.


  1. Define the %ProgramFiles(x86)% environment variable only on 32-bit machines via a Location/Device zone. Configure this environment variable to point to %ProgramFiles%. On 32-bit systems both variables will point to same location but your applications are guaranteed to work on 32-bit OSes.
  2. Ensure that you replace all file paths for managed applications with their associated environment string (I have mentioned this already haven’t I?!). If you don’t do this then you’ll need to ensure you manage the availability another way, e.g. via Workspaces or Zones.
  3. Add/configure applications in the RES Workspace Manager console on 64-bit OSes wherever possible. This will ensure that 32-bit applications always use the %ProgramFiles(x86)% variable (and not cross-platform %ProgramFiles%). If not, you need to hope that RES Workspace Manager performs it’s on-the-fly redirection magic!

Thanks, Iain