Understanding Workspace Control XML and Client Name Communication

One of the new features of Citrix MetaFrame Presentation Server 3.0 (MPS 3.0)

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 http://www.citrix4ge.de/wim.

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).

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by Ron Oglesby on December 9, 2004
Nice little work around (works on a pair of my servers but not on a third so I am looking at that) You sure can break down that code fast. Now you get a quick article out of it huh? Thanks! Ron
This message was originally posted by Frank Anderson on December 9, 2004
I have implemented the above mentioned workaround to resolve a clientname, or local hostname, issue where the application “Cerner” uses the workstation’s ID for backend printing. One problem worth noting is that this does NOT work with NLB configured WI solutions. I have been working with Citrix’s development support on this for the past month, received these two files yesterday, and have reported the NLB discovery today. When a solution has been found, and if it’s not already posted, I will offer my findings.

Thanks for writing a great article! I have based my current implementation around Smooth Roaming and believe in its advantages. It fits healthcare’s environment quite well. Along with SSO and biometric/smartcard readers – it’s a relatively seamless end-to-end solution for us.

Thanks again.

-Frank Anderson
This message was originally posted by Thomas Kötzing on December 9, 2004
I'm no programmer but you got my attention with your request and I dug into it... the article is the result.
Does your workaround still append the WI_ prefix to the client name? If not it may be worth noting that some of the new MPS4 policies look like they may use this to distinguish between WI sessions and those initiated directly from a client device.
"Does your workaround still append the WI_ prefix to the client name?"
No, since this would break a companies naming convention again.

"If not it may be worth noting that some of the new MPS4 policies look like they
may use this to distinguish between WI sessions and those initiated directly from a client device."
Citrix policies including those of MPS4 can be configured freely. I doubt that Citrix has hard-coded the WI ClientName prefix within MPS4 Citrix policies and they have not done this in MPS3.
Just forgot, you can simply change the WI modification so you would have a ClientName with "WI_" prefix and the real workstation name.
Great article Brian.
especially it was from Thomas :-)