22.11.2018, aktualisiert um 07:35:50 Uhr

8215

Drive Mapping per GPO bei lokaler Anmeldung

Hallo zusammen,

ich möchte auf einem Domänen-PC per Richtlinie ein Netzlaufwerk mappen. Dieser Rechner fährt mit einem lokalen User hoch (das soll auch so bleiben). Ich habe jetzt eine Batch Datei erstellt, welches per net use das Laufwerk mappen soll:

net use X: "´\\...\" /persistent:yes

Die Batchdatei habe ich dann per Computerrichtlinie unter Startup Scripts hinzugefügt. Die Batch liegt ebenfalls in unserem Shares Bereich. Leider wird die GPO nicht angewandt. der Rechner befindet sich in der richtigen OU und die GPO ist auch korrekt verlinkt. Führe ich die Batch lokal aus, wird das Laufwerk gemappt. Nach meinem Verständnis werden Computerrichtlininen doch bei Startup geladen unabhängig davon ob ein Domänen-User oder ein lokaler User sich anmeldet oder?

Oder wie ließe sich das besser umsetzen?

Zusammengefasst:
- PC in der Domäne
- lokaler User ohne Admin-Rechte
- Mapping auf eine Resource im Netzwerk

Später soll das auf ca. 30 weiteren Clients umgesetzt werden.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 393537

Url: https://administrator.de/forum/drive-mapping-per-gpo-bei-lokaler-anmeldung-393537.html

Ausgedruckt am: 12.04.2025 um 01:04 Uhr

28 Kommentare

Neuester Kommentar

Moin,

ich finde lokale User haben in einer Domäne nichts verloren, wozu dieses Setup?
Wenn Du überhaupt noch mit Login Skripten arbeitest, dann gehören die ins Profil (Eigenschaft der Benutzer, Anmeldskript), das geht natürlich nur für AD User.

Besser wäre es die Laufwerke direkt per GPP zu verteilen.

Gruss

Das war nicht die Frage ;)
Mir ist klar, dass das ungünstig ist. In diesem Fall ist es aber leider so.

Anmelde Scripts lassen sich auch in der Computer Configuration einrichten.

Na dann probier mal, ob das Skript ausgeführt wird, wenn ein AD User sich anmeldet...

Moin Schroedi

Zitat von @132501:

Das war nicht die Frage ;)
Mir ist klar, dass das ungünstig ist. In diesem Fall ist es aber leider so.

Aus einem lokalen Benutzer einen AD-User zu machen ist eine Sache von wenigen Minuten und schon ist das Problem gelöst.

Guten Morgen,

Zitat von @goscho:
Aus einem lokalen Benutzer einen AD-User zu machen ist eine Sache von wenigen Minuten und schon ist das Problem gelöst.

Er wird schon seine Gründe haben warum es ein lokaler User sein muss... auch wenn es weder schön noch sicherheitstechnisch Sinnvoll sein mag

Zum Problem:

Wie stellst du Fest, dass die GPO nicht angewandt wird? Per gpresult oder einfach weil die Batch nicht ausgeführt/das Laufwerk nicht gemappt wird?
Hat der lokale User genügend Rechte auf dem Netzlaufwerk?
Wie wärs wenn du die Batch per Computer-GPO auf die Rechner kopierst und dann unter HKLM\Software\Microsoft\Windows\Run in der Registry den entsprechenden Eintrag (ebenfalls per Computer-GPO) zur Ausführung der Batch erstellen lässt?

Gruß, JD

Moin,
wenn sich der locale User anmeldet,
ist ihm Deine AD-GPO so ziemlich schnurz.
Mach das ganze halt in der lokalen GPO des Rechners.

Zitat von @JohnDorian:

Guten Morgen,

Zitat von @goscho:
Aus einem lokalen Benutzer einen AD-User zu machen ist eine Sache von wenigen Minuten und schon ist das Problem gelöst.

Er wird schon seine Gründe haben warum es ein lokaler User sein muss... auch wenn es weder schön noch sicherheitstechnisch Sinnvoll sein mag

Vielleicht sind die Gründe aber unsinnig oder auf fehlendem Wissen aufgebaut. (Ist nicht persönlich gemeint).
Niemand kann immer alle Möglichkeiten kennen und Faktoren bedenken.
Deshalb halte ich es schon sinnvoll bei so etwas auch mal nachzuhaken und zu fragen warum das so gehandhabt wird obwohl es eigentlich unsinnig ist und weniger Sicherheit bietet ist.

