GPO NetShare pro Gruppe verbinden, allerdings viele Gruppen

[NorbertFe 2.065]

Na da kommen wir dann wieder zu meiner ersten Aussage, dass es wohl sehr viel aufwand für womöglich keinen Mehrwert wäre.

[daabm 1.366]

- Verursacht recht hohe Prozessorlast

 

Gilt nimmer seit 208R2... Wurde gefixt :cool:

Mal ne ganz andere Idee... .Schreib in adminDescription den Pfad rein und mappe per GPP mit Zielgruppenadressierung "LDAP-Abfrage" auf dieses Attribut. Geht recht einfach, und wenn Du ein gutes IDM drüber hast, sollte das dieses Attribut füttern können. Kannst auch irgendein anderes nehmen - wenn die XCH-Schemaerweiterungen da sind, gibt's genügend freie Attribute :cool:

[Gast]

Danke daabm für die Aussage zur CPU Last.

Hast  du auch noch infos zur den maximal möglichen/sinnvollen Shares?

 

Im Prinzip wäre das dann der selbe Weg nur anstatt über Zielgruppenadressierung auf eine Gruppe eben auf ein AD Attribut. Sehe hier spontan keinen Vorteil.

Oder kann ich hier eine Regel mit Variablen bauen ala "map share \\server\%attributename%"?

Das wäre natürlich nett weil dann bräuchte ich nur eine GPP Regel die alle User abdeckt.

[NorbertFe 2.065]

Erklärst du mir mal, warum du unbedingt 100te Shares anlegen willst, wenn EINS reicht? Du kannst doch in die Unterordner der Shares Mappen, wenn der Doppelklick für die Nutzer zu viel sein sollte.

 

Bye

Norbert

[daabm 1.366]

Im Prinzip wäre das dann der selbe Weg nur anstatt über Zielgruppenadressierung auf eine Gruppe eben auf ein AD Attribut. Sehe hier spontan keinen Vorteil.

Oder kann ich hier eine Regel mit Variablen bauen ala "map share \\server\%attributename%"?

 

Ja, sonst würde ich das ja nicht empfehlen. Du bräuchtest nur noch genau EIN Mapping, das eine Variable enthält. Und der inhalt dieser Variablen wird zur Laufzeit per Zielgruppenadressierung aus einem AD-Attribut gefüttert. Ich hab mal ein Buch über GPOs geschrieben, und da gibt's ein Beispiel zu Ordnerumleitung und eines zu "msds-PrimaryComputer auf älteren Betriebssystemen"; da verwende ich genau das. Funktioniert prima, wenn man ein klein wenig LDAP spricht - selfadsi hilft ggf. dabei :cool:

Und Norbert hat recht  - wozu 100 Shares , wenn ein share mit 100 Unterordnern reicht?

[Gast]

Hmm jetzt kam mir noch ne andere Möglichkeit auf den Tisch und zwar ganz OldSchool ein Logonscript .

Wie gesagt es ist auch einen Möglichkeit das Team in den AD Attributen (z.B. department) zu hinterlegen und daher wäre die Idee ein Logonscript zu bauen, dass sich das Attribut zieht und dann das net share simpel verbindet. Sprich sowas in der Richtung:

 

net share x: \\server\%department%

 

Das setzt natürlich voraus, dass das Share genau so heißt wie das hinterlegte Attribut, was aber kein Problem ist. Ich würde mir aber im Gegenzug entweder massiv viele GPP Einträge oder ABE sparen. Letzteres kann ich halt von der Performance nicht 100pro einschätzen und der User hat den (minimalen) Nachteil, dass er im gemappten Share noch den Teamordner auswählen muss.

 

Wie seht ihr das? Welche großen Nachteilej gibt es eurer Meinung nach?

[NorbertFe 2.065]

Mal ganz ehrlich, wie du die Laufwerke verbindest ist doch vollkommen Latte. Das versuche ich dir hier seit mehreren Postings zu verklickern. Wenn du die NTFS Struktur korrekt gemappt hast, hast du nur noch die Entscheidung zu treffen 100te Mappings oder 1 Mapping für alle. Was genau ist daran denn so schwer zu verstehen?

 

