VMware Horizon Community
jmatz135
Hot Shot
Hot Shot

Horizon View 7.12 Postsync Script with Gpupdate

We have always had a postsync script for instant clones that also runs a gpupdate /force because sometimes group policy wouldn't update properly without it.  When trying the Horizon Agent 7.12 in a pool we have found that if the script has gpupdate in it the script will always fail.  If I remove that everything else works fine.  Has anyone else seen this issue?  Does anyone know if this is intentional?  I haven't had the opportunity to make sure that group policy always updates without it now as  this is just a test pool, so it may be moot, but I'm curious about this.

Reply
0 Kudos
14 Replies
oliober
Enthusiast
Enthusiast

Hi

We use "echo N | gpupdate /force"

Tested with 7.12, without any fails.

Reply
0 Kudos
FerdiOgier
Contributor
Contributor

We have the same issue. Upgraded today and now our script doesn't work.

Will try the suggestion noted here

edit: try to change our script to but still no luck

#echo %DATE% %TIME% > "C:\Program Files\VieCuri\scripts\postsync.txt"

echo N | gpupdate /force

shutdown -r -f -t 00

----

Provisioning error occurred for Machine CSICTEST1-0003: Instant Clone agent initialization failed

Instant Clone agent initialization state error (19): Failed to execute postsync script

Reply
0 Kudos
FerdiOgier
Contributor
Contributor

Last comment in this thread C:\Windows\Temp\vmware-viewcomposer-ga-new.log file is not present on instant clone VM with Horizon ...  stated that it is a known issue.

Haven't tried this workarround yet myself.

Reply
0 Kudos
VMHero4Ever
Enthusiast
Enthusiast

We have the same issue since upgrading to Horizon View 7.12. We run powershell scripts to set different registry keys regarding our horizon instant clone pools. This part still works. But at the end of the script we want to also run gpupdate to make sure at the policies will be applied. This part doesn't seems to work and we get also complaints from our users that sometimes not all profile settings (of VMware DEM) will be applied during logon.

Did everyone test if this this fixed with Horizon 7.13 or 8.x?

 

Regards,
VM-Master

 

Reply
0 Kudos
RyanChristopher
Contributor
Contributor

We have the same command in our script that along with other commands causing Horizon to time out when provisioning new desktops. We found that with 7.11/7.12/7.13 something changed so that during the provisioning steps there is now something taking place that will at times stall/delay the postsync script with new VMs. Should it go over the 20 second default it will report back failed.

7.10 no issues whatsoever.

We ended up increasing the timeout limit to 60 seconds.

Increase the Timeout Limit for ClonePrep Customization Scripts (vmware.com)

You can easily determine this by including a date/time marker in your postsync script (echo %date% %time% >> c:\temp\pslogfile.txt) at the beginning and end of the script.

VMHero4Ever
Enthusiast
Enthusiast

Hi Ryan,

thanks a lot. I increased the timeout and now all VMs will be correct provisioned with a fresh gpupdate.
Very strange why it takes sometimes more than 20sec to complete. 

 

 

Regards,
VM-Master

Reply
0 Kudos
epa80
Hot Shot
Hot Shot

We're having the same issue on Horizon 7.13 with Instant Clones. The modification for extending the clone pep timeout looks like it has to do with a Composer regkey. Is this still the case with ICs? We tried extending it to 40, and it still failed. We can give 60 a try though.

Reply
0 Kudos
RyanChristopher
Contributor
Contributor

The registry key applies to both composer and instant clones. VMware probably just referenced the same key instead of creating/using a new one for just ICs.

If 60 seconds doesn't work you can also try adding debugging in your script to see the overall time and where you might have delays. We had put down %date% %time% markers to be able to track exactly where things were getting stalled or taking a long time to complete. Our current timeout value is 90 seconds. It usually completes before then but wanted to make sure we had a nice buffer in place.

echo %date% %time% Begin task... >> c:\temp\logfile.txt
echo %date% %time% Begin step1... >> c:\temp\logfile.txt
[commands]
echo %date% %time% End step1... >> c:\temp\logfile.txt
...
echo %date% %time% End task... >> c:\temp\logfile.txt

Reply
0 Kudos
epa80
Hot Shot
Hot Shot

Think we've found the problem. It's actually with the Defender onboarding process. Going to clean that up then try again.

Thanks for the info.

Reply
0 Kudos
rhawkins01
Contributor
Contributor

Sorry to revive a dead post but can you let me know what you're doing for your Defender onboarding or how you cleaned this up? 

We have a postsync script that runs a powershell script that creates a scheduled task that immediately runs that onboards our instant clones to Defender ATP. In all of our testing, running the MS provided script directly in the postsync section always failed the provisioning task no matter how far we extended the timer. This has been working solid for months but in the past week, we're starting to get random failures with instant clone provisioning. Some ICs complete fine, others are failing.

When I login to a failed machine, I can see that the script has executed successfully and everything is onboarded. We have two other desktop pools with different masters that are completing without an issue. I thought it was maybe a master image thing, but we last updated it in June 30 23 and the issue started around July 6 23. I created a new test desktop pool with the same snapshot with about 40 VMs, regular rebuilds of the entire pool at once are completing successfully. I'm not sure what changed but its a pretty high failure rate. Appreciate any comments you can offer.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot

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.

 

epa80_0-1689347066649.png

 

 

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.

TomKalabis
Enthusiast
Enthusiast

Hi Guys, 

 

im trying to disable defender on the login on my non-persistend desktops with your scripts, but not working in the Windows 11 Pro. 

Afrer user login, the CPU is on the 50-80% for few minutes, so is very non-confort for the students. any solution how to "restrict" Antimalware Service Executable to consume to much CPU ? 

 

Screenshot 2023-08-07 at 20.33.22.png

Thank you  

Reply
0 Kudos
rhawkins01
Contributor
Contributor

What the script is really doing is removing the onboarding data for Windows Defender Advanced Threat Protection or ATP. Defender is still a service that runs outside of this. Based on the screenshot you provided, it looks like your VM isn't onboarded to ATP.

The only registry key that I'm aware of to limit CPU usage to Windows Defender is below. I am not sure if this is the same for Antimalware.

HKLM\Software\Microsoft\Windows Defender\Scan

REG_DWORD = AvgCPULoadFactor

However, this isn't a hard and set rule - the collective average of Defender will be this value, but there are still spikes of activity that go way beyond this setting. https://www.tenforums.com/tutorials/142728-set-windows-defender-antivirus-max-cpu-usage-scan-windows...

Reply
0 Kudos
TomKalabis
Enthusiast
Enthusiast

oh sorry, im beginer with defender, yea you are right. i dont have onboarded to ATP. thank you very much for a registry key, i will try it. i have 180 VDI with Windows 11 and the Defender (antimalware secure executable) and Teams are KILLERS ! 😄 

Reply
0 Kudos