Understanding the Asset Report

The Asset Report is meant to be a listing of devices discovered within the customer environment. It should be used in an iterative process for scope setting/discovery of the customer’s environment (i.e. it is used as a working document throughout multiple scans to troubleshoot and discover further areas of a customer’s environment until the target scope is achieved).

Discovery (IP (ICMP) sweep) -> Inventory (credential check) -> Licensing -> Performance (ongoing polling on licensed devices)

The Asset Report is generated after the RN150 has completed the inventory phase. The appliance/assessment always works in this manner:

The Asset Report lists all devices that responded to an ICMP ping. Additionally, if we were able to connect to them using the provided credentials and categorize them they are further classified into device types (e.g. Windows Server, Windows Workstation, etc). The Asset report is accessible in the CloudScape Portal by clicking “Consume Intelligence > Assets”. Each link in the Asset Report aligns to a specific credential input into the appliance. (i.e. Devices under the Windows Server link indicate we have WMI access to that box, the Linux/Unix link shows SNMP accessible devices, if it is in the Virtual Machine link we have vCenter access, etc.) Clicking each link will filter the table below to show just those devices. The Asset report can also be downloaded into an excel spreadsheet; either filtered to a specific device type or the entire report.

Key Takeaways

  • The report is additive. With each successive rescan of the environment the newly discovered data will be added to that of the previous scan. Data is never removed, even in the event that credentials or subnets are removed or deselected for scanning in the appliance.
  • There is often overlap between the links. Since they correspond to a credential we could have a Windows VM that is in both the Windows link and the VM link as it responded to both sets of credentials (Windows Admin and vCenter). Additionally, it can be in the inaccessible devices link if one credential worked, but not another (e.g. vCenter passed, but Windows failed). Please note that the RISC Networks platform will resolve the duplicate devices when doing subsequent reporting (you will only see one device for the VM and Windows Server), but the asset report is purposefully left as-is so that virtual teams and windows teams can both confirm the expected asset list.


As you work with the customer on scope setting you will undoubtedly spend time reviewing inaccessible devices. Devices end up in this category because at least one set of applicable credentials were attempted and were unable to gain access to the device(s). During the inventory phase we look to see what ports are open on a specific host. If we see ports for WMI or SNMP open then we will attempt to use the corresponding credential.

For Windows devices we get an additional layer of error messages (NT STATUS codes) to assist in troubleshooting. Those common error messages are listed below:

Error Reason
NTSTATUS: NT_STATUS_CONNECTION_REFUSED – NT_STATUS_CONNECTION_REFUSED Non-Windows device, Firewall rule – verify the IP address is a Windows device and there are no access restrictions between the virtual appliance and the end device
NTSTATUS: NT_STATUS_ACCESS_DENIED – Access denied Invalid username/password, user account is not Domain Administrator or Local Administrator – verify username/password is correct, verify username is either domain administrator or local administrator account
NTSTATUS: NT_STATUS_IO_TIMEOUT – NT_STATUS_IO_TIMEOUT Firewall, host unreachable – verify there are no access restrictions between the virtual appliance and the end device. Verify that
NTSTATUS: NT_STATUS_HOST_UNREACHABLE – NT_STATUS_HOST_UNREACHABLE The remote network is not reachable by the transport – verify host is IP reachable
NTSTATUS: NT_STATUS_NETWORK_UNREACHABLE – NT_STATUS_NETWORK_UNREACHABLE The remote network is not reachable by the transport – verify host is IP reachable

Devices that were identified as neighboring devices by other routers or switches that the RISC platform does have access to, will be included under inaccessible devices.

Generally, it is best to focus on those devices that are identified in the MAC manufacturer as common server or VM manufacturers (VM Ware, HP, Dell, etc.). We will uncover any device in the environment that responds to ICMP ping (has an IP), so there can be many devices in this tab that are not in scope or useful to your objective.

Lastly, in many cases customers may not be sure the scope is correct. That’s okay, this is an iterative process and is designed such that we can always come back and rescan. You may find, once you have collected performance data on the scope and started working on grouping applications, traffic going to IPs that are out of scope. This is covered in our Application Grouping Workflow document, but know that discovery can be an iterative process. You will get further data to help you disposition the environment as you continue in the assessment process. Think of it as you are illuminating a dark room; it is not possible to fully light the room without understanding how big it is. Start with what you have so you can use it to illuminate other dark corners of a customer’s environment.