Es kann verschiedene Ursachen geben, weshalb eine Softwareverteilung mittels Managed Deploy fehlschlägt. Dieser Artikel gibt im ersten Teil allgemeine Hinweise zur Fehlersuche und -behebung bzw. beschreibt vorhandene Einschränkungen. Im zweiten Teil wird dann auf die konkreten Probleme bei der Verteilung bestimmter Apps eingegangen.


INHALTSVERZEICHNIS


Allgemeine Hinweise

Unterstützte Betriebssysteme

Managed Deploy kann auf allen Desktop-Betriebssystemen ausgeführt werden, die von WinGet unterstützt werden. Aktuell sind dies:

  • Windows 10: Ab Version 1809 (Build 17763) oder höher
  • Windows 11: Alle Versionen

Die Ausführung auf „Windows Server“ (ab 2025) wird aktuell noch nicht von Managed Deploy unterstützt.

Technische Voraussetzungen auf dem verwalteten System

Die technischen Voraussetzungen (und wie sie hergestellt werden können) sind in einem eigenen KB-Artikel beschrieben: Managed Deploy - Anforderungen der Systeme.

Installierte Software wird nicht erkannt 

Managed Deploy nutzt auf den verwalteten Systemen WinGet als Basis der Softwareverteilung. Mithilfe von WinGet wird auch ebenfalls die Liste der auf dem System installierten Software ermittelt. Es kann vorkommen, dass nicht alle installierten Apps ermittelt werden können, was dann in der Folge auch zu Problemen bei der geplanten Verteilung von Apps führen kann, die bereits installiert sind, aber nicht erkannt werden.

Eine mögliche Ursache für dieses Problem: WinGet wird von Managed Deploy im Systemkontext des jeweiligen Systems gestartet (um Apps für alle Nutzer auf dem System installieren zu können). Somit werden Apps, welche manuell im Nutzerkontext installiert wurden (beispielsweise auch manuell über WinGet), von Managed Deploy nicht erkannt und folglich auch nicht angezeigt.

Ausführungskontext

Managed Deploy wird auf den Systemen im Systemkontext ausgeführt. Dies bringt Vorteile bei der Softwareverteilung, denn dadurch kann Software global für alle Nutzer des Systems installiert werden. Der Systemkontext beeinflusst allerdings auch die Arbeitsweise von WinGet:

  • Software, die im Nutzerkontext installiert wurde, kann von Managed Deploy aktuell nicht ermittelt werden. „Erkannte Software“ zeigt daher nur Apps, die im Maschinenkontext installiert sind (falls beispielsweise über WinGet manuell installiert, mittels --scope=machine).
  • Software, die ausschließlich im Nutzerkontext installiert werden kann, kann daher aktuell nicht sicher von Managed Deploy verteilt werden.
  • Der (De-)Installationsprozess läuft nicht-interaktiv und ohne grafische Oberfläche. Dieses Verhalten ist auch erwünscht, um den Endanwender möglichst überhaupt nicht durch die Softwareverteilung zu stören. Installer, die Nutzerinteraktionen verlangen, können daher nicht erfolgreich bis zum Ende ausgeführt werden und werden nach einem Timeout (typischerweise 30 Minuten) abgebrochen.
  • Managed Deploy kann daher aktuell keine per WinGet lokal im Nutzerprofil vergebenen „Pins“ beachten (keine Unterstützung von lokalem WinGet-Pinning). Wiederum ist dieses Verhalten auch so erwünscht, da Managed Deploy als globale Softwareverteilungslösung konzipiert ist und somit die Einstellungen von Managed Deploy stets Vorrang haben sollen vor lokalen/individuellen WinGet-Einstellungen.

Verteilstatus wird nicht korrekt angezeigt

Bei der initialen Installation von Apps auf einem System kann es in seltenen Fällen passieren, dass der Verteilstatus nicht korrekt angezeigt wird. Der Status bleibt dann auf „anstehend“, obwohl die App bereits erfolgreich installiert werden konnte. In solchen Fällen hilft es, wenn eine Neuberechnung des Verteilstatus angestoßen wird. Das geschieht am einfachsten dadurch, dass die App-Sammlung, in der sich die zu installierende App befindet, einmal deaktiviert und danach wieder aktiviert wird.

Probleme bei der Verteilung von Apps

Egal ob Installation, Aktualisierung oder Löschen: Die Verteilung kann daran scheitern, dass die fragliche App gerade genutzt wird. Oder dass ein Neustart des Systems benötigt wird, damit die Verteilung überhaupt durchgeführt oder abgeschlossen werden kann. Somit gilt allgemein: Kann eine App auf einem bestimmten System nicht verteilt werden, so sollte die App dort geschlossen werden; hilft das nicht, sollte evaluiert werden, ob Neustarts des System zu einer Verbesserung führen.

Keine Aktivität auf einem System

Sollte auf einem System überhaupt keine Aktivität von Managed Deploy zu erkennen sein: Um mit Managed Deploy verwaltet werden zu können, muss das System mit dem Internet verbunden sein. Eine Verbindung zu servereye über einen OCC-Connector reicht nicht aus.

Nutzung von Managed Deploy bei Systemen mit Proxys

Die dazu notwendigen Einstellungen werden in einem eigenen KB-Artikel beschrieben: [BETA] Nutzung von Managed Deploy mit Proxys.

Nutzung durch Mandantenaccounts

