If you have been listening to the Brian & Gabe show, you know that Brian has recently started working remotely full time for the first time, and he has been having "issues" with local device devices (see Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes ). Today I'll give you a look at my woes with USB devices, which comes from a different angle - trying to write software to make this stuff work. No worry - you don't need to understand any code to appreciate this story. But it further makes the point that folks like Microsoft and Citrix and others need to take charge here. Let me tell you my story, which unfortunately isn't over yet.
Several years ago I was contacted by an ISV that makes a specialized scanner software package. They had customers asking them to work with Citrix and didn't really know what that was. Somehow they found me (google: "odd people that know odder stuff") and asked if I could help. After understanding their needs, I put together a solution using the ICA Virtual Channel.
The way it worked was like this. The scanner device (not too unlike Brian's business card scanner) connects to the local client PC over USB. The device isn't twain or WIA, which means it needs a real device driver installed on the client. But the application needs to run on the Citrix server. Basically, I broke the ISV software interface to this driver in half. The top half of the application runs on the server, while the bottom half and driver run on the client. In the middle I connect them up using the Citrix Virtual Channel Software Development Kit (VCSDK), which creates a "side channel" inside the ICA protocol for these two pieces of software to communicate, which was just a couple of day's work. The client side software acts like a plug-in to the ICA client and is loaded and available for the server side to communicate with any time the client is used. The drawing below shows how this works, except that the client device was a PC running something like Windows XP instead of a Thin Client device. The ISV customers were all using real Win32 OSs like Windows XP. Everything worked like a champ and this was deployed to many customers.
Enter the Thin Client
In November last year, the ISV contacted me because a new customer wanted to use Thin Client devices instead of PCs, specifically some HP devices running WinCE 5.0. I remembered seeing an add on Brian's site for a third party add-on to remote the USB, but that didn't work for this at all. So I checked the Citrix VCSDK documentation and found that WinCE was supported for virtual channel additions. We checked with the hardware manufacturer of the scanner and found that they had a WinCE device driver that we could use. Should be a piece of cake, yes? More like a boxing match.
In the VCSDK, Citrix provides three very simple sample applications including a "ping" app that pings the client side plug-in software. I could not get even the sample programs that Citrix provides in the VCSDK to work on WinCE; the server side could never detect that the client plug-in was present. Looking for help on the Citrix forums revealed that there was nobody willing to admit they had ever done the VCSDK on WinCE. Even the documentation for the WinCE VCSDK looked suspicious and I was guessing that nobody had tried it since maybe WinCE 3.0 and version 6 of the client. The operating system, the Citrix Client, and the VCSDK for Win32 had all changed significantly since that time while the WinCE version of the VCSDK did not.
One thing I noticed in using the WinCE for the Thin Client as a user is that you effectively get only one application running at a time. So seamless windows didn't seem so important to me. Sure, I can have icons for each app, and I can launch two different apps, but you find yourself using only one at a time because of the WinCE User Interface (its like going back to Windows 3.1). So, after talking to the ISV, I punted and implemented it using RDP and a similar RDP virtual channel technique. Once I solved the problem of editing the registry properly, this solution worked great. From the thin client, the user has only one icon. They use it to RDP into a full desktop session on the server, which then provides them desktop shortcuts to each application and they can effectively run them simultaneously.
Except that the customer couldn't handle the idea of logging in again and getting a full desktop on the server. This was a non-starter for them, they wanted ICA.
I tried getting help from my many Citrix contacts, but none had any leverage (or possibly knew who to ask) with people that could help on the ICA virtual channel problem. Several trouble tickets were opened and closed without help. By this time I basically could prove that the issue was that the Citrix client was not using the virtual channel dll that I was registering on the client. The outdated documentation told me to use a module.ini file - which was never looked at. The newer Win32 clients use the windows registry now instead of the ini file, so I tried the registry also. Without luck. Eventually I found someone who was trying the same thing with WinCE for a mobile device and he was told that it was a Citrix bug. The story was that a developer debugging something on WinCE at some point commented out the code to register virtual channels and forgot to put it back. Armed with this knowledge I shelled out cash and paid to open a ticket to get to the right person.
At which point I was told (after taking my money) that because HP provides me the ICA client for the device I needed to take it up with HP, who could contact Citrix for help. Ticket closed. It seems that OEMs using WinCE produce custom builds of the OS itself, and important apps to them like RDP, ICA, and VNC clients.
After my less than excellent experience with Citrix support (where I am in the partner program) you can imagine what I expected out of HP, where my relationship consists of my purchasing one thin client off of Ebay. But they came through. It took many calls and explanations to get to the third level support person, but once I got to this person, HP worked with Citrix and provided a new Citrix client. I now had a working virtual channel ping!
Except that we needed to upgrade from WinCE 5.0 to 6.0 to use this client. Getting the customer to agree to upgrade turned out to be a non-issue. But my problems were not over yet.
Moving to the task at hand, the scanner driver for WinCE 5.0 turns out to not work on the WinCE 6.0 build from HP. It turns out that Microsoft made some changes for drivers in 6.0. The scanner driver in question is a user mode driver. But that driver calls a system USB driver. It seems that HP's build of WinCE 6.0 delivers this USB driver only as a kernel driver (and from the Microsoft documentation it further seems that there is an option whereby HP can build it for both kernel and user mode). So now I'm trying to get HP to rebuild their OS image and fix this. I'm 9 months into this, the battle isn't over, and the customer is still waiting (and very patient!). Time will tell if we all win or all lose this fight.
Avoiding the Fight
The bottom line is exactly has Brian stated it in the video. If VDI is going to take off for the masses, simple local device connectivity is a must. No more building extra software for virtual channels, just provide a full USB remoting as part of the protocol. And that goes for everyone's protocol. Citrix and Microsoft are way behind the times here.
While at Briforum, the guys at NComputing gave me one of their access terminals (L230) to play with. It's basically a small device, probably with an ASIC or very low end processor in it (I don't really know, nor care). To use it I need to install special software on the host machine, but it provides remote video/keyboard/mouse and full USB support. Need a device driver? Install it on the host. I'm not endorsing this box as there are no doubt issues with it, and I am aware that these aren't the only guys out there doing something like this. But ultimately I am convinced that we need this for VDI to succeed. I also feel that in the end we will all end up using one of two solutions for the remoting pipe, a Microsoft or Citrix solution (VMware folks use a Microsoft solution) and that these guys need to fix their remote protocols to support remote devices better. Brian keeps saying we are a year from VDI (which I find overly optimistic, but that is beside the point)- so they don't have time to dinker.