If you use Web Interface 3.0 or later, and especially if you work in health care, you have probably noticed that connections made to Presentation Server via Web Interface don't use the client's workstation NetBIOS name as the Presentation Server ClientName variable. Instead, it's a random string such as WI_e5KPgXSIWWtOWAQTg. This change was introduced as part of the Workspace Control feature that allows users to roam from device to device and have their Presentation Server sessions automatically reconnect when they roam from one workstation to another.
But there was a regrettable side effect of leveraging the ClientName variable for unique device identification: some applications, particularly health care apps like Epic, relied on the %CLIENTNAME% environment variable to pinpoint a user's location based on a database of known NetBIOS workstation names. If you run an application in your CPS farm that relies on the "real" client name, then you are left having to choose between application compatibility and workspace contol. (And app compatibility always wins!)
Let's take a look at how we got into this mess and how we're going to get out of it.
How we got into this mess
Long before Citrix released NFuse or Web Interface or even Program Neighborhood, we supported the notion of session reconnection. In a load-balanced WinFrame 1.7 farm for example, if you had a disconnected session and you connected to a published application, the load balancing algorithm would put aside the normal load metrics and send you to the server where your session resides, regardless of how busy that server was.
The thing is, the load balancing decision had to be made before you authenticated. (Remember this was before Program Neighborhood, back in the days of Citrix "Application Manager", which would give you a drop-down list of all published applications, whether you had permission to connect to them or not.) So to get you sent back to your disconnected session, the master browser would associate your workstation name with the disconnected session. When the client requested the address of the least-busy server, the workstation name would be included with that request. If there was a disconnected app associated with that workstation name, then that's the server you got sent to. Then if you authenticated as the user with a disconnected session, you would get reconnected. Otherwise you'd get a new session on what might have been the busiest server in the farm.
Flash forward to 2004 and the ClientName mechanism is still in place, but most people now use Web Interface for published application enumeration. While developing the Workspace Control feature, the WI developers needed a way to distinguish between a CPS session that is spawned for Uesr1 on Workstation A from a session spawned by that same user on Workstation B. To do so, WI generates a random string such as e5KPgXSIWWtOWAQTg and sets it as a cookie in your browser. When WI renders an ICA file, it adds the line ClientName=WI_e5KPgXSIWWtOWAQTg to mark that session. This was the only way at the time to uniquely associate a browser-to-WI connection with an ICA Client-to-Presentation Server connection.
Now when you look at the client name in the Presentation Server console or by querying the %CLIENTNAME% environment variable within a session, you'll see something like WI_e5KPgXSIWWtOWAQTg instead of the real workstation name. If your app needs to know the real client name, the only workaround was to remove the ClientName tag from the Web Interface template so that the ICA client would send its normal string during ICA connections. But that breaks workspace control, because there's no secure, reliable way for a web server to know the name of your workstation.
Thomas Koetzing wrote a good article about the ClientName problem a while back. After WI 3.0 was released I wrote an article that discussed the negative effects of removing the ClientName tag.
How we're going to get out of it
To fix this problem, Web Interface needs to uniquely identify each workstation without relying on the ClientName variable and without knowing what the real workstation name is. For the next release of Presentation Server, the WI dev team in Cambridge has devised what I think is an elegant solution: they will leverage the ticketing model that we already use during authentication.
Recall that when a user authenticates to WI and launches a published application, the WI server performs a ticket request, where the user's credentials are sent to the XML broker, the XML broker relays the credentials to the least-busy server and then the least-busy server generates a random ticket that can be used by the ICA client for authentication. The ticket is passed back to Web Interface and included in the rendered ICA file. See section 5.4 of the Web Interface 4.0 Troubleshooter's Guide for a detailed look at how ticketing works.
Web Interface will still generate a random string to identify each workstation and set it as a cookie in the browser. But instead of jamming it into the ClientName field, the ID will be passed to the XML broker along with your credentials during a ticket request. When you land on the target server and present your ticket, it now knows who you are and knows the WI-generated ID of your workstation. If you disconnect, it can use that information where it would have used the ClientName variable before.
This is going to be a fairly big change. It requires modification not just of Web Interface, but the XML protocol used between WI and Presentation Server has to be extended to support the enhanced ticket request, and the IMA and Load Management underpinnings on Presentation Server have to be modified to use this new XML element. So older Presentation Server farms won't be able to benefit. Fortunately, there are no ICA client dependencies here, so you will only have to upgrade your farm and your WI servers--not every end user client--in order to get this benefit.
Jay
