question

SkipB-0659 avatar image
0 Votes"
SkipB-0659 asked SkipB-0659 answered

MDT task sequence mysterious thinks it's Refresh type

I am having a problem with certain Lenovo models where BitLocker fails to enable during OSD with MDT. I get error:

FAILURE ( 6767 ): -2144272340 0x8031002C: Enable BDE Protectors

I can enable BitLocker manually just fine after OSD has completed.

When I compare the ZTIBDE.log's from a device that failed to one that succeeded, I see the following in the failure's log:

"This is a Refresh Build where BDE protectors were disabled."

It looks like the EnableBitLocker step tries to unsuspend BitLocker instead of enabling it for the first time.

I cannot figure out why the task sequence thinks it's a Refresh deployment at that point. Just 3 seconds before the failure message from trying to enable BitLocker, I see this in the BDD.log:

DeploymentType = NEWCOMPUTER

Nowhere do I see DeploymentType = REFRESH. Why would the task sequence suddenly think it's a Refresh type?

It's MDT 8456. Win10 1909. The 3 models that fail: Lenovo L480, L490, X1 Yoga Gen 5. The BIOSes are the latest from the vendor.

Skip

mem-mdt
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SkipB-0659 avatar image
0 Votes"
SkipB-0659 answered

The problem seems to be BitLocker automatic device encryption. I added a step to my task sequence in MDT to modify the registry to disable it. See:

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker

The step had to be placed after the Copy Scripts step in the PostInstall phase.

Skip

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SkipB-0659 avatar image
0 Votes"
SkipB-0659 answered

Thanks for the reply. It got me going in the right direction.

What I have found is that the ZTIGather script is finding that the drive is already encrypted and setting the IsBDE variable to TRUE. That variable is parsed by ZTIBDE. Thusly ZTIBDE simply tries to unsuspend BL instead of enabling it for the first time.

The ZTIGather log shows the following when there's a failure to enable BL in the task sequence:
Encrypted drive found: C:, status = 1
Encrypted drive found: C:, status = 1
Encrypted drive found: C:, status = 1
Encrypted drive found: C:, status = 2

When BL is successfully encrypted in the task sequence, it shows:
Encrypted drive found: C:, status = -1
Encrypted drive found: C:, status = -1
Encrypted drive found: C:, status = -1
There are no encrypted drives

I am still trying to find out what the status codes mean. I wonder if certain models/hard drives have an auto encrypt feature of some kind.

Skip

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

XinGuo-MSFT avatar image
0 Votes"
XinGuo-MSFT answered

Hi,

Why would the task sequence suddenly think it's a Refresh type?

For ZTI, this property is set dynamically by MDT scripts and is not configured in CustomSettings.ini.

128207-capture.png

https://docs.microsoft.com/en-us/mem/configmgr/mdt/toolkit-reference#DeploymentType



capture.png (4.0 KiB)
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.