Accessing Windows XP and Vista via Citrix XenDesktop ICA (portICA). How does this really work?

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.

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

Why PortICA?

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!

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Hi Brian

Really good article and really cool new product from Citrix.

Do I understand it right - Is it a sepperate product that I can buy and install on any Windows XP or Vista desktop/VM?  and then connect to it via the ICA Client? or do you need XenDesktop/XenServer to get PortICA? 

Just to be clear, the only way the admin can take over the contol from the phychial console/VM console is to push Ctrl+Alt+Del, right? 

Sorry for the misspelling (Wish I could edit my comment)  sepprate = separate

What about shadowing user sessions?

Great info Brian...thanks!  What about SpeedScreen with portICA?  I understand that portICA is NOT terminal services so do you also lose SpeedScreen?  This is one of the bigger problems I've noticed with VDI via RDP, the ghosting of keyboard strokes, etc...especially over slow WAN links.  As for the multi-monitor displays, portICA looks pretty nice, but I've been using Wyse's multi-monitor utility as well as SplitView which essentially does the same thing, not really, but kinda...


From what I've heard, I think portICA isn't going to be a separate product in its own right, but part of Citrix XenDesktop 2, which will also handle the provisioning and connection to the desktops. As I say, purely from what I heard somewhere else (so may be wrong - Brian?).





Again, I might be wrong here, but its my understanding that SpeedScreen (and other ICA features) will be available, when connecting using portICA to a desktop. 

Cheers, Mark



So I can use portICA, with XenDesktop 2, to connect, one to one, via ICA, to XP\Vista workstations running on a VM or Blades.   This forms part of Citrix's "personal & versatile" (XP\Vista on a VM) or "power & performance" (XP\Vista on a Blade) approach I guess - using terminology that goes back some time though now. My question is, if I used Provisioning Server to stream Vista workstation images to Blades (whether private or shared), could I use portICA to connect to them, or do they need to be either VMs or have the OS\Desktop actually installed on the Blades? Presumably, it doesn't matter, and I could use PVS?

 Thanks, Mark


Correct, portICA is a feature of XenDesktop, so you need that to use it. (Plus it needs to connect to the controller server and everything to get its policies, etc.)

And yes, physical console access requires CTRL+ALT+DEL, and that will disconnect the remote user. 

Correct, SpeedScreen is part of ICA, so you do get that with portICA.
Correct, Provisioning Server doesn't affect the parent OS in any way, so physical blade or VM, Provisioning server or "local" install... portICA works with it all.
Shadowing does work, but for obvious reasons it can't just "share" a session on the workstation since there isn't one to share per se.. I actually goes back through the XenDesktop controller.. Hmm... maybe a separate article would be best to fully explain???

Has anyone had a chat with a Microsoft rep regarding the licensing of Vista and XP in virtual desktop environment. I've heard that owing to the fact a Windows PC accessing a virtual desktop has to be under software assurance, Microsoft licensing in effect precludes accessing virtual desktops from PCs not owned by the organisation deploying the virtual desktops i.e. home PCs or PCs in libraries and cafes etc.

Can anybody clarify if this is the case?

What about Cleartype - will this work on xendesktop?
You need a room full of lawyers to decipher MS licensing, especially with VDI.  Last I heard, an XP licesense is an XP licenses regardless of SA or not.  So if your using an XP desktop to connect to an XP VDI - it's 2 licenses.  However with Vista some of that changed in the sense, you are permitted to run a virtual instance of XP on a Vista desktop to support legacy applications.  I could be wrong, the licensing changes daily....

Here are the virtualization rules for the Windows Servers:

It does not matter how you virtualized, either with VMware or Microsoft Virtual Server, the rules below apply.  Each Windows kernel that is running is considered a license, physical or virtual.

Not sure if desktops will follow this or not since this was specific to servers. 

Yes. PortICA supports ClearType

Microsoft has something called a "VECD" license.. Vista Enterprise Centralized Desktop. Basically this is an add-on SKU that you add-on to an enterprise vista license with SA, and it lets you connect to / run multiple instances of Vista Enterprise from the particular device that has the VECD license. (So this is VDI, local VM, etc.)

If you want to use XP, you also need a VECD license, and then you excercise your "downgrade" right. 

Like most products from MS, this is tied to the client device. If you want to provide this to other people, then that's a SPLA conversation. 

I've also read that Provisioning Server is now able to stream the same image both to physical and virtual... It means we should been able to get "a single XP reference client image" streamed both to "personal & versatile" (XP\Vista on a VM) or "power & performance" (XP\Vista on a Blade) ...
not really clear... For what I've heard, MSFT have 2 type of licences for VECD : 1 for Virtual, 1 for Diskless... What about XenDesktop where you get "diskless virtual machine" ?

My understanding is that there are limits of what types of Speedscreen are supported.  I believe the Flash and Multimedia components and not baked presented.  However, I have not personally verified this myself.


It appears that portICA works similarly to HP RGS, but with a few advantages.  The multi-monitor functionality in portICA looks great, and better than what you get from RGS.  Also the fact that you get other things like client drive and printer mapping are bonuses over RGS.  Now we will have to see how the Apollo technology compares to RGS when running on blade PCs.
Does RGS work well over low bandwidth. That is where ICA and RDP play well, which is most of this market. Of course ICA adds much over RDP.

