Jump to content

GPO NetShare pro Gruppe verbinden, allerdings viele Gruppen


Gast
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

- 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:

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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

Link zu diesem Kommentar

<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 von Daniel -MSFT-
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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!

Link zu diesem Kommentar

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 :-)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...