Discovery Troubleshooting Guide - Protocol Level Table of Contents SNMP Some Knowledge:Classification:Pattern Debug: SSH Some Knowledge:Classification:Pattern Execution: WMI & WinRM Some Knowledge:Classification:Pattern Execution: SNMP Some Knowledge: For detailed discovery flow on SNMP, please refer "SNMP discovery Explained".Credential troubleshooting, refer "Credentials/Permissions troubleshooting on Discovery, Service Mapping, Orchestration"To check on SNMP support and the credentials configuration a good place to refer "SNMP support for Discovery" from ServiceNow docs.Refer ServiceNow doc "Load a MIB module" for the procedure to add new MIB. Classification: Confusion with SNMP classification type, it is supported in 2 ways One way through Classification Criteria where some prepopulated parameters are verified using some conditionsAnother way directly using device OIDs which are attached to classifier if some OID matches If device OIDs attached to the classifier, the classification is done by classifier directlyIf device OIDs not attached to the classifier, then the classification criteria come into play while classifyingMake sure that the Device SNMP OID records have correct references for Classifier and CMDB table present. Pattern Debug: In case of new enhancement need to investigate correct MIB that needs to be added in ServiceNow instanceSNMP query failing in pattern debug The potential issue would be MIB or OID or both not being available, check if available in instance. If SNMP query gets timeout o Increase timeout in property [mid.snmp.request.timeout]. Refer doc hereIf timeout doesn't work, split the OID table into 2 or 3 tables with few columns and merge these tables to combine all the columns into a single table. This would help SNMP to query limited columns in every call. MIB not listed in pattern designer while debugging in MIB browser It only shows MIBs that are already available in the instance, check the respective MIB available in the instanceIf needed to debug external MIBs, add new MIB and then will be available in pattern designer If no response for SNMP query Check with the customer whether it is a customized device, in that case, OOB discovery it is not supportedGet latest OIDs and MIBs from the respective vendorAdd OIDs in the classifier and add MIBs to the instance.Rerun discovery SSH Some Knowledge: Refer ServiceNow doc "SSH credentials" for basic support for issues with credential setup and configurations.For getting some information on servers mid needs some higher privileges to fetch that information. Refer ServiceNow doc "MID Server privileged commands" for this related support.Refer ServiceNow doc "SSH commands for Discovery" for basic commands that are used in ssh discovery which do not need any elevated privileges.Credential troubleshooting, refer "Credentials/Permissions troubleshooting on Discovery, Service Mapping, Orchestration" Classification: Refer "Troubleshooting the Classification Phase in Discovery" for issues with classification when conflicting with SNMP Vs SSH. Pattern Execution: There can be chances that ssh commands doesn't timeout and could run into pattern failures or keep executing without termination.In that case add the mid property "mid.sa.ssh.timeout" with more than 60000 milliseconds (Default value) and try running discovery. WMI & WinRM Some Knowledge: Refer ServiceNow docs "Windows credentials" for credential setup/requirements/privileges for windows environment discovery.Refer ServiceNow docs "Credentials troubleshooting" for credential troubleshooting and "Credentials/Permissions troubleshooting on Discovery, Service Mapping, Orchestration" as well.Refer solved community resolution "WMI issues on Discovery of workstations" for windows workstation discovery where we get RPC errors.A very good "MID Server: troubleshooting WMI/Powershell issues - Credentials" for credential issues w.r.t WMI/Powershell.Refer "Windows Discovery - Troubleshooting WMI/Powershell issues on the remote machine" for debugging any WMI/Powershell issues directly on target machine to assist for customers.Refer ServiceNow docs "Configure MID Server as WinRM trusted host" for supporting discovery to be able to run through WinRM protocol as we need to add in trusted host list.Refer "Resolving issue of RPC Server unavailable during Windows Server discovery in Service Mapping" for RPC server issues for windows servers discovery.Refer "Firewall blocking Discovery access to the Windows Server" for firewall issues while discovering windows servers. Classification: Refer "Troubleshooting the Classification Phase in Discovery" for issues with classification when conflicting with other protocols (SSH, SNMP etc.).There can be chances that within windows servers and desktops, discovery could classify it incorrectly, so have to check the OOB windows classifiers and their order which would give an idea.If you get "Active, couldn't classify: No WMI connection" error try things mentioned below: This error could be a credential issue or blocked port issue. I would suggest 2 troubleshooting steps to help resolve this error. First, validate the Credential using RDPRDP from the MID server to the Remote Windows host to validate the Windows credential. This will validate the credential outside of ServiceNow discovery. This step only validates the credential - because RDP communicates on port 3389 to login to the Remote Windows host while ServiceNow Discovery uses a different range of ports for login and discovery communication. Check the WMI port 135 and port ranges 49152 - 65535 are open. Validate the ServiceNow Discovery WMI ports between the MID Server and the Remote Windows host are open (in the Windows Firewall and/or any firewall between the MID Server and the Windows host). ServiceNow Discovery uses WMI for discovery, therefore port 135 from the MID Server to the Remote Windows host must be open for initial communication AND high ports 49152 - 65535 must be open for the remainder of the communication. Even though this is a large range of open ports, only a portion of this range are dynamically allocated.If Steps 1 (validated credential) and 2 (validated WMI ports are open) have been completed successfully, then I suggest troubleshooting the Windows Host itself. Pattern Execution: There can be chances that ssh commands doesn't timeout and could run into pattern failures or keep executing without termination. In that case, add the mid property "wmi_timeout" with more than 5 min (Default value) and try running discovery.Refer ServiceNow docs "Windows probes and permissions" for any registry related step failures in windows patterns which explains about the permissions required and administrative shares. Note: Refer ServiceNow docs "MID Server parameters" for all kinds of mid properties that will help in discovery debugging for each above protocol and various other scenarios as well.