Jeder, der sich selbst realistisch einschätzt wird wohl zugeben, dass ihm auch schon mal ein Fehler beim Paketieren passiert ist. Was macht man in so einem Fall? Je nach Schweregrad des Fehler kann ein neues Paket erstellt oder auch das bestehende Paket modifiziert werden.
Für Modifikationen an bestehenden Paketen bietet DSM die Möglichkeit der Revisionierung an. Obwohl die Revision X eines Paketes aktiviert ist kann es in der Revision X+1 bearbeitet und getestet werden. Ist die Bearbeitung und das Testen erfolgreich beendet so kann die korrigierte Revision für die Verteilung freigegeben werden.
Um die neue Revision des Paketes für die Verteilung zu aktivieren muss die bestehende Policy aktualisiert werden. Hier kann man entscheiden, ob die neue Revision nur auf PCs zum tragen kommt auf denen das Paket noch nicht installiert wurde (unkritische Änderung) oder auf allen Computern mit der gewünschten Zuweisung erneut ausgerollt wird, d.h. auch auf den PCs, auf denen bereits eine vorherige Revision installiert wurde (kritische Änderung).
Für Einzel-Zuweisungen ist diese Entscheidung relativ leicht zu treffen. Wie behandelt man die Thematik jedoch im Fall von Software-Sets?
Kritisch oder unkritisch – das ist die Frage
Bei Änderungen an Paketen die als Komponenten in Software-Sets verwendet werden ist die Frage ob eine Revisionsänderung kritisch oder unkritisch ist – zumindest auf den zweiten Blick eigentlich eindeutig zu beantworten:
Bei Software-Sets gibt es keine unkritischen Änderungen
Natürlich kann bei der Aktualisierung einer Software-Set-Policy die Option „unkritische Änderung“ gewählt werden. Da Software-Sets eine „Komponenten-Bildung“ von einzelnen (Software-)Paketen darstellen, ist es normalerweise nur eine Frage der Zeit, bis weitere Änderungen an dem Software-Set notwendig werden. Und hier ist es wiederum nur eine Frage der Zeit bis eine Änderung einen kritischen Charakter annimmt. Spätestens zu diesem Zeitpunkt werden alle bisher durchgeführten unkritischen Anpassungen an dem Software-Set auch zu kritischen Änderungen und damit laufen die „unkritisch“ veränderten Pakete auf den Clients erneut an.
Vor diesem Hintergrund empfehle ich Software-Set Aktualisierungen immer als kritisch auszuführen und die modifizierten Pakete entsprechend anzupassen. Folgende Vorlage ist hierfür verwendbar:
Die erste Script-Zeile prüft ob das Paket (in einer beliebigen Revision) bereits installiert ist. Falls nicht, handelt es sich auf dem entsprechenden PC um die erstmalige Installation des Pakets und es darf ausgeführt werden.
Ist das Paket bereits installiert wird in der zweiten IF-Bedingung geprüft ob die Revision bereits aktuell ist. Falls nicht, wird das Paket mit ExitProcEx(DONE) verlassen und nicht erneut ausgeführt. Ein entsprechender Eintrag im Kommentarfeld hilft um die entsprechende Konstellation auch in der DSM-Konsole besser nachvollziehen zu können.
Die zweite IF-Bedingung ist notwendig um auch den Re-Install oder Reparaturfall zu ermöglichen. Ist das Paket bereits auf dem aktuellen Revisionsstand und eine Installationsanforderung seitens des BLS liegt an, kann es sich nur um einen gewünschten Fall handeln. In diesem Fall wird die ExitProcEx – Anweisung übersprungen und das Paket erneut installiert.
