{"id":28768,"date":"2023-02-16T07:48:05","date_gmt":"2023-02-16T06:48:05","guid":{"rendered":"http:\/\/159.69.82.204\/win\/?p=28768"},"modified":"2024-10-05T19:05:33","modified_gmt":"2024-10-05T17:05:33","slug":"windows-server-2022-february-2023-patchday-and-the-esxi-vm-secure-boot-issue","status":"publish","type":"post","link":"https:\/\/borncity.com\/win\/2023\/02\/16\/windows-server-2022-february-2023-patchday-and-the-esxi-vm-secure-boot-issue\/","title":{"rendered":"Windows Server 2022: February 2023 Patchday and the ESXi VM Secure Boot Issue"},"content":{"rendered":"

\"Sicherheit[German<\/a>]The security update KB5022842 for Windows Server, released on February 14, 2023,\u00a0 triggers collateral damage. Virtual machines can subsequently no longer start after a reboot and either can no longer find their system drives or trigger a Secure Boot error. Disabling Secure Boot helps – Microsoft and VMware have since confirmed this error.<\/p>\n

<\/p>\n

Boot issues with VMs<\/h2>\n

\"\"I had presented the security update KB5022842<\/a> released for Windows Server 2022 in the blog post Patchday: Windows 11\/Server 2022 Updates (February 14, 2023)<\/a>. Shortly after the German edition of this post was published, users already came forward reporting issues<\/a> (I've translated the comments).<\/p>\n

User #1: My template Win 2022 VM does not boot up after the update once you turn it off.<\/p>\n

User #2: Windows Server 2022 with Secure Boot \/ VBS enabled in the VMware are having problems after the Feb. update and will not boot.<\/p>\n

First comes: Windows Boot Manager… Security Violation
\nThen Windows Boot Manager… unsuccessful<\/p>\n

Can anyone confirm this?<\/p>\n

User #3: Same problem, ESXi 7.0.3
\nAfter update the server is running, after further boot
\ncomes \"Security Violation
\nDisabling the Secure Boot solves the problem<\/p>\n

User #4: Same problem with our Win 2022 server VMs. By disabling VBS and Secure Boot the VM boots up again. (ESXi 7.0.3 environment)<\/p><\/blockquote>\n

German blog reader Dennis C. also contacted me by e-mail and reported the error at the VMs:<\/p>\n

Dear Mr. Born!<\/p>\n

First of all, thank you for your website, it has helped me a few times.<\/p>\n

I don't know if we are a unique case, but since today we have a problem that I would like to share with you. Maybe you can verify it and publish it:<\/p>\n

I have the following problem with a customer (Server 2022): If there is a VM in version 19, the server member is a domain and receives the February update (KB5022842), the server does not survive the next reboot.<\/p>\n

Using the console, you can still see the following before going into the boot options:<\/p><\/blockquote>\n

\"VMware<\/p>\n

If I now disable the security boot in the VM options, the server starts again as usual:<\/p><\/blockquote>\n

\"ESXi-Settings\"<\/p>\n

Interestingly, the 3 requirements had to coincide in my case. A server in VM version 16 was not affected, there was no secure boot option.<\/p><\/blockquote>\n

I then pointed Dennis to the discussion on the blog. Within my English blog post Patchday: Windows 11\/Server 2022 Updates (February 14, 2023)<\/a> I've added the following warning:<\/p>\n

Addendum:<\/strong>\u00a0I got\u00a0several reports<\/a> from German blog readers, saying, that their virtual machines can't boot either due to a \"security violation\" or due to a missing boot manager. Deactivating \"Secure boot\" should solve the issue.<\/p><\/blockquote>\n

The topic is also discussed on patchlist.org:<\/p>\n

So far this is isolated to a single VM on VMware ESXI, but we have a server 2022, new install from about 2 weeks ago, installed updated Ok, rebooted OK.<\/p>\n

Just rebooted again and it's got a \"security violation.\"<\/p>\n

Turning off VBS and secure boot seems to have fixed it for now.<\/p><\/blockquote>\n

There came the hint that on reddit.com in the patchday superthread<\/a> as well as here<\/a> the error was also reported. Martin noted on Facebook in an admin group to my post still:<\/p>\n

It is certainly also important that the first restart works. So the server runs after the updates first. Only after the next regular restart, the problem then occurs. Only times as info for all those who perhaps feel safe that it is not with you.<\/p><\/blockquote>\n

These are probably all cases where VMware ESCi is used for virtualization. Uninstalling KB5022842 does not fix the problem according to Simon<\/a> because the EFI files seem to remain in the new version.<\/p>\n

In this comment<\/a>, one refers to problems with Windows Server 2019 and Hyper-V, which is confirmed by a second user, but doesn't really correspond with above descriptions. And this comment<\/a> reports Citrix PVS vdisks\/machines not starting after the update.<\/p>\n

VMware & Microsoft confirms the bug<\/h2>\n

Andi has already posted this comment<\/a> on the German blog (thanks for that) and reported that a colleague has opened a support case with Microsoft:<\/p>\n

A colleague has opened a call at MS.
\nMS is aware of the error, it is caused by ESXI.
\nESXI 8.0 does not have the problem.
\nEither a patch will come from MS or from VMWare.<\/p><\/blockquote>\n

In the meantime VMware has published the support post Virtual Machine with Windows Server 2022 KB5022842 (OS Build 20348.1547) configured with secure boot enabled not booting up (90947)<\/a> about this – thanks to Michael<\/a> and other blog readers on Facebook for pointing this out. This reddit.com post<\/a> summarizes the error again and provides the reference to VMware's support post. The VMware support post describes the bug and states:<\/p>\n

Currently there is no resolution for virtual machines running on vSphere ESXi 6.7 U2\/U3 and vSphere ESXi 7.0.x. However the issue doesn't exist with virtual machines running on vSphere ESXi 8.0.x. vSphere ESXi 6.7 is End of general Support.<\/p>\n

Uninstalling the KB5022842<\/a> patch will not resolve the issue. If the Virtual machine has already been updated, then the only available options are:<\/p>\n

    \n
  1. Upgrade the ESXi Host where the virtual machine in question is running to vSphere ESXi 8.0<\/li>\n
  2. Disable \"Secure Boot\" on the VMs.<\/li>\n<\/ol>\n<\/blockquote>\n

    The support article then mentions upgrading to vSphere ESXi 8.0 and disabling Secure Boot in the VMs. VMware warns against the installation of the update KB5022842 on a virtual machine with Windows 2022 Server until the problem is solved. Meanwhile, Microsoft has posted the article Windows Server 2022 might not start up<\/a> in the Windows Server 2022 Health Status section under Known Issues.<\/p>\n

    After installing KB5022842<\/a> on guest virtual machines (VMs) running Windows Server 2022 on some versions of VMware ESXi, Windows Server 2022 might not start up. Only Windows Server 2022 VMs with Secure Boot enabled are affected by this issue. Affected versions of VMware ESXi are versions vSphere ESXi 7.0.x and below.<\/p><\/blockquote>\n

    Please refer to the VMware support article above. Microsoft and VMware are investigating this issue and will provide more information as it becomes available.<\/p>\n

    Addendum:<\/strong> The bug has been fixed for some ESXi versions, see Windows Server 2022: VMware ESXi 7.0 U3k Patch for Secure Boot Issue (Update KB5022842, Feb. 2023)<\/a>.<\/p>\n

    Similar articles:<\/strong>
    \n    Microsoft Security Update Summary (February 14, 2023)<\/a>
    \n    Patchday: Windows 10 Updates (February 14, 2023)<\/a>
    \n    Patchday: Windows 11\/Server 2022 Updates (February 14, 2023)<\/a>
    \n    Windows 7\/Server 2008 R2; Server 2012 R2: Updates (February 14, 2023)<\/a>
    \n    Patchday: Microsoft Office Updates (February 14, 2023)<\/a>
    \n    Exchange Server Security Updates (February 14, 2023<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":"

    [German]The security update KB5022842 for Windows Server, released on February 14, 2023,\u00a0 triggers collateral damage. Virtual machines can subsequently no longer start after a reboot and either can no longer find their system drives or trigger a Secure Boot error. … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1319],"tags":[],"class_list":["post-28768","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/28768","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/comments?post=28768"}],"version-history":[{"count":1,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/28768\/revisions"}],"predecessor-version":[{"id":35737,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/28768\/revisions\/35737"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/media?parent=28768"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/categories?post=28768"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/tags?post=28768"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}