Table of contents :

1: Introduction
2: The Workspace Control process in UML
3: Workspace Control and Auto launch usability
4: Special note : Using Workspace Control with Receiver for Web
5: Special note : Using Workspace Control with Linux Receiver
6: Special note : Using Workspace Control with Native Receiver and Mobile Receivers
7: Conclusion

1: Introduction :

In this blog post I will dive a little deeper into the Citrix Workspace Control functionality, I will show you how the Workspace Control process works and what kind of challenges it can bring to the table. For those not familiar with Workspace Control, it’s the mechanism in Webinterface and Storefront that lets users (automatically) reconnect to existing sessions when they are roaming. To start with some basics : Workspace Control can reconnect two types of sessions, Active sessions and Disconnected sessions.

The Workspace Control process is triggered in the following 2 scenarios :

– The Automatic reconnect process when a user logs on to Webinterface or Storefront
– The Manual reconnect process when a user clicks on the reconnect button in Webinterface or Storefront

Workspace Control isn’t triggered in the following scenarios :

– When a user clicks on an application or desktop manually
– When Auto launch is enabled
– When you connect straight to a XenApp server, without using Webinterface or Storefront
– When Workspace Control is disabled, either by admin or user
– When points apply that you will find in the following UML flow diagram in the following chapter

2: The Workspace Control process in UML

Below you will find an UML diagram that will show you the Workspace Control process based on the Automatic and Manual reconnect process. (click to en large)

3: Workspace Control and Auto launch usability

Auto launch is a feature you can configure in Webinterface or Receiver for Web to launch a specific Application or Desktop after a user logs on, this functionality is especially useful when you have only one published desktop.  In this way the user doesn’t have to click the desktop icon, but instead it launches directly after the user authenticates. The downside of auto launch however is that it disables the Workspace Control functionality at logon. This isn’t necessarily a problem when using XenDesktop, but for XenApp this can result in multiple sessions being launched by the user and this is something you often want to prevent, it’s getting more worse when you have session limits in place because this can even prevent the user to login when there is already an active session. To overcome this I often use one of the below two methods, please leave a comment when you use other methods to solve this challenge for XenApp.

1: Restrict users to a single session, Enable Workspace Control and Disable Auto launch
In this scenario the user logs on to Webinterface or Storefront, when there is no active\disconnected session the user clicks on the Desktop or Application and launches his session. When the user logs on from another device, Workspace Control kicks in and reconnects the session immediately after the user authenticates. The user can also choose to manually disconnect and reconnect the session through Workspace Control. In this scenario Workspace Control in combination with Session limits is used to control the number of sessions on the XenApp farm.

2: Allow multiple sessions, Enable Auto launch and use RES session guard
If you have RES Workspace Manager in place, you can leverage the RES session guard feature to notify users of already active sessions and let them disconnect them on the fly. If you educate the user how to use this, session guard can be a real handy feature to simulate a Workspace Control alike functionality. Plus you can also define a group of users (through a dummy  administrative role) that can login multiple times. This is especially handy when you have shared accounts or a couple of users that needs to logon multiple times concurrently. The only down side of this method is that the user needs to login twice when an active session is detected, one time to disconnect the session and one time to reconnect to the disconnected session. The plus side is that you can enable Auto launch to immediately launch the Desktop after the user authenticates, because RES session guard will control the amount of sessions and you don’t have to use Workspace Control in combination with Session limits anymore.

Below is a printscreen of the RES Session guard in action when multiple sessions are detected :

Session Guard detects multiple sessions by creating a lock file (guard.lock) inside the homefolder , the above message is displayed when the file is detected, after the user logs off the lock file is removed.

4: Special note : Using Workspace Control with Receiver for Web

From Storefront version 1.2 the Auto launch feature is enabled by default in Receiver for Web when there is only one published Desktop available for the user, this also means that Workspace Control is disabled by default, but the most important thing to note is that since the separation of Apps and Desktops in Receiver for Web, the Workspace Control functionality is completely disabled in the Desktops section (see below screenshot for clarification). This makes sense when using XenDesktop, but you may still want to use Workspace control for your published XenApp desktops. To enable Workspace Control for published XenApp desktops, you can put a keyword in the published XenApp desktop description field (KEYWORDS:TreatAsApp) so Receiver for Web will treat it as Application instead of Desktop, thus enabling Workspace Control again.

Workspace Control (for the Apps section) can be configured by editing the web.config file in the inetpub directory of the Storefront server, this is a little step backwards because with Webinterface you could do this through the GUI.

5: Special note : Using Workspace Control with Linux Receiver

Linux Receivers found in linux based Thinclients often use the PNAgent site to request and launch published applications and desktops, the key component used here is the PNABrowse utility. PNABrowse is often scripted by the Thinclient manufacturer and embedded in the customized Thinclient OS, like the HP ThinPro and HP Smart Client series. PNABrowse uses the –WR parameter to leverage Workspace Control and connect to active and Disconnected sessions. You can control Workspace Control behavoir for this clients by editing this parameter in the following way :

-WR = Connect to Active and Disconnected sessions
-Wr = Connect to Disconnected sessions only
– Remove –WR = don’t use Workspace Control

There will be a new Linux Receiver released by the end of the year that can connect natively to Storefront without using Legacy PNAgent.

6: Special note : Using Workspace Control with Native Receiver and Mobile Receivers

For the Windows Native Receiver and Mobile Receivers connecting to Storefront, there is currently no good way to configure Workspace Control, it’s always enabled by default. Native Receivers are a good launch platform for published applications and data, but it lacks the option to fine tune them for different access scenarios like Workspace Control or Auto launch, you have to use the Receiver for Web or Webinterface if you want to control this. Also the native Receivers doesn’t make a difference between applications and desktops yet (only apps and data), so Workspace Control will be enabled for both by default which can be a problem. Hopefully Citrix will add more options to control this behavoir in future releases of Storefront.

7: Conclusion

The main goal of Workspace Control is to reconnect published applications when users are roaming, but it’s also often used in combination with session limits to control the number of user sessions and optimize the user experience. It’s clear that Citrix is moving away from Workspace Control when using published Desktops and rather use Auto launch instead, but for XenApp this can be a challenge. You can still leverage Workspace Control in newer versions of StoreFront by treating the published XenApp desktop the same as an published application. Maybe the new Flexcast Management Architecture (FMA), which is part of the upcoming Excalibur release, will change the way how we deliver and reconnect to XenApp published desktops so Workspace Control isn’t necessary anymore to control the user sessions, in the mean time you can either use Workspace Control in combination with session limits or RES session guard to optimize the user experience and control the amount of user sessions in your XenApp farm.

Please note that the information in this blog is provided as is without warranty of any kind.