I often see testers get hung up when they try to repair a system that has been provisioned with an improper FQDN.  Here's a shortlist if things you can look at if you are in a similar situation.

 

If a pre-existing profile assignment exists in SCS, it will be reused, and the client will be provisioned with stale data. Altiris utilizes profile auto-assignment for provisioning clients that do not have a preexisting profile mapping.  Altiris can be configured with entries that map the domain suffix of a to-be-provisioned client to the appropriate AMT profile and desired organization unit.  The remaining setting that needs to be retrieved is the FQDN of the to-be-provisioned client.  To retrieve this, Altiris first attempts to match the to-be-provisioned client to one already in its database by performing a match based on GUID or MAC address.  If those fail to produce a match then a reverse lookup is performed based on the IP address received via the hello packet.  If any of these methods produces stale data, the client will be mis-configured.

 

In order to clean up after an already configured client or a client that is currently being improperly configured, three areas must be examined:

 

SCS:

If a profile assignment exists for a client’s UUID, the client will be assigned the settings in that assignment during provisioning. These assignments can be viewed in the Altiris console via Settings > Remote Management > Out of Band Management > Intel AMT Systems > Profile Assignments.  If an incorrect assignment is present delete it.  If desired a correct assignment can be manually created as a replacement or the profile auto-assignment mechanism can automatically create one at the time of provisioning.

 

Altiris DB:

As stated, the profile auto-assignment mechanism first looks through the Altiris database to retrieve the client’s FQDN.  There are several ways in which this can yield the wrong data.  The most common is if the client was previously in the Altiris DB with a different FQDN.  Several steps must be taken to repair such a situation.

 

Agent Uninstallation:

First, the Altiris agent must be removed from the client. When the agent is installed on the client, the install retains the FQDN of the client at the time the agent was installed.  If the client’s FQDN is changed, the agent will still retain the old FQDN.  The agent periodically re-populates to the Altiris DB, so if an agent with a stale FQDN is left installed, improper entries will repopulate to the Altris DB. To uninstall the Altiris agent is log onto the client and execute c:\Program Files\Altiris\Altiris Agent\aexagentutil.exe /uninstall /clean.

 

Altiris DB clean-up

After the agent is removed, delete stale client instances from the Altiris DB.  This can be done by accessing Manage > All Computers from within the Symantec Management Console, and deleting all stale entries pertaining to the effected client.

 

DNS:

During profile auto-assignment, the Altiris DB is searched, and if no matches are found for the to-be-provisioned client, Altiris will attempt a reverse lookup to retrieve the client’s FQDN from DNS.  If a stale reverse lookup exists in DNS or is cached in the management core’s DNS cache, it can result in improper assignment of the FQDN.  Furthermore, DNS scans are also used to populate the Altiris DB, so if stale forward lookups exist they can result in incorrect entries populating to the Altiris DB.

 

To fix this, view the forward and reverse lookup zones on the DNS server and eliminate any stale entries.  Then on the management core machine execute ipconfig /flushdns to remove any stale entries that may have been cached locally.

 

 

More general information can be found here:

http://www.symantec.com/community/article/1751/what-does-the-resource-synchronization-do-in-out-of-band-management-for-intel-vpro-provisioned-systems