John Twilley Posted June 4 Share Posted June 4 (edited) I'd like to start a discussion on this long overdue fix from earlier in the year. It seems to have gone dormant, but yet the issue still persists. This is the issue where many Microsoft applications can no longer authenticate (404 Error) because of some odd bug introduced in the February Microsoft Windows update KB5034763. If any of you that opened a Support ticket would care to provide any feedback, that would be great. I still have the NetSH workaround (not listed in the KB) from the old community forum. If people still need that workaround, we can recreate the detailed content in this new forum. It's basically an elevated NETSH command that triggers something in the network card on the VM that resolves the issue. Ref: https://kb.omnissa.com/s/article/97111 Additional Reading on the issue: https://www.reddit.com/r/VMwareHorizon/comments/1avofn9/authentication_issues_with_latest_version_of_365/?sort=new https://www.reddit.com/r/sysadmin/comments/190tvru/office_http_404_in_avd/ Edited June 4 by John Twilley 1 Quote Link to comment Share on other sites More sharing options...
John Twilley Posted June 4 Author Share Posted June 4 (edited) Here is an example of the Netsh workaround. It's not fair of me to mention a fix to such a big issue without going the extra-mile, right?! For some reason, this fixes the issue with the Microsoft Store App - "Microsoft.AAD.BrokerPlugin" that is failing to function. Create two "Privilege Elevation" tasks. TraceStart --> Arguments is one line: (change C:\temp to anyplace...could just be %temp%) trace start scenario=InternetClient_dbg provider=Microsoft-Windows-TCPIP level=5 capture=yes packettruncatebytes=120 tracefile=C:\temp\net.etl report=disabled perf=yes correlation=disabled TraceStop --> Create two Logon Tasks --> Just choose the elevated task from the Dropdown. That's it. You should see a small .ETL file in the temp are that you defined earlier after logging into a VM. Others have cleaned up the Netsh command to make it more efficient, so feel free to change it as needed. I just cannot find the old community post that has the updated information. NOTE: there is some discussion about deleting one registry key that COULD resolve this issue. I have not fully tested it, but I'll mention it so that you can investigate. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedInterfaces\IfIso\ Edited June 4 by John Twilley Quote Link to comment Share on other sites More sharing options...
Solution amr Posted June 4 Solution Share Posted June 4 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. Quote Link to comment Share on other sites More sharing options...
Hans Straat Posted June 5 Share Posted June 5 (edited) Hi Ram012, We have implemented this workarroundalready in a few images and use CB as antivirus. Mind we deleted the registryhyve and no longer have the http 404 issue. Mind this is a workarround not a fix! Microsoft and Omnissa should come up with a proper solution so this key can be restored without giving us a 404 error while authenticating to Microsoft. Edited June 5 by Hans Straat Quote Certified prutser Link to comment Share on other sites More sharing options...
amr Posted June 5 Share Posted June 5 1 hour ago, Hans Straat said: Hi Ram012, We have implemented this workarroundalready in a few images and use CB as antivirus. Mind we deleted the registryhyve and no longer have the http 404 issue. Mind this is a workarround not a fix! Microsoft and Omnissa should come up with a proper solution so this key can be restored without giving us a 404 error while authenticating to Microsoft. 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? Quote Link to comment Share on other sites More sharing options...
Hans Straat Posted June 5 Share Posted June 5 I don't know if you are more vulnerable, we got the tip from another hospital to delete this key and have checkpoint firewall in front of our vdi environement aswell carbon black as antivirus. No clue what it does with microsoft defender. Quote Certified prutser Link to comment Share on other sites More sharing options...
John Twilley Posted June 5 Author Share Posted June 5 Following up on this HTTP 404 from the AAD Broker Plugin. I have cleaned up my master images that had the registry keys as seen above located in the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedInterfaces\IfIso After recomposing the pools and disabling the NetSh workaround, I'm happy to report that I'm no longer getting the 404 Errors and authentication is working as expected. I've had a few thousand logins this morning, and no report of any issues! I'm now very curious why this seems to only be talked about in Horizon forums. You'd think that this key could manifest itself on physical workstations as well...but I've not heard people complain about this anywhere else. And to be fair, this is definitely a Microsoft issue. Now I know why the VMware and Omnissa KB articles "went stale" and we had to rely on forums like these to work out the issue. Thanks for helping out your fellow Horizon engineers! 1 1 Quote Link to comment Share on other sites More sharing options...
amr Posted June 5 Share Posted June 5 (edited) @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. Edited June 5 by ram012 Quote Link to comment Share on other sites More sharing options...
bjohn Posted June 6 Share Posted June 6 (edited) I have also deleted the lflso key a while ago and got rid of the DEM elevated task. We use Defender also, and haven't found any issues (no idea what to look for either). I first saw it mentioned in the below post. Edited June 6 by bjohn Quote Link to comment Share on other sites More sharing options...
amr Posted June 11 Share Posted June 11 On 6/6/2024 at 4:00 PM, bjohn said: I have also deleted the lflso key a while ago and got rid of the DEM elevated task. We use Defender also, and haven't found any issues (no idea what to look for either). I first saw it mentioned in the below post. This is really great that you haven't noticed issues with WD Quote Link to comment Share on other sites More sharing options...
Ryan Posted June 11 Share Posted June 11 (edited) I have had the netsh fix in for a couple months and it has been working with the 404 and proxy errors. I tried out the registry key deletion for the issue that I just recently started to see and it doesn't appear to make a difference. Just recently I have been getting the error seen in the the attached screenshot. Only with regard to activation. Once activated and captured in the FSLogix ODFC container the user is good to go. But onboarding new users or reset users I am seeing this issue now. Re-running the netsh trace does not fix it. But if I reset the adapter completely it fixes it immediately so something is going on still. In powershell Get-NetAdapter | Restart-NetAdapter. I am trying to see if there is some option for the netsh trace that will make it fix this issue somehow. Edited June 11 by Ryan Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.