none
GPO, Softwareinstallation, Reihenfolge RRS feed

  • Frage

  • Hallo zusammen,

    wir verteilen unsere Software über AD und GPO. Funktioniert soweit so gut. Jetzt habe ich eine Software die sich nach dem ersten Aufruf die aktuellen DLLs vom Server herunterläd und eine Konfigdatei im Softwareverzeichnis benötigt!

    Ich habe daher ein Computer Startup Script erstellt, dass mir die Berechtigung Jeder Full für diese Software setzt und eine Config Datei kopiert!

    icacls "C:\Program Files (x86)\SoftwareXY" /grant jeder:(OI)(Ci)(M) /T
    copy "Win.exe.config" "C:\Program Files (x86)\SoftwareXY\Win.exe.config" /y

    Leider wird das Startup Script offensichtlich vor der Softwareinstallation durchgeführt und ich benötige eine zweiten Reboot!

    Wo kann ich diese beide Vorgänge durchführen, dass sie nach der Softwareinstallation durchgeführt werden.


    Chris

    Freitag, 2. März 2012 11:28

Antworten

  • Hallo,

    die Reihenfolge der CSEs kannst du hier nachschauen:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

    Zuerst laufen die Administrativen Vorlagen, dann der Rest sortiert nacht Namen.

    Schau dir doch trotzdem einmal das MSI File an.

    Dort kannst du relativ einfach ein Script integrieren.

    (wird hier erklärt: http://sourceforge.net/apps/mediawiki/localupdatepubl/index.php?title=Creating_Configuration_files_during_installation)

    MSI Editoren gibt es wie Sand am Meer:

    http://www.installsite.org/pages/en/msi/authoring.htm
    http://blog.stealthpuppy.com/applications/free-msi-editor-insted/


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: http://matthiaswolf.blogspot.com/

    • Als Antwort markiert -- Chris -- Montag, 5. März 2012 10:47
    Montag, 5. März 2012 10:20
    Beantworter
  • Am 03.03.2012 12:14, schrieb tron2010:

    sorry aber für was steht CSE?

    Client Side Extension

    Das, was der tatsächliche Inhalt ist und am Client durch eine DLL über
    die winlogon.exe ausgeführt wird.

    Es gibt nicht "die" Gruppenrichtlinie. "Die" Gruppenrichtlinie ist eine
    Hülle für den Transport von insgesamt 42 Funktionen (CSEs) die LOKAL am
    Client vorhanden sein müssen, um die Inhalt in der "Hülle" zu
    interpretieren und die richtige Aktion auszulösen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    • Als Antwort markiert -- Chris -- Montag, 5. März 2012 10:47
    Samstag, 3. März 2012 12:21
  • >Ja, die CSE läuft vorher - die trägt aber nur die auszuführenden Skripte

    >in die Registry ein.

    Ja gut, soweit hab ich das nie runtergebrochen, weil es mir in der Regel egal
    ist wann meine Skripte ausgeführt (sobald ich dann eine Netzwerkverbindung habe, aber das ist ein anderes Thema).

    Nach einem kurzen Augenblick der Überlegung, ja auch nur das macht Sinn.
    Zumindest bei Logonscripten.
    Diese müssen im Benutzerkontext laufen und sollten ebenfalls losgetrennt vom Background-Refresh sein.

    Wie oben genannt, alle diese Änderungen gehören in eine Prozedur bei der am Ende steht,
    successful oder eben not successful.

    Aufeinander aufbauende Richtlinien gestalten deinen Prozess nur unnötig komplexer.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: http://matthiaswolf.blogspot.com/

    Freitag, 2. März 2012 22:07
    Beantworter
  • Hmm, aber nur wenn Du es als Benutzerkontext auch mit dem Haken im
    Reiter Gemeinmsam bestätigst.

     

    Genau das Gegenteil ist der Fall :-)

    Wenn du den Haken setzt, dann kannst du nur Files in Verzeichnisse kopieren, in denen auch der Benutzer Zugriff hat.

    In diesem Beispiel war es ja ""C:\Program Files (x86)\SoftwareXY".

    Hier muss also der Haken raus (was ja Standard ist). Dann wird das File als SYSTEM kopiert

    Natürlich muss dann auch sichergestellt sein, dass der "Benutzer" SYSTEM Zugriff auf die Quelle hat.

     

    Allerdings bleibt dann das Problem mit der Berechtigung.

    Mit diesem Satz war gemeint, es bleibt das Problem, dass die Berechtigung des Files nicht gesetzt wird.
    (was er ja auch vor hatte).

    ==> Ich habe daher ein Computer Startup Script erstellt, dass mir die Berechtigung Jeder Full für diese Software setzt und eine Config Datei kopiert!

     

    Es war nicht gemeint, dass das File nicht kopiert werden kann (siehe oben).

    Davon gibt es leider immer noch zu viel.

     

    Sad but true...


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!





    Sonntag, 11. März 2012 17:49
    Beantworter

