1 2 Previous Next 17 Replies Latest reply on Apr 8, 2017 9:53 AM by _Mel_

    Benutzt noch jemand RunEScript ?

    _Mel_ Master
      Falls ja: wozu ? wie oft ? und wäre es schlimm wenn der wegfallen würde ?

      Hintergrund der Frage ist, daß der Befehl komplett am Policy und Compliance Konzept vorbei läuft und es für den Fall, daß man aus einem Paket heraus die Installation eines anderen Paketes auslösen will, den ChangeSwAssignment Befehl gibt.
        • 1. Re: Benutzt noch jemand RunEScript ?
          Frank.Scholer Master
          Hi Mel,

          aus gegebenen Anlass: selten, aber er wird noch benutzt. Wenn, dann aber eigentlich als "Gosub-Erstatz" (um mal im BASIC-Slang zu sprechen), also wenn man Pakete hat die Funktionen beinhalten und man eigentlich nur eine Funktion / Subroutine aufrufren möchte, weil man den Code nicht jedesmal in jedes Paket einfügen will (was man mit Snippets ja recht problemlos könnte).

          Also einer neuer Pakettyp "Function Package" (in einer "Function Package Library") wäre vieeel cooler als RunEScript ;-). Dieser Pakettyp könnte dann z.B. auch die Properties "IsAssignable" statisch auf "false" und "MakeAvailableOffline" auf "true" haben und so müsste nichts zur Laufzeit aus's Depot oder auf's Netzwerk zugreifen... dazu müsste es dann einen neuen Befehl "CallFunctionPackage" geben (dem man optimalerweise noch Parameter mitgeben kann) und voilà...nur mal so ins Blaue philosophiert...

          Grüße Frank
          • 2. Re: Benutzt noch jemand RunEScript ?
            NicoS1 Master
            Hallo Mel,

            ja, wir verwenden den Befehl häufig! Primär für folgende zwei Themen:

            Middlware Runtimes:
            Themen wie C++ Runtimes etc. wir haben es bei uns so implementiert, dass wir die Runtimes in extra eScripts auslagern, und haben Snippets erstellt die eine Prüfung machen ob die Runtime Installiert ist oder nicht, wenn nicht, RunEScript auf das entsprechende Paket. So kann man sich je nachdem bequem die Runtimes zusammen ziehen die man für ein Paket benötigt. Bei diesen Paketen legen wir keinen Wert auf Compliance, und es macht das handling einfach sehr unkompliziert. (Und das wir schon Software hatten die in ihrer eigenen Installationsroutine [uninst000.exe /SILENT] auch die Runtimes wieder deinstalliert, völlig ohne Rücksicht ob sie von einer anderen Appl. noch benötigt werden!?!)

            Einstellungspakete:
            Bei manchen Applikationen haben wir separate Pakete zur Verteilung von Einstellungen. Beispielsweise Firefox oder Java. Auf der einen Seite sind diese Pakete separat zugewiesen, damit wir eventuelle Änderungen einfach durch Revision / Neuausrollen rauspushen können, auf der anderen Seite haben wir dann Beispielsweise im Java Paket einen RunEScript auf das Setting Paket drin um sicherzustellen, dass nach einem Update / Install / Reinstall von Java das Settingpaket erneut ausgeführt wird, da das Update selbst das eine oder andere Setting rückgängig macht.

            Man könnte das ein oder andere auch durch Software Sets abfackeln, aber ich sags dir wie es ist... mir ist das Handling von Software Sets mit Revisionierung etc. einfach zuwider... hätte ich nur eine Umgebung am laufen, wo wir solche Updates regelmäßig machen, wäre das denke ich mal gar nicht so schlimm, aber wir beteuen hier ja mehrere Kunden mit DSM und wenn man bei x Kunden x mal ein Softwareset hochrevisionieren muss nur weil wieder so ein verfluchtes Firefox oder Java Update rausgekommen ist, entwickelt man seinen ganz persönlichen Hass gegen Software Sets für das Massenhandling ist ein RunEScript doch um einiges praktikabler. Und meistens gehts weniger um das Assignment an sich, sondern darum, dass ein RunEScript ein bereits installiertes Paket auch nochmal ausführen kann und zwar genau an der stelle im Script an dem ich das Paket jetzt brauch.

            Rein Scripttechnisch würde ich sagen, dass der RunEScript für mich die Funktion eines include() einnimmt.
            Und da wir vieles damit gebaut haben... ja wäre schlimm und würde nicht unwesentliche Aufwände erzeugen, wenn er so wegfallen würde, dass er gar nicht mehr funktionieren würde...
            • 3. Re: Benutzt noch jemand RunEScript ?
              _Mel_ Master
              Also ich denke gerade so in zwei Richtungen
              zum einen: wenn es eine Policy für das Paket für das ein RunEScript gemacht wird gibt, dann wird dafür praktisch ein ChangeSwAssignment(Install/Update/Reinstall) gemacht und anschließend die entsprechende Instanz sofort ausgeführt (So ähnlich wie beim Patchmanagement das PatchManagement execution package die patch pakete ausführt)

              damit könnte RunEScript schonmal nicht mehr die Policies verpfuschen.

              und wenn's keine policy gibt ... dann wäre es schonmal schön, wenn der installer die daten gleich bekommt und damit auch schon im vorraus stagen kann und nicht erst mitten in der escriptausführung einen sync machen muß.
              dafür könnte man die pakete z.B. über installationsparameter verlinken (analog zu ossetupfilepackages) oder über variablen (wie bootenvironments)
              • 4. Re: Benutzt noch jemand RunEScript ?
                SBRUTSCH Expert
                Hallo,

                im WTS Umfeld gerade bei Publish Apps kommt der RunEScript oft vor.

                Da wird für die PA kein komplettes Profil für den Anwender generiert. Um jedoch dann eine App zu verwenden die Office oder Internet Explorer verwendet muss der Userteil dafür ausgeführt sein. Der Agent wird hierzu nicht verwendet da er dann wieder ein vollständiges Profil erhält was er nicht braucht.

                Somit ist momentan der RunEScript die beste Möglichkeit in diesem Szenario.

                Viele Grüße,
                Stefan
                • 5. Re: Benutzt noch jemand RunEScript ?
                  _Mel_ Master
                  ok, aber um für einzelne pakete den benutzerteil zu installieren wird doch der runscriptinstaller verwendet (also mit /execute)
                  meinst du, daß runescript in dem benutzerteil verwendet wird um benutzerteile anderer pakete zu installieren ?

                  in den fall wäre die "halte dich an das was die policy vorgibt" methode ja eigentlich ein sinnvolleres verhalten als das "benutze eine bestimmte, bzw die letzte revision"
                  • 6. Re: Benutzt noch jemand RunEScript ?
                    SBRUTSCH Expert
                    Ja, ein Script für die PA ruft die Benutzerteile anderer Scripte auf.

                    Und bei WTS darf es nur die Revision sein die als Maschinenteil auch schon installiert ist. Also meistens nicht die aktuellste Revision. Hier verwenden wir eine Variable die Vorher die Revision des Maschinenteils ausliest.
                    • 7. Re: Benutzt noch jemand RunEScript ?
                      NicoS1 Master

                      Und bei WTS darf es nur die Revision sein die als Maschinenteil auch schon installiert ist. Also meistens nicht die aktuellste Revision. Hier verwenden wir eine Variable die Vorher die Revision des Maschinenteils ausliest.



                      Sorry, wenn auch etwas Offtopic, aber ich muss es einfach loswerden: krasses Konstrukt

                      Und @ Mel: Mich würde jetzt an der Stelle doch noch etwas mehr Background interessieren. Möchtest du veranlassen das der Befehl rausgenommen wird, bzw. gibt's da konkrete Pläne von Ivanti?

                      Wenn ja... dann wäre das nämlich der nächste Punkt zu dem ich eine böse E-Mail schreiben würde... wäre nicht das erste mal das bei einem Produkt was eigentlich zur Automatisierung und Kostenreduktion dienen soll, aber durch eine nicht-nachvollziehbare Idee etwas ohne adäquaten Ersatz zu streichen, dann doch wieder unter Umständen ein Haufen Aufwände zur Umstellung erzeugen würde. Und ich kenne es leider noch zu Genüge aus der enteo V6, in dem wir beim Pakete bauen vermeintliche Features genutzt haben, die sich später als Bug rausgestellt haben und von den Kollegen aus Filderstadt "gefixed" wurden... oder so Themen wie das mit irgend einem Patch sowas wie "Execute(sc.exe config ...)" plötzlich nicht mehr funktionierte, und wir alle Pakete durchforsten mussten und es gegen "Execute(%winsysdir%\sc.exe ...)" austauschen mussten... leider sind wir was die DSM Umgebungen und Paketanzahl angeht drastisch gewachsen... weshalb ich auf solche potentiellen Änderungen doch leicht allergisch reagiere mittlerweile...

                      Wie gesagt... für mich ist der RunEScript nichts weiteres als ein INCLUDE was eine grundsätzliche Scriptfunktion in so fast allen Scriptsprachen ist... auf einen Kompromiss bzw. Evolution, wie Frank es vorgeschlagen hat (unter der Vorraussetzung, dass das Function Package nicht nur eine Script Inc, sondern auch Massendaten beinhalten dürfte), würde ich mich ja noch einlassen. Mit offizieller Ankündigung, und Kulanzzeit...

                      Der ChangeSwAssignment wäre zwar für einen Anwendungsbereich praktikabel (nach Einspielen eines Updates ein separates Setting Paket, was sowieso als SW Policy zugewiesen ist, nochmal neu installieren zu lassen), aber die Möglichkeit ein externes eScript genau an der Stelle im eScript aufzurufen, an der ich es haben möchte würde mir trotzdem verloren gehen.

                      P.S.: Dritter Anwendungsbereich fällt mir gerade noch ein... ist vielleicht etwas ausgefallener aber trotzdem:
                      Kundenanforderung: Version 1.0 einer Software ist auf allen Clients im Unternehmen automatisch mit installiert. Auf alle Computer die neu installiert werden, soll anstatt Version 1.0 einer Software direkt Version 2.0 einer Software installiert werden. Alle bestehenden Computer sollen vorerst nicht automatisch aktualisiert werden, sondern der User soll per Software Shop die Installation starten können, da die Installation länger dauert und die Arbeit des Users unterbrechen würde.

                      Unsere Lösung hierzu (schon seit längerem)...
                      - Zuweisung von Version 1.0 deaktivieren.
                      - Version 2.0 mit inaktiver Policy zuweisen.
                      - Alle Policyinstanzen die angelegt wurden auf "Rollout stoppen" setzen.
                      - Policy aktiv setzen (so läuft die Installation nur Computer die frisch in der dyn. Gruppen laden).
                      - Den Clients ein Software Shop Paket hinterlegen, dass prüft ob Version 2.0 schon installiert ist, wenn nicht, RunEScript auf das Version 2.0 Paket.

                      Das geht mit den neueren Mitteln evtl. auch anders... aber trotzdem
                      • 8. Re: Benutzt noch jemand RunEScript ?
                        _Mel_ Master
                        das "krasse Konstrukt" von SBR ist ein Workaround für eines der Probleme, die ich mit RunEScript habe: nämlich, daß wenn man eine Software per Policy in einer bestimmten Revision und mit bestimmten Installationsparametern installiert hat, RunEScript mal eben mit einer anderen Revision drüberinstalliert. Sowas sollte mMn einfach funktionieren, ohne daß man was aus der Registry auslesen muß. Oder anders formuliert: eine falsche Verwendeung von RunEScript sollte einem nicht den durch die Policies vorgegebenen Zustand zerschießen.

                        aber mal ehrlich: auf Kompatibilität wird in DSM und speziell bei eScript recht viel Wert gelegt - darum gibt's auch zig Einstellmöglichkeiten um altes Verhalten beizubehalten... z.B. gibt's eine Einstellung an Paketen, ob es als Fehler gelten soll, wenn eine Datei, die im Script kopiert werden soll nicht existiert - einfach weil es Skripte geben könnte, in denen noch copy befehle für dateien drin sind, die nicht mehr im Paket sind.
                        Und dann haben wir noch die Einstellungen in der NCP - bei denen ist natürlich immer die Frage: was ist der default: Das alte Verhalten oder das neue ? Ich tendiere da ganz klar zum neuen, wenn man mal davon ausgeht, daß das neue in den meisten Fällen keine Probleme macht und da wo es sich unterscheidet die im allgemeinen bessere Wahl ist (wenn das nicht der Fall wäre: warum hat man es dann gemacht ?)
                        Denn andernfalls hat man so tolle Ergebnisse, daß sich Leute wundern, daß alle ihre Windows Server als Terminalserver erkannt werden, nur weil das mal aufgrund eines Bugs so war und jemand gemeint hat, daß die, denen das nicht gefällt halt nen ncp wert ändern sollen anstatt daß die drei, die tatsächlich wollen, daß jeder server als terminalserver gilt den wert auf "gib mir meinen bug wieder" stellen
                        Dabei muß ich immer an das hier denken: https://xkcd.com/1172/
                        und ja, das ist kein witz, sondern in DSM tatsächlich so und das macht neueinsteigern das leben echt schwer - ich hab mal ne halbe stunde damit verbracht alle einstellungen zu finden, die man anpassen mußte, damit auf einem server die F7 installation funktioniert

                        Wenn sich da also was ändern sollte, dann ist das entweder sehr kompatibel oder man kann das alte verhalten wieder herkonfigurieren (oder wahrscheinlich beides)

                        das mit dem execute klingt danach, daß da intern wegen irgendeinem problem auf eine andere windowfunktion umgestellt wurde, die aber den Suchpfad nicht berücksichtigt. Aber ich würde vermuten/hoffen, daß das eher am Anfang der v6 war, als das neben den anderen Problemen eher als Luxusproblem gegolten haben dürfte - heute würde so eine Änderung wahrscheinlich recht schnell gefixt werden, zumal der RunAsEx Befehl seit ein/zwei Versionen auch den Suchpfad verwendet und die Endung ergänzt. Naja kommt etwas darauf an... wenn man Pech hat werden auch heute Sachen, die einfach, schnell und risikolos behebbar wären, gecancelt.


                        zurück zum Thema:
                        meine Idee wäre so eine Art RunPolicy Befehl, den man nach einem ChangeSwAssignment dazu verwenden kann um das Paket sofort auszuführen, was besonders wenn man darüber eine Systemvoraussetzung installieren will vermutlich sehr hilfreich wäre, weil dadurch die Voraussetzung vor der eigentlichen Software installiert würde - aber man würde dabei dann halt auch in der DSMC sehen, wo und in welcher Version das anderen Paket installiert wurde.
                        Und ein policykonformer RunEScript Befehl könnte intern nichts anderes machen als ChangeSwAssignment + RunPolicy.
                        In dem Fall von SBR würde sich nichtmal was ändern (außer das das Auslesen der Registry unnötig wäre).
                        Ansonsten müßte man für solche Pakete Shoppolicies anlegen die für den Benutzer im Shop nicht sichtbar sind (was geht indem man die Enduser Permissions nicht setzt) - oder es müßte einen Fallback auf das bisherige Verhalten geben, wenn es keine passende Policy gibt.

                        wobei mir für solche abhängigkeiten eine Möglichkeit gefallen würde am Paket definieren zu können welche andere Software es braucht und die dann automatisch vorher installiert würde und wenn sie nicht mehr benötigt würde automatisch wieder deinstalliert würde (ähnlich wie das alte Komponentenmodell, nur eben policykonform)

                        zu deinem dritten Fall: selbst vor der 2015.2 hätte doch eine Shoppolicy für die Version 2.0 schon ausgereicht (zumindest wenn die ein anderes Paket ist) - hätte zwar Unmengen an geshoppten Policies angelegt, aber die hast du mit deinem Hilfspaket doch auch. Ab 2015.2 kannst du einfach die Policy unkritisch updaten und dem Endbenutzer die Erlaubnis geben im shop das Update durchzuführen.
                        • 9. Re: Benutzt noch jemand RunEScript ?
                          _Mel_ Master


                          Also einer neuer Pakettyp "Function Package" (in einer "Function Package Library") wäre vieeel cooler als RunEScript ;-). Dieser Pakettyp könnte dann z.B. auch die Properties "IsAssignable" statisch auf "false" und "MakeAvailableOffline" auf "true" haben und so müsste nichts zur Laufzeit aus's Depot oder auf's Netzwerk zugreifen... dazu müsste es dann einen neuen Befehl "CallFunctionPackage" geben (dem man optimalerweise noch Parameter mitgeben kann) und voilà...nur mal so ins Blaue philosophiert...


                          Ich mag die Idee... technisch sollte es auch recht simpel sein;
                          die Frage ist nur wie man die Daten auf den Client bekommt.
                          Anbieten würden sich Installationsparameter oder ODS Variablen.
                          Also im Prinzip die Varianten, wie man auch bei Bootenvironments hat - mit demselben Effekt, daß man über Installationsparameter immer dasselbe Paket bekommt und damit dasselbe Verhalten bei einer Zuweisung, wogegen man bei einer ODS Variable leicht updaten kann ohne daß es die Compliance beeinflußt.
                          Was meinst du wieviele solcher Funktion Packages man in einer Umgebung hätte (wenn es viele sind könnte es unübersichtlich werden wenn man ODS Variablen verwendet) - man könnte die natürlich wieder zu sowas wie Sets / Libraries kombinieren.

                          und wenn man auf diese Weise auch noch OsSetuFilePackages verwenden könnte, dann hätte man auch das Windows10 Inplace Upgrade.
                          • 10. Re: Benutzt noch jemand RunEScript ?
                            derniwi Master
                            Hallo zusammen,

                            also, zuerst einmal: nein, RunEScript nutze ich nicht bzw. wenn es noch irgendwo in einem Scrikpt ist, dann ist das ein Fehler.

                            Ich wünschte mir auch schon eine Bibliothek oder zumindest ein GoSub. Allerdings weiss ich als Hobby-Programmierer auch, dass Bibliotheken auch nicht das Gelbe vom Ei sind. Denn mit einem Update einer Funktion könnten sich ja auch Parameter ändern. Somit wird das ganze Konstrukt ungleich komplizierter.

                            Hier helfen die Snippets zwar, aber auch die sind nur begrenzt universell. Denn wenn sich die Logik im Snippet ändert, weil man vielleicht etwas vergessen hat oder man noch etwas ergänzen muss, dann bleibt auch dies in bestehenden Paketen unberücksichtigt. Aber das ist auch irgendwie gut so. Denn Änderungen, die paketübergreifend vorgenommen werden müssen, müssen dann natürlich wieder die Compliance-Kette durchlaufen.

                            Was sich hier bewährt hat, sind Snippets für bestimmte Dinge, die aber nur begrenzt fertigen Code liefern. Es müssen noch Variablen angepaßt werden, evtl. RunAsEx / ExecuteEx-Befehl geändert bzw. befüllt usw. Ist ein Paket somit erstellt und getestet, dann passt die zu diesem Zeitpunkt gültige Compliance-Idee und -Prüfung. Muss später die Logik im Snippet erweitert werden, dann muss man natürlich die passenden Pakete finden und ggfs. überarbeiten.

                            Eine weiterer Ansatz ist natürlich, dass man mit Sets arbeitet, wenn das auch gleich mehr Arbeit bedeutet. Wenn es mal möglich sein wird, ein Paket mehrfach in einem Set verwenden zu können, kann das sicherlich auch für andere hilfreich sein (Service Request habe ich vor einiger Zeit erstellt).

                            Ein GoSub: wäre sicherlich hilfreich, ich kann mir aber mit der eScript Logik bzgl. SI/AI sowie Installation und automatischer Deinstallation schon einige Probleme in diesem Zusammenhang vorstellen. Alleine dass es schon keine Konstanten innerhalb eines Paketes gibt (SR wurde abgelehnt), zeigt, dass man andere Aspekte im Fokus hat. Ich habe an einigen Stellen MSIExec im Einsatz, weil die internen MSI-Befehle nicht alles liefern, wie ich bzw. die Anwendung das braucht. Dann habe ich, wegen Updates, z.B. den Namen der MSI-Datei in einer Variablen abgelegt. Es ist aber nicht einfach möglich, diese Variable während der Installation zu befüllen und im Uninstall-Teil den Wert noch zu haben. Da muss man den Umweg über die Registry gehen (im Install-Teil die Variable setzen, den Wert in der Registry ablegen und bei der Deinstallation den Wert aus der Registry wieder auslesen), ist aber leider unschön. Alternativ kann man hier auch mit Installationsparametern arbeiten, aber auch die mag ich nicht, weil man sie bei Updates einfach zu leicht übersieht und neue Werte dann auch für alle Instanzen gesetzt werden müssen.

                            Auch ein GoSub könnte man sich selbst basteln, hierzu müsste man ja "nur" eine Variable für die Rücksprungadresse setzen sowie das passende Label dazu und dann den Goto-Befehl verwenden. Bei der GoSub-Ziel-Adresse wird am Ende per If-Befehl der Inhalt der gesetzten Rücksprungadresse der Wert geprüft und dann der entsprechende Goto-Befehl ausgeführt. Das führt bei ausschweifender Benutzung natürlich zu langen GoSub-Routinen, müsste aber funktionieren.

                            Gruß
                            Nils
                            • 11. Re: Benutzt noch jemand RunEScript ?
                              _Mel_ Master
                              was meinst du mit konstanten in einem paket ?
                              in grunde sind (bei zuweisung nicht änderbare) installationsparameter doch genau das.
                              und seit der 2015.2 haben die bei der deinstallation noch den wert mit dem installiert wurde - selbst wenn in der zwischenzeit ein kritisches update der policy mit einem anderen wert gemacht wurde. bei nicht änderbaren kann man beim update auch nichts vergessen.

                              mit variablen geht's übrigens auch: bei der deinstallation stehen die variablen zur verfügung die während der installation gelesen wurden - also einfach die variable bei der installation nochmal lesen, nachdem sie gesetzt wurde (und ja, es wäre sinnvoll variablen die nur gesetzt werden ebenfalls zu speichern)
                              • 12. Re: Benutzt noch jemand RunEScript ?
                                derniwi Master
                                Uppps. Das die Variablen seit 2015.2 ihren Wert für die Deinstallation behalten, ist mir entgangen. Danke für den Hinweis, das macht es an manchen Stellen einfacher.
                                Habe da sauch gerade mal schnell erfolgreich getestet.

                                Ich hatte früher das Problem, dass das ja nicht ging. Und auch mal ein Problem mit einem Installationsparameter, den ich nur für die Deinstallation brauchte, der aber während der Installation gelesen werden musste...

                                Und den zweiten Abschnitt musste ich jetzt zweimal lesen...
                                Ja, Flags für das Verhalten von Variablen wären durchaus hilfreich:
                                - Variablenwert nach der Skriptausführung behalten
                                oder
                                - Variablenwert nach der Skriptausführung behalten für Deinstallation
                                - Variablenwert nach der Skriptausführung behalten für Reinstallation
                                - Variablenwert nach der Skriptausführung behalten für Reparatur
                                - Variablenwert nach der Skriptausführung behalten für Änderung

                                Mit den Installationsparametern bin ich nie richtig warm geworden, damit tue ich denen vielleicht unrecht...
                                • 13. Re: Benutzt noch jemand RunEScript ?
                                  Frank.Scholer Master
                                  Hi Mel,

                                  Ich mag die Idee... technisch sollte es auch recht simpel sein;
                                  die Frage ist nur wie man die Daten auf den Client bekommt.


                                  Freut mich, dass du die Idee magst - ich verstehe aber die Frage nicht... wenn für ein Paket die Eigenschaft "Herunterladen ohne Policy-Instanz" (also "%CurrentPackage.FilesetProps.MakeAvailableOffline%") fest auf "True" gesetzt ist, sollte das doch auf jeden Fall in den Repository-Cache gestaged werden, oder? Und dann isses ja da und steht für Aufrufe durch andere Pakete zur Verfügung...

                                  Anbieten würden sich Installationsparameter oder ODS Variablen..


                                  Meinst du jetzt, wie man sie im (aufrufenden) Paket referenziert? Das wäre bei meinem Konzept garnicht nötig, da alle Pakete des Typs "Function Package" im im Repository Cache dauerhaft verfügbar sein würden...

                                  Was meinst du wieviele solcher Funktion Packages man in einer Umgebung hätte


                                  Da mag ich keine Einschätzung zu wagen... ich denke, in intensiv genutzten Umgebungen viele, vielleicht sogar sehr viele ;-)

                                  Und wenn man auf diese Weise auch noch OsSetupFilePackages verwenden könnte, dann hätte man auch das Windows 10 Inplace Upgrade.


                                  Naja, da würde ich doch lieber sehen wollen, dass man zumindest aus für eScripts einen neuen Installationsparameter vom Typ "Objekt-ID" anlegen kann (wenn's schon kein eigener Pakettyp für Inplace-Upgrades sein soll) und dann beim Anlegen eben sagen muss, welches OS, welchen Flavor und welche Sprache enthalten sein dürfen... sonst wird hier was "vermischt", was m.E. eher nicht zusammengehört.

                                  Grüße Frank
                                  • 14. Re: Benutzt noch jemand RunEScript ?
                                    _Mel_ Master


                                    Freut mich, dass du die Idee magst - ich verstehe aber die Frage nicht... wenn für ein Paket die Eigenschaft "Herunterladen ohne Policy-Instanz" (also "%CurrentPackage.FilesetProps.MakeAvailableOffline%") fest auf "True" gesetzt ist, sollte das doch auf jeden Fall in den Repository-Cache gestaged werden, oder? Und dann isses ja da und steht für Aufrufe durch andere Pakete zur Verfügung...

                                    die frage war mehr: warum sollte der BLS dem client die daten des paketes schicken ? denn nur weil ein paket existiert steht es ja noch lange nicht dem client zur verfügung - klar, in runescript schon, der hebelt ja alles aus, auch das rechtekonzept.

                                    ...und auch für's herunterladen ohne instanz braucht der client (momentan) trotzdem eine policy (enter-/leave-maintenance ist ein spezialfall)


                                    Meinst du jetzt, wie man sie im (aufrufenden) Paket referenziert? Das wäre bei meinem Konzept garnicht nötig, da alle Pakete des Typs "Function Package" im im Repository Cache dauerhaft verfügbar sein würden...

                                    was nicht die frage beantwortet wie man sie im script referenziert.

                                    es könnte z.B. so aussehen
                                    CallFunctionPackage('%CurrentComputer.Var.Functions.KillOffice%')


                                    d.h. wenn man eine neue revision oder ein ganz neues paket für diesen zweck hat, dann aktualisiert man nur die variable und sie wird verwendet. Und wenn man's erstmal testen will, dann ändert man die Variable halt nur für die Testcomputer. Und wenn die neue Version irgendwo Probleme macht, dann stellt man für die Gruppe halt wieder die alte Version ein.

                                    Bei RunEScript bist du dagegen auf ein Paket festgelegt und davon entweder auf eine feste Revision oder die letzte - zurückgehen oder anderes Paket bedeutet: alle Pakete ändern. KLingt nach ungefähr so viel Spaß wie früher eine neue Bootenvironmentrevision anzulegen (und da hätte es gereicht die Policies zu ändern, aber irgnedwie haben alle lieber ihre Pakete + Sets revisioniert)


                                    Naja, da würde ich doch lieber sehen wollen, dass man zumindest aus für eScripts einen neuen Installationsparameter vom Typ "Objekt-ID" anlegen kann (wenn's schon kein eigener Pakettyp für Inplace-Upgrades sein soll) und dann beim Anlegen eben sagen muss, welches OS, welchen Flavor und welche Sprache enthalten sein dürfen... sonst wird hier was "vermischt", was m.E. eher nicht zusammengehört.

                                    darum wäre ich eher für einen eigenen Pakettyp; schon damit man nicht dasselbe Paket für Policies und für Funktionsaufrufe verwenden kann.
                                    1 2 Previous Next