An RDP Connection to Windows XP Pro connects to Session 0, which is the console session.  If one were to move the physical mouse or click the keyboard, these would only be delivered to the console if the user initiates a Ctrl+Alt+Del and either logs on as the current user, or logs on as an administrator and logs off the current user.

As for shadowing, it is possible to shadow /remote control Session 0 on Windows XP, however it must be done from an RDP / ICA Session.  In tsadmin.exe, the remote control options are disabled if logged on locally, i.e. not over RDP/ICA.  One can initiate a shadow of session zero, from session zero of another XP Pro or any session of a Server OS.  I demonstrated this at the San Diego VMUG, and showed which GPO and registry settings need to be in place for this to work.

So I guess I'm unsure how using ICA to connect to session 0 is different that using RDP, other that the protocol that is being used.  I am aware of the protocol differences.


When you are running on the physical console you can see that you are actually using session 0 if you run a qwinsta.  When you RDP to the console session 0 is placed in a disconnected state and you get a redirected console in a different session.

My question is how does portICA differ from GoToMyPC in the way it displays the desktop (protocol aside).


Yes, there are two ways to buy the VECD license. One is for where the device doesn't not already have a Windows Vista Enterprise license, like for non-MS or thin clients. The other VECD license is an "add-on" to a Vista Enterprise device license that also lets you run Windows in VMs and remotely.

So for XenDesktop.. which VECD package to you need? Depends what the client device is. If you already have an agreement with MS and you've already paid for Vista enterprise licenses for all your devices, you can use XenDesktop just by adding on the VECD option. And if you have a bunch of non-licensed clients, then you buy the VECD for thin clients. 


PortICA is very similar to GoToMyPC actually...

As for the whole session 0 thing, yeah, that's how Windows XP Pro works IF you have remote desktop enabled. (Basically this is like "installing" terminal services on Windows XP.) So then your console is Session 0 and you have a remote session / remote control.

But PortICA is not using the remote desktop subsystem. In fact, you can disable Windows remote desktop and portica still works. It is 100% its own thing. (Kind of like GoToMyPC.) 


Hi Shawn,

In the final product, I have been advised that Flash will be functional and so will multimedia.



Really? That's good then. Thanks for this information guys.

Cheers, Mark

Wow, this sounds good  - thanks for the info.

Actually, just re-read that. The SAME image to a VM and a Blade?  Really?  I thought you'd need different images. We have all physical terminal servers, but just using two models has meant we couldn't use the same shared image. We're doing a Provisioning Server proof-of-concept at the moment.



I read that as well and remember it being mentioned a a technology called ?Common Image Format? or something like that? Can someone enlighten us?


I think it's the Common Image Technology.

- Use the client with the latest chipset drivers to create the image

- Consistent HAL; clients must have same number of logical CPUs

  (Hyperthreading counts as multiple when enabled)

- Ran Common Image Maker (CIM.exe) on each client and merge data


I have it on good authority that RGS is gaining ground on ICA in the performance over long haul links.  I heard good reports on a Sydney to NY link.  not sure of the round trip, but I imagine something in the region of 300_ms



So does this mean customers that are not on EA agreements with Microsoft will not be able to use the XenDesktop Solution.  EA requires 300+ seats and all of the OPEN/OPEN VALUE options are only upgrades.  So how would someone buy NEW seats for XenDesktop if they are not on an EA with Microsoft?

I've had the below emailed from a VMWare system engineer and I'm trying to get a more balanced picture.

It lists features found in ICA that they state aren't supported by PortICA, can anyone shed any light on truth of these claims?

o Kerberos authentication
o SmartCard
o Multimedia acceleration (called SpeedScreen)
o Support for low latency connections
o PDA synchronization
o TWAIN support (Scanners)
o User shadowing (akin to Remote Assistance)
o Session Auditing (called SmartAuditor)
o Audio on Vista
o ICA perfmon counters (SMC) and end-user experience metrics

My main area of concern was the lack of support for any sort of key fob security token, kerberos or otherwise. Has anyone achieved a XD deployment and succesfully implemented any user authentication of this type?



Hi Brian,

Really good article.

Is there a way to disable PortICA and use the presentation server's ICA in XenDekstop?

Actually my problem is that I am planning to use ChipPC-JackPC as a thin client to connect to XenDesktop; the ICA client provided with ChipPC does not support XenDesktop as of now and I am searching for a workaround.


This is not just VMWare's view of PortICA, but Citrix's stance as well:,+Technical+FAQ

Q. How do the ICA capabilities in XenDesktop compare with that in XenApp?
A.All of the ICA functionality of XenApp 4.5 FP1 is available in XenDesktop.  The following are not yet supported:

  • Kerberos SSPI or SmartCard Virtual Channels
  • SpeedScreen multimedia acceleration & zero latency
  • PDA sync, TWAIN, shadowing and SmartAuditor
  • Audio on Vista
  • ICA perfmon counters (SMC) and end-user experience metrics

ICA capability variances between XenDesktop and XenApp will be address in upcoming releases.


Brian, expanding the article to note the differences between portICA and ICA would be helpful. As I understand it, one of the reasons for portICA is because the Ardence technology that's used for XenDesktop used with RDP, and that portICA is a wrapper or connection point around that RDP to provide a 'seamless' end to end connection with ICA. Thoughts ?