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.

Info

The entered passwords are always stored encrypted with the Microsoft Crypt API and cannot be read without authorization.

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

Info

The technical details contain a detailed description of the prerequisites for entry.

Tip

See the respective chapter to learn more about the differences between the acquisition methods with repect to the data collected.

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.

Info

The accounts can also be assigned to the definitions via drag & drop, just as the definitions can be assigned to the jobs via drag & drop.

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")

Tip

An unlimited number of accounts can be created, which can be assigned to individual definitions. Thus, different passwords or accounts can be tested one after the other within a definition until a device has been successfully scanned. You can also set the order of accounts using the arrow icons on the right.

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, ...).
• Exclusion from Inventory: Excludes elements from inventory (used in jobs together with other definitions).
• Active Directory Attribute Lookup: Reads user, group and computer properties from Active Directory.
• MS Exchange Inventory: Inventories a complete Exchange organization including mailbox information and mobile devices.
• VMware vSphere Inventory: Inventories VMware ESXi servers and their existing VMs.
• XenApp inventory: Inventory of applications published on Citrix XenApp.
• XenServer inventory: Inventory Citrix XenServer and its existing virtual machines.
• SQL Server Inventory: Inventories Microsoft SQL Server instances, their databases and user rights
• Microsoft 365 Subscriptions: Finds out online which products are licensed from Microsoft 365 and which users consume which licenses.

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.

Attention

The tab Accounts must always be used to select which accounts from the pool of all accounts are to be 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.

Info

If a definition has been created and at least one user account has been selected, the inventory can be started manually. The progress is displayed in the Job Monitor. The evaluation then takes place in the "Asset Management" node.

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)
• List of elements
• Active Directory: You can scan the devices that have entries in the AD.

Info

The ping interval is adjusted dynamically and should only be changed manually in exceptional cases, e.g. if you scan one or more very large areas and are not satisfied with the duration of the ping phase. Too much reduction of the interval can lead to irregularities in the detection of devices.

Attention

If the Active Directory is specified as the source during the asset inventory, the AD itself is not recorded, but rather the computers present there and currently switched on. This means that switches or computers that are not in the AD are not detected.

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\*.*.

Attention

Use recursive search with wildcards with caution. So a recursive search of the path C:\*.* should not be triggered, because otherwise the entire hard disk including all files is listed, which can lead to extremely long execution times and very large amounts of data. Instead use the search with as narrow restrictions as possible, for example to search a certain .exe in a certain directory (search path: C:\Program Files\Company\my.exe)!

Exclusion from Inventory

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

Info

If "List of elements" is selected as the source, wildcards can also be used to exclude devices. For example, "win*" or "192.168.20*.15" are valid values. The Job Monitor then shows the filter condition on the basis of which the devices are not recorded.

Tip

If you want to exclude mobile devices, such as smartphones, from the inventory, this is only possible directly in the definition of the Microsoft Exchange Inventory under Advanced.

Active Directory accounts and groups

Attention

This inventory type is used to read additional properties for users or computers from Active Directory. The Active Directory definition does not inventory Assets or Users, but complements existing Asset or User data.

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.

Info

The command line argument /ignoregroups group1;group2 can be used to exclude user groups from the AD. This can be desirable, for example, if you only want to enter part of your entire organization.

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"). This behavior can also be enabled using the /recursivegroups command line argument.

Technical background for reading the AD

LOGINventory records members (users) of an OU and, depending on the setting, resolves their group memberships in direct and indirect (recursive) groups. If during scanning the path is set to an OU which contains only the group but not the user, the user is not a member of the OU unless he has been explicitly added there and is not recorded from here.
Only for security groups the memberships can be resolved recursively if the corresponding check mark is set. For distribution groups only the direct memberships are read out.

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".

Important

You can also specify a Cloud Server as the source, simply enter the address in the line of the server name, e.g. 'outlook.office365.com'. Attention: In this case, the user account must be specified as UPN (e.g. name@domain.com), using domain\name will not work!

