Making sense of Subscribers, Extenders and VDX

From the Confucius dept. In the RES product portfolio you may have come across terms and names such as Subscriber, Subscriber Agent, Workspace Extender etc. and wonder what the heck it all means. While I’ve done my best to document these products and components in the RESpedia, it is time to set the record straight and give you a shortcut to the big picture. Through this article, it is my ambition to give you an easy overview of what each of these items are, and understand the differences. You will find a brief history of the products that eventually led to the development of the VDX product…

Generation I: The Subscriber.

Back in the beginning of the millennium, the technology known today as VDX began it’s life as an add-on component to Workspace Manager. At that time Workspace Manager itself was known as PowerFuse. The add-on component was  known as the Subscriber. The subscriber’s main purpose was to assist customers in turning regular fat client PC’s into thin clients, while retaining the fat-client capability of launching local apps.

When the Subscriber was installed, it acted as a shell replacement – just like PowerFuse itself. This could be configured with the old SetShell utility. When the user logged on to the local computer, the Subscriber could present itself in one out of two ways. Either A) the Subscriber would launch the user straight into their RDP/ICA session by invoking either MSTSC.EXE or WFCRUN32.exe with the appropriate parameters, or B) it would present a customizable menu to the user where he/she could launch the RDP/ICA session manually and start local applications directly. The Subscriber was later along the way outfitted with scores of other features. These configuration items were stored in a file called subscriber.ini and could be managed by running the subscriber.exe with a /config parameter. Here’s an overview of some of these features:

• Ability to locally map network drives and printers from within the remote session
• Configure what happened when remote session ended (logout/shutdown/menu/etc)
• Completely customize the appearance of the local menu including custom logo, skins, menu items, screensaver appearance, clock format, button names etc.
• Ability to autostart specific commandlines upon Subscriber start
• Custom keep-alive and disconnection timeouts.
• Behavior whether to preserve or kill the local explorer running behind the local desktop
• Update all of the above settings centrally via an FTP server

Once a RDP/ICA session was established local applications could be launched by the user, if they had been defined as Managed Applications in the PowerFuse console. This was in fact the core of what would later evolve into VDX. Once a Managed Application had been defined in PowerFuse, an icon could be displayed on the users start menu in the remote desktop. The Managed Application became a Subscribed Application, once the console operator ticked a special box on the Properties|General tab of the managed application in the PowerFuse console. The difference between a regular managed application and a subscribed application was this: When a regular managed application launches, it executes in the session where it was launched. In a TS/Citrix environment, the app would launch inside a session on the server. The subscribed application however, would launch locally.

In the earliest implementation of the Subscriber, the PowerFuse instance running in the server-side session, would send a command via TCP/3163 down to the Subscriber executable running on the client computer, to launch the local executable, defined in the managed application. In later versions, the Subscriber was changed to take advantage of the built-in virtual channels in both RDP and ICA instead so no extra TCP ports beyond the existing display protocol is used.

When the local application was launched, PowerFuse created a faux start menu item for the application, which allowed the user from within the remote desktop to call up the local application and interact with it. Obviously this approach had it’s limitations, as the local app could only be on top of the entire remote desktop, or entirely behind it. Thus, if you clicked on the remote desktop, the local app would disappear behind it. This problem is addressed by the Z-mode technology within VDX to ensure a true local/remote blend experience, as illustrated here on the right:

Generation II: The Subscriber Agent

The subscriber agent rose out of the customer need only to present the subscribed applications into the remote desktop. Where the Subscriber lent itself nicely to kiosk environments and other scenarios where local access was to be severely restricted, the Subscriber Agent did no such thing. It merely sat as an icon in the system tray of the local client and listened for launch commands coming down the virtual channel from the remote session. As for configuration, there wasn’t much to configure on the Subscriber Agent. You basically had the following:

• The Subscriber Agent would look for a file called C:\Program Files\RES Subscriber Agent\subagent.ini. In this file you could add a couple of settings to hide the exit option on the system tray icon and also you could hide the splash screen. Refer to the the ‘Administration of RES Subscriber Agent’ section of the help file, which you can download from the RES KB here.
• In the registry the Subscriber Agent would look in HKEY_LOCAL_MACHINE\SOFTWARE\RES\PFWSExt. Here you can configure how the Subscriber Agent should interact with the local start menu etc. More info on these settings can be found in the RES KB in Q201548 and Q202559.

In short, the Subscriber Agent was minded for environments where you want to preserve the functionality of the local desktop, while extending some of those apps into the remote desktop.

As with the native Subscriber, the Subscriber Agent also relied exclusively on the availability of RES PowerFuse in the other end of the virtual channel, as it was only with PowerFuse Managed applications that a local app could be triggered to launch. Therefore if any new applications were added locally, the administrator would have to create an Managed application, referencing that particular executable and icon, making sure the Run as a Workspace Extension check-box was set.

Generation III: The Workspace Extender

Workspace Extender, sometimes abbreviated WSXs was essentially just a new name given to the Subscriber Agent around late 2008 / early 2009. The Subscriber was never renamed though. At this point in time we started to see a lot of interest to the whole notion of Reverse Seamless operation as VDI and other remote desktop delivery solutions grew in maturity and popularity. Around the same time I wrote a technote RG011, describing how you set up a Workspace Extender demo.

Generation IV: The Virtual Desktop Extender / VDX

This is the new hotness. Workspace Extender could only take the customer requirements for true seamless integration so far. VDX is a complete rewrite from the ground up, redefining the Reverse seamless integration between local computer and remote desktop. The most important differences between VDX and the old products described above, are:

• VDX is stand-alone. Workspace Manager / PowerFuse is not mandatory on the backend for it to work.
• Z-order enables local applications to be perfectly blended into the remote desktop. This effectively allows a local application to display as if it is being sandwiched in between the remote desktop and a remote application
• There is no need to define the local applications to be extended anymore. Default behavior is to extend all locally available applications into the remote desktop.

There are now several great references available online. I have tried to capture the essence of these in article RG033 which describes how VDX works. There is also an in-depth artice about the VDX registry settings available in article RG032. Be sure to check RES Software’s site www.reverseseamless.com.

To wrap things up let’s recap the most important points:

• VDX, Workspace Extender and Subscriber are 3 different installers.
• You may hear VDX being referenced as a technology that covers all 3 products and their capabilities. Keep in mind that VDX is a separate product line.
• Subscriber and Workspace Extender does not have, and will not have Z-mode capability.
• There is no such thing as the Subscriber Agent anymore. It is now known as the Workspace Extender
• The Subscriber is not replaced by the VDX product as it offers other capabilities as described above. The Workspace extender may be of use for backwards compatibility, in legacy environments where VDX licensing is not supported.