amr

Hey @Niels Geursen! So it turns out it was UAG setting for session time out. I saw this setting numerous times and it was misleading because it isn't under the Horizon settings but rather the UAG system settings. It is also in milliseconds and the default is 10 hours. We didn't have the setting turned on in the view console to for disconnected.

We did but the users were not very willing to troubleshoot, not uncommon in my field, and it was only a handful of Mac users. An acceptable solution for them was to downgrade the client.

Good afternoon, We are currently running 2306 in our environment but have some users that use their personal Macs to connect to View. Have had 2 users who updated their Macs View Clients to 2406 and have had issues with dual screens on their Macs. The issues they have are the mouse randomly jumping between applications, lagging between monitors, clicking things, etc. Once i noticed the reported issues started around the same time as 2402 release date, i had them download the 2306 version and the problem went away. I do not know if this is because their client doesn't match our internal agent (2306) but wanted to give everyone a heads up.

Do you have a length of time this occurs at? Ours seem to be at the 10hr mark, only external users.

Incredibly helpful post, thank you! I was in the process of turning those scheduled tasks off as we speak. thanks so much.

thanks! What did you go from CPU wise? We are currently on 2x CPU.

We have had this "issue" for a few years now, including New Teams. We have just instructed our users to wait for Teams to fully open before opening Outlook...this went over well with 95% of the users ha. We also have New Teams launch on log on to accelerate that process and have started instructing them to schedule all meetings from Teams and not Outlook. Have you followed the MS article on best practices? https://learn.microsoft.com/en-us/microsoftteams/new-teams-vdi-requirements-deploy Something that has helped us was installing the Teams meeting add on locally on the golden image. I believe this is because of how Teams of provisions on log on to user appdata every time.

Good morning all, We have recently kicked off a project to get Defender for Endpoint going and replacing NSX/TrendMicro DeepSecurity. I have read the numerous articles from TechZone and Microsoft a few times each to get an understanding on the best path forward. Key points I've taken away: - Don't onboard the golden image - We want a single entry for each VM, so use the appropriate on boarding scripts for VDI - Use GPO locally, in AD, or post sync script to onboard instant clones - Follow the TechZone article and be diligent about exclusions and things unique to VDI With all that said, how are you managing on boarding ICs with Defender? To me the scripts linked to the IC OUs is probably the method we'll go. We have had issues in the past with post sync scripts timing out and VMs failing to create. Are there any caveats or gotchas to watch out for with this entire system?

I had no luck going through Broadcom or Omnissa, they both pointed me at each other 🤣. However, after some time my keys finally showed back up in our Universal Console under View Perpetual Keys. The link was broken for weeks. My licenses are also not in either vendors portal still.

This is really great that you haven't noticed issues with WD

@John Twilley Awesome to hear! We have had this deployed out to physical machines with no issues for a month or more now. Next month we will be removing the regkey in production on View and see if implementing Defender puts it back or breaks Defender with it not there.

Great to hear and i agree 100%. My biggest question(s) is what does this key do if deleted? Will Defender put it back? Does this leave us vulnerable?

Thanks Sascha. Agreed, curious to see others experience.

Thanks for this post. I just made one this morning before I even saw this one, too funny. We found 100% success in deleting that registry key but are unaware of the impact of doing this, especially with Windows Defender going into production in the next few months. I have not tried the trace start/stop fix you outlined above but have seen other people have success with that on reddit, in particular on those links you posted.

Good morning, I have been following this topic for quite some time and there used to be KB on it, however since the move to Broadcom the page returns a 404 https://kb.vmware.com/s/article/97111. Their workarounds were not viable for us since we cannot disable modern auth, etc. We are able to create this error with the February, March, and April patch on Windows 10 22H2, we have not tried the May patch. The issue appears from the AAD Broker plug in being blocked with the recent updates via Windows Defender. Even though we do not use Defender, this is not unique to us as it is happening to folks who use it or not. If this is blocked, our machines cannot communicate with Azure for auth, licensing, etc, hence the errors. The resolution was to delete the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedInterfaces\IfIso\ and all of its contents on the parent image. You can see that when a machine is broken all of the plug ins are set to ACTION=BLOCKED|ACTIVE=TRUE (attached) and you can see on a working machine, they are not blocked with some of them being ACTION=BLOCKED|ACTIVE=FALSE: (attached) Having said that, I do not know of any repercussions of removing that key as well as all of its entries or not. This is especially something to consider since we will be doing to Defender soon on VDI. Has anyone had any luck fixing this without deleting the keys or has MS/VMware fixed this yet? Does deleting this key impact Windows defender?