VDINinja311's Posts

jesseboehm214​ [HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\Agent\USB] "UemFlags"=dword:00000101 This was what was provided by VMware Support to "fix" the USB Unavailable message for USB redirection.

MikeC3964​ Do you use Writable Volumes? We had a single instance of this exact same error so far in our implementation of MS Teams. The writable was capturing something (we didn't look that far into it and I assume its what you are seeing with the newly modified directory) and deleting the writable was the fix for the user. We only use the writable for hosting .OST, so its not too big of a deal.

Unfortunately, this sounds like a different issue than the one we are seeing based on your troubleshooting. The registry key was to help with  "USB Unavailable" coming up in the USB redirection list. Doesn't look like you are having that issue.

jborrasproa​ The reason I mention both the disconnect/reconnect and writables volumes is we are seeing the same type of behaviors in MS Teams and cameras. For some users it is displaying the black screen like you are describing. We are having several issues, one is that the Horizon client is showing "USB Unavailable". VMware gave us a workaround for that (the registry key basically just bypasses all Horizon Smart Policies and enables USB redirection). Helped us with that issue. We are seeing that if the user disconnects and reconnects that the camera works again (I believe this was the same USB redirection issue and the registry key they gave us helped with that). We also saw that if you deleted the users writable volume, it would also fix the black screen issue for a period of time (Seems like weeks if not months, unknown on timeframe), but we are thinking something in the writable volume is getting captured which is causing the issue. Have you deleted the writable volume for a user to see if that helps temporarily?

pbastiaans​ We have successfully packaged Sage Fixed Assets for several years now (2018, 2019, 2019.1 and 2020 and now 2020.1). We run the Premier Depreciation piece of FAS. It's been a long time so I cannot remember if we ran into the same issue you have, but several things we have done special for this application to run correctly in our environment. During AppVolumes Packaging: Normal install for this program, we run setup.exe from the Server install location, usually something like \\%FIXEDASSETSSERVER%\FASServ\Premier Client\ After install we disable the "Sage Advisor Update" service We overwrite a license file after the install. (This is is directly from Sage Support, this allows non-persistent desktops to function correctly using their licensing scheme). As their licensing used to be tied each user to a computer name. After install we run the application and enter in our Customer information and Customer #. DEM Settings: We couldn't have DirectFlex turn on for this. Export is on logoff. We have Privilege Elevation setup for this application's EXE otherwise it wouldn't run. We have Predefined Settings for all the ODBC connection information in the registry to set the server name for the application as well as some application settings for all users. We have an Application Blocking white list setup to allow C:\Sage\* Our current DEM Import/Export config: # Flex config file generated with VMware User Environment Manager Application Profiler version 9.2 [IncludeRegistryTrees] HKCU\Software\Sage Small Business Division Desktop [IncludeIndividualRegistryValues] HKCU\SOFTWARE\ODBC\ODBC.INI\BESTSYS32\AnsiNPW HKCU\SOFTWARE\ODBC\ODBC.INI\BESTSYS32\Database HKCU\SOFTWARE\ODBC\ODBC.INI\BESTSYS32\Description HKCU\SOFTWARE\ODBC\ODBC.INI\BESTSYS32\Driver HKCU\SOFTWARE\ODBC\ODBC.INI\BESTSYS32\LastUser HKCU\SOFTWARE\ODBC\ODBC.INI\BESTSYS32\Server HKCU\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources\BESTSYS32 HKCU\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources\WINFAS32 HKCU\SOFTWARE\ODBC\ODBC.INI\WINFAS32\AnsiNPW HKCU\SOFTWARE\ODBC\ODBC.INI\WINFAS32\Database HKCU\SOFTWARE\ODBC\ODBC.INI\WINFAS32\Description HKCU\SOFTWARE\ODBC\ODBC.INI\WINFAS32\Driver HKCU\SOFTWARE\ODBC\ODBC.INI\WINFAS32\LastUser HKCU\SOFTWARE\ODBC\ODBC.INI\WINFAS32\Server

hschimpf​ In your screenshots I also see some Active Setup for Chrome. I don't know if you use AppVolumes for Chrome but I'd suggest deleting this StubPath key as well for Chrome. Every update to Chrome this gets put back in and is needing deleted as well. Delete only the StubPath key.

hschimpf​ I don't remember if the OSOT fling removes these but during our optimization we go into "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components" AND "HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components" and delete any of them that have a StubPath key. Only Delete the StubPath key. We have done this optimization ever since Windows 10 1511 as it was causing login time delays. We do this on every build. There is usually a minimum of 4 or 5 of those under Installed Components that have StubPath keys that can be deleted. Especially check this one. Hopefully this helps.

Technically its active/active as the referral ordering is just weighting one more than the other. It seems like 90% of the SMB connections go to the file server weighted heavier and 10% still go to the other file server. The UEM GPO's are pointed at the DFS namespace for the UEMProfiles and UEMConfig folders.

jooji_marsh​ We have DFS-R setup between two Windows Server 2012 R2 file servers one at each Datacenter. This is hosting our VDI users' homeshares as well as UEMconfig and UEMprofile shares. We have a 10Gbps pipe between the two DC's so we are good there. We originally had the default setup of basically a round robin approach so it would hit either of the two servers but we started having issues as DFS-R wasn't able to keep up with the replication and was causing some data inconsistency issues between the two. It kept seeing multiple changes to files on the two different servers. The few things we have learned since implementing: 1. Override the referral ordering so that one file server would be set as "first among all targets" that way all the desktops would read/write to that one and DFS-R wasn't getting multiple changes to files on both servers. 2. Make sure to set the staging quota high. We started off small and have had to grow the staging quotas to now 192GB or higher. We kept seeing where it would hit the highwater mark a lot and purge files. 3. We setup the Log Insight agent to capture certain DFS-R event logs so we know when replication is broken. This is just for peace of mind for us two admins. Hope this helps a bit if you go that route. Otherwise no real issues since we setup the quota's to the correct size and the referral ordering. We currently run ~325 daily non persistent desktop sessions with this setup.

KjellO​ You might have just helped me solve our random USB redirection issues that we have been having as well. Horizon 7.6/AV 2.16/UEM 9.5. I have been struggling to pin down the exact issue here in the last week or two. I am seeing these same messages in my Debug VDM client logs when the client says "USB Redirection is not available". Going to test this and let you know.

we created an executable of a ps1 script to add windows.immersivecontrolpanel appx package at login through UEM which resolved the settings not launching. What do you mean by the settings not launching?

Sabian0309​ I thought we were alone in this issue! We have had an SR open with AppVolumes support since 5/10/2019 for this same issue. Can confirm its happening with both the 2.16 or 2.17 agents. We upgraded the servers and agents from 2.14.2 as well to 2.16 and this is when we noticed it started. We have since been using the 2.15 agent as a workaround. It seems random because just a few weeks ago we were able to do an upgrade from the 2.15 to 2.16 agent on some of our master images and on our UAT or GPU desktop pools we were not seeing the issue so we were going to deploy it to our production pools and immediately after recomposing we saw it go nuts again, so we recomposed back. Windows 10 1803 Linked clones here. You also on linked clones?

epa80​ We also originally started with PCoIP 3+ years ago and in the last year and a half migrated completely over to Blast. We had basically no issues converting over. The end users really only noticed that the resizing of the welcome screen upon connecting was faster on Blast, otherwise no one cared or noticed. We had maybe two users that complained about the blurry text in Office products (Needed the H.264 High Color Accuracy checked) and they were fine. We use a mixture of old Lenovo desktop hardware thin clients (Stratodesk linux) and HP branded thin clients. No issues with Blast. I do think that Blast is a little more heavy on CPU consumption when the desktops don't have vGPU's attached. (task workers, etc).