gelöst Loginscript wird nicht verarbeitet
franksig (Level 1) - Jetzt verbinden
22.09.2015, aktualisiert 28.09.2015, 1769 Aufrufe, 17 Kommentare
Hallo zusammen,
Ich hab mal wieder ein leidiges Loginscriptproblem,
Ausgangslage:
es git eine GPO Namens "Loginskript-Produktion"
ich habe dort nur eine "laufwerke.bat" drin liegen die beim anmelden abgearbeitet werden soll.
es werden dort 2 Netzwerklaufwerke mittels net use verbunden.
bei der Loopbackverarbeitung habe ich "zusammenführen" ausgewählt
meldet sich jetzt ein User an bekommt er diese Laufwerke nicht.
führe ich gpresult /r unter dem User aus steht dran, dass diese Policy angewendet worden ist.
Dc ist ein Win2012R2 und der Server ebenfalls
Browse ich zum Sysvol Share des DCs in die dementsprechende GPO und klicke auf die Batchdatei doppelt werden die Laufwerke verbunden.
meine Frage nun:
hab ich was übersehen ? oder gar falsch gemacht ?
diese Einstellung habe ich garnicht
Ich hab mal wieder ein leidiges Loginscriptproblem,
Ausgangslage:
es git eine GPO Namens "Loginskript-Produktion"
ich habe dort nur eine "laufwerke.bat" drin liegen die beim anmelden abgearbeitet werden soll.
es werden dort 2 Netzwerklaufwerke mittels net use verbunden.
bei der Loopbackverarbeitung habe ich "zusammenführen" ausgewählt
meldet sich jetzt ein User an bekommt er diese Laufwerke nicht.
führe ich gpresult /r unter dem User aus steht dran, dass diese Policy angewendet worden ist.
Dc ist ein Win2012R2 und der Server ebenfalls
Browse ich zum Sysvol Share des DCs in die dementsprechende GPO und klicke auf die Batchdatei doppelt werden die Laufwerke verbunden.
meine Frage nun:
hab ich was übersehen ? oder gar falsch gemacht ?
diese Einstellung habe ich garnicht
17 Antworten
- LÖSUNG Chonta schreibt am 22.09.2015 um 09:45:40 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 09:47:42 Uhr
- LÖSUNG Chonta schreibt am 22.09.2015 um 09:57:37 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 10:11:46 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 10:44:04 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 11:34:19 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 12:19:02 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 12:50:53 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 13:34:33 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 13:45:09 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 14:18:05 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 14:59:23 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 15:01:10 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 15:21:41 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 19:58:27 Uhr
- LÖSUNG franksig schreibt am 23.09.2015 um 13:30:42 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 19:58:27 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 15:21:41 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 15:01:10 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 14:59:23 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 14:18:05 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 13:45:09 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 13:34:33 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 12:50:53 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 12:19:02 Uhr
- LÖSUNG emeriks schreibt am 22.09.2015 um 11:34:19 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 10:44:04 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 10:11:46 Uhr
- LÖSUNG Chonta schreibt am 22.09.2015 um 09:57:37 Uhr
- LÖSUNG franksig schreibt am 22.09.2015 um 09:47:42 Uhr
- LÖSUNG franksig schreibt am 28.09.2015 um 08:57:57 Uhr
LÖSUNG 22.09.2015 um 09:45 Uhr
Hallo,
Windows 8 Clients? Dann Hibernate Modus beachten und die Probleme mit Startscripten und Scripten beim Abmelden/runterfahren.
Generell ist es Besser die Laufwerke direkt über GPO zu verteilen und nicht über Script.
Ab Win7 geht es so, XP und Vista brauchen die jeweiligen Clientsideextensions.
Gruß
Chonta
Windows 8 Clients? Dann Hibernate Modus beachten und die Probleme mit Startscripten und Scripten beim Abmelden/runterfahren.
Generell ist es Besser die Laufwerke direkt über GPO zu verteilen und nicht über Script.
Ab Win7 geht es so, XP und Vista brauchen die jeweiligen Clientsideextensions.
Gruß
Chonta
LÖSUNG 22.09.2015 um 09:47 Uhr
Hallo,
danke erstmal für die schnelle Antwort.
es geht hier um einen Terminalserver wo diverse user sich anmelden.
der Terminalserver ist wie bereits geschrieben ein Win2012R2
meine erste vermutung war dass dieses Logindelay dran schuld sei, aber das ist es nicht habe ich mehrfach geprüft
danke erstmal für die schnelle Antwort.
es geht hier um einen Terminalserver wo diverse user sich anmelden.
der Terminalserver ist wie bereits geschrieben ein Win2012R2
meine erste vermutung war dass dieses Logindelay dran schuld sei, aber das ist es nicht habe ich mehrfach geprüft
LÖSUNG 22.09.2015 um 09:57 Uhr
Hallo,
stell von Script auf reine GPO Verteilung um, das ist gerade mit Windows 8+ sauberer.
Darauf achten, das die Laufwerke als Aktualisieren eingebunden sind und nicht als ersetzen.
Beim ersetzen wird die Verbindung teilweise bei GPO Aktualisierung unterbrochen und geöffnete Ordner gehen zu.
Gruß
Chonta
stell von Script auf reine GPO Verteilung um, das ist gerade mit Windows 8+ sauberer.
Darauf achten, das die Laufwerke als Aktualisieren eingebunden sind und nicht als ersetzen.
Beim ersetzen wird die Verbindung teilweise bei GPO Aktualisierung unterbrochen und geöffnete Ordner gehen zu.
Gruß
Chonta
LÖSUNG 22.09.2015 um 10:11 Uhr
Das geht nicht da ich bei einem Laufwerk den Usernamen und das Kennwort mitgeben muss und das Feld dort ist von Ms mit einem Patch deaktiviert worden.
LÖSUNG 22.09.2015 um 10:44 Uhr
mir gehts halt auch darum, warum er es nicht abarbeitet, das muss doch einen grund haben
LÖSUNG 22.09.2015, aktualisiert um 11:34 Uhr
Hi,
blöde Frage: gpresult /r hast Du in der Benutzersitzung auf dem TS ausgeführt?
Falls ja: Wenn dort steht, dass die GPO übernommen wird, dann ist das schon mal die halbe Miete.
Bau mal einen Checkpoint in die Batch ein. z.B.
Wird das Log erstellt und was steht drin.
Mal abgesehen davon: Passwörter in einer Batch mitgeben .... Da kannst Du man gleich Zugriff ohne Passwort einrichten.
E.
blöde Frage: gpresult /r hast Du in der Benutzersitzung auf dem TS ausgeführt?
Falls ja: Wenn dort steht, dass die GPO übernommen wird, dann ist das schon mal die halbe Miete.
Bau mal einen Checkpoint in die Batch ein. z.B.
01.
echo Test >>%Temp%\Checkpoint.log
02.
net use X: \\server\share /user:XXXXXXX yyyyy >>%Temp%\Checkpoint.logWird das Log erstellt und was steht drin.
Mal abgesehen davon: Passwörter in einer Batch mitgeben .... Da kannst Du man gleich Zugriff ohne Passwort einrichten.
E.
LÖSUNG 22.09.2015 um 12:19 Uhr
Hallo danke für die schnelle Antwort.
also es wird keine Log Datei erstellt
erst wenn ich das Skript über das sysvolshare ausführe
es sieht danach aus als ob nicht abgearbeitet wird
und ja das gpresult habe ich in dem benutzerkontext ausgeführt
drin steht wenn ich es "händisch" starte Befehl wurde erfolgreich ausgeführt
ich will es ja nur verstehen warum es nicht geht
also es wird keine Log Datei erstellt
erst wenn ich das Skript über das sysvolshare ausführe
es sieht danach aus als ob nicht abgearbeitet wird
und ja das gpresult habe ich in dem benutzerkontext ausgeführt
drin steht wenn ich es "händisch" starte Befehl wurde erfolgreich ausgeführt
ich will es ja nur verstehen warum es nicht geht
LÖSUNG 22.09.2015 um 12:50 Uhr
also ich in jetz so weit gekommen.
erstelle ich in der Policy einen anderen eintrag sehe ich dass dieser angewendet wird
ich habe unter benutzerkonfig\einstellungen\Windows-Einstellungen\ordner\ einen temp1 Ordner erstellen lassen -> geht bei der Anmeldung
und egal ob mein loginskript *.bat *cmd heißt es wird nicht abgearbeitet. -> komisch
es scheint so als ob die CMD oder BAT verarbeitung deaktiviert worden ist.
hat vielleicht noch jemand eine Idee ?
erstelle ich in der Policy einen anderen eintrag sehe ich dass dieser angewendet wird
ich habe unter benutzerkonfig\einstellungen\Windows-Einstellungen\ordner\ einen temp1 Ordner erstellen lassen -> geht bei der Anmeldung
und egal ob mein loginskript *.bat *cmd heißt es wird nicht abgearbeitet. -> komisch
es scheint so als ob die CMD oder BAT verarbeitung deaktiviert worden ist.
hat vielleicht noch jemand eine Idee ?
LÖSUNG 22.09.2015, aktualisiert um 13:35 Uhr
Wo ist diese CMD gespeichert?
Falls in der GPO, dann nur den Dateinamen angeben, ohne Pfad.
Falls außerhalb der GPO, z.B. im NetLogon, dann mit vollständigen Pfad angeben. \\domäne\netlogon\script.bat oder \\server\freigabe\script.bat
Falls im Netlogon: Wenn Du mehrere DC hast, und der Pfad nicht über den Namen eines DC geht (ungünstig) sondern über den der Domäne (empfohlen!), dann musst Du prüfen, ob die Replikation funktioniert und die Datei auf allen DC's im Netlogon liegt.
Falls in der GPO, dann nur den Dateinamen angeben, ohne Pfad.
Falls außerhalb der GPO, z.B. im NetLogon, dann mit vollständigen Pfad angeben. \\domäne\netlogon\script.bat oder \\server\freigabe\script.bat
Falls im Netlogon: Wenn Du mehrere DC hast, und der Pfad nicht über den Namen eines DC geht (ungünstig) sondern über den der Domäne (empfohlen!), dann musst Du prüfen, ob die Replikation funktioniert und die Datei auf allen DC's im Netlogon liegt.
LÖSUNG 22.09.2015 um 13:45 Uhr
Hallo,
also die Datei liegt in dem entsprechenden SYSVOL Ordner des DCs von dort aus kann ich sie auch starten
die replizierung funktioniert einwandfrei.
Änderungen sind in unter 2 min dort angekommen.
deswegen versteh ich das nicht
\\dc1\SYSVOL\Firma.lan\Policies\{6DB5E3AA-3B26-4DAE-BC49-5083F8F3A528}\User\Scripts\Logon\logon.bat
dortl iegen das skript und auf dem DC sein Kumpel auch
\\dc2\SYSVOL\firma.lan\Policies\{6DB5E3AA-3B26-4DAE-BC49-5083F8F3A528}\User\Scripts\Logon\logon.bat
also die Datei liegt in dem entsprechenden SYSVOL Ordner des DCs von dort aus kann ich sie auch starten
die replizierung funktioniert einwandfrei.
Änderungen sind in unter 2 min dort angekommen.
deswegen versteh ich das nicht
\\dc1\SYSVOL\Firma.lan\Policies\{6DB5E3AA-3B26-4DAE-BC49-5083F8F3A528}\User\Scripts\Logon\logon.bat
dortl iegen das skript und auf dem DC sein Kumpel auch
\\dc2\SYSVOL\firma.lan\Policies\{6DB5E3AA-3B26-4DAE-BC49-5083F8F3A528}\User\Scripts\Logon\logon.bat
LÖSUNG 22.09.2015 um 14:18 Uhr
Und in der GPO steht nur "logon.bat"? Das wäre korrekt.
LÖSUNG 22.09.2015 um 14:59 Uhr
ja so wie es sein soll
LÖSUNG 22.09.2015 um 15:01 Uhr
LÖSUNG 22.09.2015 um 15:21 Uhr
Könnte es das sein? https://rcmtech.wordpress.com/2014/01/24/logon-scripts-do-not-run-at-log ...
LÖSUNG 22.09.2015 um 19:58 Uhr
Hi,
ja das habe ich auch schon gelesen, finde aber den Eintrag in der Policy nicht.
zudem habe ich selbst mehrfach gewartet ob die vielleicht noch "kommen" aber nix
es sieht echt so aus als ob die batch kein zucker machen
ja das habe ich auch schon gelesen, finde aber den Eintrag in der Policy nicht.
zudem habe ich selbst mehrfach gewartet ob die vielleicht noch "kommen" aber nix
es sieht echt so aus als ob die batch kein zucker machen
LÖSUNG 23.09.2015 um 13:30 Uhr
mit wäre schon geholfen wie die einstellung auf deutsch heißt
LÖSUNG 28.09.2015 um 08:57 Uhr
Hall zusammen ich habe mal nachgeschaut bei einem anderen Kunden.
diese einstellung habe ich bei dieser Domäne garnicht.
kann dies evtl an dem centralstore liegen den mein Kollege eingerichtet hat ?
würde es Sinn machen die win2012R2 Policies neu herunterzuladen und drüber zu kopieren ?
diese einstellung habe ich bei dieser Domäne garnicht.
kann dies evtl an dem centralstore liegen den mein Kollege eingerichtet hat ?
würde es Sinn machen die win2012R2 Policies neu herunterzuladen und drüber zu kopieren ?
Ähnliche Inhalte
Neue Wissensbeiträge
Heiß diskutierte Inhalte
