Under the Hood, Pt. 5: Intune BIOS Configurations

Under the Hood, Pt. 5: Intune BIOS Configurations
Photo by Its me Pravin / Unsplash

New in Intune 2403, native (Dell) BIOS Management capabilities! How does it work? What happens if you do something wrong?


Before we start, we're going to need to get some pre-reqs in order, namely:

The "secret sauce" that acts as the OEM Agent to apply a BIOS configuration to a device. The documentation is worth a read, but whether you install it manually for testing or wrap it as a Win32 for wider deployment, it's essentially a lightweight version of the Configure command-line and the "Dell.EndpointConfigure.WinServiceAgent" that will run on a device and enact the changes pushed down via Intune:

  • The .NET 6.0 Runtime

A pre-req for the Endpoint Configure software to install. For convenience I added this via an Enterprise App Management package and fired it off as a Required app on all my devices:

I'd love to have been able to set this as a Dependency on my Endpoint Configure Win32 app, but sadly that's not an available option right now.

Purely to enable creation of a BIOS Configuration profile in CCTK format, though theoretically if trawl the documentation and identify the options and configuration you want to apply, you could create a .CCTK file without the software.

Policy Creation

Step 1: Create your BIOS Configuration Package

Using the Dell Command | Configure software enables you to configure a massive amount of options in your Dell BIOS. As this post isn't about Configure, I suggest reading over the docs to verify what you're trying to do is valid. Also be aware that the defined configuration has to be supported by the device(s) it's being deployed to. Trying to set Intel-only options on an AMD device is probably just going to end up with it failing, but as with everything to do with BIOS config, it's very much at your own risk...

In my example configuration, I want to ensure 3 things are configured:
Virtualisation is Enabled
TPM is Enabled
Secure Boot is Enabled

Dell Command | Configure Package Creation

I then save this configuration as a .CCTK file to be used in the Intune policy.

Step 2: Create your Intune Policy

Available as of Intune 2304, a new option is available in the "Templates" section of the new policy creation flow. Normally I'd advise against going here, but there are still some policies which only exist here and aren't configurable via Settings Catalog, this new "BIOS configurations and other settings" being one.
Don't be confused by the Device firmware configuration interface template. DFCI is a whole different thing.

Intune "BIOS configurations and other settings" template

After giving our policy a name, we're met with three options:

The "Hardware" dropdown only has Dell as an available choice, but it would be great if this feature was expanded to support the likes of Lenovo and HP in the future. You also get an option to disable BIOS password protection (more on how important this is later), and finally, an upload box to select our created CCTK file.

Work out your assignments and that's it!

