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, 20241 yr by John Twilley

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, 20241 yr by John Twilley

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.

 

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, 20241 yr by Hans Straat

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?

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. 

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!

 

@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, 20241 yr by ram012

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, 20241 yr by bjohn

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

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, 20241 yr by Ryan

Thanks to those posting in this thread for kickstarting back up this conversation. Did anyone ever get anywhere opening relevant Microsoft cases?

I mean yes the workaround is working, but it's just lazy of Microsoft and Omnissa to not actually address and fix the issue instead of relying on the community to develop their own patchwork workarounds. Imagine a brand new customer trying to come in and install Horizon with O365 and running into this with absolutely no documentation on it. Even if it is a Microsoft issue I would really expect Omnissa to push harder for a fix. I know they are competitors, but this issue freaking happens in AVD too! You would think Microsoft would be motivated to fix it.

Looks like the KB was updated with more details https://kb.omnissa.com/s/article/97111

Is anyone else seeing this resolved with the October Windows patches? We aren't able to recreate the issue anymore.

Microsoft has been pinging us monthly asking us to test after every patch Tuesday. This is the first time they've mentioned the issue should be resolved.

Edited October 23, 2024Oct 23 by Coleman Kelly

On 10/23/2024 at 9:30 AM, Coleman Kelly said:

Is anyone else seeing this resolved with the October Windows patches? We aren't able to recreate the issue anymore.

Microsoft has been pinging us monthly asking us to test after every patch Tuesday. This is the first time they've mentioned the issue should be resolved.

I was getting the 404 error with OneDrive when this broke. I disabled the workaround steps in DEM and I am not getting that error now. I think this might be fixed now.

Thanks, it seems like Microsoft finally patched it.

We have been working with Microsoft since the release of the February update that caused this problem to occur. This has been a very tiring process but we have had the same routes when it comes to removing the "IfIso" key hive and later the "CellularDataAccess" policy.

In our case, Microsoft has responded that this policy is not supported on workstations that have no relation to "cellular data usage". We should therefore not use the entire policy. We have indicated that the problem is still caused by poor detection of a "Cellular Data connection". When asked if there are any updates to be expected, we received the following response:
"Upon checking with the previous Engineer and the update by our Backend Engineering Team as of now there is no potential update on this one and the Workaround was set to be considered as a resolution at this point."

We then ran 2 months of acceptance with the "CellularDataAccess" not being set at all and there seemed to be no problems. Last Friday we went to production with this and it turns out that 1 in 20 desktops has the HTTP404 problem again. The policy has now been set to 1 via GPO and the problem has gone away again. So Microsoft's statement not to use this policy is incorrect.

The fact that Microsoft indicates that it will not make any further developments in this worries us and it looks like we will have to continue using this policy for the time being.