RES – Page 4 – Virtual Engine Ltd

2nd November 2011

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.

Workaround

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

3rd August 2011

Disabling RES VDX

If you’re like me you spend a lot of time on customer sites and a vast amounts of time using the RDP client to connect to various client machines and servers. It may just be me, but I find the whole RES VDX popup notification when starting an RDP session rather distracting. It’s fine if the client has the VDX Engine installed in the hosted desktop, but more often than not they don’t. Worse still, when integrating RES Workspace Manager with VDX it becomes even more frustrating when connecting with Admin accounts as, typically, the RES Workspace Composer is disabled. This results in VDX connecting in “time trial” mode, bringing the local applications through into the remote session and then dropping them with a pop up notification. Grrrr!

It’s for this very reason that I set off looking for how to disable the integration and allow me to re-enable it if necessary for testing. I checked the available Administration Pack but it doesn’t allow us to suppress the notification so off I went to Google. It didn’t take too long to find out where the RDP and ICA add-in settings are stored in the registry. The ICA key is only created if the Online and the locations are different for RDP and ICA..

RDP
Key 32-bit/64-bit: HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RESVDX
Value: Name
Type: REG_SZ
Data 64-bit: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x64.dll
Data 32-bit: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll

ICA
Key 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\RESVDX
Key 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\RESVDX
Value: DriverNameWin32
Type: REG_SZ
Data: VDXICAPlugin.dll

The simplest solution I’ve found is to rename the plugin DLL references in the registry so they’re not loaded. Renaming the individual registry keys doesn’t appear to work as the Add-In keys are still enumerated even though the key names have changed. I, for example, rename the above .dll filenames to .dl_ in the registry to disable the integration and set them back when needed. I have 2 .REG files; one to disable the integration and one to enable to make my life easier because I’m like that!

1st August 2011

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.

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

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

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).
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.
That’s it, you’re done.
Finally, you could configure a job to check each service and email the results.

29th July 2011

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

29th July 2011

Quest vWorkspace and RES VDX Integration

We’ve come across some issues with the integration of RES VDX and Quest’s vWorkspace on a couple of customer sites just recently. Some old timers might remember an issue that occured when using the then, RES Subscrber/Workspace Extender, with Provision Networks Virtual Access Suite (VAS). The issue fixed by Q201760 RES Subscriber and RES PowerFuse Workspace Extender do not work with Provision Networks VAS is the same issue experienced with vWorkspace.

Both the legacy VAS client and the newer vWorkspace client are virtually the same and the registry key is still called ‘HKLM\Software\Provision Networks\Terminal Server Client\’. However, to integrate the newer VDX components we need to reference the newer VDX DLL(s) rather than the Workspace Extender DLL.

To get the VDX integration to work with vWorkspace we need to create one of the following keys on the local machine. Note: these registry keys are HKEY_LOCAL_MACHINE.

For 32-bit clients:
KEY: HKLM\Software\Provision Networks\Terminal Services Client\Addins\RESVDX
VALUE: Name
TYPE: REG_SZ
DATA: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll

For 64-bit clients:
KEY: HKLM\Software\Wow6432Node\Provision Networks\Terminal Services Client\Addins\RESVDX
VALUE: Name
TYPE: REG_SZ
DATA: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll

Simples once you know how! Iain

27th July 2011

Using Software Restriction Policies to Block Scripts

When we are implementing RES Workspace Manager POC/Pilot’s on a customer’s site, one of the first things we try and do is create an new AD organisation unit (OU) where our test PC’s or XenApp/RDS servers will be placed. One of the reasons we do this is it allows us to block any existing AD group policies (GPOs) that might impact the POC e.g. startup/shutdown/logon/logoff scripts; especially as these might be the cause of slow logins that we are trying improve using Workspace Manager.

For computer related GPO’s we use “block inheritance” on the new OU. For user related GPO’s we employ the “GPO loopback > replace” technique.

These methods work very well but something I’ve come across on customers sites, they have set the login script in the AD properties for each user and not within any GPO that you are trying to block as you can see in the screen shot below. Generally this is the “old school” method of doing this but its still out there!

This causes us some headaches in our POC/Pilot especially when these users are asked to start testing the POC/Pilot and the first thing that happens is they start complaining that it takes an age to login. Why? Because the script is mapping 24 network drives and 15 printers at logon!!

Therefore, we need to stop this script from running on our POC/Pilot environment. We could do this by simply removing the line from their AD properties but what happens if they still want to use the existing environment that relies on this script to map drives and printers? We need to find another way of doing it…in steps “Microsoft Software Restriction Policies”.

Using Software Restriction Policies will allow us to block these logon scripts without affecting the users ability to use the existing environment and here is how.

