Technical Details

System Requirements

To install LOGINventory you need administrative rights on a supported version of Windows (7 SP1 and higher). In principle, no Windows Server operating system is required, but recommended for productive operation.

On the hardware side, we recommend at least four logical processors and at least 4 GB RAM.

LOGINventory requires an existing Microsoft Net Framework 4.52 or higher and a Microsoft SQL Server 2012 SP4 database or higher.


A preconfigured Microsoft SQL Server 2012 SP4 Express Edition is already included in the setup of LOGINventory.

Of course, you can also use existing databases that meet these minimum requirements (see Database configuration).

Management Server


  • Microsoft .Net Framework 4.52 compatible PC with 4 or more logical processors
  • 4GB RAM 
  • 10 GB available hard disk space

Operating System

  • Windows 7 SP1 (Internet Explorer 11 or higher required)
  • Windows 8.1
  • Windows 10
  • Windows Server 2008 R2 SP1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019


  • Microsoft .NET Framework 4.52 or later
  • Microsoft Powershell 4.0 or later



  • Microsoft SQL Server 2012 SP4 or later (all editions)
  • LOGINventory Database (included)

Prerequisites for Acquisition

Due to the agentless mode of operation, only network devices that have implemented one of the following remotely queryable interfaces can be captured:

  • Windows RPC (WMI, Remote Registry)
  • SNMP v1, v2c or v3
  • SSH

Devices where this is not the case - e.g. Fritz!boxes, non-manageable switches, Windows Home Editions, televisions etc. - cannot be captured in this way.

Microsoft Exchange:

  • Exchange 2010, 2013, 2016, 2019 (all editions)

Windows Devices:

  • Windows Server 2003 / 2008 / 2012 / 2016 / 2019 (all editions)
  • Windows XP / Vista / Windows 7 / Windows 8.x / Windows 10 (Pro, Ultimate, Enterprise)

Network Devices:

  • All with SNMP v1, v2c, v3
  • Linux/Unix derivatives and MacOS with SSH and Perl 5.8 or later
  • VMware vCenter or ESXi v5.x and 6.x
  • XenServer 4.x or later


  • x86 or x64 Intel architecture for local data acquisition via LOGINfo
  • Any for remote data acquisition (IP scan)

Windows Devices

Remote Scan

The remote scan of Windows computers is configured and executed in LOGINventory via a definition of type Asset Inventory.


Since there are no "ReadOnly-Admins" in Windows, you always have to use an account with local administrator rights on the respective computers. This is the case, for example, with a domain admin.


An account that only has WMI rights is not sufficient, because LOGINventory uses additional sources to collect a complete picture of the entire software, hardware and configuration.

The necessary APIs are not available in Windows Home Editions, in all other Windows Editions at least the service "Server" or "File and Printer Sharing" must be started and of course no firewall must hinder communication.


How to configure the firewall properly is described in detail here.

In same domain - or with Trust

The scan within the same domain or other domains with trust status (Trust) additionally requires full access to Administrative Shares (C$, Admin$, ...). Alternatively, the "Remote Registry" service must be running. Attention: This service is "Disabled" by default from Windows 10 on.

In another domain - without Trust

In principle, the scan only works across non-trusted domain boundaries if there is full access to administrative shares (C$, Admin$, ...).

In Workgroup


If you are experiencing errors 1312 or 1326 although everything might seem to be configured correctly, make sure to check the account you are using for the service LOGINventory8-InventoryService. The used account needs to have administrative rights on the LOGINventory machine (with password). Do not use Local Service or Local System!

For workgroup computers - or when capturing using the local account of the remote computer (also in domains):

  • UAC-Remote must be disabled, i.e. in the registry:
    • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, LocalAccountTokenFilterPolicy (DWORD) must be set to 1.
    • In addition, the following policy must be set (e.g. locally via GPEDIT.EXE), which is always set like this for domain members:
      Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options / Network Access: Sharing and Security Model for Local Accounts = Classic
  • The password of the remote administrator must not be empty.

Ports and protocols used for remote scan

