Endpoint Services, MECM, BitLocker Full Disk Encryption, Setting up on Windows
How to use MECM to set up full disk encryption with BitLocker on managed Windows endpoints.
Microsoft Endpoint Configuration Manager (MECM), formerly SCCM
University of Illinois IT Pros leveraging MECM, hosted by Technology Services' Endpoint Services team
BitLocker Full Disk Encryption
This process will show how to set up BitLocker full disk encryption on endpoint managed Windows systems using MECM. In order for BitLocker to be enabled on workstations a few steps must be taken to ensure proper deployment. The exact process for each step will vary depending on the hardware used and software configuration. In order to properly encrypt and protect a hard drive, the workstation should have a v1.2 or newer TPM device.
You will need
- administrative access to the affected Windows systems (the endpoints).
- access to control these endpoints via MECM.
- each managed endpoint that will become encrypted must have a v1.2 or newer TPM device.
- a new GPO (Group Policy Object) you can edit for each OU in which you intend to use MECM to encrypt endpoints. Submit a request with email@example.com if you need blank GPOs.
- GPO editing privileges and the access to the Group Policy Management console for editing the GPOs.
- Create and apply a GPO to force recovery key escrow into Active Directory
- Prepare the TPM for use (enable and activate)
- Ensure the required disk partition exists on the hard drive for BitLocker
- Encrypt and enable BitLocker
Create and apply a GPO
Because the secure recovery key escrow currently identified for BitLocker is Active Directory, a GPO is required to force the escrow process. The GPO (shown below) should then be applied to all workstations in which BitLocker may be enabled.
Prepping the TPM
In order for BitLocker to be able to access the TPM to store encryption secrets, it is required the TPM be enabled and activated. This can be done manually from the BIOS or from within Windows using manufacturer supplied tools. Contained within the examples below are methods to accomplish this within MECM. Because of the number of variables involved, testing is strongly recommended.
During OS deployment, MECM can automate the encryption process using BitLocker. This can be done as the OS data is written to disk (pre-provisioning), or towards the end of the imaging process, similar to the experience of enabling BitLocker on a deployed device (where resident data is encrypted). The difference between the two is that data is encrypted as it is written to storage when using pre-provisioning, saving significant time over the more traditional process of encrypting after the fact.
All example task sequences can be found in Software Library→Operating Systems→Task Sequences→
.DEMO DAYS. You are free to make a copy of the task sequence and customize to suit your needs.
DO NOT DEPLOY THE EXAMPLE TASK SEQUENCES!
An example of encrypting deployed workstations: The "
UIUC-DEMO DAYS In-Place BitLocker" task sequence is a good starting point with encrypting workstations that are out in the field. It demonstrates the general process to prepare the TPM, create the required 300MB partition for BitLocker, and encrypt the device. Remember, in all examples, there is an assumption that you have created the GPO to force recovery key escrow in AD.
To begin testing the task sequence (TS), make a copy by right-clicking the TS and selecting copy. Then right-click the copy and move it to your task sequence folder (right-click, move). Edit the name and anything else as necessary. Right-click the TS and deploy it to a test collection containing some test endpoints. This TS is designed to be deployed to managed endpoints, so be sure to make the deployment available to the client, and you probably want to make it an available deployment so it can manually be executed from software center.
An example of using pre-provisioning can be found in the "
UIUC-DEMO DAYS Deploy Windows 7-8.1 x64" task sequence. This task sequence is probably much more complex than one you use to deploy windows currently but you only need to pay attention to how the Pre-provision BitLocker step appears in the TS. The important thing is for the Pre-Provisioning step to execute somewhere between when the drive is partitioned and when the OS image is applied. Other than that, preparation of the TPM and the enabling of BitLocker are in their usual places before and after OS application respectively. Using the task sequence as-is would likely be overkill. Simply modify your existing TS to perform the pre-provisioning and enabling of BitLocker in a similar way. If you want to automate TPM activation, you could copy the appropriate TS step groups and paste into your TS as necessary.
Compliance and reporting
Encryption state of each drive on individual workstations are visible in the MECM console via the Resource Explorer (right-click→start→resource explorer) and navigating to the BitLocker node within the hardware inventory.
Collections can be created whose membership is based on this attribute. Below is a query that tests if the
C: drive is encrypted. As written it would be used to create a collection of devices where the
C: drive is not encrypted. You can copy the following text and paste it into the collection query editor:
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ENCRYPTABLE_VOLUME on SMS_G_System_ENCRYPTABLE_VOLUME.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ENCRYPTABLE_VOLUME.DriveLetter = "C:" and SMS_G_System_ENCRYPTABLE_VOLUME.ProtectionStatus = 0
Configuration Items\Baselines can also be used to determine compliance. In the MECM console, in Assets and Compliance→Compliance Settings→Configuration Items, there is a configuration item called "BitLocker C: Status (PS)" and another called "BitLocker C: Status (WMI)" that can each check BitLocker status. The one ending in (PS) uses a PowerShell script to check the status of BitLocker on the C: drive, the (WMI) variant uses a simple WMI query to determine the encryption status. There is a tradeoff between the two configurations:
"BitLocker C: Status (PS)"
"BitLocker C: Status (WMI)"
|• allows for a remediation script to force encryption of the
||• doesn’t require any special MECM client setting|
|• but also currently requires the MECM client PS execution policy setting to be set to Bypass (the default is All Signed)||• but doesn’t offer the ability to auto-remediate|
You will need to copy the PS variant and modify it if you wish to add a remediation script.
In either case, you would select which works best for you and use it to create a Configuration Baseline which can then be deployed to your endpoint collections. Example configuration baselines that can be copied are found in Assets and Compliance→Compliance Settings→Configuration Baselines as "BitLocker C: Status Baseline (PS)" or "BitLocker C: Status Baseline (WMI)". Each demonstrates how to use the respective configuration item to check the endpoint for compliance on a set schedule (established during the configuration baseline deployment wizard).
In the example below, you see the "BitLocker C: Status (PS)" compliance baseline deployed to the UIUC-Illini Union Laptops collection. The upper pane shows the status of the configuration baseline, indicating number of endpoints that are compliant, non-compliant, and unable to compute compliance due to a failure. The lower pane (the deployments tab) shows the deployment status of the configuration baseline, indicating the number of targeted endpoints, number of successful evaluations and number of failed evaluations. It is important to note that it is showing endpoints where the configuration baseline successfully evaluated compliance, not the result of that evaluation. By right-clicking on the deployment and selecting "View Status" the MECM console shows a breakdown of the deployment.