GTO455's Posts

I just wanted to give an update on this post. Since the original post, we have upgraded a few things. Here is the current list. Environmental Specs Horizon 7.13 ESB DEM 9.11 Instant Clones Windows 10 20H2 (Ent.) 4 CPU/16 GB RAM/ 75GB Disk  NVidia M10 (1GB Profile per user) Zoom Client for VDI (5.5) Zoom Plugin for VMWare Horizon (5.5) Dell 5470 Thin Clients UAG 21.03.1 We finally got our smart cards working with ThinOS 9.1 (9.1.2101), and everything seemed to be working fine on our LAN using the thin clients until we used them to connect to our Horizon environment through the UAG's over the WAN and tried to use Zoom and/or Teams. This time I don't think it is isolated to the thin clients. If you are RECEIVING video from either Zoom or Teams in a VDI session using the UAG's and thin clients, it works great. Screen sharing works, whiteboard, presentations, etc. Even streaming services such as YouTube, CNN, Fox all work great. No lag or performance issues. However, if you are SENDING video, it is absolutely HORRIBLE for everyone who has tried it, so its not isolated to one person with a crappy ISP. At most we are getting 1fps sending through Zoom and Teams. I have checked everything I can think of. The network utilization on the VMware environment where the UAG's sit is fine. I have even tried disabling any performance settings in any GPO's we had set for PCoIP. The Network guys have gotten involved and haven't found any issues with the network or the F5's. I have placed a call to VMware support, but am yet to hear back. Anyone else ever experience something like this?

Yep, I'm still having issues with Zoom (and Teams) in general, and I'm afraid I can't help you with Zoom Phone. But, do you have anything setup for PCoIP in your GPO's? There is a setting for PCoIP session audio bandwidth under Computer Configuration/Administrative Templates/PCoIP Session Variables/Overridable Administrator Defaults/Configure the PCoIP session audio bandwidth limit

I had this same issue after upgrading from 7.10 to 7.13, however the fix posted here didn't work for me. Putting the files in C:\Windows\Temp or C:\Windows\Temp\Vmware still failed when trying to publish the pool. Extending the clone-prep timeout value did not work either. After engaging VMware support, it was discovered that placing the postsync files in a directory off of the root (for example C:\Scripts) fixed the issue for me. Just an FYI for everyone.

@DEMdev  OK, I found the issue, rather, YOU found the issue. At some point in the past I must of added my normal user account into a group that has admin rights on the desktop for testing. Once I removed my user account from the Admins group, everything works as expected. Apologies for making you go in circles! It was a beneficial exercise for me though. I picked up from another thread your trick for adding the flexdebug.txt file to the users profile to turn on debug mode. Very useful tip! Thanks!  

Hi @RachelW ,   We use O365 Containers in our FSLogix profile, and our mail files can get pretty large, so sizes can range anywhere from 30 MB to 15 GB per user. I am by no means a Teams "expert" so I'm not sure how one would shrink stuff. You could see what is taking up space by creating a couple of FSLogix profiles and then mounting the file in Windows. Its a VHD file that can be mounted in disk manager on a Windows system.

Hi @DEMdev    I am not an admin in my environment (unless I elevate to admin) and neither are my users. And I am not elevating in this case.   As a test, I completely deleted my profile and logged in, basically as a new user. ADMX policy to prevent editing the registry is enabled and allowing registry tools to run silently is enabled. I turned debugging on and I found in the log that regedit is in use successfully; 2021-02-08 11:58:52.603 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\REGEDIT.EXE" /S "C:\Users\User1\AppData\Local\Temp\FLX5AD4.tmp"' (RPAL: l=0 (F/E), r=1) 2021-02-08 11:58:52.654 [DEBUG] Read 1 entry from profile archive (size: 700; compressed: 288; took 58 ms)   However, further down the log, I see that I am still getting the error when launching Chrome   2021-02-08 12:00:47.018 [DEBUG] Found 'FlexDebug.txt' - changed log level to DEBUG 2021-02-08 12:00:47.018 [INFO ] Performing DirectFlex import for config file '\\Server1\UEMShare$\general\Applications\Chrome.ini' [IFP#ffc5e26c-49b0663>>] 2021-02-08 12:00:47.019 [DEBUG] User: Domain\User1 (A/L), Computer: VDI-059, OS: x64-win10 (Version 1909, BuildNumber 18363.1316, SuiteMask 100, ProductType 1/4, Lang 0409, IE 11.1198.18362.0, VMware VDM 7.10.0, App Volumes 2.18.0.25, DEM 9.9.0.905, ProcInfo 1/2/4/4, UTC-05:00S), PTS: 11012/11540/1C 2021-02-08 12:00:47.019 [DEBUG] Using profile archive '\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip' 2021-02-08 12:00:47.019 [DEBUG] Triggered by 'C:\Program Files\Google\Chrome\Application\chrome.exe' 2021-02-08 12:00:47.038 [INFO ] Importing profile archive 'Chrome.zip' (\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip) 2021-02-08 12:00:47.043 [FATAL] Policy prevents access to registry editing tools -- please disable this policy 2021-02-08 12:00:47.043 [FATAL] ImportRegistry::Import: Error creating command line 2021-02-08 12:00:47.044 [FATAL] Error importing archive '\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip'        

