Delaying Discovery based on date

[Jason_DaSilva]

We have an interesting issue happening due to our HAM process. 

---Long Story---

When we order equipment from our vendor, Assets are created along with that a Shell CI record is created.  This is because at the time of ordering, we have the model and some other information, but no serial number.  With our current automation process, the vendor has all endpoints pre-loaded with our company image.  I assume that in order to make sure that they do not ship any DOA equipment, they fire them up to test.  Once a complete order has been tested, they send us the serial numbers which then are added to the Assets and the shell CIs are updated with that information.  The problem is that when they boot up the endpoints to test, CrowdStrike sees them, then from our CrowdStrike Service Graph (CS-SG) CIs are created, since there is no matching serial number at that point.  This causes a lot of things to break in our process, along with the duplication that happens both on the CI table and the Asset table (since an asset is created with the CI creation on discovery)
Since this is only an issue with Computers I have set an IRE Data Source Rule preventing the CS-SG from creating CIs on the Computer table, but we may need this to be active.
---Short Story---
CrowdStrike data has a field called 'first seen'.  Is it possible to delay the ingestion of data from the CrowdStrike Service Graph by an offset of this field?  For example, to not import the discovery on the computer table unless the current date is 45 days later than the first seen date from the imported data?

[Pratiksha]

Assuming that the data you are entring in cmdb has discovery source mapped to it. Now you can create a reconciliation rule to define the precedence of data insertion. On top of this create a data refresh rule (

Specify data refresh rules to determine if a CI is stale for a specific discovery source. Such CIs can then be updated by a lower-priority authorized discovery source.)

Doc : https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/configuration-manag...

Regards,

Pratiksha

[Jason_DaSilva]

I think you are miss understanding what I am looking for.  Our problem is that data from CrowdStrike comes in before the asset information is supplied.  When this happens, since there is no matching CI with a serial number, a new CI is created, and with that a new Asset.  When the actual data is added to the asset (imported excel from the vendor's ASN file) we end up with 2 records for both the CI and the Asset.  This also messes with our receive process.  

My hope is that when the data comes in, if it is less than 45 days old (based on a comparison from the first seen date supplied by CS to the current date) that the data is ignored.  If it is older than 45 days, then the data is pulled in.  Right now I have set it to only update from CrowdStrike, but due to the nature of some of our equipment, I will need to turn that back on soon.

[Pratiksha]

You need to make sure when vendor ASN filles comes it go via IRE. In that way it will just update and not create a new one. 

Check this out : https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/configuration-manag...

Regards,

Pratiksha

[Jason_DaSilva]

Its the order that we receive the data that is causing the problem.  

1. the order is placed which creates an asset in SN, which in turn creates a CI.  Because the equipment needs to be tested before the actual device can be named (at the vendor side), there is no serial number for this CI (shell record).

2.  The devices are tested at the vendor, which triggers crowdstrike.  the CS-SG picks up this new device and tries to match on serial number.  It does not find one because we haven't been sent them yet.  It creates a CI which creates a different asset.

3. We get the ASN file, and now get the list of serial numbers for the assets ordered which is then applied to the shell record CIs.
At this point we now have the vendor defined asset related CI, and also the discovered CS-SG CI with its own related asset.  The vendor defined Asset has all the HAM data associated with it, and because CS-SG made its own CI and asset, it will only update that.

We have recently lost the DEV that worked the initial ASN scripted import (I'm sure he would have gone through the IRE), and this issue is really only a problem since we started to use the CS-SG.  CS gives us very important data on our CI relating to VR, so management does not want to turn that off.  We are ok at this point with having it not make an CIs on the Computer table, but that means we are missing out of some of our DMZ equipment.