Duplicates getting created in CMDB by the Vulnerability response

Niks1
Tera Contributor

‎08-12-2023 09:42 AM - edited ‎08-12-2023 09:43 AM

Hi Experts,


Our discovery schedules runs during off-business hours i.e. mid night onwards till early morning.

Whenever a new Server CI is configured in the infrastructure by Infra teams (Wintel or Linux) and if a Vulnerability check runs on that server (During Afternoon or evening time) then VR response creates an entry in the CMDB against that Server CI with class "Unmatched CI".
Now when the auto discovery runs (midnight) then the discovery also creates an entry in the same table in CMDB as either "Windows Server" or "Linux Server" accordingly, which is a second entry in the same table.

We need to keep the CI created by auto discovery as "Main CI".

These duplicate records breaks the managed CIs selection during raising a change ticket or an incident ticket.
Please share your wisdom on how to resolve this CI duplication issue.

Regards,
Niks

0 Helpfuls
  • 511 Views
2 REPLIES 2

Prabu Velayutha
Mega Sage
Mega Sage

‎08-12-2023 12:35 PM - edited ‎08-12-2023 12:39 PM

Hello @Niks1 

 

Discovery uses identification and reconciliation rules called as IRE,  Hope you should be aware of discovery phases Scanning, Classification, Identification and Exploration.

 

If ServiceNow Discovery locates and finds a match between an Unclassed Hardware item and a newly discovered device that device will be reclassified to its correct class. (i.e. it will be moved from the Unclassed Hardware class to whatever class ServiceNow Discovery / IRE decides it should be).

 

You need to check the CMDB Service class has Identifier attributes like Serial number & Serial Number type, Serial Number, name, MAC address & IP address, etc these are Out of box and this will be applied applied in order defined below 

  1. Check  if Serial number & Serial Number type matches with any of the existing CI in the Server class
  2. Check  if Serial number matches with any of the existing CI in the Server class
  3. Check  if name matches with any of the existing CI in the Server class
  4. Check  if FQDN matches with any of the existing CI in the Server class
  5. Check  if MAC address & IP address matches with any of the existing CI in the Server class

If discovery can identify any one of match CI already exist with the matching attribute of the incoming CI otherwise it will create a new CI.

 

In your case to avoid new CIs getting inserted you need verify any of these Identifier attributes of Server class is matching with CI inserted by Vulnerability check and CI inserted by discovery.

 

Example : If CI inserted by Vulnerability check dose not have serial number then the discovery would check the name If CI inserted by Vulnerability check name is ServerABC and CI Discovery is SrvABC and remaining MAC and FQDN is not available on the CI inserted by Vulnerability check then discovery would insert a new CI.

 

Solution: 

  1. Verify the Identification Rules, poor identification rules leads to duplicate CIs
  2. Set Serial number as mandatory attribute for CI inserted during Vulnerability checks
  3. Verify Schedule of Vulnerability checks, make sure it run after the discovery schedule runs daily
  4.  Create Business Rule to restrict insert of CIs by Vulnerability checks by lookup in the Server table and ignore the record insertion if CI already exist with same name or serial number.
  5. To avoid these duplicate CIs getting displayed for selection you can set the CI class filter for Incident and Change

 

If my answer has helped with your question, please mark helpful and mark my answer as accepted solution.

 

 

0 Helpfuls