One of the big topics of discussion on my recent visit to Citrix's Advanced Products Group office in Sydney was their "portICA" technology. PortICA is the name of the technology that "ports" the ICA protocol stack from Presentation Server / Terminal Server to a workstation OS. In other words, portICA lets you use the ICA protocol to connect to a Windows XP or Vista host acting as the server (for a VDI or blade PC scenario). Citrix is using PortICA instead of the built-in RDP-based remote desktop option in their upcoming XenDesktop product. (Note: All of the portICA technology described in this article is part of Citrix XenDesktop 2, currently in beta, scheduled for a May release.)
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
A lot of VDI products are entering the market using server-based computing technology to connect to single instances of Windows XP or Vista instead of Terminal Server. Several companies, including VMware (VDM2), Quest / Provision Networks (Virtual Access Suite), and Ericom (PowerTerm) have real products on the market now.
Citrix also has a VDI product on the market called "Citrix Desktop Server," but this product is just a quick-and-dirty product that was thrown together fairly quickly only solves basic needs. Citrix's first "real" VDI product will be XenDesktop 2.
Anyone who's been in this industry more than a few days knows that connecting into a server-based computing environment via ICA is better than via RDP. And this is where PortICA comes in. It lets you use an ICA client to connect to a remote Windows XP or Vista instance via ICA, including support for all the add-on capabilities you'd expect like SpeedScreen, port mapping, and EMF-based printing. PortICA technology is one of the key features of XenDesktop 2.
Even though the purpose of this article is to discuss PortICA and not XenDesktop in general, it probably makes sense mention a few things about XenDesktop first though.
Fundamentally, XenDesktop is not that different than Presentation Server. XenDesktop still has a data store, Web Interface, and too many management consoles. The only real difference between Presentation Server and XenDesktop is that when an incoming ICA connection is made to a XenDesktop environment, it connects to a single-user Windows XP or Vista workstation running on a blade or in a VM. Essentially it's like a farm of single-user servers instead of multi-user terminal servers like with Presentation Server. XenDesktop handles all of the logistics such as provisioning VMs, routing users to the correct server, etc.
(A quick note for technical accuracy: XenDesktop can also provide ICA desktops to users via Terminal Services. But that's a topic for another day. Today we're focusing on ICA to remote desktops, not Terminal Servers.)
From the PortICA standpoint, though, the real action begins when an incoming ICA connection request comes in.
PortICA: The same, but different
When I first heard about the portICA product, my gut reaction was, "so what?" "What's the big deal?" Windows XP and Vista have remote desktop capabilities using RDP, so isn't portICA nothing more than just recompiling some ICA stack drivers so they run on a workstation?
Well, yes and no.
Certainly there are some elements of PortICA that Citrix was able to pull directly from the ICA implementation on Presentation Server. Other elements wouldn't work. (For example, on a Presentation Server, the ICA stack interacts with the session manager. On a workstation, there is no session manager!) And finally, there are some elements of ICA on Presentation Server that Citrix could have implemented in the same way, but that they chose not to for reasons we'll discuss later. In a sense, Citrix took the time with PortICA to do it right. The designed what they felt was the best way to provide remote ICA-based access to a single-user machine.
This leads us to a key point about PortICA that I'll reiterate several times: In an out-of-the-box Windows XP or Vista environment, remote desktop access is based on terminal services. PortICA is not terminal services.
As you can imagine, if you had to get remote access to a workstation's desktop, using the built-in remote desktop feature is one option. VNC (and other display mirroring techniques) is another option that achieves the same goal using vastly different techniques. And PortICA is a third option. (My point being that it achieves the same goal as remote desktop, but that it's not remote desktop.)
With portICA, Citrix is remoting the physical console via ICA. There are ICA stack elements you'd expect, as well as keyboard drivers and mouse drivers and whatnot. But the key is with PortICA, the physical console is remoted. It's not adding a session or introducing a second remote control.
When portICA is installed (as an "XenDesktop agent" really), there are two main Windows services that run on the workstation:
- The Citrix ICA Service, which is the central control service for the workstation.
- The Citrix Desktop Service, which is responsible for communicating with the XenDesktop server.
There's also a "CGP Service" (which actually replaces the XTE Service in you're used to on a Presentation Server) that's used when clients want to connect using Session Reliability, as well as the Citrix Print Manager Service for EMF-based client printing.
The ICA stack in portICA is the same as on Presentation Server. In fact, if OEM software vendors implemented their own virtual channels using Citrix's wfapi, then their virtual channels will "just work" via portICA--no recoding necessary.
In portICA, Citrix also implemented keyboard and mouse drivers to receive user input via ICA, but unlike Presentation Server, they're implemented as filter drivers in portICA. They have to do this because remember, in portICA, Citrix is remoting the physical console, so they needed a way to "inject" remote key clicks into the local console.
But they also needed a way to filter out actual local keystrokes on the console. (Remember that with Windows XP or Vista remote desktop, anyone can walk up to a workstation that's been accessed remotely and start poking physical keys, and those keystrokes and mouse movements would be seen in the remote session too. Not good!) So Citrix's filter driver filters out all local console mouse activity and local key presses. (Of course keep in mind that when I say "phyiscal console," probably 99.9% of portICA-controlled workstations will be blades or VMs, so in reality I'm talking about the VM management console, and Citrix's desire to prevent admins from messing up user sessions on the VM host.) The only key sequence that Citrix does not filter out from the local console is CTRL+ALT+DEL, which will let that local person grab control of the screen. (Physical access will always reign surpreme!)
Interestingly, while a portICA session is active, the physical console screen is blank. No special message. Nothing. Just completely blank. The reason for this is that because Citrix is remoting the physical console, there is no separate display buffer or session for the console, so it's not possible to have a local display that's different than the remote display. (Remember, portICA is NOT terminal services.)
The portICA ICA connection process
As I said earlier, the actual ICA stack on a portICA environment is just like on a Presentation Server. PortICA uses the same ICA clients too. But while the protocol stack is the same, the connection process is (again) "the same, but different" from Presentation Server.
The first change that most people will notice is that in a portICA environment, the ICA listener stack is NOT always running. It only loads when the XenDesktop control server contacts the Citrix Desktop Service running on the workstation to let it know that it's about to send over a user connection. When that happens, the local Citrix ICA service fires up the ICA listener.
This is cool from a security standpoint, and can probably prevent certain DoS-style attacks that could happen in regular Windows XP or Vista remote desktop environments. But it also means that you can't just telnet to 1494 and look for that ICAICAICAICAICAICAICAICA response to know whether a host is online.
By the way, remember that portICA also supports Session Reliability via the Citrix CGP Service, so connection requests that come in via 1494 can then be handed over to the CGP-wrapped 2598, just like Presentation Server.
A few key differences between ICA on XenDesktop with PortICA and ICA on Presentation Server
As I wrote before, ICA on portICA is similar, but not quite the same, as ICA on Presentation Server. Let's look at a few more of those in depth.
First, let's revisit this whole "black screen at the console" thing. Some people have asked why Citrix didn't implement the ICA display as a "mirror driver" which would allow them to show the session at the console and the remote session. (If VNC can do it, why can't Citrix?) The problem with a mirror driver is that they remote session display must match the physical display. This is not so much of a problem in a virtual environment when you can make the "virtual" display on the VM host as big as you want, but how would you handle multiple monitors? (Can you imagine a VM Management Console with four monitors per VM?)
Since portICA is NOT Terminal Services, Citrix can do a lot of cool things with the way the display is remoted. Going back to the multiple monitor example, some VDI products that are remote desktop-based get around the multiple monitor session by creating a "super size" display that spans multiple physical client diplays. (You have two 1900x1200 displays at that client? Create a single host session with a resolution of 3800x1200 and then span that across the two client displays.)
The problem with this is that the host views this as one giant display. So now you have problems like your start bar going across both screens, and windows maximizing across both screens, and not being able to control what's displayed in each window separately, and dialog boxes popping up right in the center, with half on each display... I could go on and on (as many of you know)! Sure, most vendors work around this be writing all sorts of code and adding intelligence to try to make the host behave as "normally" as it should. But really the "single display stretching" is just a bad way of doing things.
n portICA, multiple monitors are remoted as actual multiple monitors. When an ICA session connects, the ICA Service creates actual (virtual) displays in the remote workstation host that match the physical displays on the client. Here's a photo (sorry for the blur) that shows a right-click | display properties window from a single portICA session spanning 8 monitors. Even though it's blurry, you can see that the remote windows host views this as 8 proper displays:
This means that you can move windows and maximize and minimize windows as you would expect to, as shown here. (Popups centered in their own displays, task bar only on one display, windows maximized in their own displays, etc.)
And maybe the best feature?
In Presentation Server, setting per-user timezones was a huge challenge. (The whole "session time versus machine time" thing.) In portICA this is simple: The Citrix ICA service can just change the timezone of the workstation! Done!