Datenerfassung
Für die Datenerfassung stehen verschiedene Optionen zur Verfügung. Neben der klassischen agentenlosen Erfassung, kann auch mittels lokaler Ausführung einer exe-Datei, oder mit Agenten gearbeitet werden, um die Daten der verschiedenen Geräte-Typen zu erfassen. Um jedoch einen ersten Überblick über das Netzwerk zu erlangen, eignet sich besonders das agentenlose Scannen.
Beim ersten Start von LOGINventory erscheint ein Wizard, der Sie bei der agentenlosen Ersterfassung unterstützt, wenn Sie auf den Knoten Remote Scanner wechseln. Im Wizard kann festgelegt werden, in welchem IP-Adress-Bereich nach Geräten gesucht werden soll, ob das Active Directory und Microsoft Exchange ausgelesen werden sollen, und ob vSphere-Geräte erfasst werden sollen.
Außerdem können administrative Windows-Credentials, SNMP-Communities und ein SSH-Login hinterlegt werden.
Info
Die eingegebenen Daten werden dabei stets mit der Microsoft Crypt-API verschlüsselt gespeichert und können nicht unbefugt ausgelesen werden.
Im Nachhinein lassen sich natürlich noch weitere Definitionen und Benutzerkonten hinterlegen.
Info
In den Technischen Details sind die Voraussetzungen zur agentenlosen Erfassung detailliert beschrieben.
Tipp
Die Unterschiede bei der Datensammlung zwischen den Erfassungsmethoden sind im entsprechenden Kapitel beschrieben.
Agentenloses Scannen
Um mit LOGINventory agentenlos zu scannen, muss ausgewählt werden, was inventarisiert werden soll (Definitionen) und wie darauf zugegriffen werden kann (Benutzerkonten). Dann können diese Definitionen zu Jobs zusammengefasst und durch die Aufgabenplanung automatisiert ausgeführt werden. Im Job Monitor ist dabei stets der Fortschritt der aktuell laufenden und das Ergebnis der vergangenen Scans einsehbar.
Info
Die Benutzerkonten lassen sich auch via Drag & Drop den Definitionen zuweisen, ebenso wie sich die Definitionen via Drag & Drop den Jobs zuweisen lassen.
Benutzerkonten
Grundsätzlich lassen sich die Benutzerkonten in folgende Typen unterscheiden:
- Generic Credentials (mit Benutzername, Passwort und Domäne): Administrative Konten zum Auslesen von Windows, Active Directory, Exchange, vSphere, XenApp, XenServer, SQL Server & Office365
- SSH Credentials (für Linux und MAC Computer) mit Login und Passwort oder Login, Key-File und (optionaler) Passphrase. 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.
- SNMP Communities (Read-Only): Zum Auslesen von SNMP v1/v2c Geräten, wie Netzwerkdruckern, Switches, Router, etc.
- SNMP v3 Credentials (mit entsprechenden Anmeldeparametern): Zum Erfassen von SNMP v3 Geräten mit Security-Name (z.B: "v3user"), Security-Level (z.B. "authNoPriv"), Auth Protokoll (z.B. "MD5"), Auth Schlüssel (z.B. "v3password"), Priv Protokoll (z.B. "AES"), Priv Schlüssel (z.B. "privPassword")
- Azure Credentials: Zum Hinterlegen von Zugangsinformationen für die "Modern Authentication" bei Microsoft Azure. Mittels "Client Secret" oder Zertifikat wird die Authentifizierung durchgeführt.
- AWS Credentials: Zum Hinterlegen von Zugangsinformationen für die "Modern Authentication" bei AWS. Mittels "Access Key" wird die Authentifizierung durchgeführt.
Tip
Es kann eine unbegrenzte Anzahl von Benutzer-Accounts angelegt werden, die sich jeweils einzelnen Definitionen zuordnen lassen. So können also innerhalb einer Definition verschiedene Passwörter, bzw. Benutzerkonten nacheinander durchprobiert werden, bis ein Gerät erfolgreich erfasst wurde. Dazu lässt sich auch die Reihenfolge der Benutzerkonten über die Pfeil-Symbole auf der linken Seite festlegen.
Scan-Definitionen
Die Definitionen beschreiben einzelne Scan-Bereiche, die sich in Jobs zusammenfassen lassen. Jede Definition benötigt einen Typ, einen eindeutigen Namen und optional eine Beschreibung. Die Definitionen lassen sich in folgende Typen unterscheiden:
- Asset Inventarisierung: Inventarisiert Windows-, Hyper-V, SNMP- (Switche, Netzwerkdrucker) und SSH-Geräte (Linux, Solaris, MacOS, …).
- Active Directory Konten und Gruppen: Liest Benutzer-, Gruppen und Computer-Eigenschaften aus Active Directory.
- Microsoft Exchange Inventarisierung: Inventarisiert eine komplette Exchange Organisation inklusive Mailbox-Informationen und mobile Geräte.
- VMware vSphere Inventarisierung: Inventarisiert VMware ESXi-Server und ihre vorhandenen VMs.
- Azure AD und Microsoft 365 Subscriptions: Liest aus dem Azure Active Directory Information zu Benutzer, Gruppen und Computern, sowie Berechtigungen im Azure AD aus. Außerdem wird ermittelt, welche Produkte bei Microsoft 365 lizenziert sind und welche User welche Lizenzen verbrauchen.
- Azure virtuelle Maschinen: Bei Azure wird ausgelesen, welche virtuellen Maschinen existieren, sowie diverse Konfigurationseinstellungen zu diesen VMs.
- AWS virtuelle Maschinen: Bei AWS wird ausgelesen, welche virtuellen Maschinen existieren, sowie diverse Konfigurationseinstellungen zu diesen VMs.
- SQL Server Inventarisierung: Inventarisiert Microsoft SQL Server Instanzen, deren Datenbanken und Benutzerrechte
- XenApp Inventarisierung: Inventarisiert auf Citrix XenApp publizierte Anwendungen.
- XenServer Inventarisierung: Inventarisiert Citrix XenServer und und ihre vorhandenen virtuellen Maschinen.
- Ausschluss von der Inventarisierung: Schließt Elemente von der Asset-Inventarisierung aus (wird in Jobs zusammen mit anderen Definitionen benutzt).
- Skriptbasierte Inventarisierung: Ermöglicht es skriptbasiert auf eigene Datenquellen zuzugreifen, um aus diesen beispielsweise Assets zu erzeugen, Lizenz-Informationen auszulesen oder Garantie-Daten zu ermitteln.
Für alle Definitionstypen sind unter Allgemein die allgemeinen Einstellmöglichkeiten zusammengefasst, wie z.B.
- Anzahl der parallelen Scans (bei langsamer Netzverbindung niedriger wählen!)
- maximale Laufzeit für einen einzelnen Scan
- maximale Antwortzeit für den PING auf ein Gerät
- zusätzliche Kommandozeilenparameter
Hier gilt stets: Wenn die entsprechenden Felder leer sind, wird der Standard-Wert verwendet.
Achtung
Über den Tab Benutzerkonten muss immer ausgewählt werden, welche Accounts aus dem Pool aller Benutzerkonten benutzt werden sollen.
- Für jedes Gerät werden alle angewählten Accounts der Reihe nach (von oben nach unten) benutzt, bis ein Scan erfolgreich war.
- Über die Pfeil-Buttons lässt sich die Reihenfolge der Accounts innerhalb der Typen ändern.
- Die Credential Typen werden in folgender festen Reihenfolge verarbeitet:
- Generic Credentials
- SSH Credentials
- SNMP v3 Credentials
- SNMP Community
- An oberster Stelle sollten diejenigen Benutzerkonten stehen, die für die meisten Geräte in dieser Definition gültig sind.
Info
Wenn eine Definition angelegt und mindestens ein Benutzerkonto ausgewählt wurde, kann die Inventarisierung manuell gestartet werden. Der Fortschritt wird im Job Monitor angezeigt. Die Auswertung geschieht dann im "Asset Management"-Knoten.
Asset Inventarisierung
Für den Definitionen-Typ Asset Inventarisierung spezifiziert die Quelle den Scan-Bereich. Es gibt folgende Typen von Scan-Bereichen:
- IP v4 Adressbereich (z.B. 192.168.200.1 - 192.168.200.121)
- IP v4 Subnetz (CIDR) (z.B. 192.168.200.64/16)
- Datei-Liste (Textdatei mit Namen oder IP-Adressen der Assets: pro Zeile ein Eintrag)
- Liste von Elementen
- Active Directory: Sie können die Rechner erfassen, die Einträge im AD haben.
Info
Das Ping-Intervall wird dynamisch angepasst und sollte nur in Ausnahmefällen manuell geändert werden, z.B. wenn Sie einen oder mehrere sehr große Bereich scannen und mit der Dauer der Ping-Phase nicht zufrieden sind. Eine zu starke Absenkung des Intervalls kann zu Unregelmäßigkeiten beim Erkennen von Geräten führen.
Achtung
Wenn bei der Asset Inventarisierung das Active Directory als Quelle angegeben wird, wird nicht das AD selbst erfasst, sondern dort vorhandene und aktuell eingeschaltete Rechner. Das bedeutet, dass Switches oder Rechner, die nicht im AD sind, nicht erfasst werden.
Falls als Quelle Active Directory gewählt wird, kann zwischen OUs und Sites and Subnets unterschieden werden. Mittels des Schiebereglers Knoten explizit wählen kann umgeschaltet werden, ob automatisch alle im gewählten Ordner (und Unterordnern) vorhandenen Elemente erfasst werden sollen, oder ob eine explizite Auswahl nötig ist.
Unter Erweitert kann die Datenermittlung angepasst werden. So lässt sich z.B. einstellen, ob Share-ACLs (Freigegebene Ordner), Treiber, Schriftarten, u.v.m. erfasst werden sollen. Diese Einstellungen können auch Einfluss auf die Laufzeit der Inventarisierung haben.
Unter Asset Eigenschaften lassen sich spezielle, frei definierbare Eigenschaften für diese Definition angeben (siehe Eigene Eigenschaften). Definieren Sie mit den Asset Eigenschaften Werte, die allen erfolgreich inventarisierten Assets einer Definition zugewiesen werden sollen! Falls Ihre IP-Adress-Bereiche z.B. bereits nach Standort aufgeteilt sind, könnten Sie als Asset Eigenschaft z.B. den jeweiligen Standort zuweisen und diese Zuweisung dann natürlich auch in Abfragen verwenden.
Unter File-Suche können Suchpfade angegeben werden, an denen nach bestimmten Dateien auf den zu scannenden Windows-Geräten gesucht werden soll. Dazu kann ein Pfad unter Verwendung von Wildcards (*
) angegeben und bestimmt werden, ob die Suche rekursiv (also auch in allen Unterordnern) stattfinden soll. So können zum Beispiel alle Dateien im Temp-Ordner mit einer Suche nach C:\Temp\*.*
gefunden werden.
Achtung
Verwenden Sie die rekursive Suche kann je nach gewähltem Filterkritierium und Festplatten-Inhalt zu längerern Scan-Zeiten führen!Verwenden Sie am Besten die Suche mit möglichst engen Einschränkungen, zum Beispiel zur Suche einer bestimmten .exe in einem bestimmten Verzeichnis (Suchpfad: C:\Program Files\Hersteller\meine.exe
)!
Wichtig
Durch die Asset-Inventarisierung werden automatisch auch Hyper-V Instanzen erfasst! Bitte beachten Sie die Hinweise zu den Besonderheiten der Hypervisor-Erfassung, die auch erklären, wie bestimmte VMs nicht erfasst werden, warum die VMs auch direkt gescannt werden sollten und wie den Hosts und VMs Eigene Eigenschaften zugewiesen werden!
Info
Falls bestimmte Geräte von der Erfassung ausgeschlossen werden sollen, nutzen Sie den Definitions-Typ Ausschluss von der Inventarisierung.
Active Directory Konten und Gruppen
Achtung
Dieser Inventarisierungstyp wird dazu benutzt, aus dem Active Directory zusätzliche Eigenschaften für Benutzer oder Computer zu lesen. Mit den Active Directory Daten werden keine neuen Knoten unter Assets oder Benutzer angelegt, sondern es werden bereits vorhandene Asset- oder Benutzerdaten ergänzt, die über die Asset-Inventarisierung erfasst wurden.
Falls die Option Benutzernamen anonymisieren in den Einstellungen aktiviert ist, können die Benutzerdaten nicht mit Active Directory Informationen ergänzt werden, da eine Zuordnung dann nicht möglich ist!
Die Quelle definiert, welche Einträge aus dem AD eingelesen werden sollen. Hier kann im Root-Verzeichnis der vollqualifizierte Domänen-Name angegeben werden. Über den Active Directory Browser kann ein Unterverzeichnis ausgewählt werden, um die Suche einzuschränken.
Über Erweitert können ausgewählte AD-Attribute gelesen und in LOGINventory-Attribute eingetragen werden. Dazu muss der Name des Wertes aus dem AD eingetragen und einem Custom-Wert in LOGINventory zugeordnet werden.
Außerdem kann hier eingestellt werden, dass Gruppenmitgliedschaften von Sicherheitsgruppen rekursiv aufgelöst werden, falls also eine Gruppe in einer anderen Gruppe enthalten ist ("Nested Groups", bzw. "Gruppenverschachtelung"). Weitere Parameter finden sich bei den Erklärungen zur LOGINfoAD.exe.
Technischer Hintergrund zum Auslesen des AD
LOGINventory erfasst Mitglieder (User) einer OU und löst je nach Setting deren Gruppenmitgliedschaften in direkten und indirekten (rekursiv) Gruppen auf. Wird beim Scannen der Pfad auf eine OU gesetzt, welche nur die Gruppe, jedoch nicht den User enthält, so ist der User nicht Mitglied der OU, sofern er dort nicht explizit hinzugefügt wurde und wird von hier aus nicht erfasst.
Nur bei Sicherheitsgruppen können die Mitgliedschaften rekursiv aufgelöst werden, falls der entsprechende Haken gesetzt wurde. Bei Verteilergruppen werden immer nur die direkten Mitgliedschaften ausgelesen.
Tipp
Wir empfehlen, dass die regelmäßige Bereinigung der AD-Daten eingeschaltet ist (und der AD-Scan regelmäßig durchgeführt wird).
Microsoft Exchange Inventarisierung
Mit der Microsoft Exchange Inventarisierung lassen sich Informationen über die gesamte Exchange Organisation (2010 und später) inklusive Server, DAGs, Datenbanken, Mailboxen und mobile Geräte per Remote Scan von einem Microsoft Exchange Server erfassen. Falls unterschiedliche Exchange Server Versionen im Einsatz sind, sollte derjenige mit der neuesten Version benutzt werden. Das angegebene Benutzerkonto muss in der Exchange Organisation ausreichende Rechte besitzen, z.B. Mitglied der Gruppe „Exchange View-Only Administrators“, bzw. "View-Only Organization Management" (on-premises Server).
Wichtig
Es kann als Quelle auch ein Cloud Server angegeben werden, dazu muss einfach die Adresse in die Zeile des Server-Namen eingegeben werden, z.B. outlook.office365.com
.
Voraussetzungen für die Erfassung von Online Exchange Servern mit App-Registrierung
Zusammengefasst gelten folgende Voraussetzungen für den Scan:
- Eine Internet-Verbindung muss bestehen.
- Das PowerShell-Modul ExchangeOnlineManagement muss auf dem LOGINventory-Rechner installiert sein.
Die Installation dieses Moduls erfolgt durch Eingabe des BefehlsInstall-Module -Name ExchangeOnlineManagement
in einer administrativen PowerShell auf dem Scan-Server (dem Rechner, auf dem LOGINventory installiert ist, von dem aus die Datenabfrage geschehen soll).
Gegebenenfalls muss noch der NuGet-Anbieter zuerst über die PowerShell installiert werden, damit das ModulExchangeOnlineManagement
installiert werden kann. Darauf wird aber von der PowerShell hingewiesen, falls der oben genannten Befehl ausgeführt wird. - Ein Konto vom Typ Azure Credentials muss entsprechend der Anleitung eingerichtet und berechtigt worden sein und für die Erfassung verwendet werden.
- Das Manifest der App-Registrierung muss angepasst worden sein & die Anpassung mit Administratorzustimmung bestätigt sein, siehe Warnung in Schritt 2. Ansonsten kommt es zur Meldung "Zugriff verweigert".
Info
Über die Exchange Inventarisierung werden standardmäßig auch alle über Exchange Active Sync (EAS) verbundenen mobilen Geräte erfasst und als Assets in LOGINventory angelegt. Dieses Verhalten lässt sich unterdrücken, indem unter Erweitert ein Haken bei Keine mobilen Geräte (EAS) gesetzt wird.
Um zu verhindern, dass alle Exchange Server erfasst werden, sondern nur ausgewählte, kann unter Erweitert ein Server-Filter gesetzt werden. So werden z.B. durch einen Eintrag von Serv*
beim Server-Filter nur noch Exchange-Server erfasst, deren Name mit "Serv" beginnt.
Info
Falls den Exchange Servern und mobilen Geräten (erfasst via EAS) 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"
. So wird also mit dem Argument ///Custom.Stockwerk "3.OG"
eine Eigenschaft "Stockwerk" mit dem Wert "3.OG" für alle erfassten Exchange Server und mobilen Geräte angelegt.
VMware vSphere Inventarisierung
Mit der VMware vSphere Inventarisierung können ESXi und vCenter Server direkt erfasst werden, ohne dass weitere Konfigurationsschritte dort notwendig sind.
Als Quelle wählen Sie den Typ „Liste von Elementen“ und fügen Ihre ESXi Server, Ihren vCenter Server, bzw. Cluster als Element ein (Full Qualified Domain Name (z.B. vcenter.m.loginventory.de) oder die IP-Adresse).
Tipp
Es ist nicht notwendig alle ESXi-Hosts einzeln hier einzufügen, falls ein vCenter zum Einsatz kommt. In diesem Fall genügt es, nur den Namen oder die IP-Adresse des vCenters einzugeben, alle ESXi-Hosts werden dann automatisch erfasst.
Das Benutzerkonto muss über die benötigten administrativen Rechte (mindestens Read-Only-Admin) auf den VMware Servern verfügen.
Wichtig
Bitte beachten Sie die Hinweise zu den Besonderheiten der Hypervisor-Erfassung, die auch erklären, wie bestimmte VMs nicht erfasst werden, warum die VMs auch direkt gescannt werden sollten und wie den Hosts und VMs Eigene Eigenschaften zugewiesen werden!
Azure AD und Microsoft 365 Subscriptions
Mit diesem Definitionstyp werden einerseits aus Microsoft Azure Informationen zu User-Account, Computer-Account & Gruppenmitgliedschaften (analog zum Auslesen des on-premises Active Directory), sowie Berechtigungen in Azure AD ausgelesen. Andererseits lässt sich online auslesen, welche Subscriptions (z.B. Office365, Microsoft Intune, Power BI Pro, etc.) abgeschlossen wurden und welchen Usern dabei welche Lizenzen zugeordnet wurden.
Tipp
Die Inventarisierung ist also sowohl für reine Azure Active Directory Umgebungen, als auch für Hybrid-Umgebungen (on-premsises AD mit mit AAD Connect, bzw. AAD Sync) interessant.
Info
Wird in Hybrid-Umgebungen sowohl das Azure AD als auch das on-premises AD erfasst, entstehen keine Duplikate, sondern die Daten werden zusammengefügt.
Achtung
Für das Auslesen des Azure AD ist es notwendig, eine App-Registrierung im Azure Portal durchzuführen. Dieses Prozedere ist ausführlich bei den Technischen Details beschrieben.
Beim Zuordnen der Benutzerkonten zu der Definition kann ausschließlich der Typ Azure Credentials verwendet werden. Ein Auslesen ist mittels Generic Credentials (Benutzername + Passwort) nicht möglich!
Wir empfehlen bei der Authentifizierung ein Client Secret anstatt eines Zertifikats zu verwenden, da der Einrichtungsaufwand deutlich geringer ist.
Voraussetzungen
Zusammengefasst gelten folgende Voraussetzungen für den Scan:
- Eine Internet-Verbindung muss bestehen.
- Ein Konto vom Typ Azure Credentials muss entsprechend der Anleitung eingerichtet und berechtigt worden sein und für die Erfassung verwendet werden.
Wenn die Erfassung erfolgreich war ist dies im Job-Monitor ersichtlich und die Daten aus dem Azure AD werden in den entsprechenden Active-Directory-Abfragen in LOGINventory angezeigt.
Die Daten zu den Micorsoft 365 Subscriptions stehen dann unterhalb des Knoten "Software" in den entsprechenden Abfragen zur Verfügung. Ebenso lassen sich diese Cloud-Subscriptions zum Lizenzmanagement hinzufügen.
Tipp
Wir empfehlen, dass die regelmäßige Bereinigung der Cloud Subscription Daten eingeschaltet ist (und der Scan regelmäßig durchgeführt wird).
Azure virtuelle Maschinen
Mit diesem Definitionstyp wird von Microsoft Azure ausgelesen, welche virtuellen Maschinen (VMs) angelegt wurden, welchen Status diese haben, sowie diverse Informationen zu Betriebssystem, IP-Adresse, Größe, Standort etc. ermittelt.
Dabei wird die Azure-Umgebung als "Hypervisor" betrachtet, sodass eine Zuweisung der VMs zu diesem Host (= der Azure Umgebung) in LOGINventory existiert.
Wie bei den anderen Hypervisor-Erfassungen auch, werden nur laufende VMs als Asset angelegt, siehe Besonderheiten bei der Hypervisor-Erfassung.
Voraussetzungen
Zusammengefasst gelten folgende Voraussetzungen für den Scan:
- Eine Internet-Verbindung muss bestehen.
- Ein Konto vom Typ Azure Credentials muss entsprechend der Anleitung eingerichtet und berechtigt worden sein und für die Erfassung verwendet werden.
- Der App-Registrierung muss ein Abonnement (Subscription) zugewiesen worden sein, siehe Schritt 4. Ansonsten kommt es zur Meldung "Zugriff verweigert".
Tipp
Um die Details zur Software, Konfiguration, etc. auszulesen, eignet sich z.B. eine Installation des Offline Agenten auf der virtuellen Maschine.
AWS virtuelle Maschinen
Mit diesem Definitionstyp wird von AWS (Amazon Web Services) ausgelesen, welche virtuellen Maschinen (VMs) angelegt wurden, welchen Status diese haben, sowie diverse Informationen zu Betriebssystem, IP-Adresse, Größe, Standort etc. ermittelt.
Dabei wird die AWS-Umgebung als "Hypervisor" betrachtet, sodass eine Zuweisung der VMs zu diesem Host (= der AWS Umgebung) in LOGINventory existiert.
Wie bei den anderen Hypervisor-Erfassungen auch, werden nur laufende VMs als Asset angelegt, siehe Besonderheiten bei der Hypervisor-Erfassung.
Voraussetzungen
Zusammengefasst gelten folgende Voraussetzungen für den Scan:
- Eine Internet-Verbindung muss bestehen.
- Ein Konto vom Typ AWS Credentials muss entsprechend der Anleitung eingerichtet worden sein und für die Erfassung verwendet werden.
Tipp
Um die Details zur Software, Konfiguration, etc. auszulesen, eignet sich z.B. eine Installation des Offline Agenten auf der virtuellen Maschine.
SQL Server Inventarisierung
Bei der SQL Server Inventarisierung können einzelne Server anhand des Namens oder der IP erfasst werden, oder es werden IP-Bereiche definiert, in denen nach SQL Server Installationen gesucht wird. Das verwendete Benutzerkonto sollte nach Möglichkeit Administrator-Rechte auf dem Datenbank-Server haben; es kann aber z.B. auch mit dem User "sa" und dem entsprechenden Kennwort (Generic Credentials) gescannt werden.
Achtung
Für die Erfassung von Datenbanken außerhalb des eigenen Subnets unter Verwendung der SQL-Server-Authentifizierung (z.B. User "sa"), kann es notwendig sein, sowohl Windows Credentials, als auch den SQL-Server-User als Konten bei der Definition zuzuordnen. (Über den Windows-User werden die Instanzen gefunden, der SQL-Server-User kann diese erfassen.)
Info: Berechtigungen
Damit mit einem SQL-Server-User die Daten zu allen auf dem Server vorhandenen Datenbanken ausgelesen werden können, benötigt dieser die Rolle sysadmin auf Serverebene.
Um von einzelnen Datenbanken die Informationen zu Name, Insatz, Server-Version & Größe auslesen zu können, genügt die Rolle public auf Datenbankebene. Sollen auch die zugewiesenen Rollen auf Datenbankebene ausgelesen werden, ist die Rolle db_accessadmin auf Datenbankebene nötig.
XenApp Inventarisierung
Die auf Citrix XenApp Servern publizierten Anwendungen und deren Zugriffsrechte-Einstellungen werden über die XenApp Inventarisierung erfasst. Dazu müssen keine weiteren Voraussetzungen auf dem LOGINventory-Rechner erfüllt sein. Beim Anlegen der entsprechenden Definition muss von jeder XenApp Server Farm nur jeweils ein Server inventarisiert werden.
Der Name dieses Servers muss im dafür vorgesehen Feld eingegeben werden. Beim Öffnen der Dropdown-Liste werden die Mitglieder der Gruppe „XenApp Servers“ zur Auswahl angezeigt.
XenServer Inventarisierung
Bei der XenServer Inventarisierung können bei Quelle die einzelnen zu erfassenden XenServer über den Full Qualified Domain Name oder über die IP-Adresse hinzugefügt werden. Das verwendete Benutzerkonto muss auf dem XenServer Administrator-Rechte besitzen.
Wichtig
Bitte beachten Sie die Hinweise zu den Besonderheiten der Hypervisor-Erfassung, die auch erklären, wie bestimmte VMs nicht erfasst werden, warum die VMs auch direkt gescannt werden sollten und wie den Hosts und VMs Eigene Eigenschaften zugewiesen werden!
Ausschluss von der Inventarisierung
Es ist möglich, bestimmte Geräte von einem Scan-Bereich auszuschließen (Achtung: gilt nur für Definitionen vom Typ Asset Inventarisierung ), indem Definitionen mit Ausschluss von der Inventarisierung gemeinsam mit einer anderen Definition ausgeführt werden. Dazu können diese entweder per Multi-Selektion gemeinsam gestartet werden oder in einem Job kombiniert werden.
Info
Falls als Quelle "Liste von Elementen" gewählt wird, kann auch mit Wildcards gearbeitet werden, um Geräte auszuschließen. So sind z.B. "*win*" oder "192.168.20*.15" gültige Werte. Im Job-Monitor ist dann sichtbar auf Grund welcher Filterbedingung die Geräte nicht erfasst werden.
Tipp
Falls Sie mobile Geräte, wie Smartphones von der Erfassung ausschließen möchten, dann ist dies nur direkt bei der Definition der Microsoft Exchange Inventarisierung unter Erweitert möglich.
Tipp
Falls bestimmte VMs nicht mehr erfasst werden sollen, kann dies über Kommandozeilen-Argumente bei der Erfassung der jeweiligen Hosts eigestellt werden (siehe Tipp "Keine Erfassung von bestimmten virtuellen Maschinen (VMs)").
Skriptbasierte Inventarisierung
Die skriptbasierte Inventarisierung ermöglicht es, dass über den Remote Scanner ein Powershell-Skript mit Übergabe-Parametern aufgerufen wird. Dieses Skript kann dazu genutzt werden, Daten aus einer Datenquelle auszulesen und diese in eine inv-Datei zu schreiben.
Da Sie die Skripte selbst erstellen / bearbeiten können, können Sie selbst festlegen, aus welcher Datenquelle welche Informationen gelesen werden sollen.
Beispiele
So lassen sich beispielsweise neue Devices in LOGINventory erzeugen, indem über ein Skript eine API angesprochen wird, über welche Geräte-Informationen abgerufen werden können. Dazu könnten Verwaltungs-Systeme für Thin Clients, Mobile Device Management Lösungen, etc. gehören - also Systeme zu denen aktuell in LOGINventory keine explizite Schnittstelle besteht.
Ebenso könnten weitere Informationen zu in der Cloud verwalteten Lizenzen, Garantie-Informationen von weiteren Herstellern und mehr abgerufen werden.
Über folgendes Github Repository stellen wir bereits einige Beispiele für Skripte mit verschiedenen Funktionen bereit:
https://github.com/loginventory/custom-scan-scripts
Tipp
Hier finden sich auch detaillierte Erklärungen zur Syntax. Außerdem können Sie dort auch ihre eigenen Skripte mit anderen Usern teilen oder bestehende Skripte gemeinsam mit anderen Kunden verbessern. Tauschen Sie sich gerne mit anderen Usern über die Diskussions-Funktion von Github aus!
Bitte befolgen Sie die Anleitung bei Github, und legen Sie die Skripte, die Sie verwenden möchten, an den dafür vorgesehenen Orten ab. Daraufhin kann im Dropdown-Menü das gewünschte Skript ausgewählt werden.
Gefahr
Wer die Möglichkeit hat, diese Datei auszutauschen oder in diesem Verzeichnis eigene Skripte abzulegen, hat potentiell auch Zugriff auf an der Definition hinterlegte Parameter. Stellen Sie daher unbedingt selbst sicher, dass auf diesen Ordner nur befugte Personen Zugriff haben, beispielsweise indem Sie die Filesystem-Berechtigungen entsprechend anpassen.
Einer Definition vom Typ Skriptbasierte Inventarisierung können keine Benutzerkonten zugewiesen werden. Stattdessen müssen im Reiter Parameter hinterlegt werden, die dann im Skript verwendet werden sollen. So werden z.B. Zugangsdaten, Kunden-IDs, Filterbedingungen oder Ähnliches über Parameter an das Skript übergeben, je nachdem, was dieses benötigt.
Jobs
Über Jobs erstellen Sie Kombinationen von Scan-Definitionen, um so Ihr Netzwerk oder Teilbereiche optimal zu scannen.
- Sollen mehrere Scan-Definitionen gleichzeitig gescannt werden, kann diese Aufgabe in einem Job zusammengefasst werden. So brauchen nicht immer die einzelnen Definitionen angewählt zu werden.
- Wenn bestimmte Assets in einem Scanbereich nicht gescannt werden sollen, können Sie diese über die Definition einer Ausschluss-Inventarisierung angeben. Wird diese Definition mit Inventarisierungs-Definitionen kombiniert, werden die ausgeschlossenen Assets nicht gescannt.
- Scan-Definitionen können in mehreren Jobs verwendet werden.
- Jobs lassen sich deaktivieren, woraufhin der Zeitplan ignoriert wird und die Jobs nicht mehr automatisch ausgeführt werden.
Zeitplan
Mit Hilfe eines Zeitplans können Sie festlegen, zu welchen Zeitpunkten Jobs automatisiert ausgeführt werden, um das Netzwerk regelmäßig zu scannen.
Wichtig
Jeder Job kann auch mit mehreren Zeitplänen mehrmals täglich ausgeführt werden.
Tipp
Wir empfehlen mehrmals täglich das Netzwerk zu scannen; am besten zu Zeitpunkten, wenn Ihre User auch tatsächlich die Rechner verwenden. Je häufiger gescannt wird, desto fein-granularer ist die Änderungs-Historie.
Job Monitor
Sobald ein Job gestartet wurde (oder eine Definition über Auswahl starten), kann der Fortschritt der Inventarisierung über den Job Monitor beobachtet werden. In der oberen Ergebnisliste werden alle bisher gelaufenen und aktuell laufenden Jobs aufgeführt. Wird eine der aufgeführten Definitionen angewählt, wird der Status der Erfassung dieser Definition in der unteren Ergebnisliste aufgelistet. Für die laufende Inventarisierung lässt sich hier auch der Verlauf beobachten. Für beendete Asset-Scans werden u.a. angezeigt:
- der Status ("Finished", "Executing", "Queued" oder "None")
- das Resultat ("Ok", "Error" oder "None")
- Informationen zur Startzeit und Laufzeit
- Informationen zum Fehler (falls vorhanden), typische Gründe und Maßnahmen zur Fehlerbehebung
In vielen Netzwerkkonfigurationen können mit den ersten Scans nicht direkt alle Geräte erfolgreich erfasst werden. Wenn Fehler bei der Erfassung auftreten, sollte zunächst geprüft werden, welche Art von Gerät sich hinter der nicht erfolgreich inventarisierten IP-Adresse verbirgt. Wenn es sich z.B. um ein IP-Telefon handelt, das über keine Remote-Schnittstelle verfügt, kann das Gerät höchstens manuell in die Datenbank eingetragen werden. Ggf. ist auch das Hinterlegen von weiteren Benutzerkonten mit den nötigen Rechten erforderlich, die Firewall-Konfiguration muss angepasst werden. Oder auf den Geräten müssen Remote-Protokolle freigeschaltet werden.
Info
Vom Job Monitor aus kann aus dem Ribbon-Menü SSH Problembehandlung aufgerufen werden. Mit diesem Tool können verschiedene Einstellungen, wie Port, Benutzername, Passwort etc. getestet werden. In der textuellen Ausgabe ist dann ersichtlich, welche Probleme beim Verbindungsaufbau, bzw. bei der Abfrage der Linux-Geräte auftreten.
Erfassung mittels Logon-Script
Windows-Rechner können über einen Aufruf der LOGINfo.exe inventarisiert werden. Dieser Aufruf kann im Logon-Script positioniert werden, damit sich Rechner bei der Benutzer-Anmeldung automatisch erfassen.
Wichtig
Der große Vorteil dieser Methode besteht darin, dass eine Datenerfassung auch ohne administrative Rechte und bei vorhandener Firewall erfolgen kann, da der Scan lokal und im Benutzerkontext ausgeführt wird.
Voraussetzungen
Um die Erfassung mittels Logon-Script einzurichten, sind verschiedene Schritte notwendig. Wie bei der Datenverarbeitung beschrieben, entstehen bei der Erfassung von Rechnern .inv-Dateien. Diese Dateien müssen in dem zentralen Datenverzeichnis abgelegt werden, welches vom Dienst LOGINventory Data Service überwacht wird. Dieser Dienst trägt die Daten dann in die Datenbank ein.
Zur Erfassung eines Rechners wird das Programm LOGINfo.exe aufgerufen, welches sich im Datenverzeichnis befindet. Im LOGINventory Helpdesk steht auch eine Legacy-Version namens LogInfoL.exe zum Download zur Verfügung, welche zur Inventarisierung von alten Systemen, wie NT4, ME oder Windows 2000 dient. Sie können das Datenverzeichnis auch über die Taskleiste öffnen, indem Sie den Dienst LOGINventory Data Service wählen und sich Neue Inventardateien anzeigen lassen.
Der Speicherort des Datenverzeichnisses kann in den Einstellungen angepasst werden. Hier lässt sich auch das Verzeichnis freigeben, was für die Inventarisierung mittels Logon-Script notwendig ist. Standardmäßig wird der Freigaben-Name Li9Data verwendet. Wenn Sie das Verzeichnis über diesen Dialog freigeben, werden folgende Rechte im Dateisystem gesetzt: Authentifizierte Benutzer: Voll; Lokaler Dienst: Ändern.
Achtung
Damit das Freigeben in diesem Dialog klappt, muss LOGINventory mit administrativen Rechten gestartet werden.
Damit können alle User und Computer innerhalb der Domäne auf das Verzeichnis zugreifen und dort die LOGINfo.exe aufrufen, um sich selbst zu inventarisieren. Eine Automatisierung dieses Aufrufs ist sinnvoll und kann über das Logon-Script konfiguriert werden.
Konfiguration
In das Logon-Script kann z.B. folgender Aufruf aufgenommen werden, der keine Ausgabedaten anzeigt:
START /B \\server\LI9DATA\LOGINfo.exe
Falls der Scan nur für lokal angemeldete Benutzer ausgeführt werden soll, kann folgendes Kommando verwendet werden:
If "%SESSIONNAME%"=="Console" START /B \\server\LI9DATA\LOGINfo.exe
Alternative: Die folgenden Zeilen im Skript bewirken, dass LOGINfo.exe lokal ausgeführt wird, wobei zuvor geprüft wird, ob es eine neuere Version der LOGINfo.exe auf dem Server gibt. Die entstehende .inv-Datei wird dabei direkt auf dem Server abgelegt. Weiterhin wird die Erfassung nur gestartet, wenn der Anwender lokal an der Konsole angemeldet ist.
If "%SESSIONNAME%"=="Console" (
xcopy /d \\server\LI9DATA\LOGINFO.EXE %temp%
start /b %temp%\LOGINfo.exe \\server\LI9DATA)
Anstatt "server" muss hier natürlich jeweils der Name des entsprechenden Servers mit der LOGINventory-Installation angegeben werden. Außerdem können auch noch weitere Parameter beim Aufruf der LOGINfo.exe mit übergeben werden, diese sind ausführlich unten beschrieben; notwendig ist dies aber nicht.
Wie ein Aufruf dieser Art in das Logon-Script integriert wird, ist ausführlich von Microsoft beschrieben. Hierbei gibt es zwei Varianten:
- Zuweisen von Benutzeranmeldeskripts: https://technet.microsoft.com/de-de/library/cc770908(v=ws.11).aspx
- Zuweisen von Skripts zum Starten des Computers: https://technet.microsoft.com/de-de/library/cc770556(v=ws.11).aspx
Nun wird automatisch beim Anmelden der jeweilige Rechner inventarisiert. In der Abfrage "Überblick letzte Erfassung" können Sie überprüfen, welche Methode zur Inventarisierung verwendet wurde und wann die Inventarisierung geschehen ist, indem Sie die Spalten LastInventory.Agent und LastInventory.Timestamp überprüfen.
Hinweis
Wenn der Eintrag bei Agent mit "(LOCAL)" endet, wurde die Inventarisierung im Benutzerkontext oder vom Computer ausgeführt, also durch den Aufruf der LOGINfo.exe im Datenverzeichnis.
Parameter
Durch die Parameter kann das Verhalten der LOGINfo.exe angepasst werden. Wird ein Schaltername angegeben, hat dieser Priorität vor einem Eintrag in der LOGINfo.script Datei.
LOGINfo.exe [!IpAddress] [DataDir] [/parameter1] [/parameter2] ...
LOGINfo.exe | Kommandozeilen-Parameter |
---|---|
/? |
Gibt Informationen zur Verwendung der Parameter aus |
!IP-Adresse |
Remote Scan Adresse; Default: eigener Rechner |
Zielverzeichnis |
Die Ergebnisdatei wird in ‹Zielverzeichnis› gespeichert. Default: aktuelles Verzeichnis. Im Unterordner "Script" dieses Verzeichnisses wird auch nach der LOGINfo.script gesucht. |
/NOWMI |
Verwende kein WMI bei Windows-Rechnern. |
/DEBUG |
Nur auf Anweisung des LOGIN Support-Teams verwenden |
//‹Schaltername› n |
Ändert den Wert eines Schalters mit dem Wert ‹n› (siehe Schalter) |
/PINGLEN nummer |
Anzahl Bytes im Ping (default: 32) |
/PINGTIMEOUT wartezeit |
Ping-Wartezeit in ms (default: 2000 ms) |
/NOWIN |
Keine Windows APIs verwenden |
/NOSNMP |
Kein SNMP verwenden |
/NOSSH |
Kein SSH verwenden |
/USESNMPFALLBACK |
SNMP auch verwenden, wenn keine Antwort auf Ping erfolgt |
/SNMPPORT port |
Benutze SNMP UDP ‹port› (default:161) |
/SNMPCOMMUNITY community |
Benutze SNMP v1 Read-Community (standard: ‹public›) |
/USER Benutzername Passwort |
Windows Zugangsdaten |
/NETSNMP |
Verwende Net-SNMP statt Microsoft SNMP |
/NETSNMPCONF |
Standard-Konfigurationsdatei von Net-SNMP verwenden |
/SNMPUSER user |
SNMP v3 Benutzer; security level=noAuth |
/SNMPAUTH md5 | sha pass |
SNMP v3 Passwort; security level=authNoPriv |
/SNMPPRIVACY des | aes pass |
SNMP v3 Passphrase security level=authPriv |
/FindFiles "path" |
Stößt die File-Suche an. z.B. "/FindFiles "C:\Temp*.*" |
/FindFilesRec "path" |
Stößt die rekursive File-Suche an. Beide Such-Parameter können mehrmals verwendet werden, wenn an mehreren Orten gesucht werden soll. |
Beispiele
Erfassung des Rechners mit der IP "192.168.200.50": LOGINfo.exe !192.168.200.50
Erfassung des eigenen Rechners und Ablegen der entstehenden inv-Datei in "C:\Temp": LOGINfo.exe C:\Temp
(Achtung: Hier wird im Unterordner "Script" des Zielverzeichnis nach der LOGINfo.script-Datei gesucht, also C:\Temp\Script\LOGINfo.script
)
Wichtig
Über Schalter (zu erkennen am //
) können noch viel mehr Anpassungen vorgenommen werden. Diese sind alle bei der Modifikation der Datenermittlung beschrieben.
Windows Offline Agent zur Erfassung von Rechnern außerhalb des LANs
Der LOGINventory Offline Agent kann auf Windows-Rechnern mit .NET Framework 3.5 und höher benutzt werden, die selten oder nie im LAN sind, aber trotzdem inventarisiert werden sollen. Da mit den bisher vorgestellten Erfassungsmethoden nur Geräte erfasst werden können, die im Netzwerk verfügbar sind, ist eine zusätzliche Erfassungsvariante nötig, um beispielsweise Laptops von Außendienstmitarbeitern regelmäßig zu inventarisieren. LOGINventory stellt hierfür den Windows Offline Agenten bereit. Dieser sorgt dafür, dass die entsprechenden Rechner sich selbstständig erfassen, diese Daten lokal puffern und bei vorhandener Netzwerkverbindung die gepufferten Daten selbstständig an den LOGINventory-Rechner senden.
Einrichtung
Achtung: Vor der Einrichtung beachten!
Wir empfehlen dringend vor dem Durchlaufen des Wizards sicherzustellen, dass der Web Viewer veröffentlicht wurde und das Datenverzeichnis freigegeben wurde. Nur so schlägt der Wizard automatisch die richtigen Pfade bei den URLs vor.
Wenn Sie sich nicht sicher sind, ob diese Voraussetzungen erfüllt sind, prüfen Sie dies bitte, bzw. durchlaufen den entsprechenden Wizard erneut!
Die Veröffentlichung des Offline Agenten kann über das Ribbon-Menü Extras gestartet werden.
Zunächst muss ein Verzeichnis ausgewählt werden, in dem die entsprechenden Dateien abgelegt werden sollen. Die Konfigurationsdaten werden zusammen mit den MSI-Setups in einem administrativen Installations-Punkt (AIP) zur Verfügung gestellt – also einem Verzeichnis, aus dem die administrative Installation ausgeführt werden kann.
Dann können für die verschiedenen Firewall-Profile Öffentlich, Privat und Arbeit jeweils eine URL und Anmeldedaten hinterlegt werden, mit denen die Daten übertragen werden können.
Info
Vor der Übertragung ermittelt der Offline Agent, in welcher Art von Netzwerk-Verbindung sich der PC gerade befindet und versucht dann die jeweils passende URL gemäß den hinterlegten Daten in Öffentlich, Privat und Arbeit zu erreichen.
Dabei ist folgendes zu beachten:
- Die Geräte, auf denen der Offline-Agent installiert wurde, erfassen sich selbst und versuchen dann (je nach aktivem Windows-Firewall-Profil) die in diesem Schritt angegebene URLs zu erreichen und dort ihre .inv-Dateien abzulegen.
- Für die Übertragung der Daten muss ein User hinterlegt werden, der auf die OfflineAgent.aspx-Seite, bzw. die Li9Data-Freigabe zugreifen kann. Zum Zugriff auf die OfflineAgent.aspx genügt es auch, einen lokalen Nutzer zu berechtigen, es ist kein Domain-User nötig. So muss lediglich sichergestellt sein, dass im Filesystem auf dem Web-Server Lese-Zugriff auf die Datei
C:\inetpub\wwwroot\LOGINventory9\OfflineAgent.aspx
besteht.
Ggf. sollte zunächst ein entsprechender User eingerichtet werden und dann dessen Daten hier im Dialog hinterlegt werden. - Die hier konfigurierten URLs müssen vom Client aus (z.B. Internet) erreichbar sein; dies kann z.B. mittels Port-Forwarder, Reverse Proxy oder DMZ-Server realisiert werden.
- Wird ein Port-Forwarder zum LOGINventory-Rechner konfiguriert, dann muss hier der LOGINventory Web Viewer sowie ein Zertifikat für https installiert werden.
- Der Empfang der Daten ist außerhalb des LOGINventory Web Viewers auch von einem anderen Server aus mittels ASPX oder PHP möglich. Dazu kann der Button Upload Script Vorlagen erstellen verwendet werden. Diese Script-Dateien können ggf. angepasst werden. Mehr Infos dazu in der Box "Verwendung eines anderen Webservers" unten.
- Der Offline Agent verfügt über eine Möglichkeit, sich selbst upzudaten, daher muss auch eine URL angegeben werden, unter welcher der Offline Agent prüft, ob ein neues Update zur Verfügung steht und dieses ggf. herunterladen kann.
Ist der Webserver, der von den Offline Agenten angesprochen werden soll, gleichzeitig der lokale LOGINventory-Rechner inklusive veröffentlichtem Web Viewer, so sind keine weiteren Konfigurationsschritte notwendig. Hier ist eine spezielle Version der Datei OfflineAgent.aspx zum Empfangen der Daten bereits vorhanden, welche die Daten automatisch im aktuell konfigurierten Datenverzeichnis) des Servers ablegt. Deswegen wird diese URL auch als Standard-Adresse vorgeschlagen.
Info
Beachten Sie, dass bei der Verwendung von http(s) zur Datenübertragung an den IIS-Server dieser so konfiguriert sein muss, dass er die Daten empfangen kann. Wenn nur Windows-Geräte Daten an den Server schicken, genügt die Aktivierung der Windows-Authentifizierung. Sollen auch macOS- / Linux-Geräte mit dem Offline Agenten ausgestattet werden, muss die Standard-Authentfizierung (Basic Authentication) in der IIS-Konfiguration auch aktiviert sein. Mehr Informationen zu diesem Thema finden Sie im Helpdesk.
Verwendung eines anderen Webservers
Falls ein anderer Server für den Empfang der Daten verwendet werden soll, ist dies "auf eigene Gefahr" möglich. Dieses Prozedere erfordert in jedem Fall, dass die Daten, die der andere Webserver empfängt in irgendeiner Form in das Datenverzeichnis des LOGINventory-Servers kopiert / verschoben werden, damit diese automatisch in die Datenbank eingetragen werden. Diese Übertragung ist z.B. durch ein eigenes Skript selbst zu realisieren.
Auf dem anderen Webserver kann entweder der IIS verwendet werden, wozu folgende Voraussetzungen gelten / Dateien benötigt werden:
- IIS-Version ab 7.0 und ASP.NET ab 4.5
- OfflineAgent.aspx (Diese Datei erhalten Sie durch klicken auf Upload Script Vorlagen erstellen)
- OfflineAgent_msi.zip
oder es wird PHP verwendet:
- Apache Version 2.4 oder höher
- PHP Version 5 oder höher
- OfflineAgent.php (Diese Datei erhalten Sie durch klicken auf Upload Script Vorlagen erstellen)
- OfflineAgent_msi.zip
Folgende Konfigurationsschritte sind im Fall der Verwendung von IIS auf dem anderen Webserver notwendig:
- IIS-Manager Starten
- In der Default Web Site eine „Anwendung hinzufügen“, entsprechend dem Pfad den Sie zuvor definiert hatten, z.B. „LOGINventory-OfflineAgent“, welches auf das physische Verzeichnis zeigt, in welches die Datei OfflineAgent.aspx gespeichert wird.
- Darunter ein „Virtuelles Verzeichnis hinzufügen“ mit dem Namen „Selfupdate“, welches auf ein physisches Verzeichnis zeigt, in dem die Datei OfflineAgent_msi.zip gespeichert wird (siehe Erläuterungen zum Update des Offline-Agenten).
- Der Webserver, respektive der User muss in das Datenverzeichnis schreiben können, welches in der OfflineAgent.aspx angegeben ist.
Der Webserver verwendet hierzu einen Account aus der Gruppe IIS_IUSRS (Gruppe die alle ApplicationPool Identities beinhaltet), bzw. den Account der dem entsprechenden ApplicationPool zugeordnet ist.
Sofern der Rechner nicht in der Domain ist (DMZ), muss auf dem IIS bei der Offline-Agent Anwendung Standard-Authentifizierung aktiviert sein.
Die vom Offline Agent empfangenen .inv-Dateien werden nun im Datenverzeichnis abgelegt (standardmäßig%Public%\Documents\LOGIN\LOGINventory 9\Data
).
Durch Editieren der Datei OfflineAgent.aspx oder OfflineAgent.php können Sie den lokalen Speicherort nach Ihren Erfordernissen abändern. Aus Sicherheitsgründen sollte dies jedoch nicht das Verzeichnis sein, in dem OfflineAgent.aspx liegt.
Falls ein anderer Webserver verwendet wird, müssen die .inv-Dateien schließlich noch zur Verarbeitung durch den Data Service auf dem LOGINventory-Rechner in das Daten-Verzeichnis kopiert werden, z.B. durch Robocopy.exe.
Im zu Beginn des Wizards ausgewählten Ordner entstehen mehrere Dateien, die alle zur Installation benötigt werden, darunter die entsprechenden MSI-Pakete für 32-bit und 64-bit Systeme:
Zur Installation auf den zu erfassenden Clients, empfiehlt es sich das passende Paket direkt aus dem AIP zu starten.
Tipp
Hier sollten nach Updates auch die jeweils vorherigen Versionen aufgehoben werden, da diese zur Deinstallation auf den Client ggf. wieder benötigt werden.
Info
Im Ordner "macOS" entsteht automatisch auch ein Setup für das Betriebssystem macOS. Die Einrichtung wird unten erklärt.
Arbeitsweise
Ist der Offline Agent auf einem Rechner installiert, werden jeden Tag zwei „geplante Aufgaben“ zur Inventarisierung mittels einer lokalen Kopie der LOGINfo.exe (siehe Logon-Skript-Methode) ausgeführt, und zwar:
- um 10:00 im Benutzer-Kontext eines angemeldeten Users (Achtung: Die Task im Benutzerkontext wird erst angelegt, wenn sich ein entsprechender Nutzer nach dem Setup neu an dem Gerät anmeldet.)
- um 20:00 im System-Kontext, also auch, wenn kein Benutzer angemeldet ist.
Ist der Rechner zu diesen Zeiten ausgeschaltet, werden die Scans innerhalb von maximal 24 Stunden nachgeholt.
Wichtig
Ist der Rechner also eingeschaltet, entstehen - getriggert durch die Windows-Aufgabenplanung - .inv-Dateien. Diese müssen dann von den Clients noch zum LOGINventory-Server übertragen werden, damit die aktuellen Daten in der Datenbank zur Verfügung stehen. Dabei versucht der Dienst "LOGINventory Offline Agent" (Displayname) , bzw. "LOGINfoSvc" (Name) die Daten an die bei der Einrichtung hinterlegten URLs zu übetragen.
Findet der Dienst "LOGINventory Offline Agent" im Verzeichnis "C:\Users\Public\Documents\LOGIN\LOGINventory 9\LocalData"
(lokales Datenverzeichnis) neue Inventardateien (*.inv), und es existiert eine Netzwerkverbindung, dann wird kurz darauf versucht, diese Dateien an die in der Konfiguration definierte - zum aktuellen Firewall-Profil passende - URL zu übertragen und danach ein SelfUpdate durchzuführen (falls verfügbar).
Fazit
Wenn alles korrekt eingerichtet ist, inventarisieren sich die entsprechenden Geräte also zwei Mal täglich und senden dann die Daten an das LOGINventory-Datenverzeichnis. Sie können bei den Assets am Wert der Eigenschaft LastInventory.Agent
sehen, mit welcher Erfassungsmethode das Gerät zuletzt inventarisiert wurde (hier: „Local“) und anhand des LastInventory.Timestamp auch den Zeitpunkt überprüfen. Außerdem können Sie auf dem LOGINventory-Rechner in der Ereignisanzeige sehen, wenn .inv-Dateien verarbeitet wurden.
Ein tägliches Protokoll der Kommunikation mit dem zentralen LOGINventory Server befindet sich auf dem Client mit installiertem Offline Agenten im Verzeichnis %ProgramData%\LOGIN\LOGINventory\9.0\Logs
.
Info
Falls zu Testzwecken nach der Installation direkt eine Übertragung der Daten ausgeführt werden soll, kann bei installiertem Offline-Agent in der Windows Aufgabenplanung die entsprechende Aufgabe ausgeführt werden.
Update des Offline Agenten
Für das Bereitstellen eines Update des Offline Agenten kann es verschiedene Gründe geben:
- Durch ein Update von LOGINventory wird eine Änderung an der Logik des Offline Agenten vorgenommen (z.B. um die Zuverlässigkeit zu verbessern). Darauf wird dann jeweils im LOGINventory-Changelog explizit hingewiesen. Diese Updates kommen in der Regel sehr selten vor.
- Durch ein Update von LOGINventory wird die Erfassung der LOGINfo.exe geändert (z.B. werden jetzt neue Werte ausgelesen). In diesem Fall sollte den Clients eine neue Version der LOGINfo.exe bereitgestellt werden, damit diese von den Neuerung profitieren und Daten liefern, welche kompatibel zur aktuell installierten Datenbank-Version sind.
- Durch den Administrator wird eine Anpassung der LOGINfo.script-Datei vorgenommen, weil z.B. eine Regel zum Setzen von eigenen Eigenschaften abhängig von der IP-Adresse hinzugefügt wurde. Damit diese für die Clients gilt, muss den Clients die aktualisierte Version der LOGINfo.script-Datei zur Verfügung gestellt werden.
- In Zukunft soll bei der Übertragung der Daten oder beim Selfupdate eine andere Ziel-URL verwendet werden, z.B. weil die LOGINventory-Installation auf eine andere Maschine umgezogen wird.
Wichtig
Bei keiner dieser Änderungen werden die installierten Offline Agent-Installationen automatisch geändert, sondern die Änderungen müssen für die Offline Agenten zum sogenannten "SelfUpdate" von Ihnen zur Verfügung gestellt werden.
Prinzipiell gibt es zwei unterschiedliche Arten an Updates, die Sie zur Verfügung stellen können. Geschehen tut das jeweils, indem Sie den Wizard zur Bereitstellung des Offline Agenten erneut durchlaufen und auf der letzten Seite eine der beiden Selfupdate-Optionen auswählen:
Über die Schaltfläche OfflineAgent_msi.zip für Selfupdate erstellen wird für den ersten der beschriebenen Fälle eine zip-Datei erstellt, die sich die Offline Agent-Installation herunterladen und sich damit selbst updaten. Dabei ist übrigens nicht nur das Update der "Logik" enthalten, sondern auch die aktuelle LOGINfo.exe und LOGINfo.script werden bereitgestellt. Damit wird quasi ein "vollständiges Update" bereitgestellt. Bei Verwendung eines anderen Webservers müssen Sie diese Datei ebenfalls manuell auf diesen Server kopieren. Ein Update an Hand dieser Dateien beim Offline Agent erfolgt dann automatisch bei der nächsten Verbindung, aber maximal einmal täglich.
Falls jedoch "nur" die LOGINfo.exe oder die LOGINfo.script geändert wurden (Fall 2 oder 3), muss kein "vollständiges Update" bereitgestellt werden, sondern es genügt den Button loginfo_script.zip für Selbstupdate erstellen zu klicken. Daraufhin wird eine Datei "loginfo_script.zip" erstellt, die die jeweils aktuelle Version der LOGINfo.exe und der LOGINfo.script enthält. Auch diese zip-Datei wird am Ende der nächsten Übertragung vom Client mit der Offline Agent Installation heruntergeladen und damit ein Selbstupdate von nur diesen beiden Dateien ausgeführt.
Für den vierten Grund - also eine Änderung der Upload- / Selfupdate-URLs - muss wie folgt vorgegangen werden: Im Wizard zur erneuten Veröffentlichung des Offline Agenten werden zunächst die neuen URLs eingetragen. Dann muss die Aktion OfflineAgent_msi.zip für Selfupdate erstellen (also die vollständige Aktualisierung) ausgeführt werden.
Info
Sie haben ein Update bereitgestellt und möchten wissen, ob dieses auch von den Clients installiert wurde? In der Log-Datei auf den Clients finden Sie dazu Hinweise (%ProgramData%\LOGIN\LOGINventory\9.0\Logs
).
Linux Offline Agent
Mit dem Linux Offline Agent können sich Linux-Maschinen selbst erfassen und die Daten eigenständig zum LOGINventory-Server übertragen. Dazu werden unterschiedliche Pakete-Typen für die jeweiligen Linux-Derivate im Programmverzeichnis im Unterordner LoginfoXScripts (standardmäßig C:\Program Files\LOGIN\LOGINventory9\LoginfoXScripts
) ausgeliefert.
Achtung: Voraussetzung zur Übertragung
Beachten Sie, dass bei der Verwendung von http(s) zur Datenübertragung an den IIS-Server dieser so konfiguriert sein muss, dass er die Daten empfangen kann. Wenn nur Windows-Geräte Daten an den Server schicken, genügt die Aktivierung der Windows-Authentifizierung. Sollen auch macOS- / Linux-Geräte mit dem Offline Agenten ausgestattet werden, muss die Standard-Authentfizierung (Basic Authentication) in der IIS-Konfiguration auch aktiviert sein. Mehr Informationen zu diesem Thema finden Sie im Helpdesk.
Installation des Agenten
So kann zum Beispiel das .deb-Paket für Ubuntu und das .rpm-Paket für CentOS verwendet werden. Um den Agenten zu installieren, sollte wie folgt vorgegangen werden:
- Transferieren des gewünschten Pakets auf die Linux-Maschine (z.B. via WinSCP)
- Installieren Sie
- das .deb-Paket mittels
sudo apt install /path/to/package/name.deb
- das .rpm-Paket mittels
rpm -i /path/to/package/name.rpm
Bekanntes Problem: Dasrpm
-Kommando könnte sich über fehlendeperl
-Abhängigkeiten beschweren. In diesem Fall bitte--nodeps
an die Kommandozeile anfügen.
- das .deb-Paket mittels
- Durch die Installation wurden
- ein Inventarisierungs-Skript
loginfo.sh
angelegt (/opt/loginfox/loginfox.sh
) - ein täglicher Cronjob angelegt, der die Erfassung um 10:00 Uhr startet und im Anschluss die .inv-Datei überträgt (
/etc/cron.d/loginfox
)
- ein Inventarisierungs-Skript
- Um die automatische Übertragung der Dateien zu aktivieren, müssen noch die Inhalte von zwei Dateien angepasst werden:
- Die Upload-URL unter der die bei der Erfassung entstehende .inv-Datei abgelegt werden soll (z.B. OfflineAgent.aspx):
/etc/loginfox/loginfox_url.config
z.B.http://my-inventory-server/LOGINventory9/OfflineAgent.aspx
- Die Credentials, die für die den Zugriff auf die Upload-URL verwendet werden sollen:
/etc/loginfox/loginfox.config
z.B.--user ACCOUNT@DOMAIN:PASSWORD
- Die Upload-URL unter der die bei der Erfassung entstehende .inv-Datei abgelegt werden soll (z.B. OfflineAgent.aspx):
Weiter Hinweise zur Einrichtung der Upload-URL finden sich auch bei der Beschreibung des Windows Offline Agenten.
Manuelle Datenübertragung
Falls Ihr Linux-System keine .deb-Pakete oder .rpm-Pakete unterstützt, können Sie auch selbst eine .tgz-Datei auf ein entsprechendes Gerät kopieren, entpacken und ausführen. Die entstehende .inv-Datei muss dann manuell zurück kopiert werden, bzw. eine Übertragung selbst eingerichtet werden.
Dazu kann die Datei loginfo.tgz aus dem Unterordner LoginfoXScripts auf der Linux Maschine mittels tar xfz loginfo.tgz
entpackt werden. Die Erfassung wird dann mittels ./loginfox.sh
gestartet.
macOS Offline Agent
Achtung: Voraussetzung zur Übertragung
Beachten Sie, dass bei der Verwendung von http(s) zur Datenübertragung an den IIS-Server dieser so konfiguriert sein muss, dass er die Daten empfangen kann. Wenn nur Windows-Geräte Daten an den Server schicken, genügt die Aktivierung der Windows-Authentifizierung. Sollen auch macOS- / Linux-Geräte mit dem Offline Agenten ausgestattet werden, muss die Standard-Authentfizierung (Basic Authentication) in der IIS-Konfiguration auch aktiviert sein. Mehr Informationen zu diesem Thema finden Sie im Helpdesk.
Einrichtung
Durch die Veröffentlichung des Windows Offline Agenten wird ein Verzeichnis erzeugt, in dem sich die benötigten Setup-Dateien befinden. Dabei steht auch ein Unterordner "macOS", in dem sich die Dateien zur Installation auf macOS befinden.
Zur Installation auf macOS werden die beiden Dateien loginfox.config und loginfox-macos-installer(version).pkg benötigt.
In der loginfox.config ist dabei hinterlegt, wohin der macOS-Agent seine inv-Dateien schicken soll. Dabei werden die im Veröffentlichungs-Prozess im Reiter "Öffentlich" hinterlegte URL und Passwort verwendet und diese verschlüsselt in der Datei hinterlegt. Falls die URL oder Benutzer / Passwort geändert werden sollen, empfiehlt es sich den Veröffentlichungs-Dialog erneut zu durchlaufen, woraufhin die loginfox.config aktualisiert wird. Die verschlüsselten Informationen werden durch die Installation unverschlüsselt auf dem macOS-Gerät im Verzeichnis "/Library/loginfox/(version)/" hinterlegt, damit sie für die Übertragung verwendet werden können. Die Rechte zum Einsehen der Datei wurden jedoch auf das Nötigste beschränkt.
Alternativ kann auch im Klartext in der loginfox.config hinterlegt werden, wohin die inv-Dateien geschickt werden sollen und mit welchem Benutzer die Übertragung stattfinden soll, indem folgende Syntax verwendet wird:
--user usr:pwd
--url https://{ADDRESS}{:PORT}/{UPLOAD-URL}
also z.B.
--user OfflineAgent@domain.local:MyPassword123
--url https://inventoryserver/LOGINventory9/OfflineAgent.aspx
Achtung
Die Übertragung der Dateien vom Offline Agenten zum Zielserver kann ausschließlich via http(s) erfolgen, nicht via fileservice oder anderen Methoden.
Zur Installation auf dem macOS-Gerät müssen also die beiden Dateien loginfox.config und loginfox-macos-installer(version).pkg auf das Zielgerät in das Verzeichnis "/Users/Shared" kopiert werden.
Gefahr
Wenn nicht das Verzeichnis "/Users/Shared", sondern die Verzeichnisse "Downloads", "Documents" oder "Desktop" verwendet werden, kann es zu Sicherheits-Fehlern während der Installation kommen und diese schlägt möglicherweise fehl!
Um das Setup zu starten, kann entweder ein Doppelklick auf die pkg-Datei gemacht werden und der Installations-Wizard durchlaufen werden, oder folgender Befehl in einem Terminal-Fenster ausgeführt werden:
sudo installer -pkg /path/to/package.pkg -target /
Nach der Installation können die Setup-Dateien gelöscht werden.
Arbeitsweise
Der installierte Offline Agent besteht aus mehreren Komponenten:
- Inventarisierungs-Skript: Die Datei "/Library/loginfox/(version)/loginfox.sh" führt die Inventarisierung des macOS-Geräts durch
- Automatismus zum regelmäßigen Ausführen: Täglich um 10 Uhr wird der Offline Agent durch einen
launchd
-Prozess gestartet: "/Library/LaunchDaemons/com.loginventory.loginfox.plist" - Übertragung der inv-Datei: Die entstehende inv-Datei wird zur vorkonfigurierten http(s)-URL via
curl
-Befehl durch die loginfox.sh-Datei übertragen (siehe Einrichtung)
Achtung
Im Gegensatz zum Windows Offline Agenten verfügt der macOS Offline Agent über keinen Selfupdate-Mechansimus! Das bedeutet, dass der macOS Agent ggf. händisch aktualisiert werden muss, wenn sich die Erfassungslogik oder das Datenmodell mit einer neuen Version geändert haben.
Tipp
Sie können beim jeweiligen Gerät sehen, wie dieses erfasst wurde, indem Sie die Werte bei LastInventory.Method
und LastInventory.Agent
prüfen. Wenn ein Gerät mit einem macOS Offline Agenten in der Version "9.2.2.15136" erfasst wurde, sehen die Werte beispielsweise wie folgt aus:
Bei einem macOS-Gerät, das agentenlos erfasst wurde, würde hier stattdessen LastInventory.Method = SSH
und LastInventory.Agent = LOGINfoX 9.2.2.15136
stehen.
Softwarenutzungs-Auswertung mit LOGINuse
Standardmäßig verwendet LOGINventory zur Ermittlung des Zeitpunkts der letzten Benutzung einer Anwendung die entsprechende Windows Explorer Statistik („Last recently used“ bzw. „Zuletzt geöffnete Programme“). Diese Statistik ist bei allen unterstützten Windows Betriebssystemen ab 2000 im jeweiligen Benutzerkontext vorhanden, berücksichtigt jedoch nur die über Startmenü, Desktop oder Explorer gestarteten Anwendungen - also nicht den Taskbar!
Info
LOGINventory bietet mit Hilfe des eigens entwickelten Benutzungsstatistik-Agenten LOGINuse die Möglichkeit herauszufinden, welche Software in Ihrer Firma tatsächlich von wem genutzt wird. Somit können insbesondere teure, ungenutzte Software-Pakete identifiziert und der Lizenzbestand reduziert werden. Damit unterstützt Sie LOGINventory bei der Minimierung von unnötigen Ausgaben für teure Software-Lizenzen.
Zusätzlich bietet LOGINventory auch einen eigenen Benutzungsstatistik-Agenten: LOGINuse. Damit werden alle benutzten Anwendungen (.exe, .jar, und .bat) (z.B. auch über Kommandozeile) von allen Benutzern eines Rechners erfasst. Dies funktioniert u.a. auch auf Terminalservern. LOGINuse sammelt seine Informationen in einer eigenen lokalen Datenbank. Wenn ein Programm das dritte Mal gestartet wurde und jeweils mindestens 10 Sekunden gelaufen ist, wird dieses Programm als „benutzt“ notiert. Diese Daten werden bei der normalen Inventarisierung des Systems eingesammelt und in die LOGINventory-Datenbank übertragen. Falls LOGINuse Daten zur Verfügung stehen, werden eventuell vorhandene Daten in der Windows-Statistik für dieses System ignoriert!
Achtung
Das bedeutet, dass ohne die Verteilung des Software-Nutzungs-Agenten die Daten im Lizenzmanagement bei der Nutzungsauswertung mit Vorsicht zu bewerten sind! Nur wenn der Agent verteilt wurde, sind die Daten zuverlässig!
Info
Die Auswertung der Daten geschieht stets im Lizenzmanagement.
Installation
LOGINuse wird in einer MSI-Datei mitgeliefert, die in einen zentralen InstallationsPunkt (AIP) kopiert werden sollte. Von dort aus erfolgt die Verteilung auf die Client-Systeme z.B. über Group-Policies oder einen anderen der vorhandenen Mechanismen.
Info
Um die Software-Nutzungsüberwachung für die Verteilung bereitszustellen, kann über das Ribbon-Menü unter Extras die entsprechende Option aufgerufen werden.
Da LOGINuse eine 32-Bit-Applikation ist, wird das Programm auf den 64-Bit Systemen unter dem Pfad %ProgramFiles(x86)%\LOGIN installiert. Zudem wird ein automatisch startender Dienst LOGINuse Service konfiguriert (Anmeldung mit dem lokalen Systemkonto). Wie bei allen MSI-Setups sollte die Original-MSI-Datei nach der Installation aufgehoben werden, um ggf. LOGINuse wieder deinstallieren zu können.
Info
Solange keine Änderungen am LOGINuse Programm vorgenommen werden, bleibt die Versionsnummer im Namen unverändert, d.h. LOGINuse braucht nicht mit jedem LOGINventory-Update neu ausgerollt zu werden, solange die LOGINuse-Versionsnummer sich nicht ändert.
Regeln zur Erfassung
Für die Erfassung von LOGINuse gelten folgende Regeln:
- Es werden nur interaktive Prozesse erfasst, die im User-Kontext laufen.
- Es werden nur Prozesse erfasst, die außerhalb von %SYSTEMROOT% (inkl. Unterverzeichnisse) gestartet wurden.
- Es werden nur Prozesse erfasst, die mehr als 10 Sekunden Laufzeit zwischen Start und Stopp haben.
- Es werden nur Prozesse erfasst, die mindestens dreimal den o.a. Bedingungen entsprechen.
- Sichtbar sind die Ergebnisse frühestens 8 Stunden später in der LOGINventory-Datenbank!
Mit diesen Regeln soll erreicht werden, dass nur die echte Benutzung von Software-Paketen berücksichtigt wird, also:
- nur Pakete gezählt werden, die nicht in Windows enthaltenen sind
- ein versehentlicher Start (mit sofortigem Stopp) nicht erfasst wird
- der Funktionstest nach der Installation nicht erfasst wird
- keine unmittelbare Überwachung der Benutzer erfolgen kann
Beispiele:
Aktion | Ergebnis |
---|---|
Notepad, Explorer, Regedit benutzen | wird niemals erfasst |
Einmal alle Office Applikationen starten und gleich wieder schließen | wird nicht erfasst |
Dreimal Microsoft Excel starten, jeweils mindestens 11 Sekunden laufen lassen | Die Software-Nutzungsdaten sind nach frühestens 8 Stunden in LOGINventory sichtbar |
Auslesen unterdrücken
Das Auslesen der LOGINuse-Datenbank während des Scannens kann unterbunden werden über den Schalter //NoLoginUse 1
. Der Schalter kann entweder als Kommandozeilen-Parameter in der Scan-Definiton bzw. für das Programm LOGINfo.exe gesetzt werden, oder über die Datei LOGINfo.script.
Info
Falls nur verhindert werden soll, dass die Programm-Nutzungsinformationen aus der Windows Explorer Statistik gesammelt werden, kann der Schalter !SET Ignore=ProgramUsage
in die LOGINfo.script-Datei eingefügt werden. Dann werden nur noch die Daten des Nutzungsagenten gesammelt.
Konfiguration des Daten-Verzeichnisses
Wenn nicht anders konfiguriert, schreibt LOGINuse seine Daten in das Verzeichnis%ProgramData%\LOGIN\LOGINventory\9.0\LOGINuse
. Dies lässt sich pro Rechner umkonfigurieren, indem folgender Registry-Wert angelegt und gesetzt wird: HKLM\Software\LOGIN\LOGINuse, DataLocation
. Dies kann zum Beispiel über folgende Kommandozeile (als Administrator) geschehen:
C:\> reg add HKLM\Software\LOGIN\LOGINuse, /v DataLocation /t REG_SZ /d "d:\LoginUseData" /f
Bei einer Deinstallation wird die lokale Datenbank gelöscht. Falls dies nicht erwünscht ist (z.B. weil im Anschluss eine Neuinstallation geplant ist), sollte zuvor ein Backup des lokalen Daten-Verzeichnisses angefertigt werden.
Manuelles Einfügen von Daten
Neben den verschiedenen automatisierten Verfahren gibt es auch die Möglichkeit, Daten manuell in LOGINventory einzufügen.
Lokale Erfassung mittels USB-Stick
Falls Sie Windows-Geräte nicht Remote oder per Logon-Script erfassen können, da diese gar keine Netzwerkkarte haben oder deren APIs das Vorgehen nicht unterstützen, können Sie sich auch die LOGINfo.exe auf einen USB-Stick kopieren und diese am zu erfassenden Rechner ausführen. Dabei gehen Sie am besten wie folgt vor:
- Kopieren Sie das Datenverzeichnis inklusive LOGINfo.exe (normalerweise zu finden unter C:\Users\Public\Documents\LOGIN\LOGINventory 9\Data) auf einen USB-Stick.
- Entfernen Sie den USB-Stick vom LOGINventory Rechner, gehen zum isolierten PC und stecken den USB-Stick ein.
- Starten Sie den Windows Explorer, navigieren zum USB-Stick, starten die LOGINfo.exe und warten, bis eine .inv-Datei auf Ihrem USB-Stick erstellt wurde.
- Entfernen Sie den USB-Stick wieder vom isolierten PC und gehen zurück zum LOGINventory Rechner.
- Kopieren Sie die neue .inv-Datei in das Datenverzeichnis des LOGINventory Rechners.
- Vergewissern Sie sich, dass der Dienst LOGINventory Data Service läuft und die Daten in die Datenbank eingetragen werden (die .inv-Datei verschwindet nach kurzer Zeit).
Info
Natürlich lassen sich auch mehrere Rechner so erfassen und die .inv-Dateien von allen erfassten Geräten werden dann erst gesammelt ins Datenverzeichnis kopiert.
Manuelles Anlegen von Assets
Assets können über zwei unterschiedliche Benutzeroberflächen selbst angelegt werden: Um schnell und einfach ein oder mehrere Assets mit grundlegenden Eigenschaften anzulegen empfiehlt sich die Verwendung des Asset-Editors.
Falls zum manuell angelegten Asset 1:n-Beziehungen, wie z.B. die vorhandenen Software-Pakete hinterlegt werden sollen, ist dies nur mittels LOGINject möglich (veraltet).
Tipp
Falls Daten zu mehreren Assets aus Excel-Listen oder csv-Dateien eingelesen werden sollen, ist die Verwendung des Daten-Imports empfohlen.
Asset-Editor
Über das Ribbon-Menü kann ein Neues Asset angelegt werden, falls Sie sich unterhalb des Asset-Management-Knotens befinden.
Beim Anlegen von manuellen Assets kann zwischen drei vordefinierten Typen gewählt werden: Computer, Mobil, Peripherie-Gerät.
Info
Für das händische Anlegen von eigentlich scanbaren Geräten (Device / Mobil) wird wie bei jedem scanbaren Gerät eine "normale" Asset-Lizenz benötigt. Da auf diese Weise auch Geräte angelegt werden, die sich noch im Zulauf befinden ("Prestaging"), kann jederzeit durch einen erfolgreichen Scan das händisch angelegte Asset durch gescannte Informationen erweitert werden.
Anders verhält es sich bei Peripherie-Geräten: Diese benötigen eine Peripherie-Asset-Lizenz.
Je nach ausgewählten Typ stehen andere - für den jeweiligen Typ relevante - Felder zum Befüllen zur Verfügung. Bei Katalog-Einträgen, wie z.B. Asset-Modell oder Betriebssystem-Informationen haben Sie die Möglichkeit aus den bisher in der Datenbank vorhandenen Einträgen auszuwählen oder auch neue Einträge anzulegen.
Durch einen Klick auf OK wird das Asset angelegt. Falls noch ein weiteres ähnliches Gerät angelegt werden soll, kann oben rechts auf das Save & Next-Symbol geklickt werden. Dadurch werden alle bisher befüllten Einträge übernommen, bis auf den Namen.
Tipp
Auf diese Weise ist es möglich schnell mehrere ähnliche Assets anzulegen.
Falls ein manuell angelegtes Gerät editiert werden soll, ist dies möglich, indem das Gerät in der Datenansicht gewählt und dann im Ribbon-Menü Asset Bearbeiten ausgewählt wird.
Info
Falls Eigene Eigenschaften befüllt werden soll, ist dies ganz normal - wie bei jedem anderen Asset auch - über das Eigene Eigenschaften - Widget möglich.
Tipp
Falls Geräte, die nicht erfolgreich erfasst werden konnten (z.B. IP-Telefone, Fernseher, etc.) auch als Asset angelegt werden sollen, kann aus der Liste der nicht erfolgreich erfassten Geräte (Fehlerhafte Inventarisierung im Ordner Fehleranalyse) aus dem Ribbon-Menü die Aktion In Asset umwandeln ausgewählt werden. Daraufhin werden die Daten, die bei der fehlerhaften Erfassung gesammelt werden konnten (Name, IP, Hersteller) direkt übernommen und aus dem "fehlerhaften" Asset wird ein "vollwertiges" Asset.
Anlegen von Peripherie-Geräten
Beim Anlegen von Peripherie-Geräten gibt es einige Besonderheiten zu beachten. Alle eingangs erwähnten Anmerkungen gelten aber weiterhin.
Info
LOGINventory kann durch die Erfassung von Geräten bereits Informationen zu verbundener Peripherie erfassen. Es gibt jedoch gute Gründe, diese Geräte als eigenständige Peripherie-Geräte in LOGINventory anzulegen:
- Standardmäßig sind die Informationen zu verbundenen Geräten "flüchtig", d.h. wenn ein Monitor oder USB-Gerät abgesteckt wird, gehen die Informationen erst einmal verloren, da sie "aktuell nicht mehr verbunden sind" (in der Änderungshistorie tauchen Sie ggf. weiterhin auf).
- Beim Umwandeln in ein Peripherie-Gerät können Informationen hinterlegt werden, die sich nicht durch den Scan eines PCs vom verbundenen Gerät auslesen lassen, z.B. Seriennummer, Modell-Bezeichnung etc.
- Wenn an den verbundenen Geräten Zusatz-Informationen, wie Eigene Eigenschaften, Rechnungen (im Dokumente-Widget) etc. hinterlegt werden sollen, müssen diese als eigenständiges Gerät in LOGINventory existieren.
- Wenn für das Gerät ein eigenes Etikett gedruckt werden soll, muss es als Peripherie-Gerät angelegt sein und somit eine eindeutige Inventarnummer erhalten.
- Wenn die Ausgabe und Rücknahme des Geräts an einen User mittels Smartphone dokumentiert werden soll, muss für das Gerät eine eigene Web-Seite vorhanden sein - dies ist nur für explizit angelegte (oder automatisiert erfasste) Geräte der Fall.
Um Peripherie-Geräte anzulegen, kann entweder, wie oben beschrieben, über Neues Asset der Asset-Editor geöffnet werden, oder es können bei bestimmten Datentypen die Informationen zu verbundenen / verbauten Geräten übernommen werden. Dazu zählen:
- Monitore
- Docking Stations
- Festplatten / Laufwerke / USB-Sticks
- via USB oder Bluetooth angeschlossenen Geräte
Tipp
Wechseln Sie dazu zu einer Abfrage, die die oben genannten Datentypen anzeigt oder expandieren Sie die Details eines einzelnen Assets und dann zu "Docking Stations" oder unter "Hardware" zu "Monitore", "Laufwerke" oder "USB-Geräte". Wenn Sie dann in der Daten-Ansicht eine oder mehrere Ergebniszeilen auswählen, steht im Ribbon-Menü die Option Peripherie-Gerät Erzeugen zur Verfügung. Wird nur eine Ergebniszeile selektiert und die Option Peripherie-Gerät Erzeugen im Ribbon-Menü gewählt, können die Details des neu anzulegenden Peripherie-Geräts direkt bearbeitet werden. Im Fall der Multiselektion werden alle Geräte direkt angelegt und können, wie oben beschrieben, im Nachgang bearbeitet werden.
Info
Das Feld "Eigener Typ" befüllt die Eigene Eigenschaft "CustomType". Dieses Feld sollte dazu verwendet werden, den Typ des Geräts (z.B. Headset, Webcam, Dockingstation, etc.) zu spezifizieren. Falls ein Name gewählt wird, zu dem im Resource Repository ein Bild mit gleichem Namen hinterlegt ist, erscheint das entsprechende Icon u.a. im Info-Widget.
Alle angelegten Peripherie-Geräte sind dann u.a. in der Abfrage Peripherie-Geräte sichtbar.
Tipp
Falls Sie Auswertungen erstellen möchten, die sowohl gescannte Assets, als auch Peripherie-Geräte enthält, nutzen Sie die Basistabelle HardwareAsset
(siehe Klassenhierarchie "HardwareAsset").
Veraltet: LOGINject
Achtung
Dieses Modul ist veraltet und wird nicht mehr weiterentwickelt. Wir empfehlen die Verwendung des Asset-Editors.
Über das Ribbon-Menü unter Extras kann der Assistent LOGINject zum Manuellen Anlegen von Assets gestartet werden, wenn im Baum zu Asset-Management (oder unterhalb) navigiert wurde.
Bei 1:1-Beziehungen können die entsprechenden Felder direkt befüllt werden.
Bei Katalogeinträgen (z.B. Software-Pakete) können bestehende Einträge auf der rechten Seite per Drag & Drop ausgewählt werden. Falls ein bisher nicht in der Datenbank existierender Eintrag geschrieben werden soll, muss dieser ebenfalls zunächst auf der rechten Seite in eine freie Zeile geschrieben werden und kann dann dem Gerät zugeordnet werden.
Über die Funktion Datei → Asset speichern werden die Daten direkt in die LOGINventory-Datenbank übertragen.
Einlesen von Assets, Lizenzen und Eigenen Eigenschaften aus csv-Dateien
Wichtig
Daten, die sich in csv-Dateien befinden, können von LOGINventory automatisch eingelesen und importiert werden, indem diese im Datenverzeichnis abgelegt werden. Dazu muss zuvor ein Mapping zwischen eingelesenen Daten und den Spalten in LOGINventory definiert werden, damit die Werte richtig zugeordnet werden.
Wenn das Mapping richtig angelegt wurde können so sowohl Assets angelegt, Eigene Eigenschaften (wie z.B. "Owner") eingelesen werden oder Lizenzen inklusive deren Eigenschaften importiert werden.
Um ein Mapping zu definieren, kann der Daten-Import aus dem Ribbon-Menü Extras aufgerufen werden. Daraufhin kann eine csv-Datei aus einem beliebigen Speicherort gewählt werden, um eine Import-Definition anzulegen. Für jeden Import muss ein eindeutiger Name vergeben werden und es muss eine Tabelle aus dem LOGINventory-Datenmodell ausgewählt werden, in der sich der Schlüssel für die Daten befindet.
Beispiel
Für den Import von Daten zu Assets oder eigenen Eigenschaften, die sich auf Geräte beziehen, muss die Tabelle "Device" gewählt werden, für Peripherie-Geräte die Tabelle "PeripheralDevice". Falls Daten zu Lizenzen eingelesen werden sollen, kann der entsprechene Lizenztyp ausgewählt werden. Eine Übersicht der verfügbaren Lizenztypen und deren Eigenschaften sind im Lizenzmanagement zu finden.
Abhängig von der ausgewählten Tabelle stehen dann bei der Zuordnung unterschiedliche Zielspalten zur Verfügung.
Beim Einlesen von Assets kann in den Spalten Editierbar und Subtyp eine Einstellung vorgenommen werden: Wenn die neu einzulesenden Geräte im Nachgang über den Asset-Editor editierbar sein sollen, muss der Haken bei Editierbar gesetzt sein. Ausschließlich, wenn die Tabelle Device gewählt wird, kann ein Subtyp ausgewählt werden, der bestimmt, mit welchem Asset-Editor das Gerät im Nachhinein editiert werden soll: Handelt es sich um ein normales Gerät, muss kein Subtyp selektiert werden, handelt es sich um ein Smartphone oder Tablet, muss der Subtyp "Mobile" selektiert sein.
Info
Die Spaltennamen in der Quelldatei dürfen nicht mit einer Zahl beginnen und weder Leerzeichen, noch Sonderzeichen wie /
, \
, ?
etc. enthalten.
Der Import unterstützt alle gängigen Formate UTF7, UTF8, Unicode (UTF-16LE), BigEndianUnicode (UTF-16BE), UTF32 korrekt. Default ist die Betriebssystem Ansi-Codepage, die z.B. Excel schreibt. Um die oben genannten Formate zu erkennen, MUSS aber die sog. Byte-Order-Mark (BOM) gesetzt sein. In Notepad++ findet man sowohl UTF8 als auch UTF8 BOM und nur letztere funktioniert, da sonst nämlich gar keine Information in den Datei-Header geschrieben wird und folglich auch kein Encoding erkannt werden kann.
Also kurz zusammen gefasst: Entweder mit BOM oder es wird die Standard Code Page versucht.
Hinweis
Damit beim Einlesen von Daten die Zuordnung, bzw. das Updaten von bestehenden Daten richtig funktioniert, muss stets ein sogenannter "Key" vorhanden sein, anhand dessen ein Eintrag eindeutig identifiziert wird. Beim Einlesen von Assets ist dieser Key das Feld Device.Name
. Sollen Lizenzen eingelesen werden, ist der Key das Feld License.Number
. Falls in den Quelldaten keine solche ID einer Lizenz vorhanden ist, werden aushilfsweise die Felder Name
, Version
, Manufacturer
, End
und Begin
als Kombination verwendet. Das heißt, wenn keine ID vorhanden ist und sich eines dieser Felder gegenüber einem vorherigen Import ändert, kann es sein ,dass ein Lizenz-Duplikat angelegt wird.
Info
Nur 1:1-Beziehungen können eingelesen werden! Es ist also nicht möglich zu einem Gerät einzulesen, welche Programme alle auf diesem Gerät vorhanden sind (1:n-Beziehung).
Wenn die Zuordnung erfolgreich durchgeführt wurde, kann durch einen Klick auf Übernehmen die Datei eingelesen werden.
Wichtig
Mit Hilfe des Datei-Filters kann der Dateiname mit Wildcards angepasst werden. Wenn also aus "MeineMappe.csv" "Meine.csv" gemacht wird, werden in Zukunft alle Dateien, die mit "Meine" beginnen und ".csv" enden, automatisch eingelesen*, sobald sie in das Datenverzeichnis kopiert werden. Deshalb lassen sich auch unterschiedliche Import-Definitionen anlegen, um unterschiedliche Daten (Unterscheidung anhand des Dateinamens) unterschiedlich zu behandeln.
Info
Falls Eigene Eigenschaften zu Assets eingelesen werden sollen, muss sichergestellt sein, dass die eigene Eigenschaft bereits existiert, da sie sonst bei der Zuordnung nicht ausgewählt werden kann. Im Zweifelsfall kann die entsprechende eigene Eigenschaft zunächst angelegt und dann der Import erneut gestartet werden.
Info
Falls Datumswerte eingelesen werden sollen, muss darauf geachtet werden, dass diese im englischen Format (MM.DD.YYYY) in der Quelldatei hinterlegt sind. Das bedeutet, dass der 15.Januar 2019 als "01.15.2019" oder "01/15/2019" in der Datei eingetragen ist.
Beispiel: Einlesen und Zuordnen von Lizenzen
Wie bereits oben erwähnt, werden Lizenzen anhand des Feldes License.Number
eindeutig identifiziert. Da auch Software-Versionen in Kombination mit dem Produkt-Namen (SoftwareAsset.CustomId
) eindeutig identifiziert werden können, lassen sich Lizenzen beim Einlesen auch direkt dem richtigen Produkt und der richtigen Version zuweisen. Um herauszufinden, wie die CustomId einer Software-Version lautet, kann z.B. in die Abfrage "Alle Versionen" unterhalb von "Auswertungen" geschaut werden. Typischerweise ist die CustomId jedoch der Produkt-Name in Kombination mit dem Versions-Namen (durch ein Leerzeichen getrennt).
So lässt sich beispielsweise folgende Quelldatei einlesen:
Daraufhin kann im Datenimport folgendes Mapping verwendet werden:
Modifikation der Datenermittlung
Die standardmäßig ermittelten Daten lassen sich durch eigene Regeln erweitern. Dazu benutzen die agentenlosen Scans und die Erfassung mittels Logon-Script mit LOGINfo.exe die Datei LOGINfo.script; diese Datei befindet sich im Unterverzeichnis Script des Datenverzeichnisses (standardmäßig C:\Users\Public\Documents\LOGIN\LOGINventory 9\Data
). Diese Script-Datei wird bei jeder Inventarisierung eines Assets ausgewertet. Das bedeutet, dass alle Anpassungen hier den gesamten Erfassungsprozess beeinflussen.
Achtung
Dies gilt nicht für die Erfassung von Linux-basierenden Systemen. Für diese ist eine andere Form der Modifikation möglich, wie unten beschrieben.
Wichtig
Wenn die LOGINfo.exe über die Kommandozeile aufgerufen wird, kann auch ein Zielverzeichnis angegeben werden (siehe Parameter). Die LOGINfo.script wird dabei stets im Unterodner "Script" des Zielverzeichnisses gesucht. Ist kein Zielverzeichnis angegeben, wird der Speicherort der LOGINfo.exe als Zielverzeichnis verwendet. Im Zielverzeichnis entsteht die .inv-Datei.
Beispiel
Somit lassen sich also auch eigene OIDs von SNMP-Geräten auslesen, sodass für jedes Gerät die Informationen angezeigt werden, die Sie wirklich interessieren. Viele Hersteller publizieren ihre MIBs online, sodass Sie einfach nachschauen können, wo die Daten stehen, die Sie interessieren, und dann die entsprechenden Befehle in die Skript-Datei einfügen.
In dieser Script-Datei können
- über !SET-Befehle Schalter gesetzt werden, die vor der Inventarisierung ausgewertet werden und diese so beeinflussen können. Über diese Schalter lassen sich z.B.
- die Timeouts für die Inventarisierung anpassen
- das Lesen von zusätzlichen Informationen (wie z.B. Schriftarten) aktivieren
- das Lesen von bestimmten Informationen während der Inventarisierung abschalten (z.B. Programm-Usage Daten, Netinstall-Pakete, Software Uninstall Informationen, Dienste)
Dazu müssen die nicht mehr zu erfassenden Daten mit einem Komma getrennt aufgelistet werden, also z.B.!SET Ignore=BootLog,Event
- über zusätzliche Kommandos die Daten nach der Inventarisierung modifizieren:
- Über Bedingungen und Vergleiche können Werte eingegrenzt werden.
- Eigene (frei definierbare) Eigenschaften können Asset-bezogen zugeordnet werden, z.B. „Standort“-Informationen, Umgebungsvariablen, Werte aus WMI oder der Registry, bestimmte Dateieigenschaften.
-
einfache Eigenschaften der LOGINventory-Datenbank können direkt geändert werden, z.B. kann der Wert für den Namen der gelesenen CPU geändert oder überschrieben werden.
-
Über das Kommando
Cpu.Name=%$Cpu.Name% X1234
wird z.B. aus dem EintragAMD Athlon™ 64 X2 Dual Core Processor
→AMD Athlon™ 64 X2 Dual Core Processor X1234
-
Einträge von Listeneinträgen können hinzugefügt, modifiziert oder entfernt werden.
- Das Kommando
!Modify NetworkAdapter Name=Broadcom NetXtreme-Gigabit-Ethernet, Name=Gigabit, DefaultGateway=10.11.12.14
ändert z.B. in dem Netzwerk-Adapter Eintrag mit Namen „Broadcom NetXtreme-Gigabit-Ethernet“ den Namen und den Eintrag für das Default-Gateway
-
Die Namen der Eigenschaften entsprechen den Spaltenüberschriften in LOGINventory.
Verfügbare Kommandos
Befehl | Erläuterung | Beispiel |
---|---|---|
; oder # |
Kommentar | ; so oder # so fangen Kommentarzeilen an |
!Include Dateiname |
Über Include-Befehle haben Sie die Möglichkeit weitere Steuerdateien einzubinden, die sich im gleichen Verzeichnis befinden. Damit können Sie Regeln für bestimmte Bereiche oder Themen in eigene .script-Dateien zusammenfassen und so die Einträge besser strukturieren und übersichtlicher gestalten. | !Include ProductKeys.script |
!IF {regexist/ fileexist/ direxist/ oidexist:Pfad Aktion !ENDIF |
Abfrage auf Vorhandensein | !IF{regexist:HKEY_LOCAL_MACHINE\Software\Oracle8} !ADD SoftwarePackag Name=Oracle,Version=8,Publisher=Oracle !ENDIF |
!Stop |
Inventarisierung abbrechen (z.B. zum Ausschluss von Rechnern aus der Inventarisierung) | Falls der Registry-Wert »WERK« nicht den Wert B96 hat, wird dieser Rechner nicht inventarisiert: !IF {ne:{reg:HKEY_LOCAL_MACHINE\SOFTWARE\SMS-IC\Userinfo,Werk},B96} !STOP !ENDIF |
eq/ ne/ lt/ le/ gt/ ge/ like/ notlike |
Vergleiche: gleich/ nicht gleich /kleiner /kleiner oder gleich /größer / größer oder gleich/ ähnlich wie /nicht ähnlich wie | !IF {eq:%$LastInventory.IP%,192.168.200.157} Custom.Stellplatz=R4.192 Custom.Druckername=Buchhaltung !ENDIF |
and/ or not |
Boolsche Operatoren: und/ oder/ nicht | !IF{and:{fileexist:%SYSTEMROOT%\win.ini}, {regexist:HKEY_LOCAL_MACHINE\Software\MySoft}} !STOP !ENDIF |
!FindFiles <PFAD> & !FindFilesRec <PFAD> |
File-Suche und rekursive File-Suche (siehe Asset-Inventarisierung) | !FindFiles C:\Temp |
Schalter
In die LOGINfo.script-Datei können Schalter eingefügt werden, um den Erfassungsprozess weiter anzupassen. Dazu kann folgende Syntax verwendet werden: !SET Befehl=Wert
. Viele der angebotenen Einstellungen sind auch in den jeweiligen Scan-Definitionen direkt einstellbar.
Info
Die im Folgenden vorgestellten Werte können auch jeweils als Kommandozeilen-Argumente benutzt werden. Dabei ist jeweils ein //
vorne anzustellen und anstatt einer Zuweisung durch ein =
genügt ein Leerzeichen, also z.B. LOGINfo.exe //TotalTimeout 300
.
Achtung
Alle in der LOGINfo.script-Datei gesetzten Schalter werden durch Kommandozeilen-Argumente überschrieben!
Befehl | Erläuterung | Default-Wert | Beispiel |
---|---|---|---|
AllCertificates = [0|1] |
Auslesen von allen Zertifikaten, die auf dem Computer gefunden werden können und nicht nur von den Zertifikaten aus dem SystemStore "My" | 0 | !SET AllCertificates=1 |
AllGroups = [0|1] |
Alle Gruppen erfassen: Standardmäßig werden nur die Mitglieder der lokalen Gruppe "Administratoren" erfasst. Um alle lokalen Gruppen zu erfassen, kann dieser Schalter verwendet werden. | 0 | !SET AllGroups=1 |
AllowOidsOutOfOrder = [0|1] |
Auszulesende OIDs müssen vom SNMP-Gerät nicht in aufsteigender Form geliefert werden; diese Option verlangsamt die Erfassung erheblich. | 0 | !SET AllowOidsOutOfOrder=1 |
AllowWindowsSnmp = [0|1] |
SNMP-Scan für Windows-Rechner aktivieren | 0 | !SET AllowWindowsSnmp=1 |
BootLogEntries = ZAHL |
Standardmäßig werden bei der Erfassung nur die letzten 50 BootLog-Einträge (Hochfahren und Herunterfahren eines Rechners) erfasst. Die Liste der BootLog-Einträge wird jedoch kumuliert. | 50 | !SET BootLogEntries=100 |
ConnectionsMaxLocalPort = ZAHL |
Standardmäßig werden bei der Erfassung der Netzwerkverbindungen alle diejenigen herausgefiltert, bei den LocalPort >11000 ist. Damit wird erreicht, dass prinzipiell nur eingehende Verbindungen erfasst werden. | 11000 | !SET ConnectionsMaxLocalPort=65000 |
DontScanCurrent UserUninstall = [0|1] |
Software Uninstall Key nicht erfassen für den aktuellen Benutzer | 0 | !SET DontScan CurrentUserUninstall=1 |
DontScanNetinstall = [0|1] |
Keine Enteo Netinstall-Pakete erfassen. Die Software-Verteilung Enteo Netinstall schreibt in bestimmte Registry-Keys zusätzliche Einträge, wenn ein Paket verteilt wird. Wenn dieser Schalter verwendet wird, werden die zusätzlichen Einträge nicht mehr erfasst (die entsprechenden Registry Keys werden nicht durchsucht). Die tatsächlich installierten Pakete werden jedoch weiterhin erfasst. | 0 | !SET DontScanNetinstall=1 |
DontScanServices = [0|1] |
Dienste nicht erfassen | 0 | !SET DontScanServices=1 |
DontScanUninstall = [0|1] |
Software Uninstall Key nicht erfassen für den Computer | 0 | !SET DontScanUninstall=1 |
EnableSnmpAlways = [0|1] |
SNMP erzwingen: Ignorieren von Windows APIs | 0 | !SET EnableSnmpAlways=1 |
ForceAllPossibleData = [0|1] |
Wird dieser Schalter verwendet, werden die sehr wahrscheinlich unvollständigen Daten der Dienste (Entität: Service ) & Geplanten Tasks (Entität: ScheduledTask ) erfasst. Dabei werden die im Kontext eines unprivilegierten Users auslesbaren Werte erfasst, obwohl durch einen administrativen Scan deutlich mehr Werte zur Verfügung stünden. Mehr Erläuterungen dazu bei den Technischen Details. |
0 | !SET ForceAllPossibleData=1 |
HiddenAcls = [0|1] |
Erfassen der Berechtigungen auf Freigegebene Ordner auch von versteckten Freigaben (Endung auf $ -Zeichen). Hinweis: Administrative Freigaben (Admin$, IPC$, C$, D$, E$, ...) werden niemals erfasst. |
0 | !SET HiddenAcls=1 |
Ignore = TABELLENNAME |
Erfassung von Eigenschaften verhindern: Tabellen-Namen (z.B. SharedFolder, DeviceInfo, Mainboard, Font, ...) von der Erfassung ausschließen | !SET Ignore=Mainboard , bzw. !SET Ignore=BootLog,Event |
|
IgnoreFingerPrintRules=NameOnly |
Setzt die Fingerprint-Regel "NameOnly" außer Kraft. Mehr Infos dazu hier. | !SET IgnoreFingerPrintRules=NameOnly |
|
IgnorePingTtl = [0|1] |
Windows-Scan auch dann durchführen, wenn der Ping TTL-Wert auf ein Nicht-Windows-System hindeutet | 0 | !SET IgnorePingTtl=1 |
IgnoreVMs "[Name:<NAME>][OperatingSystem:<OPERATINGSYSTEM>]" |
Auschluss von bestimmten VMs bei der Erfassung des Hosts (siehe detaillierte Erklärung: Tipp "Keine Erfassung von bestimmten virtuellen Maschinen (VMs)") | //IgnoreVMs "[Name:A*][OperatingSystem:*Linux*,*Windows*]" |
|
InactivityTimeout = ZAHL |
Reagiert ein Client während des Scan-Prozesses nicht für 600 Sekunden auf einen Abfrage-Befehl (z.B. eine WMI-Abfrage), so wird ein Timeout gesetzt. Dieser Wert lässt sich anpassen. | 600 sec | !SET InactivityTimeout=900 |
MaxDiskLetter TryCount = ZAHL |
Suche nach lokalen Laufwerken abbrechen nach einer Lücke von X Laufwerkbuchstaben | 5 | !SET MaxDiskLetterTryCount=30 (Suche nach allen lokalen Laufwerken) |
NetinstallDispPrefix = PREFIX |
Falls Enteo Netinstall-Pakete erfasst werden sollen (siehe Schalter DontScanNetinstall ), die Namen der Pakete aber in der SoftwarePakete-Liste ein Prefix tragen sollen (um diese zu unterscheiden), kann durch Verwenden dieses Schalters an den Namen der Pakete ein Präfix hinzugefügt werden. |
!SET NetinstallDispPrefix = "NETINSTALL_" |
|
NetinstallKeyPrefix = PREFIX |
Falls Enteo Netinstall-Pakete erfasst werden sollen (siehe Schalter DontScanNetinstall ),der KeyName der Pakete aber in der SoftwarePakete-Liste ein Prefix tragen sollen (um diese zu unterscheiden), kann durch Verwenden dieses Schalters an den KeyName der Pakete ein Präfix hinzugefügt werden. |
!SET NetinstallKeyPrefix = "NETINSTALL_" |
|
NoAcls = [0|1] |
Berechtigungsanalyse: Aus Performance-Gründen kann es gewünscht sein die Erfassung auszuschalten, da komplette Freigaben-Ordnerstrukturen auf Windows-Servern rekursiv durchsucht werden müssen. | 0 | !SET NoAcls=1 |
NoCaching = [0|1] |
Kein lokales Kopieren der LOGINfo.exe auf die zu erfassende Maschine. Stattdessen immer Aufruf aus dem Datenverzeichnis. | 0 | !SET NoCaching=1 |
NoCDP = [0|1] |
Kein Cisco Discovery Protocol (CDP) verwenden: Bei der Inventarisierung von Switches und Routern wird normalerweise CDP verwendet, um eine Hierarchie zu entdecken (weitere direkt angeschlossene Switches oder Router). Dies lässt sich abschalten. | 0 | !SET NoCDP=1 |
NoFailedLogons = [0|1] |
Standardmäßig werden alle fehlgeschlagenen Anmeldeversuche aus dem Eventlog (Ereignis-ID: 4625) gelesen. Dieses Verhalten kann jedoch ausgeschaltet werden. | 0 | !SET NoFailedLogons=1 |
NoFonts = [0|1] |
Standardmäßig werden alle System-Fonts gescannt. Dieses Verhalten kann jedoch ausgeschaltet werden. | 0 | !SET NoFonts=1 |
NoIPv6 = [0|1] |
Kein Auslesen von IP v6 Adressen (z.B. beim Wert NetworkAdapater.Ip) | 0 | !SET NoIPv6=1 |
NoLLDP = [0|1] |
Keine Verwendung des LLDP-Protokolls zum Auslesen verbundener MAC-Adressen an Switches | 0 | !SET NoLLDP=1 |
NoLoginUse = [0|1] |
Das Auslesen der LOGINuse-Datenbank (Software-Nutzungsauswertung) während des Scans kann unterbunden werden. | 0 | !SET NoLoginUse=1 |
NoNetworkPrinters = [0|1] |
An Windows-Geräten angeschlossene Netzwerk-Drucker nicht erfassen. Dieser Schalter betrifft nicht die Inventarisierung von Druckern via SNMP. | 0 | !SET NoNetworkPrinters=1 |
NoSysName = [0|1] |
SNMP SysName nicht als Asset-Namen übernehmen: Falls eine Inventarisierung über SNMP erfolgt, wird der PC-Name aus der OID system.sysname gelesen und nicht mehr über Reverse-DNS-Lookup. Dies kann zu unter-schiedlichen Ergebnissen für den PC-Namen führen! | 0 | !SET NoSysName=1 |
NoTSPrinter = [0|1] |
Netzwerkdrucker beim Terminaldienst-Sitzungen nicht erfassen | 0 | !SET NoTSPrinters=1 |
NoUpdatesPending = [0|1] |
Bei der Erfassung von Windows-Rechnern nicht auslesen, ob es ausstehende Windows Updates gibt | 0 | !SET NoUpdatesPending=1 |
NoValidate = [0|1] |
Ignorieren von Fehlern in der LOGINfo.Script-Datei (Scan wird auch ausgeführt, wenn fehlerhafte Einträge vorhanden sind). | 0 | !SET NoValidate=1 |
NoVirtualSwitch = [0|1] |
Bei Hosts wird kein virtueller Switch und die entsprechende MAC-Adress-Tabelle erfasst | 0 | !SET NoVirtualSwitch=1 |
NoVmWare = [0|1] |
Kein Erfassen von Geräten, deren Betriebssystem-Name "ESX" oder "VmWare" enthält. Hinweis: Diese Geräte werden normalerweise über die LOGINfoESX.exe erfasst. | 0 | !SET NoVmWare=1 |
NoWMI = [0|1] |
Kein WMI verwenden: Normalerweise werden Informationen per Remote Registry und per WMI erfasst. Die Erfassung über WMI lässt sich abschalten. | 0 | !SET NoWMI=1 |
ReplaceControlChars = [0|1] |
Steuerzeichen ersetzen: Über diesen Schalter ist es möglich, die Inventarisierung anzuweisen, Steuerzeichen innerhalb eines Wertes, wie TAB , CR , LF durch ein Leerzeichen zu ersetzen. Dies kann z.B. beim Auslesen des Betriebssystems eines Cisco Switches oder -Routers gewünscht sein. |
0 | !SET ReplaceControlChars=1 |
RPC = [0|1] |
RPC = 0 -> kein RPC-Scan Standardmäßig ( RPC = 1 ) wird die LOGINfo.exe auf den Rechner kopiert und dort ausgeführt. Falls das nicht klappt, wird ein Fallback auf RPC 0 gemacht -> komplette Remote-API-Erfassung (funktioniert nur in Trusted Umgebungen mit eingeschaltetem Remote Registry Dienst) |
1 | !SET RPC=0 |
RPCOnly = [0|1] |
Nur Verwendungs des RPC-Scans (kein Fallback auf RemoteRegistry & WMI) | 0 | !SET RPCOnly=1 |
RpcTimeout = ZAHL |
Wird ein Scanvorgang über RPC durchgeführt, wird dessen Prozess nach 1200 Sekunden abgebrochen. Diese Zeitspanne lässt sich über diesen Parameter ändern. | 1200 sec | !SET RpcTimeout=300 |
ScanAppUpdates = [0|1] |
Microsoft App Update Pakete erfassen | 0 | !SET ScanAppUpdates=1 |
ScanClusterIp = [0|1] |
Durchführen eines Scans, auch wenn eine Cluster-IP erkannt wurde | 0 | !SET ScanClusterIp=1 |
ScanDrivers = [0|1] |
Auslesen der Treiber-Informationen (zu finden in der Tabelle "SystemDriver") | 0 | !SET ScanDrivers=1 |
ScanSqlServerDatabases = [0|1] |
Bei SQL Server Datenbanken werden durch die Asset-Inventarisierung die ermittelbaren Namen der Datenbanken erfasst, obwohl durch eine SQL Server Erfassung deutlich mehr Werte zur Verfügung stünden. | 0 | !SET ScanSqlServerDatabases=1 |
ScheduledTaskLevel = ZAHL |
Gibt an, welche Arten von Scheduled Tasks ausgelesen werden sollen.0 = keine Scheduled Tasks erfassen1 = nur Tasks aus dem Root-Ordner2 = Alle außer Microsoft-Ordner9 = alle |
2 | !SET ScheduledTaskLevel = 9 |
SnmpConnectTimeout = ZAHL |
Falls eine IP-Adresse nicht auf PING reagiert, wird von LOGINfo trotzdem versucht, eine SNMP Verbindung zu öffnen. Dies geschieht zweimal mit einem Timeout von 10s. Dieser Timeout kann geändert werden. | 10 sec | !SET SnmpConnectTimeout=2 |
StoppedVms = [0|1] |
Anlegen von Assets auch für gestoppte Virtuelle Maschinen | 0 | !SET StoppedVms=1 |
TotalTimeout = ZAHL |
Der Scan-Prozess auf eine Adresse wird normalerweise nach 5400 Sekunden (90 Minuten) abgebrochen, wenn keine Antwort kommt. Diese Zeitspanne lässt sich über diesen Parameter ändern. | 5400 sec | !SET TotalTimeout=600 |
UseSnmpFallback = [0|1] |
SNMP Fallback: Falls eine IP-Adresse nicht auf PING reagiert, wird nicht weiter versucht, mit diesem Knoten in Verbindung zu treten. Alternativ kann trotzdem ein SNMP-Verbindungsaufbau versucht werden. | 0 | !SET UseSnmpFallback=1 |
Validate = [0|1] |
Validiert nur die LOGINfo.Script-Datei ohne einen Scan zu starten | 0 | !SET Validate=1 |
WmiMonitors = [0|1] |
Je nach Hersteller wird die Seriennummer von Monitoren anders ausgelesen. Um das Auslesen über WMI zu erzwingen, kann der Schalter auf "1" gesetzt werden. | 0 | !SET WmiMonitors=1 |
WMIOnly = [0|1] |
Nur Geräte erfassen, die WMI unterstützen. (Wird ignoriert, falls NoWMI gesetzt wurde) |
0 | !SET WMIOnly=1 |
WmiSmartData =[0|1] |
Standardmäßig wird versucht SMART-Daten von Festplatten mit der CDI-Methode zu erfasen. Falls die SMART-Daten stattdessen via WMI erfasst werden sollen, kann dieser Switch auf 1 gesetzt werden. |
0 | !SET WmiSmartData=1 |
Anlegen von Eigenen Eigenschaften
Sie können selbst Eigenschaften anlegen und ihnen Werte zuweisen. Um die Werte dieser Eigenschaften zu ändern, wird entweder ein Eintrag in der Datei LOGINfo.script benutzt – oder Sie können dies in LOGINventory interaktiv tun.
Die Eigenschaften, die über die Script-Datei erzeugt werden, haben immer den Typ String – im Gegensatz zu im LOGINventory angelegten Eigenen Eigenschaften, welche den Typ String, Int64 oder DateTime haben können. Weitere Informationen zu diesem Thema finden Sie bei den Eigenen Eigenschaften.
Verwenden Sie keine Leer- oder Sonderzeichen (z.B. $#_&-) im Eigenschaftsnamen!
Zuordnung von | Syntax | Beispiel(e) |
---|---|---|
Konstanten | Eigenschaft= Konstante |
Custom.Company=LOGIN |
Umgebungsvariablen | Eigenschaft= %Umgebungsvariable% |
Custom.WindowsDir=%Systemroot% Custom.UserPath=C:\Temp\%UserId% |
LOGINventory-1:1-Eigenschaften | Eigenschaft= %$Eigenschaft% |
Custom.IP=%$Lastinventory.IP% Custom.Mainboard=%$Mainboard.SerialNumber%/%$Mainboard.Name% |
WMI-Werten | Eigenschaft= {wmi:[[root\][namespace\]WMI-class,value} (Ist der Namespace nicht angegeben, wird CIMV2 angenommen.) |
Custom.Year={wmi:Win32_LocalTime,Year} Custom.CName={WMI:root\CIMV2\Win32_ComputerSystem,Name} Custom.Part= {WMI:CIMV2\Security\MicrosoftVolumeEncryption\ Win32_EncryptableVolume,DriveLetter} |
Registry-Keys | Eigenschaft= {reg:Schlüssel,Wert } bzw. Eigenschaft= {reghex:Schlüssel,Wert } |
Custom.IEPatches={reg:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Internet Settings,MinorVersion} Custom.Serial={reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Vmware, Inc.\Vmware Workstation\License.ws.*",Serial} (Achtung: bei der Verwendung von Sonderzeichen und Leerzeichen muss der Key in Anführungsstrichen stehen!) |
SNMP-Werte | Eigenschaft= {OID:oid-in-dotted-Nummer} |
Custom.SystemUpTime={oid:.1.3.6.1.2.1.25.1.1.0} |
Datei-Version | Eigenschaft= {fileversion:DateiName } |
Custom.IEVersion={fileversion:shdocvw.dll} Custom.MDACVER={fileversion:%CommonFiles%\System\ado\msado15.dll} |
Datei-Datum | Eigenschaft= {filetime:DateiName } |
Custom.BOOTINIDATE={filetime:c:\boot.ini} |
Datei-Größe | Eigenschaft= {filesize:DateiName } |
Custom.MDACSIZE={filesize:%CommonFiles%\System\ado\msado15.dll } |
Datei-Sprache | Eigenschaft= {filelanguage:DateiName} |
Custom.Vblang={filelanguage:vbscript.dll } |
Listeneinträge verändern
Vorhandene Listeneinträge (z.B. Software-Pakete) können geändert werden. Dies ist z.B. nützlich, wenn man eine Seriennummer hinzufügen oder die Softwarebezeichnung einer bestimmten Software ändern will. Die Benutzung von Wildcards ?
und *
wird dabei unterstützt. Es werden alle Einträge geändert, auf die der Ausdruck passt.
Unter Verwendung der Syntax !MODIFY tabelle bedingung Eigenschaft1=Wert1[,Eigenschaft2=Wert2 …]
werden die Einträge dabei verändert, also z.B.
- Ergänzung von ProduktID und Produkt-Schlüssel beim Softwarepaket:
!MODIFY SoftwarePackage Name=Nero*, PRODUCTID=reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Ahead\Nero – Burning Rom\Info”,user}, PRODUCTKEY={reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Ahead\Nero – Burning Rom\Info",Serial5}
- Ersetzen des SW-Paket-Namens durch konstanten Namen:
!Modify SoftwarePackage Name=*WinZIP*,Name=File Compressor
- Ersetzen des SW-Paket-Namens durch seinen Namen und die Versionsnummer :
!MODIFY SoftwarePackage NAME=Acrobat,NAME=$NAME$ $VERSION$
- Ergänzung von Produkt-Schlüsseln aus der Registry:
!MODIFY SOFTWAREPACKAGE NAME=VMware Workstation, PRODUCTKEY={reg:"HKEY_LOCAL_MACHINE\!32!SOFTWARE\Vmware, Inc.\Vmware Workstation\License.ws.*",Serial}
Mit Hilfe der Syntax !BLOCK tabelle bedingung
kann auch das Eintragen von gewissen Werten verhindert werden, z.B. !Block SoftwarePackage Name=LOGINventory
oder !Block Hotfix Product=.Net*
.
Beispiele
Setzen einer Eigenen Eigenschaft "Standort" abhängig vom IP-Bereich der Erfassung
!IF {like:%$Lastinventory.Ip%,192.168.10.*}
Custom.Standort=Munich
!ENDIF
!IF {like:%$Lastinventory.Ip%,192.168.20.*}
Custom.Standort=Berlin
!ENDIF
Hinweis
Die eigene Eigenschaft "Standort" muss nicht zuvor in der Benutzeroberfläche angelegt worden sein. Wenn sie noch nicht existiert, wird sie automatisch erstellt und als "Editierbar vom Scanner / Agenten" angelegt, wodurch sie auch nicht in der Oberfläche durch den Nutzer mehr geändert werden kann.
Hinzufügen eines Software-Pakete-Eintrags, obwohl weder in der Registry, noch in der "Add / Remove Software-Liste" Einträge zu finden sind (geschieht z.B. bei Paketmanagern, die über die Kommandozeile installiert wurden)
!IF {fileexist:"%programdata%\chocolatey\choco.exe"}
!ADD SoftwarePackage Name=Chocolatey,Version={fileversion:"%programdata%\chocolatey\choco.exe"}
!ENDIF
Ändern des ausgelesenen ChassisTypes für bestimmte Geräte (in Abhängigkeit vom ausgelesenen Betriebssystem-Namen)
!IF {like:%$Operatingsystem.Name%,*SonicWALL*}
DeviceInfo.ChassisType=Sonic
!ENDIF
Verhindern der Erfassung von Software-Paketen, die aus einem bestimmten Pfad installiert wurden (z.B. durch Software-Verteilung)
!Block SoftwarePackage InstallSource=*dfs\apps\*
Anpassung unter Linux
Die Datei LOGINfo.script wird nicht beachtet, falls es sich um eine Erfassung eines Linux-basierenden Geräts handelt. Hierfür kann aber auf dem zu scannenden Gerät eine Datei abgelegt werden, mit der es möglich ist verschiedene Einträge zu modifizieren, bzw. neue Einträge selbst zu schreiben.
Dafür muss eine Datei "custom.xml" im Pfad /opt/loginfox/custom.xml
abgelegt werden, die folgenden Aufbau hat:
<?xml version="1.0" encoding="utf-8"?>
<Device>
<Name>custom name</Name>
<Custom>
<myvalue>myvalue content</myvalue >
</Custom>
<DeviceInfo>
<Description>device description</Description>
</DeviceInfo>
<OperatingSystem>
<Name>os name</Name>
<Version>os version</Version>
<Domain>os domain</Domain>
</OperatingSystem>
<SoftwarePackage>
<NAME>F-Secure Policy Manager</NAME>
<VERSION>14.20</VERSION>
<INSTALLDATE.VALUE>2018-12-04T00:00:00Z</INSTALLDATE.VALUE>
<PUBLISHER>F-Secure Corporation</PUBLISHER>
</SoftwarePackage>
<SoftwarePackage>
<NAME>FileZilla Server</NAME>
<VERSION>beta 0.9.60</VERSION>
<INSTALLDATE.VALUE>2018-12-04T00:00:00Z</INSTALLDATE.VALUE>
<PUBLISHER>FileZilla Project</PUBLISHER>
</SoftwarePackage>
</Device>
Die hier gesetzten 1:1-Beziehungen (z.B. Device.Name, OperatingSystem.Name, ...) überschreiben die eigentlich ausgelesenen Werte. Die Einträge bei den SoftwarePackages werden zu den bereits ausgelesenen Einträgen hinzugefügt.
Fehlermeldungen bei der Erfassung
Alle bekannten Fehler, die bei der Erfassung auftreten können, deren typische Gründe und wie die Fehler behoben werden können, sind im Helpdesk von LOGINventory beschrieben.