To use your own enterprise CA to general the Remote Configuration PKI certificate, first follow the instruction layed out in the Step-by-Step Example Deployment of the PKI Certificates Required for AMT and Out of Band Management TechNet article.
To prepare the AMT client, login to the MEBx by pressing "Ctrl-P" during the client POST.
Once logged in the MEBx, select "Intel(R) AMT Configuration"
Select "Setup and Configuration"
Select "TLS PKI"
Select "Manage Certificate Hashes"
In the "Manage Certificate Hashes" Screen, Press the insert key to add a new certificate
In the "Hash Name" field, enter in something human readable and identifiable
In the "Certificate Hash" field, enter in the thumbprint of your Root CA that the PKI certificate was generated from
To get the thumbprint of you Root CA, open up the Root CA certificate and go to the detail tab. Scroll down the list until you see the thumbprint; this value is your certificate hash.
Please note, that if you perform a full unprovision of the AMT client, the custom certificate hash will be deleted from list and you will need to re-enter it. Some OEMs can provide a service to have your custom certificate hash permanently burned in during the manufacturing process.
Now I am able to burn the thumprint value in vPro chip.
but In SCCM Console,
Still I could see the AMT status as "Detected" and when I look into the amtopmgr.log it was showing following the error msg,
"CAMTDiscoveryWSMAN:DoConnecttoAMTDevice:Failed to establish tcp session to<ipaddress>:16992"
I changed the MEBx pwd and I entered the certificate Thumprint value .
Did the MEBx password change might affect the remote admin password?
Please help in this regard,
Thanks in advance,
The MEBx Account in the "Out of Band Management Properties" is used for 2 purposes.
What to set the MEBx account to if it's currently the factory default admin/admin
What to try if the MEbx account is not admin/admin
The Provisioning Account allows you to specify the name of the AMT Remote Admin Accounts and its password that have been configured in the firmware for AMT-based computers and can provision these computers. So in a scenario where the amt client remote admin password was set by another ISV or is different then the MEBx password, you can specify a different remote admin account info (admin / <something else>) or another Digest User that has been already been configured in the MEBx firmware.
When SCCM tries to provision a AMT device, the it will use the following attempt order:
User: admin / Password: admin (Factory Default)
User: admin / Password: (what is listed in SCCM MEBx account)
Users and passwords listed in the Provisioning Account
The reason the Provisioning Account is typically not needed is because...
In a factory default state, the remote admin password is "admin". Since SCCM knows that it will try and provision with that first
The first time you log into and AMT MEBx from a default state, it requires you to change the MEBx password which then set the remote admin (since it was not currently set)
If you do a Full unprovision of an AMT client, it set the Remote Admin password to the MEBx password
So in most cases, the password you set in SCCM as the MEBx account works on the second remote admin password try.
Hi Matt,Hope you are well!
I have an enviroment with internal certification authority, SCCM 2007 SP1 installed and configured, clients Dell optiplex 755 provisioned.
I can power off, power on and access web ui, but i have one question:
I have more than 100 clients here, how to burn the internal certificate thumb print value in Intel vPro remotely?
thanks a lot.
Root certificate hashes can only be configured via the MEBx locally.
It *really* needs to be made an option to use an internal CA without having to go through hoops to make it work.
Plus, whats up with changing the OU string and OID business between versions? Reeks of not knowing what you're doing. Seems like massive overhead for something that is just not necessary. If someone is going to hijack an AMT service, they've likely compromised way more of an environment that is far more important.