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).
[wpdm_file id=8]
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