Discovery scans updating the wrong CI

[barb_perronne]

I have an HI incident on this, but I thought to ask the community as well.   Has anyone noticed that Discovery scans are updating the wrong computer CI?     Before the scan I have 2 computer CI's with different names and after the scan I have 2 CI's with the same name (i.e. duplicate name).

First, I am not blaming Calgary.   I mention it because it is the thing that changed in our environment.   We have been using Discovery scans for years. We saw this on a small scale with Berlin (24 duplicates out of 15k CI's w/ single digit weekly growth).   After upgrading to Calgary the Discovery scheduled scans are updating the wrong computer CI which creates duplicate named CI's. The first week after the upgrade 100 duplicates were created.

For example, 2 computer CI's named CAT and DOG.   They have unique serial numbers for example the name CAT has serial number TABBY1 and the name DOG has a serial number 1COLLIE.   Their IP's are in the same range and are scanned on the same schedule.   After the scan completes there are 2 computer CI's named CAT; one combo is CAT / sn TABBY1 and another combo is CAT / sn 1COLLIE.   After I find the duplicate name, I can run an individual scan on the IP for the (wrong) combo CAT / sn 1COLLIE and it corrects to DOG / sn 1COLLIE.   Is anyone seeing this?

We have the Discovery property "Always update hostname" set to "true" because IT admins will change the computer name.   This property is also helpful for us to track when an IT admin swaps a system board without running asset.com or the like.   We have a business rule on computer CI create that looks to match name and serial number on create.

[mamann]

The ECC queue and Discovery Log are going to help quite a bit here.

When discovering these and the issue happens, the Discovery Log tab should tell you which identifier was used to match the CI. It's also possible that it could tell you there is no match found, but there is matchable info in the CMDB and create a new CI.

I've also seen edge cases where WMI fails to work at a random point during discovery (this is usually a network issue or an issue on the host, not discovery) and it will fall back to using the SNMP probes to finish discovering the device, which will most likely cause the device to be incorrectly classified based on lack of information, and also due to the same lack of information, cause identification to be incorrect.

Again, looking at the ECC queue information and the Discovery Log during and/or after Discovery should help narrow down the issue(s).

[barb_perronne · Accepted solution]

Great tip, mamann.

At it turns out Service Now fixed this in Calgary Patch 3, Hot Fix 3.   We put the fix in TEST on Monday, 17-March.   All tests successful so it will go into production over the week end.

[mamann]

Your're correct.

I just learned this myself two days ago. There was an issue with a piece of code on the MID server which could cause this to happen inconsistently and is fixed in the release you mentioned and future releases.