Intune

This is the reference post for the Managing BIOS with Intune series. It is not part of the setup walkthrough. If you are deploying the solution, follow the deep-dive posts in order; come here when you need to look up a status line, understand the registry markers, decode a FailReason, or troubleshoot a device that isn’t behaving as expected. The registry markers A recurring remediation has to remember what it has done between runs, because the BIOS can only report whether a password is set, not which version. The scripts bridge that gap with registry markers under HKLM:\SOFTWARE\ConfigJonScripts\FirmwareManagement\. ...

This is the third post in the Intune BIOS Reporting series The first post covered the output format and the no-infrastructure reporting; the second built the Azure infrastructure. This one turns the Log Analytics reporting on, explains the data model, what it costs, and shows the KQL it enables. With the workspace, tables, app, and certificate from the setup post in place, the detection scripts can send a structured record on every run (full per-device, per-setting picture, queryable with KQL). ...

This is the second post in the Intune BIOS Reporting series. The first post, Reporting on BIOS management with Intune, covered what you can do with no extra infrastructure. This one builds the Azure infrastructure that lets the detection scripts push structured records to Log Analytics over the Logs Ingestion API. This is a one-time setup. It is the longest post in the series because there are several moving parts. ...

This post is a continuation of the Managing BIOS with Intune series, and is the first of three posts about reporting. The Intune scripts are configured to output information to log files, registry keys, the Intune remediations dashboard, and Azure Log Analytics. This series will cover the available options for working with the output of the Intune scripts. This post covers what you can do with no extra infrastructure: reading results in the Intune console, exporting them to CSV, and pulling the same per-device run states from Microsoft Graph. ...

Keep Dell, HP, and Lenovo BIOS settings at a desired state with an Intune remediation that detects drift, reapplies settings, and tracks each one separately.

Deploy Dell, HP, and Lenovo BIOS password management as an Intune remediation that sets, rotates, reapplies, or clears the password based on a target version.

This is the first deep dive in the Managing BIOS with Intune series. The goal here is to get from nothing to password material that is ready to deploy as an Intune remediation. That means three things, in order: A document-encryption certificate, with its private key delivered to devices. BIOS passwords encrypted to that certificate as CMS files. Those CMS files embedded into a remediation script. The actual password and settings remediations are covered in the next two posts. This one is everything that has to be in place first. ...

My Dell, HP, and Lenovo BIOS password and settings scripts have primarily been built for use with traditional device management tools like Microsoft Configuration Manager. This post introduces a new set of scripts designed specifically for Intune. These scripts are designed around the Intune Remediations feature. The goal is to manage BIOS passwords and settings continuously, with no module dependencies, and no plain-text passwords. The scripts can be downloaded from my GitHub. https://github.com/ConfigJon/Firmware-Management ...

This post was updated on June 18th, 2026. This post has been rewritten from the ground up. The original version of this solution was a Configuration Manager task sequence script driven by a Parameters.ini file. It worked, but it was built for a Windows 10 task-sequence world, and a lot of its customizations were applied as policies that locked the setting so the user could no longer change it. The modern version is a complete redesign for Windows 11 and Intune/Autopilot. It is a Win32 app that runs during the Autopilot device Enrollment Status Page and applies a curated set of customizations as defaults that a non-admin user can still change. This post covers the high-level concepts. The full setting list and the deeper implementation details live in the docs in the GitHub repo, so I won’t duplicate all of that here. ...