For those who have Provisioned Intel AMT Systems, you may wonder what takes place in the background. This article is for you! The process has often been covered at a high level, but here the technical details are provided. Hopefully this helps you understand the inner workings, and provide you information when troubleshooting Provisioning issues. And for those of you who are technically minded, it's also neat to know! This information was compiled working on issues and running through provisioning processes from Symantec Support.

Introduction

Often the Provisioning process for Intel vPro systems has been described as complex. This comes from the fact that the Provisioning process was designed with high security in mind. Since the initial release we have improved success rates by working with Intel to make the process more user friendly without compromising the high level of security. To this end this document will explain the process of Provisioning from a technical level, providing an unfiltered view of the process, also without compromising its security.

Provisioning Flow

The following process assumes that Altiris Out of Band Management and Intel SCS are install, configured, and ready to go. This process follows the flow of Provisioning and what data points, technologies, and methods are used. The level of details is meant to be a resource when working with Provisioning or troubleshooting Provisioning issues, so not all details are available for this process. Note the following points before moving through the process:

• The console items in the Altiris Console under View > Solutions > Out of Band Management > Provisioning are not tied to the Altiris database like most of the rest of the Altiris Console. They connect through a virtual Website (AMTSCS under the Default Website of the SCS Server) to the IntelAMT database.
• Data from two databases (IntelAMT and Altiris) are used during the Provisioning process.

The following articles can assist if you need information on these:

• http://juice.altiris.com/article/1314/altiris-and-intel-reg-vpro-copy-technology-evaluators-guide
• Administrator's and Reference Guides: http://www.altiris.com/support/documentation look under Out of Band Management

1. The server is loaded with a security key or certificate. See the following two items for how these keys are loaded:
   1. For a PID PPS, either keys are randomly generated or imported into the IntelAMT database. Specifically they reside in the table csti_pid_map. Once created/imported, they are available for verifying authentication from an incoming provisioning request from AMT.
   2. For TLS-PKI (certificate-based Remote Configuration) a certificate is loaded onto the server. See this article for details: http://juice.altiris.com/article/4496/obtaining-and-applying-a-verisign-remote-configuration-certificate.
2. The clients need the matching keys loaded onto them. This is done differently depending on the type:
   1. For PID PPS the keys are set by one of the following methods: the OEM sets it, it's entered manually into the Intel ME, or inputted via a one-touch USB flash drive. The PID and PPS are written into the firmware to be used as the authentication credentials when it looks for a provisioning server.
   2. For Remote Configuration (TLS-PKI) at the factory predefined hashes are burned into the firmware for the following certificate vendors (more to come in subsequent versions of AMT). This means AMT already has authentication keys to begin the provisioning process direct from the factory.

• VeriSign
• Komodo
• GoDaddy

1. The client machine, once it has it's keys and has been connected to the network and power, uses one of two methods to find the Provisioning Server:
   1. The IP address of the server can be manually put into the Intel ME, including what port the SCS listener is configured for (default 9971). When this is done, the AMT client will transmit its Hello message directly to the IP Address and port.
   2. The client will transmit its message on port 9971 to the name of ‘ProvisionServer'. If Out of Band Management, Intel SCS, and DNS have been properly setup DNS will route the packet to the Notification Server.
2. The Notification Server is set to listen for AMT Provisioning traffic on port 9971, but can be configured to use a different port if so desired in the Altiris Console under View > Solutions > Out of Band Management > Configuration > Provisioning > Configuration Service Settings > General. The top options labeled: ‘Listen port:".|
   
3. When SCS, via the service AMTConfig (process AMTConfigWinService.exe) receives the incoming "hello" packet, it initiates an authentication request with the client to complete the authentication process, the beginning of which was stored in the packet. Once authentication completes successfully, the process moves on.
4. The service, AMTConfig, catches the incoming packet and logs the data in the IntelAMT database, in the table csti_amts. This table contains all the relevant data for this system's identity.
   
5. Once the system has been logged into the IntelAMT database, Intel SCS uses the database entries under csti_configuration to initiate what's known as the props script. This script is what will assist in the provisioning process. In Altiris case, it is oobprov.exe, located by default at C:\Program Files\Altiris\OOBSC\oobprov.exe. For an example of how Intel SCS knows about this, see this data snippet from the csti_configuration table:
   
6. On a busy SCS server you can look at Task Manager and see multiple instances of oobprov.exe running. The default settings allow 10 threads to work on provisioning requests at any given time. These threads will interface with the Altiris Database via the Altiris Agent on the local server system. In a standard setup the local system is also the Notification Server.
7. OOBPROV runs a SQL query to fetch the Fully Qualified Domain Name (FQDN) for the system it is to provision. The query is based off the following data points:
   1. UUID passed to it via Intel SCS, Source is as follows: Database: IntelAMT, Table: csti_amts, Data Source: "Hello" packet from AMT system, Values used: uuid
   2. Database: Altiris, Data-class: OOB Capability, Table: Inv_OOB_Capability, Data Source: Out of Band Discovery Task, Values used: _ResourceGuid - UUID
   3. Database: Altiris, Data-class: AeX AC Location, Table: Inv_AeX_AC_Location, Data Source: Basic Inventory Agent, whether from Basic Inventory function or Hardware Inventory from Inventory Solution, Values used: _ResourceGuid - Fully Qualified Domain Name
