The primary key of identity for an AMT computer is its Fully Qualified Domain Name (FQDN). One of the essential parts of the setup and configuration process (Provisioning) is when Altiris attempts to map a valid FQDN inside the IntelAMT database. This article covers how to handle FQDN issues, including ways to correct invalid entries, the best method to avoid the issues, and how it all works. If you're using Altiris Out of Band Management for provisioning, this is a must read!

Introduction

The two key identity items for vPro are the UUID (Universally unique Identification) and the FQDN. The UUID is contained within the hello packet sent by AMT, but the FQDN is not held within AMT without Provisioning. This means it is up to Altiris to acquire the system's FQDN. While this may sound simple, the problems arise when the system is in its setup process, whether prepping or being imaged, having software and scripts rolled out to provision and join the system to the domain, including when its final identity on the Domain and network are established and it received a new IP Address.

So how is the FQDN used? SCS uses the FQDN as the key identifier. Any provisioning type requests after initial provisioning are executed using the FQDN as the identifier. If the FQDN is invalid, Intel SCS cannot reach the system. One other primary use is in TLS certificates for encrypted AMT management traffic.

Preferred Provisioning method

For specifics I'll refer to the Best Practices document and the Optimal Provisioning POV, but for the general steps to be followed specifically for the FQDN I'll provide the steps below.

LINKS: Best Practices for Configuring an Intel vPro Capable System within the Symantec\Altiris vPro Toolkit

http://www.symantec.com/connect/node/4082

1. Image the system with the Operating System, including any post-imaging work to get the system configured. This includes rolling out software or scripts.
2. Join the system to the Domain after it has its rightful identity. The computer name should be set. When the computer is joined to the domain, this will provide the valid operable FQDN.
3. Install the Altiris Agent on the system. This provides the information for the FQDN in the Inv_AeX_AC_Location table.
   NOTE: If the Altiris Agent was part of the image, make sure the system sends Basic Inventory again after the system has been joined to the network to ensure we have the valid FQDN within the Altiris database.
4. Ensure the Out of Band Discovery package is enabled and configured via the collection to go to all machines.
   NOTE: This step is essential because OOB Discovery will pick up the FQDN from the Basic Inventory and map it in the IntelAMT database. This screenshot shows where the data is located:
   

   Click to view.

5. Now if the hello message was sent before the above steps were completed, normally it will recover as long as the process completes before 24 hours have passed. 24 hours is the period of time the hello packets will be sent from the client. AMT will continue to send hello packets throughout the period UNTIL it is fully provisioned. This helps reestablish connection if the IP Address changes in the middle of the Provisioning process and the Server can't connect back up to the remote AMT system.

Preferred Provisioning Settings

Not all settings within Out of Band are FQDN friendly. The following items affect how Out of Band Management approaches provisioning.

1. Resource Synchronization - Make certain this is enabled! A Disabled Resource Synch policy will halt Provisioning, greatly increasing the change for FQDN problems when it is finally enabled.
2. Use DNS IP resolution to find FQDN when assigning profiles - This option, under the Resource Synchronization policy, is typically unreliable. While this option allows for bare-metal provisioning or Agentless provisioning, it also is at the mercy of the DNS and DHCP environment. It is highly recommended NOT to use this option unless you fully trust your DHCP and DNS environment. Factors to consider are:
   • IP Lease times - The lease times afforded systems may be short, increasing the possibility that when OOB fetches the FQDN via IP the lease will have expired and the wrong FQDN will be mapped.
   • PXE or other auxiliary boots - Often these types of systems will obtain a different IP address from DHCP as their identity is not the same as when the system is booted to the OS.
   

   Click to view.

3. Intel AMT 2.0+ to Profile - This option allows a default Profile to be setup for Provisioning. Make sure you've created a default profile and set it in the Resource Synchronization policy. Without a profile Provisioning will not occur.
4. Intel AMT requires authorization before provisioning - Under the General node within Provisioning, this option stops provisioning from occurring. The profile will not go down to the system until the system is selected, using the right-click to choose 'authorize'. This can aggravate FQDN problems by delaying full provisioning.

FQDN Fixes

Invalid FQDN in IntelAMT

The first issue stems from a variety of causes. The issue is that in the IntelAMT database, shown under the Intel AMT Systems node under Provisioning for Out of Band Management, the FQDN is invalid. The causes vary, but here are a few we've seen:

