RES Automation Manager Emergency Patch Management

I previously covered the reasons why you probably wouldn’t use RES Automation Manager for patch management (see here). Max Ranzau (AKA @RESguru) made a great point that you can certainly use Automation Manager to push a patch out individual patches easily. With the release of the Microsoft RDP critical patch MS12-020 and an exploit apparently in the wild, this proves that RES Automation Manager certainly still has its place in your patch management strategy.

Assuming that you haven’t exposed port 3389 directly to the internet you may feel that you’re somewhat “safe.” I actually think that the greater risk comes from worms that will be run from within the corporate network firewalls. All it takes is for one machine to be compromised… How many desktops and servers do you have inside the corporate network that have RDP access enabled?

Microsoft provides some workarounds that will give you time to test the patch prior to deployment. Fortunately, RES Automation Manager gives you the following options in dealing with this exploit using the built-in Automation Manager tasks/tasklets:

    1. Deploy the patch within minutes and/or
    2. Disable RDP connections completely and/or
    3. Enable/modify the Windows firewall rules to block RDP connections and/or
    4. Enable Network Level Authentication for RDP connections.

One thing is for certain, you need to be acting and mitigating this risk now. I think it’s only a matter of time before things get interesting. Who remembers Slammer?! I know people who are still mentally scarred by its long lasting effects!

GPOs could help you with some of this, but nothing is going to be able to deploy any of (or a mixture of) the above workarounds within minutes. How will you be sure that your workarounds are in place on all machines? RES Automation Manager will give you near instant feedback on what tasks failed and provide you with the data to target those computers. Remember, if you use RDP/Remote Assistance for support then you’re probably limited to option #1 (or maybe #4).

If you don’t have RES Automation Manager today, you probably wish you did! You’ve been warned Smile with tongue out..


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).

