Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Employee
1,446 Views

HP 6910p units that will not remote configure nor remote provision?

Looking for feedback from the community on the following:

HP 6910p units with AMT 2.6.1 - unable to remote provisioning or configure (i.e. certificate based provisioning, PKI-CH, etc)

In a batch of 40 units that have been updated, 1 of the units does not work with remote configuration. Further testing and investigation reveals the certificate hashes did not get loaded into the firmware. If using vPro Activator utility - the output will highlight "Not Ready" for remote configuration, and usually ends with an exit code 6.

On systems where this has been experience - BIOS F.10 and F.13

USB one-touch (i.e. preshared key) works just fine on the units

Anyone else experiencing this on HP 6910p units? It doesn't appear very often - just on an occasional box.

Since the units I'm using are often used in labs, teaching environments, etc - I have to admit that they go through a little more use\abuse on OS loads, firmware updates, and so forth...

Tags (1)
0 Kudos
7 Replies
Highlighted
Employee
20 Views

If you are experiencing this issue - curious to know if the system was PSK configured (i.e. PID\PPS entered) BEFORE you did AMT 2.6 firmware update. Yes\no?

0 Kudos
Highlighted
Employee
20 Views

More reports have occurred of AMT 2.5 systems in PSK mode... and then upgrade to AMT 2.6... remote configuration is not supported. PSK (i.e. USB one-touch, use of PID\PPS, etc) are still supported

Reports of both HP and Lenovo systems experiencing this event

Others in the community seeing this?

0 Kudos
Highlighted
Valued Contributor I
20 Views

Terry,

You cannot do Remote Configuration on a system that was shipped with the 2.5 FW and upgraded to the 2.6 FW. The needed hashes weren't included with the 2.5 FW, and the upgrade process doesn't add them into the image. The MEBx for 2.6 doesn't include a way to add the hashes for remote config into the image, and there is no way to programmatically push the needed hashes into the ME from the OS. So, basically, there is no way to do remote config on a 2.5 system that has been upgraded to 2.6. This is an issue with the FW itself, so it will affect any OEM's product that shipped with 2.5 and was updated to 2.6 in the field. The only way to fix this would be to reflash the ME FW in the field, which is a service event for any OEM, so you would need to contact your system OEM regarding this issue.

Regards,

Roger

0 Kudos
Highlighted
Employee
20 Views

There are a couple points to be clarified.

<![CDATA[<ol> Units that are AMT 2.5 and upgraded to AMT 2.6 will support remote configuration. This has been done several times in lab and production environments. There is one clarifying point... Units that are AMT 2.5 and have a PID\PPS applied to them _may_ experience a situation where remote configuration certificate hashes are not successfully applied during the AMT 2.6 upgrade process. This is a bug in the firmware upgrade package\process, and has been escalated. On AMT 2.6 systems, the MEBx does not allow direct entering of the certificate hashes as seen on AMT 3.0 and higher units. ]]>

0 Kudos
Highlighted
Community Manager
20 Views

So is there a fix for this problem? I have a thread about the issue, where the ConfigMgr client fails to call the "CheckCertificate" method (this is a WMI method provided by the ConfigMgr client) ... this is probably due to the hashes not being present in the firmware.

The HP 6910p I am working with is an Intel demo unit, and was most likely PID/PPS-provisioned prior to my upgrading it to AMT 2.6, and testing ConfigMgr remote provisioning with it.

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
Highlighted
Employee
20 Views

Contact HP. There is an "Engineering Advisory" that is not publicly posted.

0 Kudos
Highlighted
Community Manager
20 Views

Do you know why they haven't publicly posted it, and do you have a number or ID to reference the "Engineering Advisory" with?

If this hasn't been publicly posted, then shouldn't the Intel hardware interop team work with HP to make sure that it's documented to avoid the need for HP / Intel customers to jump through hoops to get the fix?

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos