When using duplicate computer names and/or GUIDs, various issues occur. For example, duplicate or shared GUIDs can occur, inventory being added to the wrong computer, the wrong computers being processed in tasks or policies, etc.
Altiris matches up computers based on their Name.Domain. It can also check for existing GUIDs that match up to computers. If computer names are reused or shared between multiple computers such as being pushed out by an image, this will result in severe issues such as duplicate or shared GUIDs, which prevents Altiris from uniquely identifying which computer is being referenced correctly. This situation can become further complicated if a hierarchy or stand-alone replication rules are used. Because of these requirements, using duplicate computer names is not supported by Altiris*.
(1) When the computer name is duplicate but belongs to a different domain than its duplicate.
(2) When setting up staging (unmanaged) computers that are later to be merged with managed computers. For example, a common process for many customers is the following on how they bring in new computers to their environment:
A staging record of a computer is entered into Altiris. This can be created by manually making a computer in CMDB Solution, using Data Connector to import computers or by Barcode syncs of computers. These are all unmanaged and include only CMDB and Asset data classes for the computer records. Note: This assumes that the staging record has no duplicates: if it does, then this exception no longer applies as duplicate issues will then still occur.
Later, an Agent is pushed to these computers or an image is deployed to them with an Agent. The Agent then checks in, creating a duplicate computer with potentially the same name.
A CMDB merge is then performed to merge the unmanaged CMDB/Asset record with the Agent's record. This creates a combined record with both sets of data classes.
If Inventory Solution was also installed on the computers, the Inventory to Asset Synchronization task can lastly be ran to copy over Inventory's Manufacturer, Model, Serial Number and System Number, to CMDB's (if they are blank).
Note: If the Inventory to Asset Sync is not enabled to work correctly because values are already present, it will not be able to "update" the Manufacturer, Model, Serial Number and System Number with the "new" values, from corrupted records. This becomes then a symptom of a larger issue, that is further discussed in this article. There is no method to separate or split these apart into their original two computers with unique inventory data. The record is corrupted and therefore data is already lost. Information about this can be found throughout this article and also in the following article:
To prevent duplicate computer names, ensure that however computers are brought into Altiris, they are uniquely named beforehand. For example, if duplicate computer names exist in Active Directory, when Altiris performs an Active Directory Sync, this will then cause duplicate computer names. Correct this in AD before performing an AD Sync to avoid this occurring from there.
Do not push images or reuse hard drives with duplicate computer names or GUIDs.
Depending on what's happened, there may be little to no solution. The following possible solutions can be attempted, but which may result in data loss, which may be unavoidable.
WARNING: Once computers are duplicated with overlapping data (such as some data classes show their values are from HP, others are from Dell), there is no method of separating these into two unique computers. The record has become corrupted. The only way to resolve this is to delete the computers (from Home > Service and Asset Management > Manage Configuration Items > Computers and Peripherals > Computer) and probably therefore losing some if its data and then letting the computer's Agent check back in to recreate the current data classes.
If duplicate names currently exist, run a CMDB merge task (Manage > Jobs and Tasks > Service and Asset Management > CMDB > Resource Merge Rule). This may result in the loss of data if the record is corrupted (as noted above).
If duplicate or shared GUIDs exist, refer to the following article on how to resolve these as currently exists in the database:
Lastly, it may be possible to restore the database before all of this occurred. If this is a new system, the user can choose to to simply recreate the database instead to let the Agents check in to create fresh computer records.
The resource history of an asset can shed light on what may have changed it. The following instruction describe how to check this:
In a Symantec Management Platform Console with a computer selected in a report (such as the Computer Configuration Item report), right click on it and then click on Resource Manager.
Click on the View menu > Resource Change History.
While this is not all-encompassing, not everything is recorded here, many events are. This can help clarify what has occurred to an asset to cause changes.