Citrix - Streaming a physical desktop to Citrix client using DDC without virtualizing
Hey guys - here's the latest in my epic saga of strange Citrix experiments. I recently tried to install the Desktop Delivery software (the virtual desktop agent) on an actual physical machine running XP Pro. I joined the machine to a Xen farm the same way you would do with a VM. The desktop delivery controller sees the desktop as an actual virtual desktop, and I can log onto ( and stream) the desktop using Citrix Online Plugin. However, now that I've done this, I can't get to any desktop at all (just a black screen) on the physical desktop unless i"m connected to it remotely with the citrix client! Now, I realize that this probably isn't really normal practice, since I'm streaming a desktop using the DDC WITHOUT using Xenserver at all, or really without using any virtual machine at all. My question is: has anybody every tried this? Also, if it does work correctly (which it does 'seem' to), how do I still allow normal physical access to the machine, when I'm at the physical box? Does that make sense? If I can correctly use this method on a couple of my PC's WITHOUT virtualizing them, I think it would be really cool.
ToxicPig
This should work just fine. I do it for my own desktops. XP Pro only allows one user to be connected at a time, so yes, you will not be able to sit at the physical console if you are still connected via the DDC. Has to be only one or the other, never simultaneously. The screen gets blanked for security purposes when you are on via XD.
ASKER
Hey there - My problem is, the physical desktop is only displaying a desktop when i AM connected to it from XenDesktop. It's like the reverse of how I want it to be. When I'm logged on from the citrix client, I have the full desktop in my Citrix client AND physically on the desktop, which is fine because that means it's streaming out just fine, but when I disconnect from the desktop (a.k.a. when I disconnect from the Citrix Client), the physical desktop goes back to being just a black screen. It's like the opposite of what you are describing agove. Any ideas?
Very odd. Is everything hooked into the same Active Directory tree?
Are there any interesting RDS errors in the system log on the client?
Are there any interesting RDS errors in the system log on the client?
ASKER
Yep, same AD tree. Here's a question - in the DDC when I assign the VM (even tho it's physical), I chose "none" for the type of hosting infrastructure. Should I still be choosing XenServer as the type of hosting infrastructure? (even tho it's a physical machine)..?
You are correct, it is not a VM with a hosting infrastructure, so you choose none.
Problems like this have been widely reported under Vista and Win7. It usually falls down the hole of WDDM vs XPDM controlling the display drivers. That being said, I have had problems before with the VDA under XP when the graphics drivers were not compatible. Here's an experiment:
Change you graphics driver back to Standard VGA, and reboot the physical machine. Try it now in both modes to see if it behaves better. If it does, then Try updating the manufacturer's display driver for your video card. Nvidia and Intel very good about keeping up with the technology. Not sure about ATI.
Problems like this have been widely reported under Vista and Win7. It usually falls down the hole of WDDM vs XPDM controlling the display drivers. That being said, I have had problems before with the VDA under XP when the graphics drivers were not compatible. Here's an experiment:
Change you graphics driver back to Standard VGA, and reboot the physical machine. Try it now in both modes to see if it behaves better. If it does, then Try updating the manufacturer's display driver for your video card. Nvidia and Intel very good about keeping up with the technology. Not sure about ATI.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm going to try out the display driver thing right now - I will let you know what happens. One other side question, not really related to this exactly: In a standard installation, does the citrix client just connect to the delivery controller on port 80? I'm having trouble finding decent documentation on the best method to connect remotely (over the internet) to my virtualized (or in this case, non-virtualized!) desktops. Right now my actual delivery controller machine is just a VM running Server 2003 directly on the Xenserver machine. For experimental purposes, at home I just fire up my VPN to the corporate network first, then connect to the http://local_ip_address of the delivery controller. I want to eliminate this step for my true remote employees, but don't want to purchase any more hardware. Any guidance?
ASKER
Just a quick update - I never was able to successfully get the display drivers correct on this particular machine for what I was trying to do with it. However, I've not tried the HDX 3D settings to tweak the display settings yet, will be trying that later today. I will probably move my other question regarding remote access gateway and/or secure access gateway to a new question. Stay tuned...
I will quote from another source, and switch the referenced technology:
HDX is voodoo. Damned cool voodoo, but voodoo nonetheless.
Once you get HDX tweaked and performing, it's a thing of beauty. Getting there is fun, though. To answer your other question, the client only communicated with the DDC on port 80 for the initial broker connection ( think Web Interface), then the client talks directly to the desktop VDA via ICA (think XenApp applications). This can all be tunnelled over port 443 using an Access Gateway.
HDX is voodoo. Damned cool voodoo, but voodoo nonetheless.
Once you get HDX tweaked and performing, it's a thing of beauty. Getting there is fun, though. To answer your other question, the client only communicated with the DDC on port 80 for the initial broker connection ( think Web Interface), then the client talks directly to the desktop VDA via ICA (think XenApp applications). This can all be tunnelled over port 443 using an Access Gateway.