Tag your *.ndi files with the first hotfix for RayVentory Portal 11.1

We have a small feature update to recently released version 11.1 of RayVentory Portal. Don’t be confused by the suffix “Hotfix 1” – this is just to be consistent with our update and patching policy – actually, this release brings one important feature and does not change anything else. With this release, it is possible to dynamically inject predefined and/or precomputed values into the *.ndi files, so that – after upload – these characteristics are accessible by parent instances.

Below is a short background story of the new feature.

Regardless of the source and timing of an inventory, the core unit is a single inventory file, which is always represented by a file with extension *.ndi. In decentralized infrastructure consisting of several level of distribution servers, administration servers and RayVentory Portal instances, the data transfer and updating of upper instances is realized by an upload of these little files.

For administrators and maintainer of upper levels, it may be quite a challenge to identify which “sub-instance” was responsible for a scanned object and thus where the object comes from. To fill this gap, we decided to implement a tagging mechanism to NDI files. In current implementation, it consists of 6 properties, out of which 3 are configurable by the user:

• Version of RayVentory Portal used to perform a scan (non-configurable)
• Host name of the computer which initiated the scan
  (non-configurable)
• Current date and time (non-configurable)
• Organization (configurable)
• Location (configurable)
• Point of contact (configurable)

You can configure the last three values in the RVP settings screen:

Once configured, the branding information is injected on-fly in one of the following situations:

• *.ndi file has been created as a result of a local inventory (from the wizard)
• *.ndi file has been created as a result of remote execution or zero-touch execution methods
• *.ndi file is about to be uploaded to the parent upload location

There are just two exclusions:

• If there is already a branding, it is preserved and new information does not override existing values
• Empty values (applies only to configurable values) are ignored.

For profis…

Ever wondered what happens to the information and how to get it in the parent instance? To prevent maximum compatibility with existing installations and to avoid refactoring the *.ndi format, we save the branding information in a specially spoofed hardware class with the following parameters:

• Class: MGS_Identity
• Evidence: MGMT API
• Property names:
  • RVP-Server
  • RVP-Version
  • RVP-Time
  • Organization
  • Location
  • Contact

Known issues

This release is not fixing any known issues from the RTM release. There are two new known issues in this hotfix regarding the newly added functionality:

• Changes to the tagging settings will require a restart of the upload service when the remote execution inventory scan method is being used (if the product has been installed with a Windows Service) or the whole application (if the product has been started without prior installation of a service).
• A local scan no longer creates an NDI file named after the machine it was run on, as it now creates one called rvphost along with a 10 character alpha-numeric prefix.

(c) Taken from rayInsider:- 

https://insider.raynet.de/tag-your-ndi-files-with-the-first-hotfix-for-rayventory-portal-11-1/