BitLocker Initialize - NinjaOne

Purpose

This solution provides a comprehensive, policy-driven framework for automating and enforcing BitLocker encryption on Windows endpoints within NinjaOne. It eliminates the need for manual script execution by utilizing NinjaRMM Custom Fields to define encryption standards (such as encryption method, key protector type, and mount point) and enforcing them via automated logic.

The solution operates on a "Gatekeeper" model: administrators opt-in specific devices or locations using a control flag. A detection script then continuously audits the device against the defined policy. If a device is found to be non-compliant—whether it is unencrypted, suspended, or using an incorrect algorithm—the system automatically triggers a remediation workflow to bring the device back into compliance.

Safety & Recovery Key Backup: A critical feature of this updated solution is the mandatory safety audit. Regardless of whether the initialization succeeds or fails, the automation immediately captures the current BitLocker status—including active Recovery Passwords—and writes them directly to NinjaOne Custom Fields. This ensures that recovery keys are available in the RMM immediately, preventing data loss scenarios on non-TPM devices where a drive might lock before keys can sync to Active Directory or Entra ID.

Key capabilities include:

• Granular Configuration: Define specific encryption parameters (e.g., XTS-AES 256 vs. AES 128) and key protectors (TPM, PIN, Recovery Password) via Custom Fields.
• Immediate Key Backup: Automatically stores the Recovery Password in the cPVAL BitLocker Info field to ensure immediate access in lockout situations.
• Smart Remediation: Automatically handles complex scenarios, such as injecting a missing Recovery Password, resuming suspended protection, or fully re-encrypting a drive if the wrong algorithm is detected.
• Safety & Compatibility: Built-in checks prevent execution on unsupported hardware (e.g., Windows Home edition) or missing prerequisites.
• Wait-Loop Logic: The remediation process includes intelligent monitoring to ensure drives are fully decrypted before attempting re-encryption.

The solution uses a BitLocker Initialization - Detection script to evaluate the system state against the Custom Field policy, which triggers the Initialize BitLocker script via a Compound Condition to execute the necessary encryption logic.

Associated Content

Custom Fields

Name	Default	Example	Level	Required	Managed By
cPVAL BitLocker Enable	-	Windows	Organization, Location, Device	Yes	Manual
cPVAL MountPoint	$env:SystemDrive	C:	Organization, Location, Device	No	Manual
cPVAL EncryptionMethod	XtsAes128	XtsAes256	Organization, Location, Device	No	Manual
cPVAL KeyProtectorType	RecoveryPassword	TpmPin	Organization, Location, Device	No	Manual
cPVAL Allow TPM Or Reboot	0	3	Organization, Location, Device	No	Manual
cPVAL SkipHardwareTest	false	true	Organization, Location, Device	No	Manual
cPVAL PIN Or Password	-	123456	Organization, Location, Device	No	Manual
cPVAL Path Or ADAccount	-	CONTOSO\Group	Organization, Location, Device	No	Manual
cPVAL BitLocker Info	-	HTML Table	Device	No	Automation
cPVAL BitLocker Enabled for System Drive	No	Yes	Device	No	Automation

Automations

Name	Function
BitLocker Initialization - Detection	Evaluates the endpoint's current encryption state against the policy defined in Custom Fields. Returns specific exit codes (0=Compliant, 1=Non-Compliant, 2=Error) to drive the automation logic.
Initialize BitLocker	The remediation engine that applies the desired configuration. It handles enabling encryption, adding key protectors, or re-encrypting the drive. It now also performs a safety audit to log recovery keys.

Compound Conditions

Name	Function
Enable BitLocker - Workstation	Automatically runs the Initialize BitLocker automation on Workstations when the Detection script identifies a non-compliant state AND the device is opted-in via the "Windows Workstations" setting.
Enable BitLocker - Server	Automatically runs the Initialize BitLocker automation on Servers when the Detection script identifies a non-compliant state AND the device is opted-in via the "Windows Servers" setting. The BitLocker Drive Encryption feature must be enabled on servers to encrypt a drive with BitLocker disk encryption. Encryption will not work without enabling this feature.

Implementation

Step 1

Create the following custom fields as described in the documentation:

• Custom Field: cPVAL BitLocker Enable
• Custom Field: cPVAL MountPoint
• Custom Field: cPVAL EncryptionMethod
• Custom Field: cPVAL KeyProtectorType
• Custom Field: cPVAL Allow TPM Or Reboot
• Custom Field: cPVAL SkipHardwareTest
• Custom Field: cPVAL PIN Or Password
• Custom Field: cPVAL Path Or ADAccount
• Custom Field: cPVAL BitLocker Info
• Custom Field: cPVAL BitLocker Enabled for System Drive

Step 2

Create the following automations as described in the documentation:

• Automation: BitLocker Initialization - Detection
• Automation: Initialize BitLocker

