Windows update catalog kb4457128 update#
The only wrong, but somehow understandable place for suspending to happen should be immediately before forcibly rebooting at update time to get system to running state again. When the update had finished without any further reboot request the bitlocker was left suspended without any prompt. When rebooting after prompt the bitlocker was not suspended and the password was asked correctly. Exactly this happened with the latest "August 30, 2018-KB4346783 (OS Build 17134.254) Applies to:
The biggest problem is that "illegal suspending" happens "after" the reboot and "after" the update is already fully installed. I have had this bitlocker suspended problem for quite long time now. I have no TPM password protected system drive as well.
Windows update catalog kb4457128 install#
Perhaps I'll blow away the current install back to 1803 release and see if applying the current CU immediately replicates the behaviour. No scripts running to manage the updates. Bitlocker suspending automatically during a CU on a system without TPM and only a password protector, so Microsoft's own article for the changes introduced during 1803+ upgrades does not apply.ģ.
Bitlocker suspending automatically during CU's which you say is impossible, but the logs say otherwise.Ģ. This is a machine that is not joined to our domain and all the updates are user-managed.ġ. : Cumulative update KB4284848 installed log shows bitlocker suspended by system account.ģ. : Cumulative update KB428435 installed log shows bitlocker suspended by system account. : Cumulative update KB1410043 installed log shows bitlocker suspended by system account. I can't post images here, but this is the correlation between the Windows Update history and the Bitlocker
But that aside, the issue I'm having is definitely with cumulative updates. Feature upgrades should only suspend Bitlocker on systems with a TPM. Thanks for your reply Ronald, but if things made sense I wouldn't be posting here.ġ.
0 kommentar(er)
