Zum 23.08.2023 ist die NWC Services GmbH zur CANCOM GmbH geworden. Besuchen Sie uns gerne auf www.cancom.de
Toggle Bar

BLOG

BLOGGING CONSULTANTS

NWC Services Blog

Blogs von Consultants der NWC Services GmbH

Clientseitige Voraussetzungen in DSM

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.

b2ap3_thumbnail_AvailableConditions.png

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:

  1. 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.
  2. 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.

    b2ap3_thumbnail_AllowInstalledPackagesToExist.png

 

 

×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Das Konzept der Fileablage in SCCM (SCCMContentLib...
Informationen von eigenen ODS Wartungsplänen per P...

Ähnliche Beiträge

 

Kommentare 1

Andreas Fey (webseite) am Mittwoch, 24. Januar 2018 14:37

Hallo,

vielen Dank für den Tip. In die besagte Falle bin ich auch kürzlich gelaufen. Auf einmal deinstallierte sich die ganze Software von den PCs, weil die Festplatte zu wenig Speicherplatz hatte. Besonders unschön: Dieses Verhalten gab es früher nicht und wurde ab einem bestimmten Versionsupdate eingeführt.

Viele Grüße, Andreas

Hallo, vielen Dank für den Tip. In die besagte Falle bin ich auch kürzlich gelaufen. Auf einmal deinstallierte sich die ganze Software von den PCs, weil die Festplatte zu wenig Speicherplatz hatte. Besonders unschön: Dieses Verhalten gab es früher nicht und wurde ab einem bestimmten Versionsupdate eingeführt. Viele Grüße, Andreas
Bereits registriert? Hier einloggen
Freitag, 29. März 2024

Sicherheitscode (Captcha)