First published on TechNet on May 02, 2018
One of the new features mentioned in the
What’s new in Windows 10 1803 documentation
is a new ability to perform a feature update without suspending BitLocker. This is what it says:
New command-line switches are also available to control BitLocker:
Setup.exe /BitLocker AlwaysSuspend
– Always suspend bitlocker during upgrade.
Setup.exe /BitLocker TryKeepActive
– Enable upgrade without suspending bitlocker but if upgrade, does not work then suspend bitlocker and complete the upgrade.
Setup.exe /BitLocker ForceKeepActive
– Enable upgrade without suspending bitlocker, but if upgrade does not work, fail the upgrade.
For more information, see
Windows Setup Command-Line Options
And if you look at the
Windows Setup Command-Line Options
page, it confirms the same thing: there are new command line options that affect how BitLocker is handled during feature updates. Let’s dig a little deeper though to understand the requirements. In order to successfully use this feature, the device needs to meet the following requirements:
It needs to be running Windows 10 1709 or higher, and needs to upgrade to Windows 10 1803 or higher. (So this is a “going forward” change, not one that goes back into the Windows 10 stone ages.)
The Windows device needs to be using Secure Boot and have a TPM.
BitLocker needs to be using a TPM protector only (yet another good reason to not have a PIN).
The user profile folder can’t be on a separate volume that is also BitLocker protected. (If you are doing something like this, we really need to talk.)
You could add a command line option (through a ConfigMgr task sequence variable, MDT script edit, SetupConfig.ini file, etc.) to explicitly make your choice, but if you don’t, what’s the default? The easiest way to find out (since the documentation doesn’t say) is to try it. First, let’s look at a device that was updated from Windows Update. The SETUPACT.LOG clearly shows the default behavior:
2018-05-01 19:36:53, Info SP Client requested to suspend BitLocker unconditionally
Now, a second device updated using media (SETUP.EXE /AUTO UPGRADE):
2018-05-01 19:22:27, Info SP Client requested to suspend BitLocker unconditionally
OK, also off, so both mechanisms (servicing and media) are acting like /BitLocker AlwaysSuspend was specified, so that’s the default (at this point at least, that could change in the future). Interestingly, if you have a device that is enrolled in Insider Preview, you might see a different default as new Insider builds are installed. I can see that TryKeepActive is the default for my Insider laptop:
2018-04-19 15:28:08, Info MOUPG SetupManager: No BitLocker command line option specified, will try to keep active but suspend on errors, because this is a WU scenario
2018-04-19 15:28:08, Info MOUPG ImageDeploy: Initializing BitLocker Mode: [Keep Active (Best-Effort)]
2018-04-19 15:28:15, Info SP CNewSystem::PreInitialize: Velocity feature state for BitLocker auto-unlock is enabled
2018-04-19 15:28:15, Info SP Client requested to keep BitLocker active on a best-effort basis, and the device supports it. Will try to keep BitLocker on, and fall back if needed.
(That’s the cool thing about Insider Preview, you can be trying out new features that are behind the scenes without really even being aware of them.)
Alright, so we’ve established that the default is presently
for both servicing (WU, WUfB, WSUS, ConfigMgr Windows 10 Servicing) and media-based (SETUP.EXE, ConfigMgr task sequence, MDT task sequence) upgrades, while the default is
with Insider Preview devices (well, at least for mine). So how do we change it to TryKeepAlive? It depends:
For ConfigMgr task sequences, add a step to set variable
For MDT, edit the LTIApply.wsf script, changing this line:
sCmd = sCmd & " /compat IgnoreWarning"
to instead be:
sCmd = sCmd & " /compat IgnoreWarning
For servicing-based approaches (WU, WUfB, WSUS, ConfigMgr Windows 10 Servicing), create a SetupConfig.ini file (roughly as described at
), with a line that specifies:
Of course only make those edits/changes if you are upgrading exclusively to Windows 10 1803, since earlier versions of SETUP will have no idea what to do with that command line switch and will most definitely fail. (But hey, we’re all upgrading to 1803 now, right?)