- Critical vs. Non-Critical- The derivation of Critical vs Non-Critical is primarily driven from the identification of traffic that does NOT play a role in application or supporting system communication. Application process and contexts with corresponding traffic supporting the OS or default system level communication is marked as ‘Non-Critical’. Traffic from OS default system processes is also classified as Non-Critical.
- Internal vs. External- An internal connection (displayed as green and blue within the visualization) is one that is internal to the group whereas an external connection (displayed as red and orange within the visualization) is one that is made to a device outside of the select group.
- Application Context- Is a mapped application based on the the process that initiated the connection. This proprietary mapping is maintained by RISC Networks.
- LocationXX: if access to the switching and routing environment is granted via SNMP then the Platform will automatically group devices into Locations based on the routing tables gathered during Inventory
- risc-autoconfiguration: RFC 3927
- risc-broadcast: RFC 919
- risc-loopback: RFC 6890
- risc-multicast: RFC 5771
- risc-reserved: RFC 1700
- risc-testnet: RFC 5737
- risc-unknown-private: (RFC 1918 addresses that are not already assigned a location – which would be all RFC 1918 addresses if there are no routers/switches in scope) RFC 1918
- risc-unknown-internet (all Class A,B, and C addresses that are non-RFC 1918 and are not part of a location – likely all – although we do have a few defined internet locations – such as Amazon EC2 IP Ranges)
Device Type Definitions
Asset Category (2.0)
it will be listed in each of the items listed in this column
|Device found during inventory collection...|
|AP||Basic Devices||via SNMP access AND it reports back as a Wireless Access Point|
|ATA||Basic Devices||via SNMP access AND it reports back as an Analog Telephone Adapter|
|Generic SNMP Device||Basic Devices||via SNMP access though NOT to the required core MIBs|
|Printer||Basic Devices||via SNMP access AND it reports back as a printer|
|Telepresence||Basic Devices||via SNMP access AND it reports back as a Telepresense|
|Virtual-Generic SNMP Device||Basic Devices, Virtual Machines||via VMware access AND we have SNMP access to the device though NOT to the required core MIBs|
|unknown||Inaccessible Devices||successfully ping'd the device though NO supported protocols found|
|unknownNetworkDevice||Inaccessible Network Infrastructure||with NO protocol access AND UDP port 161 open|
|Virtual-unknownNetworkDevice||Inaccessible Network Infrastructure, Virtual Machines||with NO protocol access AND UDP port 161 open (virtual)|
|Virtual-Inaccessible Windows Device||Inaccessible Windows, Virtual Machines||via VMware access only AND port 135 open|
|IP-Phone||IP Phones||via SNMP access AND reports back as an IP Phone|
|Generic Server||Linux/UNIX||via SSH or SNMP access AND reports back as a Linux/UNIX OS|
|Virtual-Generic Server||Linux/UNIX, Virtual Machines||via VMware access AND we have either SSH or SNMP access AND it reports back as a Linux/UNIX OS|
|DB_NOI||n/a||a derived device that is created to represent a database that was not otherwise inventoried|
|NFS||n/a||a derived device (Network File System) that is created if a Generic Server that has a file system mounted from a remote host that cannot be resolved back to a device currently in inventory|
|FC Switch||Network Infrastructure||via SNMP access AND it reports back as a fiber channel switch|
|Firewall||Network Infrastructure||via SNMP access AND it reports back as a Firewall|
|l3switch||Network Infrastructure||via SNMP access AND it reports back as a switch with a routing table|
|router||Network Infrastructure||via SNMP access AND it reports back as a router with a routing table|
|switch||Network Infrastructure||via SNMP access AND it reports back as a switch|
|Orphaned - (Device Type)||Virtual Machines||accessed through VMware AND was licensed but is no longer accessible through VMware|
|Virtual Machine||Virtual Machines||via VMware access only AND device was not included in subnet range for discovery (ping)|
|Virtual-unknown||Inaccessible Devices, Virtual Machines||via VMware access only AND device was successfully ping'd during discovery. See "unknown"|
|Virtual-Windows Server||Windows, Virtual Machines||VMware access only AND we have WMI access AND it reports back as a server OS|
|Virtual-Windows Workstation||Windows, Virtual Machines||VMware access only AND we have WMI access AND it reports back as a workstation OS|
|VMware Host||Vmware Host||vCenter reports this device as the host|
|Inaccessible Windows Device||Windows||no protocol access AND to have port 135 open during discovery|
|Windows Server||Windows||via WMI access AND it reports back as a server OS|
via WMI access AND it reports back as a workstation OS
Devices that are suspected to no longer exist in the IT environment are marked with the RISCdecom flag in the hostname and primary IP address fields. For example, a device with the hostname
test-app-01 would be displayed as
RISCdecom - test-app-01.
This flag is applied when a rescan of the environment with the View Inventory Changes feature enabled fails to communicate with a device that was successfully brought into the Asset inventory on a previous scan. Any error received when connecting to the device other than a "permission denied" error will trigger this behavior. The flag can be removed from the device if a subsequent rescan succeeds in communicating with the device. For instance, if a firewall change results in an inability for the RN150 Virtual Appliance to communicate with a subnet, devices within that subnet will be flagged as RISCdecom when rescanned. A subsequent rescan after correcting the firewall configuration will remove the flag from those devices.
- RSG Groups (aka Infrastructure Service Groups) - servers in these groups match an existing profile for the particular application group they are placed. Details in table below.
- AutoApp_XX Groups - Any device that does not match a predefined profile will be grouped into an AutoApp group based on its critical connectivity.
- Isolated Devices- Devices in this group have had connectivity collected (there is an existing connectivity record where the specific device is either the source or destination of the connection), but none of the collected connections or processes would cause the specific server to join into an AutoApp or RSG Group.
- No Connectivity- Any device where there is not an existing connectivity record where it is either the source or destination of the connection will end up in the No Connectivity group. (i.e. we do not have any connectivity to or from this device)
- RSG-95th Highly Connected Stack- is the top 5% of hosts by connectivity in the network that are available to go into AutoApp_XX groups. In other words, it is the list of servers that talk the MOST that are not RSG eligible.
- RSG-Out of Scope Services- IP addresses and / or device names will appear in this group if they are offering one of the following services: MSSQL, MySQL, oracle, NFS, or iSCSI, but are either not licensed, or their IP is out of scope (not included in the subnet ranges requested to be scanned).
- AutoSchemaDependency_XX- Any device who has a connection collected from our database collection module
The Intelligent Application Grouping Algorithm identifies and isolates devices which provide infrastructure-critical services. These infrastructure services should not be considered part of any individual Business Service, but rather as a distinct type of IT property which may be evaluated and managed separately from the more business-logic-driven stacks which our algorithm identifies based on common connectivity.
Here is a list of all of the Infrastructure Service Groups we currently create. If any servers in your environment fit into one of these groups, the group will be automatically created and the server will be placed into it, rather than into a Business Service group. Note that for historical reasons, the moniker “RSG” is appended to all Infrastructure Service Groups.
Microsoft Active Directory Domain Controllers
Reported in inventory as PDC or BDC
Backup Exec Server
Veritas Backup and Recovery service
Endpoint management services
Endpoint management services
Virtual/remote desktop service
Running Citrix ICA Host
Deep Freeze (NEW)
ECi FMAudit (NEW)
Running Eci FMAudit Onsite
Application performance monitoring
Running egurkha and nfping
Data protection and backup
Running nsrjobd or nsrmmd
Virtual infrastructure management
Data retention and archiving
ERA Remote Administrator (NEW)
ERA Remote Administrator
ESET Remote Administrator (NEW)
ESET Remote Administrator
Running SET Remote Administrator Service
Graphite monitoring tool
Running carbon-cache or carbon-relay
Kaspersky Lab Administrator (NEW)
Running Administrator Kit Server
IT asset management
Chat (Skype for Business)
Running Lync server processes
McAfee ePolicy Orchestrator
Running ePolicy Orchestrator
McAfee antivirus security
Microsoft Exchange Server
Running Microsoft Exchange Server
Microsoft Operations Manager
Datacenter monitoring service
Nagios monitoring tool
Running NRPE daemon
Network Storage devices
Hostname matches “netapp” or “isilon”
Switches, routers, access points
Reported in inventory as switch, router, or access point
Network File System servers
Octopus Deploy Server (NEW)
Continuous delivery and deployment
Running Octopus deploy server process
Papercut Print Control (NEW)
Parity Server (NEW)
ServiceNow MID Server
Management, Instrumentation, and Discovery service
Running servicenow or mid server application
ShoreTel IPDS (NEW)
Running ShoreTel ipds
Solarwinds network monitoring
Running a non-agent solarwind process
Solarwinds Serv U File Server (NEW)
Managed File Transfer
Running Sophos Management Server or Console
SOTI Mobicontrol Deployment Server (NEW)
Mobile/IOT endpoint management
Running SOTI mcdeplsvr
Running splunk service processes
Symantec antivirus security
Running Symantec Endpoint Protection Manager
Trend Micro Service
Trend Micro antivirus security
Running Trend Micro or Officescan database server process
Veeam backup and data recovery
VMWare Horizon (NEW)
Virtual desktop manager
Running VMWare Horizon or VMWare View Server processes
VMware Recovery Manager
VMWare disaster recovery
Windows Server Update Service
RedHat repository service
- Burst- This is a 30 day license of performance and dependency data collection. Once a burst has begun the relevant licensing is available for 30 days from start of the burst.
- CCL (Continuous Collection License)- This is a license that is available for the life of the subscription. This allows the user to collect performance and dependency data at any time.
- Flow License- This license allows the user to collect flow data (see the Flow Collection Deployment Guide for more information) and understand bandwidth, latency, etc. about connections within the environment.
Please note: The only valid characters for tag keys and values are alphanumeric, comma, period, hyphen, colon, forward slash, space, and underscore. If any other characters are part of a string that would be added programmatically (i.e. in a DNS tag), those character will be omitted.
App Stack Level
- Application Owner- The person responsible for an application, this is entered manually.
- Application Description- A description of the application, its purpose, and other relevant metadata. This is entered manually.
- Confirmed By- The user who last successfully selected the Stack Confirmed check box. This is entered automatically and cannot be manually altered.
- Confirmed Date- The timestamp of the last time the stack was confirmed. This is entered automatically and cannot be manually altered.
- Department- The department that owns or is responsible for a particular application stack.
- Saved By- The user who last successfully selected the Stack Saved check box. This is entered automatically and cannot be manually altered.
- Saved Date- The timestamp of the last time the stack was saved. This is entered automatically and cannot be manually altered.
- Stack Confirmed- This is a modal whereby if a stack is confirmed it can signal that the stack has been reviewed for accuracy by the appropriate individuals as well as it becomes unavailable for auto-grouping (aka build app stacks).
- Stack Saved- This is a modal whereby if a stack is saved it can signal that the stack becomes unavailable for auto-grouping (aka build app stacks).
- Application Instance- This is the instance name collected from any identified application running on the host server.
- Database Instance- This is the instance name collected from the database application running on the host server.
- Tier- This is the application tier type that a server matches based on the rules below.
- rscore- This is the migration pattern that a server matches based on the rules below.
rscore - Replatform
Server OS Contains 2003 OR Server OS Contains 2000
rscore - Refactor
Server OS Contains SunOS OR Server OS Contains AIX
rscore - Rehost
Server OS Contains 2008 OR Server OS Contains 2012 OR Server OS Contains 2016 OR Server OS Contains 2019
rscore - Rehost
Server OS Contains Red Hat Enterprise Linux 6 OR 7
|5||rscore - Replatform||Server OS Contains Red Hat Enterprise Linux 4 OR 5|
rscore - Replatform
Application Runpath Contains mysql OR Application Runpath Contains postgre
rscore - Refactor
Application Runpath Contains oracle
rscore - Refactor
Application Runpath Contains isodx
Tier - Web
Application Runpath Contains httpd OR Application Runpath Contains apache OR Application Context Contains IIS OR Application Runpath Contains nginx
Tier - Middleware
Application Runpath Contains jboss OR Application Runpath Contains tomcat
Tier - Database
Application Runpath Contains mysql OR Application Runpath Contains ora_dba OR Application Runpath Contains postgre OR Application Name Contains SQL
DNS information is collected from licensed Windows DNS Servers and used to apply tags about A records, CNAME records and other data to device groups. Tags are applied every 24 hours to licensed, inaccessible, and unknown devices, where data is available.
The term Degree is used for DNS-based tags to represent the distance of a CNAME record from an A record. For example, a CNAME record of name.domain.com which directs to a second CNAME record other-name.domain.com before finally directing to an A record of 192.168.56.4 would have a Degree of "2". For definition of DNS-based tags, see below:
- DNS A Record: This tag will be applied to a device for any A record that refers to it; A Records have a degree of 0.
- DNS CNAME Record - Degree X: This tag will be applied to a device for any CNAME record that refers to it, where "X" is the degree value. CNAME Records have a degree greater than 0.
- DNS Entry Point- This tag will be applied to a device for any DNS records that exist at the largest degree available for that device.
- If a device has only A records (degree 0), all A records would exist in this tag key
- If a device has 5 records at degree 0, 2 at degree 1 and 1 at degree 2, it would have one Entry Point tag with the value of the degree 2 record
- DNS Unique- This uses the same logic as the Entry Point tag, but further filters out any tags that contain the host name of the device.
Device State Change Tags
The device state change tags indicate the time when, during a scan, the state of a device's accessibility changed. They tag keys are listed and defined below. The tag value is the time of the scan overall, this may vary somewhat from the exact time we attempted to access the device.
- discovered: This indicates when we first accessed this device.
- stopped responding: This indicates that this device was no longer found. Typically this is a timeout/no response.
- resumed responding: This device did not respond on the previous scan(s), but did on this scan.
- lost authorization: The device responded with an authentication error on this scan.
- regained authorization: The device responded with an authentication error on the previous scan(s), but we were able to successfully authenticate on this scan.
Please note: These tags are only added when there is a change. For instance, if we are unable to authenticate a device for several consecutive scans, a tag would only be applied on the first of those.
We will profile devices based on their performance. These profiles are applied as tags to the device daily as long as we are receiving performance uploads.
|Strained||At least 1 performance issue has been found as calculated across all collected data (i.e. all-time) for the device. This is calculated daily as long as we are receiving performance uploads. Performance issues and their definitions can be found on the Issue Summary Page or by exploring the devices with issues column on the All Applications page.|
|In Use||Not determined to fall into the other categories|
|Idle||Average CPU and Mem below 20% for the last 90 days of collected data|
|Zombie||Average CPU and Mem below 5% AND the device is not the DEST for any known/critical flows|
IaaS Cloud Pricing
- Inventory- compares the resources present and usable (provisioned) by the device against the various cloud instances, to provide a match on what is already present in the environment. However, many systems may not be utilizing the full potential of the hardware.
- Usage- determines the instance type that is the best fit for the actual workload (performance) of the system, based on the data collected during the performance collection period of the assessment.