About this page

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 ...

My Dell, HP, and Lenovo BIOS password and settings scripts have been around for years, and over time they drifted away from the modules, operating systems, and hardware they run against. I’ve now finished a top-to-bottom modernization of the whole set (the v2 generation) currently at version 2.3.0. This post summarizes what changed across all of the scripts and links to the individual posts where each one is covered in detail. ...

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. ...

The CMS method described in Securing BIOS Passwords relies on a document encryption certificate. The BIOS password is encrypted to that certificate’s public key, and only devices holding the matching private key can decrypt it. This post is a companion to that one. It covers how to create and manage the certificate itself: choosing between a self-signed certificate and one issued from an enterprise PKI, and handling the full lifecycle from creation through distribution, rotation, and removal. ...