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.

This document contains links to BIOS updates and available utilities to some of the OEMs out there. Take a look - this is helpful stuff if you are getting a vPro deployment off the ground!

BIOS Settings for Intel® Active Management Technology (Intel® AMT) Devices

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) :

Using LANDesk 8.8 for your vPro deployment? The quick start guide was just updated for this latest LANDesk release:

Quick Start Guide for LANDesk* and Intel® AMT

Just published - a new wiki that outlines the high level steps for activating your vPro systems. Each step lists the corresponding training and documentation that will help you complete it.

Activation Cheat Sheet

In part 3 we covered troubleshooting common Provisioning Console issues. In part 4 we now focus on those components operating in the background during provisioning. With a functioning install and console, and when the issue appears to be server-related (In part 1 we covered troubleshooting the locale AMT system) now any issues seen must be evaluated on the server side. This article covers this process in a Problem - Cause - Solution format.

Introduction

The server components constitute a lot of ‘background' processes that support what is only seen as Altiris Console points. Much of what goes on in the background is invisible to the user save as a change in status. If setup correctly, machines simply provision. It's when they do not provision that a user should understand the server components so that proper troubleshooting can be accomplished. Note that this covers the symptoms of server-component problems. Some of the symptoms do overlap client-side issues, but in this process we are assuming we've confirmed that the client systems is functioning as expected. If you are unsure, see Part 1 of this article series.

Symptoms

The following symptoms are seen on the Server. Please note that some of the symptoms may appear to be both client and server related making it difficult to know where the issue lies. Use Part 1 in conjunction with this article if necessary in troubleshooting these issues.

• No update to Intel AMT Systems Node - At times this node can abruptly appear stagnant with no new systems coming in and no provisioning taking place
• No Systems Appearing - The Intel AMT Systems node may stay blank even after connecting systems in Setup Mode onto the Network.
• FQDN Not Acquired - Once the SCS receives a hello message, it needs to acquire the FQDN, and if this fails the machine will remain in an unprovisioned state
• No systems Provisioning - This can occur where systems show up in the system, but none of them provision
• Properties Script Failed - This is a common error to be covered separately, though many of the above symptoms end up throwing this particular error

In addition to the symptoms, the following tools were used to troubleshoot the issues to find out which particular issue afflicted the Server:

1. AMT Logs
2. OOB Trace Loggging
3. Wireshark

See Part 1 in this article series on how to use these. These will be referenced in the below items.

No update to Intel AMT Systems Node

Problem

The typical symptom is an abrupt stop to updates on this node. For example if you have a number of provisioned systems, with systems added as systems are brought up on the network, and abruptly they stop updating or being added, this is indicative of this issue.

Tools:

AMT Logs - No updates to this log occur.

Cause

AMTConfig Service - The AMTConfig service has stopped, crashed, or is in a hung state. This isn't common in version 3.0 of SCS or higher.

Resolution

Check that the AMTConfig Service is running.

• 1. Go to Services Manager under Administrative Tools.
• 2. Check the Service named AMTConfig to make sure it is running.
• 3. If the service is not running, start it. If the service is running, try restarting it just in case it's in an hung state.
• 4. Once the service is up and running again (if this is the issue) provisioning should start occurring.

No Systems Appearing

Problem

The symptom is that no machines appear in the Intel AMT Systems list when the page is refreshed over a period of time when new systems are expected. The page ties directly into the IntelAMT database to populate the systems, so if the list isn't updating on the page, the list is also not updating in the database.

Tools:

AMT Logs - I. No entries found

II. No entries found

III. Invalid PID Map error

Wireshark - II. On the client the "Hello" packet is sent, but on the server it never arrives.

Cause

The causes vary. See below for known causes for this issue:

1. I. AMTConfig Service - The AMTConfig service has stopped, crashed, or is in a hung state. This isn't common in version 3.0 of SCS or higher.
2. II. "Hello" packets - The routing of "hello" packets is not configured correctly, so clients can't reach the Provision Server.
3. III. PID rejected - The PID provided in the "Hello" packet is not contained as a valid security key in the IntelAMT database. This is only seen in the AMT Log found in the Provisioning Console under Logs, selecting the ‘Log' icon.

Resolution

See the steps to follow for the above causes.

1. I. AMTConfig Service
   • 1. See the resolution to the section No update to Intel AMT Systems Node.
2. II. "Hello" Packets
   • 1. In the Provisioning console go to the DNS Configuration node. Does the ‘Test' button allow Provisionserver to resolve back to the IP of the Notification Server?
   • 2. If yes, go to the segment of the network the client is on and try to ping the name ‘Provisionserver'. Does the IP resolve?
   • 3. If answer to either question above is NO, a CNAME record needs to be created on each DNS Server to route to the IP address of the Notification Server.