Zitat von @132501:
Die Batchdatei habe ich dann per Computerrichtlinie unter Startup Scripts hinzugefügt. Die Batch liegt ebenfalls in unserem Shares Bereich. Leider wird die GPO nicht angewandt. der Rechner befindet sich in der richtigen OU und die GPO ist auch korrekt verlinkt. Führe ich die Batch lokal aus, wird das Laufwerk gemappt. Nach meinem Verständnis werden Computerrichtlininen doch bei Startup geladen unabhängig davon ob ein Domänen-User oder ein lokaler User sich anmeldet oder?

Der Fehler wird wohl daran liegen, dass dein Startup Script über die Computerrichtlinie mit dem Systemaccount "%computername%\system" ausgeführt wird und nicht mit deinem Lokalen Benutzeraccount.
Dieser hat gewöhnlich keine Berechtigung auf die Freigaben in der Domäne und kann das Script gar nicht lesen.

Deshalb lässt man login Scripts immer unter dem User laufen. Das wird aber in deinem Fall natürlich bei lokalen Usern auch nicht funktionieren.

Du hast entweder die Wahl das auf jedem Computer per Lokaler GPO zu machen die auf eine lokal liegende Batch zugreift (Viel Spaß das auf 30 Clients auszurollen. Dazu kommt das bei einer Änderung du alle 30 Clients händisch abändern darfst) oder man prüft mal ob der Grund warum das über Lokale User laufen soll nicht doch behebbar ist.

Hi,
Netzlaufwerke werden im Benutzerkontext verbunden. Wenn man es mit einem Startupscript verbindet, dann ist es nur für Local System verfügbar, aber nicht für die einzelnen angemeldeten Benutzer.

Du könntest die Batch per GPO/GPP "Dateien" im Computerkontext von der Freigabe auf die Rechner kopieren, in einen standardisierten Zielordner. Die lokale Benutzerkonten bekommen dann die lokale Kopie dieser Batch am Benutzerobjekt als Loginscript eingetragen.

E.

Zitat von @Bem0815:
Vielleicht sind die Gründe aber unsinnig oder auf fehlendem Wissen aufgebaut. (Ist nicht persönlich gemeint).
Niemand kann immer alle Möglichkeiten kennen und Faktoren bedenken.
Deshalb halte ich es schon sinnvoll bei so etwas auch mal nachzuhaken und zu fragen warum das so gehandhabt wird obwohl es eigentlich unsinnig ist und weniger Sicherheit bietet ist.

Hast schon recht, seh ich genau so. Aber wenn es vorher schon zwei mal erwähnt wurde hilft es dann auch nichts, es noch ein drittes Mal zu anzusprechen - vor allem wenn halt ansonsten nichts zur eigentlichen Frage beigetragen wird.
(Das riecht dann für mich immer gleich ein bisschen nach oberlehrerhaftem Klugscheißertum und Punkte-Sammelei

)

Grüße, JD

Zitat von @JohnDorian:

Guten Morgen,

Zitat von @goscho:
Aus einem lokalen Benutzer einen AD-User zu machen ist eine Sache von wenigen Minuten und schon ist das Problem gelöst.

Er wird schon seine Gründe haben warum es ein lokaler User sein muss... auch wenn es weder schön noch sicherheitstechnisch Sinnvoll sein mag

Zum Problem:

Wie stellst du Fest, dass die GPO nicht angewandt wird? Per gpresult oder einfach weil die Batch nicht ausgeführt/das Laufwerk nicht gemappt wird?
Hat der lokale User genügend Rechte auf dem Netzlaufwerk?
Wie wärs wenn du die Batch per Computer-GPO auf die Rechner kopierst und dann unter HKLM\Software\Microsoft\Windows\Run in der Registry den entsprechenden Eintrag (ebenfalls per Computer-GPO) zur Ausführung der Batch erstellen lässt?

Gruß, JD

Führe ich net use in der CMD.exe lokal im Kontext des lokalen Benutzers auf dem PC aus, wird das Laufwerk problemlos gemappt.
Script per GPO bei Startup klappt weder mit lokalem noch mit AD User. Ich habe es mit einem Registry Eintrag per GPO versucht, geht auch nicht.
Bei gpresult zeigt mir die Kiste an, dass gar keine GPO gezogen wird, obwohl da einige drin stehen sollten. gpresult im Kontext eines AD Users zeigt mir dann alle GPOs an

Loopback ist aktiv und steht auf Replace.

Hallo, lokale GPO. Auf dem jeweiligen Rechner. Dein lokaler User interessiert sich nicht für die AD-GPO.

