- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-02-2025 05:16 AM
Our team reports that Discovery is failing to identify some Linux servers, and the CIs are not being created or updated in the CMDB.
How to troubleshoot ?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-02-2025 05:24 AM
Validate if those linux server are under the ip range of your discovery schedule, check further on the ECC queue and then error tasks. Try these steps, hopefully this will help you in figuring out what is missing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-02-2025 05:45 AM
Hi @sanyalshubh
Below steps will help you :-
1. Verify MID Server Health
Since MID Servers execute Discovery probes, check:
- Status: Navigate to MID Server > Servers and ensure the MID Server is Up and Validated.
- Logs: Review logs under MID Server > Log Messages for errors.
- Permissions: Ensure the MID Server has proper access to the target environment (firewall, network, and credentials).
2. Check Discovery Logs for Errors
Navigate to Discovery > Status > Discovery Log and look for:
- Errors or warnings related to failed authentication, unreachable hosts, or missing permissions.
- Sensor processing errors that may indicate issues with processing returned data.
If Discovery Log shows "No Response from Target", verify network connectivity.
3. Test Network Connectivity
From the MID Server host, run:
- Ping: ping <target_linux_server> → If no response, check firewalls or VPN settings.
- SSH Test:
ssh -v <username>@<target_linux_server>
- If SSH fails, ensure the port (default 22) is open and credentials are correct.
4. Verify Credentials in Discovery
Go to Discovery > Credentials > Credentials and check:
- Ensure valid Linux SSH credentials are present.
- Run "Test Credential" for a failing server.
- If test fails, confirm the user has sufficient sudo privileges (if needed).
✅ Fix: Add the correct user and grant sudo permissions if Discovery requires elevated access.
5. Check Identification & Reconciliation (I&R) Logs
- Navigate to CMDB Identification and Reconciliation > Identification Log.
- Look for errors like:
- Multiple Matches Found (duplicate CIs).
- No Matches Found (discovery failing to identify the CI).
✅ Fix: Adjust Identification Rules for Linux CIs if needed.
6. Review Discovery Pattern Execution
If using patterns:
- Navigate to Discovery > Patterns > Linux Server Pattern.
- Run the Pattern Debugger for failing servers.
- Ensure the correct steps are being executed.
✅ Fix: If steps fail, update the pattern to match the environment.
7. Validate Discovery Schedule & IP Ranges
- Go to Discovery > Schedules and verify:
- The correct IP ranges are included.
- Classification phase successfully identifies Linux servers.
- Run Quick Discovery on an affected server to test.
✅ Fix: Adjust IP ranges or Discovery schedules if needed.
8. Check CMDB Data Integrity
- Navigate to CMDB Health Dashboard and check for:
- Duplicate CIs
- Orphaned CIs
- Outdated CIs
✅ Fix: Run CMDB reconciliation and clean up duplicates.
If you found my response helpful, I would greatly appreciate it if you could mark it as "Accepted Solution" and "Helpful."
Your support not only benefits the community but also encourages me to continue assisting. Thank you so much!
Thanks and Regards
Ravi Gaurav | ServiceNow MVP 2025,2024 | ServiceNow Practice Lead | Solution Architect
CGI
M.Tech in Data Science & AI
ï”— YouTube: https://www.youtube.com/@learnservicenowwithravi
ï”— LinkedIn: https://www.linkedin.com/in/ravi-gaurav-a67542aa/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-02-2025 05:24 AM
Validate if those linux server are under the ip range of your discovery schedule, check further on the ECC queue and then error tasks. Try these steps, hopefully this will help you in figuring out what is missing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-02-2025 05:45 AM
Hi @sanyalshubh
Below steps will help you :-
1. Verify MID Server Health
Since MID Servers execute Discovery probes, check:
- Status: Navigate to MID Server > Servers and ensure the MID Server is Up and Validated.
- Logs: Review logs under MID Server > Log Messages for errors.
- Permissions: Ensure the MID Server has proper access to the target environment (firewall, network, and credentials).
2. Check Discovery Logs for Errors
Navigate to Discovery > Status > Discovery Log and look for:
- Errors or warnings related to failed authentication, unreachable hosts, or missing permissions.
- Sensor processing errors that may indicate issues with processing returned data.
If Discovery Log shows "No Response from Target", verify network connectivity.
3. Test Network Connectivity
From the MID Server host, run:
- Ping: ping <target_linux_server> → If no response, check firewalls or VPN settings.
- SSH Test:
ssh -v <username>@<target_linux_server>
- If SSH fails, ensure the port (default 22) is open and credentials are correct.
4. Verify Credentials in Discovery
Go to Discovery > Credentials > Credentials and check:
- Ensure valid Linux SSH credentials are present.
- Run "Test Credential" for a failing server.
- If test fails, confirm the user has sufficient sudo privileges (if needed).
✅ Fix: Add the correct user and grant sudo permissions if Discovery requires elevated access.
5. Check Identification & Reconciliation (I&R) Logs
- Navigate to CMDB Identification and Reconciliation > Identification Log.
- Look for errors like:
- Multiple Matches Found (duplicate CIs).
- No Matches Found (discovery failing to identify the CI).
✅ Fix: Adjust Identification Rules for Linux CIs if needed.
6. Review Discovery Pattern Execution
If using patterns:
- Navigate to Discovery > Patterns > Linux Server Pattern.
- Run the Pattern Debugger for failing servers.
- Ensure the correct steps are being executed.
✅ Fix: If steps fail, update the pattern to match the environment.
7. Validate Discovery Schedule & IP Ranges
- Go to Discovery > Schedules and verify:
- The correct IP ranges are included.
- Classification phase successfully identifies Linux servers.
- Run Quick Discovery on an affected server to test.
✅ Fix: Adjust IP ranges or Discovery schedules if needed.
8. Check CMDB Data Integrity
- Navigate to CMDB Health Dashboard and check for:
- Duplicate CIs
- Orphaned CIs
- Outdated CIs
✅ Fix: Run CMDB reconciliation and clean up duplicates.
If you found my response helpful, I would greatly appreciate it if you could mark it as "Accepted Solution" and "Helpful."
Your support not only benefits the community but also encourages me to continue assisting. Thank you so much!
Thanks and Regards
Ravi Gaurav | ServiceNow MVP 2025,2024 | ServiceNow Practice Lead | Solution Architect
CGI
M.Tech in Data Science & AI
ï”— YouTube: https://www.youtube.com/@learnservicenowwithravi
ï”— LinkedIn: https://www.linkedin.com/in/ravi-gaurav-a67542aa/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-03-2025 04:38 AM
Thank you so much for the solution, it helped me.