I am unable to get USB redirection to work in either windows 7 or windows 8 guests,from windows 7 or windows 8 clients. I believe the problem is related to the below excerpt from horizon log file on client
2014-08-19 13:11:57.030+-5:00 DEBUG (2CDC) [(null)] Creating new channel "1" to listener "Port1" for connection 1 of 0.
2014-08-19 13:11:57.050+-5:00 DEBUG (2CDC) [WinCDK] PCoIPWindow::OnMKSSizeChanged : new MKS size is (1024 x 768).
2014-08-19 13:11:58.536+-5:00 DEBUG (2CDC) [(null)] Error raising channel "1": Problem starting channel 1 for Port1: Failed to allocate onbound connection to 10.4.30.105:32111: java.net.ConnectException: Connection refused: no further information
2014-08-19 13:11:58.537+-5:00 DEBUG (293C) [vmware-view-usbd] CdkViewUsb_Log: ViewUsblib log: ViewUsb_FindDesktopFromHandle: handle=00000005, desktop=00000000
2014-08-19 13:11:58.537+-5:00 INFO (293C) [vmware-view-usbd] CdkViewUsb_Log: ViewUsblib log: ViewUsb_Error_CB: desktop found
2014-08-19 13:11:58.537+-5:00 ERROR (293C) [libcdk] CdkViewUsbCbFunc: callback called, reason=VIEWUSB_CB_ERROR, desktopHandle=03ACB280, msgId=213, msgString="IDS_DROPDOWN_DEVICES_NOT_AVAILABLE"
2014-08-19 13:11:58.537+-5:00 INFO (2CDC) [WinCDK] USBDevices::HandleUSBError : USB remoting is disabled for this desktop because the USB component is not available in the agent. The broker is 'fccwnwvdics01.frederick.edu'. The desktop is 'Windows7CE'.
Port 32111 is listening for connection on guest
I have checked and I can establish a connection on port 32111 using telnet between the client side and guest. We have teradici zero clients that work fine connected to the same pools/VMs
View agent is 5.3. Horizon view client is 3.0. Double checked policies in horizon view admin and everything is set to allow for USB redirection (at global level)
The thing that I saw first was the last line that says "USB remoting is disabled for this desktop because the USB component is not available in the agent". Have you tried a reinstall of the agent?
Also,check out this KB for USB troubleshooting. http://kb.vmware.com/kb/1026991
Tried reinstalling the agent, no difference. I've seen that KB before and went through most of the suggestions with no luck. Did create a new windows 8.1 pool the other day and USB redirection is working to that pool from some windows 7 clients. That pool uses the same template as the other pools that don't work. Thought it might be a service that was getting disabled after running the vmware optimization tool but all the appropriate services seem to be enabled (there is a service listening on 32111 which is indicative of the services being enabled)
We have the same problem, went through the same troubleshooting steps as well:
2015-01-06 11:48:44.614+-5:00 DEBUG (47F0) [vmware-view-usbd] CdkViewUsb_Log: ViewUsblib log: ViewUsb_FindDesktopFromHandle: handle=0000000A, desktop=00000000
2015-01-06 11:48:44.614+-5:00 INFO (47F0) [vmware-view-usbd] CdkViewUsb_Log: ViewUsblib log: ViewUsb_Error_CB: desktop found
2015-01-06 11:48:44.614+-5:00 ERROR (47F0) [libcdk] CdkViewUsbCbFunc: callback called, reason=VIEWUSB_CB_ERROR, desktopHandle=07608770, msgId=213, msgString="IDS_DROPDOWN_DEVICES_NOT_AVAILABLE"
2015-01-06 11:48:44.614+-5:00 INFO (4D64) [WinCDK] USBDevices::HandleUSBError : USB remoting is disabled for this desktop because the USB component is not available in the agent. The broker is ' '. The desktop is 'Technology'.
Some pools work fine, others do not. When I compare a log of a working desktop, only the first line is the same, though it says "handle=0000000B" instead of "handle=0000000A" All versions, files, drivers, and registry keys pertaining to VMware are the same between working and non-working.
what version of view are you running? did you just upgrade from say 5.1 to 5.2?
That's one of the things I looked into earlier, unfortunately that did not work. Our agents are 18.104.22.1684644, and our clients are Horizon 3.2.0. It's odd that some desktops work, while others do not.
ok... some basic questions (sorry if this rehashes some work you have done/discussed) ;
* are you connecting internally (ie without going via a security server)?
* what are the client / guest OS's? is there a pattern as to which do/dont work?
* in a non-working scenario, is the same client able to connect to a different guest where it works?
* is there anything installed in the guest that may be blocking the port (eg 3rd party firewall tool or similar)
I appreciate your assistance:
-Not sure about that question. We authenticate each user through AD and connect to a single server. All hosts are within a local data center.
-Both clients and guests OS are Windows 7 SP1, clients are a mix of 32 and 64 bit. Guests are all 32 bit.
-Yes, a client that receives the error can connect to a guest from a different pool and redirection will function. Some of the master images work, others do not. Each have the same versions of Agent and Tools (22.214.171.12421) and all drivers are exact matches between functional and non.
- I checked the open ports on both working and not and they were identical. Our guests and clients have Windows Firewall disabled.
It's worth noting that clients using the older (pre-horizon) View client, (5.2.1 Build-937772) have no issues with USB redirection.
the first question is more about the "location" of the clients as to whether they are inside or outsize the dmz. ie on the LAN or connecting in over the WAN via a security server. Sounds however like this is irrelevant and you are on the lan
interesting about the older client... SO - when using the older client, are you saying that you can connect to a "non working" guest and then usb starts "working" ?
ie the implication here is that the issue is more client side than agent side?
if so, on a non working client, can you check that;
a.) the vmware usb and arbitrator services are running.
b.) that you dont have any other vdi "clients" installed, or perhaps its a thin client which has a local "usb" management style app for managing other vdi vendors clients
c.) that you dont have any usb "security" style software installed on the client machine.
hmmm, but then this doesnt really make sense if the same "new" client that connects to a non working guest can connect to a working guest without client side changes....
please confirm the older client works without issues to any of the guest images and we can explore from there...
I neglected to mentioned some of the clients are Windows 8.1 64bit, they have Horizon and still see the USB issue..
I'm not sure where the blame lies, the fact that the old one works implies client issue, but the new client works on some of the guests depending on what master image they have. That points to the agent/tools - but the software and drivers are identical across all images. It's also worth noting that USB permission is the same in View Admin. vSphere also shows identical hardware settings for each machine.
All USB services are running, and none of the clients have any USB security or VDI software outside VMware.
I can confirm the older client has no issues, the majority of our users have that version. Downgrading our Horizon users is not a preferred option in our situation.
so, im starting to suspect this is a client side problem. it still might not be, but thats where i'd start looking.
do you have any gpo's set for teh client (eg Auto connect or similar)?
any chance you could attach (or private message me) your full client side debug logs rather than just an extract? ideally showing a working and non working connect ?
you haven't done anything with SSL have you on the client or agent in terms or restricting cipher suites etc and perhaps the newer client connecting to some of your guests cant find a maching compatible cipher suite? just wondering if this might be related as it might explain why the framework channel sometimes comes up....
(the full client logs will help show this if this is indeed what is happening)
In the master image can you check Device Manager and ensure the ‘VMware View Virtual USB Host Controller’ and ‘VMware View Virtual USB Hub’ are present. I’ve seen a fault where after installing the agent you are prompted to reboot but this doesn’t give enough time for the USB hub device driver to install. After installing the agent you can check the system tray and see if the device driver is being installed.
If the devices aren’t present a repair of the agent does not fix the problem, you need to uninstall/reboot/re-install.
Just my 2 pence worth and doesn’t explain why some VM’s work and others don’t.
no worries about the delay. this week is crazy for me too.
those logs dont give me enough detail. (they arent the debug logs). Im going to private message you, and maybe you would be willing to email me the original debug logs from client and agent.
Update: I identified Windows Update KM2992611 as the source of the problem. After removing it, Horizon was able to establish USB redirection.
Problem is, however, that is a critical update that addresses a vulnerability in SSLv3 and I'd prefer to leave it installed. I'm currently looking for a workaround.
looping back on this thread, and having worked offline on this, looks like we found the cause.
with View 5.3.4 because of poodle security vulnerability, SSLv3 is disabled by default after Microsoft patch KB2992611 is installed.
SSLv3 is enabled by default for older version till 5.3.3.
The issue happens here because the new clients don't support SSLv3 yet the older agents do, and once the Microsoft patch is installed ultimately an agreement on the authentication cant be reached, and the USB channel doesn't open.
The correct security advisory here is for customers to update the agents to 5.3.4. or, you could uninstall the Microsoft patch but that's not recommended.