Event details
82 Comments
what about AVDs? can they be added to the configure policy for secure enable? we this a few weeks ago and a few devices got blue screens related to the policy. What about surface hubs? should both be handled separately and not through the policy? Please advise, thank you
- Arden_White
Microsoft
Azure Virtual Desktops will act like any other device. I believe that AVDs were added as High Confidence to the High Confidence Database in the cumulative updates for June and should automatically apply the certificates and the boot manager.
There was a known issue in Azure that I believe was resolved in May.
I have about 6500 devices in our environment with various Win 10 and Win 11and I'm worried that I won't have enough time to get all these updated. They have recently been updated to the May update. Please let me know if the June Windows Update will take care of the boot cert issue
Hi JTisdale if you may, could you share in more detail: are these domain-joined, standalone, Intune Entra only etc.
If you runget-securebootsvn get-securebootuefi -decoded dbdefault get-secureboot -decoded dbwhat is their output?
Have you tried Microsoft recently published PowerShell scripts?
In addition you might want to hire my MVP colleague Kaido Järvemets. He's a top-notch competent person, solving your situation at scale and swift.
For Configuration Manager, An LCU must be applied to the Dec. 2024 ADK winpe.wim and files copied out to ADK install directories to get 2023 signed .efi files in place, correct? What is the intended/expected outcome of this? I am only finding bootmgfw_EX.efi getting 2023 signed while all others remain 2011. Even if "Legacy", MS is still supporting?
- Arden_White
There's some documentation on Updating Bootable Media to the 2023 signed boot manager.
This is not my area, but I think there are multiple things that happen:- Updates the loose files that the device initially boots from with the boot manager files.
- Updates the boot.wim and install.wim with the boot manager files
There are a number of files that need to be placed in the correct location. I think this includes font files. The PowerShell script available on that page should do the right things.
"The Secure Boot update failed to update a Secure Boot variable with error The parameter is incorrect." Event ID 1796
I have not been able to find a solution for this as it is so vague, are there any troubleshooting steps to take to identify the actual problem?
dupe, answered there
Follow-up to the temporarily paused question. How can we know if upgrading to 'OEM recommended' bios version will actually fix the issue and/or make it safe to update the certs via the reg key or Intune policy?
Should we just upgrade the bios on some devices and see if it's ok to update the certs and skip the confidence level and do more and more if our initial tests have been successfull post bios upgradeI can say that for all uncontrolled / unmanaged devices, there is zero relation between low confidence level and rollout. Even on low confidency deploying Windows 11 25H2 05-2026 fixed CA2023 for more than 98%.
Why are we not getting guidance/support on Configuration Manager ADK/PE/PXE? (Particularly with WDS.)
MDT has been deprecated.
WDS has been deprecated in-parts for Windows 11, too.
https://learn.microsoft.com/en-us/windows/deployment/wds-boot-support
If your deployment relies on anything that is based on affected parts, or relies on anything using cscript / wscript / vbscript, be cautious as they are on a very short deprecation path, too.Thanks.
"The operating system deployment functionality of Windows Deployment Services (WDS) is being partially deprecated."
"This change doesn't affect WDS PXE boot. WDS can still be used to PXE boot devices with custom boot images, but boot.wim can't be used as the boot image and run Windows Setup in WDS mode.Windows Setup can still run from a network share. This change doesn't change Workflows that use a custom boot.wim, such as Microsoft Deployment Toolkit (MDT) or Microsoft Configuration Manager."
For WDS I'm planning on taking 25H2 install media, mounting boot.wim, applying the LCU, running the following:copy "C:\Mount\Windows\Boot\EFI_EX\bootmgfw_EX.efi" "C:\bootmgfw.efi"
copy "C:\Mount\Windows\Boot\PXE_EX\wdsmgfw_EX.efi" "C:\wdsmgfw.efi"
Then copying them to the \RemoteInstall\SMSBoot\x64 directory on each DP and restarting WDS service. Fingers crossed.
I work for a small company and all our rollouts for the update have gone well for user workstations, however I am having difficulty updating windows server 2016 VM's. They are returning an error:
"The Secure Boot update failed to update a Secure Boot variable with error The parameter is incorrect." Event ID 1796
I have not been able to find a solution for this as it is so vague, are there any troubleshooting steps to take to identify the actual problem?I'd like to suggest open a support ticket.
https://support.microsoft.com/support-for-business
However WS 2016 and WS 2019 are no longer in full support (mainstream support).
One may expect Secure Boot compatibility and updates even in extended support phase.
Severity B+ (24/7) is fairly justified given the security impact and soon expiration / time to solution or remediation cannot take too long. Usual Sev B and C the traction is super slow.dupe, answered there.
Is it safe to assume that the buckets listed in the csvs in the github repository (https://github.com/microsoft/secureboot_objects/tree/main/HighConfidenceBuckets) will be part of the June update?
Not a question - but I wanted to say thank you for hosting these sessions. It has given myself a confidence level of high (pun intended) to roll this out in my environment.
Thanks again!
Less a question more a comment, for future rollouts of this type, it would be really nice if the "high-confidence" value wasn't waiting until the month of the certificate expiration before being applied. While you have consistently stated "don't worry, we're handling it" it is worrisome to be less than 30 days out from the expiration and not having most of our devices (running new firmware versions, with the certs in place from those updates) running with the new certificate yet.
Additionally, the reporting from Intune only recently started working as well as the rollout of the settings catalog/config profile was plagued with 6500 errors.
