Event details
116 Comments
lalanc01 Very good questions.
Would you mind following up with some more details:
- Those machines are managed / part of a domain, I assume? And neither AvailableUpdates nor ManagedDevicesOptIn has ever been touched by you?
- Can you definitely say that they have been updated by Microsoft (as opposed to them coming with the new certs from the factory, or having them updated by updating the firmware and applying setup defaults)?
- Do you find any of the relevant Event log entries in their event logs (apart from the one stating that there is nothing to update)?
- Would you mind share a sample Bucket Hash?
For devices that are not managed or have opted into ManagedDevicesOptin, they may have been updated via CFR despite the Bucket hash not yet being High Confidence. After all that is what CFR is about (rolling changes only to a subset of devices). Update via the High Confidence list included in the LCR should (as I understand it) not update devices that were in "Under observation" state, and I assume that hashes that once were High Confidence would not move back to Under Observation, but rather to one of the known blocker categories in case there were any issues.
About your last question, my impression is that they will not succeed to getting all the buckets to High Confidence by June, just by looking at the pace buckets have moved in the last months. But I'd be happy to be proven wrong.
Stats so you can draw your own conclusion:
Name May April March High Confidence 2005634 1878953 1617397 Under Observation - More Data Needed 395777 466652 597235 Temporarily Paused 52420 53611 0 Not Supported - Known Limitation 32736 33831 0 High Confidence (Percent) 80,7 % 77,2 % 73,0 % Under Observation (Percent) 15,9 % 19,2 % 27,0 % My apologies Mihi, I see you weren't replying to me. Edited for removal.
Why do we have a lot of devices that are 'Under observation' that have been updated by MS?
We haven't set the registry and set any policies to do the update.
Is it that you're trying on some of those devices but you're still not fully confident to set them to 'high confidence'
Should we expect them to be handle by MS before June?
thksWe are doing IT Managed updates. Edited for clarity:
Q. If an OEM firmware update successfully updates dbDefault without issue, can that outcome be used as an indicator that the platform falls into a “high confidence” category for subsequently applying the Microsoft OS‑initiated Secure Boot update (db via AvailableUpdates = 0x5944)?
Background:
- Small IT Staff (Practically managing this change myself)
- We do not send send Windows diagnostics/telemetry to Microsoft
- Small subset of newer Dell models, but total device count in thousands.
I'd say it is a very strong reason to believe so. But on the other hand, alone the fact that the vendor issued a firmware update in the timeframe the certificate updates have been running is a very strong argument that the update process is safe (does not lead to hangs or incompatibility issues).
OTOH, it is not a guarantee that it is successful (does not fail with a defined error code). There are cases (lost/replaced platform key) that cannot be remediated just by installing a firmware update, but only by following additional steps (e.g. suspending Bitlocker and resetting setup defaults). But I would expect the firmware vendor to clearly communicate those if they apply.
Mihi,
I appreciate your response and want to provide some more insight and clarification on my question and situation.
Our planned update flow is going to be:
- Deploy approved OEM firmware/BIOS updates via Dell Command Update.
- Dell is packaging the dbDefault certificates with most of its newer BIOS updates.
- Verify (via SCCM) that the firmware update successfully updates dbDefault and that systems remain healthy (Secure Boot enabled, normal boot, no intervention required)
- Build an SCCM collection scoped only to systems where dbDefault is confirmed updated
- Deploy a configuration to that collection that sets the Windows Secure Boot AvailableUpdates registry value to 0x5944 (IT‑managed Secure Boot update path)
Let me clarify two things about our fleet of devices:
- We do not send Windows diagnostics/telemetry to Microsoft.
- While we deploy only a small, controlled subset of hardware models, the total device count is in the thousands, and manual validation or reverse‑engineering of Microsoft “high confidence” buckets on a per‑model/firmware version/etc. basis is operationally infeasible for a small IT staff. I am practically taking this on by myself.
What I'm trying to validate is:
If an OEM firmware update successfully updates dbDefault without issue, can that outcome be used as an indicator that the platform falls into a “high confidence” category for subsequently applying the Microsoft OS‑initiated Secure Boot update (db via AvailableUpdates = 0x5944)?
I understand Microsoft’s intent and safety model, I'm just trying to confirm that successful OEM‑managed dbDefault updates can reasonably substitute for telemetry‑driven confidence signals in an IT‑managed, low‑model‑variance enterprise environment.
I fully recognize there are edge cases (e.g., lost PK, Setup Mode state, BitLocker remediation requirements), but we are trying to validate whether this assumption aligns with Microsoft’s intended deployment guidance for enterprises unable to rely on diagnostics‑based confidence scoring.
- Deploy approved OEM firmware/BIOS updates via Dell Command Update.
