xbast1x
Goto Top

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

Content-Key: 465612

Url: https://administrator.de/contentid/465612

Ausgedruckt am: 28.09.2022 um 14:09 Uhr

Mitglied: SeaStorm
SeaStorm 24.06.2019 um 08:37:27 Uhr
Goto Top
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?
Mitglied: xbast1x
xbast1x 24.06.2019 um 08:42:09 Uhr
Goto Top
Wie oben beschrieben, haben wir damit unter Windows 10 massiv Probleme.

Das Logonskript wird im Userkontext ausgeführt.
Mitglied: SlainteMhath
SlainteMhath 24.06.2019 um 09:09:08 Uhr
Goto Top
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
Mitglied: xbast1x
xbast1x 24.06.2019 um 09:48:13 Uhr
Goto Top
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ß
Mitglied: SeaStorm
SeaStorm 24.06.2019 um 09:54:52 Uhr
Goto Top
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.
Mitglied: xbast1x
xbast1x 24.06.2019 um 10:00:40 Uhr
Goto Top
Leider hilft "Update" ebenfalls nicht, so hatten wir es schon standardmäßig face-wink
Mitglied: erikro
erikro 24.06.2019 um 10:55:41 Uhr
Goto Top
Moin,

Zitat von @xbast1x:
da sich die per GPO gemappten Laufwerke bei allen Usern schließen

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
Mitglied: IceBeer
IceBeer 24.06.2019 aktualisiert um 11:14:26 Uhr
Goto Top
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
Mitglied: xbast1x
xbast1x 24.06.2019 um 12:34:02 Uhr
Goto Top
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.
Mitglied: ChriBo
ChriBo 24.06.2019 um 13:19:17 Uhr
Goto Top
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
Mitglied: Datick
Datick 24.06.2019 um 13:30:50 Uhr
Goto Top
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ß
Mitglied: emeriks
emeriks 25.06.2019 aktualisiert um 09:04:19 Uhr
Goto Top
Hi,
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.
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.
Mitglied: emeriks
emeriks 25.06.2019 aktualisiert um 09:04:43 Uhr
Goto Top
Hi,
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.

Fährst Du noch ein Auto oder mit einem Bus oder Bahn von gestern? Falls ja, zuerst: Sowas macht man aber nicht ... face-wink

E.
Mitglied: IceBeer
IceBeer 25.06.2019 um 12:19:47 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 25.06.2019 um 13:11:17 Uhr
Goto Top
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. face-wink

UAC kann man hier ausschließen.
  1. greift UAC beim NTFS-Zugriff nur für lokale Ordner und Dateien. Beim Zugriff auf Freigaben greift es nicht.
  2. damit zusammenhängend hat es keinen Einfluß auf net use
  3. das Script (die Batch) liegt laut TO im NETLOGON. Also Freigabe, also kein UAC-Problem.
Mitglied: IceBeer
IceBeer 25.06.2019 aktualisiert um 13:30:10 Uhr
Goto Top
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
Mitglied: emeriks
emeriks 25.06.2019 um 14:11:00 Uhr
Goto Top
Zitat von @IceBeer:
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..."
Mitglied: IceBeer
Lösung IceBeer 25.06.2019 um 14:53:10 Uhr
Goto Top
Hallo

Zitat von @emeriks:

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
Mitglied: emeriks
Lösung emeriks 25.06.2019 aktualisiert um 15:07:46 Uhr
Goto Top
So, jetzt bin ich bei Dir. face-smile
Also erstens, diesen Artikel kannte ich noch nicht. Er ist ja auch schon etwas älter ... face-smile

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.
Mitglied: xbast1x
xbast1x 26.06.2019 um 11:14:28 Uhr
Goto Top
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
Mitglied: xbast1x
xbast1x 28.06.2019 um 12:31:32 Uhr
Goto Top
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.
Mitglied: xbast1x
xbast1x 01.07.2019 aktualisiert um 09:07:02 Uhr
Goto Top
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.