Skip to content

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.


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.


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


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.


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.


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.


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

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. This function is currently only available in beta mode.

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.


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.


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. -
  • IP v4 Subnet (CIDR) (e.g.
  • File List (Text file with names or IP addresses of the assets: one entry per row)
  • List of elements
  • Active Directory: You can scan the devices that have entries in the AD.


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.


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.

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


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


When doing an Asset Inventory, all Hyper-V instances are also being scanned. Please refer to the notes on special considerations for hypervisor acquisition, which also explain how certain VMs are not scanned, why the VMs should also be scanned directly and how the hosts and VMs are assigned custom properties!


If you want to exclude certain devices from being scanned, use the Scan Defintion Exclusion from Inventory.

Active Directory Accounts and Groups


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.

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.

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.


We recommend that the periodic cleanup of Active Directory data is enabled (and the scan is performed regularly).

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


You can also specify a Cloud Server as the source, simply enter the address in the line of the server name, e.g. ''.

Prerequisites for scanning Online Exchange Servers using an app registration

In summary, the following requirements apply to the scan:

  1. An Internet connection must exist.
  2. The ExchangeOnlineManagement PowerShell module must be installed on the LOGINventory machine.
    This module is installed by entering the command Install-Module -Name ExchangeOnlineManagement in an administrative PowerShell on the scan server (the computer on which LOGINventory is installed, from which the data query is to be done).
    If necessary, the NuGet provider must still be installed first via the PowerShell so that the ExchangeOnlineManagement module can be installed. However, this will be pointed out by PowerShell if the above command is executed.
  3. An Azure Credentials type account must have been set up and authorized according to the instructions and must be used for the scan.
  4. The app registration manifest must have been customized & the customization confirmed with administrator approval, see warning in step 2, otherwise an "Access Denied" message will be shown.


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.


If a Custom Property is to be given to the Exchange Servers and mobile devices (EAS) directly at the time of acquisition (analogous to Asset Inventory), then this is only possible by adding a corresponding command line argument. The syntax here is ///Custom.Property "Value". So the argument ///Custom.Floor "3rd floor" will create a "Floor" property with the value "3rd floor" for all captured Exchange Servers and mobile devices.

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. or the IP address).


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.

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.


So the inventory is interesting for pure Azure Active Directory environments, as well as for hybrid environments (on-premises AD with with AAD Connect, or AAD Sync).


If both Azure AD and on-premises AD are captured in hybrid environments, no duplicates are created, but the data is merged.


To read data from the Azure AD, it is necessary to create an app registration in the Azure Portal. This procedure is described in detail in the Technical Details.

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.


In summary, the following requirements apply to the scan:

  1. An Internet connection must exist.
  2. An Azure Credentials type account must have been set up and authorized according to the instructions and must be used for the scan.

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


We recommend that the periodic cleanup of Cloud Subscription data is enabled (and the scan is performed regularly).

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.


In summary, the following requirements apply to the scan:

  1. An Internet connection must exist.
  2. An Azure Credentials type account must have been set up and authorized according to the instructions and must be used for the scan.
  3. The app registration must have been assigned a subscription, see step 4. Otherwise, an "Access denied" message will appear.


To read out the details of the software, configuration, etc., it is recommended to install the offline agent on the virtual machine, for example.

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.


In summary, the following requirements apply to the scan:

  1. An Internet connection must exist.
  2. An AWS Credentials type account must have been set up and authorized according to the instructions and must be used for the scan.


To read out the details of the software, configuration, etc., it is recommended to install the offline agent on the virtual machine, for example.

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


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.

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.

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.


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.


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.


If certain VMs should no longer be detected, this can be set via command line arguments when detecting the respective hosts (see Tip "Excluding specific virtual machines (VMs)").

Script-based Inventory


This function is currently only available in beta mode. Read here how to activate beta mode.

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.


For example, new devices can be created in LOGINventory by using a script to access an API that can be used to retrieve device information. This could include management systems for thin clients, mobile device management solutions, etc. - i.e. systems for which there is currently no explicit interface in LOGINventory.
Further information on licenses managed in the cloud, warranty information from other manufacturers and more could also be retrieved.

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


Detailed explanations of the syntax can also be found here. You can also share your own scripts with other users or improve existing scripts together with other customers. Feel free to exchange ideas with other users via the Github discussion function!

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.


Anyone who has the option of exchanging this file or storing their own scripts in this directory potentially also has access to the Parameters stored in the definition. It is therefore essential that you ensure that only authorized persons have access to this folder, for example by adjusting the file system permissions accordingly.

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


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


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


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.


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.


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.


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.


In order to share this folder from this dialog, you need to launch LOGINventory with administrative rights.

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.


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:

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.


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.


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.


Acquisition of the computer with the IP "": LOGINfo.exe !
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)


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


Attention: Observe before setup

