Issue with reusing server CI in ServiceNow

[Stefan van Laar]

Hi community,

I'm encountering a problem with server reuse and how ServiceNow handles this. Below, I’ll outline the situation and would appreciate your insights and potential solutions.

Issue 1:

At our company, servers are being reused, for example, serverAAA. When this happens, server administrators can still see the information from the server's "previous life." This occurs because ServiceNow recognizes the new server as serverAAA based on the serial number, even though the CI name changes (e.g., to serverCCC). ServiceNow retains the historical information linked to the hardware via the serial number to maintain the relationship between incidents, changes, problems, etc., and the hardware. From an ITSM process perspective, it is determined that this information must always be tied to the asset.

Question 1: What would be a good approach to prevent the old information from being visible when servers are reused, while still maintaining the relationship between the CI and the hardware?

 

Issue 2:

A similar issue occurs when blade servers with unique serial numbers are replaced.

• Scenario 1: A new blade server (with a new serial number) that doesn't exist in ServiceNow is added. ServiceNow recognizes the server based on its name and updates the serial number. However, from an asset management perspective, this is undesirable because the historical data pertains to different hardware.

• Scenario 2: A new blade server that already exists in ServiceNow is added. In this case, ServiceNow recognizes the CI based on the serial number and updates the name. This results in two servers with the same CI name, causing the server history to be split across two CIs.

Question 2: How can we prevent serial numbers from being incorrectly updated and avoid duplicate CIs in these scenarios, while ensuring the history of the old server is preserved?

Thanks in advance for your help!

[Mark Manders]

Q1: visible to who? The fact that the information is kept for tickets, is based on the ServiceNow sys_id of the CI, not the serial number. So a Change done on Server AAA in July of 2023, will show as a Change done on Server CCC after that server is renamed. Same with applications running on that server. If Server AAA ran application xyz and the application gets retired (non operational), it will show that it ran on Server CCC after the change of server name.

What information do you want to be 'invisible' and for who? The history of the CI will tell you the name change. Everything related to this CI (same sys_id) will show the new name of the CI.

Q2: a serial number is unique to a device (I assume). So a device should not be updating the serial number. You should discover based on the serial number. You should only be updating the name if that changes, because apparently, those aren't unique for the device. A serial number will never change. If you are reusing names on different devices, you are making it a mess, if you use that for checking uniqueness of the devices (since that's not a unique identifier). Your CI's should be discovered on the uniqueness of the sys_id, creating/updating the device with the sys_id in ServiceNow (so the device serial number will always have the same sys_id) and that preserves the history as well.

[Mani A]

Here’s a detailed approach to address the issues you’ve outlined:

Issue 1: Preventing Old Information from Being Visible with Reused Servers

**Problem:** When a server is reused (e.g., serverAAA becomes serverCCC), the old information associated with the serial number continues to be visible because ServiceNow uses the serial number to link historical data.

**Solution:**

1. **Implement CI Lifecycle Management:**
- **Retire Old CIs:** Implement a process to retire or archive CIs when a server is reused. For example, once a server is repurposed, mark the old CI as retired or decommissioned. This ensures historical data is preserved, but it’s clear that the CI is no longer active.
- **Archive Historical Data:** Use a custom field or tagging system to denote that a CI is archived. Ensure that the historical records are still accessible for auditing purposes but not visible in active CI lists.

2. **Use a Historical Data Table:**
- Create a separate table to archive historical data for retired CIs. This way, the historical incidents, changes, and problems linked to the old CI can be preserved and accessed if needed, without cluttering the active CI view.

3. **Custom Logic for Reuse:**
- Develop custom logic or a Business Rule to handle CI updates when a server is reused. For example, when a server’s name changes but the serial number remains the same, the script can automatically create a new CI for the updated server details and link historical data from the retired CI to the new CI.

Example Script:

(function executeRule(current, previous /*null when async*/) {
if (current.serial_number == previous.serial_number && current.name != previous.name) {
// Mark previous CI as retired
var oldCI = new GlideRecord('cmdb_ci');
oldCI.addQuery('serial_number', previous.serial_number);
oldCI.query();
while (oldCI.next()) {
oldCI.u_status = 'Retired'; // Custom status field
oldCI.update();
}
}
})(current, previous);
```

 Issue 2: Handling Blade Servers with Unique Serial Numbers

**Problem 1:** A new blade server with a new serial number gets mistakenly associated with an existing server due to the name update.

**Problem 2:** A new blade server that already exists in ServiceNow results in duplicate CIs with the same name.

**Solutions:**

1. **Improve Serial Number Handling:**
- **Unique Serial Number Validation:** Ensure that each serial number is unique in your system. Implement validation rules or scripts to prevent updating or creating CIs with duplicate serial numbers.

Example Script to Validate Serial Number:

(function validateSerialNumber(current) {
var gr = new GlideRecord('cmdb_ci');
gr.addQuery('serial_number', current.serial_number);
gr.query();
if (gr.next() && gr.sys_id != current.sys_id) {
gs.error('Duplicate serial number detected: ' + current.serial_number);
current.setAbortAction(true);
}
})(current);
```

2. **Enhance CI Identification Logic:**
- **Name and Serial Number Combination:** Adjust your identification logic to use both the CI name and serial number when importing or updating records. This approach helps ensure that new records are correctly distinguished from existing ones.

3. **Use Configuration Management Processes:**
- **Regular Audits and Reconciliation:** Implement regular audits and reconciliation processes to identify and correct issues with duplicate or incorrectly updated CIs. This involves periodic checks of CIs and their associated data to ensure accuracy.

4. **Handle CI Updates with Caution:**
- **Prevent Automatic Updates:** Modify your import or update logic to prevent automatic updates based solely on the name. Instead, base updates on a combination of unique identifiers (e.g., serial number) and name.

5. **Update Integration and Import Scripts:**
- **Check Existing Records:** Before creating or updating a CI record, ensure that your integration or import scripts check if a record with the same serial number or name already exists. If it does, update the existing record rather than creating a new one.