GPO Batch Startscripts unter Windows 7 nicht mehr möglich?

Alle Antworten

• 

  

  0

  Anmelden

  Moin,

  Am 30.07.2010 17:37, schrieb Hannes Schurig:

  sind Batch Startscripts via GPO unter Windows 7 noch möglich?

  ja problemlos.

  Ich habe hier W7 Clients, die über eine GPO Startscripts ausführen
  sollen, es aber nicht tun. GPO ->  Computer ->  Windows ->
  Startscripts ->  3 .bat Scripte und eine .exe Anwendung

  und  "Anmeldescripts gleichzeitig ausführen" ist aktiviert?
  sollte, quasi ein Muss.

  - UAC deaktiviert (Windows GUI und Registry)

  ... danach neugestartet, sonst ist es nicht aus.

  Tschö
  Mark

  ---

  Mark Heitbrink - MVP Windows Server - Group Policy

  Homepage:    www.gruppenrichtlinien.de - deutsch
  NNTP Bridge: http://communitybridge.codeplex.com/releases

  • Als Antwort markiert Norbert-FehlauerModerator Montag, 18. Juli 2011 09:50

  Mittwoch, 4. August 2010 20:35

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  und  "Anmeldescripts gleichzeitig ausführen" ist aktiviert?
  sollte, quasi ein Muss.

  Als Leser von Gruppenrichtlinien.de gehören "Computer\Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten", "Computer\Anmeldeskripts gleichzeitig ausführen", "Computer\Startscripts sichtbar ausführen", "Benutzer\Zugriff auf Eingabeaufforderung verhindern" (Deaktiviert), "Benutzer\Anmeldeskripts gleichzeitig ausführen", "Benutzer\Anmeldeskripts sichtbar ausführen" zum Standard. Testweise auch "Computer\Maximale Wartezeit für Gruppenrichtlinienskripts" auf 0 (Unendlich) gestellt.

  - UAC deaktiviert (Windows GUI und Registry)

  ... danach neugestartet, sonst ist es nicht aus.

  Deaktiviert, Neustart, Registry geprüft (beide Werte waren auf deaktiviert gestellt), noch ein Neustart, das ganze an 2 Clients.

   

  Ich teste heute ein .exe Programm, das einfach den ersten Parameter ausführt. Like: "execute.exe -C:\test.bat" und da .exe Files ausgeführt werden hoffe ich, dass ich somit auch Batch Scripte gestartet kriege. Mal sehen.

  Wenn gar nichts geht, beraten Sie Unternehmen bei Problemfällen? :D

   

  Edit:

  http://weizenspr.eu/2010/runas-fur-normale-dokumente-anwenden/ - "\\serverpfad\execute.exe \\serverpfad\test.bat" funktioniert im Administratorkonto einwandfrei, test.bat wird ausgeführt. Als Startscript passiert nichts beim Client. Gruppenrichtlinie wurde übernommen (gpresult stimmt).

  Also müssen die Clients irgendein Problem mit .bat Files an sich haben. Windows 7 Enterprise N, ist das irgendwie eingeschränkt abgesehen von den Multimiediasachen? 

   

  Edit 2:

  Ein Kumpel programmiert mir gerade ein .exe Programm, das beliebige .bat Scripte aus dem Parameter Zeile für Zeile einliest und mit system("[zeile]"); ausführt. Das hat mit einem simplen echo Script funktioniert. Eine sinnvolle Lösung ist das natürlich nicht.

   

  Edit 3:

  Ich sitz hier ja in einem Institut der Humboldt Universität von Berlin. Vielleicht wurde im Rechenzentrum eine Art Block eingerichtet, der alle Windows 7 Computer betrifft und die Ausführung von Batches verhindert. Muss ich mal im Rechenenzentrum nachfragen, wir nutzen ja die Humboldt-typische Windows Domäne, da ist das vielleicht integriert.

  Donnerstag, 5. August 2010 09:13

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Am 05.08.2010 schrieb Hannes Schurig:

  Als Leser von Gruppenrichtlinien.de gehören "Computer\Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten", "Computer\Anmeldeskripts gleichzeitig ausführen", "Computer\Startscripts sichtbar ausführen", "Benutzer\Zugriff auf Eingabeaufforderung verhindern" (Deaktiviert), "Benutzer\Anmeldeskripts gleichzeitig ausführen", "Benutzer\Anmeldeskripts sichtbar ausführen" zum Standard. Testweise auch "Computer\Maximale Wartezeit für Gruppenrichtlinienskripts" auf 0 (Unendlich) gestellt.

  Das kann von uns niemand wisse. ;)

  Edit:
  
  http://weizenspr.eu/2010/runas-fur-normale-dokumente-anwenden/ - "\\serverpfad\execute.exe \\serverpfad\test.bat" funktioniert im Administratorkonto einwandfrei, test.bat wird ausgeführt. Als Startscript passiert nichts beim Client. Gruppenrichtlinie wurde übernommen (gpresult stimmt).

  Computerstartscript? Wenn ja, sind denn auch die Authentifizierten
  Benutzer berechtigt lesend auf die o.g. Freigabe zuzugreifen? Da sind
  auch die Computerkonten enthalten.

  Also müssen die Clients irgendein Problem mit .bat Files an sich haben. Windows 7 Enterprise N, ist das irgendwie eingeschränkt abgesehen von den Multimiediasachen? 

  Nein, das ist das gleiche Windows 7 wie ohne N. Fehlermeldungen im
  Ereignisprotokoll?`

  Servus
  Winfried

  ---

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

  Donnerstag, 5. August 2010 16:32

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Das kann von uns niemand wisse. ;)

  Wie gruselig wär das denn auch?! ;)

  Computerstartscript? Wenn ja, sind denn auch die Authentifizierten Benutzer berechtigt lesend auf die o.g. Freigabe zuzugreifen? Da sind auch die Computerkonten enthalten.

  Authentifizierte Benutzer haben Ändern-Rechte auf den komplette Ordner "GPOs_Install", in dem sich alles abspielt, was mit GPOs zu tun hat. Das wird auch korrekt nach unter vererbt und ein Test mit effektiven Berechtigungen für ein beliebiges Computer/Nutzerobjekt war in beiden Fällen positiv, Änderungsrechte stehen. Wie im ersten Post auch erwähnt:

  Die .exe Anwendung (als letzter Eintrag) wird bei jedem Systemstart einwandfrei ausgeführt, die 3 Scripte nicht.

  Also von den 4 Startscripten ist 1 Eintrag (der letzte) ein .exe Programm. Es liegt im selben Ordner wie die .bat Startscripte und wird einwandfrei von (fast) jedem PC ausgeführt. Selbe Rechte etc. Strange thing.

  Nein, das ist das gleiche Windows 7 wie ohne N. Fehlermeldungen im
  Ereignisprotokoll?`

  Das dacht ich mir ^^

  Ich bin mittlerweile echt soweit, dass ich nach meinem Urlaub nächste Woche mal mit meinem Chef sprechen werde ob wir nicht einen externen Experten herholen. Das kann ja nun echt nicht sein, dass ich seit einer Woche keine Lösung dafür finde. .bat Startscripte sind nicht lebensnotwendig aber in vielen Fällen einfach mal unbeschreiblich brauchbar von daher würde ich das Problem wirklich gerne lösen und zwar ohne noch eine weitere Woche damit zu verbringen. Mal sehen was er meint.
  Consulting Angebote nehme ich gerne entgegen ;)

  Freitag, 6. August 2010 09:53

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  ...Ich bin mittlerweile echt soweit, dass ich nach meinem Urlaub nächste Woche mal mit meinem Chef sprechen werde ob wir nicht einen externen Experten herholen. Das kann ja nun echt nicht sein, dass ich seit einer Woche keine Lösung dafür finde. .bat Startscripte sind nicht lebensnotwendig aber in vielen Fällen einfach mal unbeschreiblich brauchbar von daher würde ich das Problem wirklich gerne lösen und zwar ohne noch eine weitere Woche damit zu verbringen. Mal sehen was er meint.
  Consulting Angebote nehme ich gerne entgegen ;)

  
  @Hannes Schurig

  Das Problem liegt zwar schon etwa ein Jahr zurück,, dennoch würde mich interessieren ob es gelöst wurde?

  Unser Lösungsansatz wäre folgender gewesen:

  Als Skript wird für die .bat Files folgendes übergeben:

  Skriptname: C:\Windows\system32\cmd.exe

  Scriptparameter: /c UNC-Pfad zu der jeweilgen .bat

  So führen wir unsere An- und Abmeldescripte aus die auf .bat basieren.

  Wie ich gesehen habe, hattest Du dies bereits versucht. Hast Du das /c ... als Parameter übergeben oder ebenfalls bei Skriptname mit eingetragen. Der Pfad C:\Wi...\...\cmd.exe ist ebenfalls wichtig. Nur cmd.exe als Skriptname funktioniert nicht.

   

  Gruß

  Markus Pauly

  
  
  

  • Bearbeitet Markus Pauly Mittwoch, 16. November 2011 11:14

  Mittwoch, 16. November 2011 11:06

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hatte das gleiche Problem!

  Der Tipp von Markus Pauly hat bei uns funktioniert!

  Skriptname: C:\Windows\system32\cmd.exe

  Scriptparameter: /c UNC-Pfad zu der jeweilgen .bat

  Freitag, 13. Februar 2015 14:43

  Antworten

  |

  Zitieren