Why doesn't Citrix use HDX Connect with XenServer?

One conversation I find myself having at the different shows and meetings we attend is whether or not HDX Connect

One conversation I find myself having at the different shows and meetings we attend is whether or not HDX Connect (a.k.a. PortICA, a.k.a. Project Trinity) will ever be used outside of XenDesktop. PortICA was essentially the baseline for Citrix Desktop Server, which eventually became XenDesktop. Since then, it's been unofficially renamed to HDX Connect, but its use has been limited to only XenDesktop so far.

Citrix has been trying to find a viable place to use the technology without letting go of their prized intellectual property. While there are plenty of use cases that we can come up with, the possibility of using someone else's Terminal Server product or desktop broker with Citrix's protocol has so far kept HDX Connect off the shelves.

Today, Brian and I were talking about HDX Connect and we realized that there is a way it can be used without letting it into the wild completely--XenServer.

If HDX Connect were included in the XenServer Tools package that gets installed on each guest VM, and the XenServer Management Console given the ability to directly connect to HDX sessions, admins could take advantage of all the features of HDX and avoid using VNC or RDP.

It amounts to little more than a value-add for XenServer, but it would put to use a capable technology that is otherwise collecting dust. It also might lead to more use-cases for HDX Connect in other situations, like pay-for solutions for home access or free use for small deployments that could lead to large scale deployments with all the other Citrix products.

I know Citrix will pay attention to this, so sound off. Do you think including it in XenServer is a good idea? If you can think of any other use cases, post them, too!

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I think that implementing PortICA in XS is a wrong way, because it runs only on Windows, so you will need something else for linux VMs, VPXs and XS itself.

Better way to use ICA - integration of CPS for unix into XS, but, as i know it works only with Xwindows :)

I think that best way to avoid VNC - replace it with GoTo protocol, which is not using any GDI interfaces or OS-specific API


Integrating ICA into XenTools is not beneficial, as by that stage you can use RDP which is fine for most server admin tasks.

But if they could integrate it into the generic video stream and speed up display response before the XenTools get loaded, now that would be an idea!


Good points.

I don't have a XenServer in front of me at the moment, so I can't check, but what protocol does the XenServer Management Console use to connect to the console of each VM? I think it's VNC, which would allow the admin to see boot up and such (RDP would only kick in until later, and only if it's Windows, as Denis mentioned).

So, I wonder if Citrix can devise a way to build HDX Connect into XenServer itself so that it can be used "outside" the guest OS, no matter what that guest OS is (Linux, Windows, VPX, etc...), all while seeing bootups and such.



Maybe the same way it is being done on XC.

using ATM with build in hardware KVM support and have a service VM for management, like Receiver is for XC.

It just locks you further into Intel, but Citrix seems to not have a problem with that thus far.

Failback on AMD servers could be status quo.


Also, I don't see a need for HDX Connect on the desktop because Desktop Director will take care the helpdesk administration that HDX would have alleviated.

All connections should be managed by a broker, just make sure it's stable, resiliant, and reliable then we are all good.

What use would HDX connect for desktops be if the broker is down anyway? Unless HDX Connect could determine which user gets which desktop (be a mini broker) HDX Connect would stay device centric and not user centric.



Yes, XenCenter uses VNC over SSL (in fact you can connect to your servers via HTTPS proxy, with no direct connection)

Some reasons, why Citrix will not change VNC to something else:

1. Nobody needs it, all windows admins use RDP, no matter which server they are connecting (physical or virtual). All *nix admins using ssh

2. It works ok

3. VNC based on opensource code, there is a lot of contributions to it outside citrix, less work, same result

4. XenServer is opensource, ICA and GoTo protocol is proprietary. integrating them in to XS is complex and can result in source code leak.


GTM sucks as a protocol for hif def presentations. It's not great when you have to do animation and I doubt they can or will decouple that from the hosted only GoTo products.

Agree with Gabe, want a richer experience not RDP so we can boot etc.

@Icelus. Desktop Director is yet another console useful for other use cases. When my WI infra dies and 1000's of users are out despite "reliable infra" by boss wants to kick me where it hurts. When this happens because Citrix does not test and the XD product is LOW quality, I need a way to check that the machine is alive/available independent of the infra, otherwise finger pointing and chaos results. I can't run a desktop like this where many users are taken out. I need a back door to always be able to connect no matter what the infra does, even if I loose some function. Think of it like LHC in XA. Even with that it can and does fail. XD is so immature, that I need a safety net for troubleshooting and to let users connect. A broker has no value, it is nothing more than a user to machine mapping which I can script in 10 minutes. It is added complexity that makes the basic desktop dial tone unreliable. One can argue that the broker adds other management benefits. I agree, but that can't get in the way of the desktop dial tone which let's the user connect.