Before running the wizard, we strongly recommend that you make sure that the web viewer has been published and the data directory has been shared. Only then the wizard will automatically suggest the correct paths for the URLs.
If you are not sure whether these requirements are met, please check this or run the corresponding wizard again!

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.


Please note that when using http(s) to transfer data to the IIS server, the server must be configured so that it can receive the data. If only Windows devices send data to the server, it is sufficient to activate Windows Authentication. If macOS/ Linux devices are also to be equipped with the Offline Agent, Basic Authentication must also be activated in the IIS configuration. You can find more information on this topic in the Helpdesk.

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)


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

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 file is stored (see explanations for updating the Offline Agent).
  4. The web server or the user must be able to write to the data directory specified in OfflineAgent.aspx.
    The web server uses an account from the group IIS_IUSRS (group that contains all ApplicationPool identities), or the account that is assigned to the corresponding ApplicationPool.
    If the computer is not in the domain (DMZ), Basic Authentication must be activated on the IIS for the offline agent application.

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.


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.


In the "macOS" folder, a setup for the macOS operating system is also automatically created. The setup is explained below.

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


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


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


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

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 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 for self-update. Thereupon a file "" 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 for Selfupdate (i.e. the complete update) must be executed.


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\9.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\LOGINventory9\LoginfoXScripts).


Please note that when using http(s) to transfer data to the IIS server, the server must be configured so that it can receive the data. If only Windows devices send data to the server, it is sufficient to activate Windows Authentication. If macOS/ Linux devices are also to be equipped with the Offline Agent, Basic Authentication must also be activated in the IIS configuration. You can find more information on this topic in the Helpdesk.

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 (/opt/loginfox/
    • 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

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

macOS Offline Agent


Please note that when using http(s) to transfer data to the IIS server, the server must be configured so that it can receive the data. If only Windows devices send data to the server, it is sufficient to activate Windows Authentication. If macOS/ Linux devices are also to be equipped with the Offline Agent, Basic Authentication must also be activated in the IIS configuration. You can find more information on this topic in the Helpdesk.


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


The transfer of files from the offline agent to the target server can only be done via http(s), not via fileservice or other methods.

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


If not the directory "/Users/Shared" but the directories "Downloads", "Documents" or "Desktop" are used, security errors may occur during the installation and it may fail!

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)/" 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 file (see Setup).


Unlike the Windows Offline Agent, the macOS Offline Agent does not have a self-update mechanism! This means that the macOS agent may need to be updated manually if the capture logic or data model has changed with a new version.


You can see how a device was captured by checking the LastInventory.Method and LastInventory.Agent values. For example, if a device was captured with a macOS Offline Agent version "", the values look like this:
For a macOS device that was captured agentless, this would instead say LastInventory.Method = SSH and LastInventory.Agent = LOGINfoX

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!


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!


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.


The data is always evaluated in License Management.


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.


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.


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


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.


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


If you want to import data for multiple assets from Excel lists or csv files, it is recommended that you use the Data Import Wizard.

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.


For the manual creation of actually scannable devices (device / mobile), a "normal" asset license is required, as for every scannable device. Since this method is also used to create devices that are still in the process of being installed ("prestaging"), the manually created asset can be expanded with scanned information at any time by means of a successful scan.
The situation is different for peripheral devices: These require a peripheral asset license.

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.


This way it is possible to quickly create several similar assets.

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.


If you want to fill your own properties, you can do this - as with any other asset - via the Custom Properties - Widget.


If devices that could not be successfully inventoried (e.g. IP phones, TVs, etc.) should also be created as assets, you can select the Convert to Asset action from the ribbon menu in the list of unsuccessfully created devices (Failed Inventory inside the folder Error Analysis). 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.

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.


LOGINventory can collect information about connected peripherals already by capturing devices. However, there are good reasons to create these devices as independent peripheral devices in LOGINventory:

  • By default, information about connected devices is "volatile", i.e. if a monitor or USB device is unplugged, the information is for now lost because it is "currently disconnected" (it may still show up in the change history).
  • When converting to a peripheral device, information may be added that cannot be read from the connected device by scanning a PC, e.g. serial number, model designation, etc.
  • If additional information, such as custom properties, invoices (in the Documents widget), etc., is to be stored on the connected devices, these must exist as an independent device in LOGINventory.
  • If a label is to be printed for the device, it must be created as a peripheral device and thus be assigned a unique inventory number.
  • If the handing out and return of the device to a user is to be documented by using a smartphone, a separate web page must exist for the device - this is only the case for explicitly created (or automatically recorded) devices.

To create peripheral devices, either the Asset Editor can be opened via New Asset as described above, or, in the case of monitors and devices connected via USB, the information collected by the acquisition can be applied.


To do this, switch to a query that shows all USB devices or connected monitors, or expand the details of a single asset and then switch under "Hardware" to "Monitors" or "USB devices". Then, when you select one or more result rows in the Data View, the Create Peripheral Device option is available in the ribbon menu. If only one result row is selected and the option Create Periphery Device is chosen in the ribbon menu, the details of the new peripheral device to be created can be edited directly. In case of multiselection all devices are created directly and can be edited afterwards as described above.


