Event details
Hi Arden_White
What are the methods available for Server OS to renew secure boot certificates? we are using SCCM to manage the patching of server OS.
Is any Estimated timeline for Secure Boot Certificate renewal to be delivered through monthly cumulative updates for Windows Server OS, any additional steps required to complete the certificate renewal when using cumulative updates?
My ask is about the windows Server OS (2019, 2016, 2012R2, 2012).
MicrosoftHi!
I hope this server playbook helps answer your question:
https://aka.ms/SecureBootForServer
The modules necessary for the Secure boot updates are already delivered through monthly cumulative updates for Windows Server OS. Unlike PC clients, the Secure boot cert update needs to be manually triggered by IT Administrators, and the server playbook shares the best practices on how to plan and manage this transition safely.
Thanks RoySasabe its clear now that for server OS, we need to manually initiate the secure boot certificate Renewal process via reg key or by GPO. looking for some more details:
- Request for Linux VM Certificate Renewal Process
Could you please provide the detailed certificate renewal process for Linux virtual machines where Secure Boot is enabled and the underlying virtualization platform is Microsoft Hyper‑V, Azure? - Secure Boot Certificate Renewal for Citrix Non‑Persistent VDI/Image‑Based Servers
We have Citrix VDI and image‑based non‑persistent servers, and we require clarification on the correct Secure Boot certificate renewal procedure for these environments. Since updates are deployed through the master image, if we renew the certificate within the master image, will the non‑persistent servers inherit the updated certificate seamlessly when the image is applied? Additionally, are there any further steps required for each non‑persistent VM to ensure proper certificate update? - Secure Boot Requirements for Physical Hyper‑V Hosts
We have several physical Hyper‑V host servers where Secure Boot is disabled at the hypervisor level, while the guest virtual machines are configured with Secure Boot enabled. Please confirm whether a Secure Boot–compatible firmware update is still required on the physical Hyper‑V hosts under these conditions. - Downtime and Reboot Requirements for Secure Boot Certificate Renewal
articles say it may take 12 Hrs to 24,48 Hrs to complete the renew process , being a server os we also seek guidance on managing this within a controlled patch window. Specifically, if we perform one reboot during the current monthly patch cycle and defer the second reboot to the next month’s patch schedule, would this pose any performance degradation, stability issues, or operational risk for the affected servers? - Is there any potential impact on installed applications following the renewal of Secure Boot certificates? Is there any rollback plan in case of any issues?
Event ID 1795 Error on Multiple VMs – Clarification on Required Fix
We are observing Event ID 1795 across multiple virtual machines. Based on several articles and known-issue references, it appears that Microsoft has acknowledged this issue and is expected to release a fix as part of the March Patch Tuesday updates.
Could you please confirm whether the upcoming fix (KB) will need to be applied on:
- the individual virtual machines only,
- the Hyper‑V host servers only, or
- both the VM guests and the Hyper‑V hosts
in order to fully resolve the Event ID 1795 occurrences?
- Arden_White
Hi kumarshai88hotmailco,
- I can't speak much about Linux and how it updates the Secure Boot certificates. I would expect it to be the same way that Linux updates Secure Boot certificates on a physical machine. Note that, if you create new Linux VMs, the certificates should already be up to date.
- I know very little about the Citrix solution and I think this is a question for Citrix.
- The firmware for the guests is independent of the firmware of the physical device running Hyper-V host. If you're not running Secure Boot on the host then there is nothing to do. Note that updating the firmware on any machine for Secure Boot updates is not required. I can think of two reasons to update the firmware in this scenario: 1) there is a firmware defect that prevents the Secure Boot certificates from being applied, 2) the OEM has updated the Secure Boot defaults to include the new certificates. #2 is useful when you reset Secure Boot on the machine - since the new certificates are in the defaults, resetting Secure Boot in the firmware will ensure that the new certificates are applied to the active Secure Boot variables.
- Separating the updates across two scheduled patch cycle will not impact performance, stability, or operational risk. Another option is to trigger the updates on the servers a day in advance. The scheduled task should apply the certificates without the need for a reboot. Then apply patches and reboot. I believe this should work in most cases.
- There should be no impact on applications. This is adding trust for new certificates and replacing the boot manager with one signed by one of the new certificates.
Regarding the Hyper-V fix, I don't know the answer, but I'll find out.
Hi Arden_White
We observed Event ID 1808 on multiple servers, which indicates that the Secure Boot certificate has been successfully renewed and applied to the firmware.My question is: if Event ID 1808 confirms successful renewal, why are we still receiving the same event ID on a daily basis? Ideally, once the renewal is completed, this process should not continue to repeat.
Please advise if there are any additional steps required to prevent this process from running again for servers where the Secure Boot certificate has already been renewed successfully.
- Request for Linux VM Certificate Renewal Process
