Xendesktop: Force USB redirection for Webcams

HDX Realtime video compression was a feature that Citrix added to their XenApp/Xendesktop. It uses compression and its blend of herbs and spices to lower the bandwidth requirement for webcams, while keeping fidelity.

While this sounds all good, it some cases you need to use good ol USB plug in play for compatibility. By default, Xendesktop will try to use the HDX Realtime video compression (which shows up as ‘optimized’ under Devices in citrix receiver). In our case, when using the HDX realtime compression, the recording software would complain that the device wasn’t available. However, switching to Generic (ie USB plug n play) everything would work just fine.

There is not an easy way to force the Generic method over the Optimized method. The user can switch it, sure, but we want the users to log in and go, not fiddle with settings every time they log in.

It may be that the web camera was unsupported (is that possible nowadays?)  but in any case, administrators need a way to force this via Citrix HDX policies.  There wasn’t, at least not that I could find.

After searching, we found the answer.

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\GenericUSB\Devices]
“AutoRedirectVideo”=dword:00000001

This settings forces Generic usb redirection first, before trying to use the Optimized metho.

HTH,

J

Edit: Updated the key path, typos

Disclaimer:  Usual stuff, I’m not responsible if this breaks things, be sure to back up your Registry just in case.

james gonzales / October 5, 2016 / Citrix, Registry, XenApp / 0 Comments

Recover VM’s from a permanently down XenServer host.

 

We recently had a XenServer node crash to the point it was not possible to recover.

The VM’s that had been operating on the host were no longer visible in XenCenter and had seemingly disappeared.

The first you need to do is locate the UUID of the down host with

 

 

 

Then display a list of all the VM’s on the failed host with

This will output all the VM’s on that host and indicate that they are in a “running” state.

We need to reset the powerstate of each VM.

Once you run this command you will notice the VM appear in XenCenter.  You will more than likely not be able to start the VM due to the VDI being in use by the downed host.

you’ll need to reset the locks on the VDI, this can be done by forgetting the UUID of the VDI and reattaching it to the VM.

One way to do this is to run

 

This will gernate an error but more importanly it will also tell you the UUID of the VDI that is in use.

Then you need to “forget” the VDI

 

this will cause the VM to “lose” the disk, rescan the SR and you’ll see the disk without a VM.

Go to the storage tab of the VM and reattach the VDI and then restart the VM either with XenCenter or

 

note: if the VM has more than one disk youll need to repeat the process of running

 

and each time it will show you the VDI causing the issue.

 

There is a way to reset the VDI’s on a given SR as the above can be time consuming with a large number of virtual machines but this post will not cover that method.

 

 

 

casey jones / March 7, 2016 / Citrix, Virtualization, XenServer / 0 Comments

Citrix XenApp 6.5 Printer Woes, Bloated Registry

I wanted to share an interesting case in hopes that it would save an admin out there from an unnecessary headache.

The environment was a small XenApp 6.5 farm, maybe 1-2 servers on Server 2008 R2.  It had maybe 30-35 users.  One day, users started getting Temporary Profiles.  Looking in the event log there was numerous “<> took too long to respond…” events.  Every so often, connections would come back with a server is low on resources message.  Though, all performance metrics were seemingly normal.

Before I logged a support case, I came across this website. http://carlwebster.com/the-curious-case-of-the-bloated-default-profile/

This described our problem and when I looked at the size of the registry, it was 1.5 GB in size!  Navigating to below registry keys, the screen would hang, there were hundreds of entries, if not more!

HKEY_USERS\.DEFAULT\Printers\DevModePerUser

HKEY_USERS\.DEFAULT\Printers\DevModes2

Deleting the keys seemed to help, the screen would no longer hang, but the registry was still the same size. We ended up compressing the registry, and the problem went away.  There are quite a few resources that should be able to help if looking to compress the registry.

The issue stemmed from some registry keys being created  for each printer, each time the user logged in.  This occurred over and over again.  Over time, I suspect the issue would have reoccurred.  Citrix provides a tool to stress test printer drivers, http://support.citrix.com/article/CTX109374   We switched out most drivers for the Citrix Universal Drivers.  After that, the registry didn’t grow as it did before and after watching it for about a couple of weeks, stayed about the same size, ~100MB.   After that I called the problem fixed.

 

Hope this Helps if your experiencing a similar issue!

james gonzales / September 28, 2015 / Citrix, Printers, Registry, XenApp / 0 Comments