1 2 Previous Next 18 Replies Latest reply on Feb 9, 2010 3:38 AM by NicoS1

    [SOLVED] Softwaremanagement

    Apprentice
      Hallo Zusammen,

      ich habe mal ein paar Fragen bezüglich des Softwaremanagement.

      1. Ich habe hier im Forum des öfteren schon gelesen, wenn eine Software upgedatet wird z.B.: Adobe 9.2 auf Adobe 9.2.1, wird das über eine Revision gemacht. Das die Daten hoch kopiert werden verstehe ich noch, aber wie sieht das Skript technisch aus? Es gibt genügend Software bei der erst alte Version deinstalliert werden muss um die neue zu installieren zu können, was macht man dann?

      2. Wann verwendet man den Software Sets? Wenn ich mehrer SW-Pakete zusammen fassen möchte?
      Weil wir haben festgestellt, dass man die verschiedenen Versionen einer Software wunderbar in einem Set handhaben kann. Dem Set kann man ja bei einer neuen Revision auch sagen das nur die geänderte Komponente inst. werden soll. Und wenn bei einem neuen Release, die alte gölscht wird kann man ja ganz einfach das alte SW Paket im Set als Komponente entfernen, welches sich dann auch automatisch bei den Usern deinstalliert wenn es nicht mehr im Set vorhanden ist.

      Evtl. kann mir ja jmd von euch etwas Klarheit bei dem Thema verschaffen und wie das von Enteo eigentlich gedacht ist.

      Vielen Dank

      Manuel
        • 1. Re: [SOLVED] Softwaremanagement
          NicoS1 Master
          Wie man mit Softwareupdates umgeht, hängt ehrlich gesagt davon ab, wie man allgemein mit Software umgeht.

          Dein Ansatz bzgl. der Softwaresets ist gut, funktioniert natürlich auch.

          Ich persönlich mach es ähnlich wie schonmal jemand anders (Ich glaub Frank Scholer) geschrieben hatte. Bei Minor Updates innerhalb der Version (9.2 auf 9.2.1) mach ich revisionen. Major updates (9.0 auf 10.0 z.B.) mach ich auch eher neue Pakete.

          Wenn ein Paket eine deinstallation des alten Pakets vorraussetzt, frag ich vorher mit if ab, ob es installiert ist. Falls ja, mach ich vorher den Deinstall.

          Wenn du in der Site Config den preview auf 1 gestellt hast, hast du als if Abfrage auch "MsiProductisInstalled" und kannst dann direkt auf .msi Files abprüfen und dann ggf. per MSIuninstallProduct das ding wegschießen.

          Bezüglich den Softwaresets. Das ist auch so ne Sache, die man entscheiden muss, je nachdem wie man mit Software umgeht. Wir haben bei uns im Active Directory und Enteo unsere Unternehmensstruktur abgebildet. Von dem her gehen wir so vor, das wir Standardsoftware und Standardsoftware (Adobe, Office, Flash usw) für Notebooks (VPN Client, Bestimmte Settings, UMTS Software) in ein Set zusammenfassen, was bei der Installation jedem client zugewiesen ist. Abteilungsspezifische Standardsoftware ist pro Paket auf die einzelnen OUs der Abteilung entweder als Software oder als Shop Policy zugewiesen. Wenn man eine relativ flache Struktur hat, oder die Struktur nach Standorten aufgebaut ist, kann man entweder Software Sets nehmen um Abteilungsspezifische Software zusammenzufassen, oder auch statische Gruppen... eine pro Abteilung und da dann jeweils Software bzw. Shop Policys zuweisen.

          Ich persönlich hab lieber weniger Sets und weise lieber die einzelpakete zu, da mich das mit der Revisionierung etwas nervt, da man beim Softwareset immer mind. 2 Pakete revisionieren muss ;-) und ab und an haben wir Probleme mit dem Rebootverhalten, da wir nicht mit dem Wartungsplan arbeiten.

          Ein anderer Sinnvoller Einsatz für Sets ist z.B. bei Software die aus mehreren Paketen besteht... z.B. hab ich mal Office 2000 verscriptet für welches die Anforderung bestand das es die MUI Version ist, mit Deutsch, Englisch und Französisch.

          1. Komponente: Office 2000 Englisch
          2. Komponente: Office 2000 MUI CD 2 (inkl. Deutsch)
          3. Komponente: Office 2000 MUI CD 3 (Inkl. Französich)
          4. Komponente: Konfigpaket das die Sprache entweder auf Deutsch oder Franz als Defaultsprache einstellt.

          So hab ich 3 Softwaresets, eines für Office 2000 mit Standard Deutsch, eines mit Standard Englisch (4. Komponente weglassen) und eines mit Standard Französisch. Und die Anforderung ist erfüllt, das ein User jederzeit switchen könnte. Da macht ein Set wiederrum sehr viel Sinn ;-)
          • 2. Re: [SOLVED] Softwaremanagement
            Apprentice
            Hi NicoS,

            erstmal danke für die Antwort, im Fall es ist ein MSI Paket mag das mit der Deinstallation ganz gut funktionieren, nur wir ham halt auch nen haufen ander Software die kein MSI hat und genau da frage ich mich wie das mit der Deinstallation ablaufen soll.

            Angenommen du hast:

            - Dateien die im EScript mit InstallFileList installiert werden
            - RunAs Befehl wird ein Setup mit eigener Silent Methode installiert

            Wie läuft dann die Revisionierung ab?

            Mfg
            Manuel

            P.s. Wo in der Site Config steht Preview?
            • 3. Re: [SOLVED] Softwaremanagement
              FrankScholer Master
              Hallo,

              also ich verstehe Software-Sets als "Meta-Pakete", also einen Satz an Paketen, die nur logisch aber nicht technisch miteinander verknüpft werden (wie Nico schreibt, z.B. Standard-Software, die aber jeweils auch Stand-Alone wunderbar funktionieren würde).

              Für technische Abhängigkeiten aktiviere ich stets das "alte" Komponenten-Modell und bilde diese darüber ab.

              Die "Preview"-Befehle kannst du aktivieren, indem du einen neue benutzerdefinierte Variable namens "Preview" anlegst und dieser den Wert 1 gibst. Neustart der eMMC ist dann erforderlich.

              Deinstallation:
              1. eScript mit InstallFileList-Befehlen: die dreht Enteo automatisch um bei der Deinstallation, genauso wie CreateLink und viele andere. Nicht-umkehrbare Befehle wie MsgBox, RunsAs etc. werden dabei übersprungen

              2. RunAs (und andere nicht-umkehrbare Befehle): dann musst du mit einem Abschnitt "$BeginUninstallScript" arbeiten. Trifft die Scriptengine bei der Deinstallation auf dieses Label, wird wieder in den "normalen" Ausführungsmodus geschaltet und Befehle werden nicht mehr umgekehrt. Damit machst du dann eben eine Deinstallation über RunAs, Delete o.ä.

              HTH, Gruß Frank
              • 4. Re: [SOLVED] Softwaremanagement
                Apprentice
                Hallo Frank,

                ich weiß das eScript wie InstallFileList umgedreht werden, und ich kenn auch den Abschnitt "$BeginUninstallScript", allerdings ist dies nicht die Antwort auf meine Frage.

                Wenn ich eine neue Revision eines EScript Pakets erzeuge, stehen immer noch die selben Befehle wie im alten drin.

                Wenn ich jetzt mein neues SW minor Release, in das neu revisionierte Script einbauen muss und neue Befehle verwende, wird dann nach der Paket aktualisierung, das alte Paket automatisch gelöscht?


                Mfg
                Manuel
                • 5. Re: [SOLVED] Softwaremanagement
                  NicoS1 Master
                  Also grundsätzlich sollte man seine Pakete so bauen, das eine Deinstallation unterstützt wird. Bei InstallFile(List) ist das weniger ein Problem, bei Dateien die per setup.exe aufgerufen werden musst du natürlich mit $BeginUninstallScript und noch einen Unattended uninstall dazu bauen.

                  Ich muss ehrlich gestehen, das ich vor dem Problem noch nicht so intensiv stand, aber nach ein bisschen grübeln würde ich das so machen:
                  (Vorraussetzung, das du einen Funktionierenden Uninstall für dein Paket gebaut hast)

                  1. If Abfrage mit IsSwPackageRevInstalled
                  2. => Falls ja : UndoInstall: Und deine alte Revision auswählen.
                  3. Installation normal weiter fortsetzen.

                  Das ganze müsste man noch testen. Ich hab hier nämlich 2 Bedenken dabei:
                  1. Funktioniert IsSwPackageRevInstalled und UndoInstall auf eine alte Revision während sie gerade aus der neuen Revision aufgerufen werden?
                  2. Berücksichtigt "UndoInstall" den $BeginUninstallScript ?

                  --------------------
                  Wenn du ein Handzahmes Paket hast, das einen recht einfachen Installer verwendet (und in jeder Version den gleichen), dann mach ich einfach eine if xist abfrage auf die Uninstaller Datei falls möglich und für die aus.

                  Ein Beispiel ist Firefox. Der hat in jeder Version seine "Helper.exe" Datei dabei, hinter der sich der Uninstaller verbirgt. Da wir vermehrt Probleme beim Update haben hab ich in jeder Revision beim Install von Firefox einfach einen if exist und runas auf die helper.exe /S (nach einer Abfrage ob der Prozess läuft ).

                  Komplizierter wird es halt je nach Software. Man muß auch nicht zwingend die Revisionierung benutzen. Enteo bietet ja eigentlich für alles ca. 1000 verschiedene Möglichkeiten an es zu lösen. In manchen fällen reicht eine Revision, in manchen Fällen ist ein neues Paket einfach praktischer. Pauschalisieren lässt sich das leider nicht, das hängt einfach mit dem Softwarehandling zusammen, und vor allem wie die Software die man verscriptet hat funktioniert.
                  • 6. Re: [SOLVED] Softwaremanagement
                    Klaus Salger Expert
                    Hallo Manuel,

                    das sind 2 sehr interessante Themen.

                    zu 1.
                    Meines Erachtens sollte im Regelfall revisioniert werden wenn das Update der Software durch erneute Installation, also OHNE Deinstallation abläuft. Wenn eine Deinstallation der alten Version notwendig oder erwünscht ist, sollte meines Erachtens auch ein neues Paket erstellt werden.
                    Während die neue Revision durch ein kritisches Update einfach über die bestehenden Installationen installiert wird, werden die neuen Pakete durch Entfernen der alten Policy und Hinzufügen einer njeuen Policy ausgerollt. Das führt dann auch zunächst zur Deinstallation des alten Pakets und anschließend zur Installation des neuen Pakets. Mit SWSets funktionert's analog.
                    Das halte ich so für einfach und straight forward.
                    Ob man auch Major Releases über eine neue Revision ausrollen möchte, wenn keine vorherige Deinstallation nötig ist, ist Geschmacksache.

                    zu 2.
                    Software Sets haben den Vorteil, dass man mehrere Pakete transparent zusammen fassen kann, d.h. die einzelnen Status innerhalb des Sets sind in der Konsole erkennbar. Außerdem kann die Installationsreihenfolge, in der zu installieren ist, einfach und sicher festgelegt werden.
                    Mir gefällt auch, dass die Logik gut passt - die Zusammenfassung von Paketen hat erst mal nichts mit der Zuweisung zu tun.
                    Schließlich gibt es Szenarien, die über Software Sets besser handhabbar sind als mit Einzelzuweisungen. Z.B. das Entfernen einer Policy führt sofort zur Deinstallation auf allen betroffenen Clients. Das Entfernen einer Komponente aus einem Software Set lässt dem Admin die Freiheit auch ein unkritisches Update zu machen, d.h. nur die Neuinstallation der Komponente abzustellen, die bereits installierte Software aber zu belassen.
                    Nachteile:
                    Es gibt nur eine einzige Ebene - Software Set mit Komponenten. Ein Software Set kann leider keine weiteren Software Sets enthalten.
                    Bei Änderungen muss gegenüber der Einzelzuweisung ein Paket mehr revisioniert werden - das SWSet ist zusätzlich immer zu ändern.
                    Am kritischsten finde ich aber, dass die Situation bei Überlappungen problematisch ist. Z.B. Installation von Software Sets mit einer gemeinsamen Komponente, also eine Paket, das in beiden Sets vorhanden ist. Wird beim 2. SWSet nochmal installiert? Was ist wenn die Installationsparameter unterschiedlich sind? Was passiert bei der Deinstallation.
                    Mit dem aktuellen Servicepack hat sich an der Stelle etwas getan - hab ich noch nicht getestet.
                    Ich würde bei Software Sets auf jeden Fall Überlappungen weiterhin vermeiden.

                    Ciao
                      Klaus
                    • 7. Re: [SOLVED] Softwaremanagement
                      LjokajK Expert
                      Für die Deinstallation der alten Pakete, die KEIN MSI enthalten mach ich das bei einigen Kunden so:

                      - Im neuen eScript eine IF-Abfrage. Jede installierte Software registriert sich in der Registry unter: HKLM\SW\Microsoft\Windows\CurrentVersion\Uninstall

                      Dort steht die ganze Software drin, die du auch unter Systemsteuerung\Software siehst. Wenn du jetzt mal einen Schlüssel anklickst, siehst du rechts die Zeichenfolge "UninstallString".

                      Das heisst, du machst eine IF-Abfrage RegKeyExists auf den Schlüssel der zu deinstallierten Software, dann in der Bedingung einen Execute oder RunAs-Befehl mit dem Wert des UninstallStrings in der Registry. Darunter packst du dann deine Installation der neuen Version.
                      • 8. Re: [SOLVED] Softwaremanagement
                        Klaus Salger Expert
                        Hallo Kurt, hi all,

                        ich glaube, dass es die ganze Paketierung und Zuweisung vereinfacht, wenn ich mich in einem Paket nur um Installation und Deinstallation dieses einen Pakets in dieser einen Revision kümmern muss. Das ist gelegentlich ja schon schwierig genug.

                        Das alte Paket kann einfach deinstalliert werden indem man die Policy entfernt oder die Komponente aus dem Software Set entfernt. Dann brauchen die Pakete nicht zu prüfen, ob vorher etwas anderes deinstalliert werden muss. An der Stelle macht es die Sache doch nicht einfacher, wenn ich mit Revisionen arbeite, oder?
                        Was ist so unangenehm an einem neuen Paket?

                        Ciao
                          Klaus
                        • 9. Re: [SOLVED] Softwaremanagement
                          Apprentice
                          Hallo,

                          erstmal danke für das Interesse an meinen Problem Thema.

                          @ Klaus: Wir hier arbeiten mit einem Standard Software im SSet und jede andere Software geht dann über den Software Shop. Wenn ich jetzt anfange dauernd irgendwelche Policys mit der Hand zu löschen, wenn ich eine neues Software Release einbinden will, brauche ich Enteo nicht mehr.

                          Es muss doch möglich sein eine Software sei es mit Revisionen oder SSet's dazu zu bringen das man:

                          1 Policy für 1 Software hat, in der die neuen Releases eingebaut werden können.

                          @Nicos: Ich hab das mal getest was du gesagt hast, hab nen simples EScript (Rev.1) erstellt:

                          CreateLink
                          Copy

                          danach eine neue (Rev.2):

                          If IsSWPackageRevInstalled (Paket Rev.1)
                            UndoInstall (Paket Rev.1)

                          CreateLink (andere Verknüpfung)
                          Copy ( neue Dateien)

                          Allerdings hat beim UndoInstall nur das rückwärtslaufende Copy funktioniert, habe keine neue Verknüpfung oder neue Dateien kopiert bekommen.

                          Wie ist den das eigentlich, bei uns ist das problem das einige Rechner auch nicht immer das sind wenn ich jetzt mehr als einaml in diesem Zeitraum eine Rev. anlege müsste ich ja für jede Rev so eine if IsSWPackageRevInstalled Routine hinterlegen bis ich ein Major Release bekomme oder?

                          Mfg
                          Manuel
                          • 10. Re: [SOLVED] Softwaremanagement
                            Klaus Salger Expert
                            Hallo Manuel,

                            wenn Du ein großes Software Set hast, über das Dein Standard Client abgebildet ist, dann hast Du für das Handling von Updates aus meiner Sicht 2 Varianten:

                            1. Revisionsupdate
                            Du erstellst eine neue Revision des Pakets, passt es entsprechend an usw., dann eine neue Revision Deines Software Sets und aktualisierst das dort eingebundene Paket auf die neue Revision. Dann aktualisierst Du die Policy, über die das SWSet zugewiesen ist.

                            2. Neues Paket
                            Du erstellst statt der Revision ein neues Paket, dann erstellst Du eine neue Revision Deines Software Sets, schmeisst das alte Paket raus und fügst das neue Paket hinzu. Dann aktualisierst Du die Policy, über die das SWSet zugewiesen ist.

                            Wo ist bei 2. der Mehraufwand?
                            Wenn ich die alte Version deinstallieren muss bevor ich die neue installiere, spare ich mir bei 2. das Handling der Deinstallation der Vorversion in jedem Paket - das macht der enteo Client automatisch.
                            Ist doch viel einfacher, oder?

                            Die Policy würde man nur bei einer direkten Zuweisung entfernen, mit einem Software Set entfernt man halt die Komponente und aktualisiert die Policy.

                            Ciao
                              Klaus
                            • 11. Re: [SOLVED] Softwaremanagement
                              Apprentice
                              Hi Klaus,

                              also wenn ich das bei meinem Standard SSet mache ist mir das bewusst, aber was mache ich den mit den ca. 30 anderen Pakete die in meinem Shop in keinem SSet vorhenden sind?

                              Ich kann da ja nicht jedem User ne Mail schreiben es gibt nen neues Release bitte installieren. Sondern ich möchte die ganze Software die geshoppt wurde, wenn es ein minor Release ist automatisch updaten, ist es ein Major Release will ich es im Shop neu zu Verfügung stellen.

                              Bei den Minor Release soll die alte Sw Rev. 1 (deinst.) dann das neue Release Sw Rev2. installieren ohne das der User was machen muss.

                              Ist es ein Major Release soll es im Shop auftauchen. Wenn es geshoppt wird, soll das alte Paket (egal welche Rev. es ist) deinst. werden und das neue installiert werden.

                              Das kann doch gar nicht so schwer sein. Es muss doch irgendwo ein Konzept verfolgt werden von Enteo oder?

                              Mfg
                              Manuel
                              • 12. Re: [SOLVED] Softwaremanagement
                                Klaus Salger Expert
                                Hi Manuel,

                                aha, ich bin jetzt schon mal einen Schritt weiter - ich hab verstanden, was Dein Problem ist
                                Das hilft Dir allerdings nicht unmittelbar, ich kann nämlich zumindest ad hoc keine gute Lösung liefern.

                                Dass bei dem Szenario - automatischer Rollout von vorher interaktiv installierten Paketen - die Revisionierung viel einfacher funktioniert als die Zuweisung eines neuen Pakets ist so weit klar. Die Deinstallation der Software vor der Reinstallation ist sicher möglich, die Kollegen haben dazu ja schon einiges gesagt, schmerzhaft ist es aus meiner Sicht allemal.

                                Eine saubere Lösung wäre, z.B. bei der Aktualisierung der Policy abzufragen, ob bei einem kritischen Update die alte Revision vorher deinstalliert werden soll.
                                Dazu müsste FrontRange das Produkt anpassen - vielleicht kann jemand von FrontRange dazu was sagen?
                                Ich bilde mir ein, sowas in der Art wäre in einer früheren Version (6.0? 6.1?) schon mal gegangen.
                                Rollout stoppen, Parameter ändern, Rollout starten. In der Abfrage konnte man wählen ob nochmal installiert werden soll oder ob deinstalliert + installiert werden soll. Kann das jemand bestätigen?

                                Ciao
                                  Klaus
                                • 13. Re: [SOLVED] Softwaremanagement
                                  ChristophSteckelberg Expert
                                  Hallo Manuel

                                  um noch mal Dein Ursprungspost zu beantworten:

                                  1. Revisionen mache ich nur um kleine Änderungen am Skript zu machen. Ein Versionsupdate der zu installierenden Software ist bei mir in jedem Fall ein eigenes Paket. Warum ? Weil Clientseitig immer alle Revisionen heruntergestaged werden. Mal angenommen Du hast dein Ursprungspaket mit 15 MB und dadrauf 10 Revisionen á 5 MB geänderter Daten um ein Paket auf die aktuelle Version zu bringen, die alleine auch 15 MB hat.
                                  Wenn Du revisioniert hast, dann bist Du bei 65MB die gestaged werden müssen und den Repository Cache verstopfen, wenn Du ein neues Paket gebaut hättest dann wärst Du bei 15.

                                  2. SoftwareSet: Für Standard Policies niemals. Warum ? Weil technisch die Möglichkeit besteht durch Installationsreihenfolgen ID Abhängigkeiten vorzugeben. Weil eine ganze Zeit lang SoftwareSets nicht sauber funktionier(t)en und ich dem ganzen immer noch nicht traue. Weil das Handling von Revisionen komplex wird. Weil die Gefahr besteht das gleiche Package in unterschiedlichen Revisionen in mehreren Softwaresets ein und demselben Client zuzuweisen.  Weil dadurch das Layer Modell außer Kraft gesetzt wird.
                                  Für Shop-Policies: Immer. Aus den von Dir genannten Gründen: Austausch von Paketen / Hinzufügen von Komponenten, ohne dass ein User manuell "nachshoppen" muss
                                  • 14. Re: [SOLVED] Softwaremanagement
                                    NicoS1 Master


                                    1. Revisionen mache ich nur um kleine Änderungen am Skript zu machen. Ein Versionsupdate der zu installierenden Software ist bei mir in jedem Fall ein eigenes Paket. Warum ? Weil Clientseitig immer alle Revisionen heruntergestaged werden. Mal angenommen Du hast dein Ursprungspaket mit 15 MB und dadrauf 10 Revisionen á 5 MB geänderter Daten um ein Paket auf die aktuelle Version zu bringen, die alleine auch 15 MB hat.
                                    Wenn Du revisioniert hast, dann bist Du bei 65MB die gestaged werden müssen und den Repository Cache verstopfen, wenn Du ein neues Paket gebaut hättest dann wärst Du bei 15.



                                    Bist du dir da sicher?
                                    Ich hab gelernt, das Enteo bei ClientSync sich die Revision automatisch zusammenbaut. Sprich, im Work Dir liegt alles drin was für die aktuelle Revision gebraucht wird, und beim "Distribution vorbereiten" verpackt er nur die geänderten Sachen im Vergleich zu Rev 1. Und beim Staging auf den Client läd er nur das aus den einzelnen Revisionsordnern raus, um das zu rekonstruieren was im Work Dir zu dem Zeitpunkt drin lag als du auf "Distribution vorbereiten" geklickt hast.

                                    Ich habs gerade mal auf meinem Client nachvollzogen. Bei Mozilla Firefox sind wir mittlerweile bei der 7. Revision. Jedes mal haben wir die Setup Datei aus dem Work Verzeichnis gelöscht, die neue rein kopiert, die Script datei angepasst, und dann die Software Policys aktualsiert. Mein Client hat alle Revisionssprünge mitgemacht, und in meinem Repositorycache liegt NUR die aktuelle Revision 7, mit der Setup-Datei die zur Revision gehört.

                                    Das einzigste wo ich mir das evtl. Vorstellen könnte, wäre, wenn du mit komprimierten Sites Arbeitest, wo alles nur gezippt vor liegt... obwohl ich mir da nicht sicher bin, ob er da nicht schon aufm Server jeweils die komplette Revision in ein ZipFile packt, oder ob er nur die Deltas zwischen den Revisionen verzippt.
                                    1 2 Previous Next