Firstly we need to add the Software Restriction Policy to a GPO which will allow it to apply; the easiest way to achieve this would be to add it to the new GPO we have created in the first instance that applies the computer related settings.

Using the Group Policy Management Console (GPMC) edit the GPO and expand the “Computer Configuration/Windows Settings/Security Settings/Software Restriction Policies”

Right click on “Software Restriction Policies” and select “New Software Restriction Policies”.

At which point the you will see some additional settings available.

Right click on “Additional Rules” and select “New Path Rule”.

You now need to tell the policy what path to block scripts running from. Most lightly these scripts will located in the NETLOGON share on your domain controllers (DC); the problem now being which DC will the script run from should you have more than one DC in your environment. Easy we can use the %LOGONSERVER% environment variable that is used to store the logon DC used by the user who is logging on. The Security level should obviously be set to “Disallowed”.

That’s about it!! Now when you logon to the POC/Pilot environment you can be sure any unwanted logon/logoff scripts will be blocked from running.

Nathan

20th July 2011

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

Add Task > Remote Terminal Server Logons.
Settings > Enable Logons.
Condition Expression > User Logon Mode = 1.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 2 (Disable Logons) :

Add Task > Remote Terminal Server Logons.
Settings > Disable Logons.
Condition Expression > User Logon Mode = 2.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 3 (Allow connections) :

Add Task > Registry Settings (Apply).
Settings > Add the following registry value.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“TSServerDrainMode”=dword:00000000.
Condition Expression > User Logon Mode = 3.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 4 (Allow reconnections, but prevent new logons) :

Add Task > Registry Settings (Apply).
Settings > Add the following registry value.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“TSServerDrainMode”=dword:00000002.
Condition Expression > User Logon Mode = 4.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 5 (Allow reconnections, but prevent new logons until server is restarted) :

Add Task > Registry Settings (Apply).
Settings > Add the following registry value.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“TSServerDrainMode”=dword:00000003.
Condition Expression > User Logon Mode = 5.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
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.

Enjoy

Nathan

14th July 2011

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 3^rd 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 3^rd party tools you might as well extend that list to common middleware such as Flash and/or Java as save the money on the 3^rd party integration. Leverage WSUS for what it’s good at and use RES Automation Manager for what it’s very good at; the rest!

11th July 2011

Migrating RES Databases to a New SQL Server

We have recently had the requirement to move the SQL databases to a new Microsoft SQL Server 2008 R2 server. This process is not complicated, but there does seem to be a lack of documentation available. At a high level we need to perform the following actions:

Backup the RES Workspace Manager and Automation Manager databases on the source server;
Restore the RES Workspace Manager and Automation Manager databases on the destination server;
Fix the SQL permissions, i.e. recreate the users and redelegate access;
Update the RES Automation Manager Dispatchers to point to the new database server;
Update the RES Workspace Manager Agents to point to the new database server.

I’m not going to cover Steps 1 and 2 as these are well documented on Microsoft’s web site and many other various blogs. In this particular instance we’re moving from SQL 2008 to SQL 2008 R2 and I’ve restored copies of the Workspace Manager and Automation Manager databases on the new server. The SQL user account for the Workspace Manager database (RES-WM) is ‘RES-WM’ and the user account for the RES Automation Manager database is ‘RES-AM’ (note that naming the database and user accounts the same is not best practice but it helps in our lab environment!).

Migrating RES Automation Manager

We’ll start with the RES AM database as we’ll then use this to update the RES WM information! Firstly we need to check that the correct user permissions have be granted on the new database server. When creating the SQL user accounts you’ll need to ensure that the password policies are set correctly:

In short make sure that the user password policies are disabled (unless you want to be forever updating your Dispatchers!). If you forgot to uncheck this and you can’t seem to change it, you can run the following SQL script via the SQL Management Studio (remember to change the RES-AM reference to your SQL user account!):

USE Master
GO
ALTER LOGIN “RES-AM” WITH PASSWORD = ‘samepassword’
GO
ALTER LOGIN “RES-AM” WITH CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;

After this is complete you will need to ensure that the RES-AM user account has DB Owner (DBO) rights to the database via the “User Mapping” page of the user account:

Once we’re happy with this we can focus our attention on the RES Automation Manager console. As it’s only the RES AM Consoles and Dispatchers that talk directly to the SQL database, we do not need to worry about the RES AM Agents. From the RES AM management console select the Infrastructure > Setup > Database node and enter the new SQL database server name (if the username/password has changed you can update them here).

After you click the Connect button the management console will reload and ask if you want to use the connection information permanently.

The management console will reload. The final piece to this puzzle is to update all the Dispatchers and Consoles. From the Infrastructure > Engines node we need to repair each Dispatcher and update the SQL connection information.

