Skip navigation

A while back I ran into an issue configuring an AMT system in TLS mode. I wanted to walk you through the issue and one potential solution in the event you are seeing similar issues with TLS.


I did a quick overview of my environment and everything appeared to be set up correctly. I was able to provision using a non-TLS profile in SCS, but when I switched to a TLS profile I kept getting this error on the vPro client while running ACUConfig.exe:


“Exit with code 75.

Details: Failed to complete remote configuration of this Intel(R) AMT device. Failed to get the certificate from the CA. (Certificate ID: 3310051103).  (0xc0002825). The certificate chain could not be built. Please make sure that the root certificate is installed properly. (0xc0003e93). Intel(R) AMT Operation failed. (Request Certificate). (0xc00007d5). The RCS failed to process the request.”

I checked out the SCS server and made sure the root Cert was installed correctly and everything looked normal. Then accessing the MMC cert snap-in on the SCS server, I created a test request to the CA for the AMT TLS cert and it issued it to me:











And as you can see, the OS had no issues with the certificate, but I was still seeing the errors on the vPro client while running ACUConfig.exe.


Taking a closer look at the acuconfig error message, it seemed like the SCS was having trouble building the certificate chain. So I decided to take a look at the CRL. After some digging around a bit, I decided to copy the CRL from the Cert Authority. To do this I just ran this command from a PowerShell prompt on the Certificate Authority:




Then I copied the crl.crl file over to the SCS server and installed it:




After I finally got the CRL installed on the SCS server, I restarted the SCS service and attempted the provision again. Sure enough, I was able to complete the process and the Cert Authority issued the TLS certificate for the AMT device.




There are quite a few different methods of publishing / referencing the CRL in your environment, for more information see this technet page:


Instead of relying on the SCS error messages, you could also use a utility like certutil to check the validity of the CRL. Here is a blog post on TechNet on Basic CRL Checking with certutil:


Bill York also has some information related to expired CRLs and SCCM:


If you suspect you are having issues with the CRL in your environment, this manual workaround will get you back up and running, but for a long term fix you should bring it up with your PKI team.

Last week in my Blog I mentioned the Active Directory AMT Objects and things to watch for when working with them. Today I want to share a possible temporary solution.


So to recap, current objects that are created by the SCS are not being treated as true “computer” objects. They end up being returned by queries as user objects, and that leads to some confusion.


One way that I have dealt with these objects is to restrict “list” access to them. This way they do not show up in AD searches and users (like me) are less likely to select them on accident.


So let’s take a look at the object again. I provisioned this client using AD integration and TLS using SCS

Here is the AD Object that was created:


And remember when we search for this particular computer name, it is returned as a user object (notice how I do not have Computer objects selected for object types in the search below)


One way I have found to prevent this from returning in queries is to specifically deny “list contents” for the AMTOU container and all the descendant objects.

In this example, I am logged in with a user account “amt\Josh”, which happens to have full control of the AMT device.


Now we modify the permissions on the OU, and Deny List Contents for This object and all descendant objects for the accounts and groups we do not want to find the AMT objects:


**Keep in mind that the SCS service account still needs Full Control in this OU for provisioning/unprovisioning**

**I would treat this as a temporary workaround and be very careful about making any changes to the OU in your production envronment!**


This will basically “hide” the AMT AD objects from that certain group or user (amt\josh in this case).

Now when we query for the machine name:


We get the above error message, which forces us to add the “Computer” object types to the query:



And finally we only get our true computer AD object returned from the query.


This is just a simple test method we have used in the lab to prevent the AMT objects from showing up in AD searches. You will want to consult with your network/active directory owner for best practices of hiding AD objects in your production environment.


To show that the account is still able to authenticate and connect to AMT, here is a screenshot showing a successful command from the AMT vPro PowerShell Module:



If you have any other creative ways of hiding these objects, I would love to hear about them!

This past week I was experimenting with the Active Directory object that gets created by the SCS when a system is configured with Kerberos integration. I found some things you should be careful with and wanted to share.


First let’s take a look at how we set up the Active Directory to get it ready for provisioning with the SCS:

In order to use Kerberos to authenticate with your AMT device out of band, you need to first set up a new Organizational Unit within your Active Directory:




Now because our SCS Service will be creating the AMT Device Objects, we need to grant the SCS Service Account Create/Delete permission on the container:




In my case im just using my AMT\Administrator account to keep things simple. Once I have the Create / Delete options selected, I am finished with the new OU.


The next thing I need to do is add the Active Directory OU Information to my SCS Profile:





