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
  #11  
Old April 18th, 2017, 13:41
derniwi derniwi is offline
Erfahrener Benutzer
 
Join Date: 02-15-12
Posts: 1,654
Default

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
__________________
Sie haben die Maus bewegt. Bitte starten Sie den Rechner neu, damit die Änderungen wirksam werden.
Reply With Quote
  #12  
Old April 18th, 2017, 13:54
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

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)
Reply With Quote
  #13  
Old April 18th, 2017, 14:47
derniwi derniwi is offline
Erfahrener Benutzer
 
Join Date: 02-15-12
Posts: 1,654
Default

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...
__________________
Sie haben die Maus bewegt. Bitte starten Sie den Rechner neu, damit die Änderungen wirksam werden.
Reply With Quote
  #14  
Old April 22nd, 2017, 15:41
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,
Quote:
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...
Quote:
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...
Quote:
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 ;-)
Quote:
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
__________________
Frank Scholer | NWC Services GmbH
www.nwc-services.de/de/service-de/blog
Reply With Quote
  #15  
Old April 24th, 2017, 08:41
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

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

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

Quote:
Originally Posted by Frank Scholer View Post
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.
Reply With Quote
  #16  
Old April 24th, 2017, 09:01
derniwi derniwi is offline
Erfahrener Benutzer
 
Join Date: 02-15-12
Posts: 1,654
Default

Quote:
Originally Posted by Mel View Post
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)
Oder man bräuchte also auch ein eigenes Verzeichnis, sagen wir mal analog zum EXTERN$-Ordner auf dem DSM-Server. Dieses wird dann auch an die Clients synchronisiert.

Quote:
Originally Posted by Mel View Post
was nicht die frage beantwortet wie man sie im script referenziert.

es könnte z.B. so aussehen
Code:
CallFunctionPackage('%CurrentComputer.Var.Functions.KillOffice%')
Und wie macht man das mit der Variablenübergabe?
Man kann ja nicht davon ausgehen, dass dann jeder alle zu übergebenenden Variablen kennt und diese vorher setzt und nachher auswertet.

Das müsste dann noch irgendwie erweitert werden:
Code:
CallFunctionPackage('%CurrentComputer.Var.Functions.KillOffice%'; 'VarUp1', 'VarUp2', 'VarDown1', 'VarDown2')
wobei ich jetzt hier einfach mal zwei Variablen zur Übergabe an das Skript (VarUp1, VarUp2) und zwei für Rückgabewerte (VarDown1, VarDown2) als Beispiel angegeben habe. In aktuellen Programmiersprachen ist der einfache Datentyp als Ergebnis ja schon lange nicht mehr das einzige, was geht. Aber jetzt hier Klassen einzuführen, ist dann doch etwas überzogen.

Variablen in den Funktionsskripten dürften dann auch nicht global geändert werden... und und und...

Quote:
Originally Posted by Mel View Post
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)

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.
Ja, RunEScript ist eine Notlösung.

Auf der anderen Seite: was versprecht Ihr Euch von Funktionen, was man nicht mit anderen Skriptsprachen wie VB oder PowerShell lösen kann? Oder besser hierfür einen anderen Thread eröffnen?

Ich bin nicht sehr tief in der PowerShell--Programmierung drin, eher auf den CMD-Skripten stehen geblieben , nutze auch VB, wenn mir das hilft. Aber ganz klar, eScript hat viele Einschränkungen und manche Dinge darüber zu lösen ist mega aufwendig. Und PS oder VB kann das dann als relativ kurzes Skript, und dann auch noch schnell abgearbeitet...

Gruß
Nils
__________________
Sie haben die Maus bewegt. Bitte starten Sie den Rechner neu, damit die Änderungen wirksam werden.
Reply With Quote
  #17  
Old April 24th, 2017, 17:03
Mel Mel is offline
Erfahrener Benutzer
 
Join Date: 09-15-09
Posts: 1,874
Default

Quote:
Originally Posted by derniwi View Post
Oder man bräuchte also auch ein eigenes Verzeichnis, sagen wir mal analog zum EXTERN$-Ordner auf dem DSM-Server. Dieses wird dann auch an die Clients synchronisiert.
dann hast du wieder das problem, daß alle clients dasselbe bekommen obwohl eigentlich nur die testgruppe die neue version kriegen soll und die buchhaltung wegen irgnedwas auf der vorletzten version bleiben will etc...

Quote:
Originally Posted by derniwi View Post
Und wie macht man das mit der Variablenübergabe?
mir gings nur um die Abgrenzung zu
Code:
CallFunctionPackage('<PaketGuid>','<Revision>')
aber ja, parameter wären da natürlich schon hilfreich...

