11
Netwerkpfad (kein Laufwerk!) per GPO verteilen
Hallo zusammen,
ich versuche grad unsere Netzlaufwerke abzulösen gegen den (DFS) UNC Pfad. Jetzt kann man im Explorer ja per "Netzwerkadresse hinzufügen" einen neuen Ordner erstellen der sowohl unter den Netzwerkadressen als auch unter "Dieser PC seitlich erscheint.
Der erste Versuch war per GPP>Verknüpfung eine solche zu erstellen, was zwar grundsätzlich auch funktioniert, aber nur ein .lnk ist, was dann unter "Dieser PC" nicht erscheint und zudem noch im Explorer "hässlich" ist hier in rötlich als "DFSLnk":
Das was Windows hingegen erstellt, erscheint an beiden Orten und wäre mir entsprechend lieber.
Nach ein bisschen graben hat sich das von Windows erstellte als normaler Ordner herausgestellt, der ReadOnly ist und eine desktop.ini so wie eine .lnk zum Ziel enthält.
Jetzt meine eigentliche Frage:
Wie kann ich das denn halbwegs verwaltbar per GPO verteilen?
Bisher kann ich mir 2 Varianten aus den Fingern saugen:
-Ein Powershellscript mit allen vor und Nachteilen und vor allem einem ziemlichen Aufwand, damit es mir bisher vorhandenen Shares wieder aushängt, wenn der User keine Berechtigung mehr darauf hat. Und eigentlich will ich keine Loginscripts mehr haben...
-Manuell die Objekte in den GPPs erstellen. Bedeutet: Ordner erstellen und 2 Dateien erstellen. Allen 3 dann jeweils mit viel manuellem Aufwand die entsprechenden Einstellungen zusammenklicken inkl. dem Item-level targeting. Und grad bei letzterem werde ich etwas abgeschreckt. Ich will eigentlich nicht pro Mapping 3 Objekte + Einstellungen anfassen müssen. Bei ca 100 Targets klick ich mich da blöd und dabei werden Fehler passieren.
Leider ist nur das Bereitstellen des DFS Root-Namespaces keine Option
Die Kollegen steigen mir aufs Dach, wenn sie sich immer durch die Ordner klicken müssen.
Wie löst ihr das? Irgendwie finde ich da nichts zufriedenstellendes
Gruss Sea
ich versuche grad unsere Netzlaufwerke abzulösen gegen den (DFS) UNC Pfad. Jetzt kann man im Explorer ja per "Netzwerkadresse hinzufügen" einen neuen Ordner erstellen der sowohl unter den Netzwerkadressen als auch unter "Dieser PC seitlich erscheint.
Der erste Versuch war per GPP>Verknüpfung eine solche zu erstellen, was zwar grundsätzlich auch funktioniert, aber nur ein .lnk ist, was dann unter "Dieser PC" nicht erscheint und zudem noch im Explorer "hässlich" ist hier in rötlich als "DFSLnk":
Das was Windows hingegen erstellt, erscheint an beiden Orten und wäre mir entsprechend lieber.
Nach ein bisschen graben hat sich das von Windows erstellte als normaler Ordner herausgestellt, der ReadOnly ist und eine desktop.ini so wie eine .lnk zum Ziel enthält.
Jetzt meine eigentliche Frage:
Wie kann ich das denn halbwegs verwaltbar per GPO verteilen?
Bisher kann ich mir 2 Varianten aus den Fingern saugen:
-Ein Powershellscript mit allen vor und Nachteilen und vor allem einem ziemlichen Aufwand, damit es mir bisher vorhandenen Shares wieder aushängt, wenn der User keine Berechtigung mehr darauf hat. Und eigentlich will ich keine Loginscripts mehr haben...
-Manuell die Objekte in den GPPs erstellen. Bedeutet: Ordner erstellen und 2 Dateien erstellen. Allen 3 dann jeweils mit viel manuellem Aufwand die entsprechenden Einstellungen zusammenklicken inkl. dem Item-level targeting. Und grad bei letzterem werde ich etwas abgeschreckt. Ich will eigentlich nicht pro Mapping 3 Objekte + Einstellungen anfassen müssen. Bei ca 100 Targets klick ich mich da blöd und dabei werden Fehler passieren.
Leider ist nur das Bereitstellen des DFS Root-Namespaces keine Option
Die Kollegen steigen mir aufs Dach, wenn sie sich immer durch die Ordner klicken müssen.Wie löst ihr das? Irgendwie finde ich da nichts zufriedenstellendes
Gruss Sea
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: 526796
Url: https://administrator.de/forum/netwerkpfad-kein-laufwerk-per-gpo-verteilen-526796.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
11 Kommentare
Neuester Kommentar
Hi
darf man fragen warum? Gerade DFS macht es doch einfach auch im Hintergrund die Ressourcen zu wechseln und wenn alle Benutzer das auf den gleichen Buchstaben gemapped haben gibt es auch keine Verlinkungprobleme.
Ich kenne deine DFS Struktur nicht, aber wir haben mehrere DFS-Root Verzeichnisse und geben die erste Ordnerebene vor, alles was dann darunter passiert z.B. "1_Verkauf\" ist Sache der Abteilung, wenn die sich das selbst vermurksen ist das nicht mehr unser Problem :>. Das einzige was die nicht können, auf keinen Fileserver, ist: Berechtigungen und Rechte anpassen.
Gruß
@clSchak
PS: ich würde auch behaupten das einige Programme mit UNC Pfaden Probleme haben, also wenn das kein Laufwerksbuchstabe gesetzt ist
darf man fragen warum? Gerade DFS macht es doch einfach auch im Hintergrund die Ressourcen zu wechseln und wenn alle Benutzer das auf den gleichen Buchstaben gemapped haben gibt es auch keine Verlinkungprobleme.
Ich kenne deine DFS Struktur nicht, aber wir haben mehrere DFS-Root Verzeichnisse und geben die erste Ordnerebene vor, alles was dann darunter passiert z.B. "1_Verkauf\" ist Sache der Abteilung, wenn die sich das selbst vermurksen ist das nicht mehr unser Problem :>. Das einzige was die nicht können, auf keinen Fileserver, ist: Berechtigungen und Rechte anpassen.
Gruß
@clSchak
PS: ich würde auch behaupten das einige Programme mit UNC Pfaden Probleme haben, also wenn das kein Laufwerksbuchstabe gesetzt ist
Hi,
ja, ja, der Teufel "Loginscript" ... Besser keine Lösung als ein Loginscript, hm?
Ich würde mir ein solches Script erstellen. Dann dieses Script so universell schreiben, dass es einfach die Gruppenmitgliedschaft des Benutzers auswertet. Dann eine Namenskonvention für entsprechende Gruppen, z.B. "Explorer_Shortcuts_{Name}". Im Beschreibungsfeld der Gruppe den UNC ablegen. Jetzt muss man nur einen Benutzer zu einer solche Gruppe hinzufügen oder entfernen, um den Shortcut zu erstellen oder löschen. das Script könnte etwa wie folgt vorgehen:
So ähnlich machen wir das z.B. mit Netzlaufwerken.
E.
ja, ja, der Teufel "Loginscript" ... Besser keine Lösung als ein Loginscript, hm?
Ich würde mir ein solches Script erstellen. Dann dieses Script so universell schreiben, dass es einfach die Gruppenmitgliedschaft des Benutzers auswertet. Dann eine Namenskonvention für entsprechende Gruppen, z.B. "Explorer_Shortcuts_{Name}". Im Beschreibungsfeld der Gruppe den UNC ablegen. Jetzt muss man nur einen Benutzer zu einer solche Gruppe hinzufügen oder entfernen, um den Shortcut zu erstellen oder löschen. das Script könnte etwa wie folgt vorgehen:
- alle Gruppen nach festgelegtem Schema abfragen, incl. Beschreibung
- Benutzer nicht drin --> Shortcut vorhanden --> Shortcut löschen
- Benutzer drin --> Shortcut nicht vorhanden --> Shortcut erstellen
So ähnlich machen wir das z.B. mit Netzlaufwerken.
E.
Hi
Aber das bleibt ja so nicht.
Dann will die Abteilung X noch ein Laufwerk was auf \\domain\namespace\Standort\Abteilung\ zeigt. Weil sich da jedes mal nach unten durchzuklicken ist (verständlicherweise) ätzend.
Und die Abteilung HR dann eh auch. Ist klar. Karen will das ...
Und dann haben nur die Leute in den Abteilungen diese Laufwerksbuchstaben. Und die Verlinken jetzt mal wieder eine Datei im Excel\PDF\etc und linken da auf Y:\WichtigesZeug.xls .
Der Arme Sea hat aber kein Laufwerk Y: . Oder Sein Y: Zeigt ganz woanders hin und damit funktioniert der Spass nicht.
Das ist eine niemals endende Diskussion und macht elends viele Probleme. Deshalb wollen wir so weit es geht auf Buchstaben verzichten.
Wir haben \\Domain\dfs1\Standort\Abteilung\....
Ziel ist es, die Entsprechenden Abteilungen direkt beim User einzuhängen, so das er nur noch das sieht was er wirklich braucht und die Struktur so Flach wie möglich bleibt. (So viel zur Theorie ;) )
darf man fragen warum? Gerade DFS macht es doch einfach auch im Hintergrund die Ressourcen zu wechseln und wenn alle Benutzer das auf den gleichen Buchstaben gemapped haben gibt es auch keine Verlinkungprobleme.
Genau darum. Wenn man durchsetzen könnte "alle haben das Laufwerk X: und das mapped auf \\domain\namespace\" dann wäre alles super.Aber das bleibt ja so nicht.
Dann will die Abteilung X noch ein Laufwerk was auf \\domain\namespace\Standort\Abteilung\ zeigt. Weil sich da jedes mal nach unten durchzuklicken ist (verständlicherweise) ätzend.
Und die Abteilung HR dann eh auch. Ist klar. Karen will das ...
Und dann haben nur die Leute in den Abteilungen diese Laufwerksbuchstaben. Und die Verlinken jetzt mal wieder eine Datei im Excel\PDF\etc und linken da auf Y:\WichtigesZeug.xls .
Der Arme Sea hat aber kein Laufwerk Y: . Oder Sein Y: Zeigt ganz woanders hin und damit funktioniert der Spass nicht.
Das ist eine niemals endende Diskussion und macht elends viele Probleme. Deshalb wollen wir so weit es geht auf Buchstaben verzichten.
Ich kenne deine DFS Struktur nicht, aber wir haben mehrere DFS-Root Verzeichnisse und geben die erste Ordnerebene vor, alles was dann darunter passiert z.B. "1_Verkauf\" ist Sache der Abteilung, wenn die sich das selbst vermurksen ist das nicht mehr unser Problem :>.
Ich beneide dich Wir haben \\Domain\dfs1\Standort\Abteilung\....
Ziel ist es, die Entsprechenden Abteilungen direkt beim User einzuhängen, so das er nur noch das sieht was er wirklich braucht und die Struktur so Flach wie möglich bleibt. (So viel zur Theorie ;) )
Das einzige was die nicht können, auf keinen Fileserver, ist: Berechtigungen und Rechte anpassen.
So auch bei unsPS: ich würde auch behaupten das einige Programme mit UNC Pfaden Probleme haben, also wenn das kein Laufwerksbuchstabe gesetzt ist
Ja wird sicher das eine oder andere Programm geben. Aber die paar User bekommen dann halt einen Buchstaben der nur dafür da ist.so das er nur noch das sieht was er wirklich braucht
Schau mal ABE.
und bei DFS kannst noch "enable access-based enumeration for this namespace" dann sehen die Leute nur die Ordner wo auch die Rechte vorhanden sind. Du kannst den "Mountpunkt" ja auch tiefer setzen bei dem Mapping der Laufwerke,
Das mit dem klicken ist in meinen Augen nur Bequemlichkeit, die können sich das selbst via Rechtsklick "senden an Desktop" einen Link setzen, aber naja, jede Firma ist und "tickt" da anders
Und ja wir haben "Glück" damit, da wir die Freiheit haben das vorzugeben und das auch zum Teil "ohne Rücksicht auf Verluste" weil sich "Eigenlösungen" immer als Fehlerhaft/-anfällig erwiesen haben, vor allem wenn etwas Abteilungs- oder Niederlasungsübergreifend bearbeitet werden soll.
Klar hat alles seine Vor- und Nachteile, wenn man als "neuer" aber erst in dutzenden Standorten nach Daten suchen muss für einen Kunden, wäre mir das zu nervig
Wir haben natürlich auch Niederlassungspezifische Shares, die sind aber im Root verankert
\\dfs-root\konzernfreigabe\niederlassung\Niederlassung1\
Das Ganze dann bei jedem als Z:\ eingehangen ab \konzernfreigabe, wenn jemand was in seiner Niederlassung ablegen will, muss er den Weg gehen, der ist aber für alle gleich, da gibt es keine Ausnahmen, alleine schon weil zum Teil in der ERP auf die Pfade verlinkt wird.
Einheitliche Lösungen, egal auf welchem Weg, lassen sich deutlich einfacher und besser administrieren und alle reden vom gleichen
Just my 2 Cent
Das mit dem klicken ist in meinen Augen nur Bequemlichkeit, die können sich das selbst via Rechtsklick "senden an Desktop" einen Link setzen, aber naja, jede Firma ist und "tickt" da anders
Und ja wir haben "Glück" damit, da wir die Freiheit haben das vorzugeben und das auch zum Teil "ohne Rücksicht auf Verluste" weil sich "Eigenlösungen" immer als Fehlerhaft/-anfällig erwiesen haben, vor allem wenn etwas Abteilungs- oder Niederlasungsübergreifend bearbeitet werden soll.
Klar hat alles seine Vor- und Nachteile, wenn man als "neuer" aber erst in dutzenden Standorten nach Daten suchen muss für einen Kunden, wäre mir das zu nervig
Wir haben natürlich auch Niederlassungspezifische Shares, die sind aber im Root verankert
\\dfs-root\konzernfreigabe\niederlassung\Niederlassung1\
Das Ganze dann bei jedem als Z:\ eingehangen ab \konzernfreigabe, wenn jemand was in seiner Niederlassung ablegen will, muss er den Weg gehen, der ist aber für alle gleich, da gibt es keine Ausnahmen, alleine schon weil zum Teil in der ERP auf die Pfade verlinkt wird.
Einheitliche Lösungen, egal auf welchem Weg, lassen sich deutlich einfacher und besser administrieren und alle reden vom gleichen
Just my 2 Cent
Moin,
Gruß,
Dani
Dann will die Abteilung X noch ein Laufwerk was auf \\domain\namespace\Standort\Abteilung\ zeigt. Weil sich da jedes mal nach unten durchzuklicken ist (verständlicherweise) ätzend.
Und die Abteilung HR dann eh auch. Ist klar. Karen will das ...
Und dann haben nur die Leute in den Abteilungen diese Laufwerksbuchstaben. Und die Verlinken jetzt mal wieder eine Datei im Excel\PDF\etc und linken da auf Y:\WichtigesZeug.xls .
Der Arme Sea hat aber kein Laufwerk Y: . Oder Sein Y: Zeigt ganz woanders hin und damit funktioniert der Spass nicht.
Das ist eine niemals endende Diskussion und macht elends viele Probleme. Deshalb wollen wir so weit es geht auf Buchstaben verzichten.
das Wunschkonzert spielt täglich im SWR4 Bodensee Raido. Wenn ihr natürlich in dessen Nähe den Stammsitz oder Niederlassung hast, sieht es schlecht aus. Und die Abteilung HR dann eh auch. Ist klar. Karen will das ...
Und dann haben nur die Leute in den Abteilungen diese Laufwerksbuchstaben. Und die Verlinken jetzt mal wieder eine Datei im Excel\PDF\etc und linken da auf Y:\WichtigesZeug.xls .
Der Arme Sea hat aber kein Laufwerk Y: . Oder Sein Y: Zeigt ganz woanders hin und damit funktioniert der Spass nicht.
Das ist eine niemals endende Diskussion und macht elends viele Probleme. Deshalb wollen wir so weit es geht auf Buchstaben verzichten.
Einheitliche Lösungen, egal auf welchem Weg, lassen sich deutlich einfacher und besser administrieren und alle reden vom gleichen.
so ist es. Die Erfahrung hat sicher jeder schon einmal gemacht. Das habe ich bei uns als zweites abgeschafft, dass sich jedes Team etwas wünschen darf. Gerade die Zeit der ITler ist kostbar und sollte nicht für solche Pseudoprobleme verschwendet werden. Höchstens ihr seid überbesetzt, dann habe ich nichts gesagt. Gruß,
Dani
Jo Jungs ist schon klar. ABE ist schon lange aktiviert, ändert ja aber nichts daran das es gewisse Vorgaben und Erwartungen gibt. Wie wir alle wissen, ist die IT nur in wenigen Firmen ein Entscheidungsträger. Selbst wenn, würde ich das gerne so lösen, da ich hier den Service für die Anwender doch ziemlich erhöhen kann, wenn ich da per Richtlinie jedem sein Share einhänge das er in den allermeisten Fällen braucht. Und das, ohne irgendwelche gammeligen Laufwerksbuchstaben zu verwenden.
Hat noch jemand eine Idee zur eigentlichen Frage? Kann ja nicht der erste sein, der das in schön haben will
Hat noch jemand eine Idee zur eigentlichen Frage? Kann ja nicht der erste sein, der das in schön haben will
Habe gerade angefangen ein PS Script zu erstellen das mir gleich die GPO entsprechend modifiziert.
Dabei bin ich über https://github.com/jperryNPS/GroupPolicyNetworkLocations gestolpert, was das schon kann \o/
Zumindest ein erster schneller Test in der Testumgebung hat funktioniert.
Dabei bin ich über https://github.com/jperryNPS/GroupPolicyNetworkLocations gestolpert, was das schon kann \o/
Zumindest ein erster schneller Test in der Testumgebung hat funktioniert.
Zitat von @SeaStorm:
Und das, ohne irgendwelche gammeligen Laufwerksbuchstaben zu verwenden.
Hat noch jemand eine Idee zur eigentlichen Frage? Kann ja nicht der erste sein, der das in schön haben will
Und das, ohne irgendwelche gammeligen Laufwerksbuchstaben zu verwenden.
Hat noch jemand eine Idee zur eigentlichen Frage? Kann ja nicht der erste sein, der das in schön haben will
Manche Admins muss man nicht verstehen. Das es etliche Programme gibt, die den Laufwerksbuchstaben brauchen, weil sie kein UNC unterstützen weißt du, oder?
Was spricht denn ausser deinem subjektiven Empfinden gegen Netzlaufwerke?
Das einfachste ist doch GPP Laufwerkszuordnung mit Benutzerbezogener Verteilung.
Moin,
bin mir nicht ganz sicher obs funktioniert
Du erstellst irgendwo öffentlich für jede "Verknüpfung" einen Ordner mit den beiden dateien darin.
Jeder Ordner bekommt seine eigene lesen-Gruppe.
AnmeldeScript robocopy /mir
Möchte nun ein User eine Netzwerkverknüpfung haben musst du ihn nur in die entsprechende Lesegruppe packen. robocopy kopiert nur das was es (als User ausgeführt) auch lesen kann. (Und löscht worauf der Nutzer keine Rechte mehr hat)
Statt Anmeldescript kannste eventuell auch über gpp den Ornder mit den Netzwerkverknüpfungen erst leeren und mit copy neu füllen. Ein lnk und ein ini sind ja nicht so groß dass es nennenswert traffic gibt
bin mir nicht ganz sicher obs funktioniert
Du erstellst irgendwo öffentlich für jede "Verknüpfung" einen Ordner mit den beiden dateien darin.
Jeder Ordner bekommt seine eigene lesen-Gruppe.
AnmeldeScript robocopy /mir
Möchte nun ein User eine Netzwerkverknüpfung haben musst du ihn nur in die entsprechende Lesegruppe packen. robocopy kopiert nur das was es (als User ausgeführt) auch lesen kann. (Und löscht worauf der Nutzer keine Rechte mehr hat)
Statt Anmeldescript kannste eventuell auch über gpp den Ornder mit den Netzwerkverknüpfungen erst leeren und mit copy neu füllen. Ein lnk und ein ini sind ja nicht so groß dass es nennenswert traffic gibt
Hi
Aber wie es aussieht habe ich mit dem Tool oben eine Lösung. Ich werde das Ding wohl so umbiegen, das es die GPP Objekte nicht mit Update anlegt sondern mit Replace/Remove item when it is no longer applied. Damit habe ich dann meine Wunsch-Lösung, die nur per GPPs arbeitet, recht simpel verwaltbar ist und die Shares auch wieder aushängt, wenn die Berechtigung weg ist.
Das Projekt ist zwar in VB geschrieben, aber da muss ich dann wohl mal ein Auge zudrücken
Du erstellst irgendwo öffentlich für jede "Verknüpfung" einen Ordner mit den beiden dateien darin.
Jeder Ordner bekommt seine eigene lesen-Gruppe.
Möchte nun ein User eine Netzwerkverknüpfung haben musst du ihn nur in die entsprechende Lesegruppe packen. robocopy kopiert nur das was es (als User ausgeführt) auch lesen kann. (Und löscht worauf der Nutzer keine Rechte mehr hat)
Statt Anmeldescript kannste eventuell auch über gpp den Ornder mit den Netzwerkverknüpfungen erst leeren und mit copy neu füllen. Ein lnk und ein ini sind ja nicht so groß dass es nennenswert traffic gibt
Ja so hatte ich das auch schon getestet. Funktioniert zwar, bedingt aber das ausführen von Scripts. Und wenn ich es vermeiden kann, will ich logonscripts vermeiden.Jeder Ordner bekommt seine eigene lesen-Gruppe.
Möchte nun ein User eine Netzwerkverknüpfung haben musst du ihn nur in die entsprechende Lesegruppe packen. robocopy kopiert nur das was es (als User ausgeführt) auch lesen kann. (Und löscht worauf der Nutzer keine Rechte mehr hat)
Statt Anmeldescript kannste eventuell auch über gpp den Ornder mit den Netzwerkverknüpfungen erst leeren und mit copy neu füllen. Ein lnk und ein ini sind ja nicht so groß dass es nennenswert traffic gibt
Aber wie es aussieht habe ich mit dem Tool oben eine Lösung. Ich werde das Ding wohl so umbiegen, das es die GPP Objekte nicht mit Update anlegt sondern mit Replace/Remove item when it is no longer applied. Damit habe ich dann meine Wunsch-Lösung, die nur per GPPs arbeitet, recht simpel verwaltbar ist und die Shares auch wieder aushängt, wenn die Berechtigung weg ist.
Das Projekt ist zwar in VB geschrieben, aber da muss ich dann wohl mal ein Auge zudrücken
