USB Drives and Mobile phones not showing up in VM

[AlexLSx7]

We have had a reoccuring problem for quite a few people now where they will plug their USB storage drive or Mobile phone into their VM and it wont appear in the VM through Windows. Sometimes they do appear, but more than likely they wont.

They show up on the thin client or zero client (We use 10Zig 5984qv and HP T310s) so it cant be them.

Any ideas on where to start looking at this issue?

Some people never seem to have the problem. Obviously most of the USB drives are completely different but most of the phones are exactly the same as they are company provided.

[BenFB]

Are users just looking to charge their phone or does it need to be available for data transfer? We don't allow data transfer so we disable USB redirection (This can be done on the Horizon Agent, with UEM/Smart Policies, via firewall rules or on the thin/zero clients directly). This will allows the users to still connect their phones for charging.

[AlexLSx7]

Our users use their phones to take pictures so we need the storage working.

[DEMdev · Accepted solution]

Hi AlexLSx7,

Are you by any chance using VMware UEM? There's an issue in the Horizon agent (versions 7.4 and 7.5) where USB redirection is turned off under certain circumstances if UEM is installed (regardless of whether any Horizon Smart Policies are configured in UEM).

If you do indeed have UEM installed, can you try creating a REG_DWORD value uemFlags in key HKLM\Software\VMware, Inc.\VMware VDM\Agent\USB on the agent machine, and setting it to hex 101 (decimal 257)?

[AlexLSx7]

Yes we are using 7.5 and UEM!

I will give that reg key a try, thank you.

EDIT -

I have just looked in the registry and cannot see the full path you mention, there is no "USB" key only HKLM\Software\VMware, Inc.\VMware VDM\Agent

[DEMdev]

Hi AlexLSx7,

Just create the USB sub key under Agent.

[AlexLSx7]

Great thanks, i did that anyway just incase. Just rolling it out to some test machines at the moment, fingers crossed.

[DEMdev]

Hi AlexLSx7,

I was curious whether you have any news on this.

[AlexLSx7]

Sorry its been real hectic here had a lot of problems and didn't get a chance to reply.

Yes, that reg key did work, thanks for your help.

[DEMdev]

Hi AlexLSx7,

Happy to hear that this solved your issue; thanks for the feedback! With the next release of Horizon and UEM this workaround should no longer be required.

[nzorn]

We upgraded our environments from Horizon View 7.3.1 to 7.8 and started having to disconnect/reconnect users View Session in order to get USB devices working, the problem does not happen all of the time though.  We tried various agents and are still seeing the problem (7.6, 7.8, and 7.9).  We are using UEM 9.7.

Do you think this registry key might fix this problem?

[nzorn]

Just wanted to update that this registry key fixed our issue, so this has NOT been fixed in the agent or UEM yet.  We still need to apply this workaround.

[a_kader]

Hi DEMdev,

we also had this error in our environment. "Horizon View Agent v7.5.1" and UEM 9.2.1 (Win7 and Win10 FullClone) and the registry hack fixed the error. Thank you for your hints. In addition we tested to disable the UEM-Service in control panel but this does not change the behavior. My question is: Is it right that the error comes from the View Agent or from UEM?

VDM\Log

debug-2019-11-07-021048.txt:2019-11-07T10:29:40.370+01:00 DEBUG (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] USB is allowed by GPO

debug-2019-11-07-021048.txt:2019-11-07T10:29:40.370+01:00 DEBUG (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] UEM is installed

debug-2019-11-07-021048.txt:2019-11-07T10:29:53.573+01:00 DEBUG (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] vhublib: Uem timeout is 120 seconds

debug-2019-11-07-021048.txt:2019-11-07T10:31:53.587+01:00 DEBUG (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] vhublib: Check [UemState]->[DONE] timeout

debug-2019-11-07-021048.txt:2019-11-07T10:31:53.587+01:00 INFO  (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] vhublib: Uem engine timeouts in 120 seconds

debug-2019-11-07-021048.txt:2019-11-07T10:31:53.587+01:00 DEBUG (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] Usb is not allowed by UEM. sessionId=8

debug-2019-11-07-021048.txt:2019-11-07T10:31:53.587+01:00 DEBUG (0A50-2BC8) <MessageFrameWorkDispatch> [ws_vhub] USB policy set to disallowed

Is there any version out now which does not have this error?

Thanx

Achim

[DEMdev]

Hi Achim,

(Apologies for the delay; I was on holiday.)

The USB component of the Horizon agent needs to wait for UEM/DEM to apply its Horizon Smart Policies settings before it can read its configuration. The default timeout for this is 120 seconds, which is what you encountered in the logon for which you posted that log file fragment.

Normally, that timeout should be more than enough, but if the logon is very slow, UEM might be delayed so much that it does not get launched within 120 seconds from the start of the logon.

Do you consistently encounter this problem? Are there any VMware or third-party products that might be delaying the logon? Are you trying to log on using a USB-based smart card?

Configuring that uemFlags registry value as described in this thread turns off the "wait for UEM to have run before reading configuration" logic. That means that the USB component won't wait, but also that you can't use Horizon Smart Policies to disable USB redirection (which might be fine for you, depending on your use cases.)

It's also possible to change that 120 timeout: just create a uemTimeouts REG_DWORD value in the same registry key, set to the timeout length in seconds.

As for other versions: you definitely should consider upgrading from 9.2.1, as that reached its end of general support last May, but USB redirection remains a bit non-robust in later UEM/DEM/Horizon versions as well, I'm afraid... In UEM 9.5 we added a fix for a Horizon agent issue (requiring Horizon 7.6+), but that's a different issue than you encountered. And the most recent Horizon agent versions seem to have a different timeout-related issue as well... Anyway, let's first try to find out more about the problem you're currently seeing.