How to de-duplicate 2 ESX servers with same name?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-19-2023 01:36 PM
We originally discovered an ESX server in 2017
Recently, a new server was discovered with same name (different OS Version / Build / Managed object reference ID)
- same vCenter Instance UUID and same vCenter Reference
I see the "install_status" on the old one shows "retired"
Also the "hardware_status" on the old one shows "retired"
If I understand correctly, these do not run through IRE, so no de-duplication tasks are generated.
How to best de-duplicate? or do we just set the older server's Operational State to "Retired"?
Should the Operational Status get automatically set to "Retired" when the other status change?
Thank you for your guidance.
Or should
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-19-2023 09:47 PM
I would suggest checking IRE. There may be a rule which is stopping CI to be discovered if it is marked as retired. The best practice around this would be to mark the old one active and let cmdb do its job. It will tell you that one of them is a duplicate.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2023 12:07 AM
@Dave Hoglund Check if there is an identification inclusion rule to apply IRE only for specific set of CIs part of the class and exclude the retired CIs.
About Inclusion Rules:
The inclusion rules are used to narrow down the scope of what Cis are included in the identification process.
CIs which do not match the criteria set by the inclusion rules will not be used by the IRE.
Thus, first we use the identification rules to find the CIs in the CMDB and then we use the inclusion rules to check if those Cis can be used.
But why have inclusion rules in the first place?
As an example, suppose there is a environment requirement that retired windows servers in the CMDB should no longer be updated by data sources. We could use an inclusion rule to stop retired servers from being used/updated by the IRE. A drawback to inclusion rules is that they can lead to "duplicate" CIs if not configured properly.
Note: Configuring an inclusion rule to exclude CIs by class leads to duplicates.
Reference KB: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1064718
Please mark my answer helpful or accept it if it works for you!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2023 05:05 AM
Hi Dave
How to best de-duplicate? or do we just set the older server's Operational State to "Retired"? - It is already retired and CI Inclusion rule must have ignored this and new was discovered.
Should the Operational Status get automatically set to "Retired" when the other status change?--> No STATE Change is done by Discovery OOTB . When First time it discovers it sets the Status.
How to address your use case- COPY IRE attributes from Newly Discovered CI. Update same in OLD one. Old ESX CI which is retired make it operational. Delete newly created CI as OLD CIS may have some INC/CR also connected.
Regards
RP
Regards
RP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2023 05:19 AM
@Dave Hoglund You can use the Duplicate CI Remediator wizard to merge the CIs/attributes and flag/retire/delete your duplicate.
You can manually generate a de-duplication task (sysID1 and sysID2 are the sysIDs of the duplicate CIs):