Suspend bitlocker windows 10#
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. So how do we change it to TryKeepAlive? It depends:įor ConfigMgr task sequences, add a step to set variableįor MDT, edit the f script, changing this line:įor servicing-based approaches (WU, WUfB, WSUS, ConfigMgr Windows 10 Servicing), create a SetupConfig.ini file (roughly as described at With Insider Preview devices (well, at least for mine). (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.)Īlright, so we’ve established that the default is presentlyįor 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 Will try to keep BitLocker on, and fall back if needed. 15:28:15, Info SP Client requested to keep BitLocker active on a best-effort basis, and the device supports it. 15:28:15, Info SP CNewSystem::PreInitialize: Velocity feature state for BitLocker auto-unlock is enabled 15:28:08, Info MOUPG ImageDeploy: Initializing BitLocker Mode: 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 I can see that TryKeepActive is the default for my Insider laptop: Interestingly, if you have a device that is enrolled in Insider Preview, you might see a different default as new Insider builds are installed. 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). 19:22:27, Info SP Client requested to suspend BitLocker unconditionally Now, a second device updated using media (SETUP.EXE /AUTO UPGRADE): 19:36:53, Info SP Client requested to suspend BitLocker unconditionally The SETUPACT.LOG clearly shows the default behavior: First, let’s look at a device that was updated from Windows Update. 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. (If you are doing something like this, we really need to talk.) The user profile folder can’t be on a separate volume that is also BitLocker protected. The Windows device needs to be using Secure Boot and have a TPM.īitLocker needs to be using a TPM protector only (yet another good reason to not have a PIN). (So this is a “going forward” change, not one that goes back into the Windows 10 stone ages.)
Suspend bitlocker upgrade#
It needs to be running Windor higher, and needs to upgrade to Windor higher. In order to successfully use this feature, the device needs to meet the following requirements: Let’s dig a little deeper though to understand the requirements. Page, it confirms the same thing: there are new command line options that affect how BitLocker is handled during feature updates.
– Enable upgrade without suspending bitlocker, but if upgrade does not work, fail the upgrade. – Enable upgrade without suspending bitlocker but if upgrade, does not work then suspend bitlocker and complete the upgrade. – Always suspend bitlocker during upgrade. New command-line switches are also available to control BitLocker:
Suspend bitlocker update#
Is a new ability to perform a feature update without suspending BitLocker. First published on TechNet on May 02, 2018
0 kommentar(er)
