Windows 7 SCCM 16 Pre-Provision Bitlocker winload.exe 0xc0210000 error

Last monday we upgraded our SCCM environment from 2012R2 to 1610. Earlier we did the same upgrade in our test environment and didn’t have any problems at all. Unfortunately, our test environment only has one active laptop, and we never thought to test the task sequence on this laptop.

After the production upgrade we found that all task sequences worked without issues, except for our laptops: after the step “Pre-Provision Bitlocker” our windows image is loaded and windows setup should start, only it doesn’t. It throws an error saying something like this:

The operating system couldn’t be loaded because the Bitlocker key required to unlock the volume wasn’t loaded correctly.

Being a lazy admin, I googled the symptoms and of course I wasn’t the first one to get this error. In short, with the upgrade of SCCM we also upgraded ADK from 8.1 to 10. Since ADK10, Microsoft has increased the default encryption level that’s used for bitlocker. Since Windows 7 does not support this level, the setup fails.

Probably the best write-up about this issue can be found on the Configuration Manager OSD Support Team Blog.

You will find that the resolution seems simple: add a registry key just before the Pre-Provision Bitlocker step, and the encryption level should be compatible with Windows 7. Of course this didn’t work. Well it did, but created another problem. The error message disappeared, but now we cancelled the Windows setup after a couple of hours, as it was still installing devices.

The encryption method that is recommended by the blogpost mentioned earlier, is AES_128, set by the following command:

reg.exe add HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 3 /f

I found an article, closed it and forgot where it was, but I found a reference somewhere that for Windows 7, the default encryption level was AES_128_WITH_DIFFUSER, which registry value is 1. So we tried that and lo and behold: it works.

So if you’re experiencing these issues and tried the value of 3, try a value of 1. Or upgrade to Windows 10 CB.

We used this:
reg.exe add HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 1 /f

VMWare Horizon View Client: Disable Client Drive Redirection


[HKEY_LOCAL_MACHINE\Software\Policies\VMware, Inc.\VMware VDM\Client]

VMWare has been tinkering with the name, version, function and anything other they can come up with for a while now. For example, we’ve upgraded the VMWare View Client version 5.x to VMWare Horizon Client 4.3.0 recently, i think. I get that the name “view” is disappearing from the product, but why they are **** around with versionnumbers is beyond me.

Anyway, since VMWare Horizon View 6.x the function “Client Drive Redirection” has been added, which lets you redirect local client drives and folders to your View/Horizon/whatever session. This function, frankly, is useless and I don’t want it. We use a UPM tool (RES) to map networkdrives and have USB redirection enabled. Client Drive Redirection only presents a security risk, as it seems to ignore drive restriction policies. For example, by default, the View client on our thin clients shows the “share drive” option, giving the user access to the local drive of the thinclient that they are using. They can’t do real damage because of the write-filter ofcourse, but I just dont want it.

Since the 4.x clients for VMWare Horizon. (which has VMWare-view.exe as executable.. thanks VMWare), it seems that we’ve lost all control of which components we can install: Client Drive Redirection becomes mandatory.

Searching the net, i’ve found the following registry setting: HKLM\Software\VMware, Inc.\VMware TSDR\disabled=true

Unfortunately, this seems to be an agent setting, which doesn’t remove the sharing option from the client itself.

Fortunatly, since client version 4.3.0, the people at VMWare have seen fit to supply us with an option to disable the whole option. See table 3-7 of “Using VMware Horizon Client for Windows Horizon Client 4.3”

If you open the PDF, you will find the mention of “Disable sharing files and folders” in table 3-7, and also see that this is a “User Configuration setting”.

Well, **** VMWare.

First of all, i’m configuring thin clients, which won’t be member of our Active Directory domain, so AD GPO’s are out.
Local Group policy would work, but cannot be configured programmatically, from for example, a SCCM or MDT task sequence.

As a test i’ve enabled the policy on a testing system, and found that the following registry keys and values had been created:

[HKEY_CURRENT_USER\Software\Policies\VMware, Inc.\VMware VDM\Client]

Because i’m stubborn, i tried creating the same keys and values on a system that doesn’t have the ADM-templates loaded, and also, changed HKCU to HKLM, and what do you know: IT WORKS.

So, if you are like me and only need a simple registry setting for the local machine, put the following in your installscript, and go enjoy the weekend:

[HKEY_LOCAL_MACHINE\Software\Policies\VMware, Inc.\VMware VDM\Client]

Powershell: Force full update of Root CA store

By default, Windows comes only with a small set of Root CA’s in the trusted Root CA store. These are enough to get you started, but as soon as you visit a website that uses HTTPS and the Root CA that has issued the certificate is not in your trusted Root CA list, the Root CA certificate is downloaded from Windows Update.

Generally, this is a good solution, as long as your clients can reach Windows Update to start with and they aren’t non-persistent VDI clients.

