ITOM POC Help

[SandeepKSingh]

In My organization I have to create a POCs that ..has implemented ServiceNow Discovery and Event Management.

During a discovery run, I notice the following:

• Multiple duplicate CIs are being created for the same Windows Server across different IP ranges.

• Event Management is receiving alerts from both Nagios and SolarWinds for the same server, but they are not correlating properly in ServiceNow (each creates a separate alert instead of merging).

• The CMDB shows 3 different entries for the same server, with different sys_class_name values (cmdb_ci_win_server, cmdb_ci_computer, cmdb_ci_hardware).

can anyone please help me with the Below questions:-

1. Why are these issues happening?

2. Which ITOM concepts and configurations you would use to fix them?

3. What would be the final state of CMDB and alerts after applying your solution?

[AJ-TechTrek · Accepted solution]

Hi @SandeepKSingh ,

This is a classic POC scenario when testing ServiceNow Discovery + Event Management together.

As per my understanding why are these issues happening?

1. Duplicate CIs during Discovery
* Identification and Reconciliation (IRE) rules not configured properly.
* Different probes/patterns or different discovery schedules scanning the same server via multiple IP ranges, but ServiceNow cannot reconcile them into a single CI.
* Overlapping credentials or multiple classifiers (Windows pattern + generic computer probe) can also create duplicates with different sys_class_name.

2. Duplicate Alerts in Event Management
* Event sources (Nagios, SolarWinds) both report on the same CI, but ServiceNow can’t correlate them because:
* CI reconciliation is broken (multiple CIs exist for the same server).
* Event correlation rules (deduplication, threshold, or dependency-based) are not properly configured.
* Missing or inconsistent source CI identifiers (hostname, FQDN, IP).

3.Different sys_class_name entries
* If reconciliation is not aligned, Discovery may classify the same CI differently:
* cmdb_ci_computer (generic computer classifier),
* cmdb_ci_hardware (fallback from serial-based probe),
* cmdb_ci_win_server (Windows pattern).
* This happens when class inheritance rules and classification logic are not standardized.

2. Which ITOM concepts and configurations to fix them?

For CMDB & Discovery
1. Identification & Reconciliation (IRE)
* Review Identification Rules for cmdb_ci_computer and cmdb_ci_win_server.
* Use serial number + FQDN + BIOS UUID as unique identifiers wherever possible.
* Extend IRE rules if required (e.g., prioritizing hostname + domain for Windows).

2. Discovery Best Practices
* Avoid overlapping IP ranges across discovery schedules.
* Configure Credential Affinity so the same protocol doesn’t classify the same host twice.
* Validate Classifier rules to ensure Windows servers always resolve to cmdb_ci_win_server.

3. Data Reconciliation
* Use the Reconciliation Definitions in CMDB to control which source (Discovery, SCCM, Intune, Cloud connectors) wins for each attribute.

For Event Management
1. CMDB Health First
* Make sure there is one golden CI per server in CMDB.
* Ensure alerts from Nagios/SolarWinds resolve to the same CI (cmdb_ci_win_server).

2. Event Correlation Rules
* Configure Deduplication → so same node alerts from multiple sources merge.
* Configure Threshold/Time-based Correlation if repeated events occur.
* Use Alert Aggregation (clustering rules) → e.g., group by node or host.

3. Connector Normalization
* Make sure both Nagios and SolarWinds connectors map events consistently:
* node, source, and resource field should match the CMDB entry.
* Use Event Field Mapping to normalize hostnames/FQDNs.

3. Final State After Fix
* CMDB
* Only one CI for each Windows Server (cmdb_ci_win_server).
* Correct attributes populated (serial, FQDN, IPs, OS version).
* No duplicates across cmdb_ci_computer or cmdb_ci_hardware.

* Discovery
* Runs across multiple IP ranges but reconciles into the same CI due to correct IRE.
* Clean classification — Windows always → cmdb_ci_win_server.

* Event Management
* Alerts from Nagios + SolarWinds for the same server correlate into a single alert in ServiceNow.
* Deduplication ensures no duplicate incidents are created.
* Operators see one CI, one alert, one incident, with cross-source evidence.

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

[Dr Atul G- LNG]

HI @SandeepKSingh 

I’m not an expert in ITOM, but the first point or reason is IRE-related. In the CDB class, you need to define the identification and reconciliation rules for each class to avoid duplicates.