I am planning on doing a similar upgrade this week (7.10 -> 7.13) and would be interested in hearing about potential issues with the upgrade from others. I have 3 Connection Servers, 2 behind a load balancer and 1 standalone, DEM 9.9 and App Volumes 2.18. I plan on doing DEM and AV at a later date. Some of takeaways I have so far; Check the VMware Compatibility matrix for versions of all software Take screenshots of existing settings, pools, CS, etc. Back up the LDAP database using vdmexport.exe Snapshot the CS's prior to upgrade For the CS's behind a load balancer, disable the server that hosts the Connection Server instance that you are about to upgrade, and re-enable after the upgrade. Horizon 7 -7.13 Upgrade Guide -> https://docs.vmware.com/en/VMware-Horizon-7/7.13/horizon-upgrades/GUID-E3607442-8936-49A8-97B4-722D012FDF1E.html

    If I disable the policy, I do see an entry in the logs for Chrome using reg.exe 2021-02-08 10:30:30.639 [INFO ] Importing profile archive 'Chrome.zip' (\\server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip) 2021-02-08 10:30:30.645 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\System32\REG.EXE" IMPORT "C:\Users\User1\AppData\Local\Temp\FLX5054.tmp"' (RPAL: l=1 (P), r=0) 2021-02-08 10:30:34.934 [DEBUG] Read 1097 entries from profile archive (size: 9232980; compressed: 3111493; took 4290 ms; largest file: 733772 bytes; slowest import took 7 ms; registry took 140 ms)   I checked logs of other users and found that these errors do not exist with the policy enabled, which is weird. However, I delete my profile consistently during image testing, so that may have something to do with it.

Hi @RachelW , That's just it, I don't have a MS Teams profile in DEM anymore, I retired it. I tried it out by downloading it from the VMware Marketplace, and had it running for a few weeks where it grew to a ridiculous size, so I retired it. FSLogix in combination with the registry settings I posted earlier seem to be working fine for us (for now).

Hi DemDev, For clarification, are you saying I should disable UAC in the image ompletely? Currently, UAC is set to default. I checked our previous image and it is set the same way. I also checked the registry on both images and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA is set to 1. Also, if I elevate my privs to Admin while in a VDI session, I can run regedit.exe from a CMD prompt.    

Hi @RachelW, I really don't know. I have the same problem, which is why I added the Teams profile in DEM, hoping it would shrink the size of the Teams FSLogix profile, but it didn't. What I ended up with was a huge Teams zip file in DEM and a large FSLogix profile. Since the Teams file in DEM was not providing any value, I just removed it. I have heard of people running scripts on their FSLogix volumes to clean/defrag them, but I haven't gotten around to doing any research into it. If you find a way let me know!

We use FSLogix as well, and also had a profile set up in DEM for Teams too. I found the Archive files in DEM for Teams getting pretty large after a week even with FSLogix, so make sure you check your disk usage. I decided to remove it in DEM and now just have everything saved in their FSLogix profile without any adverse affects. You may also want to consider adding these registry keys to your master image to prevent users having to log into Teams with every VDI session. I got them from someone in this community, but I don't remember who. Microsoft confirmed the first registry key, but wouldn't commit to the second one. Both seem to work and not cause any harm, so I left them both in my master image. Add the following keys to block the reoccurring MDM enrollment. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin\autoWorkplaceJoin=dword:00000000 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin\BlockAADWorkplaceJoin=dword:00000001

Hello, Thanks! Since I made this post, I removed or "retired" the Teams config in DEM and haven't seen any issues, and in fact, recovered quite a bit of disk space. We don't allow our users to install apps, so I have Teams installed on the master image and used the per machine installation (msiexec /i <path-to-teams-msi> OPTIONS="noAutoStart=True" ALLUSER=1 ALLUSERS=1) You might want to try adding the following registry entries into your master image to stop the reoccurring login issues. I got these settings from someone on this site and since I added them, users don't have to log into Teams every time they start a VDI session anymore. Add the following keys to block the reoccurring MDM enrollment. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin\autoWorkplaceJoin=dword:00000000 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin\BlockAADWorkplaceJoin=dword:00000001  

Thanks. I will look into this as soon as I can get my thin clients to work consistently with 9.1. We use smart cards and having issues with ThinOS recognizing the cards/certificates. ThinOS 8.6 works fine though.   Never a dull moment.