TCP/IP (IPv4 or IPv6) and is used for acquisition:

  • ICMP Echo Request (Ping)
  • Client for Microsoft Networks
    • TCP Port 139 (NetBIOS Session Services)
    • UDP Ports 137 and 138 (NetBIOS Name Server, NetBIOS Datagram)
    • TCP Ports 135 and 445 (RPC, WMI)
    • Dynamic Ports:
      • Windows Server 2008, Windows Vista and higher: TCP Ports 49152-65535
      • Windows 2000, Windows XP, and Windows Server 2003: TCP Ports 1025-5000
  • UDP Port 161 (SNMP)
  • TCP/UDP Port 22 (SSH)
  • TCP/UDP Port 443 (VMware vSphere)

The Windows Firewall configuration is explicitly described below.

Recommended as access test:

C:\> NET USE * \\\RemotePc-or-IP\Admin$ /USER:Domain\AdminAccount AdminPassword


C:\> WMIC /NODE:RemotePc-or-IP /USER:Domain\AdminAccount /PASSWORD:AdminPassword CPU

Logon Script

No further prerequisites need to be fulfilled on the respective computer when executing the logon or startup script. The executing account must only have the right to store the .INV file created during the entry in the "data directory" of the LOGINventory computer, i.e. have write access to the share and in the file system.

We recommend: Authenticated Users (= Domain User + Domain Computers) with write permissions ("Change")

Example for a logon script call

START /B \\loginventory-server\LI8DATA\LOGINFO.EXE

Windows Offline Agent

With the Offline Agent the inventory data can be delivered via http/https to a web server as well as to a file share. Also here the used account must have write permissions on the share and in the file system of the "data directory".

To install the Offline Agent on a Windows computer, the .NET Framework 3.5 must be available.

Exchange Organization

The definition type "Microsoft Exchange Inventory" is used in the Remote Scanner to inventory a complete Exchange organization. The account used requires membership in the role "View-Only Organization Management" or "Organization Management" in the Exchange organization. As the source, you only need to select one Exchange Server from the suggested list, the one with the highest version, but no Edge role. At the same time, the account on the Exchange Server computer - as always with Windows - must have local administrator rights.

VMware vSphere, ESXi

For VMware ESXi and vCenter there is the definition type "VMware vSphere Inventory" in LOGINventory.

The used account only needs "read only" rights.

Typically, when you capture ESXi or vCenter, the Job Monitor will display a "Warning: Invalid SSL Certificate" message if you are using SelfSigned certificates automatically created by VMware and have not yet used a trusted certificate authority. This warning does not affect the inventory.


An account with administrator rights on the XenServer is also required here.

XenApp Server

To access the XenApp data on a corresponding Windows server, the account used in the "XenApp Inventory" method must have administrator rights on both Windows and XenApp. In addition, the Citrix XenApp Powershell SDK must be installed on the XenApp computer (supplied in the ISO with the XenApp setup).

Unix, Linux, MacOS

The acquisition of these systems via "Asset Inventory" is done via a Secure Shell connection, which transfers the acquisition script and the result data.

The prerequisites for this are general:

  • Installation/activation of the SSH daemon (including share of port 22)
  • Account with "sudo" or "wheel" rights (only with this account hardware information can be read)
  • Program package Perl (from version 5.8)
  • Necessary existing commands:

    which perl chmod cp gzip mkdir mv rm rmdir tar cut date head last uname

The authentication of the user for SSH is done alternatively by user name and password or by user name and key file as well as passphrase. On some systems the password authentication must be enabled separately, the authentication via key file with passphrase is in principle always possible. The key file must be in OpenSSH format because SSH.NET is used. PPK keys from PuTTY can be converted to this format.


In detail, the following modules are required:
Perl module XML::Simple, Perl module Net::IP, Perl module LWP::UserAgent, Perl module Net::SSLeay, Perl module Data::UUID, Perl Module Mac::SysProfile (on MacOSX), dmidecode, lspci (on Linux and BSD (pciutils package))
The following modules are recommended:
Perl module IO::Socket::SSL, Perl module Crypt::SSLeay, Perl module LWP::Protocol::https, Perl module Proc::Daemon, Perl module Proc::PID::File (if Proc::Daemon is installed), Perl module Net::SNMP, Perl module Net::Netmask, Perl module Nmap::Parser, Perl module Module::Install, Perl module Net::CUPS, Perl module Parse::EDID, Nmap (v3.90 and higher)

