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

Preferred Provisioning method

LINK: http://juice.altiris.com/article/2810/best-practices-configuring-intel-vpro-capable-system-within-symantecaltiris-vpro-toolki

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

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

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

• 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

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.

Update FQDN on local AMT

1. 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.
2. In the Altiris Console browse under View > Solutions > Out of Band Management > Configuration > Intel AMT Systems > and select the Intel AMT Systems node.
3. Select one or more systems you need to update the local AMT FQDN on.
4. Right-click and choose the ‘Re-provision...' option.
   
5. 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.
6. Done! The systems, when reprovisioned, should have the correct FQDN planted by the IntelAMT database entry that was updated from the Altiris database.

Conclusion

Formerly known as Web Admin for Windows, Real-Time System Manager provides a powerful set of functions for IT specialists. In part 5 of this article series we covered the main points for Real-Time Console Infrastructure troubleshooting. As a natural extension of RTCI, Real-Time System Manager troubleshooting is covered in this article as part 6. With an emphasis on credentials and connection methods, this article provides information to overcome the most common issues seen when using the Real-Time tab for direct, one-to-one computer interaction.

Introduction

• Connection Issues
• Authentication Issues
• IDE Redirect (IDER)
• Network Filtering

Connection Issues

Invalid FQDN

In this example my system is in a workgroup and reported only the hostname as the FQDN, which DNS had no trouble resolving. If this fqdn is not reachable via DNS, we won't be able to connect to the AMT functionality.

NOTE: We use several methods, including IP address, for WMI. WMI functionality may show correctly when AMT is absent in this situation

Use these steps to see the FQDN is the issue:

1. Open the Real-Time tab for the AMT system you are managing.
2. Once the tree loads, open the Real-Time System manager folder, open Administrative Tasks, and click on ‘Hardware Management'.
3. Once the page loads, if AMT is missing as an available technology, take note of the name displayed as in the screenshot above.
4. Go to Start, Run, type in cmd, and click OK.
5. Type in nslookup <name displayed>. In the above example it would read:
   1. Nslookup dellvpro
6. Can DNS resolve this address? If no, we'll need to fix the issue in one of the following ways.
7. FIX DNS and/or the Altiris record: If DNS can be fixed, this is the preferred method. The difficulty is finding out why the Altiris Agent reported the incorrect record. Once DNS is fixed, have the Altiris Agent run Basic Inventory. The table location we pull this out of for management in RTSM is Inv_AeX_AC_Location, column: Fully Qualified Domain Name.
8. Use the ‘Manage' node available in RTSM (see the below screenshot): By putting in the IP address of the system, we'll use the IP to lookup the FQDN and not make any assumptions.
   
9. Update the Servers HOSTS or LMHOSTS files to contain the mapping to the invalid name. For example find the LMHOSTS file, edit it and add a line <IP ADDRESS> <FQDN>, as in this example:
   1. 10.10.10.1 Dellvpro

Real-Time unable to connect

Note: If you use another product such as Dell or HP's plug-ins to this tab, you'll simply not have the ‘Real-Time System Manager' node underneath Real-Time Consoles.

The number one reason this occurs is due to a firewall being engaged. Firewalls need to allow AMT traffic through. If a firewall is enabled, use the following details to resolve the AMT issue:

1. Create an inclusion in the firewall properties.
2. Allow the following ports, based off your environment:
   1. 16992 - For non-TLS encrypted traffic - if you are not using TLS this is the port that will be used for communication
   2. 16993 - For TLS-enabled, encrypted AMT traffic - If https is required for communication with AMT, this port will be used
   3. 16994 - For a note, AMT provisioning uses this port for sending out the ‘hello' packet during the configuration process - this will be used if you initiate a reprovision from RTSM
3. Another options is to disable the firewall when you need to manage the system via RTSM.
4. Unfortunately WMI has a known issue with the Windows firewall where the dynamic ports WMI uses after initiation will be blocked. It's a bug in WMI that has been addressed in Vista. Previous Operating Systems do not have a resolution at this time.

The other issue we've seen is where the system is simply unavailable for one reason or another. AMT is available if the system is off but still connected to the network, but WMI or if the system is unplugged from power or off the network RTSM obviously cannot function. Verify that the system is available if nothing resolves this issue.

Authentication Issues

Authentication Methods

• All known good credentials used to connect via RTSM to a system
• The Intel SCS AMT password sent to systems when provisioning occurs
• Previously successfully used credentials from past RTSM sessions

• WMI digest or Domain account
• AMT digest or Kerberos-authenticated user
• ASF digest or Domain account
• SNMP community strings

Troubleshooting Authentication

1. In the Altiris Console browse to View > Solutions > Real-Time Console Infrastructure > Configuration > select Manage Credentials Profiles.
2. Where does the green checkmark fall? This is the default profile that will be used when connecting via the Real-Time tab.
3. Create a new profile by clicking the blue + on the icon bar in the right-hand pane.
4. Under the Intel® AMT tab check the box ‘Enable this technology in the profile'.
5. Supply the admin user credentials set when the managed vPro systems were provisioned.
6. Under the WMI tab also check the box as above and provide a user that has admin privileges to the target system.
7. Give the profile a name and then save it.
8. Back at the main screen check the box under the ‘Default' column until the green check-mark uses your new Profile.
9. Test to see if this new profile is successful. Note that you'll need to launch IE fresh to use the new settings.
10. If it is not, try entering credentials in manually when you hit the system under the Real-Time tab. See the screenshot below for the connection icon to switch between WMI and AMT authentication. If two show in this area, both technologies are available but not authenticated.
    