Info

By default, all mobile devices connected via Exchange Active Sync (EAS) are also recorded and created as assets in LOGINventory via the Exchange Inventory. This behavior can be suppressed by checking No mobile devices (EAS) in Advanced.

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).

Tip

It is not necessary to enter all ESXi hosts individually here, if a vCenter is used. In this case it is sufficient to enter only the name or IP address of the vCenter, all ESXi hosts will then be scanned automatically.

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

Attention

VMware Inventory creates hosts and VMs as assets. However, during acquisition, only the data that the host has about its VMs is collected. This means that virtual machines scanned solely through VMware Inventory have incomplete information (e.g., no information about installed software, hardware, etc.). Therefore, all virtual machines should always be additionally scanned using Asset Inventory definitions (e.g. by scanning the relevant IP range containing the VMs). Incompletely scanned devices can be recognized by the entry Stub in LastInventory.Method.
The same applies, of course, to XenServer inventory and the scanning of Hyper-V hosts via Asset Inventory: The VMs should still be additionally scanned explicitly.

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.

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).

Attention

For the acquisition of databases outside the own subnet using SQL server authentication (e.g. user "sa"), it may be necessary to assign Windows credentials as well as the SQL server user as accounts in the definition. (The instances are found via the Windows user, the SQL server user can enter them.)

Info: Access Rights

In order to be able to read out with a SQL server user the data to all databases existing on the server, the role sysadmin on server level is required.
To be able to read out from individual databases the information to name, record, server version & size, the role public on database level is sufficient. If also the assigned roles on database level are to be read out, the role db_accessadmin on database level is necessary.

Microsoft 365 Subscriptions

With Microsoft 365 Subscriptions you can read online which subscriptions (e.g. Office365, Microsoft Intune, Power BI Pro, etc.) have been contracted and to which users which licenses have been assigned. This data can be evaluated in license management.

The following prerequisites must be fulfilled in order to make it possible to read Microsoft 365 data:

1. An Internet connection must exist.
2. The required Powershell module must be available.
   This module is installed by entering the command Install-Module -Name AzureAD in an administrative Powershell on the scan server (the computer on which LOGINventory is installed from which the data query is to be made).
   If necessary, the NuGet provider must first be installed via Powershell so that the module AzureAD can be installed. This will be indicated by Powershell if the above command is executed.
3. A user account of the type Generic Credentials must be assigned as user account for the acquisition, whereby the user name is specified as UPN, e.g. john.doe@domain.com. This user must also be authorized to read the data from Microsoft 365, e.g. all users who have been assigned a Microsoft 365 license.

Like any other definition, the reading of Microsoft 365 data can be automated by jobs. The data is then available under the "Software" node in the corresponding queries. These cloud subscriptions can also be added to the license management.

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.

Important

Each job can also be executed several times a day with several schedules.

Help

We recommend scanning the network several times a day, preferably at times when your users are actually using the computers. The more frequently you scan, the more fine-grained the change history will be.

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.

Info

In the Job Monitor, you can call SSH Troubleshooting from the ribbon menu. With this tool different settings like port, username, password etc. can be tested. The textual output then shows which problems occur when establishing a connection or when querying the Linux 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.

Important

The great advantage of this method is that data can also be captured without administrative rights and with an existing firewall, since the scan is executed locally and in the user context.

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. The program LogInfoL.exe is also located there and can be used for inventorying 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 Li8Data 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\LI8DATA\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\LI8DATA\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\LI8DATA\LOGINFO.EXE %temp% 
start /b %temp%\LOGINfo.exe \\server\LI8DATA)

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.

Note

If the entry for Agent ends with "(LOCAL)", the inventory was executed in the user context or by the computer, i.e. by calling LOGINfo.exe in the data directory.

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] ...

