We are rolling this out with the Intune policies, and overall it appears to be working well. The new report in Autopatch looks great - thanks.

However, we have encountered a consistent issue with Dell OptiPlex 3040 and 7040 systems.

On these models, running the latest firmware and Windows 11 LTSC (unsupported, we understand), the machines lock up completely a few minutes after boot when network access is available. There is no blue screen or crash dump—the system simply freezes as if time has stopped. This behavior does not appear to occur when the network is disconnected.

These devices have been running since purchase in 2016 and have been using the same Windows 11 LTSC image since it was released, without prior issues.

We have confirmed that disabling Secure Boot in the BIOS immediately resolves the problem. Every OptiPlex 3040 and 7040 that has received this policy is affected.

These models must be on the known good list, but this specific configuration clearly does not work as expected.

Hi there I've noticed a problem with AMD consumer platforms. Confirmed with two different AMD chipsets, SVM (CPU Hyper-V required feature) is disabled by default. But this is required along with Secure Boot to make use of VBS and other subsequent security features, that are to be set in Microsoft Security App (Defender).

After today's AMA, I think I understand that as long as IT managed systems are configured with this reg key / value - 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates' to '0x5944', that should trigger the system to apply the updated Secure Boot certs as long as the firmware supports the update and the machine has the certs via CU. Can you please verify that my understanding is correct? If it's not correct, what additional requirements am I missing? Additionally, with the above configuration, what does timing look like? Should the certs be applied relatively quickly or is there still a wait period before you should expect the updated certs?

Thanks for your participation in today’s AMA! We’ll post a recap of the questions panelists answered during the live AMA, shortly.

what about the 65000 error in Intune.... there are enough people posting this, why isn't it being covered in this discussion thoroughly?

In my environment, we are not currently consuming all the event logs to look for 1808, but I have a MECM (SCCM) baseline looking for the regkey status of "Updated". For those workstations that show "Updated" does that mean they are good? Nothing else to do?

Are you guys aware if there are plans to allow the OS to automatically suspend BitLocker protection when a firmware update comes down via Windows Update on devices where Secure Boot is enabled but the PCR 7 binding is not possible?

Firmware updates coming from WU are currently being prevented from installing when Bitlocker Protection is On and the PCRs are set to 0,2,4,11 (generally devices with Secure Boot turned off). The main concern is a subset of devices that leverage OROMS can not bind PCR7 when Secure Boot is enabled and BitLocker is enabled. This causes an SB enabled device to have 0,2,4,11 PCRs preventing them from receiving important firmware updates with updated Default DB 2023 certs. Depending on the client base to suspend bitlocker protection periodically is not a viable solution and doing it automatically via Remediation script would be a security concern.

If a device receives the new certificate in the active db and is later reimaged, would the device lose the new certificate? I'm unclear how reimaging affects the db/bootmgr since the drive has to be en-encrypted?

Does triggering the update manually via registry key in a corporate environment on sample machines help to develop the confidence buckets?

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?