1 2 Previous Next 19 Replies Latest reply on Sep 6, 2010 7:44 AM by Nico-B

    Wie skriptet ihr ?

    andy232 Specialist
      Hallo,

      ich wollte mal fragen, wie andere so ihre eScripts und packages bauen ?
      Die eigentliche Installation ist ja meist individuell, aber das "drum herum" ist meist gleich.
      Bei mir hat sich folgendes Schema eingespielt, aber ich würde mal wissen, ob andere das auch so machen:

      Das eScript hat bei mir folgendes Schema:

      - Prüfen, ob Paket schon installiert ist
      - Paket installieren
      - Prüfen, ob Paket installiert wurde.

      Konkret als eScript:


      ' ist schon installiert ?
      If FileVersion ('filename.exe') = 1.2.3.4
        ExitProc(Done)

      Execute ('setup.exe')

      ' hat geklappt ?
      If FileVersion ('filename.exe') <> 1.2.3.4
        ExitProc(Failed)

      Außerdem flagge ich immer alle Befehle als "per Service auszuführender Befehl (computerbezogen)", da die Leute keine Adminrechte haben und der Netinstaller per Logonscript gestartet wird.

      In der Packagingworkbench stelle ich zu dem ein:

      Computervoraussetungen festlegen (Client):
      FileVersion ('filename.exe') <= 1.2.3.4

      IsInstalled-Bedingung
      FileVersion ('filename.exe') = 1.2.3.4

      Gruß, Andy.
        • 1. Re: Wie skriptet ihr ?
          andy232 Specialist
          Hmm noch keine Antwort ?
          Wahrscheinlich nehmen die meisten eh nur MSI-Pakete ?

          Gruß, Andy.
          • 2. Re: Wie skriptet ihr ?
            Markus.Zierer Expert
            Hallo,

            Also ich für meinen Teil versuche soviel wie möglich per Snapshot zu machen. Das verursacht in der Regel am wenigsten Probleme. Allerdings muss man da schon Fit sein, was Paketierung mit NetInstall betrifft. Wenn ich per Snapshot nicht erfolgreich Bin, oder die SW einfach zu groß ist, nutze ich die MSI Files vom Hersteller. Das liegt einfach daran, weil MSI ein paar hässliche Eigenschaften hat, die einem schonmal gehörig die Suppe versalzen können (AppRepair z.B.). Und Setup.exe aufrufe versuche ich zu vermeiden wo es nur geht. Damit ist ein vernünftiges SW Management eigentlich überhaupt nicht zu machen. Glücklicherweise sind die meisten Setups nichts weiter als ne Hülle um ein MSI Paket. Und wenn man weis wie man an das rankommt, kann man in der Regel das ganze als MSI Inst abfrühstücken.

            Eine Paketierungsphilosophie in nen Thread zu packen halte ich für nicht möglich. Dafür ist das Thema zu umfangreich.
            • 3. Re: Wie skriptet ihr ?
              andy232 Specialist
              Ah klingt interessant.....
              Bei mir ist es genau umgekehrt. Ich versuche nur dann Snapshots zu machen, wenn MSI oder escript nicht geht.

              Grund: In manchen Umgebungen sind leider nicht alle PC's durch ein Image auf dem selben Stand. Und ich hab dann bedenken, daß die Setup-Routine eine eingebaute Intelligenz hat und nur die für den Rechner benötigten Komponenten installiert, die dann bei einem anderen PC fehlen würden. Beispielsweise könnte ja das Setup entdecken, daß für die Software die C++ Redist Runtime schon installiert ist und daher diese nicht installieren. Dann würde diese auch im Snapshot nicht auftauchen und bei einem anderen PC fehlen.....

              Daher ist meine Priorität immer:
              MSI nehmen, da recht unkompliziert.
              Oder mittels escript die Setup-EXE aufrufen, sofern die Installation ohne Benutzerinteraktion durchläuft
              Oder mittels Snapshot.

              Du hast Recht, das Thema ist für einen Thread wohl zu komplex......

              Gruß, Andy
              • 4. Re: Wie skriptet ihr ?
                info@offlimits-it.com Expert
                Also wir machen das auch in der Reihenfolge

                1. MSI
                2. Setup Routine des Herstellers Silent
                3. Snapshot
                • 5. Re: Wie skriptet ihr ?
                  Markus.Zierer Expert
                  @andy232

                  Also ich weis nicht warum Du der Annahme bist, dass nur durch "ein Image" die Clients alle einen Stand haben können, aber davon abgesehen trifft das den Nagel schon auf den Kopf. Die Aufgabe des Client Managements ist es, Sicher zu stellen DASS jeder Client gleich ist. Das geht aber nur dann, wenn man ein Vernünftiges Konzept hat, nach dem man arbeiten kann.

                  Und zum Thema MSI bzw. Herstellersetup kann ich nur sagen, wenn Du wüsstest, was manche Hersteller so alles als sog. CustomAction in ein MSI Setup reinbauen, dann würdest Du vermutlich auch irgendwann zu der Erkenntnis gelangen, dass diese Methode nicht immer die erste Wahl ist. Die 100%ige Kontrolle über das, was auf dem Client passiert hast Du nur mit einem Snapshot. Allerdings ist es leider auch so, dass die meisten Scripter die ich kenne diese Methode nicht nutzen weil Sie denken, sich dadurch Zeit und Aufwand zu sparen. Da stimmt aber leider nicht....

                  Ich habe jedenfalls noch keine Umgebung gesehen, die ausschliesslich mit MSI und Herstellersetups aufgebaut war und die länger als 2 Jahre problemlos funktioniert hat. Am Anfang läuft das noch sauber, aber mit zunehmender Lebensdauer treten immer mehr Fehler auf, die sich keiner so richtig erklären kann. Solange bis gar nix mehr geht.

                  Tipp: Nimm mal ein MSI Paket und mach mal nen Validate von dem Paket. ich habe noch kein einziges Paket gesehen, welches zu 100% dem MSI Standard entsprochen hat (ganz besonders nicht von MS selbst).
                  • 6. Re: Wie skriptet ihr ?
                    FrankScholer Master
                    Hallo Andy,

                    ich bin eher pragmatisch - so wie's am einfachsten geht, wird gescripted.

                    Bei MSIs erzähl ich Leuten in Schulungen im gern den Merksatz "MSI - Hände weg vom Spy" was prinzipiell daran liegt, dass man - wenn man ein MSI spyed - noch etliche Sachen aus der Registry rausschmeißen muss, damit's auf lange Sicht auch keine Probleme gibt (damit Windows Installer und NI nicht "konkurrieren"). Daher nehm ich dort typischerweise den MSIInstallProduct-Befehl oder - wenn das aus irgendeinem Grund Probleme gibt - den ExecuteEx (per Service geflaggt) auf MSIEXEC.EXE.

                    Transforms erstelle ich, wann immer möglich, mit einem Transform-Editor des Software-Herstellers, weil der darin ggfs. auf irgendwelche proprietären Erweiterungen eingehen kann, was natürlich ein generischer Editor, wie der von NI, nicht kann.

                    Silent Setups nehm ich am ehesten bei sehr systemnahen Paketen (Virenscanner z.B.), weil dort z.T. so tiefgreifende Änderungen gemacht werden, dass der Spy die garnicht mitkriegt. Änderungen in Dateisystemberechtigungen sind da ein Beispiel. Aber auch, wenn's z.B. im Readme oder bei www.appdeploy.coom bereits ne fertige Kommandozeile gibt, die man einfach einsetzen kann.

                    Ich würde die Installationsprüfung (die du ja in deinem Beispiel per FileExist prüfst) eher per Returncode des aufgerufenen Setups machen (Returncode des per ExecuteEx aufgerufenen Executables = 0 -> Erfolg, <> 0 Fehler).

                    Die Zurückhaltung beim Spy, die ich bei fast allen Kunden in den letzten Jahren erlebe, halte ich allerdings auch für "ein reines Bauchgefühl" ohne dass das begründet würde. Für "normale" Legacy-Setups (Setup.exe ohne dass da ein MSI aufgerufen würde) ist der Spy m.E. oftmals immernoch die schnellste, einfachste und ggfs. sauberste Methode. Wenn natürlich dynamische Keys oder Verzeichnisse erzeugt werden (z.B. die Cache-Einstellungen bei Firefox), ist der Spy nicht optimal...

                    Wichtig auf jeden Fall - und das kam hier noch garnicht zur Sprache: beim Paketieren für v6 unbedingt das Thema "Deinstallation" des Pakets bereits beim Paketieren betrachten. Sonst gibt es über kurz oder lang Probleme mit der Compliance (Paket wird in der eMMC als grün und installiert angezeigt, wurde aber ggfs. von einem anderen Paket deinstalliert oder von einer Nachfolge-Version der Software oder so).

                    Was sicher auch richtig ist, ist - wie Markus schreibt - dass SETUP.EXEs der Hersteller in aller Regel maßlos überschätzt werden (die kochen auch nur mit Wasser) und ich war schon manches mal regelrecht entsetzt, wie wenig Ahnung solche Hersteller (bzw. der Ersteller der Setup-Routine) von Windows Installer oder sogar Windows selbst haben. Die Einstellung "ich lass das Setup laufen, das wird schon am besten wissen, was es tut und was es braucht" gehört meiner Erfahrung nach genauso in das Reich der Fabel wie die umgekehrte Einstellungen, dass der Spy nicht richtig funktionieren würde und man daher lieber die Finger davon ließe.

                    Ansonsten sind aussagekräftige Kommentare m.E. ein wichtiger Aspekt eines Scripts (und ein Standard-Header, wo drin steht, wer das Script wann gemacht/geändert hat, ne kleine History, der Sinn und Zweck etc.) und werden m.E. auch vernachlässigt.

                    Dann mach ich die Sachen möglichst modular (d.h. Voraussetzungen wie irgendwelche Runtimes werden separat paketiert) und nicht in ein "All-in-One-Paket" verschnürt und bilde die Abhängigkeiten dann über's (alte) Komponentenmodell ab.

                    Außerdem: je größer die Umgebung, desto eher wird alles passieren, was theoretisch passieren kann. Daher niemals von irgendwelchen Annahmen ausgehen, sondern grundsätzlich explizit prüfen, ob die Annahme auch stimmt, bevor irgendwelche Aktionen ausgeführt werden, die ansonsten fehlschlagen würden.

                    So, das soll mal reichen für heute - zu sagen gibt's sicher noch jede Menge, aber diese Sachen sind mir mal spontan eingefallen.

                    Grüße und angenehme Arbeitswoche
                    Frank
                    • 7. Re: Wie skriptet ihr ?
                      Ratzratz Expert
                      Hallo Markus,

                      ich lese gerade mit äußerstem Erstaunen, daß Du viel mit Snapshots arbeitest. Ich denke, damit meinst Du das Aufzeichnen von Software per "Ist-Zustand aufzeichnen"->Software installieren->"Installation aufzeichnen".
                      Wie andere bereits geschrieben haben, kann ich nur empfehlen möglichst nicht mit dieser Art von Aufzeichnung zu arbeiten. Da zerschießt man sich nur die PCs.

                      Unsere Reihenfolge ist die:
                      1.) Das vom Hersteller empfohlene Verfahren (z.B. Custom Installation Wizard beim Acrobat Reader etc.)
                      2.) Falls vorhanden, silent-Parameter der setup.exe (z.B. /s, /quiet, --mode unattended etc.).
                      3.) Falls vorhanden, per MSI und dann, falls unterstützt, zuerst per "msiexec /a" einen administrativen Installationspunkt machen, bevor man das MSI-Paket ins enteo importiert.
                      4.) Wenn alle Stricke reißen (häufig bei Uralt-Software, z.B. VB6-Programmen) per AutoIt die manuelle Installation automatisieren, das AutoIt-Skript mit RunAs benutzerbezogen ausführen und "Konto des enteo Runtime Service verwenden" einstellen wegen der nötigen Admin-Rechte beim Installieren.
                      5.) Jetzt bleibt tatsächlich nur noch Aufzeichnen (dürfte wegen 4. aber so gut wie nie vorkommen). Dann aber das Paket gründlich putzen und genau abklären, welche Zusatzsoftware im Hintergrund installiert wird (oder halt auch nicht weil schon drauf->siehe VC++, Java etc.), d.h. alles raus, was nicht zur Software gehört (Dateiänderungen, Registrierungsänderungen), da die Zielrechner sonst Probleme kriegen können. Das Problem ist, daß es schwierig ist, das eine vom anderen zu unterscheiden.
                      Berechtigungsänderungen werden übrigens überhaupt nicht aufgezeichnet!
                      Es sind übrigens gerade die aufgezeichneten Pakete, die bei zunehmender Lebensdauer immer mehr Fehler verursachen, die sich keiner so richtig erklären kann.

                      Gruß
                      M. Metzger
                      • 8. Re: Wie skriptet ihr ?
                        FrankScholer Master
                        Hallo M.,

                        Wie andere bereits geschrieben haben, kann ich nur empfehlen möglichst  nicht mit dieser Art von Aufzeichnung zu arbeiten. Da zerschießt man  sich nur die PCs.


                        Da ist die Art von Aussage, die ich oben meinte mit "Reich der Fabel"... also ich habe noch keinen einzigen PC gesehen, der mit einem Spy-Paket zerschossen worden wäre (es sei denn, jemand hat ein MSI aufgezeichnet und wusste nicht, was er/sie tut). Kannst du das mal an irgendeinem Beispiel belegen oder zumindest erklären, warum das deiner Meinung nach der Fall wäre?

                        Dann aber das Paket gründlich putzen und genau abklären, welche  Zusatzsoftware im Hintergrund installiert wird (oder halt auch nicht  weil schon drauf->siehe VC++, Java etc.), d.h. alles raus, was nicht  zur Software gehört (Dateiänderungen, Registrierungsänderungen), da die  Zielrechner sonst Probleme kriegen können.


                        Das ist klar - Paketieren ist halt auch ne eigene Disziplin und das muss man können bzw. üben.

                        Das Problem ist, daß es  schwierig ist, das eine vom anderen zu unterscheiden.


                        Würde ich bestreiten. Mit Übung, Erfahrung und Hintergrundwissen über das Betriebssystem und die zu paketierende Software lässt sich das m.E. problemlos unterscheiden...

                        Wenn alle Stricke reißen (häufig bei Uralt-Software, z.B.  VB6-Programmen) per AutoIt die manuelle Installation automatisieren...


                        Das ist bei mir wiederum der "last exit", sprich wenn alle Stricke reißen. Wo oben geschrieben: je größer die Umgebung, desto eher wird alles passieren, was passieren kann. Und ich kann mir beim besten Willen nicht vorstellen, dass man in einem Script alle Dialoge, die ja ggfs. auch vom Betriebssystem kommen, vorhersehen und dann entsprechend drauf reagieren kann. Ich habe bisher in 12 Jahre NetInstall ca. 3-4 Pakete so gemacht, wo's eben garnicht anders ging.

                        Noch'n Nachtrag übrigens zum ersten Post von Andy: ich würde in v6 Umgebungen empfehlen die Prüfung, ob eine Software bereits installiert ist, nicht im Script selbst, sondern in die IsInstalled-Bedingung zu packen. Hat den Vorteil, dass nicht das komplette Paket (inkl. aller Massendaten) gestaged werden muss, nur um festzustellen, dass es nix zu tun gibt. Außerdem hat die Methode im Script den Nachteil, dass praktisch nie ein Repair funktionert (außer wenn ausgerechnet die Datei nicht mehr da sein sollte), was bei der IsInstalled-Condition nicht der Fall ist.

                        HTH, Grüße Frank
                        • 9. Re: Wie skriptet ihr ?
                          FrankScholer Master
                          Und noch ein Satz zur Spy-Technologie: die Applikations-Virtualisierung ist ja heute in aller Munde und wird als das Beste seit der Erfindung von geschnitten Brot angesehen. Dort kommt (egal welchen Hersteller man da jetzt nimmt) immer die Spy-Technologie eingesetzt. Kann sooo verehrt also nicht sein (nur dass NetInstall ca. 10 Jahre mehr Erfahrung da drin hat und schon vor Jahren der Spy für den Repackager von InstallShield als OEM-Technologie eingekauft wurde ;-)

                          Auch ganz interessant: wenn ihr euch mal den Sequencing Guide von Microsoft anschaut (http://download.microsoft.com/download/F/7/8/F784A197-73BE-48FF-83DA-4102C05A6D44/App-46_Sequencing_Guide_Final.docx) - das was dort im Kapitel 2 beschrieben wird, gilt (von den App-V spezifischen Sachen mal abgesehen) auch 1:1 für Paketieren mit dem NetInstall-Spy.

                          HTH, Grüße Frank
                          • 10. Re: Wie skriptet ihr ?
                            Ratzratz Expert
                            Hallo Frank,

                            zu den zerschossenen PCs:
                            Zu alten NI 5.7-Zeiten war auch bei uns das Aufzeichnen eigentlich das Standardverfahren beim Erstellen eines Pakets.
                            Ich kann nur sagen, daß wir sehr oft seltsame Probleme mit abgestürzten Windows-Komponenten hatten (insbesondere die explorer.exe).
                            Seit wir das mit der Einführung von v6.1 gleich mit abgestellt haben, kommen solche Probleme eigentlich nicht mehr vor.
                            An der neuen enteo-Version (von 5.7 nach 6.1) kann das wiederum nicht liegen, da der Spy bei v6.1 und höher meines Wissens noch genauso funktioniert wie früher.

                            Zu Paketieren ist eigene Disziplin:
                            Leider kann man auch mit noch so viel Erfahrung nicht immer sagen, ob eine Änderung von der Software kam oder vom normalen laufenden Betrieb des Betriebssystems (insbesondere die vielen Änderungen unter HKCR\CLSID).
                            Die offensichtlichen Sachen, wie Änderungen unter "C:\WINDOWS\SoftwareDistribution", "C:\WINDOWS\WBEM" etc., sind nicht das Problem.
                            Deshalb kam von den Kollegen bei aufgezeichneten Paketen immer die Aussage "Bitte bloß nichts putzen sonst tuts am Ende wieder nicht richtig!".

                            Was das AutoIt angeht, kann ich bei meinen bisherigen Erfahrungen nur sagen, daß das bestens funktioniert.
                            Vom Betriebssystem kommt normalerweise nichts unvorhergesehenes, außer solche Geschichten wie "Treiber nicht zertifiziert" oder "Voraussetzungen nicht erfüllt". Ersteres kann man mit AutoIt abdecken und letzteres kann man mit Computervoraussetzungen erschlagen.

                            Was die Applikations-Virtualisierung angeht scheint es tatsächlich so zu sein, daß hier die Spy-Technologie zum Prinzip erhoben wird.
                            Ich habe das "App-46_Sequencing_Guide_Final.docx" mal etwas überflogen. Dabei ist mir aufgefallen, daß das eine Wissenschaft für sich ist. Es ist aber klar zu erkennen, daß mindestens die Hälfte dieses Artikels damit beschäftigt ist, die Risiken und Nebenwirkungen einer Aufzeichnung von vornherein zu minimieren.
                            Ich glaube also nicht, daß diese Spy-Technologie an sich so toll ist (Qualität, Lauffähigkeit, Störungsfreiheit etc. der fertigen virtuellen Applikation).
                            Das schöne ist halt, daß man sehr schnell paketieren kann.
                            Das Ganze ist bequem und schnell gemacht. Genauso wie aufgezeichnete Pakete eben.

                            Gruß
                            Matthias
                            • 11. Re: Wie skriptet ihr ?
                              Markus.Zierer Expert
                              Hallo,

                              Also meine Vorgehensweise ist eigentlich immer die, dass ich zuallererst immer einen Spy von einer Software mache. Der Grund hierfür ist ganz einfach der, dass ich anhand des Spy's sehen kann, was genau denn so alles von dem Installer gemacht wird. Anhand des Ergebnisses dieser Prüfung entscheide ich dann, ob es tatsächlich ein Spy Paket bleibt oder ob ich statt dessen MSI Pakete einsetze.

                              Was das Thema Spy betrifft, kann ich mich dem Frank nur anschliessen. Wenn man nicht weis was man da tut, verursachen Spy Pakete enorme Bauchschmerzen. Leider haben meiner Erfahrung nach nur ganz wenige Paketierer die Notwendige Erfahrung und auch Ausbildung um effektiv mit Spy Technologie arbeiten zu können. Ich für meinen Teil habe ca. 2 Jahre gebraucht um einigermaßen valide abschätzen zu können, welche RegKeys für das funktionieren einer Anwendung notwendig sind oder nicht. Diesen Luxus hat aber leider nicht jeder NI Admin, das ist mir durchaus bewusst.

                              Und was das Thema Applikationsvirtualisierung betrifft. Da kann ich nur den Kopf schütteln. Ich habe mich die letzte Woche ausschliesslich mit App-V beschäftigt und muss sagen dass man auch hier ohne fundiertes Wissen um die Funktion der Registry nicht auskommt. Es ist zwar total einfach mit dem Sequencer eine Appliakation zu Virtualisieren, aber für ein Reibungsloses funktionieren muss die Registry und das Filesystem trotzdem nachgearbeitet werden. Ansonsten landet der ganze Müll ja wieder auf dem System. Und der Idee, die ganzen VirtualApps als MSI Paket auf dem Zielsystem zu installieren. LOL, wenn das nicht von hinten durch die Brust ins Auge ist weis ich auch ned mehr.

                              Applikationsvirtualisierung hat in meinen Augen schon eine Berechtigung. Aber nur da, wo ich gezwungen bin Anwendungen auf einem OS laufen zu lassen, dass nicht mehr unterstützt wird (z.B. NT4 App auf Vista oder sowas). Für die ganzen anderen Themen ist es nicht geeignet.
                              • 12. Re: Wie skriptet ihr ?
                                FrankScholer Master

                                Applikationsvirtualisierung hat in meinen Augen schon eine Berechtigung.  Aber nur da, wo ich gezwungen bin Anwendungen auf einem OS laufen zu  lassen, dass nicht mehr unterstützt wird (z.B. NT4 App auf Vista oder  sowas). Für die ganzen anderen Themen ist es nicht geeignet.


                                Aber genau das ist von Microsoft NICHT supported!

                                Hier die (meines Wissens nach aktuelle) offizielle Aussage von Microsoft dazu:
                                It is often possible to sequence on one OS and run the virtualized app on a different OS, however this scenario is both app and OS dependent and is not guaranteed to work for all app/OS combinations since App-V is not a general purpose OS compatibility solution. If problems are encountered, the customer may be required to sequence on the same OS environment as the App-V client is running in order to resolve those problems.
                                (siehe http://blogs.technet.com/appv/archive/2009/12/14/do-i-need-to-re-sequence-my-applications-when-i-move-to-a-new-os.aspx)

                                Grüße Frank
                                • 13. Re: Wie skriptet ihr ?
                                  Markus.Zierer Expert
                                  LOL, wie Geil ist das denn...

                                  Auszug aus dem Technet App-V Guide:

                                  Bewährte Methoden der Sequenzcomputerkonfiguration

                                  Für die Konfiguration des Computers, auf dem App-V Sequencer ausgeführt wird, gelten die folgenden Empfehlungen:

                                  Führen Sie die Sequenzierung auf einem Computer durch, der eine ähnliche Konfiguration besitzt und auf dem eine frühere Version des Betriebssystems als auf den Zielcomputern läuft.

                                  Stellen Sie sicher, dass auf dem Computer, auf dem der Sequencer ausgeführt wird, eine frühere Version des Betriebssystems läuft als auf den Zielcomputern. Dies schließt die Übereinstimmung von Service Packs und Updateversionen ein. Wenn auf den Zielcomputern beispielsweise Windows Vista und Windows XP ausgeführt wird, müssen Sie zum Sequenzieren von Anwendungen einen Computer verwenden, auf dem Windows XP ausgeführt wird.

                                  Also tut mir echt leid, aber ich finde wirklich NICHT dass Applikationsvirtualisierung der große Wurf ist. Mit vernünftigem SW Mangagement kommt man weiter.
                                  • 14. Re: Wie skriptet ihr ?
                                    FrankScholer Master
                                    Dieser Hinweis ist aber schon ganz alt und stammt, soviel ich weiß, noch aus Softgrid-Zeiten. Im aktuellen 4.6er Sequencing Guide ist in der Beschreibung, was der Sequencer-Computer für Voraussetzung erfüllen soll, als allererstes zu lesen:
                                    "Sequence on a machine that matches the operating system (OS) and configuration of the target clients".

                                    Grüße Frank
                                    [FONT="]
                                    1 2 Previous Next