Anyone having issues with Outlook or Teams after latest Windows 10 security updates ?

[kanid99]

We are running Horizon 2303 in ESXI 7.03. Guests are Windows 10 21H2 Ent. Horizon pools instant clones with floating assignments.

We just pushed Windows security update for February (KB5034763) and after this was published, the users in these pools where it was published were having intermittent issues connecting to Outlook or Teams (MS365). If the same user logged out and back in, they would be ok, but maybe not the next day.

I used my test user to connect to 30 sessions in the pilot pool and about 1 in 3 had the issue.

It seems to be WAM is broken because if I apply DisableAADWAM Outlook will work again (but no such workaround for Teams). The only consistent fix is to rollback the update.

The reason Im posting this here is that this issue is NOT affecting our physical workstations or, as far as I can tell any persistent VMs. Only affecting our instant clone VMs. Ive seen a couple posts on Reddit about this but in each case the experience was the same, affecting Horizon instant clones but not persistent machines or Physical devices and specific to this MS KB.

[tonyflan1]

ticket 2403190050001549 👍

[bjohn]

Thank You

My case numbers are in Authentication issues with latest version of 365 apps. : VMwareHorizon (reddit.com) if needed.

[bjohn]

@JeroenTil Would you be able to share your case#, since you got a confirmation from MS?

[JohnTwilley]

I was struggling with this issue for weeks, but I may have found an issue.

I download and ran one of the Microsoft Support and Recovery Assistant tools on my Master Image.  It was SetupProd_Act.exe and  it checks Open Authentication which is what is failing for all of us having this issue. If you run Teams/Outlook/word in Compatibility mode, you notice that you can authenticate. This is because Compatibility Mode forces the older authentication method, instead of the newer Microsoft OpenAuth.

Anyways, the tool detected that my UAC wasn't running...although I have it enabled.  It asked if it could auto-fix it, and of course I said yes.  We all know that Microsoft Modern apps don't run properly with UAC disabled. It could be an issue with Microsoft.AAD.BrokerPlugin, I'm just not sure.    I did go into UAC settings and re-adjust the slider, as well as install the March Windows updates. 

Afterwards, I recomposed the pool and all the 404 errors stopped.  So far, I can no longer get a VM with the issue, and tickets have stopped. I see about 9,000 user sessions per day, so I'm happy with the results.

Give it a shot and let me know if it works for you...please reply with your results to help us determine if the issue is UAC related.

[bjohn]

Interesting, although I'm not sure if this is the case for everyone.

For those of us on the reddit thread, it seems be a network card/driver issue.

Switching to E1000 from VMxnet3 resolves the issue.

[Jnissa]

Really?!

This is what Microsoft said. it looks like something with the authentication.

I tried that too and it didn't fix it for me, interesting that I didn't see that in the reddit thread I am there as well looking for that fix. 

Like you said maybe it's something else.

[JohnTwilley]

I'd also run across this Blog post that had a tweak to the NIC to disable Checksum Offloading.

The interesting part is that the CMD will instantly resolve the issue on an affected VM. (ran as Admin)

Disable-NetAdapterChecksumOffload -Name "*" -TcpIPv4

Microsoft Connection Test (NCSI) and office 365 - Pure PC's (purepcs.co.uk)

My problem was that it was just a temporary fix.  I'd recomposed my pools with TCP/UDP checksum disabled but still had issues.  So I turned it all back on and focused on Open Authentication issues...

Here is the VMware KB on the issue:  Microsoft Store Apps stop working in VDI after applying Microsoft Monthly Patch (KB5034763) (vmware....

[JohnTwilley]

I wanted to point out that were still having Authentication Issues after running the Support and Recovery Tool.

We have resorted to Disabling Modern Auth as suggested by VMware.  I hope Microsoft gets this resolved soon, as disabling Modern Auth makes me nervous...

    ref: Microsoft Store Apps stop working in VDI after applying Microsoft Monthly Patch (KB5034763) (97111) ...

[bjohn]

Start and stop a trace using DEM if you don't want to do that.

Refer to the reddit thread.

[kanid99]

Yes, I dont use DEM, I use ProfileUnity but the steps are similar Im sure. We also implemented a login script that starts and stops the trace and for us it was an effective workaround until this issue is fixed.

[JohnTwilley]

Do you have the information on that to share?  "starts and stops the trace"

[bjohn]

Refer to the reddit thread.

Authentication issues with latest version of 365 apps. : VMwareHorizon (reddit.com)

Basically this what I used as an elevated task in DEM.

c:\Windows\System32\netsh.exe 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

c:\Windows\System32\netsh.exe trace stop

[Jnissa]

As for right now there are 2 problems with the Horizon VDI and Microsoft latest changes.

1. New teams that broke the authentication with Microsoft

2. February patch that pushed the new Microsoft authentication.

We have tried everything we can together with the VMware team, it doesn't seem like there is a fix for it right now.

I hope maybe soon to have a fix for it! 

We are using the Dem profile solution btw.

[bjohn]

Maybe not a permanent fix. But there certainly is a workaround as mentioned above!

[JohnTwilley]

Are you running this as a Logon Task, leveraging an Elevated Task?

I'm trying to validate that it actually runs for regular users...where is the .etl file going?

[bjohn]

Yes, that's exactly what I'm doing. I don't have run async selected, not sure what diff it makes.

c:\temp can be any directory, I think the file path can even be left out and will probably get created in system32 or something. I just decided to have it write to the temp directory.

Also, the entire netsh cmd line might not be needed. Something like this may also work.

netsh trace start capture=yes report=disabled persistent=yes tracefile=c:\%computername%_netshtrace.etl

Basically starting a trace, triggers something with the NIC that fixes the issue for the session.

[JohnTwilley]

I must be missing something.

It's not generating the net.etl file, so I assume it's failing.  It must be with how I setup the Privilege Elevation. Do you mind sharing that part as well? I've tried it as both Argument based, and also as an Elevated task.  I'm running it from the DEM Scripts folder on the NAS, not locally.

 

[bjohn]

[JohnTwilley]

Thank you for the help, that works great. I'd never had the need for Elevated Tasks until today.

I believe the two logon tasks must run in alphabetical order, since it is starting and stopping correctly.

Two Logon Tasks:

Two privileged elevation:

[rtauler]

Hello, 

Any update on this issue?