Troubleshooting practice questions

To identify the user who triggered the scan.

Why it fails: The discovery_id is a unique identifier for a single discovery run, letting you correlate all log entries and results from that scan; it carries no user identity data. It is tempting because discovery logs do record who scheduled or triggered a scan, but that attribution comes from separate audit fields, not this identifier.

To link the device to a specific MID server.

Why it fails: The discovery_id identifies a particular discovery run for log correlation; MID server association is recorded in separate fields on the discovery schedule and result records. It is tempting because MID servers execute discovery, and each run does occur on one, but the identifier itself does not encode or establish that link.

To mark the CI as 'Discovered'.

Why it fails: The discovery_id identifies a specific discovery run so its log entries and results can be correlated; it does not change CI state. It is tempting because discovery does create or update CIs and set their discovery status, but that marking is performed by the discovery process itself, not by this identifier.

It increases the polling speed

Why it fails: Log level governs what the MID Server writes to its log files, not the frequency of discovery polling, which is scheduled separately. It is tempting because verbose logging can slow a MID Server, and increased polling speed would be correct if the property controlled scheduler intervals.

It enables automatic error reporting

Why it fails: The debug level only controls logging verbosity; it does not transmit error reports anywhere. It is tempting because debug output is often used when diagnosing faults, and automatic error reporting would be the correct answer if the setting governed telemetry or diagnostic upload behaviour.

It forces the MID Server to re-validate

Why it fails: Re-validation is triggered by configuration changes or manual action, not by log verbosity. The property only changes the detail recorded in logs. It is tempting because restarting or reconfiguring a MID Server often accompanies troubleshooting, and re-validation would be correct if the setting forced a config refresh.

Restart the instance

Why it fails: Restarting the instance clears transient state but provides no pattern-level diagnostics: no step-through, no variable inspection, no probe output. It is tempting as a generic remedy for stuck MID Server jobs, and would be reasonable when a discovery run hangs due to a wedged service rather than faulty pattern logic.

Modify the MID Server source code

Why it fails: MID Server source code is vendor-supplied and unsupported for modification; editing it breaks upgrade paths and support agreements without exposing pattern logic. It is tempting because the MID Server executes patterns, and would be correct only for debugging custom JavaScript steps within a pattern, not the platform itself.

Run the pattern from the command line

Why it fails: Patterns execute inside the MID Server's Java engine against a target; there is no supported command-line invocation that loads and runs a pattern standalone. It appeals because command-line execution is a genuine debugging route for other ServiceNow scripts, such as background scripts and scheduled jobs.

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.

Credentials

Why it fails: Credentials are configured in the MID Server and credential records, not the Pattern Designer, so inspecting them there yields nothing; the identification phase runs pattern steps against a target. Credential faults surface as authentication errors, which is when credential troubleshooting becomes the right focus.

Schedule

Why it fails: The Schedule tab controls when a pattern runs, not how it identifies devices, so it cannot explain an identification-phase failure. It is tempting because scheduling is configured in the same Pattern Designer interface, and it would be the right area to inspect if the pattern never launched at all.

Discovery log

Why it fails: The Discovery log records overall run outcomes and errors, but not the step-level pattern logic that determines how identification classifies a device. It is the right place to confirm a discovery failed, yet the Pattern Designer's steps and debug output reveal why identification misfired.

Change the proxy server settings

Why it fails: Proxy settings affect outbound web traffic, not the MID Server's REST connection to the instance, which uses the instance URL directly. Changing them is tempting because proxies commonly break connectivity, but it is correct only when the MID Server must reach external endpoints through a proxy.

Create a new discovery schedule

Why it fails: Discovery schedules run against already-connected MID Servers; they cannot restore a missing heartbeat. Creating one is tempting because schedules are the visible discovery artefact, but it is correct only when you need to discover new ranges, not when the MID Server itself is down.

Update the MID Server version

Why it fails: A version mismatch does not stop the MID Server heartbeating to the instance; connectivity, credentials and service state do. Updating the version is tempting because upgrades are routine maintenance, but it is the correct action only when the instance requires a newer MID Server build.

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.

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.

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.

The database folder

Why it fails: The MID Server database folder holds transient queue and cache data rebuilt from the instance, so backing it up preserves nothing unique to the configuration. It tempts because databases usually warrant backup, but here the critical items are the agent's config.xml and keystore files, which hold instance credentials and connection settings.

The temporary file folder

