cmd wird nicht mehr über GPO ausgeführt
Hallo Zusammen,
wir haben eine .cmd, die im Hintergrund beim Anmelden eines Users über GPOs gestartet wird.
Bei Win7 lief das ganze auch noch Einwandfrei. Mit dem Upgrade auf Windows 10 wird diese .cmd Datei nicht mehr ausgeführt....bzw.
unter gpresult /r oder rsop.msc noch nicht einmal mehr angzeigt...
Wenn man die .cmd per user startet, funktioniert der Script ohne Fehler und Einwandfrei mit Windows 10....nur automatisiert gibts probleme...
VG
Hanuta
wir haben eine .cmd, die im Hintergrund beim Anmelden eines Users über GPOs gestartet wird.
Bei Win7 lief das ganze auch noch Einwandfrei. Mit dem Upgrade auf Windows 10 wird diese .cmd Datei nicht mehr ausgeführt....bzw.
unter gpresult /r oder rsop.msc noch nicht einmal mehr angzeigt...
Wenn man die .cmd per user startet, funktioniert der Script ohne Fehler und Einwandfrei mit Windows 10....nur automatisiert gibts probleme...
VG
Hanuta
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 306668
Url: https://administrator.de/forum/cmd-wird-nicht-mehr-ueber-gpo-ausgefuehrt-306668.html
Ausgedruckt am: 04.04.2025 um 04:04 Uhr
21 Kommentare
Neuester Kommentar

Wenn das Skript nicht in den GPOs am Client auftaucht ist entweder die GPO falsch konfiguriert (falsche OU/ etc.pp) oder dein Client hat Probleme wenn er sich diese nicht zieht, oder keinen Zugriff auf den Skriptablageort hat.
Ebenfalls solltest du wissen das unter Windows 10 Anmeldeskripte bis zu 10 Minuten nach dem Login verspätet starten. Dazu gibt es eine extra GPO um dieses Verhalten zu steuern.
Ebenfalls werden "Startskripte" dort ebenfalls nicht getriggert wenn ein Rechner heruntergefahren und wieder gestartet wird (Stichwort: Schnellstart), das passiert dann nur bei einem "Neustart".
Gruß skybird
Ebenfalls solltest du wissen das unter Windows 10 Anmeldeskripte bis zu 10 Minuten nach dem Login verspätet starten. Dazu gibt es eine extra GPO um dieses Verhalten zu steuern.
Ebenfalls werden "Startskripte" dort ebenfalls nicht getriggert wenn ein Rechner heruntergefahren und wieder gestartet wird (Stichwort: Schnellstart), das passiert dann nur bei einem "Neustart".
Gruß skybird
Warum ich frage: Ich habe hier auf einem 2012R2 das Phänomen, das ich bei Systemstart mittels Geplantem Task eine Anwendung die x.server.exe heißt nicht ausführen kann. Wenn ich den Task unverändert lasse und die exe aaa.exe nenne, funktioniert das Einwandfrei. Eine Erklärung dafür habe ich noch nicht gefunden.

Mit dem Upgrade auf Windows 10 wird diese .cmd Datei nicht mehr ausgeführt....bzw.
"Upgrade" ist Mist! Wenn dann nur "Clean Install". Du solltest erst mal dein GPO-Problem lösen, wenn dort deine GPO auf dem Client noch nicht mal "aufgeführt" wird kann das Skript ja auch nicht ausgeführt werden.Und den Client mal aus der Domäne schmeißen das Computer-Konto im AD resetten und den Client neu einbinden. Stimmt die Uhrzeit des Client mit den DCs überein?

Was macht das Skript überhaupt ? Und was ist wenn du das Skript zusätzlich in eine schon vorhandene andere GPO steckst in dem schon ein anderes Skript aufgerufen wird ?
Wo liegt das Skript, im SYSVOL Scriptsordner ? Stimmen die Zugriffsrechte auf das Skript/Ordner/Freigabe?
Lass uns hier nicht verhungern mit, "aber hier klappts ja" das hilft ja keinem
Versorg uns lieber mit harten Fakten wie Logauszügen.
Wo liegt das Skript, im SYSVOL Scriptsordner ? Stimmen die Zugriffsrechte auf das Skript/Ordner/Freigabe?
Lass uns hier nicht verhungern mit, "aber hier klappts ja" das hilft ja keinem

Ein Software-Verteilungsskript das im Kontext des Users (Anmeldeskript) läuft??? Haben eure User Admin-Rechte um Software zu installieren??
Sowas macht man normalerweise per GPO als "Startskript" das dann mit Systemrechten arbeitet.
Ich vermute hier dann eher generelle Berechtigungs- und Verständnisprobleme.
Sowas macht man normalerweise per GPO als "Startskript" das dann mit Systemrechten arbeitet.
Ich vermute hier dann eher generelle Berechtigungs- und Verständnisprobleme.

Naja ohne genau zu wissen wie du das umgesetzt hast werden wir hier noch in 100 Jahren sitzen und uns am Kopf kratzen.
Stehen da etwa tatsächlich Passwörter im Skript?
Stehen da etwa tatsächlich Passwörter im Skript?

Dann würde ich den Prozess Dienst -> Autoinstaller(was auch immer das sein mag?!) überprüfen und an die Programmierer weitergeben, die haben genug Möglichkeiten ein Logging einzubauen, dann weist du was Sache ist, und musst nicht rumraten!