Word of warning for anyone starting a UEM migration, it appears that UEM can mess with PCoIP USB if it is left in a running but unconfigured state.
We installed UEM in a Gold master image and left the service to automatic startup, with no UEM GPO's were applied to the linked clone pools. (We were preparing for UEM migration/testing)
USB devices fail to attach in the initial login session, a reconnect on PCoIP allows the devices to pass through from the Zero client. The issue also seems to delay the attachment of Appvolumes appstacks. PCoIP server log reports:
LVL:1 RC: 0 SOFT_USB :VHUBLIB(error): GetUemStatus : Failed to open key path is Software\VMware, Inc.\VMware UEM\SessionData\1
LVL:1 RC: 0 SOFT_USB :VHUBLIB(error): The UEM component is still not ready yet
Workaround is to set the service to manual/disabled until UEM is required for a desktop pool. If UEM is enabled at login (say via the GP extension method), the issue does not occur. We didn't raise a case for this, but an interesting one anyway.
(UEM 9, Appvol 2.9, Horizon 7)
Josh
Hi nhsbonn,
Sorry to hear things aren't working as they should for you. As this thread is very long and deals with a bunch of different issues, would you mind starting a new thread with the specifics of your environment and the issue that you're seeing?
Hi All,
Just wanted to append my recent experience with this issue and some details about my environment -- hopefully it will help work towards the permanent resolution of this issue:
Windows 10 LTSB2016 (1607), fully patched including Feb2019 updates
Horizon 7.6.0, non-persistent pools (refresh after logoff)
Horizon Clients 3.5.2, 4.2.0, and later (up to current)
AppVolumes 2.14.2.11
UEM 9.5.0.832, running in Group Policy mode, some DirectFlex applications enabled
Mix of both 10Zig and Dell Wyse Thin Clients (300+ clients, various models)
Before any troubleshooting, we experienced the following symptoms:
Before troubleshooting the issue, I had assumed that the fault was with Exclusions listed (or not listed) in the AppStack's snapvol.cfg. My initial assumption was that some Group Policy based settings were being reverted\overwritten by the AppStack. In the past we have created some AppStacks using Domain Joined computers, so maybe some policy settings had become embedded in the stack. However, after inspecting the snapvol.cfg, it appears that all proper Exclusions exist to keep Group Policy related items out of the stack. Searching elsewhere for answers, I stumbled upon this thread. I am not using Horizon Smart Policies within UEM in any capacity, nor do I have any near-term plans to do so, so I figured that disabling the Smart Policies would be an easy test.
I implemented BOTH the 'HorizonLogic' AND 'UemFlags' registry keys per the other posts in this thread -- and the issue is resolved! I am not sure which key correctly resolved the issue, however I don't see any harm in leaving them both set for the time being.
We now see the following behavior at logon:
It does seem that a mix of AppVolumes\UEM\Horizon Agent interplay is happening here, where potentially some critical registry key is being virtualized inappropriately by the AppStack and UEM and\or Horizon Agent cannot perform the relevant queries required to perform USB Redirection decisions during the logon cycle. However rather than futz with all my snapvol.cfg files to determine the missing exclusion (we have many AppStacks built), this global disablement of Smart Policies was the easier way to resolve the issue.
EDIT: It appears that the above keys did not fully resolve the issue in all scenarios. After some more troubleshooting, it appears that original poster was on the correct track: Some AppStacks have virtualized the Registry Keys under "HKLM\Software\VMware, Inc.\Vmware UEM\SessionData". Having these Keys virtualized precludes the 'UemState'=DONE Key from being recognized properly during session creation. I can see in the snapvol.cfg that "exclude_registry=\REGISTRY\MACHINE\SOFTWARE\VMware" is now commented-out (prefixed with #), and a secondary entry for "exclude_registry=\REGISTRY\MACHINE\SOFTWARE\VMware, Inc.\VMware VDM" has been created beneath it. It looks like some AppVolumes update likely changed this key -- I wonder what would have been the reasoning for this? I can't imagine why I would want to capture any of the settings in "HKLM\Software\VMware, Inc." into an AppStack, although I'm sure it's necessary depending on the VMware product being installed into the AppStack. I am working now to exclude & remove these Registry Trees from my (many) existing AppStacks and templates -- if removing the keys does not fully resolve the issue I will report back. I will also be looking to revert my previous workarounds after these changes, since I realize they may not be necessary in my configuration.
We encounter the same Problems in our DEV environment.
acutall we use UEM 9.6, Horizon 7.6 and Appvolume 2.16
Testing abit whit some Regkeys apointent to the USB Redirection Smart Policys of the UEM
Has anyone else had trouble with USB devices with Horizion 7.8, zero clients, and UEM 9.7?
We have these registry entires on the master image of our instant clones:
HKLM\Software\VMware, Inc.\VMware VDM\Agent\USB\UemFlags DWORD set to 1
HKLM\Software\Immidio\Flex Profiles\HorizonLogic DWORD set to 0
USB devices on our Wyse P25s with firmware 6.4 do not work until the session is disconnected and reconnected.
Master image is Windows 10 LTSC (1809).
We are using, in our testing, a single, writable, App Volume (2.17.0.50) with UIA+Profile.
Thanks for any input!
Do you mean the issue that results in USB redirection not being available? If so, you can use the key/value below (default timeout is 60 seconds). You can extend to (for instance) 200 seconds.
Use the existing or create new reg sub key:
HKLM\Software\VMware, Inc.\VMware VDM\USB
Create a REG_DWORD:
WaitForSessionIdTimeout
Give it a decimal value of 200 (for 200 seconds)
Make sure above is part of the golden image and a reboot has been performed.
This should fix the USB redirection not being available issue.
WaitForSessionIdTimeout
Thank you!
So, after some testing, most USB devices are available immediately (printers, thumb drives). The scanners, unfortunately, are not. If I try to use a scanner in the first 60-seconds or so after logging it, the scanning fails, saying the scanner cannot be found. Turning the scanner off and back on fixes the problem. Of course if I wait about 60 seconds, they always work. If I disconnect from that and log in to a pool that does not use App Volumes, the scanners are always immediately available.
It's not perfect, but its (mostly) working.
I'd be interested to know if anyone else has trouble like this. The scanners are Fujitsu models 6130 and 7160 using IP Stream TWAIN driver 1.42.
Thanks!