7 Replies Latest reply on Feb 18, 2016 8:24 AM by SitzRieSe

    DSM 2015.2 Installationsablauf

    SitzRieSe Expert

      die installationsreihenfolge ist die reihenfolge in der installiert werden SOLL
      das ausführungsdatum entspricht der reihenfolge in der tatsächlich ausgeführt WURDE
      (diese unterscheidung zwischen wunsch und wirklichkeit ist in der neuen version recht wichtig)

      bei patch policies ist die installationsorder wie gesagt eigentlich irrelevant

      was die reihenfolge angeht, sollte im log etwa folgendes auftauchen

      Resorting Jobs...
      SPD-Option SusSiteInstSequence set to: SPD LAST
      Re-inserting WUA and PM Exec Package jobs to the end of the job list
      Found a in the job list [...]
      die letzten einträge sind die pakete, die ans ende verschoben werden.

      wenn du ein escript verwendest, dann wird das natürlich nicht verschoben.
      machst du dagegen eine kopie des patch management execution packages und machst da den inhalt deines escripts rein, dann sollte das mit umsortiert werden.
      ...aber das hätte (vorausgesetzt ich hab das problem richtig verstanden) schon immer so sein müssen

      alternativ kannst du auch einfach einstellen reihenfolge beibehalten und dann die installationorder für dein escript und das client paket so setzen wie du's haben willst.
      Reply With Quote



      Hi Mel,

      ich dachte ich greif das Thema jetzt nochmal in einem neuen Thread auf. Ich habe jetzt nochmal etwas rumprobiert und kriege es nicht so hin wie ich es mir vorstelle.

      Ich möchte im Grund eine Installationroutine die das OS, Treiber, Software und am Ende alle Patche installiert inkl. nötiger Neustarts. Bisherige Vorgehensweise die auch definitiv funktioniert hat.

      Execution Package mit 1x täglich zugewiesen.
      APM mit "Nach den Software-Paketen" ausgewählt.
      selbstgebautes eScript Paket am Ende der Installationsroutine laufen gelassen welches die Updates über das APM installiert und Neustarts durchführt.

      In dem Fall wurde nach der Windows Installation direkt der APM Client installiert. NUR der Client. Danach alle Treiber, Software und am Ende mein eScript Paket.

      In der neuen Version wird mit der Option "Patche nach den Software-Paketen installieren" der APM Client erst nach allen normalen Softwarepaketen installiert. Dadurch funktioniert mein eScript nicht mehr, denn der APM Client fehlt.

      Was ich jetzt getestet habe:

      ich habe das Execution Package kopiert und im Anschluss den Inhalt meines eScriptes dort eingefügt. Das Execution Package hab ich dann als normale Software Policy (keine Job Policy) dem Client zugewiesen. Das APM stand wieder auf Nach den Software-Paketen ausführen. Hierbei hab ich das gleiche Verhalten! Nach deiner Erklärung hätte ich erwartet das er alle Softwarepakete durch geht und danach den APM Client und dann mein angepasstes Execution Package ausführt. Das tut er nicht! Er versucht zuerst mein Execution Package auszuführen was dann dazu führt das es nicht weiter läuft.

      2. Test, Paket als Job Policy mit "Am Ende einer Neuinstallation" zugewiesen. Der Versuch verwundert mich etwas. Hier hat er wie vorher auch alle Software Pakete installiert und im Anschluss dann den APM Client installiert. Bei der Installation des APM Client scheint er aber schon die Patch Installation zu triggern. Siehe hier:

      http://up.picr.de/23735123kw.png

      Ich hatte alle Execution Packages gestoppt! Die dürften nicht ausgeführt werden und sind auch entsprechend am Client grau markiert.

      Hinzu kommt, das er ein Patch nicht installieren konnte. Bei der ersten Benutzeranmeldung läuft nun wieder das APM Client Package los und versucht den Patch wie auf dem Screenshot zu installieren. Dabei befindet er sich jetzt aber in einem Loop. Zumindestens probiert er das immer wieder und kommt nicht weiter.

      KORREKTUR:

      Das APM Client führt keine Patch Installation aus wie ich es vorhin gedacht habe. Ich glaube ich habe die Pakete zu spät deaktiviert.
      Grüße
        • 1. Re: DSM 2015.2 Installationsablauf
          _Mel_ Master
          das mit der loop liegt wohl daran, daß wenn ein patch nicht richtig funktioniert, die vulnerability beim nächsten scan wieder auf offen geht und darauf der server ein reinstall antriggert (war früher auch so, aber da hat der client bis zum nächsten installerlauf gewartet - ich denke das wird gefixt werden)

          bedeutet deine korrektur, daß es jetzt richtig funktioniert ?
          andernfalls schau mal in den installerlogs nach den einträgen, die ich geschrieben habe.

          hast du nur dein paket verwendet, oder hattest du auch das normale PM execution package zugewiesen ? im zweiten fall könnte es das erklären warum es früher funktioniert hat, dann hätte er früher nämlich nur die ausführung der execution packages ausgefiltert und das client paket nicht umsortiert; wogegen ohne eine solche zuweisung das client package ans ende umsortiert wurde...
          • 2. Re: DSM 2015.2 Installationsablauf
            derniwi Master
            Hallo,

            noch ein paar Gedanken:
            - passen denn die Kontext-Einstellungen für die Installation? Sprich, kann es sein, dass Dein Paket im Kontext des Service läuft, dass des APM-Clients im Benutzerkontext?
            - kannst Du deinem Paket keine Abhängigkeit hinzufügen, dass der APM-Client zuvor installiert worden sein muss?

            Gruß
            Nils
            • 3. Re: DSM 2015.2 Installationsablauf
              SitzRieSe Expert

              Hallo,

              noch ein paar Gedanken:
              - passen denn die Kontext-Einstellungen für die Installation? Sprich, kann es sein, dass Dein Paket im Kontext des Service läuft, dass des APM-Clients im Benutzerkontext?
              - kannst Du deinem Paket keine Abhängigkeit hinzufügen, dass der APM-Client zuvor installiert worden sein muss?

              Gruß
              Nils



              Hi Nils,

              ja die Kontext-Einstellungen sind korrekt. Ich arbeite mit einem Autologon, alle Pakete werden mit dem Autoinstaller installiert. Das APM und mein Paket werden beide eigtl im Benutzerkontext ausgeführt.

              Mit den Abhängigkeiten ist das so eine Sache... Wenn ich das konfiguriere würde er ja zum nächsten Paket springen. Das wäre dann in meinem Fall das Paket was den Autologin deaktiviert und eigtl den Rechner für die Benutzung frei gibt.

              ich glaube Mel hat schon Recht. Es scheint an der Umsortierung zu liegen. Bisher wurde aber und das hab ich jetzt in 3 Umgebungen so laufen, nicht der APM Client mit umsortiert sondern nur das Execution Package.

              ..

              Ihr könnt das ganz einfach testen. Kopiert mal das Execution Package und weißt es als normale Software Policy zu (nicht Job) und dann schaut mal wann das Paket ausgeführt wird.

              PS: Wenn ich übrigens das APM umstelle, Patche vor dem Software Update installieren... Funktioniert es Da laufen dann halt nur Patche bereits nach dem Windows drauf.

              Grüße
              • 4. Re: DSM 2015.2 Installationsablauf
                derniwi Master
                Ich kann das so nicht testen, ich habe die neue Version noch nicht installiert.
                Aber ich kenne das Problem mit den Abhängigkeiten. Ich habe hier ein Paket, welches eine Anwendung installiert, die als Voraussetzung für eine weitere notwendig ist. Aber nach der Installation des Paketes werden aktuell (DSM 2015.1) die Abhängigkeiten nicht neu berechnet, ich habe auch keine Methode, dies anzustoßen. Somit wird das nächste Paket erst im nächsten Installer-Lauf eingespielt.

                Du müsstest also eine klare Linie definieren, welche Pakete wovon abhängen und ggfs. am Ende der jeweiligen Pakete einen Neustart einbinden. Für die Erst-Installation eines Rechners ist das ja durchaus ok. Später muss man halt schauen, wie man das den Benutzern zumuten will / kann. Ist halt doof, wenn man eine Anwendung einspielen möchte und dafür drei Neustarts braucht...

                Da ich die Microsoft Updates nach wie vor über den WSUS einspiele, habe ich hierfür ein Paket, was diese Aufgabe erledigt und welches mehrfach ausgeführt werden darf. Dieses Paket gibt es auch noch als normale Version, so dass die erste Update-Orgie gleich nach der Windows-Installation stattfindet. Das Paket mit mehrfacher Installation ist dann an verschiedene Software-Sets gebunden (z.B. Microsoft Office, SAP Gui oder was auch immer irgendwelche Komponenten aus der MS-Welt einspielt) und zum Abschluss läuft die zweite Kopie, einfach um sicher zu gehen. Soweit klappt das auch gut und hat den Vorteil, dass später auch Anwendungen verteilt werden können, die nur mit begrenzten Lizenzen vorhanden sind (z.B. haben alle hier Office, aber nur wenige Visio), und dann bekommen die Leute eben die Pakete je nach Lizenzen und Anforderungen zugeordnet und im Rahmen der Paketinstalltion auch gleich die Updates.
                • 5. Re: DSM 2015.2 Installationsablauf
                  _Mel_ Master
                  also im log sieht das so aus

                  09:44:35.336 0   SWMSRT: Update of downloaded packages completed.

                  09:44:35.336 1   SWMSRT: -------- Start deleting user parts from old packages --------------------------
                  09:44:35.336 0   SWMSRT: Deleted 0 old user parts

                  09:44:35.336 1  -------------------------------------------------------------------------------

                  09:44:35.336 0  Resorting Jobs...
                  09:44:35.336 0  0 Pending Jobs

                  und nach dem "Resorting Jobs..." würde patch management umsortieren, wenn in der umgebung aus der das logfile ist patch management laufen würde.

                  geändert hat sich so wie ich das sehe
                  früher: wenn nicht SPD pakete zur ausführung anstehen, würden die execution pacakges entfernt und patch client pakete normal ausgeführt
                  jetzt: execution packages und patch client pakete werden immer ans ende umsortiert.
                  • 6. Re: DSM 2015.2 Installationsablauf
                    _Mel_ Master


                    Aber ich kenne das Problem mit den Abhängigkeiten. Ich habe hier ein Paket, welches eine Anwendung installiert, die als Voraussetzung für eine weitere notwendig ist. Aber nach der Installation des Paketes werden aktuell (DSM 2015.1) die Abhängigkeiten nicht neu berechnet, ich habe auch keine Methode, dies anzustoßen. Somit wird das nächste Paket erst im nächsten Installer-Lauf eingespielt.


                    also in der 2015.2 hat es sofort auswirkungen wenn sich die auswertung der clientvoraussetzungen ändert - allerdings hätte ich gedacht, daß das auch früher schon funktioniert hat. ...spätestens beim nächsten run innerhalb eines installerlaufs.
                    • 7. Re: DSM 2015.2 Installationsablauf
                      SitzRieSe Expert
                      Hi Leute,

                      ich bin nun selber auf die Lösung meines Ursprungsproblem gekommen, vielleicht hiflt sie jemand anderen auch.

                      Nochmal kurz zur Beschreibung! Mein Problem war das seit der 2015.2 mit der Einstellung vom PM "Nach Software Installation", nicht nur die Patche am Ende der Installation durchgeführt werden, sondern auch der Patch Client am Ende installiert wird.

                      In der 2015.1 war das noch anders. Dort wurde mit dieser Einstellung lediglich die Patche ans Ende der Installation gesetzt. Das Problem was ich mit dem neuen Verfahren hatte war, das mein angepasstes Execution Package nicht mehr Updates installieren konnte weil der Client gefehlt hat und er durch die Zuweisung als "normale" Installation (nicht Job) das Paket mit den anderen Pakete ausgeführt hat. Sprich nach den Software Installationen, aber vor der Installation des PM Clients.

                      Was ich jetzt gemacht habe... ich habe das Patch Management auf die Einstellung "Installationsreihenfolge beibehalten" gestellt. Anschließend hab ich die bestehenden Policies für die Execution Packages editiert und die Installations ID hochgesetzt.

                      Dadurch hab ich nun mein gewünschtes Verhalten erzielt! Zuerst Windows, Treiber, Patch Client, alle Applikationen und dann mit einem eScript Updates und Reboots bis alle Patche installiert sind.

                      Nachteil! Bei einem DSM Update sollte man die Policies prüfen, da diese automatisch generiert werden und ich mir vorstellen kann das diese Settings unter Umständen wieder zurückgesetzt werden, würde aber bei der nächsten Installation sofort auffallen und hätte kein weiteren Auswirkungen.

                      Vielleicht hilft das Jemand