Troubleshooting Scenario Questions

The MID Server is not validated

Why it fails: Validation confirms the MID Server's credentials and configuration are accepted by the instance; an unvalidated server cannot receive Discovery commands. It is tempting because validation is a genuine prerequisite, but a connected MID Server has already passed it, so validation status cannot explain the failure here.

The MID Server is too old

Why it fails: Discovery failures stem from configuration, credentials or connectivity, not the MID Server build's age; version mismatches surface as unsupported features rather than silent Discovery failure. Upgrading is genuinely required when the instance version exceeds the MID Server's supported range, which is a different symptom.

The proxy is down

Why it fails: A proxy outage would break the MID Server's outbound connection to the instance, yet the stem states it is connected. Proxies are genuinely relevant when the MID Server must reach the instance through a corporate gateway, so the distractor exploits that real dependency rather than the stated connectivity.

The instance marks the records as 'processed'.

Why it fails: The instance cannot mark records processed because processing occurs only after the MID Server retrieves and executes them; an unreachable MID Server means no retrieval happens. Records stay queued. Marking as processed is correct when the MID Server has completed the probe and returned output.

The records are automatically moved to the error state.

Why it fails: ECC Queue records remain in the queue awaiting MID Server pickup; they are not transitioned to an error state by connection failure. Error states result from processing faults after retrieval. The error state applies when the MID Server retrieves a record and its probe or script fails.

The records are automatically deleted.

Why it fails: Records persist in the ECC Queue until a MID Server collects them; failed connectivity does not trigger deletion. Deletion occurs through scheduled cleanup of aged or completed records, not as a consequence of an unreachable MID Server. The queue simply accumulates pending output.

Pattern Log

Why it fails: Logs show execution flow, not variable memory state.

The CMDB CI Class Manager

Why it fails: Class Manager manages attributes, not pattern execution state.

The Discovery Status record

Why it fails: Status records provide high-level error summaries.

System Logs > Node Logs

Why it fails: Node Logs record instance-level system events such as startup and clustering, not IRE payload processing, so they will not show why memory attributes were rejected. They are tempting because node-level faults can disrupt Discovery, and Node Logs would be the right place to diagnose a crashed MID Server node.

Discovery > Pattern Logs

Why it fails: Pattern Logs capture pattern execution and step-level debugging during Discovery, stopping before IRE identification and reconciliation runs, so they cannot explain why memory attributes were not written to the CMDB. They are tempting because they are the correct choice when a pattern fails to collect data in the first place.

System Logs > Discovery Logs

Why it fails: Discovery Logs record sensor and probe activity during scanning, not the IRE identification and reconciliation decisions that update CMDB attributes, so memory changes would not appear there. They are tempting because they are the correct choice when Discovery fails to detect or classify a device at all.

Upgrade the MID server.

Why it fails: Upgrading the MID server addresses discovery connectivity or version compatibility, not the service map's accuracy. Service Mapping marks a service inaccurate when its CI relationships drift from the discovered topology, so the standard remedy is re-running the mapping or refreshing the relevant entry points. MID upgrades suit probe failures or unsupported OS discovery.

Re-import the entire CMDB.

Why it fails: Re-importing the entire CMDB does not recalculate the service instance's dependency relationships and risks overwriting unrelated records. Inaccuracy means the map no longer matches the live topology, so re-running Service Mapping for that service is the standard fix. Full CMDB imports suit bulk data migration or corruption recovery.

Clear the CMDB cache.

Why it fails: Clearing the CMDB cache does not rebuild the service instance's relationship graph; inaccuracy reflects stale or changed CI dependencies, not cached display data. The standard step is to re-run Service Mapping for the affected service so discovery re-evaluates the topology. Cache clearing suits rendering or performance anomalies, not map drift.

Discovery Schedules

Why it fails: Discovery Schedules control when and how often horizontal discovery runs against IP ranges or MID Servers; they do not reconcile incoming data against existing records. Duplicates arise from failed identification and reconciliation, which is the Identification and Reconciliation Engine's job. Schedules would be the right focus when tuning scan frequency or coverage windows.

