Unidesk and Windows 10 1511 boot hanging

Quick post to point out an excellent article over at the Unidesk support site that doesn’t quite describe all the symptoms you may encounter.

With Unidesk 2.7+ (2.9.4 in my case), if you are capturing Windows 10 build 1511 or greater, after you have captured your OS layer and deploy your first desktop based on that, you may encounter an endlessly spinning Win 10 boot screen.

GlzE5s

Unidesks’ article (found here), talks about the larger picture with how they capture images and provides an easy fix. It’s a pretty interesting peek under the covers of what they are doing during image capture. It is a far more predictive process around the storage side of things than I would have thought. App virtualization has changed so much in the last decade.

Unidesk helpfully points out how you can positively identify this issue in the C:\Windows\inf\setupapi.dev.log file, but I wanted to hopefully associate more Google searches with this excellent fix (it takes about 10 minutes to implement), because while they detailed some scenarios you might run into, this common situation, capturing Windows 10, is not very advertised.

If after capturing a new Windows 10 image in Unidesk and deploying a new desktop from the clean gold image, you find yourself staring at an ever more hypnotic spinning circle, follow the steps in the link!

Happy OS layering!

Netscaler Access Gateway issue

Randomly seen  “Unable to launch application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server.SSL Error 43: The proxy denied access to ….  port 1494” when using 2 or more PVS based STA servers, running on the same image.

NetscalerSTAissue-pic1

So this is one of those annoying error messages that can mean a great many things.

  • Access gateway licenses might not be installed
  • Mismatched STA’s configured on the Access Gateway and Web Interfaces
  • You could actually have some firewall issues with the XenApp server you are trying to hit.

However in a recent case, all of those factors were fine, and the problem would appear randomly. Usually if any of the above issues are present, it is an all or nothing game. It is either totally broke every time or it works. However in my case it would randomly work. You click on your app in web interface, and if you got the above message and retried a few times it would connect fine. Other times it would connect with no message at all.

So to baseline the configuration,

  • 2x Netscaler 10.0 running Access Gateway
  • 2xXenApp 6.5 HRUP1 servers providing zone data collection for the farm and STA service.
  • KEY POINT : Both STA servers are provided off the same PVS vDisk.

So what is happening is best displayed in the Netscaler config for the Access Gateway virtual server. Go to the Published Applications tab and look at the STA identifiers

NetscalerSTAissue-pic2

Now it is important to note this pic is from AFTER I fixed the issue. When the issue was occurring, both STA Identifiers were identical. Essentially Citrix was expecting the identifier to be unique and was getting confused when both STA servers were responding to the same identifier. The relevant (and fairly new) Citrix Limited Release KB article is here.

http://support.citrix.com/article/CTX137509

The hotfix side of the KB corrects an issue with using the XenApp Server Configuration tool, when you prepare a server for imaging and provisioning. It was not guaranteeing that each server had a unique STA. The second part of the fix is just to set the Citrix XML service to delayed start to ensure it comes up after the NIC does.

So a simple fix for an odd and random problem.

PCoIP and USB Mic misbehaving with “Follow-Me” desktop

 

I’ve been working on “Follow-me” desktop solutions lately, especially VMware View. Working through different workflows and use cases, I ran into a pretty vexing peripheral issue. As it stands, the PCoIP protocol has an issue with how it handles bi-directional audio through a USB microphone.

One of the new features of recent PCoIP releases has been support for isochronous USB devices to be connected. This type of device has certain bandwidth guarantee associated, and is given privileged status essentially. Things like microphones! You have to have a great connection or your voice input comes out sounds all garbled and scratchy when put over the network (connecting your physical desktop to your virtual desktop). This actually works quite well and I have to give PCoIP props for how well it performs. A good guide to the basics of getting things rolling is found here.

However, one particular use case makes apparent a big problem right now with PCoIP and USB microphones, the “Follow-me” desktop. Normal behavior for USB redirection goes along the lines of….

  1. Disconnect device from host
  2. Reconnect device to target virtual desktop

This is the Virtual USB hub included with the View client making this happen. When you disconnect your physical computer from your View desktop, the following step is supposed to happen

  1. Disconnect device from target virtual desktop
  2. Reconnect device to host

This is all because only one system can “own” a USB device at once. However the last step is not happening for USB microphones when connecting via PCoIP. The process works correctly for RDP connections oddly enough, however this will not work correctly with some commonly used apps for a USB mic, like Dragon Naturally Speaking.

What you will observe follows this pattern….

  1. First connection from a “fresh” host PC to a Virtual desktop ends with the microphone working.
  2. The user logs off of their View desktop
  3. Any user that then tries to logon from that desktop will be unable to connect to the microphone. You will see an error similar to “Cannot connect <device name> It may be in use by another application”.
  4. If you unplug the USB microphone and plug it back in to the physical PC, you will see the USB composite device in a disabled state in device manager.

There is a VMware KB regarding this issue here that describes in great detail what error messages you might see, and describes their current official workaround.

kb.vmware.com/kb/102687

The core of the solution, if you can call it that right now, is to remove the disabled USB Composite device corresponding to your mic, from the device manager, while it is plugged in and after it has “failed” and will no longer connect to View desktops. This does reset the device so that it can successfully work with another virtual desktop again, but far too detailed for an average user to do on a near constant basis.

If you want to script this to take a lot of the pain out, Microsoft actually has a nifty command line utility that lets you manipulate the device manager. DevCon is the name, and it can be a lot of fun….but can have….ahh…unfortunate side effects if you aren’t careful.

http://support.microsoft.com/kb/311272

Regardless, if used correctly, you can fire off DevCon to remove the specific VID/PID of the USB mic from the host PC(specifically the USB composite device). However the end users would still need to physically unplug the mic and plug it back in, before the device would be fully reset and ready to connect to another virtual session.

Feelers are out to Teradici and VMware to see if there is a more elegant solution to be found. It sure would be nice to be able to treat USB microphones as equal citizens in the mobile virtual world!