Data Acquisition

Various options are available for data acquisition. In addition to the classic agentless scanning, a .exe file can be run locally, or agents can also be used to acquire the data of the various device types. However, agentless scanning is particularly suitable for gaining an initial overview of the network.

When you start LOGINventory for the first time, a wizard appears to help you with the agentless initial entry once you click the Remote Scanner node. You can define in which IP address range devices should be searched, whether the Active Directory and Microsoft Exchange should be read, and whether vSphere devices should be recorded.

In addition, administrative Windows credentials, SNMP communities and an SSH login can be stored.

Afterwards, of course, further definitions and accounts can be stored.

Agentless Scanning

To scan agentless with LOGINventory, you have to select what should be inventoried (definitions) and how it can be accessed (accounts). These definitions can then be combined into jobs and executed automatically by task scheduling. The Job Monitor always shows the progress of the currently running scans and the results of past scans.

Accounts

Basically, accounts can be divided into the following types:

• Generic Credentials (with username, password and domain): Administrative accounts to query Windows, Active Directory, Exchange, vSphere, XenApp, XenServer, SQL Server & Office365
• SSH Credentials (for Linux and Mac) with login and password or login, key file and optional password phrase. The key file must be in OpenSSH format because SSH.NET is used. PPK keys from PuTTY can be converted to this format.
• SNMP Communities (read only): In order to inventory SNMP v1/v2c devices, such as network printers, switches, routers, etc.
• SNMP v3 Credentials (with correspondig parameters): In order to inventory SNMP v3 devices with Security Name (e.g. "v3user"), Security Level (e.g. "authNoPriv"), Auth Protocol (e.g. "MD5), Auth Key (e.g. "v3password"), Priv Protocol (e.g. "AES") and Priv Key (e.g. "privPassword")
• Azure Credentials: For storing access information for "Modern Authentication" at Microsoft Azure. The authentication is performed using a client secret or certificate.
• AWS Credentials: For storing access information for "Modern Authentication" at AWS. The authentication is performed an access key.

Scan Definitions

The definitions describe individual scan areas that can be combined into jobs. Each definition requires a type, a unique name, and optionally a description. The definitions can be divided into the following types:

• Asset Inventory: Inventories Windows, Hyper-V, SNMP (switches, network printers) and SSH devices (Linux, Solaris, MacOS, ...).
• Active Directory Accounts and Groups: Reads user, group and computer properties from Active Directory.
• Microsoft Exchange Inventory: Inventories a complete Exchange organization including mailbox information and mobile devices.
• VMware vSphere Inventory: Inventories VMware ESXi servers and their existing VMs.
• Azure AD and Microsoft 365 Subscriptions: Reads information from Azure Active Directory about users, groups and computers, as well as permissions in Azure AD. From Microsoft 365, LOGINventory reads which products are licensed and which users consume which licenses.
• Azure Virtual Machines:In Azure, LOGINventory reads out which virtual machines exist, as well as various configuration settings for these VMs.
• AWS Virtual Machines: In AWS, LOGINventory reads out which virtual machines exist, as well as various configuration settings for these VMs.
• SQL Server Inventory: Inventories Microsoft SQL Server instances, their databases and user rights
• XenApp inventory: Inventory of applications published on Citrix XenApp.
• XenServer inventory: Inventory Citrix XenServer and its existing virtual machines.
• Exclusion from Inventory: Excludes elements from Asset Inventory (used in jobs together with other definitions).
• Script-based Inventory: Enables script-based access to your own data sources, for example to generate assets from them, read license information or determine warranty data.

For all definition types, the general setting options are summarized under General, such as

• Number of parallel scans (select lower for slow network connection!)
• Maximum runtime for a single scan
• maximum response time for the PING to a device
• Additional command line parameters

The following always applies here: If the corresponding fields are empty, the default value is used.

• For each device, all selected accounts are used one after the other (from top to bottom) until a scan is successful.
• You can use the arrow buttons to change the order of the accounts within the types.

• The credential types are processed in the following fixed order:

  1. Generic Credentials
  2. SSH Credentials
  3. SNMP v3 credentials
  4. SNMP Community

• At the top of the list should be those accounts that are valid for most devices in this definition.

Asset Inventory

For the definition type Asset Inventory, the Source specifies the scan area. There are the following types of scan areas:

• IP v4 Address Range (e.g. 192.168.200.1 - 192.168.200.121)
• IP v4 Subnet (CIDR) (e.g. 192.168.200.64/16)
• File List (Text file with names or IP addresses of the assets: one entry per row - IP ranges or subnets can also be specified in each line, e.g. “192.168.200.5-192.168.200.15” or “192.168.200.0/24”)
• List of elements
• Active Directory: You can scan the devices that have entries in the AD.

If Active Directory is selected as the source, a distinction can be made between OUs and Sites and Subnets. By using the slider Explicit node selection you can switch whether all elements in the selected folder (and subfolders) should be scanned automatically or whether an explicit selection is necessary.

Under Advanced the data acquisition can be adjusted. For example, you can set whether Share-ACLs (shared folders), drivers, fonts, etc. should be captured. These settings can also influence the duration of the inventory.

Under Asset Properties you can specify special, freely definable properties for this definition (see Custom Properties). Use the Asset Properties to define values that should be assigned to all successfully inventoried assets of a definition! If, for example, your IP address ranges are already divided by location, you could assign the respective location as an asset property and then use this assignment in queries as well.

Under Find Files you can specify search paths to search for specific files on the Windows devices to be scanned. A path can be specified using wildcards (*) and it can be determined whether the search should be recursive (i.e. also in all subfolders). For example, all files in the temp folder can be found by searching for C:\Temp\*.*.

Active Directory Accounts and Groups

If the option Anonymize user name in the Settings is activated, the user data cannot be supplemented with Active Directory information, because an assignment is then not possible!

The source defines which entries are to be read from the AD. The fully qualified domain name can be specified here in the root directory. A subdirectory can be selected via the Active Directory Browser to restrict the search.

Via Advanced selected AD attributes can be read and entered in LOGINventory attributes. The name of the value from the AD must be entered and assigned to a custom value in LOGINventory.

You can also set here that group memberships of security groups are resolved recursively, i.e. if a group is contained in another group ("Nested Groups"). You can find more parameters (including for resolving group memberships outside the specified OU) at the explanation of LOGINfoAD.exe.

Microsoft Exchange Inventory

With Microsoft Exchange Inventory, information about the entire Exchange organization (2010 and later) including servers, DAGs, databases, mailboxes, and mobile devices can be remotely scanned from a Microsoft Exchange Server. If different Exchange Server versions are in use, the one with the latest version should be used. The specified user account must have sufficient rights in the Exchange organization, e.g. member of the group "Exchange View-Only Administrators", or "View-Only Organization Management" (on-premises Server).

To prevent all Exchange servers from being captured, but only selected ones, a server filter can be set under Advanced. For example, by entering Serv* in the Server filter, only Exchange servers whose name begins with "Serv" will be included.

VMware vSphere Inventory

With VMware vSphere Inventory, ESXi and vCenter Server can be captured directly without the need for additional configuration steps.

As source select the type "list of elements" and add your ESXi Server, your vCenter Server or cluster as element (Full Qualified Domain Name (e.g. vcenter.m.loginventory.de) or the IP address).

The user account must have the required administrative rights (at least read-only admin) on the VMware servers.

Azure AD and Microsoft 365 Subscriptions

On the one hand, this definition type is used to read out information from Microsoft Azure on user account, computer account & group memberships (analogous to reading out on-premises Active Directory), as well as permissions in Azure AD. On the other hand, it is possible to read out online which subscriptions (e.g. Office365, Microsoft Intune, Power BI Pro, etc.) were acquired and which licenses were assigned to which users.

When assigning user accounts to the definition, only the Azure Credentials type can be used. A readout is not possible using Generic Credentials (username + password)!

We recommend using a client secret instead of a certificate for authentication, since the setup effort is significantly lower.

If the acquisition was successful, this can be seen in the job-monitor and the data from Azure AD is displayed in the corresponding Active-Directory queries in LOGINventory.

The Microsoft 365 Subscriptions data is then available below the "Software" node in the corresponding queries. Likewise, these cloud subscriptions can be added to the License Management.

Azure Virtual Machines

This definition type is used to read which virtual machines (VMs) have been created in Microsoft Azure, what their status is, and to determine various information about the operating system, IP address, size, location, etc..

Here, the Azure environment is considered a "hypervisor", so that an assignment of the VMs to this host (= the Azure environment) exists in LOGINventory.

As with the other hypervisor acquisitions, only running VMs are created as assets, see Hypervisor acquisition specifics.

AWS Virtual Machines

This definition type is used to read which virtual machines (VMs) have been created in AWS (Amazon Web Services), what their status is, and to determine various information about the operating system, IP address, size, location, etc..

Here, the AWS environment is considered a "hypervisor", so that an assignment of the VMs to this host (= the AWS environment) exists in LOGINventory.

As with the other hypervisor acquisitions, only running VMs are created as assets, see Hypervisor acquisition specifics.

SQL Server Inventory

SQL Server Inventory can be used to record individual servers by name or IP, or to define IP ranges to search for SQL Server installations. If possible, the user account used should have administrator rights on the database server; however, it can also be scanned with the user "sa" and the corresponding password (Generic Credentials).

XenApp Inventory

The applications published on Citrix XenApp servers and their access rights settings are recorded via the XenApp Inventory. No further prerequisites need to be fulfilled on the LOGINventory computer. When creating the corresponding definition, only one server from each XenApp server farm has to be inventoried. The name of this server must be entered in the appropriate field. When the drop-down list is opened, the members of the XenApp Servers group are displayed for selection.

XenServer Inventory

With XenServer Inventory, the individual XenServers to be captured can be added to Source via the Full Qualified Domain Name or via the IP address. The user account used must have administrator rights on the XenServer.

By default, port 443 (https) is used to connect to the XenServer. If this is to be changed, the command line argument /port <NUMBER> can be used:

Exclusion from Inventory

It is possible to exclude certain devices from a scan scope by running an Exclude from Inventory definition along with another definition (attention: this only applies to Asset Inventory definitions). To do this, they must be started together using multi-selection or combined in a job.

If the exclusion is to be based on names, it is often advisable to work with wildcards or to explicitly specify an FQDN. The name comparison is performed with the name that is displayed in the Job Monitor. This is determined using nslookup and can therefore differ from the actual host name if the DNS entries are incorrect/outdated.

Script-based Inventory

Script-based Inventory enables you to run a Powershell script with transfer parameters to be called up via the Remote Scanner. This script can be used to read data from a data source and write it to an inv file.

As you can create/edit the scripts yourself, you can specify which information is to be read from which data source.

We already provide some examples of scripts with various functions via the following Github repository:

https://github.com/loginventory/custom-scan-scripts

Please follow the instructions on Github and place the scripts you wish to use in the locations provided. You can then select the desired script from the drop-down menu.

No user accounts can be assigned to a definition of the Script-based Inventory type. Instead, parameters must be stored in the tab that are then to be used in the script. For example, access data, customer IDs, filter conditions or similar are transferred to the script via parameters, depending on what the script needs.

Jobs

Jobs allow you to create combinations of scan definitions to optimally scan your network or sub-areas.

• If several scan definitions are to be scanned simultaneously, this task can be combined in one job. Thus the individual definitions do not always have to be selected.
• If you do not want certain assets in a scan area to be scanned, you can specify them by defining an exclusion inventory. If this definition is combined with inventory definitions, the excluded assets are not scanned.
• Scan definitions can be used in multiple jobs.
• Jobs can be disabled, whereupon the schedule is ignored and the jobs are no longer executed automatically.

Schedule

You can use a schedule to specify when jobs are run automatically to scan the network regularly.

Job Monitor

As soon as a job has been started (or a definition has been started), the progress of the inventory can be monitored via the Job Monitor. In the upper result list, all jobs that have run so far and those that are currently running are listed. If one of the listed definitions is selected, the status of the entry of this definition is listed in the lower result list. For the current inventory the course can also be observed here. For completed asset scans, the display shows, among other things:

• The status ("Finished", "Executing", "Queued" or "None")
• The result is "Ok," "Error," or "None."
• Information on start time and running time

In many network configurations, not all devices can be successfully captured with the first scans. If errors occur during acquisition, you should first check which type of device is behind the IP address that has not been successfully inventoried. For example, if it is an IP phone that does not have a remote interface, the device can be manually entered into the database. It may also be necessary to deposit additional accounts with the necessary rights, adapt the firewall configuration, or enable remote protocols on the devices.

Logon Script Acquisition

Windows computers can be inventoried by calling LOGINfo.exe. This call can be positioned in the logon script so that computers scan themselves automatically when the user logs on.

Prerequisites

In order to set up the recording by means of logon script, different steps are necessary. As described in Data processing, .inv files are created when computers are acquired. These files must be stored in the central data directory, which is monitored by the LOGINventory Data Service. This service then enters the data into the database.

The program LOGINfo.exe, which is located in the data directory, is called to scan a computer. A legacy version called LogInfoL.exe is also available for download from the LOGINventory Helpdesk, which is used to inventory old systems such as NT4, ME or Windows 2000. You can also open the data directory via the task bar by selecting the service LOGINventory Data Service and displaying New inventory files.

The Data Directory Location can be adjusted in the settings. Here you can also share the directory, which is necessary for the inventory via logon script. By default, the share name Li9Data is used. If you share the directory via this dialog, the following rights are set in the file system: Authenticated users: Full; Local service: Modify.

This allows all users and computers within the domain to access the directory and to execute LOGInfo.exe. An automation of this call is reasonable and can be configured via the logon script.

Configuration

The following call can be included in the logon script, for example, which does not display any output data:

 START /B \\server\LI9DATA\LOGINfo.exe

If the scan is only to be executed for locally logged in users, the following command can be used:

 If "%SESSIONNAME%"=="Console" START /B \\server\LI9DATA\LOGINfo.exe

Alternative: The following lines in the script cause LOGINfo.exe to run locally, after checking if there is a newer version of LOGINfo.exe on the server. The resulting .inv file is placed directly on the server. Furthermore, the capture is only started if the user is locally logged on to the console.

If "%SESSIONNAME%"=="Console" (
xcopy /d \\server\LI9DATA\LOGINFO.EXE %temp% 
start /b %temp%\LOGINfo.exe \\server\LI9DATA)

Instead of "server" the name of the corresponding server has to be entered here. In addition, further parameters can also be passed when calling LOGINfo.exe, these are described in detail below; however, this is not necessary.

How a call of this kind is integrated into the logon script is described in detail by Microsoft. There are two variants:

• Assign user login scripts: https://technet.microsoft.com/de-de/library/cc770908(v=ws.11).aspx
• Assign scripts to start the computer: https://technet.microsoft.com/de-de/library/cc770556(v=ws.11).aspx

Now the respective computer is automatically inventoried when a user is logging on. In the query "Last Inventory Overview" you can check which inventory method was used and when the inventory took place by checking the columns LastInventory.Agent and LastInventory.Timestamp.

Parameters

The behaviour of LOGINfo.exe can be adjusted by parameters. If a switch name is specified, this has priority over an entry in the LOGINfo.script file.

LOGINfo.exe [!IpAddress] [DataDir] [/parameter1] [/parameter2] ...

Windows Offline Agent for Capturing Computers Outside the LAN

The LOGINventory Offline Agent can be used on Windows computers with .NET Framework 3.5 or higher that are rarely or never in the LAN, but should still be inventoried. Since only devices that are available in the network can be inventoried using the acquisition methods presented so far, an additional acquisition variant is required, for example, to regularly inventory laptops belonging to field staff. LOGINventory provides the Offline Agent for this purpose. This ensures that relevant computers scan themselves automatically, buffer this data locally and, if a network connection is available, send the buffered data to the LOGINventory computer automatically.

Setup

The publishing of the Offline Agent can be started via the ribbon menu Extras.

First, a directory must be selected, in which the appropriate files are to be stored. The configuration data is provided together with the MSI setups in an administrative installation point (AIP) - i.e. a directory from which the administrative installation can be executed.

Then, for the firewall profiles Public, Private and Work a URL and credentials can be stored, with which the data can be transferred.

The following should be noted:

• The devices on which the Offline Agent has been installed will scan themselves and then (depending on the active Windows firewall profile) attempt to reach the URLs specified in this step and place their .inv files there.
• To transfer the data, a user must be defined who can access the OfflineAgent.aspx page or the Li9Data share. To access the OfflineAgent.aspx, it is also sufficient to authorize a local user, no domain user is required. You only need to ensure that the user has read access to the file C:\inetpub\wwwroot\LOGINventory9\OfflineAgent.aspx in the file system on the web server.
  If necessary, a corresponding user should first be set up and then their data should be stored here in the dialog.
• The URLs configured at must be reachable from the client (e.g. Internet); this can be realized e.g. using a port forwarder, reverse proxy or DMZ server.
• If a port forwarder to the LOGINventory computer is configured, then the LOGINventory Web Viewer and a certificate for https must be installed here.
• The data can also be received outside the LOGINventory Web Viewer from another server using ASPX or PHP. The button Export upload script templates can be used for this purpose. These script files can be customized if necessary. More information on this in the box "Using another web server" below.
• The offline agent has the option of updating itself, so a URL must also be specified under which the offline agent checks whether a new update is available and can download it if necessary.

If the web server to be accessed by the Offline Agents is also the local LOGINventory computer including published web viewer, no further configuration steps are necessary. Here, a special version of the file OfflineAgent.aspx for receiving the data is already available, which automatically stores the data in the currently configured data directory of the server. That is why this URL is also suggested as the default address.

The .inv files received from the Offline Agent are now stored in the data directory (by default %Public%\Documents\LOGIN\LOGINventory 9\Data).

By editing the OfflineAgent.aspx or OfflineAgent.php file, you can change the local location to suit your needs. However, for security reasons, this should not be the directory where OfflineAgent.aspx is located.

Finally, if another web server is used, the .inv files must be copied to the data directory on the LOGINventory machine be processed by the Data Service, e.g. by using Robocopy.exe.

Several files are created in the folder selected at the beginning of the wizard, all of which are required for installation, including the appropriate MSI packages for 32-bit and 64-bit systems:

It is recommended to run the appropriate setup directly from the AIP to install the OFffline Agent on the clients.

Mode of Operation

If the Offline Agent is installed on a computer, two scheduled tasks for inventory are executed every day by means of a local copy of LOGINfo.exe (see logon script method), namely:

• at 10:00 am in the user context of a logged-in user (caution: The task in the user context is created only when a corresponding user logs on to the device again after setup).
• at 8:00 pm in the system context, i.e. even if no user is logged in.

If the computer is switched off at these times, the scans are repeated within a maximum of 24 hours if the computer is switched back on.

If the service "LOGINventory Offline Agent" finds new inventory files (*.inv) in the directory "C:\Users\Public\Documents\LOGIN\LOGINventory 9\LocalData" (local data directory), and a network connection exists, then it tries to transfer these files to the URL defined in the configuration - matching the current firewall profile - and then to perform a SelfUpdate (if available).

A daily log of communication with the central LOGINventory server is located on the client with the Offline Agent installed in the directory %ProgramData%\LOGIN\LOGINventory\9.0\Logs.

Updating the Offline Agent

There can be different reasons for providing an update of the Offline Agent:

1. By updating LOGINventory, a change is made to the logic of the Offline Agent (e.g. to improve reliability). This is then explicitly pointed out in the LOGINventory changelog. These updates usually occur very rarely.
2. An update of LOGINventory changes the LOGINfo.exe (e.g. new values are read out now). In this case, a new version of LOGINfo.exe should be provided to the clients so that they can benefit from the new features and provide data that is compatible with the currently installed database version.
3. An adjustment of the LOGINfo.script file is made by the administrator, e.g. because a rule for setting custom properties depending on the IP address has been added. For this to apply to the clients, the updated version of the LOGINfo.script file must be made available to the clients.
4. In the future, a different target URL is to be used when transferring the data or during the self-update, e.g. because the LOGINventory installation is moved to another machine.

There are two different types of updates you can provide. This is done in each case by running the Offline Agent Deployment Wizard again and selecting one of the two SelfUpdate options on the last page:

The button Create OfflineAgent_msi.zip for Selfupdate creates a zip file for the first of the cases described, which the Offline Agent installation downloads and thus updates itself. By the way, not only the update of the "logic" is included, but also the current LOGINfo.exe and LOGINfo.script are provided. Thus a "complete update" is provided. If you use a different web server, you must also copy this file manually to this server. An update on the basis of these files at the Offline Agent then takes place automatically at the next connection, but at most once a day.

However, if "only" the LOGINfo.exe or the LOGINfo.script have been changed (case 2 or 3), no "complete update" has to be provided, but it is sufficient to click the button Create loginfo_script.zip for self-update. Thereupon a file "loginfo_script.zip" is created, which contains the current version of LOGINfo.exe and LOGINfo.script. Also this zip file will be downloaded at the end of the next transfer from the client with the Offline Agent installation and thus a self update of only these two files will be executed.

For the fourth reason - i.e. a change of the upload / self-update URLs - the steps to be taken are as follows: In the wizard for republishing the Offline Agent, the new URLs are entered first. Then the action Create OfflineAgent_msi.zip for Selfupdate (i.e. the complete update) must be executed.

Linux Offline Agent

With the Linux Offline Agent, Linux machines can inventory themselves and transfer the data independently to the LOGINventory server. Different package types for the respective Linux derivatives are delivered in the program directory in the subfolder LoginfoXScripts (by default C:\Program Files\LOGIN\LOGINventory9\LoginfoXScripts).

Installing the Agent

For example, the .deb package for Ubuntu and the .rpm package for CentOS can be used. To install the agent, proceed as follows:

1. Transfer the desired package to the Linux machine (e.g. via WinSCP)
2. Install
   
   • the .deb package using sudo apt install /path/to/package/name.deb
   • the .rpm package using rpm -i /path/to/package/name.rpm Known issue: The rpm command could complain about missing perl dependencies. In this case, please add --nodeps to the command line.
3. The installation created
   • an inventory script loginfo.sh (/opt/loginfox/loginfox.sh)
   • a daily cronjob which starts the collection at 10:00 a.m. and transfers the .inv file (/etc/cron.d/loginfox)
4. To activate the automatic transfer of the files, the contents of two files have to be modified:
   • The upload URL under which the .inv file created during the acquisition is to be stored (e.g. OfflineAgent.aspx): /etc/loginfox/loginfox_url.config
     e.g. http://my-inventory-server/LOGINventory9/OfflineAgent.aspx
   • The credentials to use for accessing the upload URL: /etc/loginfox/loginfox.config
     e.g. --user ACCOUNT@DOMAIN:PASSWORD

Further information on setting up the upload URL can also be found in the description of the Windows Offline Agent.

Manual data transfer

If your Linux system does not support .deb packages or .rpm packages, you can also copy a .tgz file to an appropriate device, unpack it and run it yourself. The resulting .inv file must then be copied back manually, or a transfer itself must be set up.

The file loginfo.tgz can be extracted from the subfolder LoginfoXScripts on the Linux machine using tar xfz loginfo.tgz. The acquisition is then started with ./loginfox.sh.

macOS Offline Agent

Setup

Publishing the Windows Offline Agent creates a directory where the required setup files are located. This also includes a subfolder "macOS" where the files for installation on macOS are located.

For installation on macOS the two files loginfox.config and loginfox-macos-installer(version).pkg are needed.

In the loginfox.config file it is defined where the macOS agent should send its inv files. The URL and password stored in the "Public" tab of the publishing process are used and encrypted in the file. If the URL or user / password should be changed, it is recommended to go through the publishing dialog again, whereupon the loginfox.config will be updated. The encrypted information is stored unencrypted on the macOS device in the directory "/Library/loginfox/(version)/" by the installation, so that it can be used for the transfer. However, the rights to view the file have been limited to what is necessary.

Alternatively, it is also possible to store in plain text in loginfox.config where the inv files should be sent to and with which user the transfer should take place by using the following syntax:

--user usr:pwd
--url https://{ADDRESS}{:PORT}/{UPLOAD-URL}

for example

--user OfflineAgent@domain.local:MyPassword123
--url https://inventoryserver/LOGINventory9/OfflineAgent.aspx

To install on the macOS device, the two files loginfox.config and loginfox-macos-installer(version).pkg must be copied to the target device in the directory "/Users/Shared".

To start the setup, you can either double-click the pkg file and run the installation wizard, or execute the following command in a terminal window:

sudo installer -pkg /path/to/package.pkg -target /

After installation, the setup files can be deleted.

Mode of Operation

The installed offline agent consists of several components:

• Inventory script: The file "/Library/loginfox/(version)/loginfox.sh" performs the inventory of the macOS device
• Automatism for regular execution: Daily at 10am the offline agent is started by a launchd process: "/Library/LaunchDaemons/com.loginventory.loginfox.plist"
• Transfer of the inv file: The resulting inv file is transferred to the preconfigured http(s) URL via curl command through the loginfox.sh file (see Setup).

Software Usage Evaluation with LOGINuse

By default, LOGINventory uses the Windows Explorer statistics ("Last recently used" or "Recently opened programs") to determine the time of the last use of an application. This statistic is available in the respective user context of all supported Windows operating systems from 2000 onwards, but only considers applications started via Start menu, Desktop or Explorer - i.e. not the taskbar!

In addition, LOGINventory also offers its own usage statistics agent: LOGINuse. All used applications (.exe, .jar, and .bat) (e.g. also via command line) are registered by all users of a computer. This also works on terminal servers. LOGINuse collects its information in its own local database. If a program has been started for the third time and has run for at least 10 seconds, this program is noted as "used". This data is collected during the normal inventory of the system and transferred to the LOGINventory database. If LOGINuse data is available, any existing data in the Windows statistics for this system will be ignored!

Installation

LOGINuse is supplied in an MSI file which should be copied to a central installation point (AIP). From there, the distribution to the client systems takes place e.g. via group policies or another of the existing mechanisms.

Since LOGINuse is a 32-bit application, the program is installed on the 64-bit systems under the path %ProgramFiles(x86)%\LOGIN. In addition, an automatically starting LOGINuse Service is configured (login with the local system account). As with all MSI setups, the original MSI file should be kept after the installation to be able to uninstall LOGINuse if necessary.

Rules for Acquisition

The following rules apply to the entry of LOGINuse:

• Only interactive processes that run in the user context are recorded.
• Only processes that were started outside %SYSTEMROOT% (incl. subdirectories) are recorded.
• Only processes that have more than 10 seconds between start and stop are recorded.
• Only processes that meet the above conditions at least three times are recorded.
• The results are visible at the earliest 8 hours later in the LOGINventory database!

The purpose of these rules is to ensure that only the real use of software packages is taken into account, that is:

• only packages that are not included in Windows are counted
• an accidental start (with immediate stop) is not detected
• the function test is not recorded after installation
• no direct monitoring of the users can take place

Examples:

Suppress Readout

The readout of the LOGINuse database during scanning can be prevented via the switch //NoLoginUse 1. The switch can be set either as command line parameter in the scan definition or for the program LOGINfo.exe, or via the file LOGINfo.script.

Configuration of the Data Directory

Unless configured otherwise, LOGINuse writes its data to the directory%ProgramData%\LOGIN\LOGINventory\9.0\LOGINuse. This can be reconfigured per computer by creating and setting the following registry value: HKLM\Software\LOGIN\LOGINuse, DataLocation. This can be done, for example, via the following command line (as administrator):

C:\ reg add HKLM\Software\LOGIN\LOGINuse, /v DataLocation /t REG_SZ /d "d:\LoginUseData" /f

The local database is deleted during an uninstallation. If this is not desired (e.g. because a new installation is planned afterwards), a backup of the local data directory should be made beforehand.

Manual Insertion of Data

In addition to the various automated procedures, it is also possible to manually insert data into LOGINventory.

Local Acquisition via USB Stick

If you cannot capture Windows devices remotely or via logon script, because they do not have a network card or their APIs do not support the procedure, you can also copy the LOGINfo.exe to a USB stick and execute it on the computer to be captured. The best way to do this is as follows:

1. Copy the data directory including LOGINfo.exe (usually found under C:\Users\Public\Documents\LOGIN\LOGINventory 9\Data) to a USB stick.
2. Remove the USB stick from the LOGINventory computer, go to the isolated PC and insert the USB stick.
3. Start Windows Explorer, navigate to the USB stick, start LOGINfo.exe and wait until a .inv file has been created on your USB stick.
4. Remove the USB stick from the isolated PC and return to the LOGINventory computer.
5. Copy the new .inv file into the data directory of the LOGINventory computer.
6. Make sure that the LOGINventory Data Service service is running and that the data is entered into the database (the .inv file disappears after a short time).

Creating Assets Manually

Assets can be created using two different user interfaces: To quickly and easily create one or more assets with basic properties, we recommend using the Asset Editor.
If 1:n relationships, such as the existing software packages, are to be stored with the manually created asset, this is only possible using LOGINject (legacy component).

Asset Editor

A New Asset can be created via the ribbon menu if you are below the Asset Management node.

When creating manual assets, you can choose between three predefined types: Computer, Mobile & Peripheral Device.

Depending on the selected type, other fields - relevant for the respective type - are available for filling. For catalog entries, such as Asset Model or Operating System Information, you can choose from the entries that have already been in the database or create new entries.

By clicking OK, the Asset is created. If you want to create another similar device, you can click on the Save & Next icon in the upper right corner. This will save all previously filled entries except the name.

If a manually created asset is to be edited, this is possible by selecting the device in the Data View and then selecting Edit Asset from the ribbon menu.

Creating Peripheral Devices

When creating peripheral devices, there are some special features to consider. However, all the comments mentioned for the Asset Editor still apply.

To create peripheral devices, either the Asset Editor can be opened via New Asset as described above, or, the information on connected / installed devices is taken over for certain data types:

• Monitors
• Docking Stations
• Drives / Hard Disk / USB Sticks
• via USB or Bluetooth connected devices

All created peripheral devices are then visible in the query Peripheral Devices.

Legacy: LOGINject

The LOGINject wizard for manually creating assets can be started via the ribbon menu if you navigated to Asset Management (or below) in the tree.

For 1:1 relationships, the corresponding fields can be filled directly.

For catalog entries (e.g. software packages), existing entries on the right side can be selected by drag & drop. If an entry not yet existing in the database is to be written, it must also first be written to a free line on the right-hand side and can then be assigned to the device.

The Save file → Asset function transfers the data directly to the LOGINventory database. The wizard can be called via the ribbon menu under "Tools",

Importing Assets, Licenses and Custom Properties from csv Files

To define a mapping, the Data-Import can be called from the ribbon menu Extras. A csv file, which can be located in any location, can then be selected to create an import definition. For each import, a unique Name has to be used. Then select a Table from the LOGINventory data model in which the key for the data is located.

Depending on the selected Table, different target columns are then available for the assignment.

When importing assets, a setting can be made in the Editable and Subtype columns: If the new devices to be imported should afterwards be editable via the Asset Editor, the Editable checkbox must be selected. Only if the Device table is selected a subtype can be specified that determines which Asset Editor is to be used to later edit the device: If it is a normal device, no Subtype must be selected; if it is a smartphone or tablet, the Subtype "Mobile" must be selected.

If the assignment was successful, the file can be read in by clicking on Apply.

Modification of the Data Acquisition

The information determined by default can be enhanced with your own rules. The agentless scans and the logon script with LOGINfo.exe use the file LOGINfo.script; this file is located in the subdirectory Script of the data directory (by default :\Users\Public\Documents\LOGIN\LOGINventory 9\Data). This script file is evaluated each time an asset is inventoried. This means that all adjustments here influence the entire capture process.

In this script file you can

• insert !SET-command switches, which are evaluated before the inventory. This way you can
  • change the time-outs
  • read additional data
  • not read certain data ( e.g. Netinstall packages, software uninstall info, etc.)
    To do this, the data that is no longer to be collected must be listed separated by a comma, e.g. !SET Ignore=BootLog,Event
• modify the data after inventory using additional commands:
• Values can be narrowed down using conditions and comparisons.
• Custom (freely definable) properties can be assigned asset-related, e.g. "location" information, environment variables, values from WMI or the registry, certain file properties.
• simple properties of the LOGINventory database can be changed directly, e.g. the value for the name of the read CPU can be changed or overwritten.

• Using the command Cpu.Name=%$Cpu.Name% X1234 the entry AMD Athlon™ 64 X2 Dual Core Processor changes to AMD Athlon™ 64 X2 Dual Core Processor X1234

  • Entries of list entries can be added, modified or removed.
  • The command !Modify NetworkAdapter Name=Broadcom NetXtreme-Gigabit-Ethernet, Name=Gigabit, DefaultGateway=10.11.12.14 changes e.g. in the network adapter entry named "Broadcom NetXtreme-Gigabit-Ethernet" the name and the entry for the default gateway

The names of the properties correspond to the column headings in LOGINventory.

Available Commands

Switches

Switches can be inserted into the LOGINfo.script file to further adjust the data entry process. The following syntax can be used: !SET command=value. Many of the offered settings are also directly adjustable in the respective scan definitions.

Creating your Own Properties

You can create your own properties and assign values to them. To change the values of these properties, either an entry in the LOGINfo.script file is used - or you can do this interactively in LOGINventory.

The properties created via the script file always have the type String - in contrast to Custom Properties created in LOGINventory, which can have the type String, Int64 or DateTime. For more information on this topic, see the [Own properties] section (evaluation.md#custom-properties).

Do not use spaces or special characters (e.g. $#_&-) in the property name!

Modification of List Entries

Existing list entries (e.g. software packages) can be changed. This is useful, for example, if you want to add a serial number or change the software name of a specific software. The use of wildcards ? and * is supported. All entries that match the expression are changed.

Using the syntax !MODIFY table condition property1=value1[,property2=value2 ...] the entries are changed, e.g.

• Addition of product ID and product key to software package: !MODIFY SoftwarePackage Name=Nero*, PRODUCTID=reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Ahead\Nero - Burning Rom\Info",user}, PRODUCTKEY={reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Ahead\Nero - Burning Rom\Info",Serial5}
• Replace SW package name with constant name: !Modify SoftwarePackage Name=*WinZIP*,Name=File Compressor.
• Replace the SW package name with its name and version number : !MODIFY SoftwarePackage NAME=Acrobat,NAME=$NAME$ $VERSION$.
• Addition of product keys from the registry: !MODIFY SOFTWARE PACKAGE NAME=VMware Workstation, PRODUCTKEY={reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Vmware, Inc.\Vmware Workstation\License.ws.*",Serial}.

The syntax !BLOCK table condition can also be used to prevent the entry of certain values, e.g. !Block SoftwarePackage Name=LOGINventory or !Block Hotfix Product=.Net*.

Examples

Setting a custom property "Location" depending on the IP range of the acquisition

!IF {like:%$Lastinventory.Ip%,192.168.10.*}
Custom.Location=Munich
!ENDIF

!IF {like:%$Lastinventory.Ip%,192.168.20.*}
Custom. Location=Berlin
!ENDIF

Adding a software package entry, although there are no entries in the registry, nor in the "Add / Remove Software List " (happens e.g. with package managers installed via the command line):

!IF {fileexist:"%programdata%\chocolatey\choco.exe"}
!ADD SoftwarePackage Name=Chocolatey,Version={fileversion:"%programdata%\chocolatey\choco.exe"}
!ENDIF

Modifying the ChassisType for certain devices (depending on the read operating system name)

!IF {like:%$Operatingsystem.Name%,*SonicWALL*}
DeviceInfo.ChassisType=Sonic
!ENDIF

Preventing the capture of software packages installed from a specific path (e.g., through software distribution)

!Block SoftwarePackage InstallSource=*dfs\apps\*

Modification under Linux

The file LOGINfo.script is ignored if it is a acquisition of a Linux-based device. However, for this purpose a file can be stored on the device to be scanned with which it is possible to modify various entries or write new entries themselves.

For this a file "custom.xml" must be stored in the path /opt/loginfox/custom.xml, which has the following structure:

<?xml version="1.0" encoding="utf-8"?>
<Device>
<Name>custom name</Name>
<Custom>
<myvalue>myvalue content</myvalue >
</Custom>
<DeviceInfo>
<Description>device description</Description>
</DeviceInfo>
<OperatingSystem>
<Name>os name</Name>
<Version>os version</Version>
<Domain>os domain</Domain>
</OperatingSystem>
<SoftwarePackage>
    <NAME>F-Secure Policy Manager</NAME>
    <VERSION>14.20</VERSION>
    <INSTALLDATE.VALUE>2018-12-04T00:00:00Z</INSTALLDATE.VALUE>
    <PUBLISHER>F-Secure Corporation</PUBLISHER>
</SoftwarePackage>
<SoftwarePackage>
    <NAME>FileZilla Server</NAME>
    <VERSION>beta 0.9.60</VERSION>
    <INSTALLDATE.VALUE>2018-12-04T00:00:00Z</INSTALLDATE.VALUE>
    <PUBLISHER>FileZilla Project</PUBLISHER>
</SoftwarePackage>
</Device>

The 1:1 relationships set here (e.g. Device.Name, OperatingSystem.Name, ...) overwrite the values actually read out. The entries for the software packages are added to the entries that have already been read out.