Docusnap Alternative

Beide Lösungen inventarisieren agentenlos, beide kommen aus Deutschland, beide sind seit über zwanzig Jahren am Markt. Beide lesen Windows, Linux, macOS, SNMP-Geräte und Virtualisierungshosts aus. Wer hier nach einem Sieger sucht, sucht an der falschen Stelle.

Der Unterschied liegt darin, worauf die beiden Produkte hin gebaut sind.

Fragen Sie sich, wie oft Sie beides tatsächlich brauchen. Ein Notfallhandbuch brauchen Sie einmal im Jahr, wenn der Auditor kommt. Ein Gerät geben Sie diese Woche aus. Und nächste Woche wieder.

Am Ende eines Docusnap-Projekts haben Sie eine Datei. Am Ende eines LOGINventory-Tages haben Sie Arbeit erledigt.

Die Übergabe aus dem Beispiel oben funktioniert nur, weil es eine Oberfläche gibt, in der ein Mitarbeiter etwas eintragen kann. Das ist kein Detail, sondern der Grund, warum manches geht und anderes nicht.

Bei LOGINventory führen mehrere Wege zu denselben Daten. Das Management Center, wenn Sie auswerten und konfigurieren. Der Browser, wenn jemand ein Gerät übernimmt, zurückgibt oder nachsieht, was auf ihn läuft. Und die Schnittstellen, wenn ein anderes System mitreden soll: die REST-API liest und schreibt, dazu PowerShell, CSV und der MCP-Server für eigene KI-Werkzeuge.

Docusnap nennt für die lokale Version ebenfalls einen Webclient. Er ist allerdings ausdrücklich lesend: Der Hersteller beschreibt ihn als read-only-Zugang, Daten eintragen oder ändern kann man dort nicht, das bleibt der Administratorkonsole vorbehalten.

Damit beantwortet sich auch die Frage nach dem QR-Code auf dem Etikett. Er könnte dort auf eine Leseansicht zeigen. Quittieren ließe sich nichts.

Eine REST-API gibt es bei Docusnap nur in der Cloud-Variante Docusnap365, ebenso die Anbindung an Zapier und Power Automate. Wer die lokale Version einsetzt und Inventardaten an ein anderes System übergeben will, hat diesen Weg nicht.

Wer virtuelle Windows Server betreibt, kennt das Problem: Microsoft lizenziert nach Prozessorkernen des Hosts, nicht nach Installationen. Mindestens acht Kerne je Prozessor, mindestens sechzehn je Host, und in der Standard Edition deckt ein vollständiger Lizenzsatz genau zwei virtuelle Maschinen ab. Für die dritte fängt man von vorne an.

Ein Beispiel. Ein Host mit zwei Prozessoren zu je zehn Kernen, darauf sechs virtuelle Windows Server Standard.

Ein Werkzeug, das Installationen zählt, zeigt Ihnen: sechs.

Tatsächlich brauchen Sie: sechzig Kernlizenzen. Zwanzig je Lizenzsatz, drei Sätze für sechs VMs.

Zwischen diesen beiden Zahlen liegt der Unterschied zwischen einer Bilanz, auf die Sie sich verlassen können, und einer, die im Audit auffliegt. (Ob sich an dieser Stelle Datacenter statt Standard lohnt, ist die nächste Frage, und auch die beantwortet sich leichter, wenn die Zahlen stimmen.)

LOGINventory rechnet das aus den erfassten Daten aus. Prozessoren und Kerne des Hosts stehen im Inventar, die Zuordnung der VMs zum Host ebenfalls. Die Mindestwerte und die Unterscheidung zwischen Standard und Datacenter sind hinterlegt. Kommt eine VM dazu oder ändert sich die Hardware, ändert sich der Bedarf mit.

Docusnap zählt an dieser Stelle die Prozessorkerne des Systems, auf dem die Software gefunden wurde, also der virtuellen Maschine. Was davon abweicht, trägt man als Korrekturwert von Hand nach. Bei drei Servern ist das eine Fleißaufgabe. Bei fünfzehn Hosts mit siebzig VMs ist es eine Fehlerquelle, und zwar nicht erst nach einer Hardwareänderung: Schon jede zusätzliche VM kann den Bedarf ändern, und der Korrekturwert stimmt dann nicht mehr.

Und der Termin, den alle vergessen

Ablaufdatum und Kündigungstermin sind bei uns zwei verschiedene Felder. Das klingt nach einer Kleinigkeit, bis zum ersten Abonnement, das sich stillschweigend um ein Jahr verlängert hat, weil die Erinnerung zum Ablaufdatum kam und die Kündigungsfrist drei Monate vorher endete.

Sie hinterlegen beide Termine je Lizenz, mit einem Vorlauf, den Sie selbst festlegen. Die Erinnerung kommt per Mail, ohne dass jemand ein Dashboard öffnen muss.