Alle Antworten

  • Hallo,

    du hast recht, die Scripts CSE läuf vorher.
    Im Prinzip kann man die Reihenfolge der CSEs ändern.
    Würde ich dir aber nicht empfehlen.

    Die Files kannst du auch in der Benutzerkonfiguration verteilen (als Group Policy Preference).
    Allerdings bleibt dann das Problem mit der Berechtigung.

    Wenn du eine zuverlässige Installation haben willst, musst du das MSI File editieren und alle Kopiervorgäng und Berechtigungen hier integrieren.

    PS:

    Um welche Software handelt es sich, die im Jahre 2012 immer noch Schreibrechte im %programfiles% erfordert!?


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: http://matthiaswolf.blogspot.com/


    Freitag, 2. März 2012 11:57
    Beantworter
  • hallo matthias

    es geht hier nur um ein zentrales Config File damit nicht bei jeder installation der name des Servers angegeben werden muss. Die DLL sind Patches die nach der CD herausgekommen sind, also auch ok, da diese natürlich ins Programm Verzeichnis gehören. Das mit der Benutzerkonfiguration ist genau mein problem. Der User hat keine Schreibrechte.


    Chris

    Freitag, 2. März 2012 13:44
  •  
    > du hast recht, die Scripts CSE läuf vorher.
     
    Ja, die CSE läuft vorher - die trägt aber nur die auszuführenden Skripte
    in die Registry ein. Ausgeführt werden Skripte (Startup/Logon) immer
    NACH der Verarbeitung aller CSEs, läßt sich auch im GPO Eventlog
    nachvollziehen. Das Problem muß also woanders liegen.
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 2. März 2012 14:49
    Beantworter
  • Hallo Chris.
     
    Verteilst Du die Software im User- oder im Computerteil Deiner GPO?
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 2. März 2012 14:50
    Beantworter
  • hallo martin,

    die software wird bei uns im Computeraccount verteilt, da der user künftig keine lokalen Rechte mehr auf der Maschine hat. Es muss doch noch einen Teil oder eine Möglichkeit geben, die erst nach der Softwareinstallation ausgeführt wird in der man noch etwas kopieren usw kann, dass aber trotzdem noch im computerteil läuft?


    Chris

    Freitag, 2. März 2012 15:15
  • Hi Chris.

    die software wird bei uns im Computeraccount verteilt, da der user künftig keine lokalen Rechte mehr auf der Maschine hat. Es muss doch noch einen Teil oder eine Möglichkeit geben, die erst nach der Softwareinstallation ausgeführt wird in der man noch etwas kopieren usw kann, dass aber trotzdem noch im computerteil läuft?

    Ja, gibt es - Skripte laufen definitiv NACH MSI-Paketen. Woraus schließst Du denn, daß Dein Skript zu früh läuft? Vielleicht läuft es ja - aus ganz anderen Gründen (-: - auch gar nicht.

    mfg Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 2. März 2012 15:21
    Beantworter
  • >Ja, die CSE läuft vorher - die trägt aber nur die auszuführenden Skripte

    >in die Registry ein.

    Ja gut, soweit hab ich das nie runtergebrochen, weil es mir in der Regel egal
    ist wann meine Skripte ausgeführt (sobald ich dann eine Netzwerkverbindung habe, aber das ist ein anderes Thema).

    Nach einem kurzen Augenblick der Überlegung, ja auch nur das macht Sinn.
    Zumindest bei Logonscripten.
    Diese müssen im Benutzerkontext laufen und sollten ebenfalls losgetrennt vom Background-Refresh sein.

    Wie oben genannt, alle diese Änderungen gehören in eine Prozedur bei der am Ende steht,
    successful oder eben not successful.

    Aufeinander aufbauende Richtlinien gestalten deinen Prozess nur unnötig komplexer.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: http://matthiaswolf.blogspot.com/

    Freitag, 2. März 2012 22:07
    Beantworter
  • hallo martin,

    warum ich das schliesse? bei der ersten Installation war die Gruppe Jeder Full nicht bei dem Verzeichnis dabei. Erst nach dem nächsten Reboot.

    reden wir vom selben Script. Ich meint das Startup Script in der Computer GP

    sorry aber für was steht CSE?


    Chris

    Samstag, 3. März 2012 11:14
  • Am 03.03.2012 12:14, schrieb tron2010:

    sorry aber für was steht CSE?

    Client Side Extension

    Das, was der tatsächliche Inhalt ist und am Client durch eine DLL über
    die winlogon.exe ausgeführt wird.

    Es gibt nicht "die" Gruppenrichtlinie. "Die" Gruppenrichtlinie ist eine
    Hülle für den Transport von insgesamt 42 Funktionen (CSEs) die LOKAL am
    Client vorhanden sein müssen, um die Inhalt in der "Hülle" zu
    interpretieren und die richtige Aktion auszulösen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    • Als Antwort markiert -- Chris -- Montag, 5. März 2012 10:47
    Samstag, 3. März 2012 12:21
  • >Ich meint das Startup Script in der Computer GP

    Ja.

    Leite doch dein Script einmal in ein Textfile um, so kannst du feststellen ob es überhaupt ausgeführt wird und wenn
    ja, warum die Berechtigungen nicht gesetzt werden können.

    PS:

    icacls "C:\Program Files (x86)\SoftwareXY" /grant jeder:(OI)(Ci)(M) /T
    copy "Win.exe.config" "C:\Program Files (x86)\SoftwareXY\Win.exe.config" /y

    Dein Script ist aber nicht besonders dynamisch.
    Auf einem nicht deutschsprachigen Client funktioniert es nicht.

    Es würde sich empfehlen zum Setzen der Berechtigungen die CSE "Security" zu benutzen.
    (die aber vor der Software Installation läuft).

    http://technet.microsoft.com/en-us/library/cc756952%28v=ws.10%29.aspx


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: http://matthiaswolf.blogspot.com/




    Samstag, 3. März 2012 14:10
    Beantworter
  • Hallo ihr beiden

    ich habe jetzt eine GPP erstellt, die die erforderlichen Patches (DLLs) und das erforderliche Config File in den Ordner kopiert.

    1. PC neu installiert

    2. PC im AD in die richtig OU verschoben - PC rebooted

    3. PC installiert die Software. Melde mich dann an - freue mich dass das Verzeichnis vorhanden ist! Dann leider die Erkenntnis, es sind nur die Patch Dateien drinnen.

    vermutlich ging das Setup schief, da bereits das Verzeichnis vorhanden war. Das bedeutet, dass der GPP Copy File Job auch vor der Softwareinstallation abläuft!


    Chris

    Montag, 5. März 2012 09:43
  • Hallo,

    die Reihenfolge der CSEs kannst du hier nachschauen:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

    Zuerst laufen die Administrativen Vorlagen, dann der Rest sortiert nacht Namen.

    Schau dir doch trotzdem einmal das MSI File an.

    Dort kannst du relativ einfach ein Script integrieren.

    (wird hier erklärt: http://sourceforge.net/apps/mediawiki/localupdatepubl/index.php?title=Creating_Configuration_files_during_installation)

    MSI Editoren gibt es wie Sand am Meer:

    http://www.installsite.org/pages/en/msi/authoring.htm
    http://blog.stealthpuppy.com/applications/free-msi-editor-insted/


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: http://matthiaswolf.blogspot.com/

    • Als Antwort markiert -- Chris -- Montag, 5. März 2012 10:47
    Montag, 5. März 2012 10:20
    Beantworter
  • Hallo Chris.
     
    HIer
    findest Du die aktuelle Reihenfolge bei der CSE-Verarbeitung. Problemlos
    nutzen kannst Du außer Skripten alles, was nach Software Installation kommt.
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Montag, 5. März 2012 15:11
    Beantworter
  • Am 02.03.2012 schrieb Matthias Wolf [MVP]:

    Das Files kannst du auch in der Benutzerkonfiguration verteilen (als Group Policy Preference).
    Allerdings bleibt dann das Problem mit der Berechtigung.

    Hmm, aber nur wenn Du es als Benutzerkontext auch mit dem Haken im
    Reiter Gemeinmsam bestätigst. Ansonsten kannst Du doch auch als
    Benutzer alle möglichen Dateien kopieren, das Ziel kann natürlich auch
    %programfiles% oder ähnliches sein.

    Um welche Software handelt es sich, die im Jahre 2012 immer noch Schreibrechte im %programfiles% erfordert!?

    Davon gibt es leider immer noch zu viel.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Sonntag, 11. März 2012 13:26
  • Hmm, aber nur wenn Du es als Benutzerkontext auch mit dem Haken im
    Reiter Gemeinmsam bestätigst.

     

    Genau das Gegenteil ist der Fall :-)

    Wenn du den Haken setzt, dann kannst du nur Files in Verzeichnisse kopieren, in denen auch der Benutzer Zugriff hat.

    In diesem Beispiel war es ja ""C:\Program Files (x86)\SoftwareXY".

    Hier muss also der Haken raus (was ja Standard ist). Dann wird das File als SYSTEM kopiert

    Natürlich muss dann auch sichergestellt sein, dass der "Benutzer" SYSTEM Zugriff auf die Quelle hat.

     

    Allerdings bleibt dann das Problem mit der Berechtigung.

    Mit diesem Satz war gemeint, es bleibt das Problem, dass die Berechtigung des Files nicht gesetzt wird.
    (was er ja auch vor hatte).

    ==> Ich habe daher ein Computer Startup Script erstellt, dass mir die Berechtigung Jeder Full für diese Software setzt und eine Config Datei kopiert!

     

    Es war nicht gemeint, dass das File nicht kopiert werden kann (siehe oben).

    Davon gibt es leider immer noch zu viel.

     

    Sad but true...


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!





    Sonntag, 11. März 2012 17:49
    Beantworter
  • Am 11.03.2012 schrieb Matthias Wolf [MVP]:

    Hmm, aber nur wenn Du es als Benutzerkontext auch mit dem Haken im
    Reiter Gemeinmsam bestätigst.

     

    Genau das Gegenteil ist der Fall :-)

    Nein, lies einfach nochmal ganz genau auf was ich mich bezogen habe.

    | > Allerdings bleibt dann das Problem mit der Berechtigung.
    | | Hmm, aber nur wenn Du es als Benutzerkontext auch mit dem Haken im
    | Reiter Gemeinmsam bestätigst.
    Jetzt klarer? ;)

    Wenn du den Haken setzt, dann kannst du nur Files in Verzeichnisse kopieren, in denen auch der Benutzer Zugriff hat.

    Ich weiß.

    In diesem Beispiel war es ja ""C:\Program Files (x86)\SoftwareXY".

    Hier muss also der Haken raus (was ja Standard ist). Dann wird das File als SYSTEM kopiert

    Genau, auch das ist mir klar.

    Allerdings bleibt dann das Problem mit der Berechtigung.

    Mit diesem Satz war gemeint, es bleibt das Problem, dass die Berechtigung des Files nicht gesetzt wird.
    (was er ja auch vor hatte).

    Von welcher Berechtigung sprichst Du? die lokalen NTFS Berchtigungen?
    Wenn es andere als die Default Einstellungen sein sollen, muß das
    natürlich per GPO oder andere Mittel angepasst werden.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Sonntag, 11. März 2012 23:31
  • Hallo Winfried,

    Nein, lies einfach nochmal ganz genau auf was ich mich bezogen habe.

    genau hier lag die Verwirrung :-)
    Ich denke jetzt du hattest diese Interpretierung:

    "Allerdings bleibt dann das Problem mit der Berechtigung."

    => Es bleibt das Problem, dass die Files evtl. nicht aufgrund von fehlenden Berechtigungen kopiert werden können.
    Dies ist natürlich nur der Fall wenn der Haken des Benutzerkontext gesetzt ist.

    => richtig hier stimmt deine Aussage

    Als Du geschrieben hast:
    "Hmm, aber nur wenn Du es als Benutzerkontext auch mit dem Haken im
    Reiter Gemeinmsam bestätigst."

    Dachte ich wiederum, dir wäre evtl. der Umstand mit dem Benutzer SYSTEM nicht klar.

    Um die Verwirrung aufzulösen, mein ursprünglicher Satz hätte so lauten sollen:

    Die Files kannst du auch in der Benutzerkonfiguration verteilen (als Group Policy Preference).
    Allerdings bleibt dann das Problem, dass dir hierbei die Berechtigung der Files nicht wie gewünscht gesetzt werden.

    Ich würde sagen, Problem gelöst, Verwirrung perfekt => abgeschlossen :-)


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!




    Montag, 12. März 2012 11:58
    Beantworter
  • danke allen nochmals für die vielen Tipps. Das mit dem kopieren (GPO) in der User Configuration war mir auch neu, dass hier der SYSTEM verwendet wird ist natürlich sehr sehr hilfreich.

    Das hätte ich ohne euch gar nicht getestet bzw. ausprobiert!


    Chris

    Dienstag, 13. März 2012 07:13