Zitat von @Tektronix:

Hallo, lokale GPO. Auf dem jeweiligen Rechner. Dein lokaler User interessiert sich nicht für die AD-GPO.

Das mag bei Benutzerrichtlinien stimmen, Computerrichtlinien werden gezogen.

Zitat von @132501:
Führe ich net use in der CMD.exe lokal im Kontext des lokalen Benutzers auf dem PC aus, wird das Laufwerk problemlos gemappt.
Script per GPO bei Startup klappt weder mit lokalem noch mit AD User. Ich habe es mit einem Registry Eintrag per GPO versucht, geht auch nicht.

Du vergleichst Äppel mit Birnen. Ich habe es bereits erklärt.

Zitat von @emeriks:

Hi,
Netzlaufwerke werden im Benutzerkontext verbunden. Wenn man es mit einem Startupscript verbindet, dann ist es nur für Local System verfügbar, aber nicht für die einzelnen angemeldeten Benutzer.

Du könntest die Batch per GPO/GPP "Dateien" im Computerkontext von der Freigabe auf die Rechner kopieren, in einen standardisierten Zielordner. Die lokale Benutzerkonten bekommen dann die lokale Kopie dieser Batch am Benutzerobjekt als Loginscript eingetragen.

E.

Verstehe ich deinen Ansatz richtig müsste ich ja dennoch an jeden PC ran und das Script händisch in die lokalen GPOs packen, korrekt?

Zitat von @132501:
Verstehe ich deinen Ansatz richtig müsste ich ja dennoch an jeden PC ran und das Script händisch in die lokalen GPOs packen, korrekt?

Entweder das.
Oder am lokalen Benutzerobjekt direkt eintragen. Sowas geht auch per Startupscript.
Oder der Ansatz von @JohnDorian mit dem HKLM-Run. Diesen Wert kann man auch per GPO auf die Computer verteilen.

Grundsätzliche Frage in den Raum:
Was ist denn der Auslöser fürs ziehen der Computer-GPOs? Eine Benutzeranmeldung? Schon vorher? Wird die Computer-GPO nur beim Anmelden eines Domänen-Benutzers gezogen und gilt dann eben ab da, unabhängig von der Benutzeranmeldung?

Gruß, JD

Zitat von @emeriks:
Oder der Ansatz von @JohnDorian mit dem HKLM-Run. Diesen Wert kann man auch per GPO auf die Computer verteilen.

Genau das hatte ich ja versucht. Der Wert taucht auch in der Registry auf. Allerdings nicht das Laufwerk.

Sorry, ich bekomme graue Haare...

Computerkonfiguration oder HKEY_LOCAL_MACHINE -> Alles, was den Computer betrifft und das wird alles vor der Anmeldung abgehandelt.

Netzlaufwerke mappen ist identisch mit Standarddrucker setzen, es macht logisch keinen Sinn, das auf Computerebene zu machen. Du versucht etwas zu machen, was jeglicher Logik entbehrt und zudem fernab des Designs ist.

Und nein, du kannst in der Computerkonfiguration keine Anmeldeskripts setzen, sondern nur Startup-Skripts, das ist ein Unterschied wie Tag und Nacht.

Du hast genau eine Lösung für dein komisches Murks-Konstrukt: Du meldest dich mit deinem lokalen Benutzer an und schiebst das Login-Skript mit net use in den Autostart-Ordner des lokalen Benutzers.

Emeriks hat oben die richtige Antwort schon gegeben, der Rest vom Thread ist leider für die Tonne...

Zitat von @chgorges:

Sorry, ich bekomme graue Haare...

Computerkonfiguration oder HKEY_LOCAL_MACHINE -> Alles, was den Computer betrifft und das wird alles vor der Anmeldung abgehandelt.

Netzlaufwerke mappen ist identisch mit Standarddrucker setzen, es macht logisch keinen Sinn, das auf Computerebene zu machen. Du versucht etwas zu machen, was jeglicher Logik entbehrt und zudem fernab des Designs ist.

Und nein, du kannst in der Computerkonfiguration keine Anmeldeskripts setzen, sondern nur Startup-Skripts, das ist ein Unterschied wie Tag und Nacht.

Du hast genau eine Lösung für dein komisches Murks-Konstrukt: Du meldest dich mit deinem lokalen Benutzer an und schiebst das Login-Skript mit net use in den Autostart-Ordner des lokalen Benutzers.

Emeriks hat oben die richtige Antwort schon gegeben, der Rest vom Thread ist leider für die Tonne...