• Reverse DNS IP Lookup is enabled - Unless your DHCP and DNS environment are rock solid, often IP Address leases expire, and other systems pick up the IPs that the AMT systems originally sent the Hello message with. When this occurs, the wrong FQDN is mapped.
• IP Leases short - Often the IP Lease length can create a problem acquiring the correct FQDN. This can especially have problems with TLS as the FQDN is part of authentication using certificates.
• FQDN is incomplete - When a system is in setup mode, sometimes the mapped FQDN is not part of a domain, resulting in the Host Name only being set as the FQDN.

FQDN has Changed

Another not-uncommon occurrence is when a system changes identity. This can occur in a variety of ways, including:

• The system has been reimaged
• The computer name has been changed
• The computer has been migrated to a new Domain
• The system has switched subnets, resulting in a new FQDN

Regardless of the method, changing the FQDN on the system does not change it in the Intel ME or AMT firmware, and also does not change it within the Intel SCS component database (IntelAMT). When these are not synched up, it can cause problems when you need to manage the system via AMT when the computer is booted to the operating system. This particularly has problems when TLS is enabled and the provisioned certificate no longer matches the FQDN in Windows.

Issues Resolution

Since the Altiris Agent sends Basic Inventory daily by default, the Altiris database usually has a valid FQDN on record in the Inv_AeX_AC_location database table. We can run a query that will capture the correct FQDN from the Altiris database and insert it into the IntelAMT database, correcting any duplicate or invalid FQDN entries. This is the first step. The second step is to update the FQDN within AMT on the local systems. The following processes walk you through the resolution:

Update IntelAMT from Altiris

1. Open up SQL Query Analyzer or Microsoft SQL Server Management Studio.
2. Open a Query window within the database instance that contains both the Altiris database and the IntelAMT database.
3. Run the following query, though for testing purposes you can omit the line 'COMMIT TRANSACTION until you can verify the operation completed as expected. Once validated, run COMMIT TRANSACTION to complete the process:

   BEGIN TRANSACTION
   UPDATE intelamt.dbo.csti_amts SET fqdn = b.fqdn FROM (SELECT il.[Fully Qualified domain name] AS 'fqdn',
   REPLACE(oob.uuid, '-', '') AS 'uuid' FROM 
   altiris.dbo.Inv_AeX_AC_Location il JOIN altiris.dbo.Inv_OOB_Capability oob ON 
   oob._ResourceGuid = il._Resourceguid) b WHERE intelamt.dbo.csti_amts.uuid = b.uuid
   COMMIT TRANSACTION
   
   

4. Done! The FQDNs now match between Altiris and IntelAMT. This will allow communication back to the system for the next set of steps and any other maintenance or management functions.

   Update FQDN on local AMT

5. It is recommended to follow these steps in batches so as to not overwhelm the Intel SCS component. Perhaps run this against 100 systems at any one time, or run it against those systems you know have been updated. While it doesn't hurt to run this against systems that didn't have the FQDN changed from the above process, it is unnecessary if you are able to target those systems with invalid FQDNs.
   Note: This process assumes that the system can be reached via the SCS using the new FQDN supplied by Altiris. For TLS the certificate needs to match the FQDN, and if provisioning occurred with the invalid FQDN this will make the process unusable.
6. In the Altiris Console browse under View > Solutions > Out of Band Management > Configuration > Intel AMT Systems > and select the Intel AMT Systems node.
7. Select one or more systems you need to update the local AMT FQDN on.
8. Right-click and choose the 'Re-provision...' option.
   

   Click to view.

9. Check the Action status node under Provisioning > Logs > Action Status for messages concerning the Re-provision attempts. You can also check the Log node for errors.
10. Done! The systems, when reprovisioned, should have the correct FQDN planted by the IntelAMT database entry that was updated from the Altiris database. This also reassigns the default profile to the system so any updates will be received by AMT.
11. You can also use Task Server to issue a reprovisioning command to the AMT systems. The Task type will be Update AMT Settings.

Conclusion

Use this article to resolve your FQDN issues to ensure AMT functionality is available when it is needed. The above process has been verified, though all environmental potential issues have not been explored. It is advised to test the process in your environment before implementing on a wide scale.