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:

From humble origins comes True Greatness

By Max Ranzau

From the Blast-from-the-Past Dept. A while back I was sorting some old CD medias and I came across one which made me pause for a bit: It was none other than one of the very first publically available versions of a RES product, the PowerMenu 2000 product. Yeah, so this was back in the late nineties, where everything sold better if you put the number 2000 after it :-) Anyway, PowerMenu 2000 was the ancient forerunner of the product of 14 years later, known today as the RES Workspace Manager. The grand purpose of this article is to show you how ahead of it’s time, PowerMenu 2000 really was. Second, here’s a chance for a trip down memory lane to visit the humble roots, of what is today in my opinion one of the most stellar enterprise management software suites on the market today.

My inspiration for ths article came from the well known Chain of Fools video, where the author goes through upgrading from MSDOS 5.0 all the way up to Win7. Knowing the easy upgrade methodology employed by RES from day one, I’m willing to wager the usual bottle of Danish Akvavit (known stateside as battery acid :) that you can do the same with PowerMenu 2000 all the way up to Workspace Manager 2012 in a similar fashion. The only major hurdle to pass here is migrating from PowerFuse 7.03 to PowerFuse 2008 as you had to do a complete datastore migration. In case you’re wondering about that, read this article from the archives. Other than that it’s just upgrading one RES PowerPack or Servicepack to the next.

The PowerMenu 2000 product was launched during the 32bit Winframe/NT 4.0 TSE days, so in order to give the software a compatible fighting chance to actually work, I installed it on an x86 Windows 2003 server and it still ran without a hitch. Fun fact: Now you know the reason why the default name for the RES created folder in the user’s homedrive pre WM SR1 was “PWRMENU”. For the record this folder in current versions of WM is now called Personal Settings.

When installing PowerMenu 2000, it’s noteworthy that the entire ISO with presentations, docs and everything is about the same size as the MSI installer of today: Around 35 MB. Back then we still used InstallShield though. The entire thing was pretty much a next, next finish job, as it still is today:

During installation, we prompted for a fileshare. For those of you unfamiliar with RES history, this share was home of the original FoxPro based configuration settings database. This was the same deal up to and including PowerFuse 7.03, until we went 100% SQL back in PowerFuse 2008. Today RES Workspace Manager supports every MS SQL version from version 2000 and up including SQL Azure, Oracle, MySQL and IBM DB2.

After installation the product could launch straight into the managed desktop executable, which today still is available in Workspace Manager 2012, known here as the RES Shell. There is a still relevant article available here, which shows you how to make use of it to get your Start Menu back on Windows 8. Back in 1999 PowerMenu did not have any support for the native Explorer. This was due to the fact that many customers had up until then been using it on top of Citrix Winframe, which had no Explorer. The user shell with PowerMenu 2000 looked like this:

During launch you’d see these two splash screens. On the left was the original PowerMenu 2000 splash screen, which back then was mandatory. Today’s Workspace Manager obviously allows you to turn it off. On the right you see the original restrictions of running trial mode on the product. Also note the old triangle RES logo – that’s what we looked like back then! :)

At this point you’re probably wondering; okay then, what could this old WM precursor do then? What was it’s operational scope? Well, back then it actually covered several of the main areas that the Workspace Manager of today does, including configuration, performance and a bit of security. One thing that definitely wasn’t in the product then, was any kind of profile management like the User Settings of today. Managing user settings from the profile was however still a pretty new concept then as CCS had barely thought up Hybrid Profiles at that time. Let’s have a look at what the management console (known then as the Enterprise Manager) looked like:

Granted, there wasn’t a whole lot of options back then, however the basic premise of editing a Managed Application within an application tree or list, is a solid concept that lives on today. Even the Audit log was there to begin with. If you notice the blue fields in the upper right they indicate who created and changed the current object and when.

Presuming you know your way around the current version of the Workspace Manager product, you are likely to recognize some features in PowerMenu’s managed applications, which are present in the current releases. Access Control was pretty much the same, although AD and OU’s weren’t supported as an Access Principal back then. This is probably due to the fact that Windows 2000 was barely out of the box at that time…

,

In the lower left corner above, you’ll recognize the license management and enforcement, which still looks pretty much the same in WM, although it now lives on it’s own separate tab in the console. Funny thing here is that the Cost field still to this day isn’t being used for anything just yet. Of interest here as well is the PowerHours/Opening Hours feature. You will find this exact feature (with the same dialog) is still in the WM product under the properties of a managed app, below Access Control | Time Restrictions | Basic tab. Already back then RES did ODBC Datasources. Today it still works in pretty much the same way.

Now, let’s have a look at the PowerLaunch options. The term PowerLaunch is still to this day occasionally being used by yours truly and some of our other oldschoolers, when referencing as a whole things that happen during user logon in Workspace Manager:

