Discovered Items - Best Practices for handling new devices

JGNYSTRS
Giga Contributor

‎11-03-2021 11:27 AM

Hello everyone,

Just wanted to see how everyone handles devices that get added into the CMDB as an Unclassed Hardware.   Looking to see how others are addressing the following situations:

  1. Undesired devices in the CMDB are classified as Unclassed Hardware which are not able to be deleted.  How do you handle these devices once they are populated in ServiceNow? (These devices are usually devices that cannot be scanned with Tenable or have no intention of onboarding them at any point.)
  2. Devices that do not have a CI already created in the CMDB. We are unable to Re-classify the Unclassed Hardware or change the class of the record itself.
  3. We have been looking to use the Unmatched state in the Discovered Items log as a work area to verify everything is being managed properly. Is this the most efficient way of handling this or is there a better way to manage Discovered Items?

We have a mix of two different issues with devices that are sitting as unclassed hardware. Would love to hear your process on how to handle these!

Thanks,

Jordan

  • 1,746 Views
2 REPLIES 2

Howard7
ServiceNow Employee
ServiceNow Employee

‎11-09-2021 06:55 PM

Did you confirm your unclassified devices are in the CMDB (cmdb_ci) vs. the separate table for discovered devices (sn_sec_cmn_src_ci) -- this is for items that did not match with a CMDB CI.

0 Helpfuls

Mohammed Kemal
Tera Guru

‎12-28-2021 09:22 AM

Hi Jordan,

Your questions is addressed by creating a reconciliation rules and also creating CI Lookup rules (once you create or modify exiting one make sure you re-apply the rule).

Here is example of report you will get once you re-apply the CI Lookup rules:

xx - Total Discovered items processed
xx - Updated Discovered items
xx - Unchanged Discovered items
xx - Discovered items could not be processed due to Exception
xx - Discovered items updated with CI
xx - Discovered items updated with Lookup Rules
xx - Newly created CIs.

When you create CI Lookup rules make sure understanding the following 5 points. The CI Lookup Rules define how the asset data from your third-party sources will be used to identify Configuration Items in the CMDB using the following fields:

  1. • Name – name of the rule
  2. • Order - order in which this rule should be evaluated relative to other rules
  3. • Lookup method – the method used for matching which is either a pre-built script (IP Address, DNS name, etc.), custom script, or selecting a table and field in the CMDB
  4. • Active – flag that indicates whether the rule is active or disabled
  5. • Source and Source field – the source and specific source field that is being used as input to this rule

Here is an example of CI Lookup rule you can find in the base system and pay closer attention to the commented lines to understand what really going on in the code:

        // _queryMatch function checks if the query returns 0, 1 or more than 1 CI.
// it returns:
//    null: if no CI found
//    ci record: if a unique CI was found
//    the first CI record found: if more than 1 CI was found and log a duplicate error message
//    To avoid specific CI classes ,add the class names, comma separated, to the property sn_sec_cmn.ignoreCIClass
(function process(rule, sourceValue, sourcePayload) {
    var sourceField = {};
    var ignore = global.SecProperty.getProperty("sn_sec_cmn.ignoreCIClass", "");
    sourceField[rule.source_field] = sourceValue;

    var cmdbci = new GlideRecord("cmdb_ci");
    cmdbci.addQuery("name", "IN", sourceValue);
    if (!gs.nil(ignore))
       cmdbci.addQuery('sys_class_name','NOT IN', ignore);
    cmdbci.query();

    cmdbci = _queryMatch(cmdbci, rule, sourceField);

    if (cmdbci)
        return cmdbci.getUniqueValue();

    return null;
})(rule, sourceValue, sourcePayload);

Also create a reconciliation rules that specify which discovery sources can update class attributes, and the precedence order among your discovery sources like the scanners. Ensure that there is a reconciliation rule for each discovery source that is authorized to update an attribute. Reconciliation rules can be defined at the parent and the child class level.

Discovery sources, such as EventManagement, ImportSet, ManualEntry, and Tivoli, are used with the createOrUpdateCI() API to simulate manual updates to CIs. Without reconciliation rules, discovery sources are allowed to overwrite each other's updates to attribute values.

 

For example, you might have the following reconciliation rules. The rules are created for the cmdb_ci_computer class and one of its child classes, the cmdb_ci_linux_server class. The rules specify the following:

  1. Discovery is exclusively authorized to update the name attribute in the cmdb_ci_computer class.

    Because reconciliation rules are derived by child classes from parent classes, this rule also authorizes Discovery to update the name attribute in any child classes for the cmdb_ci_computer class.

  2. ServiceWatch is exclusively authorized to update the name attribute in the cmdb_ci_linux_server class.
  3. ServiceWatch is exclusively authorized to update all attributes in the cmdb_ci_linux_server class, as configured by leaving the Attributes field empty in the rule.

Last but not least the sn_sec_cmn_src_ci table records are set to be not deleted. The ACL is set to nobody and not recommending you to change it. 

If my answer helped you in any way, please then mark it as helpful.

Kind regards,

Mohammed Kemal!

0 Helpfuls