After we set up the Profile in the SCS, we can go ahead and configure the AMT Client using the ACUConfig tool.


Once configured, we should be able to see the Active Directory object of the AMT Device in the OU we created:




Sure enough, there is our object.


Now let’s take a closer look at that object:




Notice that it is a “User” object. Because it is a user object, it will show up by default when you go to add an object to a group or when you are trying to grant users/objects access to a folder or access list.


For example if I had a security group in Active Directory named “SecurityGroup” and I wanted to add this client (e6420) to it, I would search for the name of the system (e6420):




I hit “Check Names” and it looks as though the search returned the computer account:




But look closer and you will see that the object returned was really the AMT Device Object.


Now if you are not careful when trying to add computers to a security group, and assume that this object was the computer object, you could run into issues.


What you want to do is make sure you include “Computers” when searching for objects:




Now when you search:




You will see multiple objects returned, the top one is the “AMT Device Object” (machine name + $iME)

And the bottom one is the acutal OS Machine Object (machine name + $)


To avoid confusion, in a future release of the SCS, the AD object that gets created by the SCS will be created as a “Computer Object”.

I get asked quite a few questions regarding the provisioning certificate install location for Intel® Setup and Configuration Software 8.0. I wanted to take a moment to walk you through the process and hopefully help you avoid any confusion.


Once you have your Provisioning Certificate, you need to install that cert in the appropriate Certificate Store. SCS 8 is expecting this location to be the “Personal Store” of the user that is running the scs service.


For example, the user I am running the SCS Service with is: amt\scs_service


I need to install the certificate in that user’s Personal Store. But what if I cannot log in locally on this account and install the cert? Let’s take a look at how we can accomplish this:


Once you have your provisioning certificate w/private key exported, save it to a location on your SCS server.

Now usually we would just launch MMC and add the certificate snap-in for the local user. Because we cannot log in to the server as the service account (amt\SCS_Service) this can be a challenge. Luckily it is just a matter of launching MMC as a “different user”.


An easy way to do this is to “Shift+right click” on MMC.exe.


I simply search for MMC, and when it pops up in the start menu, shift+right click and select “Run as different user”.

A normal right click will bring up the standard right click context munu as shown on the left. A shift+right click will bring up the extended version as shown on the right:


Now I can use the SCS Service Account



Now you can add the cert snap-in and because we ran MMC as our service account, we can install the provisioning certificate in the Personal Store of the amt\SCS_Service account.




Now right click on the Personal Store and choose “All Tasks-->Import”

And just follow the prompts.





And when you are finished with the import wizard, you should see the certificate show up in the personal store:9.png

Now you are ready to provision!


This is only one of a few different methods you can use to install your provisioning certificate, for more information see the SCS User Guide.

I was investigating some strange certificate issues a while back when I ran across one that I had not seen before. I was attempting to configure a Lenovo T410 using the latest version of the SCS (8.1). I purchased a certificate from GoDaddy for my domain and everything appeared to be set up correctly. Here are a few screenshots of my setup:

I had DHCP set up correctly with option 15 matching my certificate CNAME DNS Suffix:


I had the SCS Service running under my amt\administrator account:


I was logged on my SCS server as amt\administrator:


I had my provisioning certificate installed in my “Current User” certificate store and I had the Private Key:


The certificate chained up to the correct GoDaddy CA with the correct thumbprint:



Everything looked great, until I tried to configure a client:


Hrmm, failed to get private key? But my certificate clearly shows that I have the key! Digging a bit more into what may be causing this issue I found reference to CNG which is Cryptography API: Next Generation, which you can read about it here.


Now when I originally created the CSR for the provisioning certificate, I used the Cert Snap-In in MMC. The first step in that process was to select a template to use:


Sure enough, it defaults to CNG Key. Doing a bit more research, I find out that CNG Key based provisioning certificates are not supported in our Setup and Configuration (SCS) software.


So to fix this, I just ended up creating a new CSR and selecting Legacy Key as my template. Then I went to my GoDaddy account and chose to “Re-Key” my certificate. After that I could once again provision my systems with SCS!


So if you are seeing a similar issue to the one above, there is an easy way to find out if the cert template you selected was a CNG template:

On the server where you have the cert installed, just open the certificate, then use the details tab to copy it out to a file. Once you have the file run this command against it:

     CERTUTIL filename.pfx


If you see “Microsoft Software Key Storage Provider” it is a CNG cert, and you may have issues with SCS.


What you want to see is a cert that uses the Legacy Key template:


Now we are set up and ready to configure!