Bye

Norbert

[Daniel -MSFT- 129]

<Sarkasmus an>Wie wäre es, wenn Du im Logonscript die Abteilungszugehörigkeit mit if-Statements abfragst? Dann brauchst Du gar keine Variablen, sondern einfach ein paar hundert if und else und goto. Das ist dann komplementär zu deinen paar hundert Shares. Oder Du nimmst pro Abteilung einen Server. Dann hast Du zwar ein paar hundert Server, aber hey, dann brauchst Du die Performance nicht 100pro einschätzen. Hast ja nur einen Share pro Server.<Sarkasmus aus>

 

Was genau gefällt Dir denn an den Tipps nicht, die Du bisher bekommen hast? Dass bei ABE der Performance-Einfluss minimal heuzutage ist, willst Du nicht hören. Nur ein Share zu nehmen und via Variable den Unterordner (!) der einen Freigabe zu verbinden, willst Du auch nicht.

 

Vielleicht willst Du Dir auch unbedingt das Leben schwer machen. Dann hilft vielleicht obiger Tipp, wie es so richtig kompliziert, unübersichtlich, wartungsfeindlich und fehleranfällig geht

bearbeitet 14. Juli 2014 von Daniel -MSFT-

[Gast]

Kurz mal Halt.

Ich bin erstmal sehr dankbar für die ganzen Vorschläge. Ich versuche hier nur so viel Input wie möglich zu bekommen, um für mein System die best Mögliche Lösung zu finden.

Alle Tipps/Lösungsvorschläge bisher waren schon super, das ich aber weiterhin nachfrage, heisst nur, dass ich keine Möglichkeit außen vor lassen will.

Ausgeschlossen habe ich bisher keinen. 

Bekomme die Vorschläge auch teilweise nur eingekippt und soll gucken was vor und nachteile sind.

[NorbertFe 2.065]

Ich klink mich hier aus. Denn es gibt nur zweieinhalb Möglichkeiten, die dir alle hier genannt wurden. Anhand welcher Kriterien du dann Laufwerke verbindest ist doch vollkommen wurscht. Aber vielleicht versteh ich deine "Anforderungen" ja auch einfach nicht.

 

Viel Erfolg

Norbert

[daabm 1.366]

Das ist das Problem des TO - er sucht die "best Mögliche Lösung", und die gibt es schlicht und einfach nicht :cool: :cool: :cool:

[Gast]

Falls es jemanden interessiert. Ich werde das Thema über GPP mit Zielgruppenadressierung (LDAP Query) und einem Share lösen.

Funktioniert soweit einwandfrei, was ihr mir ja auch prophezeit habt, das einzige was evtl "schöner" sein könnte ist der query. Ich binde jetzt im Prinzip die OU in der sich die User befinden und verwende einen Filter ("(&(objectCategory=user)(sAMAccountName=%LogonUser%))") um mir den jeweiligen User zu holen. 

Wie gesagt funktioniert, aber schöner wäre nach meinem Verständnis, wenn ich direkt den CN des Users binden könnte anstatt, die Vielzahl der User nach dem sAMAccountName zu Filtern. Leider sehe ich keine Möglichkeit, den CN des Users im query per Variable anzugeben, da keine vorgefertigte (Übersicht F3) existiert.

Ist dem so oder übersehe ich was?

 

@daabm: Stimmt ich habe die beste Möglichkeit FÜR MICH (bzw. meine Umgebung) gesucht und daher erstmal alles was theoretisch möglich ist für zusammengefasst und verglichen. Deswegen war auch euer Input sehr sehr wichtig und hilfreich für mich. Danke noch mal an alle!

[daabm 1.366]

samAccountName ist indiziert, das ist kein großes Problem... Und in der Tat - Du kannst nicht direkt binden, Du MUSST eine Query verwenden. Wäre schön, wenn es den direkten Zugriff auf User oder Computer auch gäbe, aber so isses halt. CN ist kein Bestandteil der LDAP Query Language. Du kriegst ja nicht mal den Parent per Query raus :-)

[Gast]

Super Danke für die Rückmeldung. Dann passt des.