Now we're talking. You can slap me all you want but I will keep re-iterating this.

Centralization of user session brokering should always be made available with no down times.

If your print server or nfs goes down you won't be able to access those resources the same way.

I guess you can manually add the printers to the workstations again, wtf would be the point.

Citrix should just focus on the broker.

The broker is an integral part for authentication and access control, how would that be handled with HDX Connect?


FYI - Gartner tested PCoIP and HDX and found "some" superioirty of HDX in high-latency connections:



@Icelus. No slapping, you actually contribute a lot of good insight. I would love to have the energy and desire right now to respond with a blog and few pictures, but I just don't have time, so here is something to consider. And again not a slap trying to get across my point.

Tomorrow go and think about implementing a broker in front of every fat PC you have and latop. Justify it to yourself by saying that you want it to be an integral part for auth and access control. Build out a high scalable and redundant infrastructure and spend some money getting the hardware in place and getting people to manage all those servers. Then when a broker goes down and many users are unable to connect to their desktop despite your best efforts and vendor X telling you that the current release is the best ever go and talk to the end user. Here is a user that used to be able to connect, auth, and there was access control. Now he/she can't connect period. Then ask for desktop virt why are the auth/access functions married to the connection tier. That' s not how a desktop works today, so why architect towards something that is inferior? Why do we all assume there is only one way to do this? Why not have options and configuration that give customers choice so they can determine how big an outage they are willing to take. I could go into a longer narrative and provide suggestions on how to do it, but like I said just no time right now.

Getting back to the point of this blog. HDX Connect is lot more than a feature of XS remote access. That's one tiny use case, but it's not the point.

@SillyRabbit, it's the most well known fact in the world by those who DO, and that's just a single user experience. The impact for multiple sessions and secure remote access, policy etc are not even mentioned. PCoIP plain simple is just a piece of $h1t that is going nowhere fast, just like RDP 7 is going nowhere fast with RemoteFX due to it's wedding to Windows everything.



Slapping was a figure of speach, I enjoy being challenged.

I am learning a lot on how useful HDX Connect could become. I firmly believe that auth/access control functions should be married to the connection tier for numerous reasons however I believe what we are discussing is if it's more appropriate in a centralized or distributed environment and that you want the choice.

I believe I finally get it now, and totally agree.

How about this idea. Taking Gabe's concept one step forward, when adding HDX Connect to XenServer Tools you also subsequently add it to every server VM as well as desktop VM on XS. Since XenServer Tools are installed on the desktop as well, it's two birds with one stone.

HDX Connect can have built in functions for auth/access control just as the broker does, but in a distributed environment.

This is all ironic due to the historical debate on whether IT services are offered centralized or distributed, then back all over again. This situation might hold true for the broker here as well.

Citrix offers the the choice of an execution environment in either a centralized or distributed fashion, will this hold true for connection auth functions in the future? who knows, but I agree the choice is good.

Implementing it in XenServer Tools would be a great idea, maybe in the future the broker can act as a central repository for these connections and you can query for all servers/desktops. With no dependencies on connectivity.

My ideas are always outlandish, but it's always good to throw them out there to either get them validated or shot down.


So to re-iterate, a common guideline for server/desktop access could be:

Out of Band management can be done with closer to hardware services such as Intel's vPro or AMD's DASH and access control functions can be done in a distributed way, with a centralized backend management/reporting server.

In Band management can be done with XenServer Tools and access control functions can be done in a distributed way, with a centralized backend management/reporting server.

easier said than done.

Good ideas!


Better yet port XenAPP for UNIX to XenServer and let you run console sessions to VM's that way


Yeah, late to the party again… I was thinking a bit about how the remote connection to a guest VM actually happens from the management client. In VMWare(?) and XenServer the built-in protocol is VNC and can be used to connect outside the management client. See “RemoteDisplay.vnc.<--->” and “xe console-list” respectively.

Hyper-V  remote connections are naturally RDP based and can be equally remoted with for example HVRemote - code.msdn.microsoft.com/HVRemote.

Aside of these, also remember that Oracle (Sun) VirtualBox has a built-in implementation of (closed source) RDP server and (open source) VNC server.

What I’m saying is that I do not see any technical limitation of not including ICA alongside the two other well-known display protocols. However, I do not see any point in using ICA, or specifically HDX Connect – unless the idea is to provide a Citrix alternative to RemoteFX which I do not see for obvious reasons …nudge nudge wink wink….