So for the last couple of weeks, I have been battling deploying the Creators Update (1703) to several machines using the Windows Servicing componet of ConfigMgr. What would occur is the update would download and execute as expected. After about 15 minutes of it doing its job in the background (compat checks, setting up the SafeOS, NewOS, DISMing drivers, staging boot images, etc.) it suspends BitLocker before triggering a reboot. This is right at the end of the pre-reboot phase. If no user is logged in, the machine reboots immediately and the update process continues.
Now let's assume a user is logged in. Maybe they are working, or maybe they just left it locked before they went home. The ConfigMgr client will prompt for a reboot (as expected), the provide a 120 minute delay. This is where we hit a snag. Since we are using a 3rd party tool to manage BitLocker, the policy will refresh and re-enable BitLocker before the device reboots. This causes the machine to boot to the "Choose a Keyboard Language" screen. Once you choose your language and select continue, it boots back into (in this case) 1607. Good job on the recovery piece MS, but now what? Since there are limited options for configuration on the Servicing side within ConfigMgr, we are left to completely disable our 3rd party policy during the time it takes machines to update. We have reached out to our vendor, but I'm sure they haven't ran into this as it is a new process. I'm also sure they won't have a solution.
With that being said, are there others out there experiencing the same thing? We are submitting a feature request with MS to add a BitLocker check at reboot execution, but we will see where that goes.
Signed, Misery looking for company.
