Any changes to encryption settings create a difference between the new policy and the old policy. This causes all machines under the policy to decrypt and re-encrypt with the new settings. Changes only to advanced settings, such as recovery key rotation or backup in the domain controller, are applied without decryption and re-encryption.
When TPM is not detected, the Endpoint Central agent assumes no TPM and applies encryption settings for machines without TPM. When the failure is resolved and TPM is detected, the machine is decrypted and encryption settings for TPM machines are applied.
For non-TPM machines, encryption requires a passphrase. Only after the password is provided will encryption begin.
A single policy is sufficient for both TPM and non-TPM machines.
The policy is removed from the machines but encryption remains. Machines are not decrypted on policy removal.
The last deployed policy takes effect. The active policy can be checked in the managed systems view.
If the new policy’s encryption settings differ from the current settings, the new policy is enforced.
BitLocker enforces encryption status changes only on machines where a BitLocker policy is applied.
The policy is revoked but encryption stays. The machine is not decrypted.
To remove a fully decrypted computer and prevent encryption prompts:
Encrypted data drives are decrypted. The computer remains partially encrypted.
Modifying encryption settings triggers re-encryption of the drives.
Endpoint Central will not encrypt drives without a deployed policy. Full encryption can occur due to:
Yes. Log in with the recovery key. After login, the user is prompted to reconfigure or modify the password or PIN.
The agent initiates BitLocker processes during its refresh cycle. Execution time depends on the machine. Encryption begins only after the recovery key is successfully stored on the server.
No. BitLocker can be enabled and policies deployed at any time.
When a drive is in suspend protection mode it is encrypted but not protected. To check, go to the Endpoint Central web console, navigate to BitLocker management, find the computer under Managed Computers, and verify if Protection Status is "Disabled".
If the user manually protects data drives and a BitLocker policy is later deployed, the protector changes to "Auto Unlock".
No. A restart is not required. Once the policy is deployed, encryption begins immediately in the background.
Applying both simultaneously may cause conflicts. It is not recommended.
BitLocker supports Windows 7 and above.
Encryption of portable drives is not supported by Endpoint Central's BitLocker Management.
The current status updates during the refresh cycle. On-demand status can be obtained by navigating to Insights → Managed Systems and clicking "Update Now".
Note: Agent-server communication is required for timely data updates. Interruptions can delay updates.
Possible reasons:
Contact support for assistance if these issues occur.
If the "Encrypt OS Drive Only" option is selected during policy creation, the encryption status is shown as "Partially Encrypted".
Protection status indicates whether BitLocker is active. If it shows "Disabled" while fully encrypted, BitLocker is suspended. Endpoint Central does not suspend BitLocker. Possible causes include:
Deploying the encryption policy through Endpoint Central re-enables BitLocker protection.
To receive automated BitLocker reports, navigate to Scheduled Reports to configure the predefined reports to be sent.
The BitLocker status for Inventory module is only detected through the Inventory scans. The status will only be reflected in the next Inventory scan.
If the domain controller is unreachable or permissions prevent updates, the recovery key cannot be stored there.
Yes. BitLocker encrypts drives even if domain controller sync does not occur.
Yes. The Central Server manages all recovery passwords.
Configure a scheduled database backup stored in a safe path. Instructions are here. Recovery keys can be retrieved from the backup files.
If AD is unreachable, ManageEngine BitLocker retries updating the Recovery Key up to five times per day during its refresh cycle until AD becomes reachable.
If the recovery key retention is enabled, the recovery key will be retained in the server upto an year even after the machine is removed. On disabling, the recovery key(s) of the removed will be discarded after 30 days. If the machine's agent was uninstalled, but is viewed as greyed out under Scope of Management (SoM) in Agent tab, its recovery key can be retrieved using the machine's name. But if the machine's agent was uinstalled and also removed under SoM, the recovery key can only be retrieved using the recovery key ID. The recovery key ID can be found in the prompted recovery key dialog box.
The BitLocker-protected drive can be unlocked by providing the PIN or passphrase. If you forget the unlock password, it can be unlocked by entering the recovery key.
Once the recovery key is viewed in the console, a new recovery key is generated, and the agent will change the recovery key on the next startup.
Under the current workflow, when a new recovery key is generated, it is uploaded to the server. After the server successfully stores the new key, the old recovery key is deleted. This sequence occurs during the agent refresh cycle.
If the agent is offline, it cannot upload the newly generated recovery key to the server due to lack of connectivity. As a result, the existing recovery key remains valid and unchanged. Once the agent reconnects, the rotation process continues during the next refresh cycle, generating and uploading the new recovery key to the server.
When viewing the "Retrieve Recovery Key" page, you may see multiple Recovery Key Identifiers listed for the same drive. This occurs because previously rotated recovery keys are also retained and displayed. The identifier currently shown in the Managed Computers view represents the active recovery key for that drive.
A single drive can have multiple recovery keys associated with it. All recovery keys displayed in the Managed Computers view are valid and can be used to unlock the drive.
When unlocking a drive, Windows prompts with the Recovery Key Identifier. This identifier can be used to retrieve the corresponding recovery key in the console.
In standard scenarios, the BitLocker add-on generates one recovery key per drive. Multiple keys may appear if additional keys were created due to manual interruptions during encryption or as a result of third-party software interactions.
If the recovery key is prompted at every boot, this is typically due to an environmental or system-related issue rather than the encryption workflow itself. It is recommended that the customer contact Microsoft Support for further assistance, as this behavior is commonly associated with operating system or hardware configuration factors.
Verify whether the drive is currently in a locked state. If the drive is locked, Endpoint Central will not be able to retrieve the BitLocker recovery key. Unlock the drive and attempt the retrieval again. To verify if the drive is in locked state, navigate to Managed Computers and click on the specific machine. The lock status of the machine's drives will be stated.
