GTO455's Posts

Adding my 2 cents as well. We recently upgraded to 2306 and seeing the error as well, but only concerning internal Connection Servers, my UAG's are showing all green. I sent my "LB Guy" the relevant VMware KB's, but he can't find anything wrong. Looking at the debug logs, we see the following lines, but searches haven't turned up anything of value (except this thread). Nothing immediately immediately before or following this entry provides any relevant information either. <MessageFrameWorkDispatch> [MessageFrameWork] KeyVaultWorker::MessageHandler(): KeyVault service got operation=decipherWithDerivedKey, ok=1, msecs=16 <ajp-nio-127.0.0.1-8009-exec-1> [ConnectionServerHandler] Incrementing the warning count : Reason : unrecognized request detected

Yes I did. There doesn't seem to be a config for Brave. The application profiler works OK, but I found the best config for Chrome came from users here in the forums. Since Brave is based on Chrome, I will just try to reconfigure that for Brave.

I probably should have added my Chrome DEM config in my initial post. It contains most of the same settings as yours (and then some). I found this config here. [IncludeRegistryTrees] HKCU\Software\Google\Chrome [IncludeFiles] <LocalAppData>\Google\Chrome\User Data\First Run <LocalAppData>\Google\Chrome\User Data\Local State [IncludeFolderTrees] <LocalAppData>\Google\Chrome\User Data\Default <LocalAppData>\Google\Chrome\User Data\Profile 1 [ExcludeFolderTrees] <LocalAppData>\Google\Chrome\Default\Cache <LocalAppData>\Google\Chrome\User Data\Default\Application Cache <LocalAppData>\Google\Chrome\User Data\Default\Cache <LocalAppData>\Google\Chrome\User Data\Default\GPUCache <LocalAppData>\Google\Chrome\User Data\Default\IndexedDB #<LocalAppData>\Google\Chrome\User Data\Default\Local Storage (this is where Google Earth Settings are saved) <LocalAppData>\Google\Chrome\User Data\Default\Media Cache <LocalAppData>\Google\Chrome\User Data\Default\Session Storage <LocalAppData>\Google\Chrome\User Data\Default\Storage <LocalAppData>\Google\Chrome\User Data\Default\Sync Data <LocalAppData>\Google\Chrome\User Data\Default\Sync Data Backup <LocalAppData>\Google\Chrome\User Data\Default\Web Applications #These settings were added to reduce Chrome Profile size. Undo them if you run into any issues <LocalAppData>\Google\Chrome\User Data\Default\blob_storage <LocalAppData>\Google\Chrome\User Data\Default\BudgetDatabase <LocalAppData>\Google\Chrome\User Data\Default\data_reduction_proxy_leveldb <LocalAppData>\Google\Chrome\User Data\Default\Feature Engagement Tracker <LocalAppData>\Google\Chrome\User Data\Default\Pepper Data <LocalAppData>\Google\Chrome\User Data\Default\Platform Notifications <LocalAppData>\Google\Chrome\User Data\Default\Service Worker <LocalAppData>\Google\Chrome\User Data\Default\Sync Extension Settings <LocalAppData>\Google\Chrome\User Data\Default\VideoDecodeStats <LocalAppData>\Google\Chrome\User Data\Default\webrtc_event_logs <LocalAppData>\Google\Chrome\User Data\Default\databases <LocalAppData>\Google\Chrome\User Data\Default\Download Service <LocalAppData>\Google\Chrome\User Data\Default\File System <LocalAppData>\Google\Chrome\User Data\Default\GCM Store <LocalAppData>\Google\Chrome\User Data\Default\Thumbnails <LocalAppData>\Google\Chrome\User Data\Default\Code Cache [ExcludeFiles] <LocalAppData>\Google\Chrome\User Data\Default\Network Action Predictor <LocalAppData>\Google\Chrome\User Data\Default\Network Action Predictor-journal <LocalAppData>\Google\Chrome\User Data\Profile 1\Network Action Predictor <LocalAppData>\Google\Chrome\User Data\Profile 1\Network Action Predictor-journal *.tmp