3. III. PID rejected
   • 1. In the Provisioning Console go to the Security Keys node under the Configuration Service Settings. The list of unused PID and PPS combinations are listed.
   • 2. In the IntelAMT database, within the csti_pid_map table all used and unused security keys are listed. The ones with a value ‘True' in the ‘Used' column will not show up in the console.
   • 3. Either import the keys if the OEM placed the AMT systems in TLS-PSK Setup Mode through the import button in the Security Keys page, or manually enter the PID PPS.

FQDN Not Acquired

Problem

One or more Intel AMT Systems are registering in Intel SCS, but they never show an FQDN and never move out of the ‘Unprovisioned' status. In the AMT Log often these systems show the error ‘Properties Script Failed' (note that the cause of this error can be many, and this issue is but one of them).

NOTE! If no system is provisioning the issue may not be FQDN related. See No Systems Provisioning in this article for more information.

Tools:

AMT Logs - Properties Script Failed messages

OOB Trace - Unable to locate FQDN (Fully Qualified Domain Name) entries

Cause

Intel SCS calls the Out of Band Provisioning or Properties script oobprov.exe to do a number of things. The first thing it does is obtain an FQDN for the machine needing provisioning. If it fails to obtain an FQDN Provisioning will fail and the computer will remain in an unprovisioned state until oobprov.exe can successfully locate the FQDN.

Resolution

To find the FQDN, oobprov.exe runs through a number of checks. The suggested method is to have the Altiris Agent installed and have run the OOB Discovery Task (located in the Altiris Console under View > Solutions > Out of Band Management > Configuration > Out of Band Discovery > Out of Band Discovery). This populates the Altiris database so it has both an FQDN in the AeX AC Location data class and the UUID in the Inv_OOB_Capability data class. If this data is not available, another option is to check DNS resolution as a method. In the Altiris Console look under the Resource Synchronization node, within the Intel AMT Systems folder. As shown below, this option enables oobprov.exe to use DNS IP resolution as a method.

NOTE the warning found directly below the checkbox: Warning! Using DNS for IP to FQDN resolution might lead to incorrect profile mapping. Make sure your DHCP server is configured correctly to give update the DNS server for dynamic addresses.

No systems Provisioning

Problem

Systems are added regularly to the Intel AMT Systems node, but they never provision. This includes never getting an FQDN (see the above section for more information), though the cause may not be the inability of oobprove.exe to obtain the FQDN.

Tools:

AMT Logs - Provisioning Script Failed messages

OOB Trace - No references to oobprov.exe

Cause

If not an FQDN mapping issue, this issue stems from a timeout value in the IntelAMT database being set to 0. In the IntelAMT database, in the table csti_configuration, under the column Props_script_timeout if the value is 0 IntelSCS will timeout before it even has a chance to call oobprov.exe.

Resolution

Normally only one row exists in this table. The following SQL query will properly update this value to the default level. The default is 180 and should be set.

USE IntelAMT

UPDATE csti_configuration

SET props_script_timeout = 180

WHERE use_props_script = 'True'

Execute the script within SQL Query Analyzer or SQL Enterprise Studio to update the value.

Properties Script Failed

Problem

This message can mean a number of things, including the symptoms described in the preceding two section. This message can continually appear into the AMT logs as provisioning is attempted over and over.

Cause

The causes of this issue vary. The basic explanation is that when oobprov.exe is called, if it returns anything other than success, the resulting error message in the AMT logs is ‘Properties Script Failed'.

Resolution

See the above two sections for the symptoms No Systems Provisioning and FQDN Not Acquired, but for additional information see the following article:

• http://juice.altiris.com/article/2982/troubleshooting-properties-script-failed-out-band-management-solution

Conclusion

This concludes the troubleshooting section for the Provisioning process. For the most common issues, the resolutions and steps presented in the first four parts of this series will resolve them. I also hope the methodology here helps explain how the background processes are working. In the next parts of this series we'll cover troubleshooting issues with the management components after systems have been successfully provisioned.

**This is a repost of this article to the Activation section of the Site**

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:

OOBM	Intel SCS	AMT
6.1	1.2	2.0
		2.1
	1.3	2.0
		2.1
6.2	3.0	2.0
		2.1
		2.5
		3.0
	3.2.1	2.0
		2.1
		2.2
		2.5
		2.6
		3.0

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:
  • c-main
  • c-main

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:
   • http://juice.altiris.com/article/3612/using-intels-rct-tool-restart-amt-hello-packets-enterprise-provisioning
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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:

• c-main

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: c-main 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.

1. 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.