2 Replies Latest reply on Jun 29, 2012 3:18 PM by GB Core

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

    todd.wilburn@providence.org

      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.

       

      From AMTOPMGR.LOG

      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\amtopmgr.box\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 (TESTPC1.test.network.local), ID: 57788 - 10.232.72.124 from Resource GUID:91ce57cb-d70c-4cbd-9aa3-d1b5b147935d.  12/2/2009 11:01:12 AM

      AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 57788         12/2/2009 11:01:12 AM

      AMT Discovery Worker: Execute query exec AMT_GetProvAccounts   12/2/2009 11:01:12 AM

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

      AMT Discovery Worker: Parsed 1 instruction files 12/2/2009 11:01:12 AM

      AMT Discovery Worker: There are 1 tasks in pending list      12/2/2009 11:01:12 AM

      AMT Discovery Worker: Send task  to completion port          12/2/2009 11:01:12 AM

      Auto-worker Thread Pool: Current size of the thread pool is 1                12/2/2009 11:01:12 AM

      AMT Discovery Worker: 1 task(s) are sent to the task pool successfully.               12/2/2009 11:01:12 AM

      STATMSG: ID=7203 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_AMT_OPERATION_MANAGER" SYS=PSCCM SITE=RTN PID=14912 TID=7420 GMTDATE=Wed Dec 02 19:01:12.121 2009 ISTR0="1" ISTR1="0" ISTR2="0" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0       12/2/2009 11:01:12 AM

      AMT Discovery Worker: Wait 20 seconds...           12/2/2009 11:01:12 AM

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

      AMT Discovery Worker: Wait 20 seconds...           12/2/2009 11:01:12 AM

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

      AMT Discovery Worker: Wait 20 seconds...           12/2/2009 11:01:12 AM

      Auto-worker Thread Pool: Work thread 128924 started          12/2/2009 11:01:12 AM

      CAMTDiscoveryWSMan::DoConnectToAMTDevice: Failed to establish tcp session to 10.232.72.124:16992.      12/2/2009 11:01:13 AM

      Error 0x80090325 returned by InitializeSecurityContext during follow up TLS handshaking with server.        12/2/2009 11:01:13 AM

      **** Error 0x2d2b970 returned by ApplyControlToken     12/2/2009 11:01:13 AM

      Using translator for version *. 12/2/2009 11:01:13 AM

      session params : https://PSCCM.test.network.local/wstrans/dsc/eoi20/TESTPC1.test.network.local/wsman   ,  141001          12/2/2009 11:01:13 AM

      ERROR: Invoke(createSession) failed: 80020009 12/2/2009 11:01:13 AM

      Description: The WinRM client cannot process the request. The unencrypted flag only applies to the HTTP transport. Remove the unencrypted flag or change the transport and try again the request.    12/2/2009 11:01:13 AM

      CWSManFactory::CreateSession Failed to create wsman session.            12/2/2009 11:01:13 AM

      CSMSAMTDiscoveryTask::Execute - DDR written to D:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box         12/2/2009 11:01:13 AM

      Auto-worker Thread Pool: Succeed to run the task . Remove it from task list.         12/2/2009 11:01:13 AM

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

      AMT Discovery Worker: Wait 3600 seconds...       12/2/2009 11:01:32 AM

      Auto-worker Thread Pool: Work thread 128924 has been requested to shut down. 12/2/2009 11:01:53 AM

      Auto-worker Thread Pool: Work thread 128924 exiting.         12/2/2009 11:01:53 AM

      Auto-worker Thread Pool: Current size of the thread pool is 0                12/2/2009 11:01:53 AM

       

      I have not found anything helpful in searching the blogs.

       

      Help me,

      Todd

        • 1. Re: AMT not working on production server but does on test server.
          Trevor.Sullivan

          Todd,

           

          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: http://communities.intel.com/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.

           

          Cheers,

          Trevor Sullivan

          • 2. Re: AMT not working on production server but does on test server.
            GB Core

            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.