CCNA Discovery Configuration Questions

The ECC Queue is the bidirectional message queue carrying probes and commands from the instance to the MID Server, and returning payloads and results. This satisfies Discovery's requirement for asynchronous, firewall-friendly communication, since the MID Server polls outbound rather than accepting inbound connections from the instance.

Updating the probe's own timeout parameter targets only that probe, satisfying the requirement to adjust a single probe rather than the whole schedule. Probe-level parameters override the default timeout applied by the discovery schedule, so the change takes effect on the next run without affecting other probes.

Identification reconciles discovered data against existing records before CIs enter the CMDB, matching on attributes such as serial number or MAC address. This deduplication satisfies the stem's requirement that identification prevents duplicate CIs, since creation without this reconciliation step would generate multiple records for the same physical device.

Discovery Classification records contain the criteria (e.g., SNMP OID values, system descriptions) used to match devices to a specific class. If a router is misclassified as a printer, the classification criteria for 'Router' may not be matching correctly, or the 'Printer' classification may be too broad. Adjusting the Router classification's match criteria ensures the device is correctly identified.

A single MID Server caps discovery throughput. A MID Server cluster distributes probes across multiple nodes with load balancing, so discovery scales horizontally and continues if one node fails, satisfying the requirement to improve performance.

The MID Server is a Java application installed inside the corporate network that establishes outbound connections to the ServiceNow instance, executing probes, discovery and integrations on internal systems. It satisfies the requirement to reach network-restricted resources without exposing them to inbound internet traffic.

Spreading scans over several schedules and MID Servers divides the load, so no single segment absorbs the full probe volume at once. This directly satisfies the stem's constraint of avoiding network traffic impact, since concurrent discovery against many targets from one server is what saturates links.

Classification examines discovered devices to determine their operating system or device type, assigning the appropriate class so records land in the correct CMDB table. This identification of O/S or device type is precisely the phase's purpose before identification and reconciliation proceed.

Discovery IP range exclusions are records that let you exclude specific IP addresses or subnets from being scanned, even if they fall within an included range. This is the correct way to prevent scanning of the database servers while still discovering the rest of the subnet. The exclusion is applied during the scanning phase.

Completed signifies the discovery run has finished executing, meaning all scheduled probes and sensors have stopped and results are written. It does not by itself confirm every CI was discovered successfully; errors or unreachable devices are reported separately from this status value.

Shazzam is the port-scanning probe within Discovery, sending probes to target IP ranges to identify which ports and services are live. It supplies the raw scan results that later phases use to classify and map configuration items.

The Discovery Schedule record carries a MID Server field; populating it binds that specific MID Server to the schedule, so all discoveries it triggers run through that server. This directly satisfies the stem's requirement to associate a particular MID Server with the schedule.

Disabling the Active flag prevents the schedule from executing.

Splitting discovery across multiple schedules and MID servers distributes scanning and processing load, preventing a single MID server or schedule from bottlenecking on a very large network. This directly satisfies the scale requirement through workload segmentation.

Exploration runs patterns against discovered devices to collect detailed attributes such as serial numbers, installed software and configuration, enriching basic identification data. This detailed attribute gathering is the phase's primary function before the data is normalised and reconciled.

By limiting the Discovery Behavior to only the probes required for Linux and Windows, the administrator reduces unnecessary scanning. Classification will identify the OS and trigger the appropriate probes. This approach minimizes MID Server load and ensures that only relevant probes are executed, meeting the requirement efficiently without compromising discovery completeness.

Credential records hold the usernames, passwords, and related authentication data Discovery uses to log into target devices during horizontal and vertical discovery. They satisfy the requirement by supplying the login secrets referenced by discovery schedules.

Credential Aliases decouple discovery from stored credentials, letting a single alias resolve to different credential records per MID Server or environment. This satisfies the requirement that credentials be referenced indirectly, so Discovery can select the correct credential without hard-coding it into each schedule.

