Swapping Hard Drives between Laptops to Restore Service Causing Data Discrepancies

[Joe P]

There is a process being utilized to restore service to customers when hardware issues are encountered with laptops which is causing data discrepancies in the CMDB with CIs and Assets.

We are using the SCCM ServiceGraph Connector for loading data from SCCM.

The process is as follows:
Laptop 1 - Serial Number 12345 - Laptop Name - LPT-12345
Laptop 2 - Serial Number 67890 - Laptop Name - LPT-67890

There is a hardware issue with Laptop 1 (screen cracked). The hard drive from Laptop 1 is moved to Laptop 2. Laptop 2 is updated with the replaced serial number 12345. After the laptop has reported in and the ServiceNow SCCM job runs based on the data in the Source Table the CI serial number is updated and sync'd with the Asset record. In the end there are duplicate records with the 12345 serial number and the serial number 67890 is missing.

Is anyone performing shell swaps between laptops? Are there steps to control the updating of serial numbers to maintain data accuracy? Our objective is not to customize the SCCM ServiceGraph Connector.

[Ed Laar]

Hello Joe,

Your scenario is clear: User data should remain with the user when the laptop (let's say basic machine) is swapped. Exchanging the hard drive from the defective into the replacement laptop is a way to reach this goal.

From administrative point of view I do not understand why the serial numbers / asset tags should be changed. Why not simply replace the laptop but swap the hard drives? 

So laptop 1 is replaced by laptop 2. Laptop one is pending repair while laptop 2 is in use?

An other view on this case: Moving serial numbers between Assets can or in the long run will cause other issues. Imagine that the manufacturer comes with a mandatory retrofit for laptops with serial numbers in a certain range. When serial numbers are changed you are never able to track down the involved laptops in such actions.

Hope this helps,

Ed 

[james_L]

We have this issue as well. We did discovered that the source of the problem is indeed in the workflow of the SCCM Service Graph Connector. Since it uses an sccm resourceID to shortcut IRE, when you move the harddrive from laptop 1 to laptop 2, sccm retains the resourceID even as the computer serial number in sccm for that resourceID has changed. It then mismatches and overwrites the computer serial number in the Service Now assets. 

We have discovered that the manual way to fix this issue is to delete all records in sys_object_source related to laptop 1 and laptop 2. This tells the Service Graph Connector to make a new connection for these assets. We are working on setting up a request form for harddrive swaps that when filled out will auto-delete this information on sys_object_source from the associated devices, apply all current asset management inventory from the old device to the new, and return the old device to state = in stock; sub-state=in-maintenance. 

The problem with this approach is human error. Our techs might at times fail to remember to fill out the request form. Does anyone have any more elegant solutions that discovery and fix this issue automatically? 

[sajinalathil]

Hi James,
I was wondering if you’ve tried de-prioritizing the correlation ID by moving it lower in the Identification Rule. The idea is to prioritize serial number first, so that updates to the CI, such as name, OS details, and other attributes can proceed without flipping or overwriting the serial number. I haven’t tested this myself yet, but I was curious to hear how your approach worked for you.
We’re currently facing a similar issue where duplicates are being created using the replacement shell’s serial number, while no record shows up with the original defective serial number.
Also, when you deleted the related sys_object_source entries, did you notice any unintended consequences?

And Joe — did you happen to find any other solution or workaround that worked for your environment?

Looking forward to hearing both your thoughts.