Upgrading RES AM Linux Agents

There comes a time when RES Automation Manager Linux agents need upgrading. A typical example is with the GA release of RES HyperDrive. Now that RES Automation Manager 2012 SR1 has been released, there is a newer Linux agent that isn’t (currently) is the RES HyperDrive appliance.

If you’re like me, you’ll want to upgrade this. The Getting Started with RES Automation Manager Agent for Linux guide will point you in the right direction, but unless you’re a fairly competent Linux administrator you may struggle with certain aspects. For example, to upgrade the RES AM Linux agent all you need to do is:

1. Stop the currently installed RES Automation Manager Agent for Linux by using the command /etc/init.d/resamad stop.
2. Uninstall the RES Automation Manager Agent for Linux.
3. Install the new version of the RES Automation Manager Agent for Linux.
4. Start the new RES Automation Manager Agent for Linux.

So there you have it – simple!

I’ll actually take you through the individual steps to upgrade the Linux agent installed in a RES HyperDrive appliance. These steps are equally applicable to any Linux installation but this will no doubt be a common scenario. As an overview the steps required are:

  1. Find installed RES Automation Manager Agent for Linux version;
  2. Uninstall existing RES Automation Manager Agent for Linux;
  3. Copy new RES Automation Manager Agent for Linux;
  4. Extract RES Automation Manager Agent for Linux;
  5. Install RES Automation Manager Agent for Linux;
  6. Configure RES Automation Manager Agent for Linux;
  7. Start the RES Automation Manager Agent for Linux.


Firstly you’ll need to connect to the RES HyperDrive virtual appliance via SSH (see Remotely Administering RES HyperDrive) or connect to the console session.

Uninstall Existing Version

To uninstall the existing RES Automation Manager Agent for Linux you’ll need to find the currently installed version before you can actually remove it. To find the existing version run:

[code]rpm –qa | grep –i res-am[/code]
This will display the current version. Make a note as you’ll need it in a minute or two! Here’s an example screenshot from the RC2 appliance:


To uninstall the agent run:

[code]rpm –e <res-am-agent-version>[/code]

The <res-am-agent-version> is listed in the first command, for example res-am-agent-6.5-0.102354. If successful the agent service should be stopped and the agent uninstalled.

Note: I have seen multiple agents installed in both the RC2 and GA releases. It looks like an oversight and the 6.4-2 version is not actually installed. If you want to remove both entries then the second rpm –e command may give you an error but it will be removed from the list.

Copy Agent Files

You will need to download the latest Linux agent version from the RES support portal as they’re not included in the management console like the Windows clients. Once you’ve downloaded the tarball, copy it to the RES HyperDrive appliance (see Transferring Files to RES HyperDrive) into the /home/hyperdrive directory.

From your SSH/console session run:

[code]mv /home/hyperdrive/res-am-agent-<version>.tgz /tmp[/code]

This will move the file into the /tmp directory. Note: If you don’t have permissions to do this run the ‘su –‘ command first, enter the root password and try again.

Extracting the Agent Installer

As the RES Automation Manager Agent for Linux is compressed it needs extracting before it can be installed. Change the working directory and extract the archive by running the tar command:

[code]cd /tmp
tar xvzf ./res-am-agent-<version>.tgz[/code]

This expands the files into the /tmp/AIX, /tmp/RedHat and /tmp/Suse directories. As CentOS is based on RedHat 5 we need to install this agent version. Install the new agent version by running:

[code]rpm –i /tmp/RedHat/Release5/x86_64/res-am-agent-<version>.x86_64.rpm[/code]

Configuring the Agent

To connect the RES Automation Manager Agent for Linux, we either need to enable auto discovery or specify a Dispatcher list. If you wish to enable auto discovery you can configure the agent with the following command:

[code]/usr/local/bin/resamad –d m[/code]

If you wish to specify a Dispatcher run this instead:

[code]/usr/local/bin/resamad –dd<Dispatcher>[/code]