Step 3

Create the following compound conditions as described in the documentation:

• Compound Condition: Enable BitLocker - Workstation
• Compound Condition: Enable BitLocker - Server

FAQs

Q. What happens if I just enable the solution for all Windows machines but do not set any other custom fields?

A: The solution is designed to have safe "Default" values. If you simply set the cPVAL BitLocker Enable field to Windows (or Windows Workstations/Windows Servers) and leave everything else blank, the solution will apply the following configuration:

• Target: System Drive (usually C:).
• Encryption Method: XTS-AES 128.
• Protector: RecoveryPassword. Important: If the machine supports TPM, selecting this default option will automatically enable both the TPM and RecoveryPassword key protectors. This ensures the device boots seamlessly via TPM while retaining a recovery option.
• Hardware Test: It will run the hardware test (requiring a reboot before encryption starts) unless you explicitly skip it.

Q. How do I turn on BitLocker for a specific computer?

A: Navigate to the device in NinjaOne, go to the Custom Fields tab (specifically the BitLocker tab), and set the cPVAL BitLocker Enable dropdown to Windows, Windows Workstations, or Windows Servers.

Q. Does this solution support Windows Home edition?

A: No. The BitLocker Initialization - Detection script explicitly checks for the OS edition. If it detects "Home" edition, it exits with an error code (Exit Code 2) and will not attempt to run the encryption script, as BitLocker is not natively supported on Windows Home.

Q. Can I use this solution on Windows Servers?

A: Yes. You must enable the BitLocker Drive Encryption feature on the server first. Then, set the cPVAL BitLocker Enable field to Windows Servers to target the server-specific policies.

Q. Why do we have separate "Windows" and "Windows Workstations" options in the dropdown?

A: This allows for granular policy targeting. You might have a broad policy for "Windows" generally, but specific, stricter policies applied only to "Windows Workstations" or "Windows Servers" via different Compound Conditions. Functionally, checking either will trigger the relevant automation if the Compound Condition is targeted correctly.

Q. How often does the solution check for compliance?

A: The default schedule for the Compound Condition is every 24 hours. You can adjust this interval in the Compound Condition settings if needed.

Q. What if my drive is already encrypted?

A: The detection script will check the current configuration.

• If the settings (Method and Protector) match your Custom Fields, it marks the device as Compliant (Exit 0) and does nothing.
• If the settings do not match (e.g., you want XTS-AES 256 but the drive is AES 128), it marks the device as Non-Compliant, triggering the automation to fix it.

Q. What happens if the drive uses the wrong Encryption Method (e.g., AES 128 instead of XTS-AES 256)?

A: The Initialize BitLocker script will automatically disable (decrypt) BitLocker on the drive. It then waits for the decryption to fully complete (checking every 15 seconds) before re-encrypting the drive with the correct method defined in your Custom Fields.

Q. What happens if the drive uses the wrong Key Protector (e.g., TPM instead of TPM+PIN)?

A: Similar to the encryption method mismatch, the script will disable BitLocker, wait for decryption, and then re-enable BitLocker using the correct protector type you specified in cPVAL KeyProtectorType.

Q. My BitLocker status says "Protection Off" (Suspended). Will this solution fix it?

A: Yes. The detection script explicitly checks for ProtectionStatus: Off. If found, it flags the device as non-compliant. The remediation script will then run Resume-BitLocker to re-enable protection without decrypting the drive.

Q. Why does the "Initialize BitLocker" script perform an audit automatically?

A. The automatic audit acts as a critical fail-safe against data loss. By forcing an audit immediately after the encryption attempt, the solution captures the Recovery Password and writes it to NinjaOne instantly. This ensures that even if the device reboots and locks before it can sync keys to Active Directory or Azure AD, the recovery key is already safely stored in the RMM.

Q. How does the solution prevent lockout on non-TPM devices?

A. Devices without a TPM chip must rely on a RecoveryPassword protector. If such a device encrypts and immediately restarts, it may prompt for that password before it has had time to sync with the domain controller. By capturing this password during the script execution, NinjaOne ensures you have the key required to unlock the drive immediately.

Q. Which Custom Fields are updated by the Initialization script?

A. Regardless of whether the encryption succeeds or fails, the script updates two specific fields:

1. cPVAL BitLocker Info: Stores the full HTML report, including the critical 48-digit Recovery Password.
2. cPVAL BitLocker Enabled for System Drive: Updates the compliance flag to show if the OS drive is protected.

Q. Does the script log BitLocker details even if the encryption fails?

A. Yes. The script logic executes the internal Get-BitLockerDetail function at every exit point, including failure scenarios (Exit 1). This ensures that any partial encryption or existing keys are documented before the script terminates.

Q. What if the machine does not have a TPM chip?