IRE processes help maintain data integrity in the CMDB.

• IRE prevents duplicate CIs by uniquely identifying CIs.​
• IRE reconciles CI attributes by allowing only authoritative data sources to write to CMDB.

https://www.servicenow.com/docs/bundle/xanadu-servicenow-platform/page/product/configuration-managem...

@AJ-TechTrek is best person here to guide you.

[AJ-TechTrek · Accepted solution]

Hi @SandeepKSingh ,

This is a classic POC scenario when testing ServiceNow Discovery + Event Management together.

As per my understanding why are these issues happening?

1. Duplicate CIs during Discovery
* Identification and Reconciliation (IRE) rules not configured properly.
* Different probes/patterns or different discovery schedules scanning the same server via multiple IP ranges, but ServiceNow cannot reconcile them into a single CI.
* Overlapping credentials or multiple classifiers (Windows pattern + generic computer probe) can also create duplicates with different sys_class_name.

2. Duplicate Alerts in Event Management
* Event sources (Nagios, SolarWinds) both report on the same CI, but ServiceNow can’t correlate them because:
* CI reconciliation is broken (multiple CIs exist for the same server).
* Event correlation rules (deduplication, threshold, or dependency-based) are not properly configured.
* Missing or inconsistent source CI identifiers (hostname, FQDN, IP).

3.Different sys_class_name entries
* If reconciliation is not aligned, Discovery may classify the same CI differently:
* cmdb_ci_computer (generic computer classifier),
* cmdb_ci_hardware (fallback from serial-based probe),
* cmdb_ci_win_server (Windows pattern).
* This happens when class inheritance rules and classification logic are not standardized.

2. Which ITOM concepts and configurations to fix them?

For CMDB & Discovery
1. Identification & Reconciliation (IRE)
* Review Identification Rules for cmdb_ci_computer and cmdb_ci_win_server.
* Use serial number + FQDN + BIOS UUID as unique identifiers wherever possible.
* Extend IRE rules if required (e.g., prioritizing hostname + domain for Windows).

2. Discovery Best Practices
* Avoid overlapping IP ranges across discovery schedules.
* Configure Credential Affinity so the same protocol doesn’t classify the same host twice.
* Validate Classifier rules to ensure Windows servers always resolve to cmdb_ci_win_server.

3. Data Reconciliation
* Use the Reconciliation Definitions in CMDB to control which source (Discovery, SCCM, Intune, Cloud connectors) wins for each attribute.

For Event Management
1. CMDB Health First
* Make sure there is one golden CI per server in CMDB.
* Ensure alerts from Nagios/SolarWinds resolve to the same CI (cmdb_ci_win_server).

2. Event Correlation Rules
* Configure Deduplication → so same node alerts from multiple sources merge.
* Configure Threshold/Time-based Correlation if repeated events occur.
* Use Alert Aggregation (clustering rules) → e.g., group by node or host.

3. Connector Normalization
* Make sure both Nagios and SolarWinds connectors map events consistently:
* node, source, and resource field should match the CMDB entry.
* Use Event Field Mapping to normalize hostnames/FQDNs.

3. Final State After Fix
* CMDB
* Only one CI for each Windows Server (cmdb_ci_win_server).
* Correct attributes populated (serial, FQDN, IPs, OS version).
* No duplicates across cmdb_ci_computer or cmdb_ci_hardware.

* Discovery
* Runs across multiple IP ranges but reconciles into the same CI due to correct IRE.
* Clean classification — Windows always → cmdb_ci_win_server.

* Event Management
* Alerts from Nagios + SolarWinds for the same server correlate into a single alert in ServiceNow.
* Deduplication ensures no duplicate incidents are created.
* Operators see one CI, one alert, one incident, with cross-source evidence.

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

[SandeepKSingh]

Thank you so much 🙂

[Ravi Gaurav · Accepted solution]

Hi @SandeepKSingh 
I guess 

Weak Identification & Reconciliation (I&R) rules → duplicates in CMDB.

Improper classification patterns → wrong sys_class_name.

Missing correlation/dedup rules in Event Management → duplicate alerts.

Fix:

Configure I&R rules (FQDN, serial, BIOS UUID).

Correct classification patterns to ensure cmdb_ci_win_server.

Set Event correlation & CI binding rules for Nagios + SolarWinds.

This should help