Last week I wrote a blog showing how to subscribe to and trap AMT WSEvents in PowerShell using the High Level API (HLAPI). That information works great if you want to subscribe to WS-Events, but what about PET events? I will run through a similar demo, only this time we will use PET events:

Again, you will want to load the HLAPI assemblies in PowerShell:



And just as we did with the WS-Eventing sample last week, we need to create a connection to our AMT client. Because I am using Digest and Non-TLS mode for this example, I can connect this way:

$auth = [Intel.Manageability.ConnectionInfoEX+AuthMethod]::Digest

$cs = New-ObjectIntel.Manageability.ConnectionInfoEX(“localhost”,”admin”,”P@ssw0rd”,$False,"",$auth,$null,$null, $null)

$amt = [Intel.Manageability.AMTInstanceFactory]::CreateEX($cs)

This is where we start to differ from the WS-Eventing sameple. The PET event will be sent to port 162. Instead of indicating a listener address with a Port Number, we just assign the address (without the HTTP):

$lstn = ""

Similar to the WS-Eventing example, we also need to choose what Event filter we want to subscribe to. You can find a list of them and what events they cover at this Link

For my simple demo, I just used the “All Events” filter, basically telling AMT to send me an event for any action. Notice the PET filter is defined slightly different than the WS-Eventing example:

$petfilter = New-Object Intel.Manageability.Events.Filter("All_Events")

Next step is to define the senderID type, again I will use FQDN:

$sidtype = [Intel.Manageability.Events.SenderIDType]::FQDN

Now we can pull it all together into a “subscription”:

$sub = New-Object Intel.Manageability.Events.PETSubscription($lstn,$petfilter,$sidtype)

And finally we can use our AMT connection to subscribe, making sure we select PETEvents this time.


Now that we have our subscription, we can move over to our server and create a listener. We start out again by loading the HLAPI:



We can now create our listener:

$listener = New-Object HLAPI.Services.PETEventListener

Now we just need to define what happens when we receive a new message. For this example we will just capture the FQDN of the system sending the message:

Register-ObjectEvent $listener OnNewEventArrived -SourceIdentifier $listener.OnNewEventArrived  -Action {write-host ""; write-host "FQDN: "$Event.SourceEventArgs.Sender ;}

Now all that is left is to start the listener:


Now we are ready to generate another event from my AMT client.

I will push the "Get Technical Help" button again:


As you can see the listener received the alert and displayed the FQDN of the AMT client!


For more information regarding the High Level API and Events check out this Link.

Recently I started working with AMT and WS-Eventing and wanted to share a few things I learned along the way. I found the quickest and easiest way to get started was to download the AMT SDK / High Level API (HLAPI) (link) and start digging into the samples there.  It was pretty straight forward to get the samples working and I was actually able to create a subscription to an event and trap the alerts on my SCS server! Great! After that bit of success I wanted to see if I could replicate the functionality in PowerShell.


First off, I needed to load the High Level API assemblies in PowerShell:




As you can see all you need to do is load the HLAPI.DLL and the IWSManClient.DLL. Once loaded we can create a connection to our AMT client and create a subscription to some events.

Next we just need to create a connection to the AMT client. For my test I just used my local machine, digest user and non-TLS:

$auth = [Intel.Manageability.ConnectionInfoEX+AuthMethod]::Digest

$cs = New-Object Intel.Manageability.ConnectionInfoEX(“localhost”,”admin”,”P@ssw0rd”,$False,"",$auth,$null,$null, $null)

$amt = [Intel.Manageability.AMTInstanceFactory]::CreateEX($cs)


We also need to indicate where the “Listener” will be located:

$lstn = ""


We also need to choose what Event filter we want to subscribe to. You can find a list of them and what events they cover at this Link

For my simple demo, I just used the “All Events” filter, basically telling AMT to send me an alert for any event.

$wsfilter = [Intel.Manageability.Events.FilterName]::All


Next we need to indicate the SenderIDType and where you want to place that SenderID. You can read more about this in the HLAPI/SDK documentation here, but your choices here are: CurrentAddress, FQDN, NONE or UUID.

$sidtype = [Intel.Manageability.Events.SenderIDType]::FQDN

$sip = [Intel.Manageability.Events.SenderIDPlacing]::ReferenceParameter


Now we can pull it all together into a “subscription”:

$sub = New-Object Intel.Manageability.Events.Subscription($lstn,$wsfilter,$sidtype)



Now that we have the subscription defined, we can use the connection to our AMT device to apply it:





Now we have a subscription created on our local host that will generate a WSEvent when our filter criteria are met!

I went ahead and modified this a bit and wrapped a GUI around it:



