Share via

NEW: Upgrade to Windows 10 1803 without suspending BitLocker

  • Article

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 /BitLocker AlwaysSuspend 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 /BitLocker TryKeepActive with Insider Preview devices (well, at least for mine).  So how do we change it to TryKeepAlive?  It depends:

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?)

Comments

  • Anonymous
    May 03, 2018
    "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.)" Did you mean the entire user profile folder or just the locations of folders such as Documents, Pictures, etc.? Please elaborate.
    • Anonymous
      May 03, 2018
      The entire folder (e.g. C:\Users). Redirecting folders should be fine.