Forum Discussion
Windows Server 2022 - devices not booting when Secure Boot enabled (KB5022842)
And if you install Windows Server 2022 on unsupported hardware, it's likely the OEM won't help you about it - that's why you should avoid unsupported configurations at all costs : if something goes wrong, you're on your own.
Not sure why you're blaming Microsoft about this - it's not like Microsoft forced you to install Windows Server 2022 on those servers...
The point is that Microsoft broke it with the last Patch Tuesday update - it worked fine up until that point. It's quite normal to run server OSs on older hardware on which it's technically not supported, and it rarely gives any issues at all. And indeed the same applied with client versions up until W11.
And just to note - the servers I have tested it on only don't support it in the sense that Dell don't support running Server 2022 on them - they do meet the Microsoft requirements for Server 2022 as set out here: https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements.
- It broke because there is something wrong with those specific drivers/firmware, not because of Microsoft (otherwise, Microsoft would have provided a fix).
And no it's not normal to run OS on unsupported hardware in a production environment. It doesn't matter if there are not many issues - one is enough. And if you cannot rely on OEM support to fix it, you're toasted.
It's called risk management. Gambling is not a way to manage a production environment.
Maybe Dell will be kind enough to update those drivers/firmware for free. If not, you can replace Windows Server 2022 by an older, supported OS on this hardware, or you can upgrade your hardware, one supported by Dell for WS 2022.Alban1998 It is absolutely normal to run more recent OSes on older hardware in a combination that is technically not supported by the hardware vendor. The only parties arguing against this are those who financially benefit from customers constantly having to upgrade their hardware. Many companies cannot afford to spend tens of thousands of dollars on brand new hardware because a consultant or vendor tells them that its too risky not to. Most companies can't afford to drink that Kool-Aid. There are effective ways to mitigate the risk associated with unsupported hardware/software combinations (failover clusters come to mind), but these mitigations don't enrich Microsoft and its hardware partners the same way trying to force people to constantly upgrade their hardware does.
"otherwise, Microsoft would have provided a fix". This implies Microsoft actually tests their updates or cares about their customers. They care about making money and will fix issues that cost them money. This is a pretty recent issue, so it is yet to be determined if Microsoft will fix it or not. I'm still hopeful they will, but I don't think it will be out of the kindness of their heart.
We experienced this issue on a Dell PowerEdge R730XD and a R430. In the case of the R730XD, this was a clean install of Windows Server 2022. After several clean installs, we were able to narrow down the issue to this particular update. We went so far as to back up the Secure Boot database, perform the update that breaks secure boot, and restore the database to what it was before that and Secure Boot still didn't work. The only thing that changed was Microsoft's update. They can blame whoever they want for this issue, but it happened as a result of their update.
Thankfully, virtualization based security (including HVCI and Credential Guard) work just fine without Secure Boot. This is despite Microsoft's claim that these feature require Secure Boot to function.- We are getting off topic here, this could be a topic on its own.
You missed the "production environment" thing in my reply, this is a critical item when evaluating risk.
Well if your customers are fine with losing money because of unsupported stuff, I guess that's OK. Defeats the purpose of minimizing costs in the first place tough. Which itself contradicts buying brand new WS2022 licenses and CAL, when you can continue using WS2019, and using physical hardware for servers when you can use VM instead, and so on.
Or if you are really unable to cope with regular on-premise hardware upgrade, go Azure/AWS/Google.
And the next post kinda prove my point :
"they have reproduced the issue, and confirmed that servers later than 13G are not affected. Because Server 2022 isn't officially supported on 13G servers, they are not currently committing to doing anything about it". In some companies, telling this to your boss/customer triggers a Resume-Generating Event (RGE).
As for disabling Secure Boot to bypass your issue, and claiming VBS/CG are fine without it...yeah, good luck with that.
- The servers concerned are used in secondary roles - in one case for testing - so they need to be on the same version as the production systems.
As to whether there's something wrong with the specific drivers / firmware - so far as I'm aware none of the parties involved have released any details of what the cause is. Do you have inside information or are you just speculating? Because without details it's not possible to say what the cause was, and the fact that VMWare have issued a patch only tells us that they (quite sensibly) wanted to get it resolved as quickly as possible - which may be fixing an issue in their product, or may simply be a workaround to whatever Microsoft has done - without further information it's impossible to tell. The fact that VMware, Dell, Lenovo and HPE all seem to be affected is notable, though.- I do not have any insider information. You'll see what Dell support team can tell you about this issue.
