Why doesn't Citrix use HDX Connect with XenServer?

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!

@Gabe

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.

@Gabe

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.

@appdetective

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:

virtualization.info/.../citrix-hdx-better-than-vmware-pcoip-over-wan-says-gartner.html

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

@appdetective

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