Jump to content


Cerberus24

New Members
  • Posts

    8
  • Joined

  • Last visited

  • Days Won

    1

Cerberus24 last won the day on January 29

Cerberus24 had the most liked content!

Cerberus24's Achievements

Rookie

Rookie (2/14)

  • Week One Done Rare
  • Conversation Starter Rare
  • First Post Rare

Recent Badges

1

Reputation

  1. 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.
  2. The endpoints are running Windows 11 24H2. The severs infrastructure for the MP and DP are running Windows server 2019 1809.
  3. "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.
  4. Yes, I’ve tried that as well, but I’m still getting the same error message. One thing I didn’t mention earlier is that I’m running this ENV on HTTPS, but as far as I can tell, the certificates are all working properly.
  5. Hi, there is no CD/DCD in the tray, nor is there an ISO mounted on the system. Correct, I initiated a console login through Microsoft RDP to check the encryption process, but I always receive the following error message described below.
  6. Hi Anyweb, I’ve deployed BitLocker using your setup articles, but I’m encountering an issue where the devices aren’t encrypting the drives as expected. Any assistance you can provide would be greatly appreciated. It’s worth mentioning that the devices I’m testing with are all located in the same device collection where the MBAM encryption policy has been deployed. Additionally, all the devices have TPM 2.0, TPM is enabled and ready, and Secure Boot is also enabled. As for the logs, everything appears to be working as expected, except for the MBAM admin logs, which indicate that it cannot connect to the MBAM and hardware recovery services. However, according to Microsoft’s documentation, "Starting in version 2103, the implementation of the recovery service changed. It no longer uses legacy MBAM components, but is still conceptually referred to as the recovery service." Given this, I assume this error log should not affect the encryption process, correct? For reference, my environment is running Configuration Manager version 2409. I have attached a few screenshots for your reference. Thank you!
  7. Hi Nscott, I wanted to check in and see if you were able to find a solution to this issue. I’m experiencing the same problem and have gone through Anyweb's SCCM BitLocker setup and troubleshooting steps, but I still can't seem to identify the cause. Any insights you might have would be greatly appreciated!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.