14 Replies Latest reply on Feb 10, 2015 2:48 AM by Dimitrij

    Staging Einstellungen verändern

    Dimitrij Apprentice
      Guten Morgen.

      Wir haben DSM 7.02 im Einsatz.
      Ich möchte gerne in DSM festlegen, dass die Clients sich nur an einem bestimmten Tag ( sowie bei Microsoft der Patchday ist ) am BLS melden und prüfen ob es Pakete für sie gibt oder nicht. Ist dies überhaupt möglich ? Bei Staging Einstellungen kann ich das, leider nicht festlegen.
      In Forum konnte ich dazu leider kein Thema finden.
        • 1. Re: Staging Einstellungen verändern
          NicoS1 Master
          Hallo Dimitrij,

          das was du vor hast ist ein Thema für den Wartungsplan. Dort kannst du auf 1-Wochen-Basis festlegen, an welchem Tag und in welchem Zeitraum Software installiert werden darf... z.B. jeden Dienstag zwischen 07 und 19 Uhr.

          Bis zur aktuellen Version aber wie gesagt leider nur innerhalb einer Woche... also z.B. Wartungstag jeden Dienstag. Aber in der 2015.1 wird wohl wenn ich das richtig gelesen hab ein RM von mir umgesetzt mit dem man den Wartungsplan auch über längeren Zeitraum definieren kann.

          Gruß
          • 2. Re: Staging Einstellungen verändern
            _Mel_ Master


            Aber in der 2015.1 wird wohl wenn ich das richtig gelesen hab ein RM von mir umgesetzt mit dem man den Wartungsplan auch über längeren Zeitraum definieren kann.

            nicht ganz: die configuration policies wurden entfernt und maintenance plans werden jetzt über variablen definiert. aber die definierbaren zeitfenster sind noch dieselben.
            • 3. Re: Staging Einstellungen verändern
              Dimitrij Apprentice
              Danke NicoS und Mel, für die Info.
              Mit Wartungsplan wird aber der DSM Agent nicht deaktiviert oder ? Sondern nur die Aufgaben die vom Server zugewiesen wurden sind ?
              • 4. Re: Staging Einstellungen verändern
                Frank.Scholer Master
                Hi Dimitrij

                Mit Wartungsplan wird aber der DSM Agent nicht deaktiviert oder ? Sondern nur die Aufgaben die vom Server zugewiesen wurden sind ?


                So ist es... es ist übrigens womöglich auch ne gute Idee, den Client nicht komplett zu deaktivieren, sodass er z.B. schonmal im Hintergrund die Paketdaten runterladen (stagen) kann, um dann am "Patch-Day" direkt eine lokale Installation ausführen zu können (das schont dann das Netzwerk)...

                HTH, Grüße Frank
                • 5. Re: Staging Einstellungen verändern
                  Dimitrij Apprentice
                  Hallo Frank,

                  danke für die Info, da hast du vollkommen Recht, denn am Tag X wenn die Clients mal den " Patch Day" haben sollten wird das ganze Netzwerk larmgelegt es seit den ich defeniere in den Staging Einstellungen wie die Bandbreite genutzt werden kann.

                  Was ist wenn der Client sich die Pakete am Tag X nicht gezogen hatte, weil der z.B. aus war, wird es am nächsten Tag dann versucht oder wird dann wieder auf den nächsten Wartungstag gewartet ?
                  • 6. Re: Staging Einstellungen verändern
                    NicoS1 Master

                    nicht ganz: die configuration policies wurden entfernt und maintenance plans werden jetzt über variablen definiert. aber die definierbaren zeitfenster sind noch dieselben.



                    Okay, danke für die Info, hab gerade nochmal im SelfService geschaut, ist für 2015.2 geplant, mein Fehler. Ein wöchentlicher Wartungsplan ist bei uns im Serverumfeld nämlich leider nicht machbar. Aktuell schalten wir die Systeme per UC4 (einer Art zentral managebarer Taskplaner mit Workflowsystem etc.) und selbstgeschriebenem PowerShell Script zu gegebener Zeit aktiv / inaktiv.

                    @ Dimitrij:
                    Es würde auf den nächsten Wartungstag gewartet.
                    Du hast aber jederzeit noch die Möglichkeit manuell einzugreifen. Entweder du triggerst auf einem Rechner den Installer mit dem "Wartungsfenster ignorieren" Status (aus der Konsole, oder niinst32.exe /AI /IgnoreMW). Oder wenn du einen Emergency Rollout hast (wie z.B. das Flash Player Update Debakel der letzten Tage) könntest du z.B. noch im Paket den Schalter "darf außerhalb der Wartungszeit installiert werden. Vielleicht noch gepaart mit einer Policy Start Zeit. Dann wird das Paket (und nur dieses) beim nächsten Installerlauf installiert, unabhängig vom Wartungsplan).

                    Letzteres wäre noch eine mögliche Alternative, wenn das mit dem "wenn Rechner aus ist, am nächsten Tag installieren" zwingend erforderlich ist. Du kannst, wenn du eine Software zu weist, auch ein Policy Start Datum angeben. Angenommen ihr vereinbart jeden 15. des Monats als Patchday, dann müsst ihr Paketierer / Admins euch abstimmen, das alle Pakete die zwischen den Patchdays zugewiesen werden ein Policy Startdatum auf den 15. des Folgemonats bekommen. Die Rechner Stagen dann ebenfalls vorab, installiert werden darf aber erst am dem 15... dann ist es auch egal ob ein Rechner am 15. online ist, oder Aufgrund von Urlaub oder so erst am 18. online kommt.
                    Das funktioniert auch unabhängig oder auch in Verbindung mit dem Wartungsplan.
                    • 7. Re: Staging Einstellungen verändern
                      Dimitrij Apprentice
                      @ NicoS

                      Danke danke !!!! 
                      Per Hand den niinst32.exe /AI /IgnoreMW auszuführen möchte ich vermeiden.... bei ca. 1500 Clients ist es öfter mal das ein "paar" Stück nicht an sein werden.
                      Die Alternative passt mir besser. Die werde ich mir auch anschauen, thX
                      • 8. Re: Staging Einstellungen verändern
                        NicoS1 Master
                        Hallo Dimitrij,

                        sorry ich muss noch ergänzen. Bei der Alternative gäbe es noch einen "Knackpunkt" der zu Berücksichtigen wäre, bzw. einen Nachteil.

                        Angenommen du weist ein aktuelles Java Paket mit Ausführungsstart dem 15.02. zu, und du installierst einen neuen Computer am 13.02., wird Java auch erst am 15.02. installiert. Hier müsste man überlegen wie man damit am Besten um geht.

                        Bei Wartungsplänen löst man das durch Zuweisen verschiedener Wartungspläne... einen bei der Installation, und danach über eine Dynamische Gruppe oder andere OU z.B. da gibt es viele Wege um das zu lösen.

                        Gruß
                        • 9. Re: Staging Einstellungen verändern
                          Dimitrij Apprentice
                          OK danke für die Info NicoS. Dann kann ich das nicht in meine Umgebung verwenden. Die Clients werden fast täglich neu installiert.

                          Das Problem was ich lösen soll ist zwar lächerlich, aber die Benutzer und auch die IT Abteilung möchten das der Dienst, "DSM Agent" ( Neinstall32 /ai ) sich nur einmal pro Woche anschaltet um den Status zu prüfen, ob es Pakete für den Client gibt oder nicht. Zur Zeit haben wir es so, das sich dieser Dienst jede 8 Stunden startet und halt bei der Windows Anmeldung.
                          Ich hoffe ihr könnt mir folgen

                          Da ich leider der eizige Paketierer und DSM Supervisor bin und dazu ein blutiger Anfäger in DSM, habe ich leider nicht die Lösung dafür.
                          • 10. Re: Staging Einstellungen verändern
                            Frank.Scholer Master
                            Hallo Dimitrij,

                            sorry, aber das ist schon etwas seltsam... du schreibst "die Clients werden fast täglich neu installiert", es soll aber trotzdem nur einmal pro Woche auf dem Server nachgeschaut werden? Das kapier ich nicht ganz...

                            Unabhängig davon: deine Anforderung lässt sich mit DSM Bordmitteln nicht lösen, da sie auch halbwegs sinnfrei ist. Was du natürlich machen kannst, ist die Dienste auf "Manuell" (oder sogar "Deaktiviert") setzen und per Windows Scheduled Task einmal pro Woche (über ein VB- oder PowerShell Script) zu aktivieren / zu starten.

                            Aber lass mich noch eine Anmerkung machen: da du ja "zugibst" ein DSM Anfänger zu sein, würde es - denke ich - viel Sinn machen, wenn du / ihr euch mal kompetente Unterstützung in Form von Consulting ins Haus holt. Dann könnt ihr mit den Kollegen von der Servertruppe, oder wer auch immer das ist, die Anforderungen durchdiskutieren und ggf. anpassen. Erstens zählt der Prophet im eigenen Land ja eh nix (sprich die Kollegen hören nicht auf dich, dafür erfahrungsgemäß deutlich mehr auf Externe) und zweitens kann jemand mit viel Erfahrung und Know-how im Produkt die Dinge vermutlich deutlich besser erklären und kommunizieren, sodass am Ende eine vernünftige Lösung dabei herauskommt... nur meine Meinung ;-)

                            HTH, Grüße Frank
                            • 11. Re: Staging Einstellungen verändern
                              Dimitrij Apprentice
                              Hi Frank,

                              einen Consulter haben wir auch,ohne ihn hätte ich noch weniger Kenntnisse.
                              Er kennt unsere Umgebung und auch die Anforderungen die unsere Abteilung verlangt.
                              Bei den bereits installierten Clients soll dsm agent nur einmal pro Woche ausgeführt werden. Die Clients die neuinstalliert werden oder per hand angestossen werden soll der Agent funktionieren
                              Aber du hast Recht mit einem Consulting wäre das viel praktischer.
                              • 12. Re: Staging Einstellungen verändern
                                _Mel_ Master
                                der agent ist die niagnt32.exe.
                                niinst32.exe ist der installer.
                                und der agent startet regelmäßig den autoinstaller (niinst32 /AI) im userkontext an
                                aber es gibt ein setting, daß der agent sich nach dem installerlauf wieder beenden soll (Autoinstaller/Keep Agent resident) damit in verbindung mit einem per scheduled task gestarteten agent könntest du den autoinstaller wie gewünscht steuern

                                die frage wäre für mich aber mehr, was mit dieser (seltsamen) anforderung erreicht werden soll - einfach nur machen was verlangt wird anstelle von dem was gebraucht wird ist nur dann attraktiv, wenn man es hinterher nicht pflegen muß
                                • 13. Re: Staging Einstellungen verändern
                                  NicoS1 Master
                                  Hallo Dimitrij,

                                  nach reichlicher Überlegung... ich würde mal behaupten, dass es nicht notwendig ist hier eine technische Lösung zu finden mit Wartungsplänen usw. ich hole mal etwas weiter aus... (und jetzt hab ich auch mehr Zeit zu schreiben)...

                                  Bei uns in der Firma ist es z.B. so, dass wir eine reine Security Abteilung haben die ständig nach aktuellen Meldungen zu Schwachstellen etc. sucht, Patches dafür heraussucht und die Schwachstelle bewertet. Bei besonders kritischen Sicherheitslücken machen wir einen Emergency Rollout. Das heißt, paketieren, testen ausrollen, sofort. Bei den anderen Patches haben wir in der Regel die Vorgabe diese binnen 4 Wochen auszurollen.

                                  Wir haben uns hierfür dann auch einen internen Patchday angeschafft, der ein paar Tage nach dem MS Patchday liegt. Das ist nahe genug dran, dass andere Hersteller die sich an den MS Patchday anhängen ihre Updates Releasen, aber weit genug weg von "kritischen" Zeiten wie Monatsabschlüssen.

                                  Wenn jetzt einer meiner Kollegen oder ich, eine Anforderung bearbeiten, einen Patch auszurollen, wird dieser Paketiert, intern getestet und dann an eine "Pilot-Gruppe" ausgerollt. Das sind Benutzer in verschiedensten Abteilungen, die bei eventuell auftretenden Fehlern dann eine Meldung machen. Hierzu wird bei einem Update das Paket hochrevisioniert, und die Policy dann "kritisch" aktualisiert, mit der Option alle PolicyInstanzen zu deaktivieren. Dann steht das Paket auf allen Clients auf "grau". Die Pilotbenutzer werden dann manuell scharf geschalten.

                                  Das hat den Charme, dass das Update bei den Usern nicht los läuft, aber alle Rechner die NEU in die Zuweisung fallen (z.B. Installation eines neuen Computers) erhalten automatisch das aktualisierte Paket.

                                  Ist das erledigt, schiebt der Paketierer das Paket in einen extra Software-Ordner Patchday.

                                  Jetzt kommt besagter Patchday,,, dafür haben wir dann ein Routine-Ticket im Ticketingsystem, dass dann auf geht. Das Ticket nimmt sich dann irgend einer der Paketierer... der nimmt dann alle Pakete im Patchday Ordner liegen, aktiviert alle deaktivierten Policy Instanzen, und schiebt das Paket wieder zurück in seinen Ursprungsordner. Patchday erledigt.

                                  Somit werden die Benutzer nur 1x im Monat genervt, außer bei kritischen Sachen. Wir nehmen uns nicht die Flexiblität jederzeit etwas auszurollen was entweder kritisch ist, oder was den User in seiner Arbeit weder stören noch beeinträchtigen würde, und Neuinstallationen sind ebenfalls sofort aktuell.

                                  Sollte je ein Paket neu zugewiesen werden (also brandneues Paket, kein Update) welches für alle gelten soll, so wird dies an alle Zugewiesen über die "extra Optionen einblenden" (oder so ähnlich) beim Zuweisen, wird dann die Option gewählt die Policy nach der Zuweisung zu deaktivieren, bzw. nicht zu aktivieren... (mir fehlen gerade die genauen Wortlaute in der DSMC).

                                  Nach der Zuweisung, klappen wir diese deaktivierte Policy Instanz auf, wählen alle Computer aus Rechtsklick => Rollout stoppen... danach wird die übergeordnere Policy aktiv geschalten und das Paket in den Patchday Ordner geschoben. Das ist notwendig, damit Rechner die NEU in die Zuweisung fallen (z.B. bei Installation eines neuen Computers) dieser das neue Paket direkt bekommt, aller anderen aber noch nicht.

                                  Man muss nur schauen dass man richtig deaktiviert Ausgegraute Schrift und Balken Gelb = Die übergeordnete Policy Instanz ist deaktiviert. Paket wird nicht ausgerollt, auch nicht auf Clients die neu dazu kommen. Schwarze Schrift und Statusbalken Grau = Übergeordnete Instanz ist aktiv, aber Paket wird nicht auf diesen Rechnern mit Grauem Balken installiert. Rechner die neu hinzu kommen, bekommen das Paket installiert.

                                  Ich weiß das klingt kompliziert wenn man es in Worte bzw. Text fasst, aber hat sich bei uns als sehr gutes Vorgehen etabliert, vor allem wenn mehrere Paketierer und vor allem auch Standort-übergreifend gearbeitet wird.

                                  Im Prinzip ist es nur ein Vorgehen, vereinbart zwischen allen Paketierern und ein paar Klicks mehr bei der Zuweisung... dafür deutlich freundlicher für die User und erleichtert die Aufgabenteilung wenn mehrere Paketierer im System werkeln.

                                  Gruß
                                  • 14. Re: Staging Einstellungen verändern
                                    Dimitrij Apprentice
                                    Danke NicoS für so viel Information.

                                    Mit kritische Patche hatte ich zu tun als wir noch das Patch Management hatten. Zuweisung von kritischen oder unkritischen Sachen hatte ich letztens bei einem wichtigen Rollout.
                                    Mit Pilotbenutzer arbeite ich auch, so kann ich immer wieder so wie ihr einen Feedback bekommen ob die Software auch alles tut was "Layer 8" möchte.
                                    MS Updates bekommen die Clients über WSUS.....

                                    @ Mel

                                    niinst32 /ai den meinte ich auch natürlich.
                                    Mein Problem ist das es an vielen PCs wenn der niinst32 /ai gestartet wird ungefähr 30-40 Sek. vergehen bis sich der Client wieder "beruhigt"
                                    Nur mal so als Beispiel:
                                    User startet früh morgens sein WinXP mit 3 GB RAM und keine SSD , der PC kommt bis zur Anmelde Fenster, der User meldet sich an und jetzt springt der niinst32 /ai an um zu prüfen ob für ihn Pakete gibt. Die Prüfung dauert aber echt manchmal zu lange, und genau das sollte ich beheben.

                                    Und ja du hast Recht die Anforderung ist selten und für mich als DSM Verantwortlicher sehr schwer nachzuvolziehen, weil genau durch sollche Veränderungen werde ich später wahrscheinlich sitzen und nach Lösungen bei anderen Problemen suchen