Classification criteria determine how devices are matched to CI classes. If the criteria for Windows are missing, incorrect, or ordered after a more generic Linux criterion, the device may not be classified correctly. Reviewing and adjusting the criteria ensures that the Windows server is properly identified. This is a direct troubleshooting step for classification failures.

Serial number and manufacturer on Windows are typically collected through WMI queries executed by specific probes and pattern steps. If those steps fail or are excluded for this device, the CI is still created and classified but hardware attributes remain empty. Reviewing these probe steps and their ECC queue results is the most direct way to find why one server differs from its peers.

Raising the MID Server's concurrent task limit lets it run more probes and patterns in parallel, directly addressing the throughput bottleneck causing the slow scan. The constraint in the stem is scan duration, and this setting governs how many discovery jobs execute simultaneously, so additional capacity is used rather than sitting idle.

Manual 'Discover Now' initiates an on-demand horizontal discovery run against a specified CI or IP range, bypassing the scheduled pattern. It satisfies the stem's requirement for a valid trigger because it invokes the same Discovery engine and probes as automated schedules, letting engineers validate credentials or troubleshoot mid-cycle without waiting for the next window.

Identification rules determine which CI a discovered record matches; if they fail to match, the CI is not updated even though the probe completed successfully. The 'Success' status reflects probe execution, not record reconciliation, so faulty identification rules are the likely cause.

The MID Server record carries the Capabilities related list, where you assign capabilities such as Windows. Only MID Servers holding the matching capability are selected for that discovery, restricting the named server to Windows-only probes within the cluster.

A MID Server deployed inside the target network segment initiates outbound connections to ServiceNow, so discovery traffic never traverses the firewall inbound. This satisfies the constraint of discovering devices behind a firewall without opening inbound ports.

CIDR notation lets you express an entire subnet as a single compact range, such as 192.168.1.0/24, which Discovery expands into individual addresses during scanning. This satisfies the stem's requirement for a valid IP range configuration method, avoiding the need to list every host address separately.

Probe results are written to the ECC Queue as input records; each payload contains the raw XML response returned by the probe for that device. Inspecting the related ECC Queue records shows exactly what the probe sent and received, satisfying the need to see precise probe output during troubleshooting.

Classification records map conditions, such as the Linux Server class, to the CI type and the pattern Discovery should run. Attaching the custom pattern there ensures it triggers only once the device is classified as a Linux Server, satisfying the stem's requirement to target that classification rather than ignoring the application.

Exploration is the phase that probes a classified device to gather attributes and populate the CMDB; classification alone does not collect data. If the device is correctly classified but records remain empty, the exploration step has failed, so investigate it before patterns, probes or sensors.

Shazzam probes target devices to identify open ports and active services, feeding this data to later classification phases. This directly fulfils the stem's requirement to define the phase's purpose: port and service detection, not credential testing, CI creation, or dependency mapping.

The Discovery Status record stores the MID Server name that executed each discovery run, so opening the relevant status entry reveals the exact MID Server used. This directly identifies the performing MID Server for that task.

The Discovery Log captures per-phase execution detail, including Exploration errors, and records the exact credential failure message returned by the probe. It satisfies the stem's requirement to locate the specific error logs for insufficient credentials, since the log is scoped to the individual discovery run rather than aggregated platform-wide.

MID Server Clusters let a single schedule distribute probes across multiple MID Servers, sharing load and reaching segmented network ranges. This satisfies the requirement to spread scanning capacity rather than relying on one MID Server.

Horizontal discovery patterns are responsible for collecting detailed attributes such as serial number from devices. If the serial number is missing, the pattern may not include the necessary probe or step to retrieve it, or the pattern may be outdated. Investigating and potentially updating the Windows OS pattern ensures the correct command or WMI query is executed to populate the serial number field.

