Go Back   Desktop & Server Management (DSM) Forum > GERMAN > DSM 7 > DSM 7 NetInstall
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old April 5th, 2017, 09:35
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Frage Benutzt noch jemand RunEScript ?

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.
Reply With Quote
  #2  
Old April 5th, 2017, 11:18
Frank Scholer's Avatar
Frank Scholer Frank Scholer is offline
Erfahrener Benutzer
 
Join Date: 04-24-04
Location: Pforzheim
Posts: 1,897
Default

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
__________________
Frank Scholer | NWC Services GmbH
www.nwc-services.de/de/service-de/blog

Last edited by Frank Scholer : April 5th, 2017 at 11:28.
Reply With Quote
  #3  
Old April 5th, 2017, 11:48
NicoS's Avatar
NicoS NicoS is offline
Erfahrener Benutzer
 
Join Date: 09-10-07
Location: Bad Rappenau
Posts: 1,340
Send a message via ICQ to NicoS
Default

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...
__________________
- Nico Schmidtbauer
Fujitsu TDS GmbH
Privater Blog - Generelle IT & Deployment Themen, DSM Themen und DSM Automatisierung via PowerShell

Last edited by NicoS : April 5th, 2017 at 11:53.
Reply With Quote
  #4  
Old April 5th, 2017, 13:27
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

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)
Reply With Quote
  #5  
Old April 6th, 2017, 10:42
SBR SBR is offline
Erfahrener Benutzer
 
Join Date: 12-03-03
Location: Greifenberg am Ammersee
Posts: 822
Send a message via MSN to SBR
Default

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
__________________
Aton Consult
IT-Consulting & Training
Web: http://www.aton-consult.de Blog: http://deployment-guru.blogspot.de/
Reply With Quote
  #6  
Old April 6th, 2017, 15:45
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

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"
Reply With Quote
  #7  
Old April 7th, 2017, 10:14
SBR SBR is offline
Erfahrener Benutzer
 
Join Date: 12-03-03
Location: Greifenberg am Ammersee
Posts: 822
Send a message via MSN to SBR
Default

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.
__________________
Aton Consult
IT-Consulting & Training
Web: http://www.aton-consult.de Blog: http://deployment-guru.blogspot.de/
Reply With Quote
  #8  
Old April 7th, 2017, 22:41
NicoS's Avatar
NicoS NicoS is offline
Erfahrener Benutzer
 
Join Date: 09-10-07
Location: Bad Rappenau
Posts: 1,340
Send a message via ICQ to NicoS
Default

Quote:
Originally Posted by SBR View Post
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
__________________
- Nico Schmidtbauer
Fujitsu TDS GmbH
Privater Blog - Generelle IT & Deployment Themen, DSM Themen und DSM Automatisierung via PowerShell

Last edited by NicoS : April 7th, 2017 at 22:52.
Reply With Quote
  #9  
Old April 8th, 2017, 16:53
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

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.
Reply With Quote
  #10  
Old April 9th, 2017, 23:55
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

Quote:
Originally Posted by Frank Scholer View Post
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.

Last edited by Mel : April 9th, 2017 at 23:58.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

   

All times are GMT +1. The time now is 15:58.

Powered by vBulletin Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.