For example, if your Dispatcher was called RESAMDISP01 (with an IP address of you could either run

[code]/usr/local/bin/resamad –ddRESAMDISP01[/code]


[code]/usr/local/bin/resamad –dd192.168.0.100[/code]

Starting/Stopping the Agent

After the upgrade you’ll probably need to start the agent. To do this you can simply run:

[code]service resamad start[/code]

If you check the RES Automation Manager console you should see your agent online. The version shown below (6.00.111676) is the RES Automation Manager 2012 SR1 Agent for Linux.


If you need to restart the RES Automation Manager Agent for Linux run service resamad stop and then service resamad start. Why there is no service resamad restart command I don’t know! If I wasn’t lazy I’d create the required script but as the appliance is supposed to be “rip and replace” I don’t think I’ll bother 🙂

Phew – hopefully someone finds this useful? Iain

Citrix HDX RealTime Media Engine Fails to Install

Since the recent release of the Citrix HDX RealTime Optimization Pack for Lync, one of my colleagues Simon Pettit has been installing and configuring it on our development XenDesktop environment. The Citrix HDX RealTime Optimization Pack for Lync can be installed with both Citrix XenApp and Citrix XenDesktop. In our scenario we’re installing onto Citrix XenDesktop but it is equally applicable to Citrix XenApp. The installation has two install components:

  1. HDX RealTime Connector (HDX RealTime Connector LC.msi) that’s installed on the XenDesktop virtual machine;
  2. HDX RealTime Media Engine (Citrix HDX RealTime Media Engine.msi) that should installed on the endpoint device connecting the XenDesktop virtual machine.

Once Step 1 had been completed, we were then in a position to complete Step 2 – and this is where I started to have issues. No sooner had I started the installation I was faced with this warning message.


Now I knew for a fact that I had the Citrix Receiver installed and working so the warning message was infact lying!! – but why?

So I next decided to crack open the MSI, in one of my must have tools InstEd, and see what logic the MSI was using to determine why the Citrix Receiver wasn’t installed. The first place I always look is the CustomAction Table; this is where some ISVs love to try and cheat the built-in methods within the Windows Installer, i.e. using the AppSearch Table and a like. Please don’t use Custom Actions; I hate them with a passion?!

Looking in the CustomAction Table we can see two actions “CheckCitrixPluginVersion” and “CitrixPluginNotFound” which look like our culprits. You should also probably notice the source of all this evil is coming from the file “Install.vbs”.


The “Install.vbs” file can be found in the Binary table where such evils are normally hidden Devil!! Now as this file is embedded into the MSI, we CAN’T easily see what logic the ISV has implemented. Did I mention, that this is why I hate them with a passion Angry smile?


Now luckily we can use InstEd to export the contents of the table by simply right clicking on the table and selecting “Export Table” (and selecting the location where to export the table to). If we now browse to the destination folder we will see a “Binary” (named after the table name) directory which will contain the files in the Binary table.


We can now open the file up in our favourite text editor and take a peek inside to see what’s going on. So lets look at the contents of this file:

[code]Sub CheckRunningApp()

Set objWMIService = GetObject(“winmgmts:\\.\root\cimv2”)


Set colProcesses = objWMIService.ExecQuery _

(“SELECT * FROM Win32_Process WHERE ” & _

“Name = ‘MediaEngineHost.exe'”)


If colProcesses.Count > 0 Then

Session.Property(“APP_RUNNING”) = “1”

End If

End Sub


Sub CheckCitrixVersion()

Dim strComputer

Dim oReg

Dim strKeyPath

Dim strCitrixReceiverVersion

Dim strMinCitrixReceiverVersion

Dim strCitrixInstallFolder

Dim strKeyCitrixPathPath

Dim strKeyCitrixVerPath

Dim bHasAccess

Const HKEY_LOCAL_MACHINE = &H80000002


strComputer = “.”



strCitrixInstallFolder = “”

strKeyCitrixPathPath = “”

strKeyCitrixVerPath = “”



Set oReg = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” & strComputer & “\root\default:StdRegProv”)

strKeyPath = “SOFTWARE\Wow6432Node\Citrix\ICA Client”

oReg.CheckAccess HKEY_LOCAL_MACHINE, strKeyPath, &H20000, bHasAccess


if (Err.number=0 and bHasAccess=true) Then

strKeyCitrixVerPath = “SOFTWARE\Wow6432Node\Citrix\InstallDetect\{A9852000-047D-11DD-95FF-0800200C9A66}”

strKeyCitrixPathPath = “SOFTWARE\Wow6432Node\Citrix\Install\ICA Client”



strKeyPath = “SOFTWARE\Citrix\ICA Client”

oReg.CheckAccess HKEY_LOCAL_MACHINE, strKeyPath, &H20000, bHasAccess


if (Err.number=0 and bHasAccess=true) Then

strKeyCitrixVerPath = “SOFTWARE\Citrix\InstallDetect\{A9852000-047D-11DD-95FF-0800200C9A66}”

strKeyCitrixPathPath = “SOFTWARE\Citrix\Install\ICA Client”

end if

end if


if(Err.number=0 and bHasAccess=true) then

oReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyCitrixVerPath, “DisplayVersion”, strCitrixReceiverVersion

if (StrComp(strCitrixReceiverVersion,strMinCitrixReceiverVersion)>=0) Then

Session.Property(“CITRIX_VERSION_112”) = “1”


Session.Property(“CITRIX_VERSION_112”) = “0”

End If


oReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyCitrixPathPath, “InstallFolder”, strCitrixInstallFolder


if (Err.number=0) Then

Session.Property(“CITRIX_PATH”) = strCitrixInstallFolder


Session.Property(“CITRIX_PATH”) = “0”

end if


Session.Property(“CITRIX_VERSION_112”) = “0”

Session.Property(“CITRIX_PATH”) = “0”

end if

End Sub


Sub SetMEHostLocationsValue()

installPath = Session.Property(“INSTALLDIR”)

If IsNull(installPath) Or Len(installPath) = 0 Then

Exit Sub

End If


locationsStr = Session.Property(“MEHOST_LOCATIONS_ENTRIES”)


If IsNull(locationsStr) Or Len(locationsStr) = 0 Then

newLocVal = installPath


tempVarStr = Session.Property(“%TEMP”)

If Not IsNull(tempVarStr) and Len(tempVarStr) > 0 Then

newLocVal = newLocVal + “;%TEMP%”

End If


If InStr(locationsStr, installPath) = 0 Then

newLocVal = installPath + “;” + locationsStr


newLocVal = locationsStr

End If

End If


Session.Property(“MEHOST_LOCATIONS_ENTRIES”) = newLocVal

End Sub[/code]

Now I’m not going to talk through the logic of the VBScript line by line as you can do that yourselves. However, I will draw your attention to these bits:

[code]strKeyPath = “SOFTWARE\Wow6432Node\Citrix\ICA Client”
oReg.CheckAccess HKEY_LOCAL_MACHINE, strKeyPath, &H20000, bHasAccess[/code]


[code]strKeyPath = “SOFTWARE\Citrix\ICA Client”
oReg.CheckAccess HKEY_LOCAL_MACHINE, strKeyPath, &H20000, bHasAccess[/code]

You can see the VBScript is checking in HKEY_LOCAL_MACHINE for the existence of certain registry values that determine if the Citrix Receiver is installed (or not) and setting Windows Installer Properties that instruct the MSI to display the warning message we originally received.

Having now found out where it is determining this information, I checked those related HKLM registry keys on my local machine and surprise surprise, they weren’t there! So it’s taken me a while to find out why I’m getting the warning message (I could have potentially just used ProcMon when running the installer – but this blog also gives you some handy insight into the workings of Windows Installer Winking smile). Interestingly those very same registry keys are present in HKCU!


I hope you’re still with me? If you are, it begs the question “why when I installed the Citrix Receiver did these registry keys appear in HKCU?” If you were looking at the above screen shot very closely, you will also notice that the Citrix Receiver files are installed into my profile too!?


Well as it turns out the answer is simple, if not flawed in my view (but that’s another post). I installed the Citrix Receiver as my “standard” user account i.e. no admin privileges and as such the Citrix Receiver installed the files into my profile and registry keys into HKCU. The HDX RealTime Media Engine installer is obviously unaware that this is at all possible hence why its only checking HKLM.

So in conclusion, for the HDX RealTime Media Engine install to work without the warning message, you need to have installed the Citrix Receiver as an administrator. This will ensure the files are installed into either “%ProgramFiles%” or “%ProgramFiles(x86)%” and the registry keys into HKEY_LOCAL_MACHINE. If you’re (thinking of) operating a BYOC scheme you will probably need to be aware of this as your users won’t be and who knows what they’re doing!

Thanks for staying with me on this one – but I hope it was worth the wait Smile.


Transferring Files to RES HyperDrive

As I’ve discussed previously, connecting the RES HyperDrive appliance via SSH is more involved than is typical for other Linux appliances. My assumption is that, as SSH is used by OS X clients and is exposed to the big bad world, it needs be secured. And tightly!

I have come across numerous times that I’ve needed to transfer files to or from the virtual appliance. This normally involves copying SSL certificates and keys and grabbing log files etc. Various people have asked me how they can achieve this so I thought I’d document the process. It’s fairly straight forward and assuming you have have your SSH private key and have downloaded WinSCP (or your SCP client of choice) you’re all set. WinSCP will transfer files over SSH and therefore, the process is almost identical to the earlier Remotely Administering RES HyperDrive post.

Note: If you have RES Automation Manager 2012 deployed then you can always transfer files to the appliance with the built-in Linux/Unix Resource Download task. If you don’t or want to know how to do this manually, feel free to continue..

After launching WinSCP you need to enter the connection information. Enter the hostname/FQDN, port number, username and private key as highlighted below (replace the hostname accordingly!). Make sure that you enter the username as hyperdrive and leave the password blank!:


When you connect by clicking the Login button you’ll be asked whether you trust the server’s key, so go ahead and do so. Once connected you should be able to transfer and drag ‘n drop files from left to right.


As we’re connecting as the hyperdrive user account we can only really copy files into the hyperdrive user’s home directory (/home/hyperdrive). After you’ve copied the files into the home directory you’ll need to move the files via the command line, i.e. via the console/SSH (don’t forget to change the owner and permissions as required!). Reading files is generally less of an issue, but you might need to relocate them into the /home/hyperdrive directory before you can copy them out; diagnostic or log files for example.

Good luck! Iain

Remotely Administering RES HyperDrive

Connecting and administering a RES HyperDrive appliance can be frustrating the first time you try. Therefore, I thought I’d put a few notes together on how to connect and transfer files to the appliance. If you’re planning on deploying SSL wildcard certificates, you’re going to need to know how to do this. Whilst you can always use the XenServer or vSphere console, connecting via SSH has many benefits.

The first thing to realise is that the HyperDrive appliance listens on port TCP port 80 for Windows client synchronisation and TCP port 8080 for OS X/Mac client sync. The OS X client tunnels over SSH and therefore the default SSH (TCP port 22) is not used.

Secondly you will also need the SSH RSA key to connect. After successfully completing the configuration wizard, you are offered the option to download the PuTTY or OpenSSH keys. Don’t worry if you never saved these somewhere safe as you can always download them later from the https://<ApplianceFQDN>/va/keys/putty or https://<ApplianceFQDN>/va/keys/rsa URLs (this doesn’t appear to work on the RC release). Notice that you will need to authenticate with the root password to download the keys (notice the typo?!):


Once you have the private key you can configure the PuTTY client. Fire up the PuTTY client and enter the RES HyperDrive appliance IP address or FQDN. You must make sure that the port is set to TCP port 8080.


Before continuing you need to import the SSH private key. Expand the Connection > SSH > Auth node and select the saved key file you downloaded earlier:


When you click the Open button you should be connected to the RES HyperDrive appliance and asked if whether you trust the server’s key:


Click Yes to trust the key and continue. You’ll be prompted for a username. As you’re authenticating with a key you won’t need to enter a password. You may not be aware, but you’re actually authenticating with the local “hyperdrive” user account key. Therefore, you must use a username of hyperdrive to connect. If you enter any other user account, e.g. root, you’ll be denied access.


Once you have access to the appliance you can switch users (SU/SUDO) to perform the required administrative tasks. Enjoy!

Multi-Homing RES HyperDrive

In certain situations you may wish to install two network adapters into a RES HyperDrive appliance. For example, you may not want to route internal traffic via the same gateway interface as external traffic. In this scenario there are some things that you need to be aware of. The RES HyperDrive documentation intimates that the primary NIC is the internet facing interface.

This isn’t necessarily the case and either NIC can be used. What you do need to be aware of though, is that if you configure a default gateway on all NICs, CentOS 5.3 will use the highest interface gateway as the default route. Therefore, if you specify a default gateway on both NICs in multi-homed deployment, the eth1 gateway will be used for the default route. If you look closely at the example above you will notice (there are 2 x firewalls!) that the eth1 interface has no gateway specified. I recommend that you do leave the internet facing NIC with the default gateway, but whether this is eth0 or eth1 is up to you.

If you wish to manually alter the IP addressing information you can find the configuration scripts in the /etc/sysconfig/network-scripts/ directory. There will be an ifcfg-eth0, ifcfg-eth1 for each attached NIC. Use your favourite text editor to update the appropriate file.

Once you have configured the correct IP address(es) and gateway you will need to add static routes to the “internal” network(s). The RES HyperDrive CentOS installation stores static routes in the route-<interface> file in the /etc/sysconfig/network-scripts/ directory. As an example, if our internal networks were and we would create the following entries in the /etc/sysconfig/network-scripts/route-eth1 file (assuming the internal gateway is actually and not!):

[code] via dev eth1 via dev eth1[/code]

Once you’ve made all your changes you can restart the networking stack by running the service network restart or reboot the appliance. If you want to view the routing table, just run the route command. Simples!