LOGINfo.exe	Command line parameters
/?	Outputs information on how to use the parameters
!IP address	Remote Scan Address; Default: own computer
Target directory	The result file is saved in 'Target directory'. Default: current directory. The LOGINfo.script is also searched for in the "Script" subfolder of this directory.
/NOWMI	Do not use WMI on Windows computers.
/DEBUG	Use only on instructions from LOGIN support team
//'Switch name' n	Changes the value of a switch with the value 'n' (see Switches)
/PINGLEN number	Number of bytes in ping (default: 32)
/PINGTIMEOUT wait time	Ping wait time in ms (default: 2000 ms)
/NOWIN	Do not use Windows APIs
/NOSNMP	Do not use SNMP
/NOSSH	Do not use SSH
/USESNMPFALLBACK	Use SNMP even if no response to ping occurs
/SNMPPORT port	Use SNMP UDP 'port' (default:161)
/SNMPCOMMUNITY community	Use SNMP v1 Read-Community (standard: 'public')
/USER Username Password	Windows Access Data
/NETSNMP	Use Net-SNMP instead of Microsoft SNMP
/NETSNMPCONF	Use default Net-SNMP configuration file
/SNMPUSER user	SNMP v3 User; security level=noAuth
/SNMPAUTH md5 | sha pass	SNMP v3 Password; security level=authNoPriv
/SNMPPRIVACY des | aes pass	SNMP v3 Passphrase security level=authPriv
/FindFiles "path"	Triggers the File Search. e.g. "/FindFiles "C:\Temp*.*"
/FindFilesRec "path"	Triggers the recursive file search. Both search parameters can be used several times if you want to search at several locations.

Examples

Acquisition of the computer with the IP "192.168.200.50": LOGINfo.exe !192.168.200.50
Acquisition of the own computer and storage of the resulting inv file in "C:\Temp": LOGINfo.exe C:\Temp (Attention: Here, the LOGINfo.script file is searched for in the subfolder "Script" of the target directory, i.e. C:\Temp\Script\LOGINfo.script)

Important

