Looks like you have chosen Remote Configuration method (this is key reason why you need RCS service) to achieve Admin Control Mode (but my assumption may be wrong).
Remote Configuration requires:
- LAN network
- DHCP server with Option 15 (domain suffix) configured
- Intel® AMT Remote Configuration Certificate with CN in your DNS domain suffix (have to be same domain suffix as DHCP Option 15). Host name doesn't matter, there is no need this certificate to be wildcard certificate.
If for any reason DHCP Option 15 does not equal your external/ registered domain name you may not be able to order such cert. Then some workarounds like DHCP Option 15 (only) change may be required (Note. it may impact other devices in your network!)
Intel® AMT Remote Configuration Certificate have to ordered from /issued by one of 15 Public Root CA which root cert hashes are embeded in default Intel AMT FW (this is how AMT FW validates this certificate) - cert trust chain has to lead to one of those roots.
List of those hashes is discovered from AMT FW during Intel AMT: Discover and Report - see full list with hashes at the end of this reply.
Intel® AMT FW allows to import up to 3 Customer own PKI CA Root certificate hashes -so uou can use self signed your own CA Root cert and self issued Intel® AMT Remote Configuration Certificate
BUT this import proces will require manual or USB One touch of each Intel® AMT based system and importe hashes will be removed with Full Intel® AMT Unprovision.
See Intel® SCS User Guide -chapter 10.5.3 Entering a Root Certificate Hash Manually in the Intel AMTFirmware
Intel® AMT Remote Configuration Certificate is not specified in Intel AMT profile - it has to be installed in Intel® AMT RCS service account certificate store - use Intel® SCS Utils for this.
Please see Intel® SCS User Guide - Chapter 10 Setting up Remote Configuration for more Intel® AMT Provisioning cert details and the proces.
List of Intel® AMT FW default embeded certificate hashes for FW versions:
7.x or newer
22.214.171.1249 or newer
126.96.36.1998 or newer
188.8.131.527 or newer
184.108.40.2064 or newer
1. VeriSign Class 3 Public Primary CA – G1 SHA1 Fingerprint: 74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2
2. VeriSign Class 3 Public Primary CA – G1.5 SHA1 Fingerprint: a1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b
3. VeriSign Class 3 Public Primary CA – G2 SHA1 Fingerprint: 85 37 1c a6 e5 50 14 3d ce 28 03 47 1b de 3a 09 e8 f8 77 0f
4. VeriSign Class 3 Public Primary CA – G3 SHA1 Fingerprint: 13 2d 0d 45 53 4b 69 97 cd b2 d5 c3 39 e2 55 76 60 9b 5c c6
5. VeriSign Class 3 Public Primary CA – G5 SHA1 Fingerprint: 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5
6. Go Daddy Class 2 CA SHA1 Fingerprint: 27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4
7. Comodo AAA CA SHA1 Fingerprint: d1 eb 23 a4 6d 17 d6 8f d9 25 64 c2 f1 f1 60 17 64 d8 e3 49
8. Starfield Class 2 CA SHA1 Fingerprint: ad 7e 1c 28 b0 64 ef 8f 60 03 40 20 14 c3 d0 e3 37 0e b5 8a
9. GTE CyberTrust Global Root SHA1 Fingerprint: 97 81 79 50 D8 1C 96 70 CC 34 D8 09 CF 79 44 31 36 7E F4 74
10. Baltimore CyberTrust Root SHA1 Fingerprint: D4 DE 20 D0 5E 66 FC 53 FE 1A 50 88 2C 78 DB 28 52 CA E4 74
11. Cybertrust Global Root SHA1 Fingerprint: 5F 43 E5 B1 BF F8 78 8C AC 1C C7 CA 4A 9A C6 22 2B CC 34 C6
12. Verizon Global Root SHA1 Fingerprint: 91 21 98 EE F2 3D CA C4 09 39 31 2F EE 97 DD 56 0B AE 49 B1
13. Entrust.net CA (2048) SHA1 Fingerprint: 50 30 06 09 1d 97 d4 f5 ae 39 f7 cb e7 92 7d 7d 65 2d 34 31
14. Entrust Root CA SHA1 Fingerprint: b3 1e b1 b7 40 e3 6c 84 02 da dc 37 d4 4d f5 d4 67 49 52 f9
15. VeriSign Universal Root CA SHA1 Fingerprint: 36 79 CA 35 66 87 72 30 4D 30 A5 FB 87 3B 0F A7 7B B7 0D 54
Okay, I spent all yesterday and so far all of this morning running down every fox which your excellent response dislodged from the henhouse. Here's current status:
LAN network - Check
DHCP server with Option 15 (domain suffix) configured - Check
Intel® AMT Remote Configuration Certificate with CN in your DNS domain suffix (have to be same domain suffix as DHCP Option 15). Host name doesn't matter, there is no need this certificate to be wildcard certificate. - Check. I previously had this misconfigured. I was using a certificate based on a user template. I went back and created the certificate template according to the directions in the SCS User Guide, Ch 10. In this case, we're using an internal root certificate. I made sure to go into the MEBx of the test machine and manually add the root certificate hash as it exists on our internal root CA.
Then, I used this command to add the Remote Configuration certificate to the RCSUser's user account:
rcsutils.exe /certificate add path_to_pfx password /RCSuser domain\user
And that completed successfully.
The next attempt to run the remote configuration task sequence from within SCCM failed with the same result: A valid PKI certificate was not found in Certificate Store of the user running the Remote Configuration Service.
Against the possibility of an environmental problem, I uninstalled the SCS Addon, the SCS itself, and the the database. I also reimaged both test machines. I then re-set everything up and tried again. Same result.
Now. This morning I've made an important discovery on accident. My primary site server had a problem with rebooting last night, which led me to inspect event logs. I noticed that my enrollment point in SCCM had failed to install. Digging deeper, I found multiple repetitive instances of this error:
Site Component Manager failed to install this component, because Secure Sockets Layer (SSL) is not configured properly on the Internet Information Server.
Possible cause: No Server Certificate is attached to the designated Web Site.
Solution: Refer to ConfigMgr Documentation regarding how to create and attach a proper Server Certificate to the designated Web Site.
Possible cause: The Server Certificate is invalid or expired.
Solution: Refer to ConfigMgr Documentation regarding how to create and attach a proper Server Certificate to the designated Web Site
The instructions I got in the SCCMGuru thread, listed in the original post, were to add the web server certificate to the store of the SCCM server before installing the enrollment point. This is again referenced during the install of the enrollment point. Is this the root of the problem?
EDIT: The problem with the enrollment point has been fixed. There was a misconfiguration of the HTTPS bindings in SSL settings in IIS. No effect on the root issue, unfortunately.
That's where I am currently. Thanks very much for your help.