Duplicate Server CIs After Discovery
The CMDB holds 1,800 Windows server CIs. Both Discovery and SCCM populate the class. An audit finds 240 hostnames with two CI records: the SCCM record carries a serial number, while the Discovery record has the serial field blank but a populated IP address. Incidents are attached to both records, and service maps show the same application dependent on both. Identification and Reconciliation is enabled. The CMDB health dashboard reports completeness at 61% for the server class, with 240 duplicate tasks sitting in the queue. The platform owner wants to delete the Discovery-sourced records to clean up quickly.
1. Explain mechanically why the duplicates were created and what configuration change prevents recurrence.
Read the worked answer
The IRE matches incoming payloads against identification entries for the class. If the identification rule relies on serial number (a common identifier for the server class), then:
- SCCM sends serial -> matches the existing CI -> updates it.
- Discovery sends a payload with serial blank -> no identifier match -> IRE cannot prove this is the same server -> it inserts a new CI.
240 blanks therefore produce 240 new records. This is IRE behaving correctly given bad data; the defect is in the rule and the source data.
Prevention is a combination:
- Add a fallback identification entry (for example name + IP address, or name + object ID) so a record without a serial can still be matched.
- Set reconciliation precedence so that when sources disagree, SCCM wins on serial number and Discovery wins on IP - the field-level rule that stops a blank from being treated as authoritative.
- Fix the Discovery side (credential/permission gaps are the usual reason serial is empty) and add serial to the required attributes.
Deleting records treats the symptom and leaves the generator running.
2. How should the 240 duplicate pairs be remediated without losing incident history?
Read the worked answer
Do not delete. Deleting a CI that has incidents orphans those incidents and breaks the service maps.
Sequence:
- Decide the surviving record per pair - normally the SCCM record, because it carries the serial and is therefore the more complete and better-identified CI.
- Repoint the relationships and references from the losing CI to the survivor: incidents, change affected CIs, service map dependencies, and any related items.
- Merge or retire the losing record only after the references are re-pointed, using the de-duplication/merge mechanism rather than raw deletion, so the change is auditable.
- Re-run service map recalculation and verify the application no longer shows double dependencies.
- Close the duplicate tasks with the resolution recorded, working in batches so each batch can be verified.
Do the identification rule change first (or in the same window), otherwise the next Discovery run recreates the pairs you just cleaned.
3. What ongoing controls would you put in place, and which health metrics would you watch?
Read the worked answer
Controls:
- Field-level reconciliation rules per source, reviewed when a new data source is onboarded.
- Required-attribute enforcement on the server class so a blank serial fails at ingest rather than creating a CI.
- A named CI class owner accountable for the class, with periodic data certification of a sample.
- Monthly duplicate trend review with a defined threshold that triggers investigation.
- Change-side discipline: changes must attach affected CIs, so gaps surface at change time not audit time.
Metrics:
- Completeness (the 61% figure - target the required fields specifically, not all fields).
- Correctness and duplicate count in the CMDB Health dashboard.
- Compliance against audit/relationship rules.
- Relationship health - orphaned CIs and broken service map dependencies.
Track the duplicate count as a trend: if it flattens, the rules are working; if it keeps climbing after the cleanup, the ingestion problem was never fixed.