2
GPO - Startskript wird nicht ausgeführt - timeout bei der Ausführung
Hallo,
ich habe ein Skript geschrieben, das auf sämtlichen Server (2003 (R2), 2008 (R2)) ausgeführt werden muss. Im Hintergrund wird eine Applikation installiert (während dem Startvorgang) und anschließend müssen einige Dateien ausgetauscht und Anpassungen vorgenommen werden - Alles automatisiert. Das Skript läuft wunderbar auf den 2003 und 2008 Server durch (manuelle Ausführung). Sobald das Skript jedoch per GPO als Startskript angegeben wird, brauchen meine (Test-)Server verdammt lange um hochzufahren. Das Skript wurde anfangs per PowerShell (2008R2 AD) Startup Skript verknüpft. Da allerdings die PowerShell Startupskripte erst ab Win7 und 2008R2 unterstützt werden, wird das Skript nicht auf 2003 Maschinen ausgeführt.
Wird das Skript über eine Batch (.cmd) aufgerufen, dann wird es bei manueller Ausführung durchgeführt und macht das was es soll. Wird es per GPO an alle Server verteilt (authenticated), dann benötigt die jeweilige Maschine geschätzt 5 Minuten - und das Skript wird nicht ausgeführt.
Nun habe ich in den Associations mal .ps1 und .cmd der HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Associations\ModRiskFileTypes hinzugefügt, was allerdings keine Veränderung mit sich bringt.
Ich bin jetzt irgendwie total am Ende mit meinem Latein... Fällt euch etwas ein, woran es liegen könnte?
Hiern och der Aufruf über die Batch: powershell -file [PFAD]
die execution policy ist auf unrestricted derzeit - wurde von remotesigned geändert.
Vielen Dank und Gruß,
Tobi
ich habe ein Skript geschrieben, das auf sämtlichen Server (2003 (R2), 2008 (R2)) ausgeführt werden muss. Im Hintergrund wird eine Applikation installiert (während dem Startvorgang) und anschließend müssen einige Dateien ausgetauscht und Anpassungen vorgenommen werden - Alles automatisiert. Das Skript läuft wunderbar auf den 2003 und 2008 Server durch (manuelle Ausführung). Sobald das Skript jedoch per GPO als Startskript angegeben wird, brauchen meine (Test-)Server verdammt lange um hochzufahren. Das Skript wurde anfangs per PowerShell (2008R2 AD) Startup Skript verknüpft. Da allerdings die PowerShell Startupskripte erst ab Win7 und 2008R2 unterstützt werden, wird das Skript nicht auf 2003 Maschinen ausgeführt.
Wird das Skript über eine Batch (.cmd) aufgerufen, dann wird es bei manueller Ausführung durchgeführt und macht das was es soll. Wird es per GPO an alle Server verteilt (authenticated), dann benötigt die jeweilige Maschine geschätzt 5 Minuten - und das Skript wird nicht ausgeführt.
Nun habe ich in den Associations mal .ps1 und .cmd der HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Associations\ModRiskFileTypes hinzugefügt, was allerdings keine Veränderung mit sich bringt.
Ich bin jetzt irgendwie total am Ende mit meinem Latein... Fällt euch etwas ein, woran es liegen könnte?
Hiern och der Aufruf über die Batch: powershell -file [PFAD]
die execution policy ist auf unrestricted derzeit - wurde von remotesigned geändert.
Vielen Dank und Gruß,
Tobi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 163703
Url: https://administrator.de/contentid/163703
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
2 Kommentare
Neuester Kommentar
Nutz die Policyeinstellung, Startskripte sichtbar auszuführen und schau, was passiert.
Hallo!
An diese Option habe ich auch vor kurzem gedacht und siehe da:
PowerShell Skripte, die über vbs/cmd oder sonst wie aufgerufen werden und NICHT lokal liegen, somit also ausschließlich auf dfs shares/shares bezogen, sind nicht vertrauenswürdig und müssen manuell bestätigt werden.
Das manuelle Eingreifen kann man umgehen, indem man das dfs share zu den intranet sites hinzufügt und das share somit "vertrauenswürdig" wird. Es muss hierbei unter HKLM gesetzt werden, sodass startup Skripte ausgeführt werden können.
HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\NEUER SCHLÜSSEL (In diesem Fall der Name des DFS Shares) - neuer DWORD mit dem Namen * und dem Wert 0x1
Funktioniert jetzt herrlich =)
Merci!
An diese Option habe ich auch vor kurzem gedacht und siehe da:
PowerShell Skripte, die über vbs/cmd oder sonst wie aufgerufen werden und NICHT lokal liegen, somit also ausschließlich auf dfs shares/shares bezogen, sind nicht vertrauenswürdig und müssen manuell bestätigt werden.
Das manuelle Eingreifen kann man umgehen, indem man das dfs share zu den intranet sites hinzufügt und das share somit "vertrauenswürdig" wird. Es muss hierbei unter HKLM gesetzt werden, sodass startup Skripte ausgeführt werden können.
HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\NEUER SCHLÜSSEL (In diesem Fall der Name des DFS Shares) - neuer DWORD mit dem Namen * und dem Wert 0x1
Funktioniert jetzt herrlich =)
Merci!