Specifically these are things like printer/drive mappings, drive substitutions, registry hacks, environment variables, files and folder created in the users homedrive, and external tasks were already there as well. One thing I’d like to emphasize is the registry editor. It still looks like it’s former self without many changes. Due to the lack of kernal drivers back then, we did not have the Registry Tracing feature, which came later in PowerFuse 2010.

On the same note here is the security option of lore, known as PowerSense. Today the Workspace Manager security model includes subsystems for Process security, Read-Only Blanketing, File and Folders, Removable Devices, Session, URL and layer 3 Network security. The beginnings were somewhat more humble:

Back in PowerMenu 2000, the way that PowerSense worked, was that unauthorized processes were simply killed uppon detection, rather than preemtively blocked at the kernel layer. I believe we already started introducing the original AppGuard kernel driver somewhere in early PowerFuse series 7 in the early 00′s.

Another item of interest is a personal all-time favorite feature of mine, Access Balancing, which has been largely unmodified for 14 years:

While it was originally designed as a login-throttle for Winframe/Terminal Servers, there is a separate article here on how to use it even today to obtain valuable statistics about user logon time. On the topic of statistics, it’s also worth mentioning that PowerMenu 2000 included already then the first pieces of Usage Tracking, known back then as PowerWatch.

There are many interesting little tidbits and mental morsels to savor in this piece of old software. I hope however, with this little trip down memory lane, to have shown you both how far ahead of the curve RES technology was already back in 1999 and at the same time indirectly how amazingly far we have come since then. Not only has Workspace Manager evolved over the years into a fullblown enterprise class management software suite, but let’s not forget about the 5 other product lines which has rolled off the block since then: Automation Manager, IT Service Store, VDX, Hyperdrive and BDA.

I for one can’t wait to see what the next 14 years will bring!

Year of the Smapping Snake?

From the Spammer DeathSquad Dept. Yeah, so the title of the blog was initially a typo, but it made me giggle a bit, so there. This article is just to vent some steam at having to occasionally clear out the gunk in the spamfilters, ranging from poodle viagra to crappy fake eastern european watches. Looking at the blog stats, 2012 was relatively quiet, but it’s clear that spamming is on the rise this year. Already by mid February ’13, we have surpassed the amount of spam attempts for last year: Read more »

All about the Workspace Manager SR2

By Max Ranzau

From the There-We-Fixed-It Dept. Once again it’s that time of year where we get the extra presents that didn’t quite make it under the tree. Today RES Software released the long awaited Service Release 2 for RES Workspace Manager. As always due to that I’m on Pacific time, I’m more or less the last RES guy on the planet to know – but hey – at least I can share the nitty-gritty details with you. This time around you’re in for a treat, as the the update contains a massive overhaul on the Citrix publishing subsystems, among other things. As per usual the Service Release is available to our subscribed customers and partners at the RES Support portal. Now, let’s have a quick look at the most interesting things in SR2:

• Ability to remote publish XenApp published apps ! Yay – this was a personal thorn in my side, as up to now the only way to publish was to run the RES WM console on top of one of the XenApp boxes, as we previously could only communicate with the old MFCOM objects directly underneath. You still need a WM Agent installed on the target publishing XenApp server, as it’s the one doing the handywork. The difference is that now you can publish even from an admin workstation running the WM console.
• Support for XenApp 6.5 WorkerGroups: Another big enhancement on my wishlist. Even though that Workspace Manager has had servergroups for many years providing this functionality back from the early Citrix Presentation Server days, when Citrix finally added a group object in XAS6.5, we of course had to support it, so customers do not have to do double work.
• Cross-Farm publishing: RES Workspace Manager SR2 allows you to publish an XA app across multiple farms. Note that if you’re using Relay Servers, they must be upgraded to SR2 as well for this to work.

There is a few other items that relate to Citrix, which you can read more about in the release notes. Other than that, some other noteworthy items:

