SCCM Bitlocker Policy not working for TPM only

[anyweb]

@Cerberus24 

what client OS are you testing this on as a matter of interest?

I'm, happy to do a remote session to compare my lab to yours but it would be good to get more info about your setup

[Cerberus24]

On 2/2/2025 at 9:35 AM, anyweb said:

i'll double check in my https 2409 lab this evening and report back

have you verified that these devices are not targeted by any gpo from your 'old' mbam infrastructure ?

"Apologies for not seeing your reply sooner. This doesn’t apply to the current environment, as there was no previous MBAM infrastructure. However, I did decrypt the devices using the decryption policy, since the machine was imaged and BitLocker had been enabled with a weaker encryption algorithm. The decryption policy worked flawlessly, but as previously mentioned, the encryption policy is not functioning as expected. I have made sure that the targetted devices are no longer targetted by the decryption policy. 

[Cerberus24]

7 hours ago, anyweb said:

@Cerberus24 

what client OS are you testing this on as a matter of interest?

I'm, happy to do a remote session to compare my lab to yours but it would be good to get more info about your setup

The endpoints are running Windows 11 24H2. The severs infrastructure for the MP and DP are running Windows server 2019 1809.

[Cerberus24]

I replicated the same process on my test VM (decrypting with the policy and then re-encrypting using the policy), but for some reason, I’m encountering the same error message as I did on the other devices. Initially, I deployed the BitLocker policies in a smaller controller environment with VMs, and everything worked fine. I’m not sure what might be causing this issue now. The only difference I can think of is that the previous environment was running with self-signed certificates, whereas now it’s running with proper certificates.

- Device status before the decryption policy is deployed.

- Device status after the decryption policy was deployed and enforced.

- Trying to re-encrypt after a successful decryption.



- BitlockerManagemetHandler.log file after encryption policy is deployed

- After rebooting the VM, the next console login via the MSTSC.exe client shows the following:

It’s important to mention that I was able to successfully encrypt and decrypt this same VM while the system was running under self-signed certificates.

 

Edited February 3 by Cerberus24

[anyweb]

if you have access to teams we can do a session to talk about this, ping me there niall AT windowsnoob DOT com, i'm based in Europe.

[Cerberus24]

@anyweb, thank you for your availability and troubleshooting.

I have figured out the problem. The issue stemmed from the fact that I was primarily working with headless computers in my environment. Even though I was running MSTSC with the /admin or /console switch, I never properly checked if the established session was, in fact, a console session. This is why the policy would fail, and we would see errors in the logs when the policy attempted to launch the MBAM UI.

I didn’t realize this until I revisited my VMs and accessed them through the console, instead of connecting via MSTSC. On existing, imaged devices, I was able to resolve the issue by manually interacting with a few devices using SCCM's remote control viewer, which establishes a console session. After logging in via SCCM’s remote viewer, the BitLocker policy executed and encrypted the drives without any issues.

For anyone else in your community facing a similar problem, I addressed the headless computer issue by creating a task sequence during OS deployment. This ensures that devices are imaged with the appropriate BitLocker settings that align with my BitLocker policy. This way, all imaged devices are compliant from the start, and SCCM can still report compliance for these devices, since the policy settings are consistent and encryption is not required. Since I will mostly be accessing the headless computers via MSTSC, this solution works well for my environment.

[anyweb]

23 hours ago, Cerberus24 said:

@anyweb, thank you for your availability and troubleshooting.

I have figured out the problem. The issue stemmed from the fact that I was primarily working with headless computers in my environment. Even though I was running MSTSC with the /admin or /console switch, I never properly checked if the established session was, in fact, a console session. This is why the policy would fail, and we would see errors in the logs when the policy attempted to launch the MBAM UI.

I didn’t realize this until I revisited my VMs and accessed them through the console, instead of connecting via MSTSC. On existing, imaged devices, I was able to resolve the issue by manually interacting with a few devices using SCCM's remote control viewer, which establishes a console session. After logging in via SCCM’s remote viewer, the BitLocker policy executed and encrypted the drives without any issues.

For anyone else in your community facing a similar problem, I addressed the headless computer issue by creating a task sequence during OS deployment. This ensures that devices are imaged with the appropriate BitLocker settings that align with my BitLocker policy. This way, all imaged devices are compliant from the start, and SCCM can still report compliance for these devices, since the policy settings are consistent and encryption is not required. Since I will mostly be accessing the headless computers via MSTSC, this solution works well for my environment.

ah great to hear it and thanks @Cerberus24 for posting your findings, i'm sure it'll help someone !