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!
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.
Preferred Provisioning method
For specifics I'll refer to the Best Practices document, but for the general steps to be followed specifically for the FQDN I'll provide the steps below.
Image the system with the Operating System, including any post-imaging work to get the system configured. This includes rolling out software or scripts.
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.
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.+
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:+
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.
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.
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.
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.
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.
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.
IMPORTANT! When the FQDN is invalid in the IntelAMT database, Resource Synchronization can have troubles matching resources with their correct counterparts in the Altiris database. Because of this, duplicates can emerge. If the checkbox in Resource Synchronization labeled: ‘Remove duplicate Intel AMT resources from Notification Server database' is checked, managed resources can get deleted from the Altiris database!
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.
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
Open up SQL Query Analyzer or Microsoft SQL Server Management Studio.
Open a Query window within the database instance that contains both the Altiris database and the IntelAMT database.
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:
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
Done! The FQDNs now match between Altiris and IntelAMT.
Update FQDN on local AMT
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 there may be complications we have not foreseen.+
In the Altiris Console browse under View > Solutions > Out of Band Management > Configuration > Intel AMT Systems > and select the Intel AMT Systems node.
Select one or more systems you need to update the local AMT FQDN on.
Right-click and choose the ‘Re-provision...' option.
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.
Done! The systems, when reprovisioned, should have the correct FQDN planted by the IntelAMT database entry that was updated from the Altiris database.
Use this article to resolve your FQDN issues to ensure ATM 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.