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?
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?
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.
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...
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!
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...
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?