22
Windows 10 Logonskript greift nicht
Hallo zusammen,
da sich die per GPO gemappten Laufwerke bei allen Usern schließen und das Problem sich nicht lösen lässt, wollen wir den Weg mittels Logonskript gehen. Lokal funktioniert das Skript ohne Probleme. Per GPO allerdings, wird es nicht ausgeführt.
Laut gpresult wird die GPO angewandt. Ich habe die Anmeldeverzögerung bereits deaktiviert bzw. zum Test auf 0 gesetzt. Ebenfalls getestet, wenn die Pfade in " " stehen. Das Skript liegt im Netlogonverzeichnis. Die Berechtigungen passen.
Gruß xbast1x
da sich die per GPO gemappten Laufwerke bei allen Usern schließen und das Problem sich nicht lösen lässt, wollen wir den Weg mittels Logonskript gehen. Lokal funktioniert das Skript ohne Probleme. Per GPO allerdings, wird es nicht ausgeführt.
Laut gpresult wird die GPO angewandt. Ich habe die Anmeldeverzögerung bereits deaktiviert bzw. zum Test auf 0 gesetzt. Ebenfalls getestet, wenn die Pfade in " " stehen. Das Skript liegt im Netlogonverzeichnis. Die Berechtigungen passen.
@echo off
net use E: /delete
net use J: /delete
net use K: /delete
net use M: /delete
net use Q: /delete
net use R: /delete
net use E: \\Server\alt-daten\ENTW
net use J: \\Server\jenasurgical
net use K: \\Server\ALT-DATEN\KON
net use M: \\Server\ALT-DATEN\Marketing
net use Q: \\Server\ALT-DATEN\ALLE\QM
net use R: \\Server\ALT-DATEN\ALLE\Regulatory AffairsGruß xbast1x
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: 465612
Url: https://administrator.de/forum/windows-10-logonskript-greift-nicht-465612.html
Ausgedruckt am: 23.12.2024 um 02:12 Uhr
22 Kommentare
Neuester Kommentar
Hi
zuerst: Man macht das nicht mehr per Logonscript. Dafür gibt es seit langem die Group Policy Preferences, die sowas zuverlässiger und flexibler lösen.
in welchem Kontext wird das Script ausgeführt? User oder Computer?
zuerst: Man macht das nicht mehr per Logonscript. Dafür gibt es seit langem die Group Policy Preferences, die sowas zuverlässiger und flexibler lösen.
in welchem Kontext wird das Script ausgeführt? User oder Computer?
Wie oben beschrieben, haben wir damit unter Windows 10 massiv Probleme.
Das Logonskript wird im Userkontext ausgeführt.
Das Logonskript wird im Userkontext ausgeführt.
Moin,
1. Wenn die GPO das Script nicht ausführen kann, steht der Grund dafür im Eventlog
2. Zumindest Zeile 13 wird dir (Space im Sharennamen) auf einen Fehler laufen
3. Kann denn der Benutzer das Script "händisch" also per Doppelklick ausführen? Erfolgreich?
4. Auch mit dem Script wirst du das gleiche Problem haben wie mit der GPO (Ordner schliessen sich automatisch)
lg,
Slainte
1. Wenn die GPO das Script nicht ausführen kann, steht der Grund dafür im Eventlog
2. Zumindest Zeile 13 wird dir (Space im Sharennamen) auf einen Fehler laufen
3. Kann denn der Benutzer das Script "händisch" also per Doppelklick ausführen? Erfolgreich?
4. Auch mit dem Script wirst du das gleiche Problem haben wie mit der GPO (Ordner schliessen sich automatisch)
lg,
Slainte
3. per Doppelklick kann das Script ausgeführt werden. Alle Laufwerke werden korrekt gemapped
4. Warum meinst du, entsteht durch das Skript das gleiche Verhalten? Die Laufwerke, welche durch die GPO gemapped sind, schließen sich, da der GPO Abgleich im Hintergrund stattfindet (auch wenn wir diesen per GPO deaktivieren ändert sich das Verhalten nicht).
Gruß
4. Warum meinst du, entsteht durch das Skript das gleiche Verhalten? Die Laufwerke, welche durch die GPO gemapped sind, schließen sich, da der GPO Abgleich im Hintergrund stattfindet (auch wenn wir diesen per GPO deaktivieren ändert sich das Verhalten nicht).
Gruß
Hast du "Replace" verwendet? ist ein übliches Problem. Verwende "Update", dann passiert das nicht.
Hast halt nur das Problem, das ein Laufwerk nicht Verschwindet, wenn ein User nicht mehr in der entsprechenden Gruppe ist.
Hast halt nur das Problem, das ein Laufwerk nicht Verschwindet, wenn ein User nicht mehr in der entsprechenden Gruppe ist.
Leider hilft "Update" ebenfalls nicht, so hatten wir es schon standardmäßig 
Moin,
Das heißt genau was? Die Laufwerke sind beim Anmelden nicht vorhanden oder die Verbindung bricht während der Arbeit ab?
IMHO der falsche Weg. Ich würde immer den Fehler suchen, warum das mit dem GPOs nicht klappt. Eigentlich ist das nämlich der sicherere und stabilere Weg, um LW-Buchstaben den Freigaben zuzuweisen.
Oblogatorische Frage: Die GPO "Beim Start und Anmelden auf das Netzwerk warten" ist aktiviert?
Liebe Grüße
Erik
Das heißt genau was? Die Laufwerke sind beim Anmelden nicht vorhanden oder die Verbindung bricht während der Arbeit ab?
und das Problem sich nicht lösen lässt, wollen wir den Weg mittels Logonskript gehen.
IMHO der falsche Weg. Ich würde immer den Fehler suchen, warum das mit dem GPOs nicht klappt. Eigentlich ist das nämlich der sicherere und stabilere Weg, um LW-Buchstaben den Freigaben zuzuweisen.
Lokal funktioniert das Skript ohne Probleme. Per GPO allerdings, wird es nicht ausgeführt.
Oblogatorische Frage: Die GPO "Beim Start und Anmelden auf das Netzwerk warten" ist aktiviert?
Liebe Grüße
Erik
Hallo Zusammen,
auch wenn ich der Meinung bin man sollte herrausfinden warum es mit der GPO nicht funktioniert, denke ich dein Problem "versteckt" sich in der UAC.
Es ist spekualtiv, aber:
Ich vermute mal die Benutzer haben auf den Rechnern Adminrechte
--> Logon-Skripte laufen mit den maximal verfügbaren Rechten --> Adminrechte
--> Der Explorer läuft mit den minimalen Rechten --> Benutzerrechte
Das kannst du mit "net use" in einer administrativen Eingabeaufforderung prüfen. Ich denke in der administrativen Eingabeaufforderung sind die Laufwerke verbunden.
Gruß Martin
auch wenn ich der Meinung bin man sollte herrausfinden warum es mit der GPO nicht funktioniert, denke ich dein Problem "versteckt" sich in der UAC.
Es ist spekualtiv, aber:
Ich vermute mal die Benutzer haben auf den Rechnern Adminrechte
--> Logon-Skripte laufen mit den maximal verfügbaren Rechten --> Adminrechte
--> Der Explorer läuft mit den minimalen Rechten --> Benutzerrechte
Das kannst du mit "net use" in einer administrativen Eingabeaufforderung prüfen. Ich denke in der administrativen Eingabeaufforderung sind die Laufwerke verbunden.
Gruß Martin
Ich stimme euch zu, was die Problemlösung angeht. Wir brauchen jedoch eine brauchbare Überbrückung, deshalb der Weg mit dem Logonskript.
Die Laufwerke sind verbunden und haben kein rotes X. Mehrmals am Tag schließen sich geöffnete Dateien, vermutlich genau dann, wenn der GPO Refresh im Hintergrund durchgeführt wird.
Beim Start auf das Netzwerk warten ist aktiv.
Die Laufwerke sind verbunden und haben kein rotes X. Mehrmals am Tag schließen sich geöffnete Dateien, vermutlich genau dann, wenn der GPO Refresh im Hintergrund durchgeführt wird.
Beim Start auf das Netzwerk warten ist aktiv.
Hi,
1. leite die Ausgaben doch mal in eine Datei um:
Eg.:
net use E: /delete >c:\logon.log
net use J: /delete >>c:\logon.log
...
2. Zur "Sichherheit wüde ich die Freigabe ...\Regulatory Affairs nach ...\Regulatory_Affairs oä umbenennen
CH
1. leite die Ausgaben doch mal in eine Datei um:
Eg.:
net use E: /delete >c:\logon.log
net use J: /delete >>c:\logon.log
...
2. Zur "Sichherheit wüde ich die Freigabe ...\Regulatory Affairs nach ...\Regulatory_Affairs oä umbenennen
CH
Hallo,
zum Refresh: in der Regel sollten doch die GPO's dabei nicht neu angewendet werden. Es passiert nur ein Abgleich ob neue GPO's hinzugekommen sind. Nur ein Neustart/ Neuanmeldung oder ein 'gpupdate /force' erzwingt das alle erneut angewendet werden.
Setze die Aktion in der GPO doch mal auf "löschen" und verwende im nächsten Durchlauf "Erstellen".
Objekte werden wirlich nur erstellt. Ist das Objekt schon vorhanden, wird es nicht aktualisiert, bzw. geändert. Vielleicht ist es dann stabil.
Gruß
zum Refresh: in der Regel sollten doch die GPO's dabei nicht neu angewendet werden. Es passiert nur ein Abgleich ob neue GPO's hinzugekommen sind. Nur ein Neustart/ Neuanmeldung oder ein 'gpupdate /force' erzwingt das alle erneut angewendet werden.
Setze die Aktion in der GPO doch mal auf "löschen" und verwende im nächsten Durchlauf "Erstellen".
Objekte werden wirlich nur erstellt. Ist das Objekt schon vorhanden, wird es nicht aktualisiert, bzw. geändert. Vielleicht ist es dann stabil.
Gruß
Hi,
Lass das Script irgendwas anderes tun, woran man erkennen kann, ob es denn überhaupt ausgeführt wurde. z.B. eben eine Log-Datei erstellen. Wobei ich jetzt nicht c:\ wählen würde sondern %TEMP%, aber egal.
Erst wenn Du weißt, dass das Script ausgeführt wird, dann kannst Du darüber nachdenken, warum das net use nicht funktioniert.
E.
Zitat von @ChriBo:
1. leite die Ausgaben doch mal in eine Datei um:
Eg.:
net use E: /delete >c:\logon.log
net use J: /delete >>c:\logon.log
Das ist der einzige sinnvolle Ansatz hier.1. leite die Ausgaben doch mal in eine Datei um:
Eg.:
net use E: /delete >c:\logon.log
net use J: /delete >>c:\logon.log
Lass das Script irgendwas anderes tun, woran man erkennen kann, ob es denn überhaupt ausgeführt wurde. z.B. eben eine Log-Datei erstellen. Wobei ich jetzt nicht c:\ wählen würde sondern %TEMP%, aber egal.
Erst wenn Du weißt, dass das Script ausgeführt wird, dann kannst Du darüber nachdenken, warum das net use nicht funktioniert.
E.
Hi,
Fährst Du noch ein Auto oder mit einem Bus oder Bahn von gestern? Falls ja, zuerst: Sowas macht man aber nicht ...
E.
Zitat von @SeaStorm:
zuerst: Man macht das nicht mehr per Logonscript. Dafür gibt es seit langem die Group Policy Preferences, die sowas zuverlässiger und flexibler lösen.
Sorry, aber das ist schlichtweg falsch. Es ist nichts weiter als eine Alternative.zuerst: Man macht das nicht mehr per Logonscript. Dafür gibt es seit langem die Group Policy Preferences, die sowas zuverlässiger und flexibler lösen.
Fährst Du noch ein Auto oder mit einem Bus oder Bahn von gestern? Falls ja, zuerst: Sowas macht man aber nicht ...
E.
Hallo,
interessant dass mein Ansatz zu prüfen, ob das Skript "im Admin-Token" lief nicht sinnvoll ist.
Diese Prüfung ist nämlich erstmal ohne Änderungen an einem bereits vorhandenen System möglich.
Aber jeder darf seine Meinung haben.
Gruß Martin
interessant dass mein Ansatz zu prüfen, ob das Skript "im Admin-Token" lief nicht sinnvoll ist.
Diese Prüfung ist nämlich erstmal ohne Änderungen an einem bereits vorhandenen System möglich.
Aber jeder darf seine Meinung haben.
Gruß Martin
Zitat von @IceBeer:
interessant dass mein Ansatz zu prüfen, ob das Skript "im Admin-Token" lief nicht sinnvoll ist.
Diese Prüfung ist nämlich erstmal ohne Änderungen an einem bereits vorhandenen System möglich.
Aber jeder darf seine Meinung haben.
Klinkt so, als wärest Du jetzt eingeschnappt. Ich hoffe nicht. interessant dass mein Ansatz zu prüfen, ob das Skript "im Admin-Token" lief nicht sinnvoll ist.
Diese Prüfung ist nämlich erstmal ohne Änderungen an einem bereits vorhandenen System möglich.
Aber jeder darf seine Meinung haben.
UAC kann man hier ausschließen.
- greift UAC beim NTFS-Zugriff nur für lokale Ordner und Dateien. Beim Zugriff auf Freigaben greift es nicht.
- damit zusammenhängend hat es keinen Einfluß auf net use
- das Script (die Batch) liegt laut TO im NETLOGON. Also Freigabe, also kein UAC-Problem.
Hallo,
nein bin ich nicht, keine Sorge, finde solche Aussagen immer nur gefährlich und bin persönlich ein Freund von:
Erstmal in dem Zustand den ich habe prüfen, natürlich nur wenn ich dafür keine Klimmzüge machen muss.
Deine Aussage ist meiner Erfahrung nach leider falsch!
Das kannst du auch ganz einfach nachprüfen:
- Öffne eine administrative Eingabeaufforderung
- führe net use x: \\server\freigabe aus
- prüfe im Windows Explorer ob es das LW x: gibt
--> du wirst es nicht finden
In genau diese Falle (login-skript über GPO verteilt verbindet Netzlaufwerke) bin ich vor geraumer Zeit nämlich selbst getappt.
Ein Workaround, aus Sicherheitsaspekten aber zu hinterfragen, wäre support.microsoft.com/de-de/help/3035277/mapped-drives-are-not-available-from-an-elevated-prompt-when-uac-is-co
Wäre toll wenn der TO sich mal äußern würde ob meine Vermutung stimmt oder nicht, dann könnte man diese Möglichkeit einfach abhaken.
Gruß Martin
nein bin ich nicht, keine Sorge, finde solche Aussagen immer nur gefährlich und bin persönlich ein Freund von:
Erstmal in dem Zustand den ich habe prüfen, natürlich nur wenn ich dafür keine Klimmzüge machen muss.
Deine Aussage ist meiner Erfahrung nach leider falsch!
Das kannst du auch ganz einfach nachprüfen:
- Öffne eine administrative Eingabeaufforderung
- führe net use x: \\server\freigabe aus
- prüfe im Windows Explorer ob es das LW x: gibt
--> du wirst es nicht finden
In genau diese Falle (login-skript über GPO verteilt verbindet Netzlaufwerke) bin ich vor geraumer Zeit nämlich selbst getappt.
Ein Workaround, aus Sicherheitsaspekten aber zu hinterfragen, wäre support.microsoft.com/de-de/help/3035277/mapped-drives-are-not-available-from-an-elevated-prompt-when-uac-is-co
Wäre toll wenn der TO sich mal äußern würde ob meine Vermutung stimmt oder nicht, dann könnte man diese Möglichkeit einfach abhaken.
Gruß Martin
Ich schätze, da verwechselst Du etwas.
Beim von Dir genannten Szenario geht es darum, dass Netzlaufwerke aus der "normalen" Benutzerumbegung nicht verfügbar sind, wenn der Benutzer ein Programm eleviert startet. Und umgekehrt. Man kann das aber einschalten, dass es dann so ist.
Loginscript laufen aber immer nicht-eleviert, im Gegensatz zu Startup-Scripten, welche immer eleviert laufen.
Wir bei uns haben zig Loginscripte am Laufen, welche u.a. die Netzlaufwerke für die Benutzer verbinden, ohne dass wir da irgendwelche "Klimmzüge" veranstalten müssten. Das geht sofort mit den Standardeinstellungen, respektive "...immer auf das netzwerk warten..."
Beim von Dir genannten Szenario geht es darum, dass Netzlaufwerke aus der "normalen" Benutzerumbegung nicht verfügbar sind, wenn der Benutzer ein Programm eleviert startet. Und umgekehrt. Man kann das aber einschalten, dass es dann so ist.
Loginscript laufen aber immer nicht-eleviert, im Gegensatz zu Startup-Scripten, welche immer eleviert laufen.
Wir bei uns haben zig Loginscripte am Laufen, welche u.a. die Netzlaufwerke für die Benutzer verbinden, ohne dass wir da irgendwelche "Klimmzüge" veranstalten müssten. Das geht sofort mit den Standardeinstellungen, respektive "...immer auf das netzwerk warten..."
Hallo
Also wenn ich an einem Rechner (Windows 10 pro - eben probiert - Domäne grad nicht zur Hand) in:
gpedit.msc -> Benutzer -> Windows-Einstellung -> Skripts -> Anmelden
ein Skript einhänge das Netzlaufwerke anbindet dann ist das Laufwerk in einer:
- Administrative Eingabeaufforderung: vorhanden
- Normale Eingabeaufforderung: nicht vorhanden -> somit auch nicht im Windows Explorer
Ich weiß die Quelle (MS Artikel) spricht für Vista, aber meiner Beobachtung nach (siehe oben) ist dass immernoch so:
Da ich die Ausführung des TO so interpretiere, dass die GPO laut Eventlog sauber läuft aber die Laufwerke fehlen, bleibe ich bei meiner Theorie.
Aber alles Spekulation, wie im vorigen Post: Der TO soll es prüfen und dann ist es ggf. auszuschließen.
Die Klimmzüge waren auf das "prüfen" bezogen.
Gruß Martin
Zitat von @emeriks:
Loginscript laufen aber immer nicht-eleviert, im Gegensatz zu Startup-Scripten, welche immer eleviert laufen.
Loginscript laufen aber immer nicht-eleviert, im Gegensatz zu Startup-Scripten, welche immer eleviert laufen.
Also wenn ich an einem Rechner (Windows 10 pro - eben probiert - Domäne grad nicht zur Hand) in:
gpedit.msc -> Benutzer -> Windows-Einstellung -> Skripts -> Anmelden
ein Skript einhänge das Netzlaufwerke anbindet dann ist das Laufwerk in einer:
- Administrative Eingabeaufforderung: vorhanden
- Normale Eingabeaufforderung: nicht vorhanden -> somit auch nicht im Windows Explorer
Ich weiß die Quelle (MS Artikel) spricht für Vista, aber meiner Beobachtung nach (siehe oben) ist dass immernoch so:
When the administrative user logs on, Windows processes the logon scripts using the elevated token. The script actually works and maps the drive. However, Windows blocks the view of the mapped network drives because the desktop uses the limited token while the drives were mapped using the elevated token.
Da ich die Ausführung des TO so interpretiere, dass die GPO laut Eventlog sauber läuft aber die Laufwerke fehlen, bleibe ich bei meiner Theorie.
Aber alles Spekulation, wie im vorigen Post: Der TO soll es prüfen und dann ist es ggf. auszuschließen.
Die Klimmzüge waren auf das "prüfen" bezogen.
Gruß Martin
So, jetzt bin ich bei Dir. 
Also erstens, diesen Artikel kannte ich noch nicht. Er ist ja auch schon etwas älter ...
Zweitens war dann meine Aussage falsch: Auch die Login-Scripte laufen voll eleviert. --> Beim Nicht-Admin-User hat das keinen Effekt.
Drittens: Kann ich das aber hier in userer Umgebung nicht bestätigen. Wenn sich hier ein Admin-User anmeldet, dann hat er auch Zugriff auf seine Netzlaufwerke welche in Loginscripten verbunden werden. Bei Standard-Einstellungen. Versionen ab Win7/Win2008
Der Unterschied könnte sein, dass wir keine CMD für die Scripte verwenden, sondern VBS oder PS.
Also erstens, diesen Artikel kannte ich noch nicht. Er ist ja auch schon etwas älter ...
Zweitens war dann meine Aussage falsch: Auch die Login-Scripte laufen voll eleviert. --> Beim Nicht-Admin-User hat das keinen Effekt.
Drittens: Kann ich das aber hier in userer Umgebung nicht bestätigen. Wenn sich hier ein Admin-User anmeldet, dann hat er auch Zugriff auf seine Netzlaufwerke welche in Loginscripten verbunden werden. Bei Standard-Einstellungen. Versionen ab Win7/Win2008
Der Unterschied könnte sein, dass wir keine CMD für die Scripte verwenden, sondern VBS oder PS.
Ich bin gerade noch am evaluieren der gesetzten Einstellung und warte auf Feedback der Kollegen. Sobald ich etwas habe, melde ich mich wieder. Erst mal Danke für die Denkanstöße
Ich hatte zum Test die Laufwerke auf "Erstellen" gesetzt - gleicher Effekt. Der Explorer schließt sich nach einer gewissen Zeit. Ich werde am Montag die Skript Thematik testen und schauen, ob die Testdatei abgelegt wird.
Ich habe das net use Skript hinter jedem Befehl eine Datei ablegen lassen, das hat bei jedem Befehl funktioniert. Die Laufwerke wurden jedoch nicht gemapped.
Im Ereignislog wird kein Fehler und auch keine Warnung protokolliert.
Edit: Habe die Test GPO gelöscht - neu angelegt (gleiche Einstellungen) und siehe da, alles wird gemapped und ist verbunden, wie es soll.
Im Ereignislog wird kein Fehler und auch keine Warnung protokolliert.
Edit: Habe die Test GPO gelöscht - neu angelegt (gleiche Einstellungen) und siehe da, alles wird gemapped und ist verbunden, wie es soll.