Fühlst du dich krank? Oder was stimmt mit dir nicht.
Warum ich es so machen möchte/muss wurde hier von mir nicht erklärt/begründet und hat dich auch nicht zu interessieren. Egal wie viele Best-Practice Propheten mir noch quer kommen, ich weiss das man es anders löst. Aber in diesem Fall geht es nun mal ad hoc nicht anders. Azeptiert es oder lasst es.

Ja, das Konstrukt ist murks. Aber seit 30 Jahren gewachsen und mal eben nicht in einer Stunde zu ändern. Ich sitze hier nicht in einer Schöne-Welt IT mit 20 Windows 10 Nutzern.

Wenn das Niveau der Antworten jetzt so bleibt, spart euch das getippe. An den Rest, der schon konstruktive Ideen erbracht hat -> Danke!

Teilweise muss ich chgorges Recht geben - eine Computer-Richtline kann defacto keine Aktion für einen Benutzer ausführen.
Dennoch gibt es einen Weg ans Ziel zu kommen:

Eine Computer-Richtlinie legt eine Aufgabe im Windows Task-Planer an
Trigger: Anmeldung am System, Jeder Benutzer
Aktion: cmd.exe /c "net use …"
Benutzerkonto, welches die Aufgabe ausführt: System

Ich teste das gerade, aber aus meiner Sicht müsste das funktionieren.
EDIT: Funktioniert natürlich nicht - siehe unten*

Gruß, JD

Zitat von @JohnDorian:

Teilweise muss ich chgorges Recht geben - eine Computer-Richtline kann defacto keine Aktion für einen Benutzer ausführen.
Dennoch gibt es einen Weg ans Ziel zu kommen:

Eine Computer-Richtlinie legt eine Aufgabe im Windows Task-Planer an
Trigger: Anmeldung am System, Jeder Benutzer
Aktion: cmd.exe /c "net use …"
Benutzerkonto, welches die Aufgabe ausführt: System

Ich teste das gerade, aber aus meiner Sicht müsste das funktionieren.

Gruß, JD

Ich habe jetzt einen Service AD-User angelegt welcher auf das Shares Verzeichnis berechtigt ist.
Den Reg Key den ich jetzt per GPO setze lautet:

net use X: "\\...\Ordner" /user:de01-svc-filesyncfs1 /persistent:yes

Der Key wird so in die Registry gesetzt und bei Startup fragt die cmd.exe richtigerweise nach dem Passwort. Gebe ich das ein mapt er das LW.
Ich muss ihm jetzt nur automatisch das Passwort mitgeben (ja ich weiss, es steht dann in Klartext in der Registry). Das Passwort einfach hinter den User zu schreiben funktioniert leider nicht. Also /user:de01-svc-filesyncfs1 PASSWORT

Zitat von @JohnDorian:

Teilweise muss ich chgorges Recht geben - eine Computer-Richtline kann defacto keine Aktion für einen Benutzer ausführen.
Dennoch gibt es einen Weg ans Ziel zu kommen:

Eine Computer-Richtlinie legt eine Aufgabe im Windows Task-Planer an
Trigger: Anmeldung am System, Jeder Benutzer
Aktion: cmd.exe /c "net use …"
Benutzerkonto, welches die Aufgabe ausführt: System

Ich teste das gerade, aber aus meiner Sicht müsste das funktionieren.
EDIT: Funktioniert natürlich nicht - siehe unten*

Der Befehl wird dann ja immernoch unter dem für den Task hinterlegten User ausgeführt. Der Benutzer, der sich gerade anmeldet dient ja nur als Trigger. D.h. das Netzlaufwerk kann auch hier nicht gemappt werden.

Gruß, JD

Zitat von @132501:
Genau das hatte ich ja versucht. Der Wert taucht auch in der Registry auf. Allerdings nicht das Laufwerk.

OK.
Ansatz:
Lass eine Batch starten, die lokale abgelegt ist. Verteile das auch per GPO. Lass diese Batch ein Logfile schreiben, z.B.

echo %date% %time% >>C:\temp\test.log

Dann gpupdate und dann anmelden.
Wenn das funktioniert, dann packst Du den "net use" Befehl in diese Batch.

Am Rande: Das " vor dem "net use" und - wie ich vermute - auch am Ende der Zeile muss weg.

Zitat von @132501:
Wenn das Niveau der Antworten jetzt so bleibt, spart euch das getippe. An den Rest, der schon konstruktive Ideen erbracht hat -> Danke!