A: You should not use the Tpm, TpmPin, or TpmStartup protector types. Instead, select Password or RecoveryPassword in the cPVAL KeyProtectorType field, which do not strictly require a TPM.

Q. Does the initialization audit replace the need for the daily "BitLocker Audit" schedule?

A. No. The audit performed by the Initialization script is a specific event triggered only during remediation to capture the initial keys. You still need the daily BitLocker and TPM Audit solution to track ongoing compliance, user changes, or potential suspension of BitLocker over time.

Q. Does this solution backup the Recovery Key to NinjaOne?

A: Not directly into a custom field. The script executes standard BitLocker commands. If your environment is configured to back up keys to Active Directory (AD) or Entra ID (Azure AD), Windows will handle that key escrow during the encryption process triggered by this script.

Q. Where do I specify the Active Directory account for backing up keys?

A: If you select AdAccount or RecoveryKey as your protector type, you must provide the domain account, group, or path in the cPVAL Path Or ADAccount field.

Q. Can I encrypt a drive other than C:?

A: Yes. By default, it targets $env:SystemDrive (usually C:). You can specify a different drive letter (e.g., D:) in the cPVAL MountPoint custom field.

Q. Does the script support "Used Space Only" encryption?

A: The wrapper script uses the agnostic Initialize-BitLockerVolume script. While the custom fields don't expose a "Used Space Only" toggle, standard BitLocker behavior via PowerShell on modern Windows versions usually defaults to Used Space Only for new encryptions unless specified otherwise.

Q. How do I configure a Startup PIN for my users?

A:

1. Set cPVAL KeyProtectorType to TpmPin (or Password if no TPM).
2. Enter the desired PIN in the cPVAL PIN Or Password field.

• Note: Ensure the PIN meets Windows complexity requirements (usually 6+ digits).

Q. Will the script reboot the computer automatically?

A: It depends on your settings. The cPVAL Allow TPM Or Reboot field controls this behavior:

• 0: No reboot allowed (Script might fail if TPM needs initialization).
• 1: Allow TPM initialization only.
• 2: Allow Restart.
• 3: Allow both TPM initialization and Restart.

Q. Can I force the script to skip the Hardware Test?

A: Yes. By default, BitLocker runs a hardware test that requires a reboot before encryption begins. If you want to bypass this (start encrypting immediately), check the box for cPVAL SkipHardwareTest (set it to true).

Q. What happens if the computer loses power during encryption?

A: BitLocker is designed to be robust. If power is lost during encryption (or decryption), Windows will typically pause the process and automatically resume it when the computer turns back on.

Q. I changed the Encryption Method custom field, but nothing happened immediately. Why?

A: The automation relies on the Detection script, which runs on a schedule (default: every 24 hours). The change will be picked up during the next scheduled scan. You can force the detection script to run manually if you need immediate results.

Q. Can I use this solution to decrypt a drive permanently?

A: No. This solution is for Initialization and Enforcement. If you set cPVAL BitLocker Enable to Disable, the automation will simply stop checking the device; it will not actively decrypt the drive. You would need to run a separate decryption command manually or via a different script.

Q. What does Exit Code 1 mean in the Activity Log?

A: Exit Code 1 from the Detection script means the device is Non-Compliant. It has passed compatibility checks but requires changes (e.g., needs encryption, needs a resume, or needs a configuration change). This code triggers the Autofix script.

Q. What does Exit Code 2 mean in the Activity Log?

A: Exit Code 2 means the device is Unsupported or in an Error state. This could be because it is running Windows Home, lacks the BitLocker module, or has invalid data in the Custom Fields. The solution will not attempt to run the Autofix script to prevent loops.

Q. Why did the script fail with "Autofix is required"?

A: That message comes from the Detection script. It is not a failure; it is the success message indicating that the script successfully identified a machine that needs BitLocker enabled or fixed. This output is what tells NinjaOne to launch the remediation script.

Q. Where can I see the logs for the encryption process?

A: The scripts generate local logs on the machine at $env:ProgramData\_Automation\Script\Initialize-BitLockerVolume. These logs are also output to the NinjaOne Activity Log for the script run.

Q. What does the "Force" parameter in the script variables do?

A: The Force parameter allows you to override the standard compliance checks. When enabled, if the script detects that the drive is already encrypted, it will ignore the current state and strictly enforce the policy by decrypting the drive first, then re-encrypting it using the settings defined in your Custom Fields.

Q. When should I use the "Force" option?

A: You should generally leave this unchecked for normal operations. It is best used for troubleshooting or remediating devices with "stuck" or inconsistent encryption states. For example, if you suspect an encrypted drive has a corrupted configuration, enabling Force ensures a clean application of your policy from scratch. Note: Since this triggers a full decryption and re-encryption cycle, the process can take a significant amount of time to complete.

Changelog

2025-12-16

• Initial version of the document