This white paper article provides general information and best practices on how to understand, prevent and troubleshoot duplicate assets. Note: This article is primarily intended for CMDB Solution duplicate assets and merges. Most references are therefore regarding these types, not other non-CMDB duplicate assets and merges, which are only briefly discussed.
Other non-CMDB duplicate assets and merge types therefore only briefly covered.
What Are Duplicate Assets and How Are They Caused
The phrase "duplicate assets" refers to when two or more asset records share at least one data class value between them, such as the resource name or serial number. These asset records may or may not refer to the same physical asset. In general, this refers to one of the following:
Duplicate assets can be any asset type but are most often associated with duplicate computer records. Depending on how the computers and their data classes were brought into the Symantec Management Platform often determines how the duplicates were caused. For example, the following are three scenarios where duplicate computers can be caused:
Scenario 1: Duplicate computer names (normal)
Computers that have duplicate resource names are not considered to be an issue because the resource name data class by itself is not required to be unique. These can be created in a variety of ways, such as by the following:
Scenarios 2 and 3: Duplicate unmanaged and managed computer records (normal) and running the Inventory to Asset Synchronization task (normal)
A common business practice is to create unmanaged "staging" computer records before their physical computers are brought into the Symantec Management Platform. Later, their physical computers are integrated with a Symantec Management Agent and create managed computer records. These processes result in one unmanaged computer record and one managed computer record both referring to the same physical computer. The following example demonstrates how duplicate assets can be created by unmanaged and managed computer records. Note: Computer records created by Asset Management Solution, CMDB Solution, Barcode Solution or Data Connector are all considered to be unmanaged records with only CMDB Solution/Asset Management data classes initially. Computer records created by a Symantec Management Agent checking in for the first time are considered to be managed records with only Core data classes initially.
Scenarios 4 and 5: Reusing or renaming computer names to use old computer names (abnormal)
A computer has a name that is desired to be reused. This may occur after the old computer is retired and a new one then reuses the old name. This can result in duplicate IP addresses or MAC addresses, among other duplicate issues. The following examples demonstrate how these can occur. WARNING: It is not recommended that users reuse or rename computers to use an old computer name that already exists in the Symantec Management Platform database as this will result in serious issues throughout the Symantec Management Platform. Duplicate computer records will occur as well. For more information on troubleshooting this issue, refer to the following article:
Computer's Manufacturer, Model, Serial Number or System Number are incorrect or missing
If the Inventory to Asset Synchronization task is running when there is duplicate Inventory records, this then causes CMDB Solution duplicates for its Manufacturer, Model, Serial Number and/or System Number values, depending on what is duplicated in the Inventory Solution records. (This is the 5th scenario.) When this occurs, this causes a domino effect of duplicates which starts with the process, continues to Inventory Solution data classes and finally ends up also in CMDB Solution data classes. Symptoms include being unable to save changes to affected records (for the Serial Number and System Number duplicates only), as duplicate unique values cannot be resaved. The preferred way to resolve this is to correct the practice that is causing the duplicate Inventory Solution data classes, clear out the incorrect and duplicate CMDB Solution data classes (such as with a CMDB rule), and then finally, rerun the Inventory to Asset Synchronization task to update CMDB Solution's data classes with the correct values from the Inventory Solution data classes. WARNING: It is not recommended to run a merge task to resolve these duplicates, as the most recent record will be the one that is kept, which in this case, is usually the duplicate.
Scenario 6: Reusing IP addresses or MAC addresses
As discussed in scenario 4, reusing computer names can also result in duplicate IP addresses or MAC addresses. This can also be caused by:
For VMs, if care is not taken to ensure that each one has its own unique IP address and especially MAC address, this can result in duplicates or in automatic merges between two different computers. In some situations, this may be normal. For example, if an old VM has a specific MAC address and this is reused to be a new VM but retains its original MAC address, this can result in to computer records in Altiris but with the same MAC address.
Normally, computers with duplicate MAC addresses are found and instantly merged when the new one checks in, but in some cases they aren't. In some cases these are not able to be merged and remain unresolved. Unfortunately there is no merge rule other that CMDB Solution offers to be able to further attempt to merge records like this, at least not using the MAC address as the merge key. If there is another key field that can be used, then a CMDB merge could then merge these records. If, however, the user doesn't want them to be merged but these are two different computers, the only solution is to fix the root cause: correct the MAC address on one of the computers so that it unique. If the future, do not force the virtualization software to use a static MAC address and do not reuse VMs that have the same MAC address (if they are functionally different computers then) as either will result in this issue reoccurring.
Once the VM has unique MAC address, when its Symantec Management Agent checks back in, this will then be updated in the Altiris database. If the VM does not have a Symantec Management Agent, then this would need to be manually changed in SQL instead, specifically, in the Inv_AeX_AC_TCPIP table.
Scenario 7: Network Discovery
Using Network Discovery, in some configurations, can result in duplicate computer records. Often it will catch this and automatically merge the two records together. When this fails to do so, generally the following are what causes the two records to be not merged:
Shared and Duplicate GUIDS
If asset records share the same GUID, or, a GUID is somehow duplicated many times in a table, these become very serious issues. While these could be thought of as duplicate assets, and in fact the Resource Merge Rule can merge duplicate GUIDs, they are seen as a different type of issue and are not otherwise covered in this article. For information on how to troubleshoot these, refer to the following article:
Resolving issues with shared GUIDs
How to Prevent Shared GUIDs
Shared GUID cleanup script
Detecting computers with Shared GUIDs
How to Find Duplicate Assets
Duplicate assets can be found by a variety of ways, such as when using reports, editing assets, SQL scripts or by searching for data such as for a computer's serial number. Three out of box reports also help find duplicate assets, which can be found under Reports > Service and Asset Management > Merge. These three reports list assets that have duplicate CMDB Solution barcode, serial number and system numbers, respectively.
Another way is attempting to edit an asset that has a unique data class that has an existing duplicate, such as the Serial Number or System Number values. For example:
Example 1: Two (or more) computers have duplicate unique data class values already, which were caused by unknown processes.
Example 2: The user tries to give another computer a duplicate unique data class value that another computer already has. This can be unknowingly or by editing a computer that already has this issue.
This error looks similar to the following:
As the error states, there is another record that already has the same System Number data class value, and therefore, the record being edited, cannot be saved (regardless of the changes made, unless that was to remove/change the System Number to be unique).
Refer to the following article that further discusses this error for additional information about it:
Error "An error occurred saving changes. A resource with a duplicate field already exists in the system." occurs when trying to save a computer
Included as attachments in this article are several SQL scripts that can find duplicate assets. These are:
How to Find Merged Assets
While it is not technically the scope fo this article to answer, sometimes it's useful to see what assets have already been merged. Included as an attachment in this article is a SQL script that can do this, which is "Find CMDB merged assets.txt".
How to Merge Duplicate Assets
Duplicate assets can be resolved in one of three ways: by resolving the conflict by editing or otherwise changing the duplicated shared data class values, by deleting the unwanted duplicate or by merging the duplicates together. It's usually easiest to perform an automatic merge of the duplicates to resolve the issue, of which CMDB Solution provides three tasks (described below) that can perform this.
Merge types under control by the user include a manual merge and several automatic merge tasks, all of which are controlled by CMDB Solution. For automatic merge tasks, however, the user should be very cautious about running these as they can delete records that were not intended to be deleted (from the merge process). For all CMDB merges, the latest record is kept, along with the latest updated data classes from each of the records. Certain resource merge keys can cause the wrong record then to be kept, such as if Resource Name were used. If the oldest is the record to keep, and duplicate names were added later (which can be a normal process in the work environment), the correct old record is deleted and merged in favor of the newest, which may not be what the customer expects. For example both Barcode Solution and Asset Management Solution can receive new computers as a single name, such as "New Computer". If an automatic merge task were ran against Resource Name, all "New Computer" records except the latest, last one, are deleted and merged with it; not at all what should be done as the actual valid assets are now permanently deleted. If this were then performed without understanding this, the user would then find that they have "accidentally" deleted a lot of valid assets, with no way to restore these other than re-receiving them or restoring from a database backup.
CMDB Solution Merges
CMDB Solution merge tasks are found under Manage > Jobs and Tasks > Service and Asset Management > CMDB. Note: For a merge task to work successfully, the target records must contain matching duplicate data class values. For example, if Resource Name is used as the merge key, but no duplicate resource names are found but similarly named ones are (for example, TestPC1, Test PC2), these cannot be merged with a merge rule as there are no actual duplicate data class values.
All CMDB merge types, manual or merge task, always keep the latest record and all of the latest data class values of the records to merge. (With the exception of the manual merge, which the user can control which record and data classes are kept.) For example: New Computer (1) was created on 5/1/2014, and New Computer (2) was created on 7/1/2014. New Computer (2) would be kept, and (1) would be deleted. If (1) had data classes that (2) didn't have, they are copied over to (2). Or likewise, if (1) had data classes that were filled out that (2) had, but were more recent, these will overwrite (2)'s as they are newer.
The following are merges that are controlled by CMDB Solution:
Barcode Solution Merge
Barcode Solution can also be configured to auto-merge assets when they are synched from a handheld scanner into the Altiris database. This is not commonly used, but could be enabled and causing "unexpected merges" to occur, therefore. This is located under Settings > All Settings > Service and Asset Management > Barcode Solution Settings > Merge Settings. By default, only Barcode is selected to be a merge key.
Other Merge Types
There are two other merge types, an automatic Core forced merge (controlled by the Symantec Management Platform Core system) and an automatic Network Discovery forced merge:
General Merge Notes
The CMDB Task Inventory to Asset Synchronization
The Inventory to Asset Synchronization task is often mistaken for a merge, which it is not. The purpose of this task is to copy Inventory Solution's Manufacturer, Model, Serial Number and System Number to the same record's CMDB Solution's matching data classes. This task can be used after a merge that has combined an unmanaged and managed record together or it can be used to enable a merge task to then work based on the merge key or Serial Number or System Number. For more information about this task, refer to the following article:
How does the CMDB task "Inventory to Asset Synchronization" work?
Troubleshooting Task Issues
Occasionally, there may be an issue with the merge task. If the Task Server is functioning fine and NSEs are being processed, however, this should not normally be an area of concern. If it is suspected the task is the issue and is not working, review the Altiris server logs to see if any errors are occurring and if the task is firing successfully. If everything appears fine, then most likely if the expected duplicate assets were not merged was because they did not meet the above criteria on how the merge tasks work.
Best Practice When Using Unmanaged and Managed Computer Records
When unmanaged computer records are to be used, is it recommended that these include a key value, such as a serial number or system number. This easily enables them to be later merged using an automatic merge task once Inventory Solution has ran its hardware inventory policy on the managed computer records. If this is not done, however, there are no matching values to find between the two records. It can be difficult then to spot these in the Console as there is no common shared data class value to match them up with. A manual merge would then be needed to merge the two records together.
Finding the Root Cause of Duplicate Assets
By evaluating this article's information, often the root cause of duplicate assets can be understood, which can often by the processes that the user has set up to bring assets into the database. It's it not clear how an asset was created, review its Resource Change History. this can be found by right clicking on an asset in a report and then selecting CMDB Functions > Resource Change History. This lists most changes to an asset including its creation and changes to its data classes.
Unable to find computer by searching for its Serial Number