Deine Frage wurde (unter anderem auch von mir) aber auch schon mehrfach beantwortet. ;)

Computerrichtlinien werden bereits vor der Anmeldung vom Systemkonto ausgeführt, nicht vom Benutzerkonto.
Es würden also theoretisch die Laufwerke auf einen anderen Benutzer (System) eingebunden und nicht auf den Benutzer der sich danach letztendlich anmeldet.

Selbst wenn das script dann also durchlaufen würde könnte der User die Laufwerke nicht sehen da sie nur für den System Benutzer eingebunden werden.
Da aber wahrscheinlich zusätzlich noch das Systemkonto ggfs. gar keinen Zugriff auf die Freigabe haben sollte (je nachdem wie du es eingestellt hast) dürfte hier auch das Script selbst schon nicht durchlaufen. Ändert aber eigentlich hier dann eh nichts mehr am Ergebnis.

Die Startup Scripts bei den Computerrichtlinien ermöglichen hier also das ausführen von Scripten die z.B. unter dem Konto System dann Dienste starten könnten oder ähnliches. Es kann aber nichts unter dem Benutzer gestartet werden. Dinge wie Laufwerkseinbindungen sind hier also schon by Design nicht möglich. Daran lässt sich auch nichts rütteln.

Nach meiner Auffassung wirst du also wie gesagt alle Computer anfassen müssen. Es sei denn es kennt jemand einen funktionierenden Workaround der diese Limitierung irgendwie umgehen kann.

Das ist dann aber ein Fall der sehr knifflig ist, viel Gehirnschmalz und sehr kreative Ansätze benötigt.

Zitat von @132501:
Fühlst du dich krank? Oder was stimmt mit dir nicht.

Die Wahrheit durchtreibt mich, sorry, manche ertragen es und manche nicht...

Warum ich es so machen möchte/muss wurde hier von mir nicht erklärt/begründet und hat dich auch nicht zu interessieren. Egal wie viele > Best-Practice Propheten mir noch quer kommen, ich weiss das man es anders löst. Aber in diesem Fall geht es nun mal ad hoc nicht anders.

Falsch verstanden, es interessiert mich in der Tat nicht, wieso du einen lokalen User in einer Domäne anmeldest (habe ich auch nirgends geschrieben), aber es funktioniert per Microsoft-Design nicht und nicht auf Grund von deinen Best-Practise-Propheten.
Bei deinem Vorhaben gibt es kein Richtig oder Falsch, oder Weg A und B, sondern nur 0 und 1. Und dein Vorhaben ist der Schalter 0, da es in der Microsoft-Architektur nicht vorgesehen ist, da von Benutzern benutzbare Netzwerlaufwerke nur im Benutzerkontext eingebunden werden können.
Und wenn das von einem lokalen Benutzer aus passieren soll, dann nur per Turnschuhadministration.

Oder, Insider, du hast rein zufällig nen OPSI-Server, damit könntest du via Logon-Agent die Netzlaufwerke automatisiert auch bei lokalen Benutzern laden.

Genauso wie der User-Registry-Hive (für dich: die Datei NTUser.dat im jeweiligen User-Root-Profil) erst nach der Anmeldung von Windows geladen wird, weil es, Wahnsinn, natürlich erst dann Sinn macht. Und da tauchen auch erst die User-Settings á la Standarddrucker, Netzlaufwerke, etc., auf!

Dein Vorhaben ist nicht fern von Best Practise, das ist fern vom Microsoft-Design, das sollte dir jetzt hoffentlich klar sein, zumal ich nicht der Einzige bin, der dir das in zahlreichen Anläufen versucht, klar zu machen.

Wenn das Niveau der Antworten jetzt so bleibt, spart euch das getippe. An den Rest, der schon konstruktive Ideen erbracht hat -> Danke!

Siehe oben, welcher Niveauverstoß? Das ist meine subjektive Meinung, die nicht verboten ist, aber es werden hier Microsoft-Grundsätze und Basics missachtet, was Fakt ist.

Zumal ich dir auch einen konstruktiven Lösungsansatz noch mitgeliefert habe, aber Emotionen sind in 2018 doch einfach immer erhabener...

Habe es jetzt durch den Registry Eintrag gelöst. Danke an emeriks...

Thema ist erledigt. Danke.

Wie genau hat das jetzt funktioniert? Über den Reg-Eintrag in HKLM\Software\Microsoft\Windows\CurrentVersion\Run und dann eben mit der richtigen Formulierung?

Gruß, JD