Transform Maps

Why it fails: Transform maps control how incoming discovery payloads populate CI fields; they do not determine which existing CI a discovered device matches, so duplicates persist. It is tempting because transform maps govern data import, but they suit normalising field values, whereas duplicate prevention depends on the identification and reconciliation engine.

Data Preserver

Why it fails: Data Preserver protects specified CI fields from being overwritten during updates; it does not match discovered devices to existing records, so duplicates still arise. It is tempting because it governs how discovery writes to CIs, but it suits retaining manually maintained values, not the identification rules that decide whether a CI already exists.

System Log

Why it fails: The system log aggregates platform-wide errors such as transactions and scheduled jobs, not pattern step execution detail. It is tempting because it is the default place to look for errors, but a pattern that identifies a CI yet omits an attribute requires the pattern debug log instead.

CMDB Health Dashboard

Why it fails: The CMDB Health Dashboard reports aggregate compliance scores for completeness, correctness and duplicates, not the execution detail of a single pattern run. It is tempting because it surfaces missing attributes, but it shows outcomes rather than the step-level cause recorded in the pattern debug log.

MID Server Log

Why it fails: The MID Server log records connectivity, credential and probe execution issues between the instance and target infrastructure, not pattern step logic. It is tempting because discovery depends on the MID Server, but a pattern that identifies the CI yet skips an attribute write fails inside the pattern itself.

Node Log

Why it fails: The node log captures JavaScript errors raised by a specific node during pattern execution, but it does not record which pattern steps ran or which attributes were populated. It is tempting because patterns execute JavaScript, yet the debug log shows the step-by-step operations and attribute values needed here.

Shazzam

Why it fails: Shazzam performs port scanning and probe detection during the scanning phase, so it cannot explain why classified devices yield no CMDB payload. It tempts because scan failures do block discovery, but here classification already succeeded, meaning the failure lies in the later exploration and payload phase.

Schedule

Why it fails: The schedule merely triggers when discovery runs; it does not govern whether collected data is written into the CMDB. It tempts because a disabled or misconfigured schedule stops discovery entirely, but the stem states the device is already correctly classified, so discovery clearly executed and the failure sits downstream.

Classification

Why it fails: Classification assigns the correct CI class, and the stem states this already succeeded, so investigating it cannot explain missing CMDB data. It tempts because misclassification does cause incorrect CI records, but the failure here occurs after classification, during exploration and payload collection.

Identification

Why it fails: Identification determines whether a device exists and responds, so it precedes classification, which the stem confirms already succeeded. It tempts because unreachable devices produce no CMDB data, but here the device was found and classified, so the fault lies in the later exploration and payload phase.

Run the discovery again.

Why it fails: Re-running discovery overwrites the previous probe results, so the exact payload from the failed run is lost. It is tempting because re-running is the standard first step when a device is unreachable, but the Discovery Device Results and ECC queue records already hold the returned probe output without a fresh run.

Check the MID Server logs.

Why it fails: MID Server logs record agent activity, connectivity and execution errors, not the raw payload a probe returned from the device, so they cannot show the exact response data. It is tempting because logs are the first troubleshooting stop, and they would be correct for diagnosing MID Server or credential failures.

View the CI record.

Why it fails: The CI record holds the normalised attributes written after discovery processing, so the raw probe payload is discarded before it appears there. It is tempting because the CI is the visible end result of discovery, and it would be correct for confirming which attributes were ultimately populated on the device.

Restart the ServiceNow instance.

Why it fails: Restarting the ServiceNow instance does not restore the MID Server's outbound connection to it, and disrupts unrelated users; the fault lies on the host or network path. It is tempting as a generic reset, and would be correct if the instance itself were unresponsive to all clients.

Update the MID Server version in the MID Server record.

Why it fails: Version mismatch would not leave a running service reported as Down; the instance loses heartbeat contact, so the first step is checking the MID Server's connectivity and logs on the host. Upgrading is tempting because version drift does cause failures, and would be right after confirming the agent cannot reach the instance.

