2 Replies Latest reply on Dec 23, 2008 6:42 AM by eschloss

    "Can NOT establish connection with target device" on Provision

    eschloss

      We are attempting to provision systems already deployed within our organization.  The systems I am dealing with now are HP dc7900p with AMT 5.0.1.  Yesterday, I attempted to provision (client based) 22 systems, all new out of the box within the last 3 weeks.  They have never bbeen provisioned or attempted to be provisioned.

      Of the 22, 19 went fine and 3 I got the following log entries from AMTOPMGR.LOG:

       

      >>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<<

      Provision target is indicated with SMS resource id. (MachineId = 333992 INSERT_CLIENT_FQDN)

      Found valid basic machine property for machine id = 333992.

      Warning: Currently we don't support mutual auth. Change to TLS server auth mode.

      The provision mode for device INSERT_CLIENT_FQDN is 1.

      Attempting to establish connection with target device using SOAP.

      Found matched certificate hash in current memory of provisioning certificate

      Create provisionHelper with (Hash: INSERT_HASH)

      Set credential on provisionHelper...

      Try to use provisioning account to connect target machine INSERT_CLIENT_FQDN...

      Fail to connect and get core version of machine INSERT_CLIENT_FQDN using provisioning account #0.

      Try to use default factory account to connect target machine INSERT_CLIENT_FQDN...

      Fail to connect and get core version of machine INSERT_CLIENT_FQDN using default factory account.

      Try to use provisioned account (random generated password) to connect target machine INSERT_CLIENT_FQDN...

      Fail to connect and get core version of machine INSERT_CLIENT_FQDN using provisioned account (random generated password).

      Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 333992)

      Error: Can NOT establish connection with target device. (MachineId = 333992)

      >>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<

      Auto-worker Thread Pool: Warning, Failed to run task this time. Will retry(3) it

       

      It runs this 3 times and then shows:

       

      Auto-worker Thread Pool: Error, Can not execute the task successfully after try it 3 times. Remove it from task list.

      STATMSG: ID=7212 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_AMT_OPERATION_MANAGER" SYS=SMSSERVER SITE=SMS PID=5448 TID=5928 GMTDATE=Tue Dec 16 13:16:18.180 2008 ISTR0="INSERT_CLIENT_FQDN" ISTR1="0x       0" ISTR2="Can NOT establish connection with target device." ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0

        • 1. Re: "Can NOT establish connection with target device" on Provision
          miroyer

          Based on the log, I’m assuming you are trying to provision the vPro client with SCCM SP1?

           

          Typically this error is caused when the remote admin password of the vPro Client is different than the default (admin), different than what is configured in sccm for the MEBx password, or not an accounts/password you have listed in the Provisioning Settings tab of the Out Of Band Management in Component Configuration.  However, since you stated that they are fresh out of the box (never touched, which the remote admin password should be admin) and you have gotten a few others already provisioned, this is definitely strange.

           

          Are you using Agent based provisioning to provision the device or Bare metal (Import via Out of Band Import wizard and waiting for the hello packet)?  If Agent, what is the IP address your SCCM agent is reporting, is it different then what the OS has?  You may also want to confirm that they FQDN (which you replaced with INSERT_CLIENT_FQDN) is resolving to the correct IP address.  If not, you should be able to perform ipconfig /flushdns on the SCCM Server.

           

          --Matt Royer

          • 2. Re: "Can NOT establish connection with target device" on Provision
            eschloss

            We are using agent based provisioning.  The IP is resolving correctly, so I'm not sure where the problem lies.