C
Crking
Hi
I have encountered unexpected behavior with Bitlocker since cumulative update (CU) KB4100403 in June.
The machine is running Windows 10 Pro, 1803. The machine has no TPM, and Bitlocker is set up to use a password prior to logging in.
I noticed that since mid-June, Bitlocker is automatically suspended on my operating system drive during Cumulative Updates. Once the update has completed and I log in, Bitlocker is suspended and must either be manually resumed or will automatically resume once I manually restart the system. manage-bde shows the drive status as:
Volume C: [System]
[OS Volume]
Size: 59.07 GB
BitLocker Version: 2.0
Conversion Status: Fully Encrypted
Percentage Encrypted: 100.0%
Encryption Method: XTS-AES 128
Protection Status: Protection Off (1 reboots left) <-------------------
Lock Status: Unlocked
Identification Field: Unknown
Key Protectors:
Password
Numerical Password
The problem here is that Bitlocker should not be suspended unless user-initiated as this creates a security issue. Now I am aware of the following blog post relating to changes made to Bitlocker in 1803: NEW: Upgrade to Windows 10 1803 without suspending BitLocker. I have asked about this issue elsewhere have been pointed to this blog post, however it doesn't apply to my situation as (1) it applies only to Feature Updates, not the Cumulative Updates I am dealing with; and (2) it only applies to machines that have a TPM - mine does not.
Looking at the Bitlocker event logs, each time Bitlocker is suspended, the event shows the action initiated by the system account, and each time it correlates with a CU installed in Windows Update.
To get to the bottom of this, I have tried:
(1) To eliminate issues related to software I've installed, I tried a fresh install of 1803 English International from my original ISO, only changed the GPO to allow Bitlocker without TPM, let Bitlocker encrypt, then applied all Windows updates (including the latest CU). On reboot, Bitlocker was suspended.
(2) To eliminate issues related to my ISO, I used the media creation tool to make a new USB installer of 1803 US English. Then followed the same process as (1). On reboot, Bitlocker was suspended.
(3) To attempt to eliminate as many hardware issues as possible, I set up a VirtualBox VM (without VM extensions or tools) and installed 1803 from my original ISO. Then followed the same process as (1). On reboot, Bitlocker was suspended.
Has anyone else encountered this? Is this expected behavior since KB4100403, and if so, does anyone know why?
Thanks
Continue reading...
I have encountered unexpected behavior with Bitlocker since cumulative update (CU) KB4100403 in June.
The machine is running Windows 10 Pro, 1803. The machine has no TPM, and Bitlocker is set up to use a password prior to logging in.
I noticed that since mid-June, Bitlocker is automatically suspended on my operating system drive during Cumulative Updates. Once the update has completed and I log in, Bitlocker is suspended and must either be manually resumed or will automatically resume once I manually restart the system. manage-bde shows the drive status as:
Volume C: [System]
[OS Volume]
Size: 59.07 GB
BitLocker Version: 2.0
Conversion Status: Fully Encrypted
Percentage Encrypted: 100.0%
Encryption Method: XTS-AES 128
Protection Status: Protection Off (1 reboots left) <-------------------
Lock Status: Unlocked
Identification Field: Unknown
Key Protectors:
Password
Numerical Password
The problem here is that Bitlocker should not be suspended unless user-initiated as this creates a security issue. Now I am aware of the following blog post relating to changes made to Bitlocker in 1803: NEW: Upgrade to Windows 10 1803 without suspending BitLocker. I have asked about this issue elsewhere have been pointed to this blog post, however it doesn't apply to my situation as (1) it applies only to Feature Updates, not the Cumulative Updates I am dealing with; and (2) it only applies to machines that have a TPM - mine does not.
Looking at the Bitlocker event logs, each time Bitlocker is suspended, the event shows the action initiated by the system account, and each time it correlates with a CU installed in Windows Update.
To get to the bottom of this, I have tried:
(1) To eliminate issues related to software I've installed, I tried a fresh install of 1803 English International from my original ISO, only changed the GPO to allow Bitlocker without TPM, let Bitlocker encrypt, then applied all Windows updates (including the latest CU). On reboot, Bitlocker was suspended.
(2) To eliminate issues related to my ISO, I used the media creation tool to make a new USB installer of 1803 US English. Then followed the same process as (1). On reboot, Bitlocker was suspended.
(3) To attempt to eliminate as many hardware issues as possible, I set up a VirtualBox VM (without VM extensions or tools) and installed 1803 from my original ISO. Then followed the same process as (1). On reboot, Bitlocker was suspended.
Has anyone else encountered this? Is this expected behavior since KB4100403, and if so, does anyone know why?
Thanks
Continue reading...