Multiple CIs created with same serial number but different IPs due to RDP usage – how to handle this

sdf1
Tera Contributor

Monday

Hi everyone,

I’m facing an issue in ServiceNow CMDB where the same physical asset ends up with multiple CIs.

What’s happening

  • We have assets where users primarily work via Remote Desktop (RDP).

  • Because of this, the IP address keeps changing frequently.

  • Discovery runs pick up the new IP each time.

  • Discovery correctly identifies the same serial number and other hardware details.

  • However, instead of updating the existing CI, a new CI gets created with:

    • Same serial number

    • Different IP address

Over time, this results in multiple CIs representing the same physical machine, which breaks CMDB accuracy and asset-to-CI relationships.

Why I think this is happening

  • IP address is being treated as the main identifier.

  • Due to RDP and dynamic IP allocation, IP is not a stable attribute in our environment.

  • Discovery sees a “new” endpoint because the IP has changed, even though the hardware hasn’t.

What I’m looking for
I’d like to know the right way to handle this scenario:

  1. How should identification and reconciliation rules be configured for environments where IPs are not stable?

  2. Is it better to rely on serial number + hostname + other hardware attributes instead?

  3. Are there best practices to prevent duplicate CI creation while still keeping IP data updated correctly?

Thanks in advance.

0 Helpfuls
  • 65 Views
1 REPLY 1

SIVASANKARIS
Giga Guru

Tuesday

Hi @sdf1 ,

 

Your assumption is 100% correct for this duplicate CI creation.

It sounds like your Identification and Reconciliation Engine (IRE) is likely configured with an Identification Rule that prioritizes IP address details too highly, or your discovery source isn't correctly "matching" on the hardware layer before creating a new record.

In a modern CMDB, the IP address should be a dependent attribute, not the primary identifier for a hardware CI. Here is how to fix this and align with ServiceNow best practices.

 

1. Adjust Identification Rules (Hardware Class)

The most common cause for this is a rule that looks for IP Address or MAC Address before it looks for Serial Number. You need to ensure that the Serial Number has a higher priority (a lower "Order" number) than network attributes.

The recommended order for Hardware/Server identification:

  1. Serial Number + Serial Number Type (High Priority)

  2. Serial Number

  3. Name (Hostname)

  4. Network Interface (MAC Address) (Lower Priority)

[!IMPORTANT] Remove IP Address as a standalone identifier. In DHCP or RDP environments, the IP is a "state" of the device, not its identity.

 

How to check this:

  • Navigate to Configuration > CI Class Manager.

  • Open the Hardware class (or the specific class like Windows Server).

  • Go to Identification Rule.

  • Ensure that the Rule for Serial Number is active and has a lower order than rules involving network lookups.

2. Review Reconciliation Rules

If multiple discovery sources (e.g., ServiceNow Discovery, SCCM, Intune) are reporting different IPs for the same machine, you need Reconciliation Rules to prevent "flapping."

  • Priority: Assign a higher priority to the most "trusted" source (usually ServiceNow Discovery or a local agent like ACC).

  • Attribute Level: You can set it so only one specific source is allowed to update the ip_address field, preventing other sources from overwriting it with stale RDP session data.

     

    Navigation & Configuration Steps

    1. Open CI Class Manager:

      • In the Filter Navigator, type CI Class Manager.

      • Click Hierarchy (top left) and find the class you want to protect (e.g., Windows Server or Linux Server).

    2. Navigate to Reconciliation Rules:

      • In the middle pane under Class Info, click on Reconciliation Rules.

    3. Create/Edit the Rule for your "Trusted" Source (e.g., ServiceNow Discovery):

      • Click Add (or select the existing rule for "ServiceNow").

      • Data Source: Select ServiceNow (this represents Discovery).

      • Priority: Set this to a low number (e.g., 100).

      • Attributes:

        • If you want Discovery to update everything, leave this empty (it defaults to all).

        • Recommendation: Explicitly add the IP Address attribute here to confirm Discovery is the primary owner.

    4. Create/Edit the Rule for "Less Trusted" Sources (e.g., SCCM, Intune):

      • Click Add.

      • Data Source: Select the other source (e.g., SG-SCCM).

      • Priority: Set this to a higher number (e.g., 200). Remember: Lower number = Higher priority.

      • Attributes:

        • Select only the specific fields you want this source to update (e.g., Assigned to, CPU Count).

        • Crucial Step: Do NOT include IP Address in the attribute list for this rule. By omitting it, the IRE will prevent this source from overwriting the IP address if a higher-priority source has already set it.

     

    If this is useful, please mark it as helpful and accept my solution...

0 Helpfuls