8. The Query accomplishes the following: It takes the UUID from csti_amts, uuid and looks for a match in Inv OOB Capability, uuid. If a match is made, it takes the _ResourceGuid from the same table and makes a match of the same columns name to AeX AC Location. With the match it then reads the values stored under Fully Qualified Domain Name (I'm not sure why they didn't just label this column FQDN...).
9. Next, oobprov.exe hands back the FQDN it's read from AeX AC Location, Fully Qualified Domain Name and passes it to SCS. SCS takes this value and inserts it into the IntelAMT database at csti_amts, fqdn for the matching resource.
10. Next, oobprov.exe fetches the automatic profile set within Out of Band Management Solution. This is done in the Altiris Console under View > Solutions > Out of Band Management > Configuration > Provisioning > Intel AMT Systems > Resource Synchronization. This policy needs to be enabled for this step to work, and a default profile configured and selected under the dropdown labeled ‘Intel AMT 2.0+ to profile:'.
11. The profile provides the operational data for management of the AMT system. After AMT accepts the profile, the Provisioning process is now complete. Before this step, AMT functionality is not available on this system, and after this step only properly authenticated functions will be able to use Intel vPro on the target provisioned systems.

Troubleshooting

The following items can be considered break points for this process. If you've done provisioning you may have run into the symptoms produced by the following items. These are compiled as common areas of trouble in this process.

• The "Hello" packets only transmit for 24 hours, on a back-off schedule, before stopping altogether. If the Server is unable to provision in that time, with IP refreshes becoming more frequent, the system can be in a limbo state. See this article for steps to rectify: http://juice.altiris.com/article/3612/using-intels-rct-tool-restart-amt-hello-packets-enterprise-provisioning
• IP Address changes, refreshes within DHCP during a system's build process can leave SCS with an out of date IP Address for a system that needs provisioning. Coupled with the preceding issue this can leave the system in an unprovisioned state, leaving no ability of the SCS to contact the system to finish the process.
• Remote Configuration certificate is not properly installed on the server, producing authentication failure messages in the AMT logs.
• Oobprov.exe is unable to fetch the FQDN. The AMT system needs the Altiris Agent installed, have sent Basic Inventory when it had a valid FQDN (for example a system in the process of being built might not have a valid FQDN yet), OOB Discovery Task downloaded and executed, and data populated into the OOB Capability data class from the task in order for oobprov.exe to be able to fetch the FQDN. Conversely you can use the option in Resource Synchronization labeled, ‘Use DNS IP resolution to find FQDN when assigning profiles'.

A good resource for troubleshooting issues can be found here:

• http://juice.altiris.com/book/3699/troubleshooting-altiris-manageability-toolkit-vpro-technology

Conclusion

Knowing the underline mechanisms can help when troubleshooting or even when planning your environment. While not all details are provided here, the most essential are.

Intel® AMT Reflector is a software tool designed to allow local management of Intel® AMT Mangement Engine functionality from the local operating system. Removing the need to reboot to verify and change the Intel® AMT host computer name or un-provision Intel® AMT on the computer. This functionality improves debug and factory operations in activating and building Intel® AMT based client environments. This release completes DOPD SW Engineering's original functionality plan for the tool and is therefore marked as a production level release.

This release has the following updates from the Beta release:

· Added a timestamp to Intel® AMT events in the logs generated by the client-side applications.
· Fixed the XML logfile format so that it will be properly recognized by external applications that support the XML file format.
· Fixed the issue where some commands may not succeed on the first call for some Intel(R) AMT systems.
· Fixed the "Browse" button functionality in the Intel(R) AMT Reflector Server configuration window.
· The Intel® AMT Reflector Server now logs the client FQDN for each event.
· Removed the View Log window from the Intel® AMT Reflector Client application.
· Improved the error handling of the Intel® AMT Reflector Client application.

Download the tool here

Here's a 5 minute video overview of the tool's capabilities (Click here to view video on YouTube) :

I witnessed our Internal IT guys defining a BKM that I thougth was very relevant to share out to the community, therefore let me explain.

Challenge: How can you use a mgmt console to read the AMT version so you can write a report in your mgmt console?

Output: You need to have a value placed into the registry that has data whether it's all of the BIOS, MEBx, SOL, HECI, etc.. driver versions, then you can read this data into a mgmt report.

Solution: run MEInfowin.exe and redirect the output to a text file using the “>” operator
Example --

Then you need the write a program in your favorite language such as VB script or C# to read through that text file and write the desired into to the registry.

Then use your mgmt console to read these values & report out. The internal IT guys are doing this to check versions.

Thanks Intel IT folks for the BKM.