ProDesk 600 G1 BIOS configuration of TPM via BIOS Configuration Utility

[Dave_Wibble]

We have a range of HP devices, both desktops and laptops in our environment.  Devices are all running Windows 7 64bit and should have Bitlocker enabled, however we have found that a few have not been encrypted.  I am therefore attempting to put together a remote BIOS config and Bitlocker enable package that we can push out via SCCM and then include in an image task sequence for new machines.

I am using the HP Bios Configuration Utility to make sure a BIOS password is set and then activate the TPM chip.  I have taken a BIOS config output from each of our models and created a settings file that has all of the TPM related settings from all of the models.

At the moment I am running the BIOS Configuration Utility manually for testing.  On all of the models I have tried this is working fine, except for the ProDesk 600 G1 SFF.

When I run the utility on the ProDesk 600 G1 SFF, it says that I has been successful at updating the settings, and when I check the BIOS, the TPM has been unhidden and management of the TPM has been granted to the OS (both settings that I change), but the TPM chip itself remains hidden.

This is the output from the BIOS Config Utility (this is using version 2.60.13.1, which uses plain text passwords.  I have also tried with the later 3.0.13.1 version which uses password files - same result)

C:\>BiosConfigUtility64.exe /cspwd:"password" /set:"TPM_Config.REPSET"
<BIOSCONFIG Version="2.60.13.1" Computername="HP600G1" Date="2014/07/24" Time="13:01:37" UTC="1" >
<SETTING changeStatus="pass" name="Embedded Security Device" reason="" returnCode="0">
        <OLDVALUE><![CDATA[Device hidden]]></OLDVALUE>
        <NEWVALUE><![CDATA[Device available]]></NEWVALUE>
</SETTING>
<SETTING changeStatus="pass" name="Activate Embedded Security On Next Boot" reason="" returnCode="0">
        <OLDVALUE><![CDATA[Disable]]></OLDVALUE>
        <NEWVALUE><![CDATA[Enable]]></NEWVALUE>
</SETTING>
<SETTING changeStatus="pass" name="OS management of Embedded Security Device" reason="" returnCode="0">
        <OLDVALUE><![CDATA[Disable]]></OLDVALUE>
        <NEWVALUE><![CDATA[Enable]]></NEWVALUE>
</SETTING>
<SUCCESS msg="Successfully set BIOS config." />
<Information msg="BCU return value" real="0" translated="0" />
</BIOSCONFIG>
C:\>

And after a reboot (where it should activate the TPM), the BIOS shows the Embedded Security Device as Disabled (see attachment for image).

I have tried everything I can think of to get this to enable, including:

• Different versions of the BIOS Config Utility
• Removing the BIOS password and applying in the same command as the settings
• Different passwords
• Restarting and allowing the machine to boot fully to Windows before checking if the setting has taken effect

I've also tried adding the utility and commands to an SCCM package and running both directly and as part of a task sequence to see if that makes any difference, but nothing I have done has enabled the TPM.

I know that the TPM works, as you can enable it manually and then Bitlocker can be applied to the machine, but with thousands of devices in our environment I need to have this working without needing manual intervention.

Has anyone else had this problem and found a solution?  Or has anyone managed to activate the TPM on the ProDesk 600 G1 SFF using the BIOS Config Utility?  Any ideas / suggestions would be much appreciated!

P.S. This thread has been moved from Business PCs - Compaq, Elite, Pro to HP PC Client Management. - Hp Forum Moderator

[Dave_Wibble]

Sorry - attachment didnt upload. It was just an image of the BIOS screen showing that in the System Security section, the Embedded Security Device (the TPM chip) was showing as Disabled.

[Dave_Wibble · Accepted solution]

This issue has now been resolved by HP.

They supplied a replacement motherboard for the test machine I was using which solved this issue. I have no idea what kind of motherboard fault could prevent the TMP chip activating via script but not prevent activation via the BIOS menu, but as a replacement resolved the problem then it must be a hardware fault.