We experienced a similar issue with Surface Pro 4 + Winmagic SecureDoc using bitlocker encryption as well.
As a workaround, I just decrypt / disable encryption and reboot using the commands below. You should be able to install your Mcafee MDE (w/ bitlocker) afterwards without issue.
1. Open a command prompt as administrator.
2. run: manage-bde -status
It will probably say something is encrypted...
3. run: manage-bde -off c:
It will decrypt the drive pretty quick and you can its check status using the first command. Once complete I would reboot for good measure and try to install normally.
Wow! I can't believe it was this simple. I'm adding a step in provisioning to do this so that we can have McAfee install normally at the end. Thank you and I will report back as soon as I definitively know whether this worked or not.
OK I created a simple batch file to run the command in provisioning right after it boots into windows and after the provisioning agent is installed. It doesn't seem to run in that context but if I just run it manually right there it seems to work. Do you have any idea why it doesn't seem to like the command being executed by provisioning?
Most likely because it is being run as SYSTEM (we have several batch scripts that we cannot do in an "execute file" method). Your only options are to package it and use "Distribute Software" specifically stating a user to run as (which is not an ideal scenario), or fix your reference machine.
What type method are you using to deploy your reference images? ImageW, Semantic, or ImageX? I don't know about the Semantic portion, but ImageW captures the entirety of the virtual hard drive (including boot sectors).
We use ImageX, for the simple fact that it ONLY captures the Windows partition - and because of this, we are able to deploy the same image to either EFI or BIOS machines, and our reference VM is set in Legacy BIOS.
We also use MDE, and have successfully deployed hundreds of Surface Pro 4's without bitlocker ever being present to begin with; don't have to fix what doesn't appear.
Action Type: Partition → Create Default Partitions
Action Type: Deploy Image → ImageX → /apply \\path\to\reference\image.wim 1 C:
Action Type: Execute File → Target: bcdboot.exe → Parameters: C:\Windows /s S:
If you're using something else, reach out and I'd be happy to assist in any way I can.
I just tried running it as "current user" as a distribute software step in provisioning, before I did have it as localsystem. That didn't seem to make a difference.
I am using ImageX and performing the apply steps exactly as you are listing them there, although I wasn't aware that you didn't have to build the .wim for EFI on an EFI system, that is good to know.
I'm curious as to how your MDE is deploying to a Surface Pro 4 because the BDE, while not activated, does show the drive as encrypted and from what my McAfee engineer tells me, MDE will not deploy to the machine and install/activate if it sees a competing encryption on the device.
I really appreciate everyone's assistance with this and hopefully can have this figured out very soon.
I had this same issue as we use Symantic drive encryption. It looks like Windows 10 anniversary edition (1607) automatically enables Bitlocker when TPM is detected. The initial Windows 10 release did not do this.
Disable TPM in the BIOS before the machine is imaged and Bitlocker will not automatically enable thus allowing other drive encryption tools to work.
Kenyon, do you know if re-enabling TPM after fact will re-engage the encryption process? This might be the right path because running that command in provisioning doesn't seem to work any way I've tried. I'm going to do some testing around this and report back.
If the drive is encrypted with McAfee, I don't believe that Bitlocker will be able to activate. So I don't believe that re-enabling TPM will re-engage Bitlocker. I didn't bother to re-enable TPM afterward because Symantec does not take advantage of it.
This could be the key takeaway: TPM. We always leave it disabled in our environment. As a side note, it appears as if you can enable TPM via the command line with manage-bde: Manage-bde: tpm
Not that this will help in automation; it's essentially the same thing that you're doing now, just a different switch. Still, at least that saves you a reboot into the UEFI firmware.
This is the solution it seems, working perfectly now with TPM turned off. Thank you all for the help on this.