Wenn eine Paketierung überall funktioniert… außer bei einigen Geräten

application packaging challenges

Sie testen ein Paket, und alles verhält sich genau wie erwartet. Die Installation funktioniert, die Deinstallation funktioniert, und Upgrades werden ohne Probleme durchgeführt.

Die Bereitstellung beginnt, und die meisten Geräte verhalten sich auch weiterhin so wie bisher. Aus Sicht der Paketierung sieht alles stabil und vorhersehbar aus.

Dann gibt es einige wenige Rechner, bei denen die Installation fehlschlägt, das Upgrade nicht abgeschlossen wird oder die Anwendung einfach nicht startet. Das ist inkonsequent und schwer zu erklären. Dasselbe Paket, derselbe Bereitstellungsansatz und scheinbar dieselbe Umgebung, und doch ist das Ergebnis unterschiedlich.

In realen Umgebungen ist dies selten ein Zufall.

Nach unserer Erfahrung, die wir in enger Zusammenarbeit mit unseren Kunden gewonnen haben, lassen sich solche Fälle in der Regel auf kleine Umgebungsunterschiede zwischen den Geräten zurückführen. Diese Unterschiede bleiben in kontrollierten Testaufbauten oft unsichtbar, aber in der Produktion werden sie sehr real.

Und wenn man erst einmal weiß, wo man suchen muss, ergeben diese so genannten mysteriösen Misserfolge in der Regel einen Sinn.

Grund 1. Unterschiedliche Policies und GPO-Konfigurationen

Wenn ein Paket auf den meisten Geräten funktioniert, aber auf einigen wenigen nicht, ist eines der ersten Dinge, die zu überprüfen sind, ein Unterschied in den Richtlinien, die für bestimmte Geräte gelten.

In vielen Kundenumgebungen sind nicht alle Geräte auf die gleiche Weise konfiguriert. Unterschiedliche Organisationseinheiten, Sicherheits-Baselines oder historische Konfigurationen können dazu führen, dass für bestimmte Geräte strengere Regeln gelten als für andere.

Wir haben Fälle erlebt, in denen Installationen nicht aufgrund eines Fehlers bei der Paketierung fehlgeschlagen sind, sondern weil lokale oder Domänenrichtlinien Teile des Prozesses stillschweigend blockiert haben. Dies kann Installationsschritte betreffen, die sich auf skriptgesteuerte Logik oder Konfigurationsaufgaben auf Systemebene stützen. Beispielsweise können PowerShell-Ausführungsbeschränkungen oder damit verbundene Sicherheitsrichtlinien auf bestimmten Geräten die Ausführung dieser Schritte verhindern, was dann dazu führt, dass die Installation fehlschlägt oder sich anders verhält als im Test.

Auch andere richtlinienbasierte Einschränkungen können die Logik der Paketierung beeinträchtigen. Die Ausführung aus bestimmten Ordnern kann eingeschränkt sein, bestimmte Systemstandorte können stärker geschützt sein oder Sicherheitsregeln können verhindern, dass Teile des Installationsablaufs abgeschlossen werden.

Grund 2. Unterschiedlicher Berechtigungskontext auf Geräten

Ein weiterer Grund, warum sich ein Paket auf verschiedenen Geräten unterschiedlich verhalten kann, ist der Berechtigungskontext, in dem es ausgeführt wird.

Beim Testen führen wir Installationen in der Regel in einem Systemkontext aus, der erhöhte Berechtigungen bietet. Auf realen Geräten können jedoch lokale Sicherheitseinstellungen, die Gerätekonfiguration oder zusätzliche Einschränkungen den Installationsablauf beeinflussen und die Möglichkeiten des Prozesses zur Änderung des Systems einschränken.

In einigen Fällen funktionierten Pakete, die beim Testen einwandfrei funktionierten, auf bestimmten Geräten nicht, weil für bestimmte Aktionen Zugriffsrechte erforderlich waren, die in dieser Umgebung nicht effektiv gewährt wurden. Dies kann das Schreiben in geschützte Systembereiche, die Änderung von Teilen der Registrierung oder die Registrierung von Diensten und Komponenten betreffen.

Die Logik der Paketierung war korrekt. Der Unterschied bestand lediglich darin, dass nicht jedes Gerät in der Praxis den gleichen Zugriff zuließ.

Grund 3. Abweichendes Anwendungsset und fehlende Voraussetzungen

Ein weiterer häufiger Unterschied zwischen den Geräten ist die Menge der bereits auf dem System installierten Anwendungen und Komponenten.