Why it fails: Temporary files are working data cleared and recreated by the MID Server during normal operation, so they hold no configuration value. The option tempts because temp directories are sometimes included in generic server backups, but the critical items are config.xml and the keystore, which define the agent's identity and connection.

The logs folder

Why it fails: Logs record past agent activity for troubleshooting and are regenerated automatically, so they are not critical to restore a MID Server configuration. The option tempts because logs are commonly backed up in server administration, but the essential files are config.xml and the keystore, which carry the instance URL and authentication material.

To keep track of discovered CI data

Why it fails: Discovered CI data is written to the CMDB through identification and reconciliation, not to the MID Server log. It is tempting because the MID Server performs the discovery, but its log records agent events and probe errors, not the resulting configuration item records.

To store credentials

Why it fails: Credentials are held in the credentials store and referenced by discovery, never written to the MID Server log. It is tempting because the MID Server uses credentials to authenticate to targets, but the log captures execution events and errors, not secret values.

To store user activity

Why it fails: The MID Server log records the agent's own operational events, such as probe execution, connectivity and errors, not user activity. It is tempting because audit trails exist elsewhere, but user activity is captured in the audit log, not the MID Server log used for discovery troubleshooting.

The Discovery Schedule's IP range and MID Server selection.

Why it fails: The Discovery Schedule controls when and where discovery runs, but if the server is being discovered and probes are running, the schedule is functioning correctly. The problem is with classification, not with targeting or scheduling. Adjusting the schedule would not fix the classification mismatch.

The Discovery Behavior's probe order and pattern selection.

Why it fails: The Discovery Behavior determines which probes and patterns are executed for a given classification, but it does not define the criteria for matching a Classification record. If the pattern is already triggering, the behavior is likely correct. Checking the behavior would not resolve why the classification is not being applied.

The MID Server's capabilities and supported patterns.

Why it fails: MID Server capabilities determine which patterns can be executed, but if the pattern is already triggering, the MID Server supports it. The issue is not about pattern execution but about classification matching. Checking MID Server capabilities would not address the missing classification.

The CI Class's 'Discovery' related list of patterns.

Why it fails: The CI Class's Discovery related list shows which patterns are associated with that class, but it does not by itself control whether software details are gathered. Missing software on a successfully classified Linux server usually points to the pattern's own probe and step configuration rather than the class-to-pattern association, which already worked well enough to classify the device correctly.

The Discovery Schedule's 'Max Run Time' value.

Why it fails: Max Run Time limits how long a discovery schedule can execute before it is stopped. If the device completed successfully within the run, the limit did not truncate its data collection. A too-short Max Run Time typically produces incomplete or cancelled statuses, not a successful completion with missing software details, so this setting is not the likely cause here.

The MID Server's 'Max Threads' parameter.

Why it fails: Max Threads controls how many concurrent operations a MID Server can execute. Reducing it can slow discovery or cause queuing, but it does not selectively strip software data from an otherwise successful discovery. A thread shortage would affect many devices broadly and would show as delayed or failed probes, not as a clean completion with no software records for one server.

The Discovery schedule's MID Server selection criteria

Why it fails: MID Server selection determines which MID Server runs the discovery, not which value wins during reconciliation. Choosing a different MID Server would not change how the CPU count attribute is reconciled, so this is not the cause of the value reverting.

The MID Server's probe timeout setting for the Linux command probes

Why it fails: Probe timeouts affect whether commands complete and return data, not which value is stored after a successful return. Since discovery is correctly reporting 8 CPUs, the probe is completing successfully and the timeout is not the reason the value reverts.

The pattern's CI Identification section for the Linux Server class

Why it fails: Identification rules decide whether the discovered device matches an existing CI, not which source wins for a stored attribute value. Even a perfectly configured identifier would not explain why a correctly reported CPU count is overwritten after discovery.

error.log

Why it fails: There is no standard 'error.log' file in the MID Server directory. The MID Server logs are typically named 'agent0.log.0', 'agent0.log.1', etc. Checking a non-existent file will not help. Always refer to the official documentation for log file locations and names.

wrapper.log

Why it fails: The 'wrapper.log' file logs messages from the Java Service Wrapper, which manages the MID Server process. While it can show if the service started or stopped, it does not contain detailed connection errors. For connection issues, 'agent0.log.0' is more informative. The wrapper log is useful for service-level problems, not application-level connectivity.

mid.log

Why it fails: The 'mid.log' file does not exist by default. The MID Server uses log4j and creates files like 'agent0.log.0'. Assuming a generic 'mid.log' could lead to wasted time. The correct log to check is 'agent0.log.0' for connection and startup issues.