Zum Inhalt

Technische Details

Systemvoraussetzungen

Um LOGINventory installieren zu können, benötigen Sie administrative Rechte auf einer von Microsoft unterstützten Version von Windows (nur x64). Prinzipiell ist kein Windows Server-Betriebssystem notwendig, für den produktiven Betrieb aber empfohlen.

Hardware-seitig empfehlen wir mindestens vier logische Prozessoren, mindestens 8 GB RAM und die Verwendung einer SSD.

LOGINventory benötigt ein vorhandenes Microsoft .Net Framework 4.8 sowie eine Microsoft SQL Server 2012 SP4 Datenbank oder höher.

Info

Eine vorkonfigurierte Microsoft SQL Server 2019 Express Edition ist bereits im Setup von LOGINventory enthalten. Diese ist bei 1000 Assets oder weniger für den Produktiv-Betrieb geeignet.

Natürlich können auch bestehende Datenbanken benutzt werden, die diese Mindest-Anforderungen erfüllen (siehe Datenbank-Konfiguration).

LOGINventory Rechner

Hardware

  • Microsoft .Net Framework 4.8 kompatibler PC ab 4 logische Prozessoren
  • 4 GB RAM
  • 10 GB freier Festplattenspeicher (vorzugsweise SSD)

Betriebssystem

  • 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 oder später

Infrastruktur

Datenbank

Die Datenbank kann sich auf der gleichen Maschine, wie die LOGINventory-Installation befinden, oder auf einem anderen Rechner.

  • Mindestens: Microsoft SQL Server 2012 SP4 oder neuer (alle Editionen)
  • Empfohlen: Microsoft SQL Server 2016 oder neuer (alle Editionen)
  • LOGINventory Datenbank (enthalten)

Tipp

Mit einem Microsoft SQL Server 2016 oder neuer sind erhebliche Performance-Verbesserungen bei der Berechnung der Topologie zu erwarten. Dies ist insbesondere bei größeren Datenbanken relevant.

Rechner mit portablem LMC

Für Rechner, auf denen das portable LMC ausgeführt werden, soll gelten die gleichen Voraussetzungen, wie für den Rechner mit der LOGINventory-Installation. Zusätzlich müssen die Ports 1433 (TCP) und 1434 (UDP) auf dem LOGINventory-Rechner für die zugreifende Maschine geöffnet sein. Eine detaillierte Erläuterung findet sich im Helpdesk.

Gerät, auf dem der Web Viewer aufgerufen wird

Mit jedem modernen Web-Browser kann der Web Viewer aufgerufen werden.

Achtung

Falls Sie sich bei der Konfiguration der Datenbank-Verbindung auf dem LOGINventory-Rechner für "Windows Authentifizierung" anstatt "SQL Server Authentifizierung" entschieden haben, muss jedoch der User, mit dem auf den Web Viewer oder die portable Version zugegriffen werden soll, explizit im SQL Server berechtigt werden. U.a. deshalb empfehlen wir die Verwendung der "SQL Server Authentifizierung".

Voraussetzungen zur Erfassung

Auf Grund der agentenlosen Arbeitsweise lassen sich prinzipiell nur Netzwerk-Geräte erfassen, welche eine der folgenden Remote abfragbaren Schnittstellen implementiert haben:

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

Geräte, bei denen dies nicht Fall ist –  wie z.B. Fritz!Boxen, nicht managebare Switches, Windows Home Editions, Fernseher etc. – können auf diese Weise nicht erfasst werden.

Microsoft Exchange:

  • Exchange 2010, 2013, 2016, 2019 (alle Editionen)

Windows Rechner:

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

Netzwerkgeräte:

  • Alle mit SNMP v1, v2c, v3
  • Linux/Unix Derivate und MacOS mit SSH und Perl 5.8 oder später
  • VMware vCenter oder ESXi v5.x und 6.x
  • XenServer 4.x oder neuer

CPUs:

  • x86 oder x64 Intel-Architektur bei lokaler Datenakquise über LOGINfo
  • Beliebig bei Remote Datenaquise (IP-Scan)

Windows Rechner

Remote Scan

Der Remote Scan von Windows Rechnern wird in LOGINventory über eine Definition vom Typ Asset Inventarisierung konfiguriert und ausgeführt.

Achtung

Da es in Windows leider keine „ReadOnly-Admins“ gibt, muss dazu immer ein Account verwendet werden, der auf den zu erfassenden Rechnern lokale Administrator-Rechte hat. Dies ist z.B. bei einem Domain-Admin der Fall.

Info

Ein Account, der nur WMI-Rechte hat, genügt nicht, da LOGINventory noch weitere Quellen benutzt, um ein vollständiges Bild der gesamten Software, Hardware und Konfiguration zu sammeln.

Die notwendigen APIs sind in Windows Home Editionen nicht vorhanden, bei allen anderen Windows Editionen muss zumindest der Dienst „Server“, bzw. „Datei und Drucker-Freigabe“ gestartet sein und selbstverständlich darf auch keine Firewall die Kommunikation behindern.

Info

Wie Sie die Firewall richtig konfigurieren, ist ausführlich hier beschrieben.

In gleicher Domain – oder mit Trust

Der Scan innerhalb der gleichen Domain oder anderer Domains mit Vertrauensstellung (Trust) benötigt als Voraussetzung zusätzlich den Vollzugriff auf Administrative Shares (C$, Admin$, …). Alternativ muss der Dienst "Remote Registry" laufen. Achtung: Dieser Dienst steht ab Windows 10 per Default auf „Deaktiviert“.

In anderer Domain – ohne Trust

Prinzipiell funktioniert der Scan über non-trusted Domain-Grenzen nur, wenn es Vollzugriff auf Administrative Shares (C$, Admin$, …) gibt.

In Workgroup

Achtung

Wenn Sie die Fehler 1312 oder 1326 feststellen, obwohl alles korrekt konfiguriert zu sein scheint, überprüfen Sie unbedingt das Konto, das Sie für den Dienst LOGINventory9-InventoryService verwenden. Das verwendete Konto muss über Administratorrechte auf dem LOGINventory-Rechner (mit Passwort) verfügen. Verwenden Sie nicht Lokaler Dienst oder Lokales System!

Bei Workgroup-Rechnern – oder beim Erfassen mittels lokalem Konto des Remote Rechners (auch in Domains):

  • UAC-Remote muss abgeschaltet sein, also in der Registry:
    • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, LocalAccountTokenFilterPolicy (DWORD) muss auf 1 gesetzt werden.
    • Außerdem muss folgende Policy gesetzt sein (z.B. lokal über GPEDIT.EXE), die bei Domain-Mitgliedern immer so gesetzt ist:
      Computerkonfiguration / Windows-Einstellungen / Sicherheitseinstellungen / Lokale Richtlinien / Sicherheitsoptionen / Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten = Klassisch
  • Das Kennwort des Remote-Administrators darf nicht leer sein.

Verwendete Ports und Protokolle bei Remote Scan

Verwendet wird zur Erfassung TCP/IP (IPv4 oder IPv6) und:

  • ICMP Echo Request (Ping)
  • Client für Microsoft Netzwerke
    • TCP Port 139 (NetBIOS Session Services)
    • UDP Ports 137 und 138 (NetBIOS Name Server, NetBIOS Datagram)
    • TCP Ports 135 und 445 (RPC, WMI)
    • Dynamische Ports:
      • Windows Server 2008, Windows Vista und höher: TCP Ports 49152-65535
      • Windows 2000, Windows XP und Windows Server 2003: TCP Ports 1025-5000
  • UDP Port 161 (SNMP)
  • TCP/UDP Port 22 (SSH)
  • TCP/UDP Port 443 (VMware vSphere)

Die Windows Firewall-Konfiguration ist explizit unten beschrieben.

Als Zugriffstest empfohlen:

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

Und:

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

Logon Skript

Bei der Ausführung der Erfassung im Logon- oder Startup-Skript müssen auf dem jeweiligen Rechner keine weiteren Voraussetzungen erfüllt werden. Das ausführende Konto muss lediglich das Recht haben, die bei der Erfassung entstehende .INV Datei im „Datenverzeichnis“ des LOGINventory-Rechners abzulegen, also Schreibrechte auf der Freigabe und im Filesystem haben.

Wir empfehlen: Authenticated Users (= Domain User + Domain Computers) mit Schreibrechten („Change“)

Beispiel für einen Logon-Skript-Aufruf

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

Windows Offline Agent

Mit dem Offline-Agenten können die Inventardaten sowohl über http/https an einen Webserver als auch an eine Datei-Freigabe geliefert werden. Auch hier muss das verwendete Konto Schreibrechte auf der Freigabe und im Filesystem des „Datenverzeichnisses“ haben.

Damit auf einem Windows-Rechner der Offline Agent installiert werden kann, muss das .NET Framework 3.5 vorhanden sein.

Exchange Organisation

Zur Inventarisierung einer komplette Exchange Organisation dient im Remote Scanner der Definitionstyp „Microsoft Exchange Inventarisierung“. Das verwendete Konto benötigt in der Exchange Organisation die Mitgliedschaft in der Rolle „View-Only Organization Management“ oder „Organization Management“. Als Quelle müssen Sie nur einen Exchange Server aus der vorgeschlagen Liste auswählen, und zwar den mit der höchsten Version, jedoch keine Edge-Rolle. Gleichzeitig muss das Konto auf dem Exchange Server Rechner - wie stets bei Windows - lokale Administrator-Rechte besitzen.

VMware vSphere, ESXi

Für VMware ESXi und vCenter gibt es in LOGINventory den Definitions-Typ „VMware vSphere Inventarisierung“.

Das verwendete Konto benötigt hier lediglich „Nur lesen“ Rechte.

Typischerweise erhalten Sie im Job-Monitor beim Erfassen von ESXi oder vCenter eine Nachricht: „Warnung: Ungültiges SSL Zertifikat“ - und zwar dann, wenn Sie die von VMware automatisch erstellten „SelfSigned“ Zertifikate verwenden und noch keine vertrauenswürdige Zertifizierungsstelle verwendet haben. Diese Warnung beeinträchtigt die Inventarisierung nicht.

XenServer

Auch hier wird ein Konto mit Administrator-Rechten auf dem XenServer benötigt.

XenApp Server

Für den Zugriff auf die XenApp-Daten auf einem entsprechenden Windows Server muss das verwendete Konto in der Methode „XenApp Inventarisierung“ sowohl auf Windows als auch auf XenApp Administrator-Rechte besitzen. Außerdem muss auf XenApp-Rechner das Citrix XenApp PowerShell SDK installiert sein (wird in der ISO beim XenApp-Setup mitgeliefert).

Unix, Linux, MacOS

Die Erfassung dieser Systeme mittels „Asset Inventarisierung“ geschieht über eine Secure Shell Verbindung, über die das Erfassungs-Skript und die Ergebnisdaten übertragen werden. Die Voraussetzungen dafür sind generell:

  • Installation/Aktivierung des SSH-Daemon (inklusive Freigabe des Port 22)
  • Konto mit sudo- oder wheel-Rechten (nur damit können Hardware-Informationen gelesen werden)
  • Programmpaket Perl (ab Version 5.8)
  • Notwendige vorhandene Kommandos:

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

Die Authentifizierung des Benutzers für SSH erfolgt alternativ über Benutzername und Passwort oder Benutzername und Schlüsseldatei sowie Passphrase. Bei manchen Systemen muss die Passwort-Authentifizierung extra freigeschaltet werden, die Authentifizierung über Schlüsseldatei mit Passphrase ist prinzipiell immer möglich. Die Schlüssel-Datei muss dabei im OpenSSH-Format vorliegen, da SSH.NET verwendet wird. PPK-Keys von PuTTY können in dieses Format konvertiert werden.

Info

Die folgenden Module werden zwingend zur Erfassung benötigt:
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))
Die folgenden Module sind empfohlen:
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 mit OS X

Der SSH-Daemon ist per Default aktiviert. In der Datei /etc/ssh/sshd_config muss ggf. der Eintrag für PasswordAuthentication aktiviert und auf den Wert yes gestellt werden. Nach einer Änderung ist ein Restart des Systems oder ein Neustart des Daemons nicht notwendig.

SuSe Linux

Zur SSH-Aktivierung müssen folgende Aktionen durchgeführt werden:

  • NetServices: sshd enable
  • Firewall / Service / SSH-Daemon freigeben

Zur Passwort-Authentifizierung muss in der Datei /etc/ssh/sshd_config der Eintrag geändert werden: PasswordAuthentication no -> yes

Nach einer Änderung ist ein Restart des Systems oder ein Neustart des Daemons notwendig.

Ubuntu Linux

Die Aktivierung des SSH-Daemon muss explizit wie folgt durchgeführt werden:

sudo apt-get install openssh-server

Die Passwort-Authentifizierung ist hier per Default aktiviert.

Red Hat Linux, CentOS

Der SSH-Daemon und die Passwort-Authentifizierung sind hier per Default aktiviert.

Oracle Solaris

Der SSH-Daemon und die Passwort-Authentifizierung sind hier per Default bereits aktiviert. Für die Benutzung der Benutzerkennung »root« muss jedoch die Konfiguration des SSH-Daemon angepasst werden:

  • In der Datei /etc/ssh/sshd_config muss der Eintrag für PermitRootLogin auf den Wert yes gestellt werden
  • In der Datei /etc/default/login muss der Eintrag für CONSOLE auskommentiert werden: #CONSOLE=/dev/console
  • In der Datei /etc/user_attr muss der Eintrag ;type=role aus dem ‚root‘-Eintrag entfernt werden. Dies kann durch folgendes Kommando erfolgen: rolemod –K type=normal root
  • Nun muss der SSH-Daemon neu gestartet werden: svcadm restart svc:/network/ssh:default

Fehlersuche beim Scannen von Unix, MacOS und Linux

Falls die Erfassung dieser Geräte nicht erfolgreich ist und die Gründe dafür unbekannt sind, kann mit Hilfe eines Dialogfensters auf Fehlersuche gegangen werden. Dieses Fenster lässt sich öffnen, indem im Knoten Fehlerhafte Inventarisierung die Eigene Aktion "SSH Test" für ein fehlerhaft inventarisiertes Asset aufgerufen wird oder durch Auswahl von "SSH Problembehandlung" im Job Monitor. Öffnen lässt sich das Fenster auch direkt über den Befehl %ProgramFiles%\LOGIN\LOGINventory9\LOGINfoX.exe /w.

In dem sich öffnenden Dialog können dann verschiedene Benutzernamen, Passwörter, Schlüsseldateien, Ports, Timeouts, etc. getestet werden. Anhand der Meldungen ist direkt ersichtlich, inwiefern die Inventarisierung mit diesen Werten und Parametern erfolgreich ist. Wenn die Inventarisierung erfolgreich war, wird der Ergebniscode 20300 ausgegeben.

Drucker, Router, Switches

Diese Geräte werden üblicherweise über die Asset Inventarisierung mittels SNMP v1, v2c oder v3 erfasst. Die SNMP v1/v2c API ist standardmäßig in Windows vorhanden und funktioniert ohne weitere Konfigurationsschritte. Die meisten Drucker haben einen SNMP v1/v2c ReadOnly-Community-String „public“ voreingestellt, mit dessen Verwendung sich die Konfiguration einfach auslesen lässt.

Bei Routern und Switches ist dies meist nicht der Fall und muss dann manuell konfiguriert werden. Wir empfehlen die Verwendung unterschiedlicher Community-Strings, um beim Erfassen bestimmte Geräte-Typen zu selektieren. Angepasst werden müssen eventuell auch die Default View (sollte die OID 1 sein) sowie die IP der zulässigen Management Station(s), also des LOGINventory-Rechners (0.0.0.0 = alle Rechner).

Soll SNMP v3 benutzt werden, kann ein Benutzerkonto vom Typ NetSNMP Credentials dafür verwendet werden. Wie Sie generell die SNMP-Verbindung testen können, ist im Helpdesk beschrieben.

Info

Damit ein Gerät durch LOGINventory via SNMP erfasst werden kann, muss das Gerät snmpwalk unterstützen. Die alleinige Unterstützung von snmpget-Befehlen genügt nicht. Bei der Erfassung liest LOGINventory Werte entsprechend der Standard MIB-2; zumindest erwartet werden Werte bei "MIB-2.system" (OID: 1.3.6.1.1). Private Enterprise MIBs werden prinzipiell nicht verwendet. Durch Anpassung der LOGINfo.script-Datei lassen sich aber weitere OIDs auslesen.

Microsoft Online-Dienste

Für die Erfassung von Microsoft Online-Diensten (Microsoft Cloud Subscriptions & Online Exchange Erfassung) muss der User-Name jeweils in UPN-Form angegeben werden z.B. name@domain.com angegeben werden, eine Verwendung von domain\name wird nicht funktionieren!

Wenn eine Azure Active Directory Synchronisierung (AAD-Sync) mit den Default-Einstellungen eingericht wurde, sind alle Domain-User berechtigt die entsprechenden Daten auszulesen. Ansonsten kann für die Online Exchange Erfassung hier ein User zur Rolle "View-Only Organization Management" hinzugefügt werden. Für die Microsoft Cloud Subscriptions benötigt ein User ansonsten die Rolle "Globaler Leser". Diese Einstellung kann hier vorgenommen werden.

Achtung

Wenn für den Zugriff eine Mehrstufige- / 2-Faktor- (2FA) / Multifaktor- (MFA) -Authtentifizierung verwenden wird, dann muss eine Ausnahme bzgl. vertrauenswürdiger IP-Adresse hinzugefügt werden, für die die mehrstufige Authentifizierung nicht nötig ist. Dies ist über diesen Link möglich: https://account.activedirectory.windowsazure.com/usermanagement/mfasettings.aspx Zuvor muss allerdings ein "Benannter Standort" angelegt worden sein. Dies ist über diesen Link möglich (falls noch nicht geschehen): https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/NamedLocations

Unterschiede zwischen den Erfassungsmethoden

Je nachdem, ob die Erfassung eines Windows-Geräts mit einem privilegiertem User (lokaler Administrator) oder unprivilegiertem User, bzw. remote oder lokal durchgeführt wird, stehen teilweise unterschiedliche Daten zur Verfügung. Zu ca. 99 % sind die Daten jedoch identisch.

Remote Lokal
Rechte des scannenden / ausführenden Nutzers immer privilegiert nur privilegiert, wenn ausführender Nutzer lokaler Administrator ist
Zusätzlich erfasste Daten im Benutzerprofil
  • verbundene Netzlaufwerke (Entität: NetworkDrive)
  • vorhandene Netzwerk-Drucker
  • installierte Software-Pakete
  • installierte App-Pakete

Nur beim Ausnahmefall, wenn der remote-scannede User dem aktuell angemeldeten User des zu scannenden Geräts entspricht, werden auch die verbundenen Netzlaufwerke beim Remote-Scan miterfasst.

Der unprivilegierte Scan unterscheidet sich vom privilegiertem Scan durch den fehlenden Zugriff auf bestimmte Informationen:

  • Verschlüsselungsstatus der Partitionen (Bitlocker)
  • Einträge aus dem Security-Eventlog (dazu zählen User-Logons)
  • Festplatten-Daten zu SMART-Werten und, ob es sich um eine SSD handelt
  • TrustedPlatformModule-Werte

Weiterhin gibt es folgende Informationen, die ein unprivilegierter Nutzer jeweils nur teilweise (z.B. die im User-Kontext vorhandenen Werte) ermitteln kann:

  • Geplante Tasks
  • SQL Server Datenbanken

Wichtig

Wenn die Erfassung nicht ausschließlich in einem Kontext läuft (z.B. nur agentenloser Scan), sondern mal mit privilegierten, mal mit unprivilegierten Rechten erfasst wird, käme es zu vielen Änderungen in der Änderungshistorie. Um dieses Verhalten zu unterbinden, werden standardmäßig die Informationen, die für unprivilegierte Nutzer nur teilweise zur Verfügung stehen, nicht erfasst. Dieses Verhalten lässt sich durch Verwendung des Kommandozeilen-Parameters //ForceAllPossibleData 1 ändern, sodass auch die nicht vollständigen Informationen im unprivilegiertem Kontext gesammelt werden.
Dieser Parameter sollte also nur verwendet werden, wenn ausschließlich im unprivilegiertem Kontext (also z.B. ausschließlich Ausführen der LOGINfo.exe im Logon-Skript) erfasst wird.
Der Kommandozeilen-Parameter //ScanSqlServerDatabases 1 sorgt dafür, dass auch durch die Asset-Inventarisierung (bzw. Ausführen der LOGINfo.exe) die (unvollständigen) Informationen zu SQL-Server-Datenbanken erfasst werden. Die vollständigen Informationen stehen durch das Ausführen einer SQL-Server-Inventarisierung zur Verfügung.

Für Informationen, die nur im User-Kontext zur Verfügung stehen, ist auf Grund dieses Verhaltens auch eine Bereinigungsfunktion notwendig. Mit der Bereinigung der Veralteten Daten, werden also Kontext-bezogenen Informationen gelöscht, die länger als X Tage nicht mehr erfasst wurden.

Beispiel

In einem Netzwerk werden Windows-Geräte sowohl durch den Remote-Scanner, als auch durch das Ausführen der LOGINfo.exe im Logon-Skript erfasst. User A meldet sich an seinem Gerät an, woraufhin die unprivilegierte Erfassung im Logon-Skript ausgeführt wird und u.a. die Liste der im Kontext dieses Users installierten Software-Pakete ermittelt wird. Im nächsten Monat meldet sich ausschließlich User B an diesem Gerät an, woraufhin die Daten zu der im Kontext für User A installierte Software nicht mehr ermittelt werden. Wenn in den Einstellungen der Grenzwert für die Bereinigung der veralteten Daten auf 30 Tage gestellt wurde, werden also nach 31 Tagen die Daten zu den im Kontext von User A installierter Software entfernt. Dies hätte verhindert werden können, wenn zwischenzeitlich erneut eine Erfassung im Kontext von User A geschehen wäre.

Info

Der Offline Agent legt zwei Scheduled Tasks an: Eine im Benutzer-Kontext, eine im System-Kontext. Damit werden die Daten mindestens einmal privilegiert erfasst, wodurch ein vollständiges Abbild des Rechners erreicht wird.

Fazit

Zusammenfassend lässt sich also sagen, dass beim agentenlosen Scan prinzipiell alle Daten, bis auf die verbundenen Netzlaufwerke erfasst werden, wohingegen beim lokalen Ausführen der LOGINfo.exe (z.B. im Logon-Skript) bestimmte besonders schützenswerte Informationen nicht zur Verfügung stehen. Durch die Kombination aus beiden Erfassungsmethoden werden die erfassten Daten jedoch zusammengeführt.

Besonderheiten bei der Hypervisor-Erfassung

Bei der Hypervisor-Erfassung (z.B. VMware ESXi, Hyper-V, XenServer) gibt es ein paar Besonderheiten zu beachten.

Auslesen von Informationen

Generell gilt: Die virtuellen Maschinen können sowohl direkt (z.B. durch die Asset-Inventarisierung des entsprechenden IP-Bereichs), als auch durch Abfrage des Hypervisors erfasst werden.

Info

Für die Erfassung von Hyper-V-Maschinen gibt es im Remote-Scanner keinen speziellen Definitions-Typ. Hyper-V-Maschinen werden automatisch bei der Asset-Inventarisierung mit-ausgelesen.

Achtung

Über die Hypervisor-Inventarisierung werden zwar Hosts und VMs als Assets angelegt, allerdings werden bei der Erfassung nur die Daten gesammelt, die der Host über seine VMs hat. Das bedeutet, dass virtuelle Maschinen, die einzig und allein über die Hypervisor-Inventarisierung erfasst wurden, unvollständige Informationen aufweisen (z.B. keine Informationen über installierte Software, Hardware, etc.). Daher sollten alle virtuellen Maschinen zusätzlich stets über eine Definition vom Typ Asset Inventarisierung erfasst werden (indem z.B. der betreffende IP-Bereich mit den VMs gescannt wird). Unvollständig erfasste Geräte können am Eintrag Stub bei LastInventory.Method erkannt werden.

Wenn nur der Hypervisor gescannt wird, dann wird nur dieser als Asset angelegt, sowie alle zum Scan-Zeitpunkt laufenden Maschinen ebenfalls als Asset (diese haben bei LastInventory.Method dann der Wert Stub). Dieses Verhalten lässt sich durch Verwendung des Kommandozeilen-Parameters /StoppedVMs (siehe Schalter) umschalten, was zur Folge hat, dass auch gestoppte VMs als Asset angelegt werden.

Trotzdem können natürlich in jedem Fall bei Doppelklick auf den Hypervisor unter "VM-Gäste" jeweils alle Informationen zu den virtuellen Maschinen (egal ob gestoppt oder nicht) betrachtet werden.

Bestimmte VMs nicht erfassen

Mit Hilfe von Kommandozeilen-Parametern kann eingestellt werden, dass bestimmte VMs nicht erfasst werden.
Dazu kann im Reiter "Allgemein" das Kommandozeilen-Argument //IgnoreVMs "[Name:<NAME>][OperatingSystem:<OPERATINGSYSTEM>]" verwendet werden. Anstelle von <Name> und <OPERATINGSYSTEM> können Namens-Filter unter Verwendung des Wildcard-Zeichens * verwendet werden.

Beispiele

Um keine VMs mehr als Stub zu erfassen, deren Betriebssystem-Name "Linux" enthält, kann folgendes Argument verwendet werden: //IgnoreVMs "[OperatingSystem:*Linux*]"
Um keine VMs mehr zu erfassen, deren Name mit "VT" beginnt, kann folgendes Argument verwendet werden: //IgnoreVMs "[Name:VT*]
Um keine VMs mehr als Stub zu erfassen, deren Betriebssystem-Name "Linux" oder "Mac" enthält, kann folgendes Argument verwendet werden: //IgnoreVMs "[OperatingSystem:*Linux*,*Mac*]"
Um keine VMs mehr als Stub zu erfassen, deren Betriebssystem-Name "Linux" oder "Windows" enthält, oder deren Name mit "A" beginnt, kann folgendes Argument verwendet werden: //IgnoreVMs "[Name:A*][OperatingSystem:*Linux*,*Windows*]" Dieser Parameter gilt sowohl für die Erfassung von VMs auf VMware (Definitions-Typ: VMware vSphere Inventarisierung, auf XenServern (Definitions-Typ: XenServer Inventarisierung) als auch auf Hyper-V (Definitions-Typ: Asset-Inventarisierung).

Setzen von Eigenen Eigenschaften

Falls den Hypervisor-Hosts bei der Erfassung direkt eine Eigene Eigenschaft mitgegeben werden soll (analog zur Asset-Inventarisierung), dann ist dies ausschließlich durch Hinzufügen eines entsprechenden Kommandozeilen-Arguments möglich. Die Syntax hierbei lautet ///Custom.Eigenschaft "Wert".

Beispiel

So wird also mit dem Argument ///Custom.Stockwerk "3.OG" eine Eigenschaft "Stockwerk" mit dem Wert "3.OG" für alle erfassten Hypervisor-Hosts angelegt.

Falls den virtuellen Maschinen auf den Hypervisor-Hosts eine Eigenschaft zugewiesen werden soll, geht das analog mit dem Kommandozeilenargument ///Vm.Custom.Property Wert und findet nur Anwendung, wenn die VMs ausschließlich durch die Erfassung des Hosts gescannt werden. Wenn die VMs direkt gescannt werden, muss mittels ///Custom.Eigenschaft gearbeitet werden.

Installierte Dienste

Bei der Installation von LOGINventory werden verschiedene Dienste mitinstalliert, die unterschiedliche Funktionalitäten bieten.

Dienstname Beschreibung
LOGINventory9 Inventory Service Dieser Dienst startet die agentenlose Erfassung der Geräte. Er stellt unter anderem sicher, dass die Inventarisierung durchgeführt wird, auch wenn LOGINventory nicht gestartet ist.
LOGINventory9 Data Service Dieser Dienst überwacht das Datenverzeichnis und verarbeitet alle dort abgelegten .inv-Dateien. Dieser Dienst muss also laufen, damit alle neu erfassten Geräte auch in die Datenbank eingetragen werden und damit für Auswertungen zur Verfügung stehen. Falls mehrere Mandanten angelegt wurden, überwacht dieser Dienst auch die unterschiedlichen Datenverzeichnisse und trägt die Daten jeweils in die korrekte Datenbank ein.
LOGINventory9 Automation Service Dieser Dienst führt alle Aufgaben und Benachrichtigungen sowie die Berechnung im Lizenzmanagement durch und stellt somit sicher, dass E-Mails versendet und Exporte und Berichte an den vorher definierten Orten abgelegt werden.
SQL Server (LOGINVENTORY) Dieser Dienst stellt die SQL Server Instanz für LOGINventory bereit.

Falls mehrere Mandanten angelegt werden, werden auch zusätzliche Instanzen der Dienste LOGINventory9 Inventory Service und LOGINventory9 Automation Service angelegt, die jeweils für einen Mandanten gelten. Diese managen dementsprechend die Erfassung und die Durchführung der Tasks.

Problembehandlung bei nicht-startenden Diensten

Falls sich die Dienste Inventory Service und/ oder Automation Service nicht starten lassen, liegt das sehr wahrscheinlich daran, dass die verwendeten Konten, unter denen die Dienste laufen, keinen Datenbank-Zugriff haben.
Stellen Sie in diesem Fall durch Aufruf der "services.msc" sicher, dass die Konten Datenbank-Zugriff haben! Datenbank-Zugriff ist z.B. standardmäßig nicht gegeben, falls sich die Datenbank auf einer anderen Maschine befindet und keine SQL-Server-Authentifizierung, sondern Windows-Authentifizierung verwendet wird!
In der LOGINventory-Ereignisanzeige finden Sie beim nicht-erfolgreichen Start detaillierte Fehlermeldungen, die Auskunft über die Ursache geben.
Eine detaillierte Erläuterung zur Konfiguration der Dienste ist im Helpdesk zu finden.

System-Tasks

Um verschiedene Berechnungen / Optimierungen durchzuführen werden folgende Systemtasks automatisch gestartet:

Name Beschreibung Uhrzeit
DataCleanup Automatische Datenbereinigung, falls der entsprechende Haken in den Einstellungen gesetzt wurde 01:00 Uhr
RebuildSharedFolder Automatische Neu-Berechnung der effektiven Zugriffsrechte auf freigegebene Ordner für die einzelnen User 03:00 Uhr
ReorganizeIndices Generieren von Indizes in der Datenbank, um die Performance zu erhöhen 04:00 Uhr
UpdateVendorWarranty Automatisches Aktualisieren der Garantie-Daten Zufällige Uhrzeit zwischen 05:00 Uhr und 07:00 Uhr

Zusätzlich gibt es noch eine spezielle Task (keine System-Task): Die Berechnung des Lizenzstatus der Produkte im Lizenzmanagement. Die zugehörige Task befindet sich auf dem Lizenzmanagement-Knoten und kann editiert werden, sodass die Berechnung zu einer anderen Zeit durchgeführt werden kann, als die Standard-Einstellung 02:00 Uhr.

Windows Firewall-Konfiguration

Achtung

Grundvoraussetzung für die Erfassung von Remote-Windows-Rechnern: Der Dienst "Server" ("LanmanServer") muss laufen und Zugriff auf administrative Shares (z.B. IPC$, Admin$, C$) muss gegeben sein.

Verwendete Ports

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

  • Windows Server 2008, Windows Vista und höher: TCP Ports 49152-65535
  • Windows 2000, Windows XP und Windows Server 2003: TCP Ports 1025-5000

Info

Falls Sie die Windows Firewall verwenden können Sie Windows Management Instrumentation (WMI) in den Firewall-Einstellungen freigeben, dann werden alle benötigten Ports automatisch geöffnet.

Als Zugriffstest empfohlen:

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

Und:

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

Falls es Probleme bei der Erfassung gibt, empfehlen wir an einem zu scannenden Rechner testweise die Firewall im aktiven Profil abzuschalten und dann den Scan noch einmal laufen zu lassen. Das Deaktivieren der Windows Firewall ist über die Systemsteuerung möglich.

Falls dann das Problem bei der Erfassung behoben ist, sollte die Firewall für alle Rechner dementsprechend konfiguriert werden.

Einfachste Lösung

Über Gruppenrichtlinien kann die Firewall im Domänennetzwerk für alle Rechner deaktiviert werden.

Empfohlene Lösung

Auf allen zu scannenden Rechnern können (manuell oder über Gruppenrichtlinien) entsprechende Regeln definiert werden, die die für den Scan benötigten Verbindungen vom LOGINventory-Server (bzw. für das ganze Server-Subnetz) aus zulassen.

Diese Regel können dadurch hinterlegt werden, dass Sie die Erweiterte Einstellungen der Firewall öffnen:

  • Neue Eingehende Regel definieren

  • Benutzerdefiniert auswählen; Weiter

  • Alle Programme auswählen; Weiter

  • Protokolltyp: Alle auswählen; Weiter

  • Für welche lokalen IP-Adressen gilt diese Regel? Beliebige IP-Adresse (default)
  • Für welche Remote-IP-Adressen gilt diese Regel? Diese IP-Adressen: hier geben Sie die Adresse (oder das Subnet) des LOGINventory Rechners an, z.B.: 192.168.169.170 oder 192.168.169.0/24
  • Verbindung zulassen wählen
  • Im nächsten Schritt Haken beim Profil Domäne setzen
  • Zuletzt muss noch ein Name für die Regel festgelegt werden, z.B.: LOGINventory zulassen

Dies können Sie natürlich auch als Gruppenrichtlinie in der Domain festlegen. Dazu müssen Sie zuerst z.B. auf einem Domain Controller:

  • Gruppenrichtlinienverwaltung öffnen
  • In die gewüschte OU navigieren
  • Gruppenrichtlinienobjekt hier erstellen und verknüpfen (Name z.B. "Firewall") und dieses dann bearbeiten:
  • Navigieren Sie zu Computerkonfiguration / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen /Windows-Firewall / Windows-Firewall / Eingehende Regeln und wählen Sie Neue Regel.

Das weitere Vorgehen entspricht dann dem am Anfang dieses Kapitels beschriebenen Ablauf.

Fallback-Methode

Als Fallback-Methode, falls administrative Shares nicht verfügbar sind, können auch über die Remote-Registry Daten erfasst werden. Dazu muss der Dienst "Remoteregistrierung" ("RemoteRegistry") beim Starttyp auf Automatisch oder Manuell gestellt werden.

Dies kann auch zentral über Gruppenrichtlinien unter Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Systemdienste geschehen.

Info

Diese Methode setzt eine funktionierende Vertrauensstellung (Trust) zwischen zu scannenden Rechner und LOGINventory-Rechner vorraus.

Log-Dateien und Ereignisanzeige

Die einzelnen Module von LOGINventory9 schreiben Log-Informationen in das Verzeichnis %ProgramData%\Login\LOGINventory\9.0.

Über das LOGINventory Data Service Icon in der Taskleiste und über das Ribbon-Menü von LOGINventory unter Extras lässt sich die LOGINventory Ereignisanzeige starten. Diese beinhaltet ebenso Informationen über den Programmablauf von LOGINventory und kann wertvolle Rückschlüsse auf Fehlerquellen liefern.

Aufbau von .inv-Dateien

Die erfassten Daten eines Assets werden in .inv-Dateien gespeichert und dann in die hinterlegte Datenbank eingetragen. Eine .inv-Datei ist dabei im Prinzip eine verschlüsselte .xml-Datei. Diese Dateien lassen sich auch selbst erzeugen um beispielsweise mit einem externen Tool Daten in LOGINventory zu schreiben. Dazu kann eine .xml-Datei erstellt und diese dann in .inv umbenannt werden, also z.B. test.inv. Wenn diese Datei ins Datenverzeichnis verschoben wird, wird sie automatisch in die Datenbank eingetragen und in LOGINventory wird ein neues Asset angelegt.

Eine .inv-Datei kann exemplarisch wie folgt aussehen.

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

    <NETWORKADAPTER>

        <INTERFACEINDEX>1</INTERFACEINDEX>

        <NAME>NIC8</NAME>

        <IP>192.68.200.8</IP>

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

    </NETWORKADAPTER>

    <OperatingSystem>

        <NAME>Unknown OS</NAME>

        <Version>6.3</Version>

    </OperatingSystem>

</Device>

</Inventory>

Identifikation von Assets mittels Fingerprint

Die Identifizierung der Assets basiert auf einem Fingerprint, der genutzt wird, um zu erkennen, ob es sich um ein bestehendes oder ein bisher nicht erfasstes (= neues) Asset handelt. Dieser Fingerprint ist aus einer Reihe von Device-Eigenschaften (falls vorhanden) zusammengestellt:

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

Fast alle genannten Kriterien werden nicht einzeln als eindeutiges Identifikations-Merkmal eines Assets genutzt, sondern in Kombination. Unter gewissen Voraussetzungen kann es jedoch gewünscht sein, das Fingerprint-Verfahren zum umgehen oder abzuändern.

Umgehen des Fingerprint-Verfahrens

Info

Das Umgehen der Fingerprint-Methode kann gewünscht sein, wenn an Hand der bei der Erfassung gesammelten Informationen nicht erkannt wird, dass es sich bei zwei Erfassungsständen um das gleiche Gerät handelt oder wenn die gesammelten Informationen von zwei Geräten so ähnlich sind, dass diese fälschlicherweise für das selbe Asset gehalten werden.

Umgehen via CustomID

Das Fingerprint-Verfahren lässt sich dadurch umgehen, dass der Wert CustomID vorhanden ist. Dieser Wert kann entweder folgendem Registry-Wert gelesen werden HKLM\Software\LOGIN\LOGINfo\CustomID oder über die Datei LOGINfo.script gesetzt werden, z.B.: CustomID=%$DeviceInfo.SerialNumber%.

Der erwähnte Registry-Wert ist nicht standardmäßig auf Geräten vorhanden, sondern kann - falls gewünscht - z.B. via Software-Verteilung auf die Geräte gebracht werden. Wir empfehlen jedoch zuvor immer das Testen der Anpassungen "im Kleinen", um sich der möglichen Auswirkungen bewusst zu werden.

Hinweis

Falls die CustomID bei einem bereits in LOGINventory vorhandenem Asset gesetzt oder verändert wird, so entsteht dadurch im Umkehrschluss ein weiteres Asset.

Ignorieren von Identifikations-Regeln

Inbesondere in Fällen, in denen es in einer Infrastruktur mehrere Geräte (egal ob physische oder virtuelle Maschinen) gibt, die den gleichen Namen tragen, kann es gewünscht sein, dass der Name nicht als Fallback-Matching-Kriterium verwendet wird.

Info

Im Fingerprint ist eine der letzten Regeln, um ein Gerät eindeutig zu erkennen, dass der ausgelesene Name übereinstimmt. Dies hat z.B. auch beim CSV-Import seine Relevanz (auch dieser verwendet den Fingerprint) und erlaubt es so aus einer csv-Datei, in welcher nur Name und einzulesende Eigene Eigenschaften enthalten sind, trotzdem ein Matching zum bestehenden Asset zu generieren.

Durch die Verwendung des Parameters IgnoreFingerPrintRules NameOnly kann eingestellt werden, dass es bei zwei Geräten nicht zum gegenseitigen Überschreiben kommt, wenn diese nur im Namen übereinstimmen.

Der Parameter sollte - ebenso wie die CustomID - mit Vorsicht wie folgt verwendet werden:

  • Asset-Inventarisierung im Remote Scanner: Verwenden des Kommandozeilen-Arguments /IgnoreFingerPrintRules NameOnly
  • Ausführen der LOGINfo.exe: Verwenden des Kommandozeilen-Arguments /IgnoreFingerPrintRules NameOnly
  • VMware-Inventarisierung im Remote Scanner: Verwenden des Kommandozeilen-Arguments /IgnoreFingerPrintRules NameOnly
  • Generelles Ausschalten für alle Windows-, Linux- und Hyper-V-Scans: Hinzufügen des Eintrags !SET IgnoreFingerPrintRules=NameOnly in der LOGINfo.script-Datei
    Achtung: Dies betrifft nicht die VMware-Inventarisierung

Beispiel

In einer Nicht-Domain-Umgebung befinden sich auf zwei verschiedenen ESXi-Hosts (Host1 und Host2) jeweils eine VM mit dem Namen WindowsVirtuell. Die beiden VMs unterscheiden sich zwar in der DNS-Endung, trotzdem kommt es in LOGINventory permanent dazu, dass sich die Geräte überschreiben. Dies ist in der Änderungshistorie des Assets sichtbar: IP-Adresse, MAC-Adresse und andere Werte ändern sich mit jedem Scan.
Wenn jetzt sowohl bei der VMware-Inventarisierung (Scan des Hosts und der dem Host bekannten Infos des Gastes) und der Asset-Inventarisierung (Scan der Software, Konfiguration, etc. der VM) mit dem IP-Bereich, in welchem sich die virtuellen Maschinen befinden das Kommandozeilen-Argument /IgnoreFingerPrintRules NameOnly hinzugefügt wird, kommt es bei erneuten Scans nicht mehr zum gegenseitigen Überschreiben.

Backup / Restore

Generell empfehlen wir stets, die LOGINventory Installation auf einem Windows Server Betriebssystem durchzuführen und die normale tägliche Datensicherung auch hier zu verwenden. In Ausnahmefällen kann die Installation aber auch auf einem Desktop Betriebssystem durchgeführt werden; für diese steht aber normalerweise kein Datensicherungs-Mechanismus zur Verfügung. Für solche Ausnahmefälle, in denen gar kein Backup-Verfahren zur Verfügung steht, liefern wir zwei Batch Dateien mit: Backup-LIV.bat und Restore-LIV.bat. Diese Dateien befinden sich im Unterordner "Resources" im LOGINventory-Installationsverzeichnis. Mit Hilfe dieser Dateien kann eine einfache Datensicherung der LOGINventory Datenbank, Konfiguration und Scandefinitionen durchgeführt werden, falls folgende Voraussetzungen erfüllt sind:

  • Es wird die mitgelieferte lokale Datenbank in der Instanz „LOGINventory“ benutzt
  • Der Name der Datenbank lautet LOGINventory9
  • Der ausführende Benutzer ist lokaler Administrator

Die Datei Backup-LIV.bat führt dann folgendes aus:

  • Abfrage des Verzeichnisses, in das gesichert werden soll;
  • Die zentralen Konfigurationsdateien LOGINventory.Config und Scandb.sdf werden in das o.a. Verzeichnis kopiert;
  • Die Datenbank „LOGINventory9“ aus der Instanz „LOGINVENTORY“ wird in das o.a. Verzeichnis gesichert.

Die Datei Restore-LIV.bat führt dann folgendes aus:

  • Abfrage des Verzeichnisses, in dem die gesicherten Daten liegen;
  • Die zentralen Konfigurationsdateien LOGINventory.Config und Scandb.sdf werden aus dem o.a. Verzeichnis zurück kopiert;
  • Die Datenbank „LOGINventory9“ aus der Instanz „LOGINVENTORY“ wird aus dem o.a. Verzeichnis restauriert.

Erweiterte Erfassung mittels Kommandozeile

Wenn mittels Remote-Scanner erfasst wird, wird von der GUI aus, abhängig vom Definitions-Typ, eine entsprechende .exe-Datei aufgerufen, die die eigentliche Erfassung durchführt, woraufhin eine .inv-Datei entsteht, in der sich die gesammelten Informationen befinden. Diese .exe-Dateien lassen sich - unter Verwendung der richtigen Parameter - auch direkt über die Kommandozeile oder innerhalb eines Skripts aufrufen.

Tipp

Die Erfassung mittels Kommandozeile kann z.B. beim Scannen von Kunden-Netzwerken, in denen nichts installiert werden soll oder bei der Inventarisierung einer "fremden" Domain, also ohne Trust und DNS-Integration - z.B. durch Dienstleister, der dies per VPN-Einwahl oder mittels Laptop vor Ort durchführen möchte, interessant sein und bietet hier einige Vorteile gegenüber der Verwendung mittels Remote-Scanner-GUI.

Die für die Erfassung relevanten .exe-Dateien befinden sich im LOGINventory-Programmverzeichnis (standardmäßig C:\Program Files\LOGIN\LOGINventory9).

Scan-Definition Programm Relevanter Übergabeparameter
Asset Inventarisierung LOGINfo.exe, LOGINfoX.exe -
Active Directory Attribute Lookup LOGINfoAD.exe -
MS Exchange Inventarisierung LOGINfoMX.exe -
VMware vSphere Inventarisierung LOGINfoESX.exe -
XenApp Inventarisierung LOGINfoMX.exe /XenApp
XenServer Inventarisierung LOGINfoESX.exe /XenServer
SQL Server Inventarisierung LOGINfoESX.exe /SqlServer
Microsoft 365 Subscriptions LOGINfoMX.exe /AzureAD

Dabei gilt folgende Syntax für die Angabe weiterer Parameter:

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

Via ! wird also immer das zu erfassende Gerät mittels FQDN oder IP angegeben - dabei ist zu beachten, dass es nicht zu "conflicting credentials" kommt. Im danach angegebenen Pfad [DataDir] wird die entstehende .inv-Datei abgelegt, die Erfassung wird mit dem bei /USER angegebenen Nutzer ausgeführt und die danach zusätzlich angegeben Parameter beeinflussen die Erfassung zusätzlich.

Beispiel

So wird die Erfassung eines XenServers namens "XenServ01" über folgenden Befehl gestartet und die entstehende inv-Datei im Verzeichnis "C:\Temp" abgelegt:
LOGINfoESX.exe !XenServ01 C:\Temp /XenServer

LOGINfo.exe

Die Verwendung der LOGINfo.exe ist hier bereits ausführlich beschrieben. Die weiteren verfügbaren Schalter werden ebenfalls dort erklärt.

LOGINfoAD.exe

Für die Stand-Alone-Ausführung der AD-Erfassung müssen zusätzliche Dateien aus dem Programmverzeichnis in das Verzeichnis mit der LOGINfoAD.exe kopiert werden:

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

Durch einen Aufruf der LOGINfoAD.exe wird der Lookup auf diejenige Domain ausgeführt, an die der aktuelle Benutzer angemeldet ist und die resultierenden .inv-Dateien in das gleiche Verzeichnis geschrieben. LOGINfoAD kann prinzipiell nur auf einem Rechner ausgeführt werden, der Domain-Mitglied bei der zu erfassenden Domain ist, oder dazu eine Vertrauensstellung verwenden kann.

So kann die Domain "meine.domain.com" mit dem folgenden Befehl erfasst werden:

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

Alternativ kann hinter dem ! auch direkt ein Domain-Controller angegeben werden.

LOGINfoESX.exe

Parameter Erklärung
/AllowVmNameSpaces Schneidet Namen von virtuellen Maschinen nicht nach dem ersten Leerzeichen ab, sondern erlaubt, dass sich Leerzeichen im Namen der virtuellen Maschine befinden. Achtung: Wenn dieser Switch verwendet wird und die virtuelle Maschine explizit gescannt wird (keine Leerzeichen im Namen erlaubt), kann es zu Duplikaten in der Assets-Liste führen.
/DontIgnoreInvalidCertificate Falls kein gültiges SSL-Zertifikat gefunden wird, wird standardmäßig die Erfassung trotzdem ausgeführt. Mit diesem Parameter lässt sich dies verhindern.
/Port VMware-Erfassung: Verwenden eines anderen Ports für die Erfassung (Default: 443)
//ReadSQLServices 1 Auslesen der Windows-Dienste, die "SQL Server" im Namen tragen. Diese Liste wird dann verwendet, um bei der SQL-Server-Erfassung die Instanz-Namen zu erhalten. Standardmäßig werden die Instanz-Namen aus der Registry gelesen.
/StoppedVMs Auch für gestoppte virtuelle Maschinen wird ein Asset (Stub) angelegt. Gilt nur für die Erfassung von ESXi-Hosts.
/SqlServer Starten der SQL Server Inventarisierung
/XenServer Starten der XenServer Inventarisierung
/IgnoreFingerPrintRules NameOnly Siehe Erklärung hier
//NOVIRTUALSWITCH 1 Bei Hosts wird kein virtueller Switch und die entsprechende MAC-Adress-Tabelle erfasst
///Custom.Eigenschaft "Wert" Legt eine neue "Eigenschaft" mit dem Wert "Wert" an. Gilt nur für die Erfassung von ESXi-Hosts.
///Vm.Custom.Eigenschaft "Wert" Legt eine neue "Eigenschaft mit dem Wert "Wert" an. Gilt nur für Virtuelle Maschinen auf den ESXi-Hosts

LOGINfoMX.exe

Parameter Erklärung
/MaxLastSync Exchange-Erfassung: Standardmäßig werden mobile Geräte, die sich innerhalb der letzten 90 Tage via EAS synchronisiert haben, erfasst. Dieser Zeitraum lässt sich mit diesem Parameter anpassen (z.B. auf 30 Tage: /MaxLastSync 30)
/NoEas Exchange-Erfassung: Keine Erfassung von über EAS verbundenen Geräten (Smartphones etc.)
/EasOnly Exchange-Erfassung: Ausschließlich Erfassung von über EAS verbundenen Geräten (keine Mailboxes etc.)
/NoMailbox Exchange-Erfassung: Keine Mailbox-Informationen auslesen
/ServerFilter Exchange-Erfassung: Mittels Wildcards können nur bestimmte Exchange-Server für die Erfassung ausgewählt werden
/Test Hiermit wird keine Erfassung durchgeführt, sondern lediglich überprüft ob eine Erfassung möglich wäre (Returncode 20429)
/TestCmd hiermit können CMD-Befehle getestet werden, z.B. /testcmd "echo Test1"
/TestPowerShell hier können PowerShell-Befehle getester werden, z.B. /testpowershell "write-output test2"
/NoRpc hiermit wird die PowerShell-Session zur Erfassung nicht auf dem angegebenen Exchange Server, sondern lokal ausgeführt
///Custom.Eigenschaft "Wert" Legt eine neue "Eigenschaft" mit dem Wert "Wert" an. Gilt für die Erfassung Exchange Servern und mobilen Geräten (EAS)

Alle Test-Parameter lassen sich auch mehrfach kombinieren, um verschieden Befehls-Kombinationen bei der Erfassung zu testen. Dies kann nützlich sein, um Fehler oder Probleme zu identifizieren.

Beispiel-Test-Befehl:

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

LOGINfoX.exe

Parameter Erklärung
/cmd "COMMAND" Ausführen von Kommando "COMMAND" auf dem Client-Rechner, z.B. um die Verbindung zu testen
/keyfile Zugangsdaten mit User-Name und Private-Key-File und Passphrase
/sshport "PORT" Wert "PORT" wird als SSH-Port genutzt (Default:22)
/tmpdir "DIR" Verzeichnis auf Zielsystem, wo Scripts hinkopiert werden (Default: „/tmp“)
/workdir "DIR" Arbeitsverzeichnis auf Zielsystem, in dem Inventarisierung ausgeführt wird (Default: „/tmp/loginfo“)
/w LOGINfoX-Dialog anzeigen, z.B. um die Verbindung zum Client-Rechner zu testen

Aktivieren des Beta-Modus

Ausgewählte neue Funktionen stehen zunächst nur im Beta-Modus zur Verfügung. Um den Beta-Modus Ihrer LOGINventory-Installation zu aktivieren, gehen Sie bitte wie folgt vor.

  1. Navigieren Sie mittels Windows Explorer zu dem Verzeichnis, in dem LOGINventory installiert wurde, z.B. C:\Program Files\LOGIN\LOGINventory9
  2. Navigieren Sie in den Unterordner Manufacturer
  3. Führen Sie die Datei SetBetaMode_On.reg per Doppelklick aus und bestätigen Sie im nächsten Dialog, dass der Vorgang fortgesetzt werden soll.
  4. Starten Sie LOGINventory erneut

Info

Um den Beta-Modus zu deaktivieren, führen Sie die Datei SetBetaMode_Off.reg aus und starten Sie danach LOGINventory erneut.

Info

Die Einstellung des Beta-Modus ist rechnerspezifisch. Wenn Sie z.B. die portable Version verwenden, muss der Registry-Key auf dem Rechner hinzugefügt werden, auf dem Sie mit LOGINventory arbeiten (nicht auf der Server-Installation).

Zurück zum Seitenanfang