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

Error: Can NOT establish connection with target device - Provisioning attempt on SCCM 2007

SWood7
Novice
1,674 Views

I recently discovered that our systems had some problems getting provisioned from SCCM because our machine names have underscores in them. We're working to change our naming scheme however we still are getting errors in our efforts to provision our Vpro systems. Here's a bit from our amtopmgr.log showing an attempt to provision

Provision target is indicated with SMS resource id. (MachineId = 2734 10TH-85357.da.ocgov.com)

Found valid basic machine property for machine id = 2734.

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

The provision mode for device 10TH-85357.da.ocgov.com 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: C2512FF7A3A558C88896C7EE51F152B15965C468)

Set credential on provisionHelper...

Try to use provisioning account to connect target machine 10TH-85357.da.ocgov.com...

Fail to connect and get core version of machine 10TH-85357.da.ocgov.com using provisioning account # 0.

Fail to connect and get core version of machine 10TH-85357.da.ocgov.com using default factory account.

Try to use provisioned account (random generated password) to connect target machine 10TH-85357.da.ocgov.com...

Fail to connect and get core version of machine 10TH-85357.da.ocgov.com using provisioned account (random generated password).

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

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

I've done a full unprovision before the attempt above and even hard-coded the provisioning account for good measure but still nothing.

Has anyone run into this issue before?

0 Kudos
8 Replies
Matthew_R_Intel
Employee
761 Views

Assuming the FQDN you listed below does resolve to the properly IP address when looked up from the SCCM Server? Is the MEBx password you manaully set the same as what you configured in SCCM?

--Matt Royer

0 Kudos
SWood7
Novice
761 Views

Yes, it ping through good and the DNS entry is correct. I've double-checked the password and it matches. At this point I think I'm going to open a ticket with Microsoft to have them help me make sure I've not missed anything Microsoft-wise.

0 Kudos
idata
Employee
761 Views

We are seeing the exact same error. What doesn't make sense is that the majority of the systems are provisioning fine. But, we have a large group of systems that log this same error. Different versions as well, some 3.0.1, some 4.0, and some 5.0. Were you able to resolve this problem? SCCM Component Status says communication errors with DHCP and DNS options, but these are configured correctly. Logs are attached...

0 Kudos
idata
Employee
761 Views

Brian,

If you're sure that DHCP option 15 is set correctly on these systems, then please make sure that the A and PTR DNS records for the problematic clients are registered properly. Since you're seeing it on a variety of AMT platform versions, and because it seems to be somewhat random from what you said, I think that incorrect client DNS entries is the most likely problem you're experiencing.

Please run nslookup from your site server and perform a forward and reverse lookup on one of your problem clients.

Let me know what your results are!

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
idata
Employee
761 Views

Yes, this is one of the first things that we verified (per some other posts regarding the same issue). Also, the MEBx passwords were verified, still a no-go on any of these systems...

0 Kudos
idata
Employee
761 Views

Brian,

Can you verify that the necessary ports are open at your firewall level?

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
idata
Employee
761 Views

Yes, this has already been checked.

0 Kudos
idata
Employee
761 Views

Brian,

If you've verified the DNS records for the AMT client, and DHCP option 15 is set correctly, the only other issue I could think of would be that the MEBx password may not be set correctly. Have you changed the MEBx password (logged in locally to the MEBx) on any of the systems that you're having problems with?

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
Reply