The field "CustomType" fills the Custom Property "CustomType". This field should be used to specify the type of device (e.g. headset, webcam, docking station, etc.). If a name is selected for which an image with the same name is stored in the Resource Repository, the corresponding icon will appear in the Info Widget, among others.

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


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


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.

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.


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.


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.


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.


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


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.


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


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


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.


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= 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%,} Custom.parking space=R4.192 Custom.printer name=accounting !ENDIF
and/ or not Boolean operators: and/or/ not !IF{and:{fileexist:%SYSTEMROOT%\win.ini}, {regexist:HKEY_LOCAL_MACHINE\Software\MySoft}} !STOP !ENDIF
!FindFiles <PATH> & !FindFilesRec <PATH> File search and recursive file search (see Asset Inventory) !FindFiles C:\Temp


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.


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.


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

Command Explanation Default value Example
AllCertificates = [0|1] Read all certificates that can be found on a computer and not only the certficates found in the SystemStore "My" 0 !SET AllCertificates=1
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] Do not collect Enteo Netinstall packages. The Enteo Netinstall software distribution writes additional entries to certain registry keys when a package is distributed. When this switch is used, the additional entries are no longer captured (the corresponding registry keys are not searched). However, the actually installed packages are still captured. 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
ForceAllPossibleData = [0|1] If this switch is used, the very likely incomplete data of the services (entity: Service) & scheduled tasks (entity: ScheduledTask) will be acquired. This captures the values that can be read in the context of an unprivileged user, although significantly more values would be available through an administrative scan. For more details see Technical details. 0 !SET ForceAllPossibleData=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
IgnoreFingerPrintRules=NameOnly Disables the fingerprint rule "NameOnly". More details here !SET IgnoreFingerPrintRules=NameOnly
IgnorePingTtl = [0|1] Perform Windows scan even if the ping TTL value indicates a non-Windows system 0  !SET IgnorePingTtl=1
IgnoreVMs "[Name:<NAME>][OperatingSystem:<OPERATINGSYSTEM>]" Exclude certain VMs from beeing inventoried as assets when scanning the host (see detailed explanation: Tip "Excluding specific virtual machines (VMs)") //IgnoreVMs "[Name:A*][OperatingSystem:*Linux*,*Windows*]"
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)
NetinstallDispPrefix = PREFIX If Enteo Netinstall packages should be scanned (see switch DontScanNetinstall), but the names of the packages should have a prefix in the SoftwarePackages list (to distinguish them), a prefix can be added to the names of the packages by using this switch. !SET NetinstallDispPrefix = "NETINSTALL_"
NetinstallKeyPrefix = PREFIX If Enteo Netinstall packages should be scanned (see switch DontScanNetinstall), but the KeyName of the packages should have a prefix in the SoftwarePackages list (to distinguish them), a prefix can be added to the KeyName of the packages by using this switch. !SET NetinstallKeyPrefix = "NETINSTALL_"
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
NoFailedLogons = [0|1] By default, all failed logon attempts are read from the event log (event id: 4625). However, this behaviour can be switched off. 0  !SET NoFailedLogons=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
NoLoginUse = [0|1] Reading Program Usage Data from LOGINuse agent can be prohibited. 0 !SET NoLoginUse=1
NoNetworkPrinters = [0|1] Do not record network printers connected to Windows devices. This switch does not affect the inventory of printers via SNMP. 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
NoUpdatesPending = [0|1] Do not look for pending Windows Updates when scanning Windows devices 0 !SET NoUpdatesPending=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 TABCRLF 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
ScanSqlServerDatabases = [0|1] For SQL Server databases, asset inventory captures the identifiable names of the databases, even though a dedicated SQL Server acquisition would provide significantly more values. 0 !SET ScanSqlServerDatabases=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
WmiSmartData =[0|1] By default, an attempt is made to acquire SMART data from disks using the CDI method. If these data should be collected via WMI, this switch can be set to 1. 0 !SET WmiSmartData=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 (

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\*",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:.}
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\*",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*.


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

!IF {like:%$Lastinventory.Ip%,192.168.10.*}

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


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

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

!IF {like:%$Operatingsystem.Name%,*SonicWALL*}

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"?>
<Name>custom name</Name>
<myvalue>myvalue content</myvalue >
<Description>device description</Description>
<Name>os name</Name>
<Version>os version</Version>
<Domain>os domain</Domain>
    <NAME>F-Secure Policy Manager</NAME>
    <PUBLISHER>F-Secure Corporation</PUBLISHER>
    <NAME>FileZilla Server</NAME>
    <VERSION>beta 0.9.60</VERSION>
    <PUBLISHER>FileZilla Project</PUBLISHER>

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.