Testumgebungen werden in der Regel mit einer Standard-Baseline vorbereitet. Reale Geräte können jedoch eine sehr unterschiedliche Softwarelandschaft aufweisen. Einigen fehlen möglicherweise Komponenten, die von der Anwendung stillschweigend erwartet werden, während auf anderen bereits ältere oder widersprüchliche Versionen vorhanden sein können.

Dies kann zu Situationen führen, in denen ein Paket beim Testen wie erwartet funktioniert, aber auf bestimmten Geräten fehlschlägt, weil eine erforderliche Laufzeit, ein Framework oder eine unterstützende Komponente nicht verfügbar ist. In anderen Fällen kann auch das Vorhandensein einer unerwarteten Version einer verwandten Anwendung die Installations- oder Konfigurationsschritte beeinträchtigen.

Grund 4. Unterschiede in Betriebssystemversion und Build

Auf den Geräten läuft zwar scheinbar dasselbe Betriebssystem, aber in der Praxis können erhebliche Unterschiede in Bezug auf Version und Build-Level bestehen.

Beim Testen werden die Pakete in der Regel für eine bestimmte Anzahl von Betriebssystemversionen validiert. In realen Umgebungen können Geräte mit unterschiedlichen Builds arbeiten, unterschiedliche kumulative Updates installiert haben oder zusätzliche Systemänderungen enthalten, die das Verhalten von Anwendungen beeinflussen.

Dies ist insbesondere für Anwendungen relevant, die von bestimmten Systemkomponenten, Diensten oder Integrationen mit dem Betriebssystem abhängig sind. Ein Paket, das auf einem Build korrekt funktioniert, kann sich auf einem anderen anders verhalten, auch wenn beide als dieselbe Betriebssystemgeneration gekennzeichnet sind.

Grund 5. Reste früherer Anwendungsversionen

Ein weiterer wichtiger Unterschied zwischen den Geräten ist ihre Anwendungsgeschichte.

Auf einigen Geräten ist möglicherweise bereits eine frühere Version der gleichen Anwendung installiert. In anderen Fällen kann eine ältere Version manuell oder durch einen anderen Prozess entfernt worden sein und Dateien, Registrierungseinträge oder Konfigurationsdaten hinterlassen haben.

Nicht alle Installationsprogramme der Hersteller handhaben Upgrades oder Bereinigungen auf einheitliche Weise. Infolgedessen kann ein neues Paket auf Geräten, auf denen noch Spuren einer älteren Version vorhanden sind, auf unerwartete Bedingungen stoßen. Dies kann zu fehlgeschlagenen Installationen, unvollständigen Upgrades oder Anwendungen führen, die zwar installiert werden, aber nicht richtig funktionieren.

Dies sind natürlich nicht die einzigen Gründe, warum sich ein Paket auf verschiedenen Geräten unterschiedlich verhalten kann. Sie gehören jedoch zu den häufigsten Situationen, auf die wir bei der Zusammenarbeit mit Kunden und bei der Untersuchung von realen Installationsproblemen stoßen.

Die wahre Arbeit hinter der Paketierung

Wenn eine Verpackung auf den meisten Geräten funktioniert, aber auf einigen wenigen nicht, bedeutet das in der Regel nicht, dass die Verpackung selbst falsch ist. In vielen Fällen liegt die Ursache in subtilen Unterschieden zwischen den Geräten, die nicht sofort sichtbar sind.

Situationen wie diese sind ein natürlicher Bestandteil der Arbeit mit realen Produktionsumgebungen. Diese Unterschiede zu erkennen und zu verstehen, wie sie sich auf das Installationsverhalten auswirken, ist ein wichtiger Bestandteil der professionellen Paketierung. Unsere Aufgabe besteht nicht nur darin, Pakete zu erstellen, die beim Testen funktionieren, sondern auch darin, Kunden bei der Untersuchung und Lösung von Problemen zu unterstützen, die in verschiedenen Gerätelandschaften auftreten.

Wenn Sie bei der Anwendungspaketierung auf Probleme stoßen, können Sie sich gerne an uns wenden.

More News from Apptimized

Intune packaging with Apptimized

Every company needs to keep personal and corporate data secure…

Warum Updates wichtig sind: Alte Apps, neue Gefahren

Wann haben Sie das letzte Mal bei einem Software-Update auf…

Software-Patching, -Aktualisierung und -Bereitstellung: So automatisieren Sie Prozesse als kontinuierlichen Ablauf

Donnerstag, 15. Oktober 2020 15:00 Uhr MEZ (9:00 Uhr New…