Troubleshooting issues with the Intel® AMT Provisioning process can be a daunting prospect. This series walks through the troubleshooting methods to pinpoint where problems originate and how to fix them. Use Part 1 to troubleshoot the AMT systems when provisioning is not occurring. If the issue is on the client side, this document should provide the tools to diagnose and fix the issue.

Introduction

There are several modes a vPro capable system can be in when it arrives at the customer site. The modes are:

1. AMT disabled
2. AMT enabled, not in Setup Mode (factory default)
3. AMT enabled, not in Setup Mode (Password has been changed in the MEBx)
4. AMT enabled, in Setup Mode for TLS-PSK
5. AMT enabled, in Setup Mode for Remote Configuration
6. 4 and 5 in 'Hello' Packet Mode disabled

Each of the modes have their own quirks, and understanding the modes will help determine what state a system is in, and how to change a system from one state to another.

Versioning

It is important to understand the different versions of not only the local AMT build, but of Altiris' Out of Band Management with the Intel SCS Component. See the following table:

Note the following points when working with the different versions:

• Versions 2.0, 2.1, 2.5 do not support Remote Configuration
• Versions 2.5 and 2.6 are notebooks
• Versions 2.2 and 2.6 are upgrades to versions 2.0, 2.1 and 2.5 respectively and provide the additional functionality of using Remote Configuration for Provisioning
• Intel SCS version 1.2 was unstable. It's recommended to upgrade to 1.3 or upgrade OOB to 6.2.
• Versions 2.2 and 2.6 are not supported for Remote Configuration unless Intel SCS is upgraded to version 3.2.1. Check the following KB articles for more information:
• https://kb.altiris.com/article.asp?article=40076&p=1
• https://kb.altiris.com/article.asp?article=40117&p=1

AMT Setup

Each mode for AMT sets the system in a specific state. See the brief descriptions below of how AMT acts in each state:

1. AMT disabled - In this situation AMT must be enabled either manually by looking into the Intel MEBx (Ctrl+P at startup) or by using the RCT Tool. The following article covers the use of this tool, including data on the command-line switch that can be used to enable AMT:
   • AMT enabled, not in Setup Mode (factory default) - This is the required mode to use USB One-Touch for provisioning. If a user or the OEM has logged into the MEBx and changed the password, the system is no longer in factory default and the One Touch method will not work.
2. AMT enabled, not in Setup Mode (Password has been changed in the MEBx) - One Touch will not work, but manually entering the PSK or setting into Remote Configuration mode will allow the system to enter Setup Mode.
3. AMT enabled, in Setup Mode for TLS-PSK - All Provisioning is encrypted using TLS, however the inner security workings can differ. For Pre-shared Key (known as PID PPS) a public and private key are used. The manufacturer can set a specific PID PPS on the system or a user can auto-generate them. The key is that both the client and server have to have the key in order for authentication to work.
4. AMT enabled, in Setup Mode for Remote Configuration - All 2.2, 2.6, and 3.0 version AMT systems come in this mode unless the OEM is explicitly instructed to set it differently. The point of Remote Configuration is to avoid visiting the AMT system in order to get it provisioned for manageability use.
5. Modes 4 and 5 in 'Hello' Packet Mode disabled - This is common if the system is not immediately hooked up to the production network. All systems will fall into this state if they transmit the 'hello' packet for 24 hours.

Troubleshooting Tools

Before we get into the actual symptoms, we'll cover the tools used to determine where the problem is coming from. While not easy to use, the logging capabilities allow us to verify if the correct processes are functioning on the local system.

AMT Logs

The Altiris Console has direct ties into the AMT Logs captured in the IntelAMT database as a normal part of operation. The Logging level is set in the Altiris Console under View > Solutions > Out of Band Management > Configuration > Provisioning > Configuration Service Settings > and select General. Debug Warning is recommended so you get both Errors and Warnings.

The logs are accessed from Provisioning > Logs > and select 'Log'. Entries here will reveal problems during the provisioning process and other Intel SCS functions.

Click to view.

OOB Trace Logging

Out of Band Management has the ability to log trace details to a debugging program. See the following KB article on details on how to set this up:

• https://kb.altiris.com/article.asp?article=34418&p=1

