|
<< Click to Display Table of Contents >> Raynet One > 1.1 > User Guide > Technical overview > Inventory object import Supported inventory object classes |
Here you can find the complete list of supported inventory objects of Raynet One. Learn about each object type and which properties it supports. Use this chapter as a reference when developing custom inventory scripts.
Please note that the asterisk (*) is the wildcard character, allowing any character sequence at its place. It is used in connection with standard DMTF classes starting with the CIM_ string, usually being base classes of more specific ones.
Use the search functionality of your viewer to find a specific class name.
If the name comparison strategy is not otherwise specified, all names are case-sensitive.
Standard supported classes: CIM_ComputerSystem [1] [2] [3] [4], Win32_ComputerSystem
Standard supported classes: CIM_OperatingSystem [1] [2], Win32_OperatingSystem
Refer to the official documentation.
Standard supported classes: CIM_Keyboard [1] [2] [3], Win32_Keyboard
Standard supported classes: CIM_PointingDevice [1] [2] [3], Win32_PointingDevice
Standard supported classes: CIM_Processor [1] [2] [3] [4], Win32_Processor
Refer to the official documentation.
Standard supported classes: CIM_DiskDrive [1] [2], Win32_DiskDrive
Standard supported classes: CIM_LogicalDisk [1] [2], Win32_LogicalDisk
Standard supported classes: CIM_CDROMDrive [1] [2], Win32_CDROMDrive
Standard supported classes: CIM_NetworkAdapter [1] [2], Win32_NetworkAdapter
Refer to the official documentation.
Standard supported classes: CIM_PhysicalMemory [1] [2] [3] [4], Win32_PhysicalMemory
Refer to the official documentation.
Standard supported classes: CIM_VideoController [1] [2], Win32_VideoController
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
This class represents a generic operating system service. It is used to capture Unix-like OS services.
The name of this service as exposed by the service management solution. The name format can follow different kind of rules depending on the inventoried system and its configuration. Service names should be distinct as they are used as identification on the source system.
The description of this service as fetched from the machine itself. Many service management solutions do provide service parameters storing friendly fields such as the commonly known name or a helpful description. If any such details were detected during device service inventory, this field is populated with them.
Hint about the origin of the State field's value. If true, then the value origin is computed based on reasonable activity evidence. For example, the existence of a process id could be interpreted as a running service. This parameter is omitted for service scanning approaches with no direct service state detection.
The status of this service. Known values are: running, stopped, exited or failed
The process id of the service. This field is empty if multiple processes were detected related to this service.
Standard supported classes: CIM_Process [1] [2], Win32_Process
This class represents a software package on the inventoried system. Software packages indicate software fingerprints. During import, great care is taken to recognize the package evidence.
Identifying name of the software package.
If the package evidence is sourced in the Windows Registry, the value specifies the path into the Windows Registry to find the registry key. It is expected to be a sequence of Registry names separated by the \ character. The last Registry name is expected to be a GUID. Optionally, the GUID can be enclosed by the curly-brackets { and }. If the last Registry name is in valid notation, the GUID is the package product code.
Friendly name of the software package displayable to the end user.
Name of the software package as used in the package management solution.
Computation machine architecture name which supports the software package. It hints at the instruction set used mainly inside of package machine-coded executables.
The version of the software contained in the package.
The package code as used in the package management solution. It is usually shorter than the full-fledged package names and follows rules for optimized package referencing.
The GUID notation is supported. Optionally, the GUID can be enclosed by the curly-brackets { and }.
If the parameter value notation is not supported, the field is ignored.
The vendor of the software contained in the package.
The maintainer of the package. This field is ignored, if the package vendor is not specified.
The total size in bytes of the package software contents.
The total estimated size of the package software contents. Specified in KiB (= 1024 bytes).
The registry namespace if the package evidence is found in the Windows Registry. Otherwise, this field is ignored.
The key path of the package, if the package evidence is not found in the Windows Registry. Otherwise, this field is ignored.
Specifies the source of the package evidence. Packages with the value aspa and the Path value starting with /System are ignored.
The file system location of the package main file on the inventoried device.
The date of installation of the software package. The string value is expected in the form [year][month][day] (for example 20210627 denoting the 27th of June in the year 2021).
Represents a file-system file object on the inventoried device. It is used to collect file content inventory or verify the presence of key application files. It can be used to store opaque blobs of information about devices for later retrieval through API.
The name of the file.
The file's content. By default, it is encoded in base64 notation.
The file's size in bytes.
Contains the checksum computed from the file's captured content. The scope of data could be less than the whole file if the file data region was not read entirely during retrieval from mass storage (truncation).
The installation date of the file.
The manufacturer of the file.
The version of the file.
Windows specific. If the file is a PE executable, then the value is taken from the checksum entries inside of the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Windows specific. If the file is a PE executable, then the value is taken from the PE file headers.
Contains the various file system paths of the file.
The file system path to the file.
The file system date and time associated with this file system path.
Represents a Windows Registry key tree. The children of a Registry key are other Registry keys.
The Windows Registry path to the key.
The Docker version as found on the inventoried device. If no such object exists, all Docker information is ignored.
Properties of this object are expected to follow the layout of the information presented by the docker version command. See the official documentation for further details. The nodes are flattened by separating child node names with the dot (.) character. See the Containers user interface introduction chapter to get an idea of the property contents.
The Docker instance name.
The generic Docker informational properties. If no such object exists, all Docker information is ignored.
Properties of this object are expected to follow the layout of the information presented by the docker system info command. See the official documentation for further details. The nodes are flattened by separating child node names with the dot (.) character. See the Containers user interface introduction chapter to get an idea of the property contents.
A Docker container on the inventoried device.
The name of the Docker container.
The URL of the Docker container image the deployment is based on.
The description of used ports and their mapping relations between container-internal and external networks.
A Docker image as found on the inventoried device.
The resource location of the Docker image URL. It is the string part to the left of the colon character (:).
The tag portion of the Docker image URL. It is the string part to the right of the colon character (:).
Size specification of the referenced image. It is expected to be of the form [count] [unit name (optional)]. Supported unit names are KB, MB, GB and TB. The KB unit is interpreted as 1024 bytes.
The execution state of a Docker container.
The name of the Docker container this state belongs to.
The state value of the Docker container. Supported values are: created, restarting, running, removing, paused, exited or dead.
Refer to the official documentation.
If no such node exists, all node class names starting with Msvm_ are ignored.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.
Refer to the official documentation.