Transferring laptop to another user

Yes, sounds as if TPM is in "lockout" and requires clearing. This will affect the setting of a new PIN as you've seen - it's not applying properly as the TPM isn't in a fit state. This often happens when the wrong PIN is used repeatedly. 

I would also check BIOS mode. If it's in legacy/CSM and not in UEFI you may find that the laptop can't integrate with TPM properly. I'd also check that the TPM firmware is up to date - many can be upgraded to TPM2.0. 

Personally we encourage all to reformat/wipe the laptop before it's passed to another user. You may wish to remove the hostname entry from AD too if you're going to rebuild it with the same hostname. The recovery key generated will not be the same as the old one. You'll not need to remove any keys/certs (and I wouldn't just in case you need to try and recover their data further down the road) as the new user will have their own keys/certs etc..

Dependant on how many and how frequently you build /re-build laptops - I personally like to confirm that we DO have a recovery key within the console and that the client is actively reporting back to the console. If you include a policy within the configuration file, it is possible to start encryption before communication (and therefore sending the key) has taken place. Not normally an issue if this happens soon after, but i don;t have an encryption policy within my configuration for this very reason. Once the client communicates with the server the encryption starts - This way I know the comms are working and I WILL have the RK on the server (s)

Hope this helps?

Michael

Yes, sounds as if TPM is in "lockout" and requires clearing. This will affect the setting of a new PIN as you've seen - it's not applying properly as the TPM isn't in a fit state. This often happens when the wrong PIN is used repeatedly. 

I would also check BIOS mode. If it's in legacy/CSM and not in UEFI you may find that the laptop can't integrate with TPM properly. I'd also check that the TPM firmware is up to date - many can be upgraded to TPM2.0. 

Personally we encourage all to reformat/wipe the laptop before it's passed to another user. You may wish to remove the hostname entry from AD too if you're going to rebuild it with the same hostname. The recovery key generated will not be the same as the old one. You'll not need to remove any keys/certs (and I wouldn't just in case you need to try and recover their data further down the road) as the new user will have their own keys/certs etc..

Dependant on how many and how frequently you build /re-build laptops - I personally like to confirm that we DO have a recovery key within the console and that the client is actively reporting back to the console. If you include a policy within the configuration file, it is possible to start encryption before communication (and therefore sending the key) has taken place. Not normally an issue if this happens soon after, but i don;t have an encryption policy within my configuration for this very reason. Once the client communicates with the server the encryption starts - This way I know the comms are working and I WILL have the RK on the server (s)

Hope this helps?

Michael

Hi Michael

Thanks for this, I tried clearing the TPM from within the BIOS. I also made sure it is running TPM2.0. So, within the BIOS it has been cleared and within Windows using tpm.msc it has been cleared. But when I log back into Windows and set a PIN (using numeric keys only) it restarts but does not come up with the Bitlocker login. It also still says "The PIN you entered in the Bitlocker Authentication screen did not match the PIN set earlier. Please set a new PIN and remember that Bitlocker only supports EN-US keyboard layout". 

I thought all PINs would have been cleared so I don't know where it is now looking?

Thanks

Ric

Hi Ric Turner 

I got your issue here. The issue is related to Intel PTT (Intel (R) Platform Trusted Technology with TPM 2.0 mode) Security Chip. It will happen even you'll try to enable the encryption manually.

Please refer to this article which has steps provided to change the security chip selection.

Hi Ric. Thanks for the update. It does sound as I mentioned that BIOS is not in UEFI configuration and this marries up with what Jasmin posted too.

So either her suggested workaround or put the BIOS IN UEFI mode.

All the best

Hi Jasmin. I followed the instructions on the HP website to disable the Intel SGX feature and clear TPM on next boot. Saved and exited and it asked me to confirm and type in a code for verification. Did that, booted up, logged in and set a PIN, rebooted but the Pre boot Authentication still did not come up and it booted back to Windows upon where I got the same Bitlocker error message. Stuck at what else I can try now?

Thanks

Ric

Best to switch to UEFI if possible Ric? Jasmin's solution is a workaround really rather than a fix?

Hi Ric Turner 

Michael is correct. The best solution is to switch to UEFI. That is the only solution available now for your issue.

But if I do that then I will need to re-image the laptop? And if I try and re-image with it set to UEFI then it doesn't let me boot to MDT?

It WILL require a re-image sadly, yes. Are you using an old version of MDT? I thought most modern versions of it (post 2013/14?) could support UEFI?

If your MDT instance DOESN'T support UEFI then this is something that needs to be addressed really. It's the "current" way of the world and it's wise to move to this setup sooner rather than later?

I'm running latest (?) 6.3.8456.1000 version so it must just be a setting I've not got correct somewhere. OK I'll take a look. 

Hi Ric Turner 

Just following up to see if any further assistance is needed.