Quote:
Originally Posted by derniwi View Post
Ja, RunEScript ist eine Notlösung.

Auf der anderen Seite: was versprecht Ihr Euch von Funktionen, was man nicht mit anderen Skriptsprachen wie VB oder PowerShell lösen kann? Oder besser hierfür einen anderen Thread eröffnen?

Ich bin nicht sehr tief in der PowerShell--Programmierung drin, eher auf den CMD-Skripten stehen geblieben , nutze auch VB, wenn mir das hilft. Aber ganz klar, eScript hat viele Einschränkungen und manche Dinge darüber zu lösen ist mega aufwendig. Und PS oder VB kann das dann als relativ kurzes Skript, und dann auch noch schnell abgearbeitet...
ob in dem anderen script jetzt ein escript, ein powershellscript oder eine exe drin ist, ist erstmal sekundär, das interessante ist, daß ich sachen aus einem paket in einem/mehreren anderen paketen nutzen kann.

wobei: wenn du escript hast, dann ist es ein einzeiler eines der anderen zu starten, aber wenn du eines der anderen hast, dann ist es schwer ein escript zu starten wenn du halt doch was brauchst, was in escript einfacher ist.

wenn du nur etwas starten willst, dann ist das im zweifelsfall
Code:
GetPackagePath('%InstallationParameters.OSSetupFilePckgLink%','PackagePath',)
ExecuteEx('%PackagePath%\Extern$\Setup.exe /auto upgrade /noreboot','ExitCode','120')
Reply With Quote
  #18  
Old April 25th, 2017, 08:31
derniwi derniwi is offline
Erfahrener Benutzer
 
Join Date: 02-15-12
Posts: 1,654
Default

Quote:
Originally Posted by Mel View Post
dann hast du wieder das problem, daß alle clients dasselbe bekommen obwohl eigentlich nur die testgruppe die neue version kriegen soll und die buchhaltung wegen irgnedwas auf der vorletzten version bleiben will etc...
Das ist wahr...

Quote:
Originally Posted by Mel View Post
mir gings nur um die Abgrenzung zu
Code:
CallFunctionPackage('<PaketGuid>','<Revision>')
aber ja, parameter wären da natürlich schon hilfreich...

Quote:
Originally Posted by Mel View Post
ob in dem anderen script jetzt ein escript, ein powershellscript oder eine exe drin ist, ist erstmal sekundär, das interessante ist, daß ich sachen aus einem paket in einem/mehreren anderen paketen nutzen kann.
OK, dann hatte ich das initial nicht ganz richtig verstanden. Aber auch nicht schlimm, denn wenn man verschiedene Revisionen hat, sind wir ja auch irgendwie wieder beim ersten Abstatz.

Deine Idee oder Dein Wunsch ist also eine Erweiterung, so dass ein (eScript)-Paket verwendet werden kann, um dort Funktionen zu beherbergen, die dann über eine anderes Paket aufgerufen werden können. Somit ist eigentlich klar, dass hier ein neuer Pakettyp notwendig wird, denn dieses Paket wird ja nicht selbstständig ausgeführt werden können, weiterhin wird es da auch keine Deinstallation geben, ebenso kein Update usw.

Die in den Paketen enthaltenen Funktionen würden dann in der Pakacging-Workbench in einem separaten Abschnitt zu finden sein, dort evtl. noch unter dem Paketnamen gebündelt, und bei der Verwendung soll DSM selbsständig erkennen, dass dieses Funktionspaket auf den Client geladen werden muss und dies dann auch eigenständig erledigen.

Innerhalb der Funktionen sind wohl die meisten (wenn nicht gar alle) eScript-Befehl nutzbar, auch das Starten externer Programme und Skripte (CMD, VB, PS...). Parameter beim Funktionsaufruf kann man verwenden, hierbei kann man auch die Revision des Funktionspaketes auswählen.

Wie werden Variablen gehandhabt? Alle eScript-Variablen sind innerhalb der Funktion lokal, Variablen im aufrufenden Script werden nicht geändert?

Oder soll man Variablen auch im aufrufenden Script ändern oder auch erstellen können? Damit wäre es einfacher, Pakete für die eigene Umgebung anzulegen und am Anfang gleich ein
Code:
CallFunctionPackage InitializeStandort1SetupMSI('Revision1')
aufzurufen, mit dem die grundlegenden Initialisierungen für eine MSI-Installation an einem Standort durchgeführt werden können.

Rekursiver Aufruf möglich? Variablen immer noch lokal?

Installationsparameter im Funktionspaket? Würden die Sinn machen?

Klingt schon mal recht gut, vor allem auch nützlich.
__________________
Sie haben die Maus bewegt. Bitte starten Sie den Rechner neu, damit die Änderungen wirksam werden.
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 19:55.

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