What’s new in RES Hyperdrive 2.1

By Rob Aarts

The purpose of this article is to go a bit deeper into the latest release of RES Hyperdrive 2.1 so you can familiarize yourself with the new features.

Non-Caching mode for VDI/ SBC environments:
The HyperDrive client can now be installed in “non-caching” mode. This is very useful in SBC or VDI environments. In this configuration no data is being cached locally, instead the client uses a secure WebDAV connection to make your data available. Let’s look a bit more into this:

RES HyperDrive 2.1 introduces a secure WebDAV interface to the RES HyperDrive Virtual Appliance, that provides easy access to drives for apps on mobile devices. This also supports opening and savíng documents from most apps on IOS. This means Apple devices can now open documents directly from a RES HyperDrive drive, without the need for a native RES HyperDrive app. A few notes on this:

• The ‘previous version’ option will be disabled in the non-caching client.
• The non-caching client is only supported for environments in which single sign-on has been configured.
• Non-caching clients can be installed by using the “/NOCACHE” parameter.
• The RES HyperDrive client in non-caching mode on non-persistent desktops works only with centrally managed drive mappings and client settings.

HyperDrive client management made easier:
You can now manage the RES HyperDrive client trough RES Workspace Manager 2012. This is supported from WM SR1 and up. Alternatively you can use Microsoft Windows Group Policies, by way of an ADMX policy template. You can download it from the support portal here. Either way the following items can be managed:

• Client settings
• FileLink settings
• Invite settings
• Logging settings
• Outlook Plugin settings

New administrative dashboard
The configuration wizard in the RES HyperDrive Virtual Appliance has now been enhanced with an Administrator Dashboard to perform basic administrative tasks such as account and drive creation and usage reporting which can display and output to CSV format. With this dashboard you can now manage RES HyperDrive even without an RES automation Manager environment. This is what the dashboard looks like:

New HyperDrive modules for RES Automation Manager

If you happen to have RES automation Manage in place already, you’ll benefit from two new modules which have been added to the building blocks to help you out with configuring the next to new features:

• Disable WebDAV interface: This module disables the new WebDAV interface for the RES HyperDrive clients. This is handy in case you don’t need this functionality.
• Remove Download button from Online Client: This module prevents users from downloading and installing the RES HyperDrive clients on unmanaged systems. Effectively the downlink link will be removed.

Other things that have changed in version 2.1:

During new installations, the configuration wizard now shows the following options:

• Install New Appliance
• Upgrade or Restore Existing

After installation, the Configuration Wizard shows the following options:

• Change Configuration
• Dashboard
• View License Information
  

But wait, there is more!

• You can now assign any drive letter starting from A: and up
• The HyperDrive client for Windows is now digitally signed with an official certificate.
• The Windows HD client also now supports Microsoft Windows 8.
• The Windows HD client also now supports Microsoft Outlook 2013. Note that unfortunately the plugin doesn’t work on a Windows 8 Pro (Surface) x64 with Outlook 2013 x64 – yet!
• RES HyperDrive Clients: Log off from Online Dashboard
• The Virtual Appliance has been upgraded to CentOS 6.3. Other core components such as Apache, PHP and PostgreSQL have also been upgraded to their latest version.
• When upgrading an RES HyperDrive Virtual Appliance by performing a “Rip and Replace”, the appliance now automatically recovers the previously imported SSL certificate.

For more information, see the online administration guide for RES Hyperdrive. It can be found here.

New utility: Printer Migration Wizard

From the Technote Dept. One of the RES developers have been kind enough to share a utility, which may help you import existing printers into Workspace Manager via a BuildingBlock. You can import printers directly from Active Directory or from a CSV file. The tool also supports hooking up printers to zones via the CSV file. This article may be updated with further info, so stay tuned for updates.

<<< Click here to read the article

Fixing a Linux AM agent install problem

By Max Ranzau

From the Mostly Nuts (and bolts) Dept. Today I was messing around with getting the RES Automation Manager SR3 Linux agent (res-am-6.5-3.125079.tgz) installed on a Redhat Enterprise 6.2. However, I ran into a snafu as apparently there were some prerequisites that weren’t met. After unpacking (read Iain’s article here how to do that) – when I tried to install the RPM file (For you Windows folks, that’s the Linux equivalent of a MSI), I got the following error:

# rpm -ivh res-am-agent-6.5-3.125079.x86_64.rpm
error: Failed dependencies:

libcrypto.so.6()(64bit) is needed by res-am-agent-6.5-3.125079.x86_64
libssl.so.6()(64bit) is needed by res-am-agent-6.5-3.125079.x86_64

Searching a bit, it turns out that these libraries become available if you install a certain version of OpenSSL on the computer first. Specifically OpenSSL098e seems to do the trick. I found a place here where you can download it. Once you’ve downloaded the OpenSSL package and saved it onto the Linux box, it’s just a matter of running it with the rpm -ivh command like shown above.

After that, you want to read the getting-started notes for the Linux agent. Really, please read this guide as the rest of this article will make less than no sense if you don’t!

Anyway the getting started guide describes the commands necessary to configure the firewall and it was all well until I tried to get the agent configured and started using the /usr/local/bin/resamad binary. Unfortunately I kept getting a weird error: No configuration file found, no matter what I did. This obviously shouldn’t happen, but hey, it did and this is how I got around it:

I decided to go for broke and try creating an empty config file, betting on the configuration code would be smart enough to build the proper contents (and yes, this works) The guide specifies that the resamad binary looks for it’s config file, which is located in /etc/res/resamad.xml If this file doesn’t exist, for the less UNIX savvy, here’s a quick step by step guide to creating a blank file using the VI editor:

1. cd /etc/res
2. vi
3. press a (to start append mode)
4. hit enter (to add a blank line)
5. hit ESC (to enter vi’s command mode)
6. type :wq (to write and quit)
7. hit enter

Once this file is in place, you should be able to fire up the agent again with /usr/local/bin/resamad -dd<nnn> where <nnn> is the ip address or FQDN of your dispatcher. I tried using the described resamad -d m parameter for automatic detection, but in my case it didn’t work for some reason. It kept reporting; No environment found. Instead I used the -dd parameter to specify the dispatcher. In this regard, if you want to know what’s going on, you can enable a verbose log by adding -v 3 (yes, there’s a space inbetween the v and the 3) as the first parameter before -dd. This will create a verbose log in /var/log/resamad.log.

Once I re-ran the resamad command (which in my case looked like this /usr/local/bin/resamad -ddbackend.demo.lab ), you will be prompted to select an environment. The prompt should look similar to this, displaying the Environment name, configured under the AM global settings:

1.    res-am@backend.demo.lab
Enter value:

Seeing this prompt tells us the Linux AM agent is talking to the dispatcher and has read the list of available environments (typically only one) When you type 1 and hit enter, the configuration file /etc/res/resamad.xml should be populated with settings for this , which might look something like this:

<?xml version=”1.0″?>
<Agent><FirstTryAutoDetect>1</FirstTryAutoDetect><DispatchersList>backend.demo.lab</DispatchersList><DoRetrieveCompleteList>1</DoRetrieveCompleteList><ProtocolEncryption>0</ProtocolEncryption><NetName>res-am@backend.demo.lab</NetName><NetGUID>{5FAFFEF3-245B-42A3-B47B-CEAFB2EF07E}</NetGUID><WUID>{6e1db5ef-b330-47d6-b4d1-92b22e4653af}</WUID><LastAgentStart>2146163056</LastAgentStart><RebootInTask>0</RebootInTask></Agent>

At this point the agent should show up in your Agents node in the AM console after a few seconds. If it doesn’t, chances are that you may need to set up a dispatcher list under Global options, as I did. Once you’ve done that you’ll need to stop the Linux agent. You can use the script located here /etc/init.d/resamad, which take the two parameters start or stop. This is the equivalent of a NET <STOP|START> RESWAS command line on a windows box. Anyway, do the following

• Use /etc/init.d/resamad stop to terminate the Linux AM agent.
• Configure a dispatcher list
• Start the agent again. Instead of /etc/init.d/resamad start, I did instead like before; /usr/local/bin/resamad -dd<dispatcher.fqdn> to ensure the config XML is written.

The last thing to address is that if you’re setting up a Linux box for the first time in your RES lab, you probably want to change the hostname and domain, as the agent per default will show up in the RES Automation Manager console with the name LOCALHOST.DOMAIN. You probably want to change this into something nicer:

1. Edit the file /etc/sysconfig/network (Go VI or go home ;)
2. Change the FQDN to whatever you want
3. Reboot the Linux box. This is necessary. Do it either by Automation Manager, from the Gnome GUI or, issue an init 6 command from the terminal prompt.