[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

BigHand Digital Dictation and RES Automation Manager – License file update

Following on from the BigHand Digital Dictation and RES Automation Manager – BHF File Locations post, I’ll show you how easy it is to update the BigHand license files across all BigHand servers in your estate with RES Automation Manager.

Managing your BigHand Digital Dictation system using RES Automation Manager

BigHand is a powerful dictation product used in many environments, but most prevalent in the Legal and Medical sectors.  With enhancements such as speech recognition and workflows more and more users are relying on this business critical tool. In these posts I will go through the automation of two of the most common tasks required on the system; Updating license files and locating a dictation file.

Update license files

License files are supplied by BigHand as a .lic file.  They must be located in a particular location on every BigHand server in your environment.  If you have a BigHand file store server in every site, BigHand gateway for telephony or Mobile client there can quickly become lots of servers requiring a license file, this is a time consuming process which can easily be automated and here’s how.

Stop services
All the BigHand services should be stopped before you can update the license file.  These need to be done in a particular sequence.  For this you can use Service properties (Manage) task in the Configuration folder.

  1. Stop Branch site BigHand services (If you only have 1 BigHand server you can ignore this)
    a. On the settings tab select Change Service State
    b. In service name enter BigHand Server x.x (where x.x is the version number) or you can connect to the server using the browse button and select the service
    c. In New Service State select Stop service.
    d. You need to set a condition on this task so that it only runs for branch sites, so select the condition tab.
    e. Under expressions select Add and then Registry Setting
    f. Click the browse button next to the Operand field and connect to your Master BigHand server’s registry.  Drill down to the following key and double click: HKEY_LOCAL_MACHINE\SOFTWARE\BigHand\BHServer_x.x\ServerGuid
    g. The Operand and Value will be added to the fields, ensure the operator is equals and click Ok.
    h. Select “If the condition is TRUE then Skip this task”.
    i. Select “If the condition is FALSE then Execute this task, but skip all remaining tasks in this module” and click OK.
  2. Stop all Master services
    a. Create another 5 Manage service tasks and repeat steps a – c for the following services (the order is important to avoid conflicting dependencies):
    i. BigHand Gateway service
    ii. BigHand External Workflow server service
    iii. BigHand Active directory service
    iv. BigHand Services host service
    v. BigHand Server x.x service

Backup old license file and copy new license file

  1. Click Add and Select Files (Perform operations) from the configuration folder
    c. On the settings tab click add and select Delete as the action type
    d. In the source path enter C:\Program Files\Common Files\BigHand\BHServer.old (Default location) and click OK.
    e. On the settings tab click add and select Rename as the action type
    f. In the source path enter C:\Program Files\Common Files\BigHand\BHServer.lic
    g. In the Destination path enter C:\Program Files\Common Files\BigHand\BHServer.old and click OK.
    h. Ensure Ignore Errors is checked and click OK.
    i. Click Add and select Resource (Download) from the provisioning folder
    j. On the settings tab click Add and browse to the license file resource
    k. Check specify destination folder, in the destination enter C:\Program Files\Common Files\BigHand\  and click OK.
    l. Clone both of the File tasks you have just created, open them and change the source and destinations to C:\Program Files\BigHand\BigHand Services\
    m. These two file tasks will need conditions so they only run on the master server, click the Conditions tab and click add
    n. Select registry setting and add the value from 1f above.
    o. Select If true Execute and If false Skip task and click OK

Start services

  1. For this you can use the Service properties (Manage) task in the Configuration folder again, except this time you must select Start service as the new service state.  The jobs must run in the following order:
    a. BigHand Active directory service
    b. BigHand External Workflow server service
    c. BigHand gateway service
    d. BigHand services host service
    e. BigHand Server x.x service (Master site)
    f. BigHand Server x.x service (Branch).
  2. Be sure to set a condition on these using the BigHand server GUID as before, that way the job will not try to start services that do not exist.
  3. That’s it, you’re done.
  4. Finally, you could configure a job to check each service and email the results.

BigHand Digital Dictation and RES Automation Manager – BHF File locations

Whilst this post is targeted at retrieving archived BigHand dictation file locations, it does demonstrate how we can use RES Automation Manager parameters and its Microsoft SQL integration to good effect.

Locating a Dictation File

BigHand holds dictations in a proprietary format with the extension .BHF.  This is essentially just a WAV file with minor modifications.  Once a user has completed a dictation it will disappear from their view after a pre-determined number of days.  If you have a reason to retrieve one of these files once it is removed or if a system corruption means you need to re-import dictations there is no easy way to identify the file, as the files have GUID filenames and can be sitting on any file store server in your BigHand estate.  Using a combination of SQL and Automation Manager you can make everyone’s life easier.

Create SQL View

First you will need to create a SQL view on your BigHand SQL instance called Find_Dictation_Location as per the below script:
SELECT     a.BH_FirstName, a.BH_LastName, a.BH_UserName, b.BH_Title, CONVERT(varchar(10), b.BH_CreationDate, 103) AS BH_CreationDate,
b.BH_CompletionDate, b.BH_Deleted AS BH_Deleted_Task, b.BH_Destination, b.BH_Description, b.BH_MatterNumber, b.BH_DocumentType,
b.BH_Confidential, b.BH_FileRequired, b.BH_Open, c.BH_FileGuid, c.BH_Location, c.BH_Version, CAST(d.BH_URL AS nvarchar(4000))
+ CAST(SUBSTRING(c.BH_Path, 2, LEN(c.BH_Path)) AS nvarchar(4000)) AS Path, c.BH_Deleted AS BH_Deleted_File
FROM         dbo.BH_Users WITH (nolock) a INNER JOIN
dbo.BH_Tasks WITH (nolock) b ON a.BH_UserGuid = b.BH_Author INNER JOIN
dbo.BH_FileLocations WITH (nolock) c ON b.BH_TaskGuid = c.BH_FileGuid INNER JOIN
dbo.BH_Locations WITH (nolock) d ON c.BH_Location = d.BH_Location

Automation Manager SQL Query

Next you need to run a SQL query against that view to retrieve the URL of the file, but the SQL query needs to be edited every time you use it, so let’s create an AM job to do this.
1. Create a Module and Add a SQL Statement (Query) task from the advanced folder
2. On the settings tab add the following SQL query:
select BH_UserName,BH_Title,BH_CreationDate,path,BH_Deleted_File from Find_Dictation_Location
where bh_username like ‘%$[Username]%’ and
BH_Title like ‘%$[Title]%’ and
BH_CreationDate like ‘%$[Date]%’
Note the parameter references in the SQL query ($[Username], $[Title] and $[Date]).  These are the fields required to identify the dictation.  Obviously these can be changed to any of the fields available in the SQL view.
So that AM can insert the correct variables into the script you will need to create parameters for:
a. Username (Username)
• This will allow a full or part entry of the user who created the dictation
b. Dictation title (Title)
• This will allow a full or part entry of the Dictation title
c. Time and Date (Date)
• This must be the exact creation date; you can set a mask for the parameter on the input tab in the format 00/00/0000.
Once these are created, you will be able to run the query against your SQL instance.  It will collect information on the dictations you specified by looking up the relevant GUIDs in the database and create a field entry (Path) that has the URL built up from the separate BH_Locations and BH_FileLocations tables.  This will then be presented in the Job results for the query.
View results in Automation Manager Job History

Change RDS User Logon Modes using RES Automation Manager

[wpdm_file id=6]If you are using Windows 2008 R2 Remote Desktop Services you might have noticed that there are various user logon modes available on the Remote Desktop Session Host; which you can see from the screen shot below:

These are all well and good should you wish to manually change the user logon modes i.e. Allow reconnections but prevent new logins until the server is restarted for say maintenance purposes. But if you are already using RES Automation Manager why not complete this task in a more automated fashion? Well this can be easily achieved by adding the following tasks and module parameter.

Module Tasks:


Module Parameters.


Module Task 1 (Enable Logons):
  1. Add Task > Remote Terminal Server Logons.
  2. Settings > Enable Logons.
  3. Condition Expression > User Logon Mode = 1.
  4. Condition Expression > Computer Function = Terminal Server.
  5. If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
  6. If condition is FALSE then > Skip this task.
Module Task 2 (Disable Logons) :
  1. Add Task > Remote Terminal Server Logons.
  2. Settings > Disable Logons.
  3. Condition Expression > User Logon Mode = 2.
  4. Condition Expression > Computer Function = Terminal Server.
  5. If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
  6. If condition is FALSE then > Skip this task.
Module Task 3 (Allow connections) :
  1. Add Task > Registry Settings (Apply).
  2. Settings > Add the following registry value.
  3. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
  4. Condition Expression > User Logon Mode = 3.
  5. Condition Expression > Computer Function = Terminal Server.
  6. If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
  7. If condition is FALSE then > Skip this task.
Module Task 4 (Allow reconnections, but prevent new logons) :
  1. Add Task > Registry Settings (Apply).
  2. Settings > Add the following registry value.
  3. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
  4. Condition Expression > User Logon Mode = 4.
  5. Condition Expression > Computer Function = Terminal Server.
  6. If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
  7. If condition is FALSE then > Skip this task.
Module Task 5 (Allow reconnections, but prevent new logons until server is restarted) :
  1. Add Task > Registry Settings (Apply).
  2. Settings > Add the following registry value.
  3. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
  4. Condition Expression > User Logon Mode = 5.
  5. Condition Expression > Computer Function = Terminal Server.
  6. If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
  7. If condition is FALSE then > Skip this task.

Once you have created the module, when you come to schedule the job its then a simple matter of selecting which logon mode you would like to apply from the job parameters. Of course you can schedule the job on individual, multiple or teams of agents.


To make life even easier I’ve created a handy building block that you can import into your environment.

[wpdm_file id=6]

Any questions just ask.



Patch Management with RES Automation Manager

It’s a question that I get asked; lots. As you may well know my stock answer to nearly all questions is “YES! However…” In this particular case I’m going to stick with my stock answer and I’ll explain why here.

Using RES Automation Manager to manage application deployment and patching is absolutely the right thing to be doing, but not for Microsoft products, i.e. Windows and Office updates etc. RES Automation Manager provides us with the advanced scheduling capabilities that are required when deploying updates. We can send feedback to users, control reboots and also create our own dependencies and prerequisites using the built-in Conditions. Creating installation and/or update modules for Adobe Reader, Flash and Java etc. is a fairly straightforward process.

So why can’t we use RES Automation Manager for MS updates? Let’s get one thing clear – there is nothing stopping you from doing this. However, do you really (and I mean REALLY!) want to be creating modules for every hotfix, patch and Service Pack that Microsoft releases? What about controlling installation orders and prerequisites? What about testing and ensuring the update is really needed before attempting to install it? When I last checked WSUS for Windows and Office updates I think there was more than 20,000+ updates. Hopefully you get the point!

What can we do then? By leveraging the metadata that Microsoft has already created we don’t need to and I’m guessing the product teams inside Microsoft are the best people to create this information! We use WSUS internally to manage our patching for Microsoft products on clients, servers, hosted servers and training labs. We recommend that our customers either use WSUS or an existing patch management tool if one is already in place. We then manage all other application installations and updates as Modules within RES Automation Manager and use its advanced scheduling capabilities to push them out.

Surely if we’re going to implement WSUS for Microsoft patching, it would make sense to patch all our products with an extension to WSUS? Not necessarily. Remember you’re getting a whole load more with RES Automation Manager than just pushing out patches; think Run Books and Evaluators. We can deploy software and machine configurations, provision resources such as Active Directory accounts and Exchange mailboxes and a whole lot more.

For those that want to extend WSUS there are products available in the market to integrate 3rd party patches such as Adobe and Java. Check out the EminentWare web site for one such example. You can roll your own application updates as well with the free Local Update Publisher on SourceForge.

At the end of the day, if you have to package a single internally developed application or products not supported with 3rd party tools you might as well extend that list to common middleware such as Flash and/or Java as save the money on the 3rd party integration. Leverage WSUS for what it’s good at and use RES Automation Manager for what it’s very good at; the rest!

Add computers to a local group using RES Automation Manager

One of the many built in tasks that are provided in RES Automation Manager is the ablility to add users or groups to a local group on a server or desktop. The task does what it says on the tin but one unknown fact (well to me at least until I tried it) is you can also add computers to a local group too using the same task. A very simple example of this would be when using Remote Desktop Services and the Remote Desktop Connection Broker. In this example each Remote Desktop Session Host that is participating in the farm needs to be added to a local group on the Remote Desktop Connection Broker called “Session Broker Computers”.

To add a computer to the local group you simply need to add a dollar ($) after the computer name in the “User(s) and/or group(s) to add” field as you can see in the screen shot below.

It’s as simple as that!!


Automation Manager 2011 – Master Dispatchers

RES Automation Manager (AM) Master Dispatchers now enable an administrator to remove replicated SQL instances that have historically been used for scalability purposes. In prior versions of RES Wisdom, if two or more dispatchers are deployed over a WAN link it was recommended to place a replicated SQL instance on the remote site. The reasoning behind this was sound. As every Dispatcher talked directly to the SQL database placing two Dispatchers would require the resources to be downloaded twice. If we replicated the SQL database instance the resources would only traverse the WAN once as the Dispatchers would get their resources from the replicated SQL database instance.

Unfortunately the replication was only supported by Microsoft SQL Standard and up. Microsoft SQL Express was out the question so we had additional licensing costs. The setup and maintenance of SQL replication is also complicated and generally requires dedicated DBAs. Adding SQL database instances in large environments with many sites was challenging. Note: In large RES Wisdom/Automation Manager installations a replicated SQL instance is still highly recommended for resilience.

Enter 2010 and RES Automation Manager 2011! The new Dispatcher (now known as an “Engine”) model now includes the notion of Master and Slave Dispatchers. We don’t need to configure the Master Dispatchers per se, but we can point a “Slave” Dispatcher at a particular “Master” Dispatcher (or Master Dispatcher List). Now if there is more than 1 Dispatcher required at a remote site, we configure all but one as Slaves and the resources are only downloaded once over the WAN via the Master Dispatcher. The “Slave” Dispatchers download their resources from their Master Dispatchers; no more additional Microsoft SQL licensing and no need for DBAs (if you don’t already employ them!).

From a “RES Wisdom/Automation Manager Service Provider” (RAMSP – yes I did just make that acronym up!) point of view it now means you can protect your SQL instance and configure all remote Dispatchers as Slave Dispatchers, pointed at the hosted Master Dispatchers. Only the hosted Master Dispatchers will ever need to talk the SQL database improving security and reducing the number of open ports.

Note: It is possible and supported to daisy-chain or tier the Engines. I have no confirmation on the official tested/support limits, but being able to tier the AM Engines to two or three levels deep should enable us to support even the largest infrastructures (just wish Workspace Manager used this model Smile). Kudos RES!

Automation Manager 2011 – Evaluators

One of the major failings of RES Wisdom 2009 (and prior) was the inability to automatically action the results based on a query. For example, there has never been an easy way to defragment computers if the local drives were above a threshold. We could always automate the querying of machines and automate the defragmenting of disks drives, but basing an action on the results of a query involved manual intervention.

Some if this has been remedied in RES Automation Manager 2011. The list of queries that support the new “Evaluators” is limited, but it certainly a good start and hopefully this list will grow in future Service Releases (or are they now Service Packs?) and/or RES Automation Manager releases. These are the query types that are supported:

  • Query Computer Properties
  • Query Disk Space
  • Query Installed programs
  • Query Service Properties
  • Query TCP/IP Properties

This new feature provides us with an additional tab on particular queries. We can evaluate (now you know why they’re called Evaluators!) the results of the query and set whether query is successful or not. RES Automation Manager 2011 will fail the task if the evaluator fails our criteria enabling us to have some logic control. Note: setting Evaluators automatically sets the job to “Continue On Error” where the normal default is “Stop On Error.” Unlike Conditions, Evaluators are evaluated after the task and not before (like Conditions).

The example RES provides in the Help takes a Windows Installer job that queries the amount of disk space first. An Evaluator can be set to fail the query and the job (assuming you alter the task error control). Here is an example of this Evaluator that will fail the query if there is less than 500MB of free disk space.


If we alter the task properties like this then we can fail the job as a whole (which we would probably do in this instance):


Notice that we still can’t do this with the disk defragmentation example at the beginning of this post as it’s not a supported query type!

Note: If the query fails the job as a whole is reported as failed which makes managing by exception difficult when evaluators are used and clouds the job results view. Hopefully this behaviour will be updated (tested with the Release Candidate) in the RTM or a Service Pack release.

The Power Of 3

With the release of RES Wisdom 2011 hopefully dropping in our laps by the end of this calendar year, I thought it would be wise to revisit the Orchestration Pack for Wisdom. Having delivered many, many training courses this year, it is something that is discussed during both the RES Wisdom 2009 and RES PowerFuse 2010 courses. However, that is it – generally it is just a passing mention! I think this will be changing with RES Wisdom 2011 so we’d better get to grips with it.

RES Orchestra was always going to be the 3rd product in the RES Software suite, but RES instead rebranded it and announced it as an add-on for RES Wisdom (announced back in August 2009). The theory behind the Orchestration Pack is to be able to add business logic and workflows to both RES PowerFuse and RES Wisdom. When all three products are combined together we end up with a very powerful solution, driven by the business and not the IT department.

At a high level we define a “Catalog” of “Services” that are available to “Subscribers”. These Services could be anything that the business offers that requires some automated process and/or workflow to be performed (you’re only limited by your imagination). To get you off to a flying start we normally start with the basics; like granting access to applications or provisioning of a new user. These are IT related tasks, but they help you “get what Orchestration is all about.”

Let’s take our typical RES Wisdom Run Book example; provisioning a new user. You might have a Run Book defined within RES Wisdom that creates the user account in Active Directory (and configures it), creates their Exchange mailbox, creates the user’s home directory and then secures it. In addition you may have multiple Run Books that adds the user account into different sets of AD groups or creates MS SQL accounts depending on the user’s role.

Here is a “typical” new user (with RES Wisdom) workflow:

  • A manager in the business requests a new employee.
  • HR authorises the request and passes the request to IT.
  • IT provisions the user (via the RES Wisdom Run Book!).
  • IT adds the user to the relevant AD groups for the proposed role (via another RES Wisdom Run Book(s)).
  • IT send the details of the new user account to HR.
  • HR forwards the details back on to the requesting business manager.

In the above example, the RES Orchestration Pack will enable us to encapsulate the business logic and the workflow processes via the Orchestration Client (32-bit client executable) or via email and the Orchestration Web Client (hosted on IIS). We can offer the “New Employee” “Service” via the “Catalog” to the business managers. The RES Orchestration Pack will allow the business manager to complete the new starter request via an internal web site (with all the required new starter information) and automatically notify the HR department. Once HR approves the request, the RES Wisdom Run Book is automatically started to create the AD user account and mailbox etc. Once complete the details of the user account can then automatically be sent back the business manager.

We can take this process further and define what happens when the “New Starter” request is reversed. Now we have the power to start an alternative Run Book to decommission the user account when initiated by HR.

So what about “The Power Of 3?”, I hear you ask. We can connect the RES Orchestration Pack to RES Wisdom, but what about RES PowerFuse? Well, it’s good news here too. Within RES PowerFuse 2010 we have the ability to assign access control principal to a RES Orchestration Pack “Service”. When a “Service” is provisioned/authorised then we can grant access to RES PowerFuse 2010 applications. Here is a scenario that takes our HR example another step further on:

  • A user can request a “Service”, i.e. Adobe Acrobat.
  • The request is sent to the user’s line manager for approval.
  • If the business manager approves it then a notification is delivered to the account department for recharging.
  • Once a user has been granted access to the “Service” we can now make applications available to the user automatically via RES PowerFuse.
  • We can configure RES PowerFuse to launch a RES Wisdom module to check for the existence of the application prior to launch.
  • If it’s not installed, pop up a message and install it on demand.
  • Once installed, it will launch.
  • If the user is revoked access in due course, RES PowerFuse will not display the application to the user.

Now we can automate the business workflow, authorisation, delivery, presentation and installation of services and/or applications without being involved. The business has the power to decide where and when things happen, not IT. That my good friends, is the power of 3; RES Wisdom, RES Orchestration Pack and RES PowerFuse!