Computer records within the Altiris Console can be generated in a number of ways. Two of these ways are via Active Directory import, and when a deployment job images a computer it creates a new record. The information that is available during creation of these records is different.

A computer record consists of several resource keys that help identify the particular computer. Depending on how the record was created it may not have all of the resources keys completed. For instance, Active Directory only collects information such as computer name, domain, and FQDN. When a deployment job is run, the Deployment Solution (DS) Pectagent is executing in WinPE (automation environment.) Much of this information is not available because WinPE executes in memory only and does not have access to the hard drive; because it may be getting formatted or might not have an OS installed. It is not always possible for the DS Pectagent to collect all of the information necessary to complete the computer record so it relies on the Notification Server (NS) to complete the record once the machine is booted back into production. While in automation the Pectagent queries the NS for preexisting information and if it exists on the NS it collects all the information it can in attempt to complete the computer record. If there is no preexisting information on the NS, the Pectagent hashses the following hardware identifiers: serial number, bios, and mac address. The Pectagent sends that information up to the NS which uses the information to generate a Globally Unique Identifier (GUID) and sends that back down to the Pectagent. It should also be noted that Active Directory import uses a separate method for generating a GUID (it does not use hardware identifiers).

In the problem scenario a computer is brought into the Altiris environment via Active Directory import, and then a deploy job is assigned to it. The computer record created by the Pectagent is assigned a client task the contains a series of tasks to perform. One of the tasks installs the Symantec Management Agent (SMA). After the SMA is installed it sends an inventory that adds the name.domain key to the computer record created by the Pectagent. At this point the NS recognizes that it has 2 records for the same computer and a merge is performed. The method used to detect duplicate is by comparing "Resource Keys" written to the ResourceKey table during creation. Computers will have between 1-5 resource keys depending on how they were discovered. The following query will show computers by order of name and their respecting resource keys.

If any one of the resource keys held by an existing computer object exists during the creating of a new computer, then this will trigger a merge of the two computer resources. For Deployment Solution, the resource key that triggers the merge is called snBios. Occasionally this merge function is triggered during a deployment job after the Symantec Management Agent has been installed. The problem is that the when the merge is performed all of the tasks follow the computer record created by Active Directory import instead of the record created by the Pectagent. This causes the remaining tasks in the deployment job to get assigned to the wrong computer and the job fails out.

Within the task instance details in the Altiris Console the following message might be displayed:

Unable to run the task on a legacy computer while the Legacy Agent Communication mode is turned off.

Cause:

This root cause of this issue is how tasks are assigned after a merge is performed on a computer record. From a Deployment Solution perspective there is nothing that can be done differently between how a Pectagent computer record is created and the way an Active Directory import computer record is created. Both only have certain information available to them to populate the keys within the computer record and nothing can be done to change that. This issue can only be fixed from the task side.

Resolution:

This issue is fixed in 8.1 RU1. Because this required a significant code change this fix will not be back ported to any previous versions. To resolve this issue please upgrade to 8.1 RU1.