8/24/2017 ServiceNow KB: Troubleshooting the Exploration Phase in Discovery (KB0535240)

Troubleshooting the Exploration Phase in Discovery

5602 views
Number:KB0535240 (https://hi.service-now.com/kb_view.do?
sysparm_article=KB0535240)

Video Tutorial: Troubleshooting a failed Discovery: Exploration Phase

Troubleshooting a Failed Discovery Part 5 of 5: Exploration Phase

Details

This article pertains to Discovery with probes and sensors (not patterns).

CI Classification triggers the initial probes that are launched during the exploration phase. All exploration probes that meet the following conditions are triggered
a er the identification probe:
1. Phase = Exploration
2. Active = True
3. Condition script is empty or evaluates to true
Additional exploration probes can also be triggered via the Process Classification or within the script of a sensor.

During exploration, most probes use the same credentials used during classification and identification, however there are probes that have additional
requirements.
1. VMware vCenter and ESX/ESXi
While discovering a Windows Server, if an active process is classified as vCenter, the VMware - vCenter probe is launched. The credential used for
this probe is of type=VMware.
During the processing of the results from the VMware - vCenter probe, for each ESX server that is found, a CIM - ESX Chassis Serial Number probe
is launched. This probe uses the credential type=CIM
For addition details, see Discovery for VMware vCenter (https://docs.servicenow.com/bundle/istanbul-it-operations-
management/page/product/discovery/concept/c_DiscoveryForVMwareVCenter.html).
2. Microso SQL
While discovering a Windows Server, if an active process is classified as Microso SQL Server, the Windows - MSSQL probe is triggered. The
requirements for this probe are outlined in our document Microso SQL Servers (https://docs.servicenow.com/bundle/istanbul-it-operations-
management/page/product/discovery/concept/c_Microso SQLServerDiscovery.html).
3. SSH commands that require sudo:
Certain SSH probes require elevated privileges and leverage the use of sudo. Here (https://docs.servicenow.com/bundle/istanbul-it-operations-
management/page/product/discovery/reference/r_CmdsReqRootDiscoAndOrch.html) is a list of the probes.

Troubleshooting

The same commands within Discovery probes can be executed outside of the ServiceNow instance on the MID Server host. Typically this is the best way to
troubleshoot.
WMI
Use the command line tool wmic to target WMI Objects and registry paths.
Use the command line tool cscript to run javascript against a remote machine.
Powershell
Within Powershell, use gwmi to target Managed Objects and registry paths.

https://hi.service-now.com/kb_view.do?sysparm_article=KB0535240 1/3
8/24/2017 ServiceNow KB: Troubleshooting the Exploration Phase in Discovery (KB0535240)
SSHCommand
Use an SSH client and connect to the target machine with the same credential that Discovery should be using.
Once connected, execute the same command or script.
SNMP
Use a command line tool like snmpwalk to target OIDs on a remote device.
Use Wireshark or tcpdump to capture packets between the MID server host and the device to verify whether packets are being transmitted.

Watch Out For

A credential that is successful during the Classification and Identification does not imply that it is successful during Exploration.
Be wary of the order of credentials. Multiple credentials may have access to the same target, each with dierent privileges.
Probes have a timeout. A probe may return incomplete information or display a timeout error. This may imply that the data is too large to return in the
given time or the MID Server is too far from the target. It is possible to extend the timeout of a probe.

Common Exploration Phase Errors

Below is a list of common exploration phase issues as well as suggestions on how to resolve them.
WMI and Powershell
The impersonation of the user failed.
Ensure that the domain is specified, along with the username in the credentials.
Connection failed to WMI service and other common Windows (WMI/Powershell) error messages:

Error: 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)

WMI, does the mid server service account have access to the targeted machine? What if a domain admin account is used as the mid server
service account?
From the command prompt on the mid server host, execute for runner_type=WMI

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.

vCenter Discovery
Unable to establish connection to https://10.249.17.207/sdk
No VMWare type credential is stored in the credential table.
The user name being used is a domain account and needs to be prefixed with a domain.

CIM_RegisteredProfile{{RegisteredName='Base
Server'}}.CIM_ElementConformsToProfile{{ResultClass:'CIM_ComputerSystem'}}.CIM_ComputerSystemPackage{{ResultClass:'CIM_Chassis',PackageType='3'}}.*
- CIM_RegisteredProfile - Authentication failed.
No CIM type credential is stored in the credential table. Also, seevCenter: Setting up CIM read-only access:Creating a local read only user
(http://community.kaseya.com/kb/w/wiki/932.aspx) and Dedicated CIM account fail (http://communities.vmware.com/message/1644658).

com.vmware.vim25.NoPermission errors
Need to have a credential of type=VMware within the Credentials table. If the user is part of the domain, it needs to be explicitly defined,
username=domain\user.
Withinecc_agent_jar, vijava.jar there needs to be an attached and readable (downloadable) jar file.The MID server needs to be able
to download this jar.

MSSQL
Cannot find type [Microso .SqlServer.Management.Smo.Server]: make sure the assembly containing this type is loaded
You need to installMicroso SQL Server management library (SMO) per the followingMicroso SQL Servers
(https://docs.servicenow.com/bundle/istanbul-it-operations-
management/page/product/discovery/concept/c_Microso SQLServerDiscovery.html).
java.sql.SQLException: com.microso .sqlserver.jdbc.SQLServerException: SQL Server version 8 is not supported by this driver
Microso dropped support for SQL Server 2000 (8.0) (http://msdn.microso .com/en-US/data/928484) in JDBC version 4, in exchange for native
support for SQL Server 2012.

https://hi.service-now.com/kb_view.do?sysparm_article=KB0535240 2/3
8/24/2017 ServiceNow KB: Troubleshooting the Exploration Phase in Discovery (KB0535240)

Article Information
Last Updated:2017-03-01 10:39:34
Published:2014-03-10

https://hi.service-now.com/kb_view.do?sysparm_article=KB0535240 3/3