I keep reading about this supposed VPN breakage, but haven’t read a single comment where a Windows users has had their VPN connections break, nor a listing of the VPN clients/protocols that are supposedly affected by this security update, which is curious now several days out from this “news” coming to the surface.
Exactly. Everybody on Lemmy a couple days ago was acting like the sky was falling when all we had were these one-paragraph FUD articles quoting Microsoft’s own KB article. Most people commenting have no clue that “VPN” is a broad term covering at least a dozen different possible protocols and acted like Microsoft was intentionally breaking all VPNs.
The only thing I found was a reddit thread talking about how some VPNs using TPM-backed certs were broken. I, for one, am using an IPsec VPN with certs stored in TPM on one of the affected versions of Windows 11 and have had no problems. Nor have I had any issues with SSL or Wireguard-based VPNs, so it does just seem to be a fringe case they’re warning about.
So Microsoft is just giving a heads-up that IT should probably include VPN testing in their patch cycle test rings and all the anti-MS people are losing their shit.
This confusion is Microsoft’s fault because they’re being incredibly vague about the whole thing. Of course people are going to freak out when the only thing they have to go on is “Windows devices might face VPN connection failures” which is less than useless information. They might as well have said “Between 0 and 100 percent of your remote users may suddenly be unable to work for reasons we can’t or won’t tell you”
Which protocols are affected? In what circumstances? Is this specific to certain software or hardware? WHAT DID YOU FIND? TALK TO US. etc etc
But Microsoft’s documentation has been in a death spiral for a decade now and it’s just going to keep getting worse. We bitch at our account manager regularly about all the problems we find with it.
The reality is they probably don’t know the full scope or root cause and are going off of limited reporting coming from their beta channels.
But they likely determined the impact was low enough that they could still ship the update while they investigate further.
There are similar known issues reported in the update KBs all the time that sound much worse to me as an admin but are as equally low impact in the end. But they’re not as easy for the layperson to latch onto like these low-effort “VPN no worky” articles.
Regardless, none of this absolves IT of the responsibility of testing patches.
I don’t disagree with anything you’ve said. But I know Microsoft can do better, because they used to before they gutted their documentation team. That’s only one symptom I’ve seen of their recent decline though.
Lately I’ve had support engineers answering support cases with stuff they clearly got from Copilot or ChatGPT because they do things like giving me PowerShell cmdlets to run with parameters that don’t even exist and never have. I even recently had one engineer argue with me and tell me I didn’t run the command correctly when I pointed out to him that he gave me incorrect syntax, parameters that don’t exist, so I had fixed it and ran what was really needed to get the data he was after. I got the case reassigned to an engineer who didn’t have his head up his ass. But it’s not a great sign.
Yep totally. The documentation is downright wrong so much more today than it used to be. It’s all written like they pawned it off on a junior engineer, who then threw shit at the wall until they got it working, then that process becomes the official documentation.
And don’t get me started on Copilot hallucinating Powershell cmdlets.
With support it’s become kind of a game to see how quick you can get to T2. My tactic is to passive aggressively point out how their first response shows a complete lack of understanding of the topic, then directly request escalation.
Luckily, the patch won’t install for me, because the default size of the recovery partition is too low.
Completely coincidental eh ?
