Technische Details

Systemvoraussetzungen

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

Hardware-seitig empfehlen wir mindestens vier logische Prozessoren sowie mindestens 4 GB RAM.

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

Info

Eine vorkonfigurierte Microsoft SQL Server 2012 SP4 Express Edition ist bereits im Setup von LOGINventory enthalten.

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

Management Rechner

Hardware

  • Microsoft .Net Framework 4.52 kompatibler PC ab 4 logische Prozessoren
  • 4GB RAM 
  • 10 GB freier Festplattenspeicher

Betriebssystem

  • Windows 7 SP1 (mit mindestens Internet Explorer 11 installiert)
  • Windows 8.1
  • Windows 10
  • Windows Server 2008 R2 SP1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

Software

  • Microsoft .NET Framework 4.52 oder später
  • Microsoft Powershell 4.0 oder später

Infrastruktur

Datenbank

  • Microsoft SQL Server 2012 SP4 oder neuer (alle Editionen)
  • LOGINventory Datenbank (enthalten)

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 LOGINventory8-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\LI8DATA\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\LOGINventory8\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.

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 verbundene Netzlaufwerke (Entität: NetworkDrive)

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
  • Festplatten-Daten zu SMART-Werten und, ob es sich um eine SSD handelt
  • TrustedPlatformModule-Werte

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.

Installierte Dienste

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

Dienstname Beschreibung
LOGINventory8 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.
LOGINventory8 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.
LOGINventory8 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 LOGINventory8 Inventory Service und LOGINventory8 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

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 LOGINventory8 schreiben Log-Informationen in das Verzeichnis %ProgramData%\Login\LOGINventory\8.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="8.0"

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

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

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

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

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.

Hinweis

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

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 LOGINventory8
  • 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 „LOGINventory8“ 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 „LOGINventory8“ 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\LOGINventory8).

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
/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)
/SqlServer Starten der SQL Server Inventarisierung
/XenServer Starten der XenServer Inventarisierung
//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". Gilt nur für die Erfassung von ESX-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

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