11. In one case we supplied only AMT credentials in the Profile which allowed it to authenticate to AMT while a multiple protocol authentication profile failed.
12. Check the collection you are launching Resource Explorer from. Sometimes the identity of the system is incorrect. For AMT you can launch RTSM from the Provisioned collections populated with the Resource Synchronization.

IDE Redirect (IDER)

Redirection Invalid Parameter

Power management operation failed.
Redirection session start has failed. See logs for more details.

The Notification Server log shows the following error:

Log File Name: C:\Program Files\Altiris\Notification Server\Logs\a.log
Priority: 2
Date: 3/9/2007 2:51:05 PM
Tick Count: 10617218
Host Name: <>
Process: w3wp.exe (2436)
Thread ID: 5412
Module: AltirisNativeHelper.dll
Source: RTCI.Trace
Description: RedirectionProvider::StartIDER - RedirectionProvider::StartIDER - IMR_IDEROpenTCPSession: IMR_RES_INVALID_PARAMETER

This is caused by Intel's redirection library requiring a correct floppy device to initiate an IDER session (either floppy image or real removable device). Real-Time System Manager 6.2 can work around this. If you put floppy.img file into Program Files\Altiris\RTSM\UIData folder, then the issue will not occur.

IDER or SOL Disabled

1. Go to the Support site for the OEM for the systems.
2. Browse to the drivers and downloads section for the exact model (note that sometimes the model will differ based on possessing or not possessing vPro technology).
3. Check the firmware updates for a new BIOS.
4. Check the documentation for any new BIOS versions that include vPro to see if they've corrected this.
5. Contact your OEM if they have not and request a status!
6. The only other recourse is to develop an update yourself or manually update the settings by visiting the system.

Conclusion

While at ManageFusion, we had Symantec Director of Strategic Alliances Kevin Unbedacht discuss how Intel vPro Technology enhances the Symantec Altiris Client Management Suite. He demonstrates the following hardware assisted use models with Intel vPro technology based PCs:

• Power Management with Secure Power-On
• Diagnose and Repair PCs Remotely
• Isolate and Recover Infected PCs
• Discover PC Assets

While at ManageFusion, Intel had an opportunity to talk with four leading Symantec Service Integrators who have started deploying and activating PCs with Intel vPro technology within their customers' environment.

In the video below, listen to their thoughts on:

• When to activate Intel vPro technology
• How Intel vPro technology seamlessly compliments the Symantec Altiris Client Management Suite
• How Intel vPro technology delivers on the promise of Wake-On-Lan by being both much more secure and more reliable
• Thoughts on increased customer service levels and return on investment with Intel vPro technology

While at ManageFusion, we had a chance to talk with Lee Bender, Senior Technical Strategist for the Intel Alliance at Symantec Corporation.


Lee showed off how the Symantec Backup Exec System Recovery (BESR) takes advantage of Intel vPro technology. Intel vPro technology extends the reach of BESR, and helps prevent an IT administrator from visiting an end-user's desktop or notebook by enabling remote diagnosis and repair of a downed PC with an unavailable Operating System.


Watch Lee's demonstration of Intel vPro technology with Symantec BESR below:

There were two sessions at ManageFusion 2008 in saving energy on clients in the corporate environment. Almost all hands when up when the question was asked "How many of you have a corporate initiative for green IT?"

HP is pursuing a "top down" power management tool from Verdiem Surveyor for the corporate environment as well as a "bottoms up" tool (HP Power Manager" for installation on clients that lets employees see the actual $ impact of their energy savings using a simple slider bar. I will post the HP link for the client tool on my BLOG when it becomes available

Gartner says PCs consume 40% of the power, servers are 22% even though most enterprises think it's the servers

"It's really neat that HP and others are offering tools to shut down systems to save power, but I want my users to be able to use their system as soon as they come to work without waiting for patches..." and the answer from the presenter was "...what you need is Intel AMT... it can wake systems for patching and put them back to sleep..." The audience had not heard of this...

The hard drive password issue that many companies are facing doing wakeup&patch can be solved by Danbury and a good ISV console

The Altiris Backup Exec Recovery solution using WinPE looks very promising

On April 8th, Intel Vice-President Gregory Bryant was part of the opening ManageFusion keynote led by Symantec's Steve Morton.

In the first part of the keynote, Steve talked about his travels to Intel to learn more about Intel vPro technology. Then Gregory talked about about how customers are realizing value today with Intel vPro technology through better remote management, better power management and better security policies - essentially allowing IT administrators to "levitate." View the first part of the keynote below:

Then, Gregory (along with Steve) introduced Ted Wilkinson, an IT Vice-President at Bank of NY-Mellon. He talked about his infrastructure of 47,000 PCs after the integration of Bank of NY with Mellon Bank, and how Intel vPro technology helps his new infrastructure with enhanced remote power control and remote remediation - which eliminates costs within his new infrastructure.

Also, Gregory discussed future Intel vPro technology directions - including:

• The dynamic virtual client - which blends the manageability of thin clients with the ability to take advantage of the performance of thick clients
• The ability to manage laptops and desktops that are outside of the corporate firewall starting with Intel vPro technology that come out mid 2008
• The integration of hard drive encryption with Intel vPro technology starting in Q3'08 that is easy to manage

Today we are announcing version 1.0.5.4 of the packet decoder. This version includes some minor bug fixes as well as two important enhancements:

+ Prerelease* support for Intel® AMT Versions 4 & 5
+ Results search & sort
+ Logging
*Due to hardware availability, not all constructs have been tested

These enhancements are in direct response to user requests.

Here's a 5 minute movie on the tool.

We are currently reviewing other user's feedback to determine what the next update will contain and when it will be available. Stay tuned.

DOPD Software Engineering Team