Duplicate computer resources are created in the Symantec Management Platform (SMP) Console during PXE/preboot deployment. When the device connects to the Notification Server, the system creates a new computer object instead of mapping the device to an existing predefined computer record.
This issue is typically observed on hardware that lacks a unique BIOS Serial Number, or where devices report non-unique identifiers (e.g., "00000000" or empty strings), causing the SMP to default to standard registration logic.
IT Management Suite (ITMS) / Deployment Solution (DS) 8.x
Hardware devices without unique BIOS Serial Numbers or with factory-default non-unique identifiers.
Environments utilizing Predefined Computers for deployment.
Missing/Non-Unique Hardware Identifiers: Hardware often reports generic or empty values for Serial Numbers (e.g., blank, "0000", "To be filled by O.E.M."). The Notification Server cannot differentiate between devices if these non-unique keys are considered valid.
Persistent Unique ID: Deployment images containing a pre-existing DSUniqueID in the registry or aexnsagent.ini cause the server to treat the device as a previously registered machine.
Predefined Filter Instability: If the predefined computer record drops out of the "Predefined Computers" filter prematurely, the physical machine is treated as "unknown," triggering the creation of a duplicate entry.
Step 1: Configure Core Settings to Ignore Invalid Keys
If your hardware consistently reports non-unique identifiers (like empty serial numbers or shared defaults), you can configure the Symantec Management Platform to ignore these specific values during resource identification.
Navigate to Settings > All Settings > Notification Server > Core Settings.
Locate the following settings in the configuration file or settings editor:
InvalidSerialKeyValueList: Add the invalid values reported by your factory-specific machines (e.g., an empty string, "00000000", or "ALASKA").
InvalidUniqueIDsList: Add any specific, non-unique IDs that these factory machines are reporting.
Add the values as a comma-separated list.
Restart the Altiris Service (or the relevant service hosting the registration web service) to apply these changes.
Note: By adding these values to the "Invalid" lists, the SMP will disregard them during the resource identification/merge process, preventing the system from improperly associating devices based on these shared/invalid keys.
Step 2: Clean the DSUniqueID
To ensure each device registers as a unique resource upon deployment, you must strip the existing DSUniqueID from your image and deployment scripts.
Navigate to the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Plugin Objects\Agent Registration\DSUniqueID.
Delete the DSUniqueID value.
Delete the aexnsagent.ini file from the deployment image source.
Ensure that any custom scripts used during the preboot phase do not persist these registry or file values.
Step 3: Verify Predefined Computer Filter Integrity
If the issue persists, ensure that the predefined computer record remains in the "Predefined Computers" filter until the deployment is complete.
Review the SQL definition of your "Predefined Computers" filter.
Ensure that the filter excludes machines that have already been managed.
(Refer to KB 161648 for SQL modification guidance regarding the "All Task Devices" filter to ensure exclusivity.)
Step 4: Log Verification
Review the AeXNSAgent.log on a failing device during the preboot phase.
Check for entries confirming which resource keys are being sent to the server (GetResourceGuidFromWebService).
Confirm that the device is not attempting to read an existing DSUniqueID from a local .ini file.