Note that while Windows jobs will continue to run, waiting for Windows agents to come back up, when you issue a reboot task in AM, Automation Manager does not wait for the Linux box to resurface before continuing. Either way, when the agent comes back up, the change should take place in the console:

New technote: Creating a Maintenance Shell

From the Technotes-R-Us Dept. How often have you been in the situation that you need to make some changes to some computers out there, but no matter when you try, them pesky users seem to be logging in everywhere at any time! There is of course traditional ways to prevent this, but this article by my fellow RESguru writer Rob Aarts delivers an novel yet effective means to do this. The secret sauce is using RES Automation Manager to deploy and configure a smart little app which is then configured as the shell of the target computer(s). It has other bells and whistles, so you may want to check it out.

Update Feb 11th: Sourcecode for the Maint.Shell executable is now included in the article

<<< Click here to read the full article

New Technote: WM and XA prelaunched apps

From the Community Hero Dept. A new technote has been added to the RESguru Library. This time we are joined by guestwriter Mr. Lasse T. Hohmann, who besides being a former colleague of mine in the past, is a Citrix Systems Engineer at JN Data in Denmark. JN has been running RES for quite a long time and it’s great to be able to share some of their experiences with our products.

The article at hand explains how to use the PreLaunch feature of XenApp 6.5 together with RES Workspace Manager.

<<< Click here to read the article

How NOT to use Workspace Containers

From the You’re-doing-it-wrong Dept. This is a little quick and dirty techpost to hopefully help some of you folks who are learning the ropes with Workspace Manager. One of the very powerful features in WM is the Workspace Container object. You can think of these types of container objects as being to Workspace Manager, what OU’s are for Active Directory, but they can do so much more. For your convenience, I’ve listed none less than 6 different real-world examples in article RG037 – Workspace Containers Inside-out.

<<< Click here to read the rest of the article
 

Technote: Workspace life on Windows 8

From the Flux Capacitor Dept. I don’t know about you, but it seems to me that once every now and then, time loops in on itself in this line of work. While you don’t need a Delorean to experience it, this is the story of how an almost antiquated piece of code within the RES Workspace Manager suddenly saw itself repurposed by some of our customers to deal with Windows 8′s Metro interface.

My good friends in product management would probably whack me over the head, but hey – there’s nothing preventing anyone from obtaining a trial Workspace Manager 2012, slapping it on a Win8 and writing about it. So, rather the devil you know I guess. Anyway, this is not a comprehensive wall-to-wall test to see what floats and sinks, as RES Workspace Manager 2012 at the time of writing DOES NOT officially support Win8, but that’s expected in January 2013. Note: Automation Manager actually does support Win8 with 2012 SR3 at this time. Update per March 2013: With the release of Workspace Manager 2012 SR2  Windows 8 is supported..somewhat. See this article for more info.

<<< Read the full article here

Defeating a live virus/trojan infection with AM

By Max Ranzau

From the Crush, Kill & Destroy Dept. This is an aricle about using RES Automation Manager to defeat a live virus infection and cleaning up the colatteral damage afterwards, in case you’re dealing with many computers. With the help of others, I’ve put together a solution, as well as providing some valuable generic takeaways, like how to change special permissions in the registry and how to use the Windows PendingFileRenameOperations queue from within Automation Manager.

<<< Click here to read the article.

Detecting Windows 8 in a WM Zone

From Bats in the Attic Dept. If you’re mad enough to consider deploying Windows 8 Release Preview with Workspace Manager 2012 on top, you are indeed a Mad Hatter, as this isn’t supported yet. But hey – join the party on the funny farm! :-) I did it for the heck of it and will be sharing my experiences in an upcoming article. In the meantime I thought I’d share a nugget, which might help you if you’re contemplating this combination.

<<< Click here to read the technote

The RES Relay Server

From the Skunkworks Dept. As we are approaching the release of Workspace Manager 2012 later this year, here's a sneakpeek into the goodiebag of good things to come. Specifically I've taken the RES Relay Server for a spin and kicked the tires in the lab, in order to give you a better understanding of what this thing is. This technote article should hopefully help you gain a better understanding on what new options we will have at our disposal for designing tomorrows workspace solutions.

<<< Click here to read the article

While we're at it, I've updated an old article RG004 – Workspace Manager commandline parameters, so it reflects the new parameters to unattended configure a Relay Server connection for a Workspace Manager 2012 agent. Click here to see the updates.