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 können natürlich noch weitere Definitionen und Benutzerkonten hinterlegt werden.
Info
In den Technischen Details sind die Voraussetzungen zur 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")
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 rechten 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, …).
- Ausschluss von der Inventarisierung: Schließt Elemente von der Inventarisierung aus (wird in Jobs zusammen mit anderen Definitionen benutzt).
- Active Directory Attribute Lookup: Liest Benutzer-, Gruppen und Computer-Eigenschaften aus Active Directory.
- MS 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.
- XenApp Inventarisierung: Inventarisiert auf Citrix XenApp publizierte Anwendungen.
- XenServer Inventarisierung: Inventarisiert Citrix XenServer und und ihre vorhandenen virtuellen Maschinen.
- SQL Server Inventarisierung: Inventarisiert Microsoft SQL Server Instanzen, deren Datenbanken und Benutzerrechte
- Microsoft 365 Subscriptions: Liest online aus, welche Produkte bei Microsoft 365 lizenziert sind und welche User welche Lizenzen verbrauchen.
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)
- 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.
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 mit Wildcards mit Vorsicht. So sollte keinesfalls eine rekursive Suche des Pfades C:\*.*
angestoßen werden, da sonst die gesamte Festplatte inklusive aller Dateien aufgelistet wird, was zu extrem langen Ausführungszeiten und sehr großen Datenmengen führen kann. Verwenden Sie stattdessen 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
)!
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.
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.
Info
Über das Kommandozeilen-Argument /ignoregroups group1;group2
können Benutzergruppen aus dem AD von der Erfassung ausgeschlossen werden. Dies kann z.B. erwünscht sein, falls Sie nur einen Teil Ihrer gesamten Organisation erfassen möchten.
Ü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"). Dieses Verhalten kann auch über das Kommandozeilen-Agrument /recursivegroups
eingeschaltet werden.
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.
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“.
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
. Achtung: In diesem Fall muss das Benutzerkonto für die Erfassung als UPN (z.B. name@domain.com) angegeben werden, eine Verwendung von domain\name wird nicht funktionieren!
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 das 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.
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.
Achtung
Über die VMware-Inventarisierung werden zwar Hosts und VMs als Assets angelegt, allerdings werden bei der Erfassung nur die Daten gesammelt, die der Host über seine VMs hat. Das bedeutet, dass virtuelle Maschinen, die einzig und allein über die VMware-Inventarisierung erfasst wurden unvollständige Informationen aufweisen (z.B. keine Informationen über installierte Software, Hardware, etc.). Daher sollten alle virtuellen Maschinen zusätzlich stets über eine Definition vom Typ Asset Inventarisierung erfasst werden (indem z.B. der betreffende IP-Bereich mit den VMs gescannt wird). Unvollständig erfasste Geräte können am Eintrag Stub
bei LastInventory.Method
erkannt werden.
Gleiches gilt natürlich auch für die XenServer Inventarisierung und die Erfassung von Hyper-V Hosts über die Asset-Inventarisierung: Die VMs sollten immer noch zusätzlich explizit erfasst werden.
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.
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.
Microsoft 365 Subscriptions
Mit Microsoft 365 Subscriptions 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. Diese Daten lassen sich im Lizenzmanagement auswerten.
Um das Auslesen der Microsoft 365-Daten zu ermöglichen, müssen folgende Voraussetzungen erfüllt sein:
- Eine Internet-Verbindung muss bestehen.
- Das benötigte Powershell-Modul muss vorhanden sein.
Die Installation dieses Moduls erfolgt durch Eingabe des BefehlsInstall-Module -Name AzureAD
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 ModulAzureAD
installiert werden kann. Darauf wird aber von der Powershell hingewiesen, falls der oben genannten Befehl ausgeführt wird. - Als Benutzerkonto für die Erfassung muss ein Konto vom Typ Generic Credentials angelegt sein, wobei der Username als UPN, also z.B.
max.mustermann@domain.de
angegeben wird. Ebenso muss dieser User berechtigt sein von Microsoft 365 die Daten auszulesen, das sind z.B. alle User, denen eine Microsoft 365-Lizenz zugewiesen wurde.
Das Auslesen der Microsoft 365-Daten lässt sich - wie jede andere Definition - durch Jobs automatisieren. Die Daten stehen dann unterhalb des Knoten "Software" in den entsprechenden Abfragen zur Verfügung. Ebenso lassen sich diese Cloud-Subscriptions zum Lizenzmanagement hinzufügen.
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. Das dort auch befindliche Programm LogInfoL.exe dient übrigens zur Inventarisierung von alten Systemen, wie NT4, ME oder Windows 2000. 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 Li8Data verwendet. Wenn Sie das Verzeichnis über diesen Dialog freigeben, werden folgende Rechte im Dateisystem gesetzt: Authentifizierte Benutzer: Voll; Lokaler Dienst: Ändern.
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\LI8DATA\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\LI8DATA\LOGINfo.exe
Alternative: Die folgenden Zeilen im Skript bewirken, dass LOGINfo.exe lokal ausgeführt, 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\LI8DATA\LOGINFO.EXE %temp%
start /b %temp%\LOGINfo.exe \\server\LI8DATA)
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 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
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.
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.
- Die bei 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 mittels ASPX oder PHP möglich. Dazu kann der Button Upload Script Vorlagen erstellen verwendet werden. Diese Script-Dateien können ggf. angepasst werden.
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 Daten Verzeichnis des Servers ablegt. Deswegen wird diese URL auch als Standard-Adresse vorgeschlagen.
Verwendung eines anderen Webservers
Falls ein anderer Webserver verwendet werden soll, gelten folgende Voraussetzungen:
- 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
- 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 dann 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).
Die vom Offline Agent empfangenen .inv-Dateien werden nun im Datenverzeichnis abgelegt (standardmäßig%Public%\Documents\LOGIN\LOGINventory 8\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 müssen 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.
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 8\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\8.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 prinzipiell 3 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.
Info
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" zur Verfügung gestellt werden.
Für diese drei Fälle 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 drei 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.
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.
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)
- Installation
- des .deb-Pakets mittels
sudo apt install /path/to/package/name.deb
- des .rpm-Pakets 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.
- des .deb-Pakets 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 zwei Dateien angepasst werden:
- Die Upload-URL unter der die bei der Erfassung entstehende .inv-Datei abgelegt werden soll (z.B. OfflineAgent.php):
/etc/loginfox/loginfox_url.config
- Die Credentials, die für die den Zugriff auf die Upload-URL verwendet werden sollen:
/etc/loginfox/loginfox.config
- Die Upload-URL unter der die bei der Erfassung entstehende .inv-Datei abgelegt werden soll (z.B. OfflineAgent.php):
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.
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\8.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
Datenbank zurücksetzen
Um die LOGINuse-Datenbank auf den Rechnern zurückzusetzen, kann die die MSI-Datei LOGINuseResetDb.msi „installiert“ werden. Diese MSI-Datei installiert nichts, sondern leert nur die jeweilige lokale Datenbank.
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 8\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).
Manuelles Anlegen von Assets
Über das Ribbon-Menü kann der Assistent LOGINject zum Manuellen Anlegen von Assets gestartet werden. 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. Der Assistent kann über das Ribbonmenü unter "Extras" aufgerufen werden, wenn im Baum zu Asset-Management (oder unterhalb) navigiert wurde.
Tip
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 unterhalb des Knotens IT-Bestand) aus dem Ribbon-Menü die Aktion Asset Anlegen ausgewählt werden. Daraufhin werden die Daten, die bei der fehlerhaften Erfassung gesammelt werden konnten (Name, IP, MAC, Hersteller) direkt übernommen und aus dem "fehlerhaften" Asset wird ein "vollwertiges" Asset.
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, die sich an einem beliebigen Speicherort befinden kann, ausgewählt werden, um eine Import-Definition anzulegen. Für jeden Import muss dann im nächsten Schritt 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 Assets beziehen, muss die Tabelle "Device" gewählt werden. 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.
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 das 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 werden, 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 werden 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, können Lizenzen beim Einlesen auch direkt dem richtigen Produkt und der richtigen Version zugewiesen werden. 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. 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!IF {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 |
---|---|---|---|
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 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 Netinstall-Pakete erfassen | 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 |
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 |
|
IgnorePingTtl = [0|1] |
Windows-Scan auch dann durchführen, wenn der Ping TTL-Wert auf ein Nicht-Windows-System hindeutet | 0 | !SET IgnorePingTtl=1 |
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) |
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 |
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 |
NoNetworkPrinters = [0|1] |
Netzwerk-Drucker nicht erfassen | 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 |
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 |
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 |
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
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.