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?
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?
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.
There are a couple points to be clarified.
- 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.
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.
Contact HP. There is an "Engineering Advisory" that is not publicly posted.
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?