As this wouldn't be an Under the Hood without looking at an API, below is the Graph call to create the policy:

    "@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceManagement/hardwareConfigurations/$entity",
    "id": "{GUID}",
    "version": 1,
    "displayName": "Win - OIB - BIOS - D - Dell BIOS Configuration - v1.0",
    "description": "",
    "createdDateTime": "2024-04-03T10:25:45.9524821Z",
    "lastModifiedDateTime": "2024-04-03T10:25:45.9524821Z",
    "fileName": "enable_virtualisation-tpm-secureboot.cctk",
    "configurationFileContent": "W2NjdGtdDQpTZWN1cmVCb290TW9kZT1EZXBsb3llZE1vZGUNClRwbVNlY3VyaXR5PUVuYWJsZWQNClZpcnR1YWxpemF0aW9uPUVuYWJsZWQNCg==",
    "hardwareConfigurationFormat": "dell",
    "roleScopeTagIds": [
    "perDevicePasswordDisabled": false

Note the "configurationFileContent" value. Immediately throwing this into a Base64 decoder spat out the following:


Which is (somewhat unsurprisingly) exactly the contents of the CCTK file, and why I mentioned earlier that you could theoretically just write your own without installing the Configure software at all.

Step 3: Win?

From an Intune perspective, we're done, it was that simple. If only everything in life was that easy, eh?

So we've deployed the pre-requisite apps, created our configuration and the Intune policy to deploy said configuration on a device. What now?

Let's take a look at what actually happens on the device, and places where you can check if you experience issues...

Delivery and Troubleshooting

So this is where it got interesting real fast (if you find that sort of thing interesting).

Once you've created your policy, you'd be forgiven in thinking this may come down like any other policy, but that's not the case. This is a service-driven policy just like if you enable the App Control Managed Installer functionality within Intune, and as such comes with a delay in both deploying the policy, but also in subsequent reporting. Reporting which I will add, that is very important to listen to and wait for the results of.

Key Locations:

  • C:\ProgramData\Dell\EndpointConfigure

This is your primary logging location and contains logs for the Endpoint Configure agent runs.

  • C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

As always, the IME Logs prove helpful, but specifically the AgentExecutor and HealthScripts logs.

  • C:\Windows\IMECache\HardwareConfiguration

What's this? A brand new directory? If you dig into this folder, you'll find it's empty most of the time, but contains a copy of your .cctk file when the policy is being processed and run by the remediation script below.

  • C:\Windows\IMECache\HealthScripts\{BIOSPolicyID}

The most interesting folder. In here are a detect and remediate script pair, and a file called metadata.json. All this json file contains is a Base64 string which, when decoded, gives us a certificate with the following subject:

CN=HardwareConfigSigning.manage.microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US

So we've got an intermediate service signing our BIOS configuration as well as version tracking. We've essentially got BIOS Desired State Configuration happening!

One thing I did notice that (as of time of writing), the Detect and Remediate scripts are checking the following reg path of:


However, due to IME being a 32-bit process, it actually ends up dumping the corresponding reg keys into WOW6432Node on a 64-bit OS, which was a bit confusing when I was trying to decode everything that's going on.

This reg location keeps the local policy version info, status, and any agent error messages which eventually then get passed back up to the service and reported on via Intune.

Another curious thing about metadata.json is if we decode this as text rather than as a certificate, we can also see some additional information:

Not only can we see policy information, serial number, a hash of the configuration file service-side, we get the existing (if set) and new password to apply to the device!

This is the ONLY way that you could possibly retrieve a device password for a device outside of the published Graph API endpoint of beta/deviceManagement/hardwarePasswordInfo

If there is one thing you need must take away from this blog, it's:


MS Learn Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/bios-configuration

Dell Docs: https://www.dell.com/support/home/en-us/product-support/product/command-endpoint-configure/docs

And the reason I say this is...

Uh Oh. I broke it.

So in testing this, I assumed I knew best, and I broke my test laptop. Not entirely, but if I ever want to change BIOS settings again, I'm out of luck without submitting a repair request to Dell. So here's an explanation of where I went wrong in the hope you don't do the same thing:

Mistake Number 1:

If you do not set the "Disable per-device password protection" setting in the policy to "Yes", Intune will set a completely random BIOS password. BIOS LAPS is a theoretically neat concept, but if you're not expecting that to happen, you might be in for a bit of a shock. The first time I configured the policy, I assumed (incorrectly) that because the device didn't have a password set already, it wouldn't do anything. I was wrong, and had a BIOS password set on my device:

When managing passwords using Microsoft Intune Admin Center user interface, remember the following:
* If you select NO for Disable per-device password protection, then Intune sends a random BIOS administrator password that is applied on the device.
* If you select YES for Disable per-device password protection, then the previously applied BIOS administrator password through Intune workflow is cleared.
* If no BIOS administrator password was applied earlier through Intune workflow, then the setting helps keep the devices in a password-less state.

Mistake Number 2:

The first CCTK policy I used included a policy setting that was reliant on another setting I hadn't configured so the policy failed. I verified this in the logs, but I adjusted the deployed policy while it was still in a "Pending" state as far as the service was concerned I not only changed the CCTK, but I also switched the per-device password protection to "Yes". I haven't quite been able to identify what cadence the script runs and the results are passed back up to the service, but it's a while. Here's the bit of the Dell docs I didn't pay attention to:

Do not modify BIOS Configuration Profiles in the Pending state.
* If there is already an existing BIOS Configuration Profile that is deployed to the endpoint groups and the status is displayed as Pending, do not update that BIOS Configuration Profile.
* You must not update until the status transitions from Pending to Succeeded or Failure.
* Modifying may cause conflicts and subsequent BIOS Configuration Profile version failures. Sometimes, BIOS Password sync failures may occur, and you may not be able to see the newly applied BIOS Password.

Mistake Number 3:

I started to piece bits of this puzzle together, but remained impatient, and deleted and created a new policy.
Needless to say, the above warning about modifying a profile that's in a pending state goes out the window if you go and delete that policy.

End Result:

The policy and service did what it was told initially and set a random password on my device. I subsequently modified, and deleted the policy before waiting for the device to actually escrow the BIOS password. I realised what I'd done too late and couldn't sneakily retrieve the password from the metadata.json on the device, and that information isn't shown in any of the IME logs, leaving me without the password that had been set.


DFCI was a great concept that was under-supported by OEMs but even then had lackluster control over what you might want to be configuring. This functionality gives you immense capability, but somewhat unsurprisingly, comes with a lot of caveats and even more potential risk.

BIOS passwords have been a topic since I can remember, and while I'd argue that having an individual password per-device significantly reduces the attack vector on devices vs. having the same password set across everything, having a simplified, DFCI-like policy that interacts with the device in a vendor-agnostic fashion would be the ultimate dream here, but what's been implemented between Dell and the Intune team is no mean feat to accomplish, so credit where credit is due.

Just... Please read the docs, mkay?

James Robinson

James Robinson

With 20 years of experience, James is a Principal Consultant specialising in Modern Workplace and End User Compute technologies, with a focus on Modern Management and Cloud-Native endpoints.
Brighton(ish), United Kingdom