Event details
364 Comments
- Pearl-Angeles
Community Manager
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?
Not super important, It will get fixed by another team soon. This AMA was more about the process and technical background.
I'd also like an answer on if this will be fixed. Here's a really good resource on why its happening for anyone that hasn't found it already. Should be the top result if you search it by title: "Policy is rejected by licensing: Error Code 0x82B00006"
https://patchmypc.com/blog/intune-policy-rejected-by-licensing/
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?
active db is stored in your firmware/NVRAM, so should not be touched by anything you can do to your drives.
Does triggering the update manually via registry key in a corporate environment on sample machines help to develop the confidence buckets?
If you have (full) telemetry enabled and the telemetry is not blocked by the corporate firewall, it will help, regardless which method the update has been pushed.
I see a high number of devices in our environment with the following setting in registry. 1 - “Windows UEFI CA 2023” certificate is in the DB. Will the CFR or LCU trigger it to move to 2 - “Windows UEFI CA 2023” certificate is in the DB and the system is starting from the 2023 signed boot manager ?
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?
What is the expected downtime, how many reboot requires during the Secure Boot certificate renewal process, and how can we effectively manage this within the controlled patching window? Additionally, if we perform one reboot as part of the current monthly patching cycle and defer the second reboot to the next month’s patch schedule, would this cause any performance issues or operational risks on the affected servers?
We have several physical Hyper‑V host servers where Secure Boot is currently disabled at the Windows hypervisor level, while the guest virtual machines have Secure Boot enabled. Please confirm whether it is still necessary to update the compatible firmware on these Hyper‑V host servers.
