Intel Communities: Message List - AMT Provisioning hell

Re: AMT Provisioning hell

webadmin@intel.com — Wed, 01 Jul 2009 11:20:56 GMT

Well, assuming you've checked all your network configuration (DHCP, DNS), done a factory reset on the problem unit(s), applied Microsoft hotfix KB960804, and triple-checked your root CA's certificate hash, I'm probably going to have to defer to Microsoft Premiere Support on this one.

By the way, have you opened the AMT Provisioning certificate from your site server, and validated the certificate chain up to your root CA? An invalid certificate chain caused a problem for me a while back. See this blog post for more details:

http://communities.intel.com/community/openportit/vproexpert/blog/2008/11/18/intel-amt-provisioning-issues-with-configmgr-sp1

Edit: Fixed URL

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Re: AMT Provisioning hell

webadmin@intel.com — Thu, 02 Jul 2009 04:02:39 GMT

OK, thanks for your help, I'll post the solution once I find it.

Bob

Re: AMT Provisioning hell

webadmin@intel.com — Wed, 01 Jul 2009 00:24:52 GMT

Yes, still seeing that error. I have completely rebuilt the CA and performed a full unprovision on the clients. Still no change, the M10 client provisions fine, but the other one do not. I have checked DNS and the records are correct,

Re: AMT Provisioning hell

webadmin@intel.com — Mon, 29 Jun 2009 13:04:25 GMT

Bob,

Are you still seeing the ApplyControlToken error? If so, can you double-check your DNS records (A and PTR) for these clients?

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Re: AMT Provisioning hell

webadmin@intel.com — Fri, 26 Jun 2009 03:45:06 GMT

OK, I've done a full un-provision, from the BIOS and removed the object from AD. Then the M10 client could provision again fine (other clients still fail). I have removed the third party certificate from the certificate store on the oob management point server and deleted, then re-added the OOB service point role. I'm not sure how much 'cleaning' this does, as it still retained the settings I had. I did re-enter all the information anyway, just in case. No change.

The certificate is an internally provisioned one, and the correct certificate hash is in the BIOS of the client PCs. There is no difference in the BIOS settings between the client that does provision, and the ones that don't.

Re: AMT Provisioning hell

webadmin@intel.com — Fri, 26 Jun 2009 03:09:24 GMT

Actually, in addition to what Bill York just mentioned, it might be worth going to the extent of removing and re-installing the OOB service point role on your site server, just to make sure things are "cleaned out."

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Re: AMT Provisioning hell

william.york@intel.com — Thu, 25 Jun 2009 14:13:29 GMT

Did you do a full unprovision or partial unprovision? And did you perform it from SCCM OOB console or did you perform it manually within the MEBx?

Re: AMT Provisioning hell

william.york@intel.com — Thu, 25 Jun 2009 14:11:48 GMT

Bob, what provisioning certificate did you load into SCCM? Is it your self generated SCCM cert that was produced from your internal CA? And did you load that internal Root CA hash into the MEBx before the provisioning process started? If you want to use your own internally developed cert, I would make sure all references to the VeriSign cert is removed from the CA (personal store and any other store possibly located) and remove it from SCCM (both in the OOB service point and the certificate stores on this site server. Than make sure your self generated cert is loaded on your SCCM service point (in the OOB config and personal store on SCCM with appropriate private keys). And make sure you load your internal Root CA hash (top level CA that produced your provisioning cert) into the MEBx. And see what happens when provisioning. From your thread below, it seems as you have multiple certs getting confussed and this is hard to diagnose. I hope this might clean it up a bit...

Re: AMT Provisioning hell

webadmin@intel.com — Thu, 25 Jun 2009 05:27:44 GMT

Also, just to see what would happen, I did an un-provision on the client which is working and was able to again provision this client without any errors.

Re: AMT Provisioning hell

webadmin@intel.com — Thu, 25 Jun 2009 00:50:10 GMT

OK, so I tried factory reset and remove the record from SCCM. No change. The system actually shows up as 'Detected' in SCCM now (I did a re-install of the AMT driver).

I had a look at the provisioning record in the bios, and the weird thing is the certificate hash is that of the Verisign one. Now, I am using an internally provisioned certificate, so I did not expect to see this. I had a look on the CA and the verisign certificate is there (from some other project I don't know about).

So I tried disabling the verisign cert in the BIOS and did a full un-provision. Then again attempted to provision the client, and again the verisign hash appears in the provisioing record in the machine BIOS. Not sure now if this is the root cause or not.