Mac with OS X

The SSH daemon is activated by default. In the file /etc/ssh/sshd_config the entry for PasswordAuthentication must be activated and set to the value yes. After a change a restart of the system or a restart of the daemon is not necessary.

SuSe Linux

The following actions must be performed to enable SSH:

  • NetServices: sshd enable
  • Firewall / Service / Share SSH daemon

For the password authentication the entry must be changed in the file /etc/ssh/sshd_config: PasswordAuthentication no -> yes

After a change a restart of the system or a restart of the daemon is necessary.

Ubuntu Linux

The activation of the SSH daemon must be done explicitly as follows:

sudo apt-get install openssh-server

Password authentication is activated by default here.

Red Hat Linux, CentOS

The SSH daemon and password authentication are activated by default.

Oracle Solaris

The SSH daemon and password authentication are already activated by default. To use the user ID "root", however, the configuration of the SSH daemon must be adapted:

  • In the file /etc/ssh/sshd_config the entry for PermitRootLogin must be set to yes.
  • In the file /etc/default/login the entry for CONSOLE must be commented out: #CONSOLE=/dev/console.
  • In the file /etc/user_attr the entry ;type=role must be removed from the 'root' entry. This can be done with the following command: rolemod -K type=normal root.
  • Now you have to restart the SSH daemon: svcadm restart svc:/network/ssh:default.

Troubleshooting Scanning Unix, MacOS and Linux

If the acquisition of these devices is not successful and the reasons are unknown, a dialog box can be used to search for errors. This window can be opened by selecting the Custom action "SSH Test" in the Failed Inventory node for a failed asset or by selecting "SSH Troubleshooting" in the Job Monitor. The window can also be opened directly with the command %ProgramFiles%\LOGIN\LOGINventory8\LOGINfoX.exe /w.

In the dialog that opens, different user names, passwords, key files, ports, timeouts, etc. can be tested. The messages show directly to what extent the inventory is successful with these values and parameters. If the inventory was successful, the result code 20300 is output.

Printers, Routers, Switches

These devices are usually captured via Asset Inventory using SNMP v1, v2c or v3. The SNMP v1/v2c API is standard in Windows and works without further configuration steps. Most printers have a SNMP v1/v2c ReadOnly community string "public" preset, which can be used to easily read the configuration.

This is usually not the case with routers and switches and must then be configured manually. We recommend using different community strings to select specific device types when capturing data. The default view (should be the OID 1) and the IP of the permitted management station(s), i.e. the LOGINventory computer ( = all computers) may also have to be adapted.

If SNMP v3 is to be used, a NetSNMP Credentials user account can be used.

Differences between the Acquisition Methods

Depending on whether the acquisition of a Windows device is carried out with a privileged user (local administrator) or unprivileged user, or remotely or locally, different data is sometimes available. However, the data is identical to about 99 %.

Remote Local
Rights of scanning / executing user always privileged only privileged if executing user is local administrator
Additionally collected data connected network drives (entity: NetworkDrive)

Only in the exceptional case when the remote-scanned user is the same as the currently logged on user of the device to be scanned, the connected network drives are also included in the remote scan.

The unprivileged scan differs from the privileged scan by missing access to certain information:

  • Encryption status of partitions (bitlocker)
  • Entries from the security event log
  • Hard disk data on SMART values and whether it is an SSD
  • TrustedPlatformModule values


The Offline Agent creates two Scheduled Tasks: One in the user context, one in the system context. This ensures that the data is captured at least once in a privileged manner, thus achieving a complete image of the computer.


In summary, it can be said that the agentless scan basically captures all data except for the connected network drives, whereas when LOGINfo.exe is executed locally (e.g. in the logon script), certain particularly sensitive information is not available. However, the combination of both collection methods merges the collected data.

Installed Services

During the installation of LOGINventory different services are installed, which offer different functionalities.