Die Nutzung von Managed Deploy durch Anwender von verwalteten Kunden (sogenannte Mandantenaccounts) ist aktuell nicht vorgesehen und wird somit programmatisch verhindert.

Nutzung durch Hochgestufte Endkunden

Endkunden, welche sich im OCC selbst verwalten dürfen (sogenannte Hochgestufte Endkunden), können Managed Deploy nutzen und somit ihre Softwareverteilung selbst verwalten. Allerdings ist es nicht möglich, dass der Hochgestufte Endkunde  vom Systemhaus in Managed Deploy verwaltet wird.

Deaktivierung von Managed Deploy 

Wenn Du Managed Deploy für bestimmte Systeme wieder deaktivieren willst, so musst Du nur den Managed Deploy Sensor wieder auf den Systemen löschen. Das geht nicht innerhalb von Managed Deploy, sondern so wie jeder andere Sensor auch gelöscht wird.


Tipp: Falls Du den Sensor von vielen Systemen löschen willst, so nutze doch die Suchfunktion des OCC.


Probleme bei bestimmten Apps

Draw.io (JGraph.Draw)

Symptom: Wenn versucht wird, Draw.io mittels Managed Deploy zu installieren, so wird zwar in Managed Deploy eine erfolgreiche Durchführung angezeigt, allerdings wurde es gar nicht installiert.

Ursache: Der Installer dieser App hat die Installation im Systemkontext nicht korrekt implementiert. Deshalb meldet er einen Erfolg, obwohl die Installation nicht wirklich durchgeführt wurde.

Lösung: Aktuell kann diese App nicht über Managed Deploy installiert werden. Die Verteilung muss deshalb manuell erfolgen.

Foxit PDF Reader (Foxit.FoxitReader.Inno)

Symptom: Die Installation von Foxit PDF Reader schlägt fehl. Fehlermeldungen im Log weisen auf zu lange Installationszeiten hin, so dass der Vorgang abgebrochen (Timeout) wurde (typischerweise nach 30 Minuten). Log-Meldung lautet also beispielsweise wie folgt: „Installation of package Foxit PDF Reader timed out after 30 minutes“.

Ursache: Der Installer erwartet eine Eingabe des Endanwenders bzw. versucht, ein Fenster anzuzeigen, obwohl mittels Managed Deploy ein sogenanntes Silent-Install forciert wird.

Lösung: Aktuell kann diese App nicht über Managed Deploy installiert werden. Die Verteilung muss deshalb manuell erfolgen.

Greenshot (Greenshot.Greenshot)

Symptom: Greenshot ist auf dem fraglichen System bereits installiert. Es wird dann über Managed Deploy eine Aktualisierung angestoßen. Die Aktualisierung schlägt fehl (kann in den Logs von Managed Deploy nachvollzogen werden), danach ist Greenshot deinstalliert!

Ursache: Der von Greenshot verwendete Installer deinstalliert bei jeder Aktualisierung zuerst die vorhandene Version, bevor dann versucht wird die aktuelle Version zu installieren. Allerdings beendet der Installer laufende Greenshot-Prozesse nicht. Da somit bei laufendem Greenshot nicht alle Dateien vom Installer gelöscht werden können, schlägt der folgende Installationsversuch fehl. Allerdings führt das teilweise Löschen der Daten dazu, dass Greenshot danach als deinstalliert erscheint. Dieses Verhalten ist keine Fehlfunktion von Managed Deploy, denn wenn versucht wird, manuell über WinGet bei laufendem Greenshot eine Aktualisierung durchzuführen, so führt dies zum gleichen Fehlerbild.

Lösung: Vor dem Aktualisieren müssen alle laufenden Greenshot-Prozesse auf dem System manuell beendet werden.

Modbus Poll (WitteSoftware.ModbusPoll)

Symptom: Modbus Poll kann nicht mittels Managed Deploy installiert werden. Fehlermeldungen im Log weisen auf Probleme beim Download hin („Error while trying to download package Modbus Poll“).

Ursache: Hier kann es mehrere mögliche Ursachen geben: Die Downloadlinks können temporär nicht erreichbar sein. Ebenso kann es auch Diskrepanzen zwischen dem Hash, der im WinGet-Repsoitory hinterlegt ist, und dem tatsächlichen Hash des Installers geben.

Lösung: In beiden Fällen können wir von servereye nichts an diesen externen Fehlern tun. Tipp: Möglicherweise kann es helfen, den Herausgeber der App über diese Probleme zu informieren, so dass diese behoben werden und danach eine funktionierende Lösung auch in Managed Deploy bereit steht.

Nextcloud Talk (Nextcloud.Talk)

Symptom: Der Versuch, Nextcloud Talk mittels Managed Deploy zu verwalten, führt zu widersprüchlichen Anzeigen in Managed Deploy (beispielsweise wird die App als erfolgreich installiert angezeigt, obwohl sie es nicht ist oder eine zuvor erfolgte manuelle Installation kann nicht mittels Managed Deploy aktualisiert werden).

Ursache: Es kann nicht auf die aktuelle Nextcloud Talk Version 2.0.4 aktualisiert werden, auch nicht manuell mittels WinGet. Eine Neuinstallation von Version 2.0.4 ist hingegen möglich.

Lösung: Aktuell kann diese App nicht vollautomatisch auf Version 2.0.4 aktualisiert werden. Die vorherige Version muss zuerst manuell (nicht mittels Managed Deploy) deinstalliert werden, danach kann v2.0.4 neu mittels Managed Deploy installiert werden.