Bei der Paketierung in DSM gibt es ja verschiedene Möglichkeiten, dafür zu sorgen, dass Pakete nur unter bestimmten Bedingungen und Voraussetzungen auf den gemanagten Clients installiert werden. Zu nennen wären hier (ohne Anspruch auf Vollständigkeit):
- unterstützte Plattformen
- serverseitige Voraussetzungen
- clientseitige Voraussetzungen
- Bedingungen für vorhandene Installationen
Die Bedingungen für unterstützte Plattformen sollten klar sein: es werden nur für die Policy-Ziele auch Policy-Instanzen erzeugt, die eine der von dem Paket unterstützten Plattformen verwenden. Ebenso verhält es sich mit serverseitigen Voraussetzungen, auch hier wird eine Policy-Instanz nur dann erzeugt, wenn der Business Logic Server erkennt, dass die angegebenen Voraussetzungen von einem Policy-Ziel erfüllt sind.
Anders verhält es sich jedoch bei clientseitigen Voraussetzungen: für die Policy-Ziele werden auf jeden Fall Policy-Instanzen erzeugt (sofern die Plattform-Einstellungen und serverseitigen Voraussetzungen dem nicht widersprechen). Da DSM aber nicht alle erdenklichen Zustände über die verwalteten Clients in seiner Datenbank speichern kann, werden solche clientseitigen Voraussetzungen erst zur Laufzeit auf den Endgeräten geprüft und dann entschieden, ob die Installation ausgeführt wird oder nicht.
Ein naheliegender Anwendungsfall für die Verwendung von clientseitigen Voraussetzungen ist daher beispielsweise die Prüfung, ob genug freier Speicherplatz für die Installation eines Pakets zur Verfügung steht oder ob die Installation durch die Existenz eines Flags in der Registry oder im Dateisystem erlaubt ist. Bei diesem Vorgehen lauert jedoch "eine böse Falle"...
Für clientseitige Voraussetzungen stehen ja die gleichen Bedingungen zur Verfügung wie für den IF-Befehl. Das heißt, ob ein Paket installiert werden soll, lässt sich entweder im Vorfeld der Installation prüfen, oder im Rahmen der Paketausführung über entsprechende IF-Bedingungen.
Ein Vorteil der clientseitigen Bedingungen besteht darin, dass ein Paket – sofern die Bedingungen nicht erfüllt sind – auch nicht gestaged wird, es wird also nicht in den Repository Cache geladen. Dadurch kann verhindert werden, dass große Datenmengen unnötig auf den Client übertragen werden, wenn das Paket ohnehin nicht installiert werden kann. Wird die Prüfung im Rahmen des Scripts in einem IF-Befehl durchgeführt, muss das Paket bereits vollständig gestaged worden sein.
Was allerdings wenig bekannt ist, ist dass nicht erfüllte clientseitige Voraussetzungen auch zu einer Deinstallation führen, sofern das Paket das unterstützt und die Bedingung nicht mehr erfüllt ist!
Dies kann schnell zu ungewollten Situationen führen, wenn beispielsweise eine Voraussetzung über einen gewissen freien Festplattenspeicherplatz durch eine DiskFree-Bedingung dadurch nicht mehr erfüllt ist, dass der Anwender später – lange nach der Installation des Pakets – eine große Datenmenge auf den Client kopiert. Fällt der dann freie Speicherplatz unter den in der Bedingung angegebenen Wert und ist diese daher nicht mehr erfüllt, wird DSM versuchen, das Paket zu deinstallieren und die Policy-Instanz geht auf "blau" mit der Beschreibung "Client-Voraussetzungen nicht erfüllt".
Um ein solches – in der Regel ungewolltes – Verhalten zu vermeiden, gibt es zwei Möglichkeiten:
- Die Prüfung der Bedingungen im Rahmen von IF-Befehlen innerhalb des eScripts. Dort kann flexibel auf den vorgefundenen Zustand reagiert und die Scriptausführung über ExitProcEx abgebrochen werden. Ob das Paket als fehlgeschlagen betrachtet wird oder ob die Policy-Instanz "pending" bleibt und die Installation im nächsten Installerlauf erneut versucht wird, entscheidet dabei der Paketierer. Nachteil dieses Ansatzes ist, wie oben schon beschrieben, dass stets das gesamte Paket in den Repository-Cache geladen werden muss, unabhängig davon, ob die Prüfung fehlschlägt oder erfolgreich ist.
- Eine wenig bekannte und nicht dokumentierte Möglichkeit ist das Setzen einer Einstellung in der Konfigurationstabelle. Diese ist allerdings nur im RAW-Mode verfügbar, sodass, um sie zu setzen, das Kennwort des DSM System-Kontos benötigt wird (vgl. https://community.ivanti.com/docs/DOC-60495). Nachdem die DSM Konsole im RAW-Mode gestartet wurde, wechseln Sie in die Ansicht "Infrastruktur" und markieren das ORG-Element. Im Abschnitt Installation der Konfigurationstabelle gibt es nun die Einstellung raw: AllowInstalledPackagesToExist, deren Standardwert Nein ist. Wenn Sie diesen Wert auf Ja ändern und diese Einstellung speichern, werden zukünftig Pakete, deren clientseitige Voraussetzungen nicht mehr erfüllt sind, nicht deinstalliert, auch wenn die Pakete die Deinstallation unterstützen.