Using switches (recognizable by //) many more adjustments can be made. These are all described in the Modification of the Data Acquisition part.

Windows Offline Agent for Capturing Computers Outside the LAN

The LOGINventory Offline Agent can be used on Windows computers 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.
• 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.
• Receiving data is also possible outside of the LOGINventory Web Viewer using ASPX or PHP. For this purpose the button Export Upload Script Templates can be used. These script files can be customized 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.

Using a different web server

If another web server is to be used, the following requirements apply:

• IIS version 7.0 or later and ASP.NET 4.5 or later
• OfflineAgent.aspx (You can get this file by clicking on Create Upload Script Templates)
• OfflineAgent_msi.zip

or

• Apache version 2.4 or higher
• PHP version 5 or higher
• OfflineAgent.php (You can get this file by clicking Export Upload Script Templates)
• OfflineAgent_msi.zip

The following configuration steps are then required on the other web server:

1. Starting the IIS Manager
2. In the Default Web Site, add an "Application" corresponding to the path you had defined earlier, e.g. "LOGINventory-OfflineAgent" pointing to the physical directory where the OfflineAgent.aspx file will be stored.
3. Below that, an "Add Virtual Directory" named "selfupdate", which points to a physical directory where the OfflineAgent_msi.zip file is stored (see explanations for updating the Offline Agent).

The .inv files received from the Offline Agent are now stored in the data directory (by default %Public%\Documents\LOGIN\LOGINventory 8\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.

Tip

After updating the Offline Agent to a newer version, also keep the previous versions in this folder, since they might be needed for the deinstallation on the client.

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.

Important

If the computer is switched on, .inv files are created - triggered by the Windows task scheduling. These files must then be transferred by the clients to the LOGINventory server. The service "LOGINventory Offline Agent" (display name) or "LOGINfoSvc" (name) tries to transfer the data to the URLs stored in the profile settings.

If the service "LOGINventory Offline Agent" finds new inventory files (*.inv) in the directory "C:\Users\Public\Documents\LOGIN\LOGINventory 8\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).

Summary

If everything is set up correctly, the corresponding devices will inventory themselves twice a day and then send the data to the LOGINventory data directory. Have a look at the values of LastInventory.Agent to see with which acquisition method the device was inventoried (here: "Local"). Also, on the LOGINventory machine, you can see in the Event Viewer when .inv files have been processed.

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\8.0\Logs.

Info

If a transfer of the data should be executed directly after the installation for test purposes, the corresponding task can be executed in the Windows task scheduler with installed Offline Agent.

Updating the Offline Agent

There can be basically 3 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.

Info

None of these changes will automatically change the installed Offline Agents, but the changes must be made available to the Offline Agents for so-called "SelfUpdate".

For these three cases 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 three 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.

Info

You have deployed an update and want to know if it has been installed by the clients? You can find hints in the log file on the clients (%ProgramData%\LOGIN\LOGINventory\8.0\Logs).

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\LOGINventory8\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, two more files have to be modified:
   • The upload URL under which the .inv file created during the acquisition is to be stored (e.g.B. OfflineAgent.php): /etc/loginfox/loginfox_url.config
   • The credentials to use for accessing the upload URL: /etc/loginfox/loginfox.config

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.

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!

Info

LOGINventory offers with the help of the specially developed usage statistics agent LOGINuse the possibility to find out which software in your company is actually used by whom. In this way, expensive, unused software packages in particular can be identified and the number of licenses reduced. Thus LOGINventory supports you in minimizing unnecessary expenses for expensive software licenses.

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!

Attention

This means that without the distribution of the software usage agent, the data in license management must be evaluated with caution during usage evaluation! Only if the agent's been deployed, the data is reliable.

Info

The data is always evaluated in License Management.

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.

Info

To make software usage monitoring available for distribution, the appropriate option can be accessed via the ribbon menu under Extras.

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.

Info

As long as no changes are made to the LOGINuse program, the version number remains unchanged in the name, i.e. LOGINuse does not need to be rolled out again with every LOGINventory update as long as the LOGINuse version number does not change.

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:

Action	Result
Use Notepad, Explorer, or Regedit	is never captured
Start all Office applications once and close them again immediately	is not captured
Start Microsoft Excel three times, run at least 11 seconds each	The software usage data is visible in LOGINventory after 8 hours at the earliest

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.

Info

If you only want to prevent that the program usage information is collected from the Windows Explorer statistics, you can insert the switch !SET Ignore=ProgramUsage into the LOGINfo.script file. Then only the data of the usage agent is collected.

Configuration of the Data Directory

Unless configured otherwise, LOGINuse writes its data to the directory%ProgramData%\LOGIN\LOGINventory\8.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

Reset Database

To reset the LOGINuse database on the computers, the MSI file LOGINuseResetDb.msi can be "installed". This MSI file does not install anything, but only empties the respective local database.

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:

Copy the data directory including LOGINfo.exe (usually found under C:\Users\Public\Documents\LOGIN\LOGINventory 8\Data) to a USB stick. Remove the USB stick from the LOGINventory computer, go to the isolated PC and insert the USB stick. Start Windows Explorer, navigate to the USB stick, start Loginfo.exe and wait until a .inv file has been created on your USB stick. Remove the USB stick from the isolated PC and return to the LOGINventory computer. Copy the new .inv file into the data directory of the LOGINventory computer. 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

The LOGINject wizard for manually creating assets can be started via the ribbon menu. 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", if you navigated to Asset Management (or below) in the tree.

Tip

If devices that could not be successfully inventoried (e.g. IP phones, TVs, etc.) should also be created as assets, you can select the Create Asset action from the ribbon menu in the list of unsuccessfully created devices (Failed Inventory under the IT Inventory node). The data that could be collected during the erroneous acquisition (name, IP, MAC, manufacturer) will then be transferred directly and the " faulty " asset will become a " proper " asset.

Importing Assets, Licenses and Custom Properties from csv Files

Important

Data contained in csv files can be automatically read and imported by LOGINventory by copying them into the data directory. To do this, a mapping must first be defined between the imported data and the columns in LOGINventory so that the values are assigned correctly.
If the mapping has been created correctly, assets can be created, custom properties (e.g. "Owner") can be imported or licenses including their properties can be imported.

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. The next step is to select a table from the LOGINventory data model for each import in which the key for the data is located.

Example

The Device table must be selected to import data for assets or custom properties that refer to assets. If data for licenses are to be read in, the corresponding license type can be selected. An overview of the available license types and their properties can be found in License Management.

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

Info

The column names of the source file may not start with a number and may not contain spaces or special characters such as /, \, ? etc.
The import supports all common formats UTF7, UTF8, Unicode (UTF-16LE), BigEndianUnicode (UTF-16BE), UTF32 correctly. Default is the operating system Ansi code page, which e.g. writes Excel. In order to recognize the above mentioned formats, the so-called Byte-Order-Mark (BOM) MUST be set. In Notepad++ you can find both UTF8 and UTF8 BOM and only the latter works, because otherwise no information is written into the file header and therefore no encoding can be recognized.
So in a nutshell: Either with BOM or the standard code page is tried.

Note

In order for the assignment or updating of existing data to function correctly when reading in data, there must always be a so-called "key" on the basis of which an entry is uniquely identified. When importing assets, this key is the field Device.Name. If licenses are to be read in, the key is the field License.Number. If there is no such ID of a license in the source data, the fields Name, Version, Manufacturer, End and Begin are used as a temporary combination. This means that if there is no ID and one of these fields changes from a previous import, a duplicate license may be created.

Info

Only 1:1 relationships can be read in! It is therefore not possible to read in which programs all exist on one device (1:n relationship).

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

Important

With the help of the File filter the file name can be adjusted with wildcards. So if "MyFolder.csv" becomes "My.csv", in the future all files starting with "My" and ending with ".csv" will be automatically read in* as soon as they are copied into the data directory. Therefore, you can also create different import definitions in order to handle different data differently (differentiate by file name).

Info

If custom properties are to be imported to assets, it must be ensured that the custom property already exists, otherwise it cannot be selected during assignment. If in doubt, you can first create your custom property and then restart the import.

Info

If date values are to be read in, it must be ensured that these are stored in the English format (MM.DD.YYYY) in the source file. This means that January 15, 2019 is entered as "01.15.2019" or "01/15/2019" in the file.

Example: Importing and Assigning Licenses

As mentioned above, licenses are uniquely identified by the field License.Number. Since software versions in combination with the product name (SoftwareAsset.CustomId) can also be uniquely identified, licenses can also be assigned directly to the correct product and version when importing. To find out what the CustomId of a software version is, the query "All versions" below "Evaluations" can be looked at, for example. Typically, however, the CustomId is the product name in combination with the version name (separated by a space).
For example, the following source file can be read in:
Thereupon the following mapping can be used in the data import:

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. This script file is evaluated each time an asset is inventoried. This means that all adjustments here influence the entire capture process.

Attention

This does not apply to the acquisition of Linux-based systems. For these, another form of modification is possible, as described below.

Important

If LOGINfo.exe is called via the command line, a target directory can be specified (see parameter). The LOGINfo.script will always be searched in the "Script" subfolder of the target directory. If no target directory is specified, the location of the LOGINfo.exe is used as target directory. The .inv file is created in the target directory.

Example

This means that you can also read your own OIDs from SNMP devices, so that the information that really interests you is displayed for each device. Many manufacturers publish their MIBs online, so you can easily see where the data you're interested in is, and then insert the appropriate commands into the script file.

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

Command	Explanation	Example
; or #	Comment	;comment line
!Include filename	Include commands allow you to include additional control files that are located in the same directory. This allows you to combine rules for certain areas or topics in your own .script files and thus structure the entries better and make them clearer.	!Include ProductKeys.script
!IF {regexist/ fileexist/ direxist/ oidexist:Path Action !ENDIF	Query for presence	!IF{regexist:HKEY_LOCAL_MACHINE\Software\Oracle8} !ADD SoftwarePackag Name=Oracle,Version=8,Publisher=Oracle !ENDIF
!Stop	Cancel inventory (e.g. to exclude computers from inventory)	If the registry value "Site" does not have the value B96, this computer will not be inventoried: !IF {ne:{reg:HKEY_LOCAL_MACHINE\SOFTWARE\SMS-IC\Userinfo,Site},B96} !STOP !ENDIF
eq/ ne/ lt/ le/ gt/ ge/ like/ notlike	Comparison: equal/ not equal /smaller /smaller or equal /larger /greater or equal/ similar to /not similar to	!IF {eq:%$LastInventory.IP%,192.168.200.157} Custom.parking space=R4.192 Custom.printer name=accounting !ENDIF
and/ or not	Boolean operators: and/or/ not	!IF {and!IF {fileexist:%SYSTEMROOT%\win.ini}, {regexist:HKEY_LOCAL_MACHINE\Software\MySoft} !STOP !ENDIF
!FindFiles <PFAD> & !FindFilesRec <PFAD>	File search and recursive file search (see Asset Inventory)	!FindFiles C:\Temp

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.

Info

The values presented below can also be used as command line arguments. In each case a // must be placed in front and instead of an assignment by a = a space is sufficient, e.g. LOGINfo.exe //TotalTimeout 300.

Attention

All switches set in the LOGINfo.script file are overwritten by command line arguments!

Command	Explanation	Default value	Example
AllGroups = [0|1]	Capture all groups: By default, only the members of the local Administrators group are captured. This switch can be used to enter all local groups.	0	!SET AllGroups=1
AllowOidsOutOfOrder = [0|1]	OIDs to be read must not be provided in an ascending order by the SNMP device; this option significantly slows down acquisition.	0	!SET AllowOidsOutOfOrder=1
AllowWindowsSnmp = [0|1]	Activate SNMP scan for Windows computers	0	!SET AllowWindowsSnmp=1
BootLogEntries = NUMBER	By default, only the last 50 BootLog entries (startup and shutdown of a machine) are captured. However, the list of BootLog entries is cumulated.	50	!SET BootLogEntries=100
ConnectionsMaxLocalPort = NUMBER	By default, all network connections that are >11000 on LocalPort are filtered out. This ensures that only incoming connections are recorded.	11000	!SET ConnectionsMaxLocalPort=65000
DontScanCurrent  UserUninstall= = [0|1]	Software Uninstall Key do not capture for current user	0	!SET DontScan  CurrentUserUninstall=1
DontScanNetinstall = [0|1]	Don't collect netinstall packages	0	!SET DontScanNetinstall=1
DontScanServices= = [0|1]	Do not include services	0	!SET DontScanServices=1
DontScanUninstall = [0|1]	Software Uninstall Key do not capture for the computer	0	!SET DontScanUninstall=1
EnableSnmpAlways = [0|1]	Force SNMP: Ignoring Windows APIs	0	!SET EnableSnmpAlways=1
HiddenAcls = [0|1]	Scanning of the permissions for shared folders also from hidden shares (ending on $ characters). Note: Administrative shares (Admin$, IPC$, C$, D$, E$, ...) are never recorded.	0	!SET HiddenAcls=1
Ignore = TABLE	Prevent acquisition of properties: Exclude table names (e.g. SharedFolder, DeviceInfo, Mainboard, Font, ...) from the acquisition		!SET Ignore=Mainboard or !SET Ignore=BootLog,Event
IgnorePingTtl = [0|1]	Perform Windows scan even if the ping TTL value indicates a non-Windows system	0	!SET IgnorePingTtl=1
InactivityTimeout = NUMBER	If a client does not respond to a query command (e.g. a WMI query) for 600 seconds during the scan process, a timeout is reached. This value can be adjusted.	600 sec	!SET InactivityTimeout=900
MaxDiskLetter  TryCount = NUMBER	Cancel search for local drives after a gap of X drive letter	5	!SET MaxDiskLetterTryCount=30 (Search for all local drives)
NoAcls = [0|1]	Authorization analysis: For performance reasons it may be desired to switch off the capture, since complete share folder structure on Windows servers must be searched recursively.	0	!SET NoAcls=1
NoCaching = [0|1]	No local copying of the LOGINfo.exe to the machine to be scanned. Instead, always run it from the data directory.	0	!SET NoCaching=1
NoCDP = [0|1]	Do not use Cisco Discovery Protocol (CDP): When inventorying switches and routers, CDP is typically used to discover a hierarchy (more directly connected switches or routers). This can be switched off.	0	!SET NoCDP=1
NoFonts = [0|1]	By default, all system fonts are scanned. However, this behaviour can be switched off.	0	!SET NoFonts=1
NoIPv6 = [0|1]	No reading out of IP v6 addresses (e.g. for the value NetworkAdapater.Ip)	0	!SET NoIPv6=1
NoLLDP = [0|1]	No use of the LLDP protocol for reading out connected MAC addresses at switches	0	!SET NoLLDP=1
NoNetworkPrinters = [0|1]	Do not register network printers	0	!SET NoNetworkPrinters=1
NoSysName = [0|1]	SNMP Do not accept SysName as asset name: If an inventory is made via SNMP, the PC name is read from the OID system.sysname and no longer via reverse DNS lookup. This can lead to different results for the PC name!	0	!SET NoSysName=1
NoTSPrinter = [0|1]	Do not register network printer during Terminal Service sessions	0	!SET NoTSPrinters=1
NoUsage = [0|1]	Do not record usage statistics: This prevents the collection of usage data from the Windows Explorer statistics and from the Usage Agent. This also removes any previously existing user data from the database and creates a new entry: "Suppressed_by_rule" instead.	0	!SET NoUsage=1
NoValidate = [0|1]	Ignore errors in the LOGINfo.Script file (Scan is also performed if there are incorrect entries.)	0	!SET NoValidate=1
NoVirtualSwitch = [0|1]	No virtual switch and the corresponding MAC address table is recorded for hosts	0	!SET NoVirtualSwitch=1
NoVmWare = [0|1]	No scanning of devices whose operating system name includes "ESX" or "VmWare". Note: These devices are usually scanned using LOGINfoESX.exe.	0	!SET NoVmWare=1
NoWMI = [0|1]	Do not use WMI: Normally, information is collected via Remote Registry and WMI. Acquisition via WMI can be switched off.	0	!SET NoWMI=1
ReplaceControlChars = [0|1]	Replace control characters: With this switch it is possible to instruct the inventory to replace control characters within a value like TAB, CR, LF by a space character. This can be desired, for example, when reading the operating system of a Cisco switch or router.	0	!SET ReplaceControlChars=1
RPC = [0|1]	RPC = 0 -> no RPC scan By default (RPC = 1) the LOGINfo.exe is copied to the computer and executed there. If this does not work, a fallback to RPC 0 is made -> complete remote API acquisition (only works in trusted environments with remote registry service enabled)	1	!SET RPC=0
RPCOnly = [0|1]	Use RPC scan only (no fallback to RemoteRegistry & WMI)	0	!SET RPCOnly=1
RpcTimeout = NUMBER	If a scan is performed via RPC, its process is aborted after 1200 seconds. This time period can be changed via this parameter.	1200 sec	!SET RpcTimeout=300
ScanAppUpdates = [0|1]	Microsoft App Update Package Capture	0	!SET ScanAppUpdates=1
ScanClusterIp = [0|1]	Performing a scan even when a cluster IP is detected	0	!SET ScanClusterIp=1
ScanDrivers = [0|1]	Reading driver information (to be found in the table "SystemDriver")	0	!SET ScanDrivers=1
ScheduledTaskLevel = ZAHL	Specifies which types of Scheduled Tasks should be read. 0 = do not capture Scheduled Tasks 1 = only tasks from the root folder 2 = all except Microsoft folder 9 = all	2	!SET ScheduledTaskLevel = 9
SnmpConnectTimeout = NUMBER	If an IP address does not respond to PING, LOGINfo will still try to open an SNMP connection. This happens twice with a timeout of 10s. This timeout can be changed.	10 sec	!SET SnmpConnectTimeout=2
StoppedVms = [0|1]	Create assets even for stopped virtual machines	0	!SET StoppedVms=1
TotalTimeout = NUMBER	The scanning process for an address is usually aborted after 5400 seconds (90 minutes) if there is no response. This time period can be changed via this parameter.	5400 sec	!SET TotalTimeout=600
UseSnmpFallback = [0|1]	SNMP Fallback: If an IP address does not respond to PING, no further attempt is made to connect to this node. Alternatively, an SNMP connection setup can still be attempted.	0	!SET UseSnmpFallback=1
Validate = [0|1]	Validates only the LOGINfo.Script file without starting a scan	0	!SET Validate=1
WmiMonitors = [0|1]	Depending on the manufacturer, the serial number of monitors is read differently. To force readout via WMI, the switch can be set to "1".	0	!SET WmiMonitors=1
WMIOnly = [0|1]	Only capture devices that support WMI. (Ignored if NoWMI has been set)	0	!SET WMIOnly=1

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!

Assignment of	Syntax	Example(s)
Constants	Property= Constant	Custom.Company=LOGIN
Environment variables	Property= %Environment variable%	Custom.WindowsDir=%Systemroot% Custom.UserPath=C:\Temp\%UserId%
LOGINventory-1:1-Properties	Property= %$Property%	Custom.IP=%$Lastinventory.IP% Custom.Mainboard=%$Mainboard.SerialNumber%/%$Mainboard.Name%
WMI values	Property= {wmi:[[root\][namespace\]WMI class,value} (If the namespace is not specified, CIMV2 is assumed.)	Custom.Year={wmi:Win32_LocalTime,Year} Custom.CName={WMI:root\CIMV2\Win32_ComputerSystem,Name} Custom.Part={WMI:CIMV2\Security\MicrosoftVolumeEncryption\ Win32_EncryptableVolume,DriveLetter}
Registry-Keys	Property= {reg:Key,Value } or Property= {reghex:Key,Value }	Custom.IEPatches={reg:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Internet Settings,MinorVersion} Custom.Serial={reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Vmware, Inc.\Vmware Workstation\License.ws.*",Serial} (Note: when using special characters and spaces, the key must be enclosed in quotation marks!)
SNMP values	Property= {OID:oid-in-dotted-Number}	Custom.SystemUpTime={oid:.1.3.6.1.2.1.25.1.1.0}
File version	Property= {fileversion:FileName }	Custom.IEVersion={fileversion:shdocvw.dll} Custom.MDACVER={fileversion:%CommonFiles%\System\ado\msado15.dll}
File Date	Property= {filetime:FileName }	Custom.BOOTINIDATE={filetime:c:\boot.ini}
File Size	Property= {filesize:FileName }	Custom.MDACSIZE={filesize:%CommonFiles%\System\ado\msado15.dll }
File language	Property= {filelanguage:FileName}	Custom.Vblang={filelanguage:vbscript.dll }

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

Note

The custom property "Location" does not need to have been created in the user interface before. If it does not exist yet, it will be created automatically and created as "Editable by Scanner / Agent", which also prevents it from being changed in the user interface by the user anymore.

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

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.