Trace logging will log everything from console accesses, to oobprov.exe calls from IntelSCS. When oobprov.exe is called, all actions are logged to trace, which can capture problems with the provisioning process.

Wireshark

While the two above tools are distinctly for Out of Band Provisioning, Wireshark tells the whole story of what is coming and going across the wire. It's important to know what the AMT clients are sending, especially in the 'Hello' packet, and what the server is responding with.

Wireshark can be obtained from: http://www.wireshark.org/. While this is the recommended tool, any network trace capture program can be used to examine the network traffic between the AMT client and the Provisioning Server.

Altiris Knowledgebase

All know errors and issues we've run across have been documented in the Altiris Knowledgebase. If you have a specific error, search in the KB and see if we have a documented fix for it. Access it directly here:

• https://kb.altiris.com/

Symptoms

The following symptoms point to problems with the local AMT system or its ability to communicate to the Provisioning Server so that Provisioning can occur.

System Missing

A common symptom for new AMT client systems is that the system, even if believed to be in Setup Mode, doesn't show up in the Altiris Console under Intel® AMT Systems. The causes vary, but the following methodology should help pinpoint where the problem originates.

Is the system sending 'Hello' packets? Walk through this procedure to determine if it is or not:

1. Does the AMT Log contain entries for the system requesting Provisioning? The identifier in the logs is the UUID. One example of an error that would prevent a system from showing up is 'failed to find PID mapping', meaning the requesting system is trying to authenticate with a PID that the Server does not have. Either import any keys provided by the OEM or other provider, or manually enter in the PID PPS under the 'Security Keys' section of the Provisioning Altiris Console.
2. If no entry appears for the system, place Wireshark on both the AMT client and the Server. Now initiate a restart of the 'Hello' packet sequence by turning the AMT client off and unplugging it from power. Drain the capacitors by pressing the power button while unplugged. Generally the power LED will light for a moment before fading dark. Plug the system back in. Does the Server show hello packets (sending on port 16994, with destination port 9971) coming in from the system?
3. If the server doesn't show any incoming 'Hello' requests, fire up Wireshark on the local system to see if we see any 'Hello' packets heading out. If they are actively leaving, something is blocking the traffic from reaching the Notification Server. These ports are standard TCP calls. See the next section labeled 'Provision Server'.
4. If no 'Hello' packets are being sent, the system may be in a non-Setup State. At the AMT system access the Intel MEBx by pressing Ctrl+P at startup. Is the password what was setup during Setup Mode, or will it only accept Admin? If none of the valid passwords work, this machine may be in an unworkable state. Unplug the CMOS battery for 15 seconds to put the machine back in Factory Default Mode, and Setup as necessary.

Provision Server

With Wireshark we can prove a system is sending 'Hello' packets out on the wire. The destination is an important distinction as usually this will be simply the name ProvisionServer. By default, Remove Configuration and TLS-PSK will target the simple name ProvisionServer. It's up to the administrator to properly direct that Hello packet to the Notification Server.

1. If you ping ProvisionServer from a command-prompt, do you get the IP Address of the Notification Server? A CNAME record needs to be created in DNS to correctly direct the hello packets. Check page 21 of the Admin guide located at this KB article: https://kb.altiris.com/article.asp?article=38157&p=1 for more information.
2. Another place you can test the DNS functionality is under Provisioning in the Altiris Console. Select the 'DNS Configuration' node. Click the 'Test' button to initiate the test. A correct IP Address signifies that DNS is working correctly from the Notification Server. The ping test is still important to signify that the client can also resolve the name.
   

   Click to view.

3. If the network cannot support this CNAME, only two methods remain. You can set the Provision Server IP in the MEBx directly. You can also use the RCT tool to simulate the Hello packet and send it to the NS directly (see the previous link to the article on RCT usage).

Conclusion

Part 2 of this series covers the Server components for Provisioning. If you've read all the symptoms and suggestions, you'll note that there is crossover when troubleshooting between the client and the server, regardless of where the problem lies. See Part 2 for the continuation of Provisioning Troubleshooting.

Troubleshooting the Altiris Manageability Toolkit for vPro Technology - Index of Articles

Troubleshooting the Altiris Manageability Toolkit for vPro Technology, Part 2: Provisioning -- Intro to Server Components