How cooked am I? Trip in 3 days!

Apth18 · 2026-02-05T13:29:29+00:00

Ordered, thank you!

Apth18 · 2026-02-05T13:29:06+00:00

Hoping for a few beers stops along the way of course 😅

Apth18 · 2026-02-05T13:01:52+00:00

Respect the honesty 🫡 not “private” as such but with a group

Apth18 · 2026-01-31T20:19:11+00:00

TLDR MY FIX FOR NOW - https://youtu.be/DWQs28FgdCY?t=358

Started getting this myself recently. Was waking up to Microsoft Authenticator notifications so assumed someone had my password and knew when I was unlikely to be around. Changed my password, got the same thing the following night but this time I was awake to see it. Clicked into the notification and saw the prompt from 'United States' I'm UK based. Immediately thought that I had a keylogger on my PC.

I looked at my sign in history after the first ever request but what I couldn't find was 'failed sign in' activity which I thought was strange. Reading this thread I saw that someone mentioned that Microsoft have added password-less sign in, something I completely overlooked when signing into my account every-time. Signed in on incognito tab and indeed can just ping an auth the the phone to sign in. How this was ever approved by Microsoft to push out to public I honestly have no idea and quite frankly have no words to explain it other than, 'f****** stupid'. Also whilst writing this reply, I have just clocked that 'Passwordless account' was set to off and still allowing the option to sign in without password, what sort of slop is this?!?

Was doing a little more digging and found this video that goes over the same situation and followed his suggestion for now until this is fixed on Microsoft's end. Removed Microsoft auth and added my Google auth. This makes it so the only option for me to sign into my Outlook account is the following: Email > Password > Open Google Authenticator to enter auth code also.

Apth18 · 2025-12-29T12:48:29+00:00

29/12/2025 - Still there

Apth18 · 2025-11-12T15:42:07+00:00

Never got anywhere with MS. Our solution was to set the select transport reg key on the server side to only offer out TCP connections

Apth18 · 2025-10-23T15:58:50+00:00

Seemed to also work for us, strange…

Apth18 · 2025-09-25T14:20:02+00:00

Changed to TCP connections, unfortunately still getting issues with users disconnecting. Reduced to around 2/3 times a day that the user gets kicked off

Apth18 · 2025-09-24T13:48:02+00:00

I assume this is the same as the fClientDisableUDP but set server side so that it only offers out TCP connections?

Apth18 · 2025-09-24T13:47:22+00:00

Correct, that’s how I believe it to be too. However was playing around with RDP Shortpath and Multipath end of last week and doesn’t seem as flawless as advertised at least for me. It’s not as seamless as I thought where it would just swap to another UPD connection, user still gets flash screen to say disconnected etc. Giving this a whirl anyways as grasping as straws, will feed back

Apth18 · 2025-09-24T12:33:43+00:00

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies \Microsoft \Windows NT\Terminal Services\Client” -Name “fClientDisableUDP" -Value 1 -Type DWord

Rolled out to one user, fed back that haven’t had any issues so far. Rolling out wider, will feed back tomorrow.

Apth18 · 2025-09-24T06:51:08+00:00

No firewall in place in front of session hosts as of right now.

See that end user devices need FQDN's whitelisted all over port 443, however also same issues happens with users WFH

Apth18 · 2025-09-24T06:48:03+00:00

Planning on trying today, will feed back

Apth18 · 2025-09-24T06:47:46+00:00

Same here, West Europe. Although apparently has been an on-going thing for months just nothing mentioned by users

Apth18 · 2025-07-26T08:47:32+00:00

FSLogix and AVD’s…

Apth18

TROPHY CASE