DiscoveryAccess page

A DiscoveryAccess is a single access to a Discovery Endpoint. When an endpoint is scanned, a DiscoveryAccess node is created which records information on the interaction that BMC Atrium Discovery has with that endpoint. When BMC Atrium Discovery is unable to access a host, the DiscoveryAccess is a good starting point for troubleshooting.

To view a DiscoveryAccess page

You can view DiscoveryAccesses from a number of places in the user interface.

From a Host Node

From the view page for a host node:

Scroll down to the Inference section
Click the main link in that section, for example: 172.17.3.116 SUCCESS 09/12/2008 10:48 - 09/12/2008 10:55
The Example DiscoveryAccess is shown.

From the Discovery Recent Runs page

From the Recent Runs tab of the Discovery Status page:

Click a discovery run.
Scroll down to the Endpoint field.
Click the DiscoveryAccess link. If it is a link to a single DiscoveryAccess, then that Example DiscoveryAccess is shown. If there are multiple DiscoveryAccesses, then a list page is displayed.
Click a DiscoveryAccess line to view the Example DiscoveryAccess.

Example DiscoveryAccess

The following screens show DiscoveryAccess pages for a Unix host, a Windows host, a network device, and a mainframe computer.

Attribute	Description
Endpoint Section
Endpoint	The endpoint (IP address) scanned in this discovery access.
Start Time	The time at which the scan started.
End Time	The time at which the scan finished.
Total Duration	The time it took to discover and process the data, that is, the time between Start Time and End Time.
Discovery Run	A link to the Discovery Run that this DiscoveryAccess is part of.
Previous Discovery Access	A link to the previous DiscoveryAccess with the same endpoint. Not displayed if this is the first in a list.
Next Discovery Access	A link to the next DiscoveryAccess with the same endpoint. Not displayed if this is the last in a list.
Device Summary	An read-only summary showing the Host Type, Discovered OS Type, and Discovered OS Version. For example, Unix Server, Debian Linux, 4.0.
Host	A link to the host that was created or updated as part of the scan. Not displayed if no host was created or updated.
Status Section
State	The current state of the DiscoveryAccess. This may be Started or Finished.
End State	The end state of the discovery run. This may be one of the following: Successful discovery results in GoodAccess; during processing you may see first DeviceIdentified and later HostInferred. For optimised discovery, that is, started but stopped for a reason, you may see Opt1stScan, OptNotBestIP, OptRemote, OptAlreadyProcessing. For unsuccessful discovery you may see NoResponse, UnsupportedDevice, NoAccess, Excluded, Error. See the table below for information on how the end state and result relate to the discovery scenario.
Result	The result of the DiscoveryAccess. This may be Skipped, NoResponse, Success, NoAccess, or Error. See the table below for information on how the end state and result relate to the discovery scenario.
Errors	If there were any errors detected by the ECA engine during discovery this will link to those errors. Examples are: `Error detected by the ECA engine`: This is typically an internal rule error or pattern error. Usually triggered when the data returned does not match what is expected. `Unable to get the deviceInfo: ExecutionFailure`: Discovery has attempted to run a command but a failure has been reported. `Unable to get the deviceInfo: NoAccessMethod`: No access method, this is frequently because it is not meaningful, such as getting patches on Linux. `Unable to get the deviceInfo: NoSuchDevice`: There is a `NoResponse` endstate. That is, nothing detected on the IP address. `Unable to get the deviceInfo: TRANSIENT` `Unable to get the deviceInfo: TRANSIENT_CallTimedout`: Probably caused by the reasoning timeout; the call to discovery is taking too long to complete. `Unable to get the deviceInfo: UNKNOWN`: Some other CORBA error. Contact Customer Support.
Session Results	If there were any failures attempting to get a session on the endpoint this will link to a list of failures and successes. See below for details.
Discovery Details Section
Data Source	Does this Discovery Access originate from this appliance, come from a scanning file, or was it consolidated from a scanning appliance.
Credential Used	A link to the Windows proxy or Credential used to in this Discovery Access. The link name is a hash of details of the credential; it does not provide the credential itself. You are not shown the Credential pages if you do not have permissions to view them. This field is not displayed as a link on the consolidation appliance for scans which have been consolidated from a scanning appliance.
Discovery Start Time	The time at which discovery started on the scanning appliance. This field is only displayed on the consolidation appliance for scans which have been consolidated from a scanning appliance.
Discovery End Time	The time at which discovery completed on the scanning appliance. This field is only displayed on the consolidation appliance for scans which have been consolidated from a scanning appliance.
Session Establishment Duration	The time it took to establish the session, that is, to log onto the host.
Total Discovery Duration	The time taken to establish a session and run commands.
On Hold Since	If the discovery is currently paused, the time at which it was paused.
On Hold Duration	If the discovery has been paused, the elapsed time since it was paused.
Standard Discovery
Method	The discovery method used. This is one of: getDeviceInfo, getHostInfo, getInterfaceList, getProcessList, getPackageList, getPatchList, getNetworkConnectionList, getHBAInfo, and getNames.
Status	The status of the discovery access for the method. This is OK or the failure reason.
Script	The name of the script used, if any.
Access	The access method used to connect to the endpoint (for example, ssh, telnet, rlogin, and so on.
Result	A link to the node or nodes created by this discovery method.
Additional Discovery
Method	The additional discovery method used. These are discovery methods called by patterns, for example: `getFileInfo` `getFileMetadata` `runCommand` `getDirectoryListing`
Status	The status of the discovery access for the method. This is OK or the failure reason summarised into links.
Script	The name of the script used.
Access	The access method used to connect to the endpoint. For example: ssh, telnet, rlogin, etc.
Result	A link to the node or nodes created by this discovery method.

DiscoveryAccess state

The following table shows the possible discovery scenarios and the resulting end_state and result attributes of the DiscoveryAccess node:

In addition to end_state and result attributes on the DiscoveryAccess there is also a reason attribute that contains further details. There is no fixed set of values for reason.

The following state diagram and table may be of use understanding the results of an attempted access.

Discovery Scenario	Resulting State of DiscoveryAccess
IP Injected → In Exclude list Example: The user has requested a scan of an IP that is in an exclude range.	`end_state=Excluded` `result=Skipped`
IP Injected → Already Processing this IP Example: The user has requested a scan of an IP that is currently being processed as part of an earlier scan.	`end_state=OptAlreadyProcessing` `result=Skipped`
IP Injected → Second Scan Optimization (Best IP) Example: The user has requested a scan of an IP that is on a host that has already been scanned using another IP address that is considered to be the best IP to use to scan that host.	`end_state=OptNotBestIP` `result=Skipped`
IP Injected → No IP Response Example: No response was received from the scanned IP address.	`end_state=NoResponse` `result=NoResponse`
IP Injected → IP Response Example: After a sweep scan of an IP address, Discovery has received a response. No identification has taken place other than that there is a device of some description that has responded to the sweep scan. If the device is subsequently not recognised then the `end_state` is set to `UnsupportedDevice` as below.	`end_state=DeviceIdentified` `result=Success`
IP Injected → IP Response → Device Type not supported UnsupportedDevice is the default end_state for any device that we can detect but do not have any knowledge of in Reasoning to build an inferred node. We may still be able to identify what the device is and some key properties, or we may know nothing more than the fact it returned a ping. Example: Discovery has received a response from an endpoint but has not been able to identify the device further. This may mean that the OS is unrecognised, garbage has been returned or there is a shell error. This can be caused by a firewall. For more information, see the IP Fingerprinting information in the Base Device Discovery section.	`end_state=UnsupportedDevice` `result=Skipped`
IP Injected → IP Response → No HostInfo recovered	`end_state=NoAccess` `result=NoAccess`
IP Injected → IP Response → No InterfaceList recovered	`end_state=NoAccess` `result=NoAccess`
IP Injected → IP Response → HostInfo and InterfaceList recovered	`end_state=HostInferred` `result=Success`
IP Injected → IP Response → HostInfo and InterfaceList recovered → First Scan Optimization	`end_state=Opt1stScan` `result=Skipped`
IP Injected → IP Response → HostInfo and InterfaceList recovered → First Scan Optimization not needed	`end_state=GoodAccess` `result=Success`
IP Injected → Traceback captured	`end_state=Error\|ExistingState` `result=Error`
IP Consolidated when originally optimized on Discovery Appliance	`end_state=OptRemote` `result=Skipped`

Troubleshooting using session results

There are three scenarios that are highlighted using Session Results:

Initial scan and successful connection: a number of unsuccessful connection attempts followed by a successful connection shows BMC Atrium Discovery selecting credentials.
Failure to connect: BMC Atrium Discovery was unable to connect. Typical problems could be failed credentials or poor network connectivity.
Failure at start of scan before successful connection: this can occur when a credential fails (expiry) but a later credential is successful.

Checking credentials after a failure

From the Discovery Access, click the session results link.
Click the Connection timed out rows to display the SessionResult page for that specific login attempt.
This page shows information on the attempted login, including a credential link and a link to the DiscoveryAccess. The credential link is a hash of the credential name which links to that credential in the Login Credentials page only if you have sufficient permissions to view the credentials.
Click the test button.
If the credential tests successfully, it is likely that a transient network problem caused the connection time-out. Alternatively, you can navigate back to the Discovery Access page and rescan from the Discovery Actions menu.