I'm quite new to the Intel SCS. I administer a SCCM 2012 R2 environment and untertook to implement Intel SCS when I realized that 95% of our workstations have vPro chips that we aren't using.
Anyway, as with most other newcomers, I followed the procedure for integrating SCS with SCCM written by sccmguru here:
https://sccmguru.wordpress.com/2013/12/20/integrating-configuration-manager-2012-r2-with-intel-scs-9... Integrating Configuration Manager 2012 R2 with Intel SCS 9.0 – Part 1 : Introduction | SCCM GURU
It worked pretty well until I realized I needed to use RCS integration to get the most bang for my buck. I installed the RCS in database mode, installed the Add-on for SCCM, and ran these Task Sequences against a collection of test machines:
Intel SCS: Platform Discovery
Intel AMT: Discover and Report
Intel AMT: Remote Configuration
The first two worked without a hitch. The Remote Configuration Task sequence failed, and looking at smsts.log on the client (which is the same output as ACUConfig), I found this entry:
Thread:5172(ERROR) : ACU Configurator, Category: Exit Source: Src\ActivatorMain.cpp : wmain Line: 1254:***********Exit with code 75. Failed to complete remote configuration of this Intel(R) AMT device. Initial connection to the Intel(R) AMT device failed. A valid PKI certificate was not found in Certificate Store of the user running the Remote Configuration Service.
Now, this failed no matter what kind of profile I tried to apply. On the advice found in this thread:
...I scaled down the profile to nothing other than allowing the device to respond to pings. Same error.
I was wondering if you guys might point me in the right direction. Thanks.
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:
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
220.127.116.119 or newer
18.104.22.1688 or newer
22.214.171.1247 or newer
126.96.36.1994 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.