Service name Description
LOGINventory8 Inventory Service This service starts the agentless acquisition of the devices. Among other things, it ensures that the inventory is carried out even if LOGINventory is not started.
LOGINventory8 Data Service This service monitors the data directory and processes all .inv files stored there. This service must therefore run so that all newly recorded devices are also entered into the database and are thus available for evaluations. If several clients have been created, this service also monitors the different data directories and enters the data into the correct database.
LOGINventory8 Automation Service This service performs all tasks and notifications, ensuring that emails are sent and exports and reports are stored in pre-defined locations.
SQL Server (LOGINVENTORY) This service provides the SQL Server instance for LOGINventory.

If several clients are created, additional instances of the LOGINventory8 Inventory Service and LOGINventory8 Automation Service services are also created, each of which applies to one client. They manage the recording and execution of the tasks accordingly.

Troubleshooting non-starting services

If the services Inventory Service and/or Automation Service cannot be started, this is probably because the used accounts under which the services run do not have database access.
In this case, make sure that the accounts have database access by opening the "services.msc"! For example, database access is not given by default if the database is on a different machine and no SQL Server authentication is used, but Windows authentication is!
In the LOGINventory Event Viewer, you will find detailed error messages that provide information about the cause if the start is unsuccessful.

System Tasks

To perform various calculations / optimizations, the following system tasks are created automatically:

Name Description Time
DataCleanup Automatic data cleanup, if the corresponding check mark was set in the Settings 01:00 a.m.
RebuildSharedFolder Automatic recalculation of effective access rights to shared folders for individual users 03:00 a.m.
ReorganizeIndices Generate indices in the database to improve performance 04:00 a.m.

Additionally, there is a special task (not a system task): The Calculation of the license status of the products in the license management. The associated task is located on the License Management node and can be edited so that the calculation can be performed at a different time than the default setting of 02:00 a.m..

Windows Firewall Configuration


Basic prerequisite for the acquisition of remote Windows computers: The service "Server" ("LanmanServer") must be running and access to administrative shares (e.g. IPC$, Admin$, C$) must be given.

Used Ports

ICMP Echo Request (Ping)
UDP Ports 137 and 138 (NetBIOS Name Server, NetBIOS Datagram)
TCP Port 139 (NetBIOS Session Services)
TCP Ports 135 and 445 (RPC, WMI)
Dynamic Ports:

  • Windows Server 2008, Windows Vista and higher: TCP Ports 49152-65535
  • Windows 2000, Windows XP and Windows Server 2003: TCP Ports 1025-5000


If you use the Windows Firewall you can enable Windows Management Instrumentation (WMI) in the firewall settings, then all required ports will be opened automatically.

Recommended as Access Test :

C:\> NET USE * \\RemotePc-or-IP\Admin$ /USER:Domain\AdminAccount AdminPassword


C:\> WMIC /NODE:RemotePc-or-IP /USER:Domain\AdminAccount /PASSWORD:AdminPassword CPU

If there are problems with the acquisition, we recommend to switch off the firewall temporarily in the active profile on a computer to be scanned and then run the scan again. You can disable the Windows Firewall from the Control Panel.

If the problem with the capture is then solved, the firewall should be configured accordingly for all computers.

Simplest Solution

Group policies can be used to deactivate the firewall in the domain network for all computers.

On all computers to be scanned, corresponding rules can be defined (manually or via group policies) that allow the connections required for the scan from the LOGINventory server (or for the entire server subnet).

This rule can be stored by opening the Advanced firewall settings:

  • Define New Incoming Rule

  • Select Custom; Next

  • Select All programs; Next

  • Protocol type: Select Any; Next

  • For which local IP addresses does this rule apply? Any IP address (default)
  • For which remote IP addresses does this rule apply? These IP addresses: here you enter the address (or subnet) of the LOGINventory computer, e.g.: or 192.168.169
  • Select Allow connection.
  • In the next step check the Domain profile box
  • Finally, a name must be specified for the rule, e.g: allow LOGINventory

Of course, you can also define this as a group policy in the domain. To do this, you must first have a domain controller, for example:

  • Open Group Policy Management
  • Navigate to the desired OU
  • Create and link a Group Policy object here (name e.g. "Firewall") and then edit it:
  • Navigate to Computer Configuration / Policies / Windows Settings / Security Settings / Windows Firewall / Windows Firewall / Incoming Rules and select New Rule.

