Discovery Errors for Devices being discovered by alternate Discovery Sources

[gagribben]

Good morning, I am currently looking into our Discovery Errors and find that most errors come from Credentials or Active Couldn't Classify. The error is coming from ServiceNow Discovery (IP based schedules). We have alternative methods of discovery, such as SG-Intune, SG-SCCM, SG-Solarwinds, etc. The device associated with the IP based schedule that is triggering an "error" is discovered by one of the aforementioned integrations. How should we handle errors given this situation?

[Mark Manders]

This means that Discovery does not have access to the device, based on the credentials with which it is discovered. You will need to ensure you run that IP through a discovery source that does have access, or grant the current discovery source the access.
Or, if the device shouldn't be discovered, just ignore the warning (what you described isn't really an error, but just a notification to you to say that there is a device that can't be discovered).

[gagribben]

Mark, Yes I do understand what you are saying. However, if we have a device that is configured for discovery via SCCM, we would not require Windows credentials and the error "Windows authentication failed" would be expected and redundant. Example, device A is in SCCM, device A has a ci created via the SCCM integration. Device A is ALSO being scanned by the IP network scans, an error is generated on the IP network scan due to invalid/missing credentials. We have 75 Windows Authentication Failed Errors, of these how would we differentiate a true Windows authentication (no ci being created) versus cis that have been created due to alternative discovery sources, in which we already have a CI created.

[Selva Arun]

Good morning, gagribben!

Based on your scenario, where devices are being discovered by alternate sources (e.g., SCCM, Intune, SolarWinds) but still trigger errors during IP-based Discovery scans, here’s how you can approach the issue:

1. Understand the Root Cause

• The "Windows Authentication Failed" error occurs because the IP-based Discovery schedule is attempting to classify the device using Windows credentials, which are either invalid or missing.
• However, since the device is already being discovered and its CI is created/updated via an alternate source (e.g., SCCM), this error is redundant and does not indicate a failure in maintaining the CI.

2. Differentiate Between True Errors and Redundant Errors

To distinguish between devices that truly require Windows authentication and those already managed by alternate sources:

• Check the Discovery Source:
• Navigate to the CI record in the CMDB and review the Discovery Source field.
• If the Discovery Source is set to SCCM, Intune, or another integration, the error from the IP-based Discovery can be ignored.
• Filter Errors by Discovery Source:
• Use the Discovery Log or Discovery Errors module to filter errors by Discovery Source.
• Focus on errors where the Discovery Source is ServiceNow Discovery and no CI exists for the device. These are the true errors requiring attention.

3. Suppress Redundant Errors

If you want to avoid seeing redundant errors for devices managed by alternate sources:

• Exclude IP Ranges:
• Update the IP-based Discovery schedule to exclude IP ranges for devices managed by SCCM, Intune, or other integrations.
• This prevents the IP-based Discovery from attempting to scan devices already covered by alternate sources.
• Use Discovery Rules:
• Configure Discovery Behavior Rules to prioritize alternate sources (e.g., SCCM) over IP-based Discovery.
• For example, if a device is already discovered by SCCM, the rule can suppress further classification attempts by IP-based Discovery.
• Ignore Specific Errors:
• Use Discovery Error Rules to suppress specific errors (e.g., "Windows Authentication Failed") for devices with a Discovery Source of SCCM, Intune, or SolarWinds.

4. Validate the Current Configuration

• Review your Discovery schedules and ensure that devices are not unnecessarily scanned by multiple sources.
• Ensure that credentials for IP-based Discovery are valid for devices that require them (e.g., devices not covered by SCCM or other integrations).

5. Best Practices for Managing Discovery Sources

• Prioritize Discovery Sources:
• Use the Reconciliation Rules in the CMDB to ensure that the most reliable source (e.g., SCCM) is the authoritative source for specific attributes.
• Regularly Audit Discovery Errors:
• Periodically review Discovery Errors to identify patterns and refine your Discovery schedules and rules.
• Document Exclusions:
• Maintain documentation of which devices are managed by alternate sources and excluded from IP-based Discovery.

Example Workflow for Your Scenario

1. Device A is discovered by SCCM, and its CI is created in the CMDB with Discovery Source = SCCM.
2. The IP-based Discovery schedule scans the same device but fails due to missing Windows credentials, generating a "Windows Authentication Failed" error.
3. To handle this:
• Check the CI for Discovery Source = SCCM.
• Suppress the error using a Discovery Error Rule or exclude the device's IP range from the IP-based Discovery schedule.

By implementing these steps, you can focus on true Discovery errors while avoiding redundant notifications for devices already managed by alternate sources.

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration.

Selva Arun

Note: I have used ChatGPT to rephrase my sentence and solution for better clarity and grammar.