Share via

MDT task sequence mysterious thinks it's Refresh type

Skip B 91 Reputation points
2021-08-31T15:36:47.48+00:00

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

Microsoft Deployment Toolkit
Microsoft Deployment Toolkit
A collection of Microsoft tools and documentation for automating desktop and server deployment. Previously known as Microsoft Solution Accelerator for Business Desktop Deployment (BDD).
859 questions
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. XinGuo-MSFT 16,246 Reputation points
    2021-09-01T07:54:44.223+00:00

    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://learn.microsoft.com/en-us/mem/configmgr/mdt/toolkit-reference#DeploymentType

    0 comments
  2. Skip B 91 Reputation points
    2021-09-01T18:27:24.593+00:00

    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

    0 comments
  3. Skip B 91 Reputation points
    2021-09-08T19:11:11.913+00:00

    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://learn.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

    0 comments