top of page

Increase Granularity with IECs

Introduction | Preconfigured Scenarios | Extending Preconfigured Scenarios

Categorize based on IP Subnets | Categorize based on Naming Conventions

Categorize based on Operating System | Categorize based on Location

Categorize based on CIs present in the CMDB

Categorize based on any Attributes on the Log Analysis Table


 

Introduction

 

Discovery Admin ships with 100s of out-of-the-box IECs.


These out-of-the-box IECs can be further extended or overridden to Increase Granularity by further categorizing the results of the analysis, so we can focus on the Devices that need our attention.

This also enables us to prioritize issues that have the maximum impact on the Business.


This article provides examples and ideas to help understand what it means to Increase Granularity with Discovery Admin, to further contextualize the results of Discovery Admin to align with the unique nuances of each Customer environment.

The scenarios below may directly apply to your environment or provide the foundation to identify other use cases specific to your environment.


After the scenarios to Increase Granularity are understood, they can be translated into requirements to Create and Manage IECs and IECMs after we Understand the Troubleshooting Results.


 

Preconfigured Scenarios

 

Discovery Admin ships with preconfigured rules to Increase Granularity.

These out-of-the-box IECs cover standard use cases that apply to all Customers.


Following are (a subset of) examples of use cases (to Increase Granularity) that are configured out-of-the-box:

  • Categorize errors based on the presence of the DNS Name in the payload.

  • Categorize errors based on the presence of a CI in the CMDB (corresponding to the IP Address being discovered)

  • Categorize generic SNMP Errors into Printers, Routers, Firewalls, etc.

  • Categorize generic SSH Errors into AIX, HPUX, Linux, etc.

  • Categorize generic WMI Errors into Servers and Workstations.


 

Extending Preconfigured Scenarios

 

Examples included in the above Preconfigured Scenarios can be extended to accommodate data specific to the results of Discovery Admin in your environment.


Each bullet in the section above (representing out-of-the-box rules) can be further extended to align with the data, unique to your ServiceNow Instance.


Example 1:

In addition to the standard out-of-the-box IECs, we can extend the capabilities of ServiceNow Discovery to discover a new CI Class, like Telecom Devices, via SNMP Discovery.

In this example, IECs in Discovery Admin can be configured to categorize ServiceNow Discovery errors associated with Telecom Devices so they can be assigned specifically to the Team responsible for supporting Telecom Devices.


Example 2:

Different SNMP Devices (Routers, Switches, Firewalls, etc) are often supported by different Support Groups within the Organization.

So, we must send the correct devices for remediation to its corresponding Support Group.

In this example, IECs can be configured to identify and further categorize the SNMP Errors leveraging the CI Class attribute on the CI.


 

Categorize based on IP Subnets

 

In some scenarios, certain Devices within a specific IP Subnet may be supported by a different Support Group within the Organization.

So, we must send the correct Devices for remediation to its corresponding Support Group.

IECs in Discovery Admin can be configured to identify these Devices and further categorize the errors to segregate them for their respective Support Teams.


This can be done by leveraging attributes consolidated by Discovery Admin that capture the IP Address and Discovery Schedule Information.


 

Categorize based on Naming Conventions

 

In some scenarios, certain Devices within a specific Naming Convention may be supported by a different Support Group within the Organization.

So, we must send the correct Devices for remediation to its corresponding Support Group.

IECs in Discovery Admin can be configured to identify these Devices and further categorize the Errors to segregate them for their respective Support Teams.


This can be done by leveraging attributes consolidated by Discovery Admin that capture the Name of the Device.


 

Categorize based on Operating System

 

It is common to have different Support Groups responsible for different flavors of an Operating System (Linux, AIX, Solaris, etc)

So, we must send the correct Devices for remediation to its corresponding Support Group.


Example 1:

Categorize based on Solaris and Linux:

It is important, that we send the correct Devices (that are not being discovered) to the respective Support Teams, even though both (Solaris and Linux) fail on SSH Credentials and have identical Logs generated by ServiceNow Discovery.

IECs in Discovery Admin can be configured to identify the Operation System and further categorize the SSH Errors for the Solaris and Linux Teams.


Example 2:

Categorize based on Windows Servers or Windows Workstations:

Windows Servers and Windows Workstations are often supported by different teams or they may have a different level of priority when it comes to resolving Devices that are not being discovered.

It is important, that we segregate Windows Servers from Windows Workstations, even though both fail on WMI Credentials and have identical Logs generated by ServiceNow Discovery.

IECs in Discovery Admin can be configured to identify the Device Type and further categorize the WMI Errors for Windows Servers or Windows Workstations.


This can be done by leveraging attributes consolidated by Discovery Admin that capture the Name of the Device, along with other attributes that provide inputs confirming the Operating System of the Device.


 

Categorize based on Location

 

It is common to have different Support Groups responsible for supporting the same types, based on the Location of the Devices.

So, we must send the correct Devices for remediation to its corresponding Support Group.

IECs in Discovery Admin can be configured to identify the Location of the Devices and further categorize the Errors to segregate them for their respective Support Teams.


This can be done by leveraging attributes consolidated by Discovery Admin that capture the Name of the Device, along with other attributes that provide inputs confirming the Geographic Location of the Device.


 

Categorize based on CIs present in the CMDB

 

It is common to have Devices in the CMDB (which are populated via previous ServiceNow Discovery Runs or Manual Updates), which have well-populated Attributes (example: Support Group), Related List (IP Address), and Relationships (Runs Application Service) to other CIs in the CMDB, providing additional context.


IECs in Discovery Admin can be configured to identify these Devices and further categorize the errors to segregate them based on what is configured on the CI, its Related List, or via the CI Relationships.


Example 1:

A CI can have a populated attribute like Support Group or Location, helping us identify who to work with to resolve the error on this Device.


Example 2:

A CI can have a populated attribute like Network Adapter Manufacturer (on its Network Adapter Related List), helping us identify who to work with to resolve the error on this Device.


Example 3:

A CI can have a relationship with an Application Service which has the Service Owner populated, helping us to identify an escalation point-of-contact.


 

Categorize based on any Attributes on the Log Analysis Table

 

Building on the scenarios above, we can extend our use cases to leverage Discovery Admin to Increase Granularity.

IECs in Discovery Admin can be configured to look at any attribute (including via dot-walk) on the Log Analysis Table and use that as input to categorize the related Logs generated by ServiceNow Discovery.

bottom of page