Deleting a Discovery Schedule removes the record that triggers automated discovery runs, so no further executions occur on its defined interval. This directly satisfies the scenario's requirement of stopping future automated runs, though existing discovered CIs and historical discovery data remain unaffected in the CMDB.

The MID Server initiates all communication, so it requires outbound access to the ServiceNow instance; no inbound firewall rules are needed. This satisfies the constraint that discovery traffic originates from inside the network, letting the MID Server reach the instance through the firewall.

An excluded IP range is optional filtering, not mandatory schedule data. Discovery Schedules require core fields such as name, MID Server, and IP ranges to scan, so exclusion lists are supplementary. This makes it the element that is not a required part.

An IP Service groups a named collection of ports and protocols that Discovery probes against target devices. It defines what to scan, letting administrators tailor horizontal discovery to specific services such as SSH or WMI rather than scanning every port indiscriminately.

The IP Service record defines which ports Discovery probes for a given service type, so adding a port there extends scanning coverage. Updating it satisfies the requirement to scan the new port without altering credentials or schedules.

A custom Discovery Behaviour lets you define the exact probe sequence executed against a device class, overriding the default classification-driven probes. This satisfies the need to control which probes run for a specific device type, giving granular command over collection without altering global Discovery schedules or credentials.

Discovery Behaviors let you attach a custom set of probes to a discovery schedule, overriding the default probe selection. This satisfies the stem's need to limit or extend probes for particular scenarios, such as excluding slow patterns or adding targeted ones.

When a port matches a configured classifier but lacks a trigger probe, Shazzam still passes it to classification, so the device is identified. Exploration, however, depends on trigger probes firing; without one, no further probing occurs, leaving the port classified but unexplored.

ServiceNow's IP Range field accepts either CIDR notation or explicit start and end IP addresses, so both formats satisfy the schedule's address-block requirement. This flexibility lets you define contiguous ranges precisely, whether expressing a subnet as 192.168.1.0/24 or spanning 192.168.1.1 to 192.168.1.254, without converting between representations.

Identification matches each discovered device or record against existing configuration items in the CMDB, determining whether it is already known or new. This reconciliation prevents duplicate CIs and is what allows later phases, such as reconciliation and update, to act on accurate records.

Discovery relies on probing target devices across specific ports; a firewall blocking those ports silently drops probes, so classification fails and the scan returns incomplete or no results. This directly satisfies the stem's requirement of a common scan-failure cause.

Discovery Patterns are the reusable, OS-specific definitions that Discovery runs against a classified device. Once the device is identified as Linux, the Linux pattern executes its probes and commands to collect Linux-specific attributes, so it is the component that triggers the data gathering.

The Discover Now related link on a Discovery Schedule record launches the schedule immediately, independent of its configured interval. This is the supported way to start an on-demand discovery run for the defined IP ranges and MID Server selection. It satisfies the requirement to begin scanning without waiting for the next scheduled interval.

Discovery scope accepts IP address ranges, letting administrators enumerate contiguous host addresses to probe. This constrains the scan to specific targets, satisfying the requirement to define scope by address boundaries rather than by credentials or schedules.

Discovery Patterns are the reusable definitions that specify which probes, sensors and commands run against a device class, translating raw scan results into CIs. They form one of the core components orchestrating the Discovery process flow.

Network connectivity to the server is required so the MID Server can reach the target over the necessary ports for probing and command execution. Without reachability, neither classification nor credential-based exploration can occur, regardless of how correct the credentials are.

Discovery patterns for Linux often rely on specific command-line utilities to gather hardware and software details. If a required utility is missing, the probe fails with 'Command not found'. Ensuring utilities like 'dmidecode' and 'lspci' are installed allows the pattern to execute successfully and collect the necessary data.

The Excluded IP Ranges related list lets you carve out specific addresses from an already-configured CIDR block without editing or splitting that range. This is the most efficient approach because Discovery skips those addresses during scanning while the parent range remains intact.

