How to Set BitLocker Unique Identifiers with Intune: The Practical Guide

If you’re managing Windows devices with Intune and want to enforce BitLocker encryption on removable drives, you’ve probably run into the “unique identifier” roadblock. Here’s what’s going on, why it matters, and—most importantly—how to fix it with a simple, reliable PowerShell approach.

What Are BitLocker Unique Identifiers, and Why Should You Care?

BitLocker’s unique identifiers are special values that Windows uses to track which organization has encrypted a removable drive. When you enable the policy to block write access to drives encrypted outside your company, Windows checks this identifier. If the drive’s unique ID doesn’t match your organization’s, users can’t write to it. This is a great way to prevent data leaks, but it only works if your devices set the identifier in the first place.

Here’s the catch: if you’re using Intune, there’s no built-in setting to configure these unique identifiers. That means, in some environments—especially with Hybrid Azure AD Joined devices—BitLocker might block write access to drives encrypted by your users simply because the identifier wasn’t set. After a reboot, the device forgets it was the one that encrypted the drive, and suddenly, your users are locked out.

Why Can’t I Just Use Group Policy?

Group Policy makes this easy: just set the “Provide the unique identifiers for your organization” policy, and you’re done. But Intune doesn’t expose this setting, and you can’t just import the ADMX template—Microsoft blocks most first-party policies from being ingested into Intune.

The Solution: PowerShell to the Rescue

Luckily, the Group Policy setting just writes two registry values:

• HKLM\Software\Policies\Microsoft\FVE\IdentificationField (DWORD, set to 1 to enable)
• HKLM\Software\Policies\Microsoft\FVE\IdentificationFieldString (String, your unique identifier)

You can set these directly with PowerShell and deploy the script via Intune. Here’s a ready-to-use script (replace "YourOrgID" with your actual identifier):

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\FVE"
$enable = "IdentificationField"
$string = "IdentificationFieldString"
$identifier = "YourOrgID"

if (!(Test-Path $registryPath)) {
    New-Item -Path $registryPath -Force | Out-Null
}

New-ItemProperty -Path $registryPath -Name $enable -Value 1 -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -Path $registryPath -Name $string -Value $identifier -PropertyType "String" -Force | Out-Null

Why Proactive Remediation Is the Best Solution

You could deploy a PowerShell script once, but what happens after a Windows update, a reimage, or a registry reset? The setting could disappear, and your users are back to square one. Proactive Remediation in Intune solves this by continuously checking and fixing the settings—no manual intervention required.

Proactive Remediation (Remediations) lets you:

• Detect if the BitLocker unique identifier is missing or incorrect.
• Automatically fix it if needed.
• Schedule checks to run every 8 hours (or on demand).
• Monitor compliance and remediation status in the Intune portal.

Step 1: Write Your Detection Script

The detection script checks if the registry values for the BitLocker unique identifier exist and are set correctly. If not, it signals Intune to run the remediation script.

$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\FVE"
$enable = "IdentificationField"
$string = "IdentificationFieldString"
$identifier = "YourOrgID"

if (Test-Path $regPath) {
    $idField = Get-ItemPropertyValue -Path $regPath -Name $enable -ErrorAction SilentlyContinue
    $idString = Get-ItemPropertyValue -Path $regPath -Name $string -ErrorAction SilentlyContinue
    if ($idField -eq 1 -and $idString -eq $identifier) {
        exit 0 # Compliant
    }
}
exit 1 # Not compliant, trigger remediation

Replace "YourOrgID" with your actual organization identifier.

Step 2: Write Your Remediation Script

The remediation script sets the required registry values if they’re missing or incorrect.

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\FVE"
$enable = "IdentificationField"
$string = "IdentificationFieldString"
$identifier = "YourOrgID"

if (!(Test-Path $registryPath)) {
    New-Item -Path $registryPath -Force | Out-Null
}
New-ItemProperty -Path $registryPath -Name $enable -Value 1 -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -Path $registryPath -Name $string -Value $identifier -PropertyType "String" -Force | Out-Null

Step 3: Deploy with Intune Remediations

1. In the Intune admin center, go to Devices > Remediations.
2. Click Create script package.
3. Upload your detection and remediation scripts.
4. Assign the package to your device groups.
5. Set the schedule (default is every 8 hours).
6. Monitor compliance and remediation status in the Intune portal.

For a detailed walkthrough, see Microsoft’s official documentation.

Why This Approach Works

Deploying as a remediation script means your BitLocker unique identifier is always set, even if something changes on the device. This is more robust and future-proof than a one-time script deployment. You’ll avoid mysterious “can’t write to drive” errors and keep your data protection policies airtight.

Final Thoughts

Intune Proactive Remediation is the modern, reliable way to enforce BitLocker unique identifiers across your fleet. It’s automated, self-healing, and gives you visibility into compliance, so you can focus on bigger things.

---

Need more practical Intune and BitLocker tips?
Check out more guides at Local Error, where we break down real-world problems and deliver solutions that work.