Reinstall the MID Server.

Why it fails: Reinstalling discards configuration and logs before diagnosis, and the service already runs, so the fault is the heartbeat path rather than the installation. It is tempting as a clean-slate fix, and would be correct where the MID Server binaries are corrupt or the service genuinely fails to start.

The MID Server configuration log

Why it fails: This is not a standard log file.

The System Event Log

Why it fails: This is for OS events, not probe execution.

The wrapper log

Why it fails: The wrapper log is for the Java service process.

Update the 'MID Server' record to 'Down' and back to 'Up'

Why it fails: Toggling the MID Server status does not correct the host clock offset that triggers the drift check. It is tempting as a quick reset, but it would be correct when the MID Server is genuinely unresponsive or disabled; here the underlying time synchronisation must be fixed before jobs resume.

Increase the 'ECC Queue' processing timeout

Why it fails: Extending the ECC Queue timeout affects how long queued jobs wait, not the clock offset that invalidates the MID Server's authentication. It is tempting because jobs are not being picked up, but it would be correct when jobs time out under heavy load, not when a clock drift error is reported.

Restart the MID Server service

Why it fails: Restarting the service does not correct the host clock offset, so the drift error recurs and the MID Server remains unable to accept jobs. It is tempting as a standard recovery step, but it would be correct when the service has hung or crashed, not when time synchronisation is the fault.

discovery_device_history

Why it fails: The discovery_device_history table logs device-level Discovery activity and status, not the identification criteria that decide whether an incoming record matches an existing CI. It is tempting because it is genuinely useful for auditing what Discovery touched and when, which suits tracking failed or skipped devices rather than diagnosing duplicate CI creation.

sys_reconciliation_rule

Why it fails: The sys_reconciliation_rule table stores reconciliation rules that merge duplicate CI records after identification has already matched them, so it cannot explain why two CIs were created instead of one. It is the right place when tuning merge precedence and survivorship between already-identified duplicates.

cmdb_ci_relation

Why it fails: The cmdb_ci_relation table holds relationships between CIs, such as depends-on or runs-on links, and contains no identification criteria, so it cannot reveal why duplicate server records appear. It is the correct table when investigating missing or incorrect relationship mappings rather than duplicate CI creation.

Restart the ServiceNow instance

Why it fails: Restarting the ServiceNow instance disrupts every MID Server and integration on the platform, yet cannot repair a MID Server whose service, credentials or network path to the instance has failed. It is tempting because instance-wide restarts clear platform-side job and queue issues, which is the right action when the instance itself is unresponsive.

Run a full system scan

Why it fails: A full system scan inspects files for malware; it cannot diagnose why a MID Server's service has stopped polling or lost connectivity to the instance. It is tempting because scans are a routine host-health task, and would be the right choice when malware is suspected on the MID Server host itself.

Clear the CMDB cache

Why it fails: Clearing the CMDB cache does not restore communication with an unresponsive MID Server, whose failure concerns its host service, credentials or network connectivity. It is tempting because stale CMDB data causes discovery oddities, but cache clearing addresses data freshness, not an agent that has stopped responding to the instance.

Update the Linux credentials to use a privileged user account.

Why it fails: The error is not related to permissions; it is a missing command. Using a privileged account might be necessary for some commands, but the error 'Command not found' occurs regardless of user privileges if the utility is not installed. Therefore, changing credentials would not fix the problem.

Increase the SSH timeout value in the MID Server properties.

Why it fails: A timeout would produce a different error, such as 'Connection timed out' or 'Timeout waiting for response'. The error 'Command not found' indicates that the SSH connection succeeded but the remote command failed. Adjusting the timeout would not resolve a missing command issue, as the command itself is unavailable on the target.

Modify the Discovery Schedule to include the server's IP address in the 'Discover' field.

Why it fails: The server is already being targeted, as evidenced by the SSH probe attempt. The 'Discover' field determines which IPs are scanned; if the server were not included, no probe would run. Since the probe is running and failing, the schedule is correctly configured, and this step is unnecessary.