I'll add my own fix to this. It appears that either a Windows update, a Chrome update, (or both) caused the original issue. A full restore of the host to a date prior to the Windows update was performed. The system was booted, VMware Tools, VMware agents and Chrome uninstalled. Then we performed a manual update of Windows patches, and a reinstallation of Chrome, VMware Tools and Agents and everything returned to a normal state. 

When we are testing configs in DEM, we usually create a condition set. Usually in the condition set we just apply the config to a specific user or group and test. If testing is successful, we remove the condition set and apply it to all users

Thanks for replying and the suggestion, but for some reason it stopped happening shortly after posting, and the issue has not returned, but I'm not exactly sure why. And I cannot make it reoccur. FWIW, when the issue was present, I had 6 different ost/nst files in my %localappdata%\Microsoft\Outlook folder. A new one would get created every time I launched Outlook at a new login. All had the same filename with the traditional Windows (1), (2), (3) at the end of the filename.

Is your template VM in the same OU as your pool? We ran into something similar recently when we switched the network for our master image. We switched the network, created a new snap and provisioned the pool. The VM's came up on the right network, but none could get IP's. I had to actually power on the master, let it register with the host, get an IP, seal the image again, take a new snap and republish the pool.

Did you try running a gpupdate /force before sealing your image? I don't know if its required, but I have recently added that to my cleanup script. I haven't really seen a difference in my case (my master image is not in the domain) but it I guess it can't hurt.

The Citrix registry key has nothing to do with Citrix. It was an error that I got while trying to install Teams. I Googled the error and found the resolution here. (Look under the Installation with AppLayering section). However, if the key remains after Teams is installed, you will find that Teams will not be optimized for VMware Horizon. More on that here. The MDM keys I found while searching for issues with auto enrollment on this site. I quickly searched for the post, but couldn't find it. The CloudType registry key is based on your tenancy. It can be found on this page, (it's the same page I linked in my earlier post with the links to the Teams downloads) I normally don't use the GPU setting-only in cases where users are complaining about video performance in Teams. Since it is a json file, I couldn't find  way to set it for all users on the master image. Info on the GPU setting is also in the reddit post I linked above. For DEM & Teams, I just did some testing and found that since we were using FSLogix, and it kept the users' information when they logged out, there was no need for a separate profile in DEM. It was (in this case) redundant.

Ahhhh Teams... Good times... The language it is written in is Electron, and it is garbage. Supposedly it is being rewritten. We will see.  Yes, we got it to work, but with every new version released, it's always fun to see what works, and what used to work is now broken. We use FSLogix instead of writables so there is no need to create profile for it in UEM, (and if you do, it will create huge profiles that aren't necessary). Here are the notes I have for my installation on my master image. We have a different tenancy than most, so take the following with a grain of salt. Download the latest .msi installer from Microsoft. https://docs.microsoft.com/en-us/microsoftteams/msi-deployment Install it using the following switches: msiexec /i <path-to-teams-msi> OPTIONS="noAutoStart=True" ALLUSER=1 ALLUSERS=1 This is for a non-persistent (instant clone) setup, the Teams desktop app must be installed "per-machine" on the golden image. Note 1: When installing on Windows 10 using ALLUSER=1 property, MSI will return error: Installation has failed. “Cannot install for all users when a VDI environment is not detected.” To resolve this, the Teams installer needs ”HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA” registry key to be created on a target and then the install will complete successfully. Remove it after installation or Teams will not be optimized for VMware Horizon Note 2: 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 Note 3: When troubleshooting Teams, close Teams and delete everything under "C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Teams" and have the user restart Teams   Note 4: If Teams fails to start, verify this key is not in the master image. If it is, remove it. This was a suggested setting from Microsoft, but it does not work and causes connection failures. [HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\Teams] "CloudType"=dword:3 Note 5: Disable HWA in Teams User settings for Teams are saved in a JSON file desktop-config.json: %APPDATA%\Microsoft\Teams\desktop-config.json Search for DisableGPU in the file, and change the setting from “disableGpu”:false to “disableGpu”:true.