[German]Brief note for administrators and users of Windows 10 Version 1803 in enterprise environment using Bitlocker encryption. Microsoft plans to fix the Bitlocker bug, which deactivates the function during update installation, with a patch scheduled for November 2018.
Advertising
What's the Bitlocker Bug?
If you are not up to date (I for instance also had to check my blog for details): There is the problem that Bitlocker pauses during update installation if there is no TPM chip on the machine. I blogged about that within my article Windows 10 V1709/1803: Issues (also August Patchday) in August 2017.
The bug is described in the Technet forum and applies to machines with Windows 10 version 1803 that do not have a TPM module. If the hard disk encryption with Bitlocker is activated, Windows deactivates it during the installation of an update. Here is the description:
I have a machine with Bitlocker enabled, no TPM, Windows 10 1803.
For the last month or so, whenever a Windows system update is applied, Bitlocker is automatically suspended upon first login after the machine restarts. Case in point: the latest Windows 10 cumulative update was applied this morning, only for the machine to restart with Bitlocker suspended on the OS drive. Interestingly, there is also some dubious behaviour in terms of the initial Bitlocker password entry screen. Not having a TPM, the user must enter a password to boot. On at least 2 occasions, after applying an update, the system does not present the Bitlocker password entry screen and progresses all the way to the user login screen. However, this morning the Bitlocker password entry screen was presented correctly but after entering the correct password and then logging in to Windows, Bitlocker was suspended.
This is the state of the OS drive after logging in:
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 PasswordNow, I realise that Bitlocker is temporarily suspended – restarting the machine again will enable it without any action from the user. However, this is a security risk for the time between restarting after an update and the next restart and severely undermines our trust in Bitlocker. I would expect that Bitlocker should NEVER be suspended unless initiated by a user/admin.
If the machine is restarted again, Bitlocker will be activated again. So if people install updates and put the machine into sleep mode, Bitlocker may remain disabled for a long time. The bug only occurs on Windows 10 V1803 machines without a TMP chip.
Microsoft plans a bug fix for November 2018
I haven't followed the progress, but affected users hoped that Microsoft would roll out a fix per update in September 2018. But that didn't happen, as user andadok notes in the Technet thread. There is then a hint to deactivate Bitlocker temporarily before each update and to activate it again after the update installation. Susan Bradley, who follows the thread, now points to Twitter.
btw the bug whereby bitlocker with a password needs reactivation after patching in 1803 has been identified and will be fixed in November. Kudos to Chad Z. Hower for the assist with the bug.
— SBSDiva (@SBSDiva) 17. September 2018
Advertising
So if someone should be affected: Just keep it in mind – although the problem should be eaten in 30 months anyway. The updated Bitlocker documentation can be found here.
Similar articles
Windows 10 V1803: Custom login/lock screen image won't show, until user login
Windows 10 V1803: Issues with Cisco Anyconnect VPN
Windows 10 V1803 rollout stopped due to TLS 1.2 issues
Windows 10 V1803: Update KB4458166 fixes TLS 1.2 issue
Windows 10 V1803: Easy Document Creator scan bug fixed
Windows 10 V1803: Backup fails with 0x800706BA
Windows 10 V1803: Domain join bug and a workaround
Windows 10 V1803 fixes old (black screen) display bugs
Windows 10 V1803 detects internal SATA drives as removable
Windows 10 V1803: Roaming profile not fully synchronized
Windows 10 Pro V1803: SMBv1 'special traps'
Windows 10 V1803: HCVI causes driver error code 39