It works great on the command line, but sometimes it’s nice to have that GUI experience as well.


So now we are generating alerts off of AMT events, but how can we “Trap” them?

Let’s create a simple PowerShell / HLAPI based WSevent Trap / Decoder:


It starts out similar to that of the subscriber script, you have to load the HLAPI assemblies:






Next we just need to create a WSEventListener on our “Listening Server” indicating which IPAddress and Port I want to listen on:


$listener = New-Object HLAPI.Services.WSEventListener([IPAddress]::Any,'999')



Now we need to register an Object Event that will fire when we receive an alert:


Register-ObjectEvent $listener OnNewEventArrived -SourceIdentifier $listener.OnNewEventArrived  -Action {write-host ""; write-host "Address: "$Event.SourceEventArgs.Sender ;    write-host "Alert Type: "$Event.SourceEventArgs.EventData.AlertType ;    write-host "Filter Name: "$Event.SourceEventArgs.EventData.IndicationFilterName ;    write-host "Indication Time: "$Event.SourceEventArgs.EventData.IndicationTime ;    write-host "Message: "$Event.SourceEventArgs.EventData.MessageDescription ;  }



Here you can see that when the listener receives data, it fires off an Action. In our case it’s going to write out to the screen some information about the event such as the Alert Type, Filter Name, Indication Time and the Message of the event.


Once we have our listener created, we can start the listener on our server:




Now I have my AMT client ready to send out alerts based on events and we have our listener ready to trap them.

In my demo I used the Get Technical Help icon in the Intel Management and Security Status Icon:




Now when I hit the “Get Technical Help” button or hit the appropriate key sequence during the boot process, I can trap that event on my server:




Since we subscribed to All Events, it will also trap other event alerts. For example I pulled the battery out of my local machine:




There are plenty of options when it comes to creating subscriptions / subscribing to events, be sure to check out the SDK/HLAPI documentation online for more information: Link

To ensure you purchase the correct Remote Configuration Certificate for your environment, here is a Matrix to reference. Depending on your preference of certificate vendor, you may need to check with your OEM and update your firmware.




VeriSign Provisioning Certs

Posted by jjcopela Feb 12, 2010

Last year there were some changes to the vPro VeriSign provisioning cert.

This change caused some confusion and a lot of users still have questions about it today!


Prior to May 17th2009, if you were ordering a “Standard SSL” vPro Provisioning certificate from VeriSign, you would get a cert signed by the G1 Root CA (742c3192e607e424eb4549542be1bbc53e6174e2).

The G1 root CA was a valid VeriSign hash in the ME firmware.

You would buy the G1 VeriSign cert and it would match the firmware and everything was fine!

You could also purchase the “Premium SSL Certificate” and you would get a cert signed by the same G1 Root CA (742c3192e607e424eb4549542be1bbc53e6174e2 ), again everything worked fine!


After May 17th, VeriSign made a few changes and the “Standard SSL” vPro Provisioning cert is now being signed with the G2 Root CA (85371ca6e550143dce2803471bde3a09e8f8770f).

The G2 hash was just recently added to our firmware. Here is a table showing the versions and which VeriSign cert they support:




G1 Support


G1+G2 Support

Averill< +
Santa Rosa< +
Weybridge< +
Montevina< +
McCreary< +


So make sure you have at least this version of Firmware if you are planning on using the “Standard SSL” (G2) vPro Provisioning cert from VeriSign!


Not all OEMs have released the latest version of firmware, and if your OEM does not have the latest “G2” supported firmware released, you can still purchase the “Premium SSL Certificate” which is signed by the G1 Root CA.


Here is a complete list of supported Hashes:


VeriSign Class 3 Public Primary CA – G1

74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2


VeriSign Class 3 Public Primary CA – G2 (See the table above)

85 37 1c a6 e5 50 14 3d ce 28 03 47 1b de 3a 09 e8 f8 77 0f


VeriSign Class 3 Public Primary CA – G3

13 2d 0d 45 53 4b 69 97 cd b2 d5 c3 39 e2 55 76 60 9b 5c c6


Go Daddy Class 2 CA

27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4


Comodo AAA CA

d1 eb 23 a4 6d 17 d6 8f d9 25 64 c2 f1 f1 60 17 64 d8 e3 49


Starfield Class 2 CA

ad 7e 1c 28 b0 64 ef 8f 60 03 40 20 14 c3 d0 e3 37 0e b5 8a


VeriSign has also updated their Knowledgebase:


There are also a few expert center posts from last year that highlight the changes:


Let me know if you have any questions!


Filter Blog

By date: By tag: