Benutzer mit den meisten Antworten
GPO, Softwareinstallation, Reihenfolge

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" /yLeider 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
Antworten
-
Hallo,
die Reihenfolge der CSEs kannst du hier nachschauen:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensionsZuerst 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
-
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
-
>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/
- Bearbeitet Matthias WolfEditor Samstag, 3. März 2012 14:09
- Als Antwort markiert -- Chris -- Montag, 5. März 2012 10:47
-
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!
- Bearbeitet Matthias WolfEditor Sonntag, 11. März 2012 18:00
- Als Antwort markiert -- Chris -- Dienstag, 13. März 2012 07:10
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/
- Bearbeitet Matthias WolfEditor Sonntag, 11. März 2012 17:42
-
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
-
> du hast recht, die Scripts CSE läuf vorher.Ja, die CSE läuft vorher - die trägt aber nur die auszuführenden Skriptein die Registry ein. Ausgeführt werden Skripte (Startup/Logon) immerNACH der Verarbeitung aller CSEs, läßt sich auch im GPO Eventlognachvollziehen. 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! -
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! -
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
-
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! -
>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/
- Bearbeitet Matthias WolfEditor Samstag, 3. März 2012 14:09
- Als Antwort markiert -- Chris -- Montag, 5. März 2012 10:47
-
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
-
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
-
>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" /yDein 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/
- Bearbeitet Matthias WolfEditor Samstag, 3. März 2012 14:18
-
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
-
Hallo,
die Reihenfolge der CSEs kannst du hier nachschauen:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensionsZuerst 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
-
Hallo Chris.HIerfindest Du die aktuelle Reihenfolge bei der CSE-Verarbeitung. Problemlosnutzen 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! -
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/ -
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!
- Bearbeitet Matthias WolfEditor Sonntag, 11. März 2012 18:00
- Als Antwort markiert -- Chris -- Dienstag, 13. März 2012 07:10
-
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 kopiertGenau, 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/ -
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!
- Bearbeitet Matthias WolfEditor Montag, 12. März 2012 12:08
-
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