epa80's Posts

FYI VMware has updated the KB with this resolution entry:     Horizon Administrator: Error message: InvalidPipeArgument: 'Missing locale data for the locale "en".' for pipe 'e' in User Interface after a browser update (94667) (vmware.com) We did open an SR and obtained the hotfix. It does seem to have resolved our issue in early testing.

What version? As far as I can tell, I'm on the latest Firefox (118.0.2) and I seem to still be ok. I tested in 7.13.1 and 2111.2. I went to events as well as the dashboard status window, where I usually see the error, and it seems ok.

Our issue is still ongoing. It's a random issue and all of the listed troubleshooting steps in this thread were eliminated early on as causes/fixes. We are currently engaged with VMware professional services on a Horizon 8 upgrade, and when finished we plan to take a fresh look at it. I'll update the thread as we go along.   The slowness in loading a desktop can happen randomly on both persistent as well as non-persistent desktops. So the profile creation in this scenario is moot. 

I'm involved in another thread where this discussion kind of spiraled into. Take a look at that, specifically my last post there.   Re: Horizon View 7.12 Postsync Script with Gpupdat... - VMware Technology Network VMTN

Yeah we were running into basically the same thing. Had a Horizon post-sync task call on a script that was in the gold image, but then every time we did, no matter how much we extended the timeout, it would spin up several good VMs but eventually hit a bottle neck and die out.   We resolved it by modifying our script as follows:   cd "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Cyber" del "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Cyber\*.*" /f /s /q REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection" /v senseGuid /f Start PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& 'C:\systools\Onboard-NonPersistentMachine.ps1'"   So it does a cleanup of the VM first to delete any onboarding keys ahead of time, then onboards it again. The "Start" on line 4 will close out the open window processing the onboarding, letting Horizon move on in provisioning while the activation is happening in the background. This is where the hang up existed before. Horizon stupidly waited for the window to go away before it moved on, even though that window is inconsequential to Horizon provisioning. It's strictly Defender. So yeah, "Start" on that line will let it move on.   I do want to add in this: we had to disable several tasks on the gold image (and have to watch for them to get re-activated when patching), as we were seeing a HELL of a performance hit at random times, that Microsoft couldn't pin down. They did state to us that they think the tasks are not needed in a non-persistent world, hence we've left them disabled.       If anyone has any luck leaving them enabled, go nuts. We struggled big time. This was even after we introduced a Shared Intelligence server per Microsoft's best practices.

OP on Reddit in this same thread has a workaround listed. I haven't tried it myself, but sharing here.   VMware Downloads Page - Not Loading : vmware (reddit.com)   EDIT - thanks to u/govatent for this workaround that worked for me Set your computer host file this way: 23.44.100.30 customerconnect.vmware.com I needed to reboot before I got it to resolve properly.

We don't onboard the gold image, no. You'll see above in our post-sync task, we actually run steps to clear any possible onboarding data on VMs as they spin up/are deleted. This was detailed here: Onboard non-persistent virtual desktop infrastructure (VDI) devices - Microsoft Purview (compliance) | Microsoft Learn Note If you have onboarded the master image of your VDI environment (SENSE service is running), then you must offboard and clear some data before putting the image back into production. Ensure the sensor is stopped by running the command below in a CMD window:   sc query sense   Run the below commands using PsExec.exe (which can be downloaded from https://download.sysinternals.com/files/PSTools.zip)   PsExec.exe -s cmd.exe cd "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Cyber" del *.* /f /s /q REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection" /v senseGuid /f exit  

The OSOT can really jack up Defender if you used it to disable Defender previously on your gold image (as we did, since we used Trend Micro). These are the steps we had to perform to get it back to working. Apologies if crude, it's what we wrote kind of on the fly and never went back to.   Initial Defender setup on a base Uninstall Trend Micro Deep Security Notifier   Local GPO on the base: Computer Configuration>Administrative Templates>Windows Components>Microsoft Defender Antivirus Go thru all settings in the subfolders and make sure they are all set as Not Configured Running the OST set some of these values, but we want everything under Microsoft Defender Antivirus to be Not Configured. Reboot - don't skip this reboot. you have to do this reboot or the registry changes below won't do enough.   Change start up types for these four services. You can't change the startup type for these services in the GUI so go to the registry and change there. HKLM\System\CurrentControlSet\Services\   Windows Security Service SecurityHealthService change to 3       Windows Defender Advanced Threat Protection Service (This is used for Onboarding, if Sense is Stopped, the VM is not Onboarded) Sense change to 2     Microsoft Defender Antivirus Service WinDefend change to 2       Security Center wscsvc change to 2     Reboot after changing Services registry values

In our environment we're doing a post-sync task in Horizon as well, a .bat file that runs the script below. We have exclusions provided via a GPO linked to our non-persistent OU.     And these are how our tasks look:    

Hi @Jubish-Jose,   We have. At the very worst we have a workaround in place that seems to have fixed our issues. We ended up disabling all scheduled tasks related to Defender on the gold image, except for the "Windows Defender Update" task. We also are utilizing a Security Intelligence server per Microsoft's design document. However, we think all of our issues were related to those scheduled tasks. They just hammered us and the issue didn't go away until we disabled them outright in the gold. Microsoft had the opinion that in a non-persistent world, which ours is, those tasks should be benign.

Yeah, we hear you. We're a Hospital/University and a LOT (all) of our update cycle is determined by our main healthcare software vendor, and sometimes security. They don't always line up. IE the vendor, doesn't want many changes going on to ripple into their app, and instead asks that updates for the REST of the OS, only go out to coincide with THEIR own updates. After testing of course. Needless to say, their schedule isn't always "regular", so it doesn't leave a lot of room for updating routinely.   We'll take a look at the document you sent though. Specify version might be a thing that could work by the sound of it.

We're almost 100% at this point, that it has to do with the tasks in the Windows OS for Defender all, for some reason, having a "next run time" too close to each other across out pool(s). What is perplexing us, is other pools, using the same snap and Defender GPO, seem to have VERY spread-out timings for these tasks. They run the spectrum of time throughout the day, almost like the times get set on say refresh. Whereas our problem pools, they ALWAYS seem to want to run from 3-4PMish. We aren't sure if something happens on the clone parent creation perhaps? Or perhaps because we did a pool republish in place vs. one big mass republish (meaning in the former, the logoffs cause the full repub to go slower, thereby randomizing the times perhaps?).   At this point we're basically disabling those tasks via a script until we figure out why the pools go out with the times so close together. We have several settings to randomize tasks in the GPO, but, Microsoft is extremely confusing.

I was on 2 VMs today when the issue started, around 3:40PM. It calmed down around 4:30PM give or take. When I looked in Task Scheduler on both VMs, we saw the tasks for Defender all ran, and finished, in this window: VM#1     VM#2:         Our assumption is the clone is going out with the tasks in that ballpark. We have a GPO for Randomization of tasks, but perhaps this isn't in reference to THOSE tasks. We're wondering if we should maybe disable these tasks outright on the gold image.