rhawkins01's Posts

We have this working on our Access Portal. I followed the steps in these links: https://docs.vmware.com/en/VMware-Workspace-ONE-Access/services/workspaceone_okta_integration/GUID-3CA49953-A8F6-491D-90DF-63588EFC3292.html https://docs.vmware.com/en/VMware-Workspace-ONE-Access/services/workspaceone_okta_integration/GUID-3549863C-64E8-4F86-8842-E2A585987A43.html  Ultimately, you have to configure Okta as an Identity Provider in WS1 and WS1 as an IdP in Okta. Then you can set it up so WS1 can use Okta as an application source. When setting this up, i configured the Single-Sign on URL and the Recipient URL as the same. The application ID came from Okta or my Okta team i believe - its been several years since I set this up. It might have come from the XML I received as well. Start here and let us know if you run into problems.  

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-10-a.html

Thank you so much for this post! We've been migrating/rebuilding our AppVol 2.x AppStacks to AppVol 4.x packages. We've been seeing a lot of applications have issues during testing - mostly Adobe Acrobat, SnagIt, Notepad ++, etc -- simple apps that worked great in AppVol 2.x. As part of this effort, we're testing on Win 11 22H2. I built that master image with all of the latest agents - including the problematic FSLogix agent. Downgrading to 2.9.8361.52326 seems to have solved all of those issues.  Your post has helped at least one person and I wanted to let you know!    __PRESENT

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.

We came up with a different solution in our non-persistent environment. We use a post-synchronization script to configure some settings on each Instant Clone after its provisioned. We added a step to that document to create a scheduled task that then immediately executes the Defender ATP onboarding powershell and configure our exclusions. This has worked very consistently since we implemented this.

Do you have any exclusions configured for Horizon, AppVolumes, etc? If anything is attaching a login, ATP could be really curious why a 20GB virtual disk just popped up. We also configured a policy to set the average CPU load factor to 5% from its default. It doesn't prevent spikes, but averages out to be less than 5% CPU utilization. If your post-sync scripts are still causing errors, check them and make sure they aren't blocked by any "mark of the web" tags. We were having the same issue no matter how long we extended the post-sync timer and then noticed a .ps1 was blocked. Ultimately, what we ended up doing today that has worked was building a scheduled task that is created and executed when the instant clone builds. This scheduled task runs the non-persistent machine onboarding.ps1 from Microsoft which then runs the onboarding.cmd. So far, this has worked successfully on 3 IC desktop pools and around 800 machines. Each instant clone has received a unique SenseGUID variable and is reporting correctly in the security console.

We are also running into issues with the cp-template and cp-replica VMs onboarding during provisioning, Can you share details on the post synchronization script you created? We've  tried this same thing, but we get errors during provisioning that customization timed out. We are going to try a scheduled task that executes the onboarding.ps1 on a 20 min delay, but I don't like that machines aren't immediately onboarded.