The MID Server list shows each MID Server's status, such as Up or Down, reflecting heartbeat communication with the instance. Checking it confirms whether the MID Server is connecting correctly, which is the primary validation method.

Discovery Schedules define the IP ranges to scan and the MID Server to use. By creating a schedule for the remote subnet and assigning it to the MID Server located in that network, the MID Server can perform the discovery locally. This is the standard approach for discovering non-routable subnets, as the MID Server acts as a proxy within the remote network.

The Discovery Status record aggregates results for the entire schedule run, listing each scanned IP with its state, such as active, unreachable or error. Opening it shows per-address outcomes, which individual device records cannot provide.

Identification Rules define the attribute criteria the Identification engine uses to match incoming discovery data against existing CIs. Verifying these rules ensures duplicate server records are merged rather than created anew, directly resolving the duplicate CI creation observed during the Identification phase.

Discovery Schedules have no hard-coded run limit; execution frequency is governed entirely by the schedule interval and the instance's system configuration. This satisfies the stem's constraint on maximum runs, since ServiceNow imposes no fixed cap — administrators control repetition through interval settings and MID Server capacity rather than an inherent ceiling.

Software and package collection on Linux is performed by specific probes and pattern steps within the Linux Server pattern, such as those that read package manager data and installed application listings. If those probes or steps are disabled, fail silently, or are not included in the active pattern version, the device still classifies and completes but returns no software data. Verifying these steps is the direct way to resolve the symptom.

A Password field is stored directly on the Credential record, satisfying the requirement for authentication data held within the credential itself. Discovery uses this stored secret when probing target devices, so it belongs among the three items. Credentials reference the password rather than retrieving it externally, confirming it as a stored attribute.

Probes within a Discovery Behavior define which probe activities are launched against particular device types, letting administrators tailor discovery to the target classification. This controls probe selection per device type rather than scheduling or credential handling.

Discovery probes the network, identifies configuration items and their relationships, then writes those records into the CMDB, which is the authoritative store ServiceNow uses for asset and service context. Other tables reference the CMDB rather than being its primary target.

Discovery Classifiers hold the criteria that map discovered devices to the correct class and table, so a new device type needs a matching classifier entry before it can be classified properly. Without it, the device falls through to an unknown or default classification.

The MID Server is the on-premises execution engine that performs the actual horizontal and vertical discovery probes against target devices, then relays results back to the ServiceNow instance. Without a running MID Server with valid credentials and network reachability, Discovery cannot collect any configuration data.

Discovery schedules rely on the MID Server to execute probes and patterns against target devices. With the MID Server in a Down state, no orchestration occurs, so the scheduled discovery job either fails outright or never runs until the MID Server recovers.

Identification Rules match devices using hardware attributes such as serial number and MAC address rather than IP address. When an IP changes, Discovery still correlates the CI to the existing record, preventing duplicate device creation.

The Discovery Status module records each discovery run's progression through its individual phases, exposing where failures or delays occur. This phase-by-phase detail satisfies the stem's requirement by letting administrators pinpoint the exact stage at which a discovery schedule stalled or errored.

Discovery only probes addresses within configured IP ranges, so a new subnet absent from any range is never scanned. Verifying the Discovery IP Range first confirms the subnet is included and reachable, addressing the most common cause of no devices being detected.

The MID Server's agent logs record startup, connectivity and probe execution events. When the MID Server stops responding, these logs expose authentication failures, memory exhaustion or lost connections to the instance, making them a primary diagnostic source.

Setting Run to Daily executes the Discovery Schedule once per 24-hour period, and the associated start time determines when that single run begins. Other intervals such as periodic or cron would not guarantee exactly one execution per day.

Classification records contain conditions that determine when a device matches that classification. If the conditions are too restrictive or incorrect, the device will not be classified even if the pattern runs. The administrator should verify that the conditions (e.g., based on discovered attributes like operating system, manufacturer, or open ports) are accurate for this server.

Discovery Range Sets are the standard way to define subsets of IPs for a schedule.