Modul für Berichte um die Remote Desktop Sitzungen auszuwerten. Gerne auch Optional Auswählbar ob auch die Terminal und Dateiübertragen usw. angezeigt werden sollen. Dient zur Auswertung der Remotezeiten bei Kunden.

Integration für Threatdown mit automatischem Rollout, Management uvm.

Die WoL Funktion als Baustein in der Automatisierung

Es wäre ziemlich cool, wenn man in einer Remote Desktop Sitzung einen Button drücken könnte, mit dem man einen Text auf dem Bildschirm des Remote-Geräts auswählen und (auf dem eigenen Gerät) direkt googlen kann. Connectwise macht das ganz gut (s. Video): https://docs.connectwise.com/ScreenConnect_Documentation/Get_started/Host_client/Helper_menu

Bestehende Automatisierung duplizieren Geräte-Tags in Schritt-Bedingungen abfragen können Einzelne Schritte testen oder wiederholen können Input-Parameter für eine Automatisierung definieren können, die man dann beim ausführen eintragen muss Andere Automatisierungen als eigener Schritt ausführen (Wiederverwendbarkeit, besonders mit Input-Parametern)

Wir haben ein Powershell Monitoring Script, um von Euch nicht unterstützte Backups zu monitoren. Das Script ist in der Kategorie Backup, aber es wirkt sich nicht auf den Bericht aus. Wäre es möglich, das in die Berichte aufzunehmen, und zwar unter Backup?

Hallo Octoja Team, so wie ich es aktuell sehe, werden im Dateiexplorer ausschließlich die physischen Festplatten des jeweiligen Gerätes angezeigt. Es wäre fantastisch, wenn dort zukünftig auch die mit dem Gerät verbundenen Netzlaufwerke angezeigt und direkt aufgerufen werden könnten. Gerade im Support würde dies den Zugriff auf relevante Dateien und Verzeichnisse deutlich vereinfachen. Vielen Dank und viele Grüße

Anbindung der Yeastar PBX Systeme, Überwachung SIP Trunk, öffentliche IP, Gerätefirmware, PBX-Firmware - als Cloud oder ONpremise

LAPS Passwörter auslesen - samt History

Kunden ohne Geräte sollten nicht im Dashboard auftauchen

Erweitern des Firewall Checks um PFSense

Der Cursor könnte beim Start einer Fernwartung direkt ins Benutzernamen Feld springen. So könnten Passwörter über den Passwortmanager gleich beim ersten Versuch eingegeben werden. Aktuell landen die Eingaben irgendwo im Browser Fenster.

Aktuell bietet Octoja RMM bei den Patch-Ringen eine feste kalenderbasierte Zeitplanung (z. B. erstes, zweites oder drittes Wochenende eines Monats). Für Microsoft-Updates führt dies jedoch in der Praxis zu einem Problem: Microsoft veröffentlicht die regulären Sicherheitsupdates stets am zweiten Dienstag eines Monats (Patch Tuesday). Das darauf folgende Wochenende ist jedoch nicht immer das zweite Wochenende des Monats. Je nach Kalenderkonstellation kann es sich auch um das dritte Wochenende handeln. Für einen sauberen und konsistenten Rollout-Prozess wäre daher eine Zeitplanung wünschenswert, die sich nicht an festen Kalenderwochen orientiert, sondern direkt am Patch Tuesday. Vorschlag Ein neuer Zeitplan-Typ, beispielsweise: Zweiter Dienstag im Monat + X Tage Dritter Dienstag im Monat + X Tage (für Hotfixes oder Nachtests) Beispiele: Patchring „Pilot“: Zweiter Dienstag + 3 Tage Patchring „Standard“: Zweiter Dienstag + 10 Tage Patchring „Produktion“: Zweiter Dienstag + 17 Tage Dadurch ließen sich Patch-Rollouts unabhängig von der jeweiligen Monatskonstellation zuverlässig und reproduzierbar planen. Nutzen Perfekte Abstimmung auf den Microsoft Update-Zyklus Konsistente Rollout-Fenster über das gesamte Jahr Weniger manuelle Anpassungen der Zeitpläne Höhere Planungssicherheit für MSPs und interne IT-Abteilungen Realitätsnahe Abbildung etablierter Patch-Management-Prozesse Wir haben diese Art der Zeitplanung bislang in keinem anderen RMM-System gesehen, halten sie jedoch für einen erheblichen Mehrwert, insbesondere für Kunden, die ihre Patch-Ringe konsequent am Microsoft Release-Zeitpunkt ausrichten möchten. Kurz gesagt: Eine Regel wie „Patch Tuesday + X Tage“ wäre aus unserer Sicht die optimale Lösung für die zeitgesteuerte Verteilung von Updates über Patch-Ringe.

Überwachen der Dell iDRAC - wir haben ca. 180 Dell Server im Feld und Verkaufen eigentlich nur Dell. Vermutlich via SNMP

Es fehlt nocht zum Beispiel “Telefonie“ für TK-Anlagen und Telefone und eventuell auch “Sonstiges“ als Typ. Diesen kann man dann für alles nutzen was es noch nicht gibt.

Ich habe gerade unser Ticket System angebunden. Dabei musste ich ein wenig rumprobieren, bis ich verstanden habe, dass man nicht nur den API Token sondern auch das Wort “Bearer” davor schreiben muss damit es funktioniert. Das könnte man sicherlich eleganter machen.

Checks fuer Nakivo Backups - zB per API: https://helpcenter.nakivo.com/api-reference/Content/API-Reference-Overview.htm

Ich weiß nicht, ob das ein Einzelfall ist, aber ich habe hier einen Wortmann PC, wo man offenbar beim Bauen die Seriennummer im Bios (oder wo auch immer die gespeichert wird) fehlt. Sieht dann so aus: Wäre es evtl. möglich, ein Feld hinzuzufügen, wo man die Seriennummer notfalls von Hand eintragen kann?

z.B. nach Workstation, Server, Tag. Verfügbarkeit ist bei Notebooks nicht so relevant, bei Servern schon. Manche Checks sollen intern bleiben, die würden wir auf den Berichten gern ausblenden.

Alternative Fernwartung für Windows-Systeme: Aufbau eines Tunnels zum Endgerät, Windows-native RDP-Session durch den Tunnel