ServiceNow: Identify computer and Server CIs when CI gets repurposed

[RahulY00040]

Hello everyone,

We have an Identification Rule defined at the Hardware level, which is inherited by the Computer class. We also have a separate Identification Rule at the Server level.

Here’s the issue:
When a device is first discovered, it is created as a Computer CI. Later, when the same device is repurposed as a Windows/Linux Server, the Server-level Identification Rule does not match the existing CI and instead creates a new CI in the Server class.

Our expectation is that the same CI should be updated (upgraded/downgraded to Server) rather than creating a new one.

The challenge seems to be that Identification Rules defined at the Computer level apply to child classes (like Server), but Server-level rules do not look up to the Computer class. Because of this, a duplicate CI gets created in the Server class.

Has anyone experienced this scenario? Any suggestions or best practices to handle this?

Thanks,

Rahul

[fknell · Accepted solution]

Hi @RahulY00040,

I would recommend one of these patterns, depending on how strict your Server‑vs‑Computer split needs to be:

1. Use a single, shared identifier across Computer/Server

- Define a common identification rule at the Hardware level (or on Computer) that can match both Computer and Server based on attributes like name, serial_number, and ip_address.

- Let Discovery change the CI class (Computer → Server) via the CI Class Manager or a post‑processing script, rather than relying on a separate Server‑level identification rule.

2. Remove or relax Server‑level inclusion rules

- If you have an inclusion rule on the Server class (e.g.,  os_version = 'Linux' ), consider removing or loosening it so the existing Computer CI can still be matched when the device is repurposed.

- This avoids forcing the IRE to create a new Server CI when it should instead update the existing one.

3. Add a reconciliation / de‑duplication step

- Run the Duplicate CI or CMDB de‑duplication utilities periodically to merge Computer and Server duplicates and keep one authoritative CI.

- You can also add a scheduled job that detects pairs of Computer/Server CIs with the same  name / serial  and merges them, then updates the class to Server.

Hope this helps...

[fknell · Accepted solution]

Hi @RahulY00040,

I would recommend one of these patterns, depending on how strict your Server‑vs‑Computer split needs to be:

1. Use a single, shared identifier across Computer/Server

- Define a common identification rule at the Hardware level (or on Computer) that can match both Computer and Server based on attributes like name, serial_number, and ip_address.

- Let Discovery change the CI class (Computer → Server) via the CI Class Manager or a post‑processing script, rather than relying on a separate Server‑level identification rule.

2. Remove or relax Server‑level inclusion rules

- If you have an inclusion rule on the Server class (e.g.,  os_version = 'Linux' ), consider removing or loosening it so the existing Computer CI can still be matched when the device is repurposed.

- This avoids forcing the IRE to create a new Server CI when it should instead update the existing one.

3. Add a reconciliation / de‑duplication step

- Run the Duplicate CI or CMDB de‑duplication utilities periodically to merge Computer and Server duplicates and keep one authoritative CI.

- You can also add a scheduled job that detects pairs of Computer/Server CIs with the same  name / serial  and merges them, then updates the class to Server.

Hope this helps...

[Vishnu-K · Accepted solution]

Hi @RahulY00040 ,

This is the expected behavior.

If you expect a Computer CI to reclassify as a Server when rediscovered, that will only happen if both classes share the same Identification Rule.

In other words, the Identification Rule configured for the Computer class must be exactly the same as the one configured for the Server class. Only then can a Computer CI switch to the Server class after proper discovery.

Also, ensure that the system property glide.class.switch.enabled is set to true, otherwise class switching will not take place.

So, make sure both Computer and Server have identical Identification Rules for reclassification to work correctly.

Hope this helps you, Please do mark it as helpful . And accept the solution.

Regards,
Vishnu