Understanding Workspace Control XML and Client Name Communication
Written by Thomas Koetzing at Donnerstag, 09 Dezember 2004
One of the new features of Citrix MetaFrame Presentation Server 3.0 (MPS 3.0) and Web Interface 3.0 is something called Workspace Control. Commonly called “follow-me roaming,” Workspace Control is the marketing term for a set of technologies that allow users to easily connect back into their environments as they roam from computer to computer.
For example, it allows users to automatically reconnect to all their applications from the main screen of the web interface. (For more information about the features of Workspace Control, check out Citrix Knowledgebase article CTX103678, “Frequently Asked Questions about Workspace Control.”)
Workspace Control Requirements
In order to use Workspace Control, you have to be running at least MetaFrame Presentation Server 3.0 and Web Interface 3.0. This is due to the fact that Workspace Control depends on new extensions of the XML and IMA services.
Workspace Control also requires additional intelligence in the ICA client. For example, the client needs to detect whether ICA “pass-through” is being used. If it is, Workspace Control needs to be temporarily disabled since a Workspace Control disconnection or logoff would also affect the ICA “pass-through” session.
All this means that you’ll also need at least version 8.0 of the ICA client to use Workspace Control.
How Workspace Control Works
When a user decides to either disconnect or logoff of their “workspace” in a Workspace Control environment (by clicking the appropriate button in their web browser), an XML request is passed from the Web Interface server to the IMA service on the MetaFrame server. That IMA service contacts the IMA service running on each server where a user has sessions running. It then responds back to the Web Interface with a success message when all applications of the user are disconnected or logged off, and the Web Interface logs the user off.
Let’s take a look at the actual XML data that’s contained in one of these requests. In this network trace showing a capturing disconnect request, you’ll see that the Web Interface sends RequestDisconnectUserSessions and ClientName information to the XML Service on the backend MetaFrame server. (The extra periods in the network trace result because the Citrix XML service uses 16-bit character encoding, but our utility incorrectly processes each one as two 8-bit characters.)
The process of reconnecting is basically like the disconnection process except that the reconnection process has more steps. When reconnecting to disconnected applications via Workspace Control, the user essentially gets a custom hidden application set consisting of their currently disconnected applications.
The XML data for the reconnection contains RequestReconnectSessionData along with the ClientName section.
What is the ClientName section?
In both of the examples above, the XML data contained a section called “ClientName” which plays an important role in Workspace Control environments. ClientName is a unique identifier for a client device that lets the system know when you’ve switched client devices.
For those of you who are familiar with Web Interface, you know that the [NFuse_ClientName] tag located in the template.ica file does not represent the actual workstation name. In classic environments without Workspace Control, the Web Interface client name is a combination of the domain name and the user name in the form of domain-user. Unfortunately, for the purposes of Workspace Control, this naming convention was not unique enough and Citrix had to add a function called GlobalConf.generateClientName() that’s called in the Web Interface logon.inc file to generate a totally unique ClientName.
Either way, Citrix does not use the actual workstation name as the client name when connecting via the Web Interface. This is because in the real world it can be difficult to get the workstation name from every platform (Mac, Linux, etc.) and browser combination. The easiest way around this was to use the domain and username since they could simply be retrieved during the user login process.
The main problem this caused was that many companies have a formal naming convention for their workstations, and administrators made scripts, policies, or whatever based on those names. The problem was that when connecting via the Web Interface, the client name was the domain-user name instead of the real workstation name as configured in the ICA client properties. This was confusing.
So what did people do to “fix” this? They simply removed the [NFuse_ClientName] tag from the template.ica file. Problem solved.
Be aware, if you’re using Workspace Control and you remove the ClientName tag from the template.ica file, Workspace Control will stop working!
Why? Even if you remove the ClientName tag from the template file (which changes what client name shows up in the CMC), the ClientName is still generated (by that function in the WI logon page) and sent to the XML service. This means that a Workspace Control disconnect request would send the “unique” ClientName via XML to the IMA service, but the IMA service wouldn’t find any applications running on that client name since the deletion of the tag in the template file caused the connected client name to use the actual client name convention. This will cause the Web Interface to log the user off of the Web Interface browser session, but the ICA sessions would remain active on the client.
A Very Limited Workaround
It is possible to use the “real” workstation name as your client name while still using Workspace Control. This requires a Web Interface modification to the logon pages and works only with Win32 clients using Microsoft Internet Explorer.
While it’s only advisable to use this for an internal Web Interface deployment with a good client name convention, the modification and the description on how to use it can be found at my Website at Win32 client name.
Moving Forward
To start to address some of the complexities of this problem, the ClientName that’s generated in version 3.0 has a prefix (either “WI_” or the domain name) that can be used as a configuration target for Citrix policies. (Those policies get more and more important with MPS 4.0. Stay tuned for details.) This prefix allows you to determine (based on client name) which clients are internal versus those connecting via Web Interface.
Of course it would be great to know whether a client is coming from outside is a company-controlled workstation? That functionality will hopefully be part of Citrix’s Smart Access offerings that will be part of some future version of the MetaFrame Access Suite (due out in 2005).
Kommentar(e)
hoho Geschrieben von Guest am 2006-10-17 10:05:24
Web Interface 4.5 Geschrieben von geraldliving am 2007-05-24 23:57:54Hi Thomas, have you got any plans to make the necessary modifications for Web Interface 4.5?
Web Interface 4.5 Geschrieben von Thomas Koetzing am 2007-05-25 07:09:16Citrix has fixed the issue with WI 4.5 and CPS 4.5
Kommentar(e)