Currently, we are noticing that Internet Explorer sometimes hangs for a few seconds and then continues. At the same time, an event is logged ( CAPI2 4097 ) telling you that the Root CA has been updated. Again, this works fine on persitent VDI’s, laptops, desktops and servers. On a non-persistent VDI however, this process is repeated for every CA on every session for every user. Not so nice.

Currently, we are still testing what yields the best results. I’ve written the script below, which creates a directory on the C:\ disk, downloads all root CA’s from Windows Update into this directory and then imports every .crt in the Root CA store, then removes the directory. I’ve imported this script into RES Workspace and is being run during logon. As it’s run in the background there is no noticable delay in logon time, and after logon, about 380 CA’s (we have some internal and private CA’s added as well) are visible in the certificate manager.

You could consider adding this as a step in your SCCM task sequence or however you create your VDI image, so it’s not performed during logon. However, this means that CA’s that are added later will have to be downloaded on demand, and also CA’s that are revoked or updated after you’ve made your image will have to be updated on demand as well.

md C:\Certs
certutil -syncwithWU C:\Certs
$files = Get-ChildItem -Path 'C:\certs\*' -Include '*.crt'
Foreach ($file in $files) {
$importfile = "$file"
certutil -addstore -f Root "$importfile"
write-host $importfile
rd c:\certs -Recurse

Update: Oh yea! As you can see, i’m using Certutil to import the certificates. That’s because my current customer is still running Windows 7. When you’re on Windows 8/2012 and higher, you should ofcourse use the PS commandlet “Import-Certificate”, together with the appropriate config ofcourse.

Powershell: Check and Toggle Numlock during logon

This is one that comes up anywhere, especially in VDI/RDS-type environments: Numlock.

In my experience there are no real good ways of controlling this without scripts, too many variables, as the final state of numlock depends on the state on the client computer, the VM and whatever settings are in the user profile.

The powershell script below first checks for the state of the numlock key: If ([console]::NumberLock -eq $False), and when False, proceeds to send the command to toggle it, turning it on.


If ([console]::NumberLock -eq $False) {
$wsh = New-Object -ComObject WScript.Shell

Windows Driver Installation: Searching Windows Update..

PolicyBy default, when you plug in a USB device, Windows will search Windows Update for the latest drivers. While this might be a fantastic solution for your home computer, it’s useless in an organization, because usually Windows Update is blocked so it will sit for about 5 minutes searching, until it times out and uses the locally available driver or tell you that you need to go get some drivers yourself.

So, lazy admin as you are, you fire up Google, and find a policy:

Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings\Turn off Windows Update device driver searching.

Well.. wrong. This policy has been deprecated and will only work up to Vista. For some reason the new policy has had very little coverage on the web, so it took some time to find it.

The new policy, which you should use with Windows 7 or later, can be found at:

Computer Configuration\Administrative Templates\System\Device Installation\Specify Search Order for device driver source locations

Select the option “Do not search Windows Update” and you’re gold.

First of many: excellent SCCM Variables

Every now and then you think “wouldn’t that be a nice feature”. You fire up Google, spend some time browsing the net, end up looking at pictures of kittens and then finally somewhere deep down an archived website build in the late nineties you find what you’re looking for.

These are two features that I needed when working on SCCM task sequences. My first problem was that we had some tasks that couldn’t be part of the task sequence it self, but had to be available immediately after running the task sequence. The folks at Microsoft thought about this, and created the SMSTSPostAction variable. I won’t bore you with the actual implementation of the variable, so here’s the short version: define the variable at your favorite place (somewhere in the TS itself or as a variable on your collection), set the value to be the task that you want to be processed at the end of the TS. For example, “gpupdate /force /boot” or “c:/temp/postosdscripts.bat”. After running a deployment, you will see in your SMSTS.log that your value is the last task that is executed. This occurs after the SCCM client has been taken out of provisioning mode.

My second problem was.. well, forgetful onsite support colleagues. Every once in a while, your SCCM deployment will fail. An error message is displayed for 15 minutes after which the system will reboot and, depending on where it fails, will show a CTRL+ALT+DEL login screen. This might be just the old OS in case of preinstalled systems or redeployments, or the new OS without the rest of your TS. Originally, we tried to solve this issue by setting the background of the computer to “Deployment Successful” when it was successful. The onsite support guys know this, but still occasionally give uses a half-deployed system and then complain that OSD isn’t working as it should. So, to fix this, I decided that the task sequence error message should stay indefinitely. Again, there’s a TS variable for that! SMSTSErrorDialogTimeout. Again, add this to your deployment and decide on your value. 0 is forever(-enough), the rest is the time in seconds. Personally, I cannot think of a reason the error message should ever disappear without user interaction, but that might be me.

Any additions?

A different approach

While this has always been my personal page, I’ve found that I’m not really using it at all. So, in the interest of things, I’ve decided to use this site as a kind of professional “short-blog”. I don’t know if a short-blog is really a thing, but I’ve also decided that it is, starting now.

By short-blog I mean that I will occasionally post short findings, solutions and random things that I find during my day-to-day work. No in-depth deep dives into boring matters, but just “hey, i had this problem and i fixed it like this”.