- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Community,
I need guidance on a scenario I came across.
De-duplication tasks are being created for the Printer class, identifying duplicate CIs. Since the CI identifier is set to the Serial Number attribute, ideally no CIs with duplicate serial numbers should be created. However, during discovery, when a new printer is found, it creates a new CI instead of updating the existing one with the same serial number.
Any help would be appreciated.
Thanks,
Rahim
Solved! Go to Solution.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @AbdulRahim ,
As per my understanding why Duplicates Happen
1. CI Identifier not properly configured
* Even if Serial Number is in the identifier rule, if the identifier is not active or ordered properly, IRE may skip it.
* Printers sometimes don’t return serial numbers consistently via SNMP/WMI. If the probe/pattern fails to fetch it, IRE creates a new record.
2. Mismatch in Data Normalization
* Serial number may include extra spaces, case differences, or prefixes from different discovery sources.
* Example: SN12345 vs sn12345 (with trailing space) → IRE won’t match.
3. Multiple Sources
* If you’re pulling printer data from Discovery and another source (Intune, SCCM, manual loads), duplicate records get created if reconciliation rules aren’t aligned.
4. Reconciliation rules not prioritizing Discovery
* Even if IRE identifies the match, reconciliation may fail if another source is set as the authoritative source for Serial Number.
Solution Steps which might help you -
1. Validate the CI Identifier
* Navigate to CI Class Manager (cmdb_ci_printer class).
* Open the Identifier rule for Printer.
* Ensure Serial Number is part of the active identifier set.
* Make sure it is mandatory and ranked above attributes like Name or IP.
If Serial Number is missing in discovery, IRE won’t use it — consider using a combination identifier (e.g., Serial Number + Manufacturer).
2. Check Discovery Patterns / SNMP Probes
* Run Quick Discovery and check the pattern logs:
* Does it capture Serial Number consistently?
* If not, you may need to extend the SNMP OIDs used to fetch serial numbers (printers are notorious for vendor-specific MIBs).
* If SNMP returns nothing, Discovery inserts a “new CI” instead of updating.
3. Normalize Serial Number Values
* Create a Transform Script or use Normalization Rules to:
* Trim spaces
* Convert to upper/lower case
* Remove vendor prefixes
* Example Script in Identification Rule (Pre-processor):
current.serial_number = current.serial_number.trim().toUpperCase();
4. Review Reconciliation Rules
* Go to CMDB Reconciliation Definitions.
* Ensure Discovery Source = ServiceNow Discovery has authority for Serial Number and other attributes.
* If SCCM or another source is overwriting, it can cause duplicates.
5. Handle Existing Duplicates
* Use CMDB De-duplication (Data Manager) to merge printer duplicates.
* Configure remediation so that relationships and references move to the surviving CI.
Quick Fix Recommendation
* Short-term: Verify serial numbers are actually being returned by Discovery for printers → fix SNMP OID collection.
* Medium-term: Adjust Identifier rules → Serial Number + Manufacturer as key.
* Long-term: Align reconciliation rules across Discovery, SCCM, Intune, etc., so duplicates aren’t created.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
@AbdulRahim Check the Printer Class in CI Class Manager. Printer is a sub class from Hardware, thus, all the identification rules of Hardware should apply to Printer as well.
All -> CI Class Manager -> Search for Printer -> Identification Rule -> Indentifier Entries
As per the training instance, there are 5 entries in this location,
Name /Serial Number/Serial Number, Serial Number Type/Product Instance identifier /Mac Address, Name
Basing on these entries, the devices are identified. Check these for duplicates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @AbdulRahim ,
As per my understanding why Duplicates Happen
1. CI Identifier not properly configured
* Even if Serial Number is in the identifier rule, if the identifier is not active or ordered properly, IRE may skip it.
* Printers sometimes don’t return serial numbers consistently via SNMP/WMI. If the probe/pattern fails to fetch it, IRE creates a new record.
2. Mismatch in Data Normalization
* Serial number may include extra spaces, case differences, or prefixes from different discovery sources.
* Example: SN12345 vs sn12345 (with trailing space) → IRE won’t match.
3. Multiple Sources
* If you’re pulling printer data from Discovery and another source (Intune, SCCM, manual loads), duplicate records get created if reconciliation rules aren’t aligned.
4. Reconciliation rules not prioritizing Discovery
* Even if IRE identifies the match, reconciliation may fail if another source is set as the authoritative source for Serial Number.
Solution Steps which might help you -
1. Validate the CI Identifier
* Navigate to CI Class Manager (cmdb_ci_printer class).
* Open the Identifier rule for Printer.
* Ensure Serial Number is part of the active identifier set.
* Make sure it is mandatory and ranked above attributes like Name or IP.
If Serial Number is missing in discovery, IRE won’t use it — consider using a combination identifier (e.g., Serial Number + Manufacturer).
2. Check Discovery Patterns / SNMP Probes
* Run Quick Discovery and check the pattern logs:
* Does it capture Serial Number consistently?
* If not, you may need to extend the SNMP OIDs used to fetch serial numbers (printers are notorious for vendor-specific MIBs).
* If SNMP returns nothing, Discovery inserts a “new CI” instead of updating.
3. Normalize Serial Number Values
* Create a Transform Script or use Normalization Rules to:
* Trim spaces
* Convert to upper/lower case
* Remove vendor prefixes
* Example Script in Identification Rule (Pre-processor):
current.serial_number = current.serial_number.trim().toUpperCase();
4. Review Reconciliation Rules
* Go to CMDB Reconciliation Definitions.
* Ensure Discovery Source = ServiceNow Discovery has authority for Serial Number and other attributes.
* If SCCM or another source is overwriting, it can cause duplicates.
5. Handle Existing Duplicates
* Use CMDB De-duplication (Data Manager) to merge printer duplicates.
* Configure remediation so that relationships and references move to the surviving CI.
Quick Fix Recommendation
* Short-term: Verify serial numbers are actually being returned by Discovery for printers → fix SNMP OID collection.
* Medium-term: Adjust Identifier rules → Serial Number + Manufacturer as key.
* Long-term: Align reconciliation rules across Discovery, SCCM, Intune, etc., so duplicates aren’t created.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025