Intel vPro® Platform
Intel Manageability Forum for Intel® EMA, AMT, SCS & Manageability Commander
2835 Discussions

AMT not working on production server but does on test server.


Hello Everyone,

I need your help.

We are trying to get our production SCCM system working with AMT after successfully getting it to work on our Proof Of Concept (POC) SCCM system.

Both servers are running Windows 2003 R2 Std Ed SP2 and SCCM 2007 R2 SP1. The servers are on different subnets in the same DC. There shouldn't be any network differences. They both have the same connection specific DNS suffix.

Both servers are on our production network and are using the same Certificate Authority and AD groups. Each server has its own VeriSign Certificate for vPro AMT provisioning. I verified that all the Microsoft KB hot fixes and patches for vPro have been installed on both servers. The Out of Band Management Properties in SCCM are setup identically. "provisionserver" DNS entry is pointing to the production server.

I have a few test PC's that I have been using. I can consistently provision AMT with the POC SCCM server. The primary PC I am using, TESTPC1, is a HP dc7800 with AMT firmware v3.2.3 so it doesn't use WSMAN even though it's installed on both servers.

The 'ConfigMgr AMT web server Certificate' uses the AD group "ConfigMgr Primary Site Servers" that has both the POC and production server in it.

The Certificate Authority is using that AD group for rights to issue the template certs. The certs are being issued to the computer and show a request initialed by the production SCCM server with no errors and are valid.

DHCP option 6 and 15 are set and I get FQDN name resolution on the PC's and servers

The target computer object shows up in the AD "Out of Band Management Controllers" OU.

The other day I deleted the workstation, TESTPC1, from the OU, deleted it from SCCM, reset the CMOS, joined it into the POC SCCM server and it quickly provisioned and was working as expected. Today, I did the same process and joined it to the production SCCM server and it showed up as unknown. After I did a Discover management Contoller it's now showing up as detected.

The OOBMGT.LOG does not show anything for the time that I did the discovery at 11:01.


AMT Discovery Worker: Wakes up to process instruction files 12/2/2009 11:01:11 AM

AMT Discovery Worker: Reading Discovery Instruction D:\Program Files\Microsoft Configuration Manager\inboxes\\disc\{0E311337-78F7-45A5-9C54-A52662650C17}.RDC... 12/2/2009 11:01:11 AM

AMT Discovery Worker: Execute query exec AMT_GetThisSitesNetBiosNames NULL, 'GUID:91ce57cb-d70c-4cbd-9aa3-d1b5b147935d', 'RTN' 12/2/2009 11:01:12 AM

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromResource - Found machine TESTPC1 (, ID: 57788 - from Resource GUID:91ce57cb-d70c-4cbd-9aa3-d1b5b147935d.<span style="mso-tab-coun...

2 Replies


It might be helpful to post the results (amtopmgr.log) of a provision attempt instead of just a discovery. The most common issues I've seen causing provisioning issues are:

  • Invalid A and PTR records for client -- Might want to double-check these, if you're switching the domain membership of a client


  • Incorrect DHCP option 15 -- yes, I noticed that you said this was set correctly already


  • Static client IP -- DHCP is required for ConfigMgr OOB management
  • Invalid provisioning certificate (can you validate the root CA hash with the firmware's embedded hashes?)

Keep in mind that the AMT status field in your ConfigMgr collections will only update when you do a "Update Collection Membership", not simply a refresh of the collection -- at least, that has been my experience thus far.

Check out this excellent troubleshooting guide from Steve Davies at Intel: /thread/2988


FYI, the "provisionserver" DNS resource record is only used for out-of-band (aka. agent-less) provisioning. For in-band (aka. agent-initiated) provisioning, which it appears you're doing, this DNS record is not utilized.


Trevor Sullivan


For those that have a similar error:

"Error 0x80090325 returned by InitializeSecurityContext during follow up TLS handshaking with server."

This is likely do to a hash mis-configuration causing the TLS handshaking to fail. Check the hash table in the ME BIOS configuration, and if you are using an internal CA, you use the hash from the CA root certificate not the Provisioning certificate.

0 Kudos