• A slew of new registry tweaks to Workspace Manager. The Registry Guide to Workspace Manager has been updated accordingly. See fixes 073 to 066
• Various performance enhancements on Database Connectivity, User Settings and Logon time. Note: There is a specific reghack to boost logon time when offline. 
• A new setting under Setup|Advanced Settings: The option is to quote the release notes; “set delay for network refreshes when network connectivity changes”. This works well where a laptop may change network connectivity within a short period of time, possibly causing unnecessary Workspace Composer refreshes. Also, by configuring a delay, you can ensure that the ‘new’ network connection is fully established before the refresh takes place, preventing long refresh actions. Default value is 0 (zero) seconds, meaning it’s business as usual unless you change it.
• Hiding apps in the startmenu when using merge-mode is now possible when managing the startmenu. Something I’m personally quite happy about, as I got egg on my face during my last training class due to just that :-)
• Several labels and default views have changed as part of decluttering the console. Nothing crucial, but you might just want to glance over the releasenotes to for a heads-up on all items.
• New Zone rule for computer’s AD group membership. This has been a long standing wish of mine since we could check on the site and OU of the computer, so now this part of the big picture is complete.
• New commandline option to export the Network Security log as XML. See this section of the updated WM CommandLine reference for further info.
• Exception tab on Agents: I believe this is a very important piece to understand for designers and architects (which is why it probably deserves it’s own article at some point): The short story about SR2, quoting from the releasenotes, is that Agent-related zone rules set on the Workspace Container are now taken into account when determining the applicability of an exception tab for the node Administration | Agents. This makes it possible, for example, to define different Datastore or Relay Server connections on exception tabs based on Agent-specific properties such as IP address. Note that the following zone rules are not Agent-specific and are therefore not evaluated when defining the Workspace Containers on which to base an exception tab for the Agents node:
  • Citrix Receiver client type
  • Session Type
  • (Partial) terminal server listener name
  • User property
  • VDX / Workspace Extender

  The Workspace Container’s Access Control/Identity is still ignored for exception tabs on the node Administration > Agents; and the evaluation of Workspace Container applicability for an exception tab remains unchanged for all other features and nodes.

• Last but not least is the question on everybody’s lips: Does SR2 support Windows 8? The answer is yes and no. Yes, the software is supported running on Windows 8. Yes, it can now recognize Windows 8 as there’s now OS Zone rules for Win8 and Server 2012. This makes the temporary hack I created in article RG04C obsolete. However SR2 does NOT include management of the Metro/Modern tiles. Aparently there are some things we are working on together with Microsoft in order to make that a reality. Hopefully we’ll see this in the next Service Release.

For now, here are the releasenotes for you to download:

Enjoy!

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 Reference Architecture doc for WM

From the Document Division. Those following me on twitter (@RESguru) saw yesterday the release of the Reference Architechture document for RES Workspace Manager. This document is interesting as it covers many of the questions our partners and customers have had in regards to best practices, the Relay Server, diskspace consumption and bandwidth usage. The document also covers the complete solution scope, making it easier to understand where RES Workspace Manager fits in.

The document can be downloaded here:  

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

Time to get Trained! Calendar for USA 2013

From the Information Injection Dept. It’s my pleasure to present to you the calendars for 2013 RES certification training events in the United States. This time around we are only scheduling classes until end of second quarter. I plan to publish the calendar for the rest of the year around end of Q1. The reason for this is that we are in the process of redesigning the training materials and the curriculum for the big training courses. This is specifically the case for Workspace Manager:

So far the training material was structured according to the 3 product editions;  Personalization and Composition, Advanced Administration and Security and Performance. While this initially seemed a good idea, experience and feedback from all you, our course participants, told us that we needed to re-arrange things a bit. In other words, few people were interested in just learning about the features in one edition – it turned out that all of you wanted the full enchilada! While we are stoked by this, it was also a challenge, since Workspace Manager today is packed chock-full of goodness;  to a degree where it has become hard to cover everything in-depth in the regular 5 days. Add to the equation that consultant managers already were challenged to pulling billable feet off the street for an entire work week, it was clear that something had to change. So that’s precisely what we are doing now:

The bottom line is that later this year we are splitting up the WM courseware into two seperate courses: Workspace Manager Basic and Advanced. Each of these courses will eventually be 3 days, making it more easy on the schedule of the participants. I anticipate we will be ready with the new courses by end of Q2, so in the meantime it’s business as usual, with one slight change: Instead of the 5 days we did all 2012, we now offer the Workspace Manager class in 4 days, as a preamble to the above mentioned changes.

Below is the schedule for the RES partner certification classes for first half of 2013. The course abreviations are as follows: WM = RES Workspace Manager, AM = RES Automation Manager, SO = Service Orchestration (soon to be known as the IT Service Store)

As you may have heard, in 2012 RES Americas appointed and signed the first RES Authorized Learning Center (or RALC) in the United States. We are proud to partner with VDX out of New Jersey. They will be selling RES training classes nationwide to end-user customers, while we here at RES continue to offer training to new and existing partners. Below is VDX’s training calendar for first half of 2013:

Just to be clear, the difference between the certification classes that RES conducts and the classes our global RALC partners offers is that the RES classes are offered free of charge (for now) to new and prospective RES partners only as a part of our ongoing investment in building out the US channel. Besides, for partners above bronze level there is a mandatory certification requirement.

• If you are a new, existing or prospective RES Partner and have interest in training, please contact yours truly.
• If you are a US RES customer interested in attending RES Workspace Manager, please contact Mr. David Ball at VDX.

For more in-depth information about the RES classes in general, see What a training class is supposed to be like. Also, make sure you have a look at the official curriculum on the RES corp web. Finally I have written a training and certification FAQ available here.