Please use for the latest documentation.

This site is for reference purposes only and may not be accurate for the latest ServiceNow version

Setting Up Discovery

From Wiki Archive
(Redirected from Setting up Discovery)
Jump to: navigation, search
Note: This article applies to Fuji and earlier releases. For more current information, see Discovery at

The ServiceNow Wiki is no longer being updated. Visit for the latest product documentation.


{{ #if: Orchestration

- Orchestration
{{ #if:

}}}} {{#if: Related Topics | |-

Related Topics

{{ #if: Get the Book | |-

Get the Book
{{ #if:

Knowledge.gif Discovery
Knowledge.gif Data Collected by Discovery
Knowledge.gif Orchestration for VMWare

Knowledge.gif Discovery
Knowledge.gif Data Collected by Discovery
Knowledge.gif Orchestration for VMWare


Discovery can run on a regular, configurable schedule or can be launched manually. Whenever a Discovery runs, it runs over a specified IP address range which tells the Discovery process which specific devices to investigate. To retrieve useful information, Discovery needs credentials (usually a user name and password pair) for devices within a particular range so that Discovery can connect to and run various probes on the devices it finds. Discovery compares the devices it finds with configuration items (CI) in the CMDB and updates any matching devices. If Discovery does not find a matching CI in the CMDB, it creates a new CI.

For details on how Discovery works, see Getting Started with Agentless Discovery.

To set up Discovery and configure it to update the CMDB accurately, perform the following tasks in the order in which they appear.

  1. Meet Discovery prerequisites.
  2. Activate the Discovery plugin.
  3. Deploy one or more MID Servers.
  4. (Optional) Set up the MID Server to use PowerShell.
  5. Ensure MID Server has connectivity.
  6. Add credentials.
  7. Define and run Discovery schedules.
  8. Validate results.

Meet Prerequisites

  • Grant Discovery role: Verify that users who are expected to configure and execute Discovery in your network have the discovery_admin role. This role grants access to the tables in the Discovery application.
  • Select a MID Server host: Designate a computer to host the MID Server. See MID Server Requirements for Discovery for a complete list of MID Server requirements.
  • Gather credentials: Gather the login credentials that the MID server must use to access the devices it is expected to discover. See Discovery Credentials for instructions on providing Discovery with the proper credentials.
  • Select IP Address Ranges: Determine the IP addresses that Discovery must scan. In a very complex network, it is good practice to group IP ranges into a Range Set, which is reusable for different schedules. Discovery will not scan anything outside of these ranges.

Activate the Discovery Plugin

Discovery is available as a separate subscription from the rest of the ServiceNow platform and requires the Discovery plugin.

To purchase a subscription, contact your ServiceNow account manager. The account manager will arrange to have the plugin activated on your organization's production instance, generally within a few days.

Note: If you do not have an account manager or decide to delay activation after purchase, use the steps below when you are ready to activate.

You can evaluate the feature on a sub-production instance without charge by requesting it from the HI Customer Service System.

Deploy MID Servers

Install one or more MID Servers on physical or virtual servers that meet the minimum requirements and configure them to communicate with the appropriate ServiceNow instance. A best practice is to install at least two MID Servers at first and assign them to different schedules and IP ranges to help complete discoveries quicker. Dedicating MID Servers to a particular task with Discovery Behaviors can also improve performance.

Ensure MID Server Connectivity

Open the instance and navigate to Discovery > MID Servers. If the new MID Servers are configured properly, they will appear in the list of MID Servers. If a MID Server does not appear as a choice in the instance, perform the following checks in the MID Server:

  • Ensure that the URL in the Configuration Parameters related list provided is correct.
  • If the MID Server is installed on Windows, make sure the ServiceNow MID Server service is configured properly with the correct logon credentials and is running.
  • Check the MID Server log for errors.
    • UI: Navigate to Discovery > MID Servers > [MID Server] > Logs.
    • MID Server Host: Navigate to the agent\logs\agent0.log0 directory.
  • If Basic Authentication is enabled, a username and password must be provided.
  • The MID Server might not have outbound access on port 443 (SSL) or a proxy server might be preventing TCP communication to the instance.
  • Make sure that no firewalls are blocking communication between the MID Server and the instance.

Add Credentials

Set the Discovery Credentials on the instance for all the devices in the network - Windows and UNIX computers, printers, and network gear. Credentials for Windows devices (using the WMI protocol) are provided by the logon configured for the MID Server service on the Windows server host. Credentials for UNIX, vCenter, and SNMP must be configured on the instance. Discovery will automatically figure out which credentials work for a particular computer or device.

Set Discovery Properties

The following properties control how Discovery works. The default values are correct for most discoveries. Navigate to Discovery Definition > Properties to edit the properties.

Name Description
glide.discovery.enforce_unique_ips Enforce unique IP addresses

Ignores the IP address after Discovery encounters subsequent devices that use the same IP address. Each time a computer, printer, or network gear is discovered, and that device has a valid IP address, then any other devices with the same IP address have their IP address field cleared. If disabled, stores the IP address for each device.

  • Type: true | false
  • Default value: false
glide.eccprobe.max_queued_probes_per_run Maximum node agent queued probes per run
  • Type: integer
  • Default value: 20
glide.eccprobe.node_agent_id Node agent ID
  • Type: string
  • Default value: NODE_AGENT
glide.discovery.enforce_ip_sync Enforce syncing of IP addresses

Sets the first IP address. Each time a computer is discovered, and that device has multiple NICs, one of the IP addresses associated with the NICs will be chosen as the IP Address field of the CI. A value of false collects all NIC IP addresses.

  • Type: true | false
  • Default value: true
glide.discovery.hostname.always_update Always update host name
  • Type: true | false
  • Default value: true
glide.discovery.hostname.dns_nbt_trusted DNS or NetBIOS is trusted host name source
  • Type: true | false
  • Default value: true
glide.discovery.hostname.ssh_trusted SSH is trusted host name source
  • Type: true | false
  • Default value: false
glide.discovery.hostname.wmi_trusted WMI is trusted host name source
  • Type: true | false
  • Default value: false
glide.discovery.hostname.snmp_trusted SNMP is trusted host name source
  • Type: true | false
  • Default value: false
glide.discovery.hostname.include_domain Includes domain name in host name
  • Type: true | false
  • Default value: false Host name case
  • Type: choice list
  • Default value: Lower case
  • Additional options:
    • Upper case
    • No change Set OS domain name by NBT or WMI
  • Type: true | false
  • Default value: true
glide.discovery.discover_software Discover software packages
glide.discovery.application_mapping Application mapping
glide.discovery.active_processes_filter Active Processes Filter
  • Type: true | false
  • Default value: false
glide.discovery.auto_adm Automatically create process classifiers for application dependency mapping:
glide.discovery.adm.map_local_connection Map local connections for pending process classifier
glide.discovery.sensors.save_attachments Save ECC queue attachments
  • Type: true | false
  • Default value: true
glide.discovery.max_range_size Max range size

Specifies the maximum number of IP addresses that will be scanned in a single Shazzam probe. If a range has more IP addresses than this value, the remaining IP addresses will be skipped and a warning will be logged.

glide.discovery.bgp_router_disable BGP router exploration disable
  • Type: true | false
  • Default value: true
glide.discovery.debug.ci_identification CI identification debugging
  • Type: true | false
  • Default value: false
glide.discovery.network_owner_method Network router selection method
  • Type: choice list
  • Default value: Most Networks
  • Additional options:
    • First Router
    • Last Router
    • Least Networks
glide.discovery.physical_interface_types Physical interface types
  • Type: string
  • Default value: 6,117,9,71,209
glide.discovery.switch_interface_types Switch interface types
  • Type: string
  • Default value: 7,8,9,26,53,62,69,71,78,115,117,209
glide.discovery.virtual_interface_types Virtual interface types
  • Type: integer
  • Default value: 53
glide.discovery.debug.network_discovery Network discovery debugging Maximum netmask size for discoverable networks (bits)
  • Type: integer
  • Default value: 28
glide.discovery.network_discovery.functionality Networks discovery functionality
  • Type: string
  • Default value: SNMP only
glide.discovery.log_message_length Log Message Length
glide.discovery.roundingInterval.cpu CPU speed rounding
  • Type: integer
  • Default value: 1
glide.discovery.roundingInterval.ram Memory rounding
  • Type: integer
  • Default value: 1
glide.discovery.application_profile_discovery Application Profile Discovery
glide.discovery.fqdn.regex DNS Host Name And Domain Name Regex
  • Type: string
  • Default value: ^([^.]+)\.((?:[^.]+\.)+[^.]+)$
glide.discovery.ip_service_affinity IP service affinity
glide.discovery.apd.unix_location Application profile discovery location for UNIX based systems
glide.discovery.apd.windows_location Application profile discovery location for Windows systems
glide.discovery.use_probe_results_cache Use probe results cache
glide.discovery.max_concurrent_invocations_per_schedule Maximum concurrent invocations per schedule
  • Type: integer
  • Default value: 3
glide.discovery.warn_minor_version Warn on Minor Version Mismatch
glide.discovery.L3_mapping Map servers and network devices to routers and layer-3 switches
glide.discovery.enable.software_filter Windows software filter
glide.discovery.software_filter_keys Windows software filters
glide.discovery.software_sccm_managed Windows software is SCCM managed
glide.eccprobe.awsrestprobe.max_retries Maximum number of reconnection attempts an AWS REST probe makes after receiving a rate limit exceeded error from Amazon Web Services (AWS). The maximum allowable number of retries is 10. Setting negative values is equivalent to setting the maximum value.

Retries use exponential backoff (2^x). For example, the system waits 1 second before the first retry, 2 seconds until the second retry, 4 seconds until the third retry, and so on, until the total allowed retry time limit is exceeded. Make sure you configure enough total wait time in the glide.eccprobe.awsrestprobe.max_wait property to allow the maximum number of retries.

  • Type: integer
  • Default value: 4
glide.eccprobe.awsrestprobe.max_wait Maximum amount of time, in seconds, that an AWS REST probe continues to attempt to reconnect with Amazon Web Services (AWS) after receiving a rate limit exceeded error. This is the total amount of time used by all the probe’s retry attempts (from the glide.eccprobe.awsrestprobe.max_retries property). The maximum allowable time is 2046 seconds. Setting negative values is equivalent to setting the maximum value.
  • Type: integer
  • Default value: 30

Define and Run Discovery Schedules

The Discovery Schedule is the control point for running discoveries. The schedule controls when Discovery runs, defines the MID Server to use, the type of Discovery that should run, and the IP addresses to query. Create as many schedules as necessary, using different types of discoveries, and configure them to run at any time. Let Discovery run on its configured schedule or manually execute Discovery at any time. These schedules can be set up in a variety of ways, including a single schedule for the entire network or separate schedules for each location or VLAN.

If you do not know the IP address to scan in your network, run a Network Discovery first to discover the IP networks. Once discovered, you can convert these networks into IP address range sets that you use in a Discovery Schedule.

Note: For advanced discoveries, such as those requiring load balancing or scanning across multiple domains, use Discovery Behaviors.

Validate Results

Initial Discoveries often reveal unexpected results, such as previously unknown devices and processes or failed authentication. Results should also accurately identify known devices and update the CMDB appropriately. Become familiar with the network that is being Discovered and the types of data returned for the different types of discoveries. Use the Discovery Log and the ECC Queue to monitor the Discovery process as data is returned from the probes. To view the actual payload of a probe, click the XML icon in a record in the ECC Queue.

Viewing a probe payload in XML

Discovery Log

Use the Discovery Log form for a quick look at how the probes are doing. To display the Discovery Log, navigate to Discovery > Discovery Log.

Sample discovery log

The Discovery Log provides the following information:

Column Information
Created Displays the timestamp for the probe launched. Click this link to view the record for the probe launched in this list.
Level Displays the type of data returned by this probe. The possible levels are:
  • Debug
  • Error
  • Information
  • Warning
ECC queue input Displays the ECC queue name associated with the log message.
Message Message describing the action taken on the information returned by the probe.
CI The CI discovered. Click this link to display the record from the CMDB for this CI.
Source Displays the probe name that generated the log message.
Device Displays the IP address explored by the probe. Click this link to examine all the log entries for the action taken on this IP address by this Discovery.

Discovery Source

The Source [sys_object_source] table stores information identifying the source of a Discovery (ServiceNow or another product), the ID of that source, and the date/time of the last scan. To view this information, configure a CI form and add the Sources list. This table is populated automatically when the Discovery plugin is enabled.

Error creating thumbnail: Unable to save thumbnail to destination

Manually Changing the Discovery Source Name

To migrate your Discovery Source to ServiceNow:

  1. Update the system property glide.discovery.source_name to have a value of ServiceNow.
  2. Edit the dictionary entry for the Configuration Item [cmdb_ci] table.
  3. Update the choice list for the discovery_source column to only have the value ServiceNow.
  4. Open a list for the Configuration Item [cmdb_ci] table and filter on a discovery source field value you want to change.
  5. Use the Update All option to change the value to ServiceNow.
  6. Open a list for the Source [sys_object_source] table and filter on a name field value you want to change.
  7. Use the Update All option to change the value to ServiceNow.


Navigate to Discovery > Status and examine the status record for the current Discovery. From this record, use the links to examine the following:

  • Discovery Log: this log shows Discovery issues such as:
    • Failed credentials
    • Inaccessible ports
    • Problems with Windows Firewall
    • Viruses or intrusion products running in the network
    • WMI Services not running
    • WMI drivers not installed
    • UNIX devices with ACLs running to restrict access
  • ECC Queue: examine the payloads of the individual probes and sensors to validate information returned against what was expected. These results can help explain suspicious errors, such as why no software was detected running on a network server.

To check returned data, run queries on the MID Server machine from products such as:

  • Scriptomatic (WMI)
  • PuTTY (SSH)
  • iReasoning (SNMP)

Common Procedures

Troubleshoot a Discovery using the procedures outlined in the following stages:

  1. Port Scanning
  2. Classification
  3. Identification
  4. Exploration




  • Obsolete configuration parameter: The MID Server configuration parameter mid.powershell.use_mssqlauth is obsolete and was removed from the platform. Microsoft SQL Server discoveries use the PowerShell probe, which uses the MID Server's credentials. The PowerShell MSSQL probe was also removed.
  • Schedule field visible: A previously hidden field called Starting is now available on the default Discovery Schedule form. The run_start field enables an administrator to select the date and time that a one-time or periodic discovery runs. This field appears when a user selects the Once or Periodic option in the Run field.
  • SNMP object identifier (OID): ServiceNow first attempts to classify an SNMP device using system OIDs. If that fails, the platform tries to classify the device using the regular OIDs. In previous versions, SNMP classification with system OIDs could cause an issue if a device was also matched through regular OIDs.
  • Process handlers: Process handlers prevent the creation of duplicate CIs by filtering out parameters known to have inconsistent values before process classification occurs.
  • Gathering vCenter data without Discovery: A new workflow populates the CMDB with vCenter data without having to install the Discovery plugin. This workflow requires a MID Server and runs the standard VMware – vCenter probe from a Related Link on the VMware vCenter Instance form. See Gathering vCenter Data without Discovery for details.
  • New value for wmi_timeout probe parameter: All Windows probes now have a default timeout value of 5 minutes (configured with the wmi_timeout probe parameter), except for the Windows - Installed Software probe, which is configured with a timeout value of 15 minutes.
  • Obsolete credential type: The MSSQL credential type was removed from the Credentials [discovery_credentials] table.
  • User Name validation: A warning appears if the platform detects leading or trailing spaces in the User Name field. These spaces prevent the VMware - vCenter probe from connecting to vCenter.
  • Configuration storage menu: The Configuration menu now contains a Storage section with direct access to CIM storage tables. Previous access to these tables was through the CI record from a device link in a Discovery Status record.
  • Access privileges for discovery_admin: The discovery_admin role was updated to grant access to all the tables that a user needs to configure and run Discovery.
  • Storage forms: The HBA and Port related lists were removed from the Storage Pools, Storage Disks, and Storage Volumes forms to eliminate confusion. These related lists did not have a direct relationship to the forms.
  • Hyper-V table structure: When you upgrade an instance, ServiceNow migrates virtualization data to a new table schema and creates a backup table structure to protect existing data.