Please use docs.servicenow.com for the latest documentation.
This site is for reference purposes only and may not be accurate for the latest ServiceNow version
Setting Up Discovery
| Note: This article applies to Fuji and earlier releases. For more current information, see Discovery at http://docs.servicenow.com
The ServiceNow Wiki is no longer being updated. Visit http://docs.servicenow.com for the latest product documentation.
- 1 Overview
- 2 Meet Prerequisites
- 3 Activate the Discovery Plugin
- 4 Deploy MID Servers
- 5 Ensure MID Server Connectivity
- 6 Add Credentials
- 7 Set Discovery Properties
- 8 Define and Run Discovery Schedules
- 9 Validate Results
- 10 Discovery Source
- 11 Troubleshooting
- 12 Enhancements
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.
- Meet Discovery prerequisites.
- Activate the Discovery plugin.
- Deploy one or more MID Servers.
- (Optional) Set up the MID Server to use PowerShell.
- Ensure MID Server has connectivity.
- Add credentials.
- Define and run Discovery schedules.
- Validate results.
- 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.
|Click the plus to expand instructions for requesting a plugin.|
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.
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.
|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.
|glide.eccprobe.max_queued_probes_per_run|| Maximum node agent queued probes per run
|glide.eccprobe.node_agent_id|| Node agent ID
|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.
|glide.discovery.hostname.always_update|| Always update host name
|glide.discovery.hostname.dns_nbt_trusted|| DNS or NetBIOS is trusted host name source
|glide.discovery.hostname.ssh_trusted||SSH is trusted host name source
|glide.discovery.hostname.wmi_trusted||WMI is trusted host name source
|glide.discovery.hostname.snmp_trusted|| SNMP is trusted host name source
|glide.discovery.hostname.include_domain|| Includes domain name in host name
|glide.discovery.hostname.case|| Host name case
|glide.discovery.domain.name.nbt|| Set OS domain name by NBT or WMI
|glide.discovery.discover_software|| Discover software packages
|glide.discovery.application_mapping|| Application mapping
|glide.discovery.active_processes_filter|| Active Processes Filter
|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
|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
|glide.discovery.debug.ci_identification|| CI identification debugging
|glide.discovery.network_owner_method|| Network router selection method
|glide.discovery.physical_interface_types|| Physical interface types
|glide.discovery.switch_interface_types|| Switch interface types
|glide.discovery.virtual_interface_types|| Virtual interface types
|glide.discovery.debug.network_discovery|| Network discovery debugging
|glide.discovery.discoverable.network.max.netmask.bits|| Maximum netmask size for discoverable networks (bits)
|glide.discovery.network_discovery.functionality|| Networks discovery functionality
|glide.discovery.log_message_length|| Log Message Length
|glide.discovery.roundingInterval.cpu|| CPU speed rounding
|glide.discovery.roundingInterval.ram|| Memory rounding
|glide.discovery.application_profile_discovery|| Application Profile Discovery
|glide.discovery.fqdn.regex|| DNS Host Name And Domain Name Regex
|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
|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.
|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.
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.|
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.
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.
The Discovery Log provides the following 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:
|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.|
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.
Manually Changing the Discovery Source Name
To migrate your Discovery Source to ServiceNow:
- Update the system property glide.discovery.source_name to have a value of ServiceNow.
- Edit the dictionary entry for the Configuration Item [cmdb_ci] table.
- Update the choice list for the discovery_source column to only have the value ServiceNow.
- Open a list for the Configuration Item [cmdb_ci] table and filter on a discovery source field value you want to change.
- Use the Update All option to change the value to ServiceNow.
- Open a list for the Source [sys_object_source] table and filter on a name field value you want to change.
- 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)
Troubleshoot a Discovery using the procedures outlined in the following stages:
- Changes the Discovery source name to ServiceNow.
- 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.
|Previous version enhancements|
Aspen Patch 3
The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed from the platform. The localhost MID Server originally was intended for demonstration purposes and was not intended to be a supported feature.
Support for clustered process Discovery has been generalized to extend beyond Microsoft SQL Server.