Technical Details

System Requirements

To install LOGINventory you need administrative rights on a by Microsoft supported version of Windows. 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, at least 8 GB RAM, and an SSD.

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

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

LOGINventory Server

Hardware

• Microsoft .Net Framework 4.8 compatible PC with 4 or more logical processors
• 4 GB RAM
• 10 GB available hard disk space (preferably SSD)

Operating System

• Windows 11
• Windows 10 (x64)
• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Software

• Microsoft .NET Framework 4.8
• Visual C++ Redistributable for Visual Studio 2015-2019 x64
• Microsoft PowerShell 4.0 or later

Infrastructure

Database

The database can be located on the same machine as the LOGINventory installation, or on a different machine.

• Minimum: Microsoft SQL Server 2012 SP4 or later (all editions)
• Recommended: Microsoft SQL Server 2016 or later (all editions)
• LOGINventory Database (included): Microsoft SQL Server Express Edition 2019

PC with Portable Version

For machines running the portable LMC, the same requirements apply as for the machine running the LOGINventory installation. In addition, ports 1433 (TCP) and 1434 (UDP) on the LOGINventory machine must be open for the remote machine.

Device Accessing the Web Viewer

The Web Viewer can be accessed with any modern web browser.

Prerequisites for Agentless 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 / 2022 (all editions)
• Windows XP / Vista / Windows 7 / Windows 8.x / Windows 10 / Windows 11 (all editions except "Home")

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 or later
• XenServer 4.x or later

CPUs:

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

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.

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

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
  • These two policy changes will only become effective after a policy refresh (reboot & gpupdate /force (or after two hours))
• 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

And:

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

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.

XenServer

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.

macOS

To enable remote scanning of a device with macOS, SSH must be enabled. To do this, choose Apple > System Preferences from the Mac menu and click Sharing. Then enable "Remote Login" for the account you want to use for remote scanning.

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\LOGINventory9\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 (0.0.0.0 = all computers) may also have to be adapted.

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

Reading out Cloud Services

To read out certain online data from Microsoft (Azure) or Amazon (AWS), it is necessary to use a special authentication procedure ("Modern Authentication") instead of username and password. For this, an app registration must be created in the corresponding portal and the generated credentials must be stored in the Remote Scanner.

Configuring an App Registration with Microsoft Azure

1. Create a new App Registration

• Log in to portal.azure.com and select Microsoft Entra ID (formerly: Azure Active Directory).
• Navigate to the App registrations menu and create a New registration.
• Assign a descriptive name (e.g., "LOGINventory").

2. Create a Client Secret

• Go to the Certificates & secrets menu of the app you just created and select New client secret
• Enter a description for your key, select if or when it expires, and select Add.

• Copy the generated key, which can now be seen in the Value field on this page.
  The Secret ID is NOT required and does not need to be copied.

• Go to the Manifest option of the newly created app registration.
• Locate the section that starts with requiredResourceAccess (around line 50).
• Replace the existing section with the following lines and then save the change:

"requiredResourceAccess": [
   {
      "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
      "resourceAccess": [
         {
            "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
            "type": "Role"
         }
      ]
   }
],

• Go to the API permissions option and select Grant admin consent for ....

3. Assign Roles

• In the Microsoft Entra ID configuration, navigate to Roles and administrators and search for the Global Reader role and select it.
• Select Add assignments and search for the name of the app registration you created earlier (for example, "LOGINventory") and select it.

4. Authorization to Access the Subscription

• At portal.azure.com, select Subscriptions.
• In the list of subscriptions, select the one to which the virtual machines (VMs) in Azure are assigned.
• Select Access control (IAM).
• Select Add role assignment from the drop-down menu at Add.
• On the Role page, click in the row named Reader. The red dot next to Role will disappear and you can switch to the Members page.
• On the Members page, choose Select members and find the name of the app registration you created earlier (e.g. "LOGINventory") and select it.
• On the Review and Assign page, confirm the assignment of this app registration to the Reader role.

5. Store the Credentials in the Remote Scanner

• In the Remote Scanner, create a new account of type Azure Credentials and select Auth. Type "ClientSecret".
• For Tenant ID you have to enter the tenant ID of your Azure Active Directory (Microsoft Entra ID). You can retrieve this here, for example:
• For Client ID, the "Application (client) ID" of the previously created app registration must be entered. You can find this on the overview page of the previously created app registration:
• At Subscription ID, only something has to be entered if you want to retrieve information about virtual machines in Azure, see step 4.
  The Subscription ID can be found at portal.azure.com at Subscriptions.
• For Client Secret, enter the "Value" of the secret you created and copied in step 2.
  Reminder: You do not need the Client Secret ID, but the value!

The finished configuration looks then e.g. like this:

Now this account can be assigned to the corresponding definition and the scan can be started. The progress of the scan can be monitored in the Job Monitor.

Reading out Microsoft Online Services without App Registration

If authentication during readout is to take place using user name & password, this is only possible if multi-factor authentication (MFA) has been decativated for the user used OR the IP address of the LOGINventory computer comes from a "Trusted Location".

For Exchange Online acquisition, a user can be added to the "View-Only Organization Management" role here if the account used does not have sufficient rights.

Configuring an Access Key with AWS

To read virtual machine information on AWS, it is necessary to create an access key on AWS as described in this guide: https://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/id_credentials_access-keys.html

Specifically, this means that a new Access Key must be created at https://us-east-1.console.aws.amazon.com/iamv2/home#/security_credentials.

If an access key is created here, the Secret Access Key must now be copied and stored in the Remote Scanner at an account of type AWS Credentials together with the Access Key.

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

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 (this includes user logons)
• Hard disk data on SMART values and whether it is an SSD
• TrustedPlatformModule values

Furthermore, there is the following information that an unprivileged user can obtain only partially (e.g., the values available in the user context):

• Scheduled tasks
• SQL Server databases

For information that is only available in the user context, a cleanup function is also necessary due to this behavior. With the cleanup of obsolete data, context-related information that has not been recorded for longer than X days is deleted.

Special Considerations for Hypervisor Acquisition

There are a few special features to be aware of when capturing hypervisors (e.g. VMware ESXi, Hyper-V, XenServer).

Reading Out Information

In general, the virtual machines can be captured both directly (e.g., through the asset inventory of the corresponding IP range), and by querying the hypervisor.

If only the hypervisor is scanned, then only the host as well as all machines running at the time of the scan are created as an asset (these then have the value Stub at LastInventory.Method). This behavior can be toggled by using the command line parameter /StoppedVMs (see Switches), which results in stopped VMs also being created as assets.

Nevertheless, all information about the virtual machines (whether stopped or not) can of course be viewed in each case when double-clicking on the hypervisor under "VM Guests".

Do not Scan Certain VMs

With the help of command line parameters it can be set that certain VMs are not captured. For this purpose, the command line argument //IgnoreVMs "[Name:<NAME>][OperatingSystem:<OPERATINGSYSTEM>]" can be used in the "General" tab. Instead of <name> and <OPERATINGSYSTEM> name filters can be used using the wildcard character *.

Setting Custom Properties

If the hypervisor hosts are to be assigned a Custom Property directly during acquisition (analogous to Asset Inventory), then this is only possible by adding a corresponding command-line argument. The syntax here is ///Custom.property "value".

If a property is to be assigned to the virtual machines on the hypervisor hosts, this is done analogously with the command line argument ///Vm.Custom.Property value and is only applied if the VMs are scanned exclusively by capturing the host. If the VMs are scanned directly, ///Custom.Property must be used.

Installed Services

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

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

System Tasks

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

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

Recommended as Access Test :

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

And:

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.

Recommended Solution

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

Log Files and Event Viewer

The individual modules of LOGINventory9 write log information into the directory %ProgramData%\Login\LOGINventory\9.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.

Class Hierarchy "HardwareAsset"

In LOGINventory, both automatically scannable devices (=Entity Device) (PCs, servers, virtual machines, printers, switches, smartphones, etc.) and non-scannable devices (=Entity PeripheralDevice) (docking stations, keyboards, webcams, headsets, monitors, mice, etc.) can be managed.

Both device types are derived from the class HardwareAsset in the data model.

The HardwareAsset includes properties such as Name, Info, WarrantyStart, SerialNumber or InventoryNumber, i.e. properties that are available for both Device and PeripheralDevice.

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="http://www.loginventory.com/schemas/LOGINventory/data"

    Version="9.0"

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

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

<Device xmlns="http://www.loginventory.com/schemas/LOGINventory/data/9.0/LogInfo">

    <NAME>MyAsset8</NAME>

    <ARCHIVED></ARCHIVED>

    <DeviceInfo>

        <SERIALNUMBER>CZ3233TEYP</SERIALNUMBER>
        <ASSETTAG>Asset-CZ3233TEYP</ASSETTAG>

    </DeviceInfo>

    <NETWORK ADAPTER>

        <INTERFACEINDEX>1</INTERFACEINDEX>

        <NAME>NIC8</NAME>

        <IP>192.68.200.8</IP>

        <MAC>A0:05:CA:33:A8:AD</MAC>

    </NETWORK ADAPTER>

    <OperatingSystem>

        <NAME>Unknown OS</NAME>

        <Version>6.3</Version>

    </OperatingSystem>

</Device>

</Inventory>

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

Almost all of the above criteria are not used individually as a unique identification feature of an asset, but in combination. Under certain circumstances, however, it may be desirable to bypass or modify the fingerprint procedure.

Bypassing the Fingerprint Procedure

Bypass via CustomID

The fingerprinting procedure can be bypassed by using the CustomID. This value can either be read from the following registry value HKLM\Software\LOGIN\LOGINfo\CustomID or is set via the LOGINfo.script file, e.g..: CustomID=%$DeviceInfo.SerialNumber%.

The mentioned registry value is not available on devices by default, but can - if desired - be placed on the devices e.g. via software distribution. However, we always recommend testing the adjustments "on a small scale" beforehand to be aware of the possible effects.

Ignoring Identification Rules

Especially in cases where there are multiple devices (whether physical or virtual machines) in an infrastructure that have the same name, it may be desirable not to use the name as a fallback matching criterion.

By using the parameter IgnoreFingerPrintRules NameOnly it can be set that two devices do not overwrite each other if they only match in name.

The parameter should - like the CustomID - be used with caution as follows:

• Asset Inventory (using the Remote Scanner): Command line parameter /IgnoreFingerPrintRules NameOnly
• Running LOGINfo.exe: Command line parameter /IgnoreFingerPrintRules NameOnly
• VMware Inventory (using the Remote Scanner): Command line parameter /IgnoreFingerPrintRules NameOnly
• General disabling for all Windows, Linux and Hyper-V scans: Adding the entry !SET IgnoreFingerPrintRules=NameOnly in the LOGINfo.script file
  Note: This does not affect VMware inventory

Reading Failed Logon Attempts

Both successful and failed logins/login attempts are determined in the UserLogons entity. For Windows devices, you can see see who has logged on to this device and when. This data always comes from the Windows Event Log.

If failed logon attempts are not to be read although event log entries are available, the switch //NoFailedLogons 1 can be used when logging.

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 LOGINventory9.
• 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 scan.db are copied to the above directory;
• The "LOGINventory9" 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 scan.db are copied back from the above directory;
• The "LOGINventory9" 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.

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

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.

LOGINfo.exe

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

LOGINfoAD.exe

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:

• EntityFramework.dll
• Essential.Diagnostics.Core.dll
• Essential.Diagnostics.RollingFileTraceListener.dll
• Login.Quiry.dll
• Login.Tasks.dll
• Login.Ventory.Common.dll
• Login.Ventory.Data.dll
• LoginfoAD.exe
• LoginfoAD.exe.config

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 "my.domain.com" can be captured with the following command:

LOGINfoAD.exe !my.domain.com C:\temp

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

LOGINfoESX.exe

LOGINfoMX.exe

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

LOGINfoX.exe

Activating the Beta Mode

Selected new features are initially only available in beta mode. To activate the beta mode of your LOGINventory installation, please proceed as follows.

1. Navigate via Windows Explorer to the directory where LOGINventory has been installed, e.g. C:\Program Files\LOGIN\LOGINventory9.
2. Navigate to the subfolder Manufacturer.
3. Execute the file SetBetaMode_On.reg by double click and confirm in the next dialog that the process should be continued.
4. Start LOGINventory again