The further procedure then corresponds to the procedure described at the beginning of this chapter.

Fallback Method

As a fallback method, if administrative shares are not available, data can also be collected via the remote registry. The service "RemoteRegistry" must be set to Automatic or Manual for the Start type.

This can also be done centrally via group policies under Computer Configuration -> Windows Settings -> Security Settings -> System Services.


This method requires a functioning trust between the computer to be scanned and the LOGINventory computer.

Log Files and Event Viewer

The individual modules of LOGINventory8 write log information into the directory %ProgramData%\Login\LOGINventory\8.0. The LOGINventory Event Viewer can be started via the LOGINventory Data Service icon in the task bar and via the LOGINventory ribbon menu under Extras. This also contains information about the program flow of LOGINventory and can provide valuable conclusions about error sources.

Structure of .inv Files

The recorded data of an asset is saved in .inv files and then entered into the stored database. A .inv file is basically an encrypted .xml file. These files can also be created by yourself to write data in LOGINventory with an external tool, for example. You can create a .xml file and rename it to .inv, e.g. test.inv. When this file is moved to the Data Directory, it is automatically added to the database and a new asset is created in LOGINventory.

A .inv file can look like the following as an example.

<?xml version="1.0" encoding="utf-8"?>

<Inventory xmlns=""


    Agent="Notepad" Account="Domain\user"

    Timestamp="2018-11-09T13:47:23Z" Duration="1000" >

<Device xmlns="">













        <NAME>Unknown OS</NAME>





Identification of Assets by Fingerprint

Asset identification is based on a fingerprint, which is used to identify whether the asset is an existing asset or a previously undetected (= new) asset. This fingerprint is composed of a number of device properties (if available):

Name, LastInventory.Mac, SystemUUID, SerialNumber, AssetTag, DnsHostName, Contact, Description, Location, MachineSid, Operatingsystem.DistinguishedName, MobileDevice.IMEI, MobileDevice.ID

The fingerprint procedure can be bypassed by having the value CustomID set, either by reading it from the following registry value: HKLM\Software\LOGIN\LOGINfo\CustomID or set via the file LOGINfo.script, e.g: CustomID=%$DeviceInfo.SerialNumber%.


Bypassing the fingerprinting method may be desired if the information collected at capture does not recognize that two scan states are the same device or if the information collected from two devices is so similar that they are mistaken for the same asset.


If the CustomID is set or changed on an existing asset in LOGINventory, this will result in the creation of another asset.

Backup / Restore

In general, we always recommend to install LOGINventory on a Windows Server operating system and to use the normal daily data backup here as well. In exceptional cases, however, the installation can also be performed on a desktop operating system; however, no data backup mechanism is normally available for these. For such exceptional cases, where no backup procedure is available at all, we provide two batch files: Backup-LIV.bat and Restore-LIV.bat. These files are located in the subfolder "Resources" in the LOGINventory installation directory. With the help of these files, a simple data backup of the LOGINventory database, configuration and scan definitions can be performed if the following requirements are met:

  • The supplied local database is used in the instance "LOGINventory".
  • The name of the database is LOGINventory8.
  • The executing user is a local administrator.

The Backup-LIV.bat file will then do the following:

  • Query the directory to which you want to back up;
  • The central configuration files LOGINventory.Config and Scandb.sdf are copied to the above directory;
  • The "LOGINventory8" database from the "LOGINVENTORY" instance is saved in the above directory.

The Restore-LIV.bat file then executes the following:

  • Query the directory in which the backed up data is stored;
  • The central configuration files LOGINventory.Config and Scandb.sdf are copied back from the above directory;
  • The "LOGINventory8" database from the "LOGINVENTORY" instance is restored from the above directory.

Advanced Acquisition via Command Line

When using Remote Scanner, depending on the Definition Type, the GUI will call a corresponding .exe file that performs the actual acquisition, resulting in an .inv file that contains the collected information. These .exe files can also be called directly from the command line or within a script, if the correct parameters are used.


Acquisition via command line can be interesting e.g. when scanning customer networks where nothing is to be installed or when taking inventory of a "foreign" domain, i.e. without trust and DNS integration - e.g. by service providers who want to do this via VPN dial-in or by using a laptop on site. In this case it offers some advantages compared to the use via remote scanner GUI.

The .exe files relevant for the acquisition are located in the LOGINventory program directory (by default 'C:\Program Files\LOGIN\LOGINventory8').

Scan Definition Program Relevant Parameter
Asset Inventory LOGINfo.exe, LOGINfoX.exe -
Active Directory Attribute Lookup LOGINfoAD.exe -
MS Exchange Inventory LOGINfoMX.exe -
VMware vSphere Inventory LOGINfoESX.exe -
XenApp Inventory LOGINfoMX.exe /XenApp
XenServer Inventory LOGINfoESX.exe /XenServer
SQL Server Inventory LOGINfoESX.exe /SqlServer
Microsoft 365 Subscriptions LOGINfoMX.exe /AzureAD

The following syntax applies to the specification of further parameters:

...exe [!Target] [DataDir] /USER domain\user password [/AdditionalParameters]

Via !, the device to be recorded is always specified by means of FQDN or IP - it must be ensured that no "conflicting credentials" occur. In the path [DataDir] specified afterwards, the resulting .inv file is stored, the acquisition is carried out with the user specified in /USER and the parameters specified additionally afterwards also influence the acquisition.


For example, the acquisition of a XenServer named "XenServ01" is started with the following command and the resulting inv file is stored in the directory "C:\Temp":
LOGINfoESX.exe !XenServ01 C:\Temp /XenServer.


The use of the LOGINfo.exe is already described in detail here. The other available switches are also explained there.


For the stand-alone execution of the AD acquisition, additional files must be copied from the program directory into the directory with the LOGINfoAD.exe:

  • LoginfoAD.exe
  • LoginfoAD.exe.config
  • Login.Quiry.dll
  • Login.tasks.dll
  • Login.Ventory.Data.dll
  • Login.Ventory.Common.dll
  • EntityFramework.dll
  • Essential.Diagnostics.dll

By calling LOGINfoAD.exe, the lookup is executed on the domain to which the current user is logged on and the resulting .inv files are written to the same directory. In principle, LOGINfoAD can only be executed on a computer that is a domain member of the domain to be captured, or can use a position of trust for this purpose.

Thus, the domain "" can be captured with the following command:

LOGINfoAD.exe ! C:\temp

Alternatively, a domain controller can be specified directly after the !.


Parameter Explanation
/DontIgnoreInvalidCertificate If no valid SSL certificate is found, by default the acquisition is still performed. This can be prevented with this parameter.
/Port VMware acquisition: Use a different port for acquisition (Default: 443)
/SqlServer Start SQL Server inventory
/XenServer Start XenServer inventory
//NOVIRTUALSWITCH 1 For hosts, no virtual switch and the corresponding MAC address table is recorded
///Custom.Property "Value" Creates a new "property" with the value "Value". Applies only to ESX host discovery.


Parameter Explanation
/MaxLastSync Exchange acquisition: By default, mobile devices that have synchronized via EAS within the last 90 days are captured. This period can be adjusted with this parameter (e.g. to 30 days: /MaxLastSync 30)
/NoEas Exchange acquisition: No scanning of devices connected via EAS (smartphones etc.)
/EasOnly Exchange acquisition: Only scanning of devices connected via EAS (no mailboxes etc.)
/NoMailbox Exchange acquisition: No mailbox information read out
/ServerFilter Exchange acquisition: Using wildcards only certain Exchange servers can be selected for acquisition
/Test does not carry out a scan, but only checks whether an acquisition would be possible (return code 20429)
/TestCmd can be used to test CMD commands, e.g. /testcmd "echo Test1"
/TestPowershell Powershell commands can be tested, e.g. /testpowershell "write-output test2"
/NoRpc hereby the Powershell session for acquisition is not executed on the specified Exchange Server, but locally

All test parameters can also be combined several times to test different command combinations during acquisition. This can be useful for identifying errors or problems.

Example test command:

LOGINfoMX.exe !exchange2019 C:\Temp /user domain\admin password /test /testmd "echo hello" /testpowershell "write-output hello2" /norpc