
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 04-27-2020 05:54 AM
Port scan/Scanning Phase(troubleshooting) :
- Shazzam cannot find any devices at all
-
- It could be a network connectivity issue.
- Shazzam cannot find any particular type of devices (SNMP/SSH/WMI)
-
- If it is not a network issue, first check the port_probe_spec Shazzam output payload and make sure your port is being scanned. If it is not scanned, then check the behavior of the schedule
- The MID Server is not turning information for a certain network segment, or for the entire network
-
- Check network connectivity using PING, TRACEROUTE, TELNET, and SNMP scanning tools.
Make sure the MID Servers that Discovery is using can reach the desired segments of the network.
Classification Phase(troubleshooting) :
- Authentication: The proper probe credentials must be available on the instance. The credentials provided must have the right to perform the probes in question.
- Connectivity: Socket timeouts and other forms of IO issues may be due to network configuration, congestion, or firewalls. Placing a MID in the same LAN as the target device may solve some of these issues.
- Logical firewall: In WMI communication, traffic only initiates on port 135. When two Windows operating systems communicate with WMI, they actually negotiate unused high ports to finish the conversation. This presents a problem for logical firewalls in Windows systems. Normally, firewalls allow port 135 to be seen as it is with the Discovery port scan probe, but block the high ports that Discovery needs to communicate. To overcome this, use either of the these options:
-
- Configure firewalls to allow any port to use any protocol from the MID Server’s host, using the WMI script that is run locally.
- Lock down WMI to specific ports.
Identification Phase(troubleshooting) :
- If the identity probes are somehow not launched, check the following
-
- Did the classification probe run successfully? If not, check the credential against the target.
- Find the appropriate classification (UNIX, Windows, SNMP) and check if the identify probe is included in the Triggers probe related list. If not, add it back in.
- Discovery is overwriting the incorrect CI record
-
- This could happen if, during the identification phase, an identifier finds a match in the CMDB that is, in fact, incorrect. This can be remedied either by not using the serial number identifier, or by modifying the serial number input so that the serial number is always unique.
- I have different CIs that overwriting each are other in the same record
This is typically due to an identifier mistaking the same record in the CMDB for different devices. For example, there are two devices with the exact same name and they somehow have no serial number as the identifiable information. Discovery always ends up creating/updating the same record for both devices. If both devices happen to be in the same Discovery run, it would even look like they are the same CI with multiple IPs and one gets the Identified, ignored extra IP message.
Exploration Phase(troubleshooting) :
-
- WMI and Powershell
-
- Ensure that the domain is specified, along with the username in the credentials.
- The remote server machine does not exist or is unavailable
- Failed to access target system. Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
- Failed to access target system. Please check credentials and firewall settings on the target system to ensure accessibility: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
-
-
- From the command prompt on the mid server host, execute for
wmic /node:"<target>" /user:"<user>" /password:"<password>" path win32_operatingsystem
- From within a Powershell console on the mid server host, execute for runner_type=Powershell
gwmi win32_operatingsystem -computer <ip> -credential '<username>'
- It is possible that probe is timing out while waiting for a response. If the command is successful from a command prompt, try extending the wmi_timeout value of the probe.
- From the command prompt on the mid server host, execute for
-
if this article helped you in any way then mark it helpful and bookmark it for future use.
- 5,254 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi,
Thank you for detailed post on discovery.
I am new to discovery and trying to find documents on windows discovery failure errors and troubleshooting. Common errors like Adding target to blacklist, no valid creds found etc. If you have created any blog/ channel / post please share. It would be so helpful.
Thanl you!
Rutuja
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I am new to discovery as well. I have been trying to discover Windows but keeps getting "Active, couldn't classify: No WMI connection, now finished" message on the discovery log. I have used the troubleshooting steps mentioned in your forum. Hopefully we can get it running.