After the Dispatchers have been updated don’t forget to update the consoles in the same manner. You could also run a registry job via AM to update the connection information (remember to do this from the old database as the Dispatchers will communicating with the old database until updated!) or push out a new MSI from the Components node.

Migrating RES Workspace Manager

Note: RES Workspace Manager 2011 has the built-in ability to migrate the exisiting database to a new SQL server and/or database; this can be found in Setup > Datastore > Connections > Click on the ‘…’ next to the Primary datastore to display the migrate wizard. At the end of the migration process after various other prompts you will also be prompted if you wish to create a handy building block that can be used in RES Automation Manager Module. You can use this Module to migrate RES Workspace Manager Agents running an older version of RES Workspace Manager, not yet containing the Datastore Migration Wizard. The only downside using the migrate method I’ve found is the fact you have to activate the licenses again; if this going to cause some issues follow the procedure set out below. [Nathan Sperry]

RES Workspace Manager is slightly different as all RES WM agents talk directly to the SQL server rather than via a Dispatcher. After migrating the RES Workspace Manager database (as above) and fixing the user permission we need to update the RES WM agents’ registry settings via RES Automation Manager! For this task I created a module that updates the required registry value and restarts the RES Workspace Manager agent service.

You will notice that there are two Reigstry Settings tasks with conditions; 1 is for 64-bit machines and the other for 32-bit. Note: if the authentication details have changed you’ll need to the relevant registry settings to both Registry tasks.

Note: if you have a mixture of freshly deployed RES Workspace Manager agents and agents upgraded from RES PowerFuse 2010 or earlier then the registry settings are in different locations and you may have more tasks/conditions!

Iain

27th June 2011

RES Workspace Manager Zones and USB Devices

Have you ever had a requirement to base a Device Zone within RES Workspace Manager on a particular hardware device? If so, you may have already discovered that if is a storage based device then you’re good to go. However, if it’s not of a “removable storage” type then we’re seemingly out of luck. Not quite..

Whilst on a customer site, a requirement arose that necessitated that we detect whether a particular USB device was connected or not so that we could configure an application for the hardware device. After a lot of digging and searching, I discovered that device information is located in the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\ENUM] registry subkey(s). The problem with these registry entries is that if the device has ever been connected then it will exist and it doesn’t indicate that the device is currently connected so it’s back to the drawing board..

On further investigation, the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\Services] key lists all the currently connected devices (all internal devices are listed in here so don’t be too surprised how many there are!). The difficult bit comes in determining how your USB device is enumerated. As a general rule all USB devices attached will probably be listed under keys beginning with USB. For example, the USB microphone I’m using is listed under the ..\Services\USBAudio subkey and a USB printer under the ..\Services\USBPrint subkey (more detail on hunting this information down might be a future blog post). In this instance I’m going to pick on the Samson C03U microphone and show you how can create a Device Zone in RES Workspace Manager that will allow you to set configurations options only when it’s connected. Looking in the registry in the [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Serices\USBAudio\Enum] key exposes the following settings:

I know that my microphone is identified as USB\VID_17A0&PID_0100&MI_00\6&1895ccd4&0&0000. We can see that the Samson microphone is listed in here. When the device is unplugged the instance disappears like so:

So to create our Device Zone in RES Workspace Manager for detecting the presence of a Samson microphone all we need to is create a zone based on the presence of this particular registry setting? Nearly! By creating a zone on the information from the first screenshot, it will only be true for the microphone on my desk, not any Samson C03U mike that might be on someone else’s desk. Experience has shown that everything listed after the ‘&MI_00\6&’ is device specific, i.e. a serial number or unique identifer and can safely be ignored (unless you want to tie the zone to a unique device). Therefore, if we create a Zone based on the presence of the ‘USB\VID_17A0&PID_0100&MI_00&6*’ (note the wildcard) value it should work for all Samson C03U microphones.

Done? Almost (and you knew I was going to say that!). The value of ‘0’ (zero) in the first screenshot depicts the order in which a device is attached. Therefore, if I just so happened to have another USB audio device, the Samson mike might be listed as the second device under ‘1’ or the third device under ‘2’ etc. In order to ensure that we account for this we need to add multiple entries in like so:

If I had 4 USB audio devices, then depending on the order they were attached my Zone may fail to detect that the Samson microphone was attached. I could have added 10 or so entries but hopefully you get the idea! If you have varying models of devices, then it’s likely that the PID_ (product ID) portion of the values will change. In this case, you’ll need to make sure the rules also incorporate any variations.

It would be nice to have pattern matching on the registry keys\values like we have within RES Automation Manager. Perhaps it’s an enhancement request, but in all honesty, why can’t we natively select any hardware devices attached rather than being restricted to USB storage devices already? Perhaps I’ll take this up with product management.

Good luck! Iain