We are in the process of in-band provisioning ~50 vPro Clients (HP dc7900 Ultra Slim Desktop) using SCCM SP1, but having problems.
The AmtOpMgr.log shows the following failure on every client:
SecurityAdministration.SetTlsEnabled finished with HResult = 0x80004005, status = 0x0, clientError = 10.~ ...
Error: Failed to finish critical setup and configuration step. (pProvisionHelper->SetTlsEnabled) ...
Error: Can't finish provision on AMT device WS106.maklerzentrum.ch with configuration code (30)! ...
(The complete log for this machine is attached)
What we have done so far:
- Requested a Provisioning-Certificate vom Verisign (this is the content of the subject-field):
CN = srv-hq-1.mydomain.ch
OU = Intel(R) Client Setup Certificate
O = MyCompany
L = Basel
S = Basel-Stadt
C = CH
- The Verisign-Certificate was requested and installed using IIS 7. On export, the option "Include all certificates in the certification path..." was selected. The intermediate and root certificate of VeriSign are valid and installed in the local certificate store.
- We set up a Windows Server 2008 Enterprise CA and configured it according to the Technet Documentation and Intel Quickstart Install Guide 1.9
- The CA lists issued certificates for all clients that tried provisioning (this is the content of the subject field):
CN = WS106.mydomain.ch
CN = WS106
CN = WS106$iME
CN = Device (UUID: 3E061647-F28E-11DD-BBDA-7D1DFF970023)
- The internal CA-Certificate is listed under "Trusted Root Certification Authorities".
- The Computer objects in the AD are created in the OU assigned in SCCM (so the permissions for the Site-Server are set correctly on the OU)
- DHCP Options 6 and 15 are set correctly (6 to the AD DNS Server, 15 to mydomain.ch)
- The HECI Driver is installed, SCCM reports the AMT Version as "5.0.1" and AMT Status as "Not supported"
- The WS-MAN Translater is NOT installed (and has never been)
- No one ever accessed the MEBx locally
- The Ports 9971 and 16992-15995 are opened on the Clients Firewall (OS is Vista Enterprise SP1)
- The SCCM is a single site system, all roles (except some branch distribution points and the site database) are on the same server.
- The iAMT-Scan-Tool lists the AMT Setup Status as "In process" (see the attachment)
Does anyone have an idea what is wrong here?
Best Regards and thanks in advance
No, I hesistated to apply this patch because none of the included fixes seem to be related.
I installed it now, and I hope the Site Reset didn't cause any harm...
I kicked off a provisioning attempt using the SendSched.vbs you provided here: http://communities.intel.com/thread/2999
Unfornately it didn't seem to help and I get a different error message now, but this could be because the clients status (from iAMTScan) is still "In process" and SCCM thinks it's unprovisioned.
The log is attached, but the obvious lines are:
Set credential on provisionHelper... ...
Try to use provisioning account to connect target machine WS94.mydomain.ch... $...
Fail to connect and get core version of machine WS94.mydomain.ch using provisioning account # 0. ...
Try to use default factory account to connect target machine WS94.mydomain.ch... $...
Fail to connect and get core version of machine WS94.mydomain.ch using default factory account. ...
Try to use provisioned account (random generated password) to connect target machine WS94.mydomain.ch... ...
Fail to connect and get core version of machine WS94.mydomain.ch using provisioned account (random generated password). ...
Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 100) ...
Error: Can NOT establish connection with target device. (MachineId = 100) ...
Hi, thanks for your help!
The A and PTR records are correct, I already checked that several times.
The OobMgmt.log repeats the following lines several times:
<![LOG[Retrying to activate the device.]LOG]!>
<![LOG[Resending last OTP]LOG]!>
<![LOG[Upload provisioning data state message sent successfully. TopicType = STATE_TOPICTYPE_AMT_CLIENT_DATA_SYNCHRONIZE, OTPHash = 2169B288F2830E39AEDC92F274890CE95FD6AA8B, RetryCount = 9]LOG]!>
<![LOG[Successfully activated the device.]LOG]!>
<![LOG[Upload manufacturing data state message sent successfully. TopicType = STATE_TOPICTYPE_AMT_CLIENT_DATA_SYNCHRONIZE, Root Certificate Hash = 742C3192E607E424EB4549542BE1BBC53E6174E2, AMT Core Version = 5.0.1]LOG]!>
I just wanted to make sure the DNS records were correct, because I wasn't sure if they had perhaps changed since you last tested them. I know that, in my environment, we have some DNS issues in which I have to repeatedly check to make sure the records exist.
I would try pulling the CMOS battery, and deleting the ConfigMgr resource as next troubleshooting steps .... are all of the systems experiencing the same behavior?
So far, I have never had any DNS problems. I executed an ipconfig /registerdns, waited a few minutes and everything is still as it should be. DNS is definitely not a problem.
I hope I didn't offended you with my last message as English isn't my mothers tongue and I'm not always sure how something sounds in what is harmless in my own language.
Yes, all ~50 machines are having the same problem.
Is there any other way to reset the system remotely? I'm working over VPN in this network and don't have the possibility to perform physical maintenance tasks. I would need to coordinate with the office staff to open the machine(s) - and as you certainly unterstand I would very much like to avoid that.
As the machines are used in production, deleting the SCCM resource seems a bit too risky for me.
Funny thing is, I tried this in a lab environment and it worked great. The only thing that was different was the provisioning certificate - in the lab I manually entered the hash in the MEBx. Consequence for me is certainly not to rely on the my lab and try this next time on a smaller group of machines.
Well, if all of your systems are exhibiting the same behavior, then I would venture to say that it's probably an infrastructure-related issue, rather than an AMT client issue. Could you do me a favor, and restart your ConfigMgr Executive service, and post the amtopmgr.log file during the service start-up?
Let's see if there's anything finicky happening during this stage
Meanwhile I managed to instruct an experienced co-worker to manually reset the CMOS on one machine, and voila, this one provisioned.
I can connect to the web interface using a browser, but I can't login. I added a domain-account in the SCCM OOB Configuration (before the provisioning), but it is listed as "srv-hq-1\amt" instead of "mydomain\amt".
The SCCM OOB Management Console also cannot connect.
But: What do I do to reset the other machines? I really don't want to reset 50 machines manually.
I'm not sure what the solution is going to be for this situation ... perhaps you could try shutting off all the machines and turning them back on? Maybe pulling the CMOS battery isn't necessary, but it might be necessary to shutdown the systems to reset the AMT firmware.
Let me know your results
We can work on the OOB console and WebUI issues separately if you'd like. I'm pretty sure we can get you up and running though Why don't you create a new thread for those issues?
I tried shutting down a machine and had a colleague remove the power cord. It didn't help.
The SCCM logs sometimes state something about a OTP (One Time Password). I think the machines or SCCM created one, the provisioning failed, SCCM retried it's 3 times, and then forgot the OTP. => Access Denied on further connection attempts/retries.
I could figure that this could have been co-caused by the site reset during the application of the SCCM patch.
I'm currently searching the net for a possibility to reset the CMOS through an application. BIOS updates can be installed through Windows, why shouldn't it be possible to clear the CMOS?
This whole stuff is way too complicated. I appreciate the idea of providing a secure system, but obviously they never thought about failures during the provisioning process and small companies. It's just insane to manually walk to every computer. Imagine it would have been a few thousand instead of 50!?
There have been a number of issues I've encountered, and am still encountering, which has pushed my implementation of Intel AMT back for months. I do think the technology has matured a lot from its early stages, however. Some of the fault is Intel's, some of the fault is the software vendors', and some of the fault was even ours, in our IT infrastructure. Ultimately though, I think the technology will be beneficial long-term, and because of this, I have pursued it fervently for the past year.
Anyway, yes, my guess is that the OTP could be the issue. That is kinda why I was thinking that deleting the ConfigMgr resource record might help you out a bit.
Looks like the issue was not resolved. You could check http://www.0x80004005.info 0x80004005 site for assistance. Although 0x80004005 cases are very specific there there could be some useful hints where to dig.