Gruppenmitgliedschaft greift nicht auf Client

[Markus Butz 10]

Hallo allerseits,

 

ich habe in einer Umgebung mit mehreren DCs das Problem, dass die Gruppenmitgliedschaften irgendwie nicht auf den Clients landen.

Hintergrund ist, dass ich mit einem Logon-Script und "ifmember", welches ja auf den Clients ausgeführt wird, die Gruppenmitgliedschaft abfrage und OBWOHL ein Benutzer in bestimmten Gruppen ist, ist das Ergebnis NEGATIV, weshalb mein Script nicht so läuft, wie ich das gerne hätte.

 

Rufe ich ein gpedit /sync auf und lasse den Client neu starten, ist die Mitgliedschaft danach meist vorhanden.

 

Aber das ist doch Käse oder verstehe ich da was falsch? Lege ich im AD einen Benutzer in eine Gruppe, sollte das doch beim Benutzer auf dem Client beim nächsten Login greifen, damit er seine neuen Drucker/Mappings bekommt, oder?

 

(Rufe ich das ifmember auf dem jeweiligen Logon-DC auf, stimmt das Ergebnis immer, die Replikation hier läuft also. Nur eben nicht auf den Clients...)

 

Wo wäre hier der Ansatz?

 

DANKE für einige Tips!

 

Markus

[lefg 276]

Mit Gruppen(mitgliedschaft) sind Sicherheitsgruppen gemeint oder Organisationseinheiten?

 

Ob ifmember noch zeitgemäss ist?

[Markus Butz 10]

Sicherheitsgruppen... Ich habe für jeden Drucker eine Sicherheitsgruppe und lege da die User rein. Über das Logon Script soll dann geschaut werden, ob sie Mitglied sind und ggf. der Drucker verbunden werden.

Du weißt, wie ich meine?

Markus

[lefg 276]

Ich nehme mal an, es wurde der Ablauf des Loginscriptes beobachtet und protokolliert?

 

Ist die Gruppenrichtlinie bekannt: ".... immer auf das Netzwerk warten.", ist diese aktiviert und wirksam?

 

Um was für Clients handelt es sich denn, XP oder W7? Ob bei W7 ein Verbinden für einen User noch möglich ist wegen der UAC?

 

Off-Topic:

Zu Zeiten von Windows NT habe ich und Windows 95 habe ich auch mal ifmember verwendet und auch Drucker per Script verbunden. Heute sind bei mir auf allen Workstations die nötigen Druckertreiber installiert, neue werden nachgeführt mit printmig oder Printbrm.

[NilsK 2.930]

Moin,

 

für deinen Zweck solltest du dir die GPP ansehen:

GPP - Group Policy Preferences - Gruppenrichtlinien Einstellungen

 

ifmember ist bekannt unzuverlässig. Ich mache sowas, wenn nötig, mit whoami (allerdings erst ab Vista aufwärts, weil es unter XP noch nicht zum Lieferumfang gehört) und find.

 

Gruß, Nils

[Markus Butz 10]

Hi zusammen,

 

@lefg:

Nun, einige mehr Details zur Struktur: Es handelt sich größtenteils (ca. 80% aller User) um Terminalserver 2003/2008, die Memberserver sind. Die restlichen 20% sind größtenteils XP-Clients, nur wenige neue Ausnahmen davon sind Vista oder 7. Von daher wäre die Frage, ob die von dir genannte Richtlinie hier relevant wäre bzw. ist.

Auch sei erwähnt, dass ich nicht nur mit ifmember getestet habe sondern eigentlich mit KIX arbeite - da hier die Abfrage nach der (Sicherheits-)Gruppenmitgliedschaft ebenfalls negativ war, bin ich dann testweise - und weil es bekannter ist - auf ifmember runter. Das Ergebnis ist identisch.

Egal ob auf TS oder auf regulärem Client - die Abfrage ergibt KEIN Mitglied.

Mit der Richtlinie sollte das doch eigentlich nichts zu tun haben, oder? Und die UAC scheidet bei XP ja aus... :-)

Mache ich wie gesagt ein gpupdate /sync auf dem Client oder eben auf dem TS und starte neu, ist die Mitgliedschaft da.

Aber ich kann ja schlecht jedes Mal den TS neu starten für eine Druckeränderung bei einem User.

 

@NilsK

Ja, interessante Sache und AUF JEDEN FALL etwas, das ich demnächst in anderen Netzen einsetzen werde... Ob es in diesem Fall hilft, weiß ich noch nicht: Die User sind in OUs nach verschiedenen Standorten / Abteilungen gelegt - jedoch gibt es pro OU potentiell unterschiedliche Konfigurationen der Drucker, so dass ich diese nicht von der Gruppenrichtlinie, die ja an die OU gebunden ist, festmachen kann/möchte. Fehlgedanke?

Vielmehr war aktuell der Gedanke, für jeden Drucker unternehmensweit eine Sicherheitsgruppe zu erstellen und deren Mitgliedschaft per KIX abzufragen. Wenn ja, dann verbinden. Wenn nein, dann nicht.

Funktioniert aber wie beschrieben oft nicht, da zu oft fälschlicherweise die Gruppenabfrage negativ ist.

whoami scheidet aus, da zuviel 2003 und XP.

 

 

Wie würdet IHR das denn machen, wenn ihr ein eine bestehende, sehr heterogene und teilweise alte, Struktur (15 Server, ca. 350 User eines öffentlichen Trägers) kommt und keine Lust habt, auf 15 verschiedenen Terminalservern und X lokalen PCs neue Drucker wieder direkt per IP zu konfigurieren - was aktuell so vorgefunden wurde.

Ich fand das mit den Sicherheitsgruppen und KIX eigentlich OK... wenn's läuft.

 

Danke für weitere konstruktive Tips/Kritik...

 

Markus

[lefg 276]

Wie würdet IHR das denn machen, ....

 

Möglicherweise das Konzept überdenken, wahrscheinlich printmig verwenden. :)

[Markus Butz 10]

Hmmm, und das eignet sich wirklich, um so dynamisch Zuweisungen zu machen? Hatte ich bisher anders verstanden.

Ich dachte immer, Scripting sei hier DIE Möglichkeit...?

 

Unabhängig davon: MÜSSTE denn die Gruppenmitgliedschaftsabfrage positiv sein oder ist es hier normal, dass diese so lange nicht greift? Bin ja sicher nicht der einzige, der das hier so nutzt... bezieht sich ja genauso auf die Laufwerksmappings... Noch Ideen?

[lefg 276]

Ja, das es mit der Gruppenmitgliedschaft nicht funktioniert, weder ifmember noch kix, das erscheint mir auch verdächtig. Leider fällt mir nichts wirklich Hilfreiches dazu ein. Ich denke, in die Ereignisanzeigen wirst Du wohl geschaut haben, oder?

 

Das Verbinden von Druckern ist eine Möglichkeit, früher habe ich das auch so praktiziert. Mein heutiges Konzept sieht anders aus, allerdings habe ich keine Terminalserver.

 

Wahrscheinlich ist es doch sinnvoller, erstmal die Ursache des Problems zu finden, als alles über den Haufen zu werfen.

 

Ich bin schon mal etwas hartnäckig, frage deshalb nochmals nach der Richtlinie "..... immer auf auf das Netzwerk warten.", ob diese aktiviert und auf den Clients wirksam ist?

bearbeitet 1. Mai 2012 von lefg

[Markus Butz 10]

Klar, habe schon viel gesucht - musste aber erst einmal die Logik verstehen, wann da was wie geht und wie nicht.

Du meinst also, dass eine Gruppenmitgliedschaft grundsätzlich SOFORT am Client abfragbar sein müsste? Kannst du mir sagen, WIE das zum Client übermittelt wird bzw. auf welchem Weg die Anfrage geschieht und warum hier das gpupdate /sync hilft?

[lefg 276]

Leider kann ich deine Fragen nicht schlüssig beantworten. Die Sicherheitsgruppen haben nichts mit den Gruppenrichtlinien zu tun.

 

Nochmals, wie ist das mit der Gruppenrichtlinie ".... immer auf das Netzwerk warten.", kennst Du die, ist die aktiviert, ist sie auf alle DCs repliziert, ist sie auf den XPs wirksam (rsop.msc)?

 

Nächste Frage(n), wie ist es denn mit der Namensauflösung per DNS, ist deren Funktion gewährleistet? Ist der DNS ein AD-Integrierter? Haben sich die Clients in den DNS selbst eingetragen, sind die Einträge aktuell?

 

Wie schaut es mit Tests an den DCs aus mit Tests per dcdiag und netdiag, an den TS und Cliensts mit netdiag?

[tesso 375]

Gruppenmitgliedschaften sind erst nach erneuter Anmeldung des Users verfügbar. Nur zu diesem Zeitpunkt wird das Securitytoken erstellt.

[NilsK 2.930]

Moin,

 

Die User sind in OUs nach verschiedenen Standorten / Abteilungen gelegt - jedoch gibt es pro OU potentiell unterschiedliche Konfigurationen der Drucker, so dass ich diese nicht von der Gruppenrichtlinie, die ja an die OU gebunden ist, festmachen kann/möchte. Fehlgedanke?

 

in dem Fall ja. Mit GPP kannst du pro Eintrag festlegen, wann der gelten soll. Ich habe dir den Artikel nicht umsonst empfohlen.

 

whoami scheidet aus, da zuviel 2003 und XP.

 

Deshalb scheidet whoami ja noch lange nicht aus - installier dort whoami aus dem Resource Kit. Besser ist aber in deinem Fall aber GPP.

 

Gruß, Nils

[Sunny61 806]

@NilsK

Ja, interessante Sache und AUF JEDEN FALL etwas, das ich demnächst in anderen Netzen einsetzen werde... Ob es in diesem Fall hilft, weiß ich noch nicht: Die User sind in OUs nach verschiedenen Standorten / Abteilungen gelegt - jedoch gibt es pro OU potentiell unterschiedliche Konfigurationen der Drucker, so dass ich diese nicht von der Gruppenrichtlinie, die ja an die OU gebunden ist, festmachen kann/möchte. Fehlgedanke?

Vielmehr war aktuell der Gedanke, für jeden Drucker unternehmensweit eine Sicherheitsgruppe zu erstellen und deren Mitgliedschaft per KIX abzufragen. Wenn ja, dann verbinden. Wenn nein, dann nicht.

 

Lies dir den von Nils gep. Artikel nochmal genau durch, das zweite Bild sollte helfen die Tragweite zu verstehen. Stichwort Zeilgruppenadressierung. Für XP/VISTA Clients mußt Du nur auf diesen Artikel setzen: CSE, GPP, RSAT - Remote Server Admistration Tool und die neue GPMC

 

Wie würdet IHR das denn machen, wenn ihr ein eine bestehende, sehr heterogene und teilweise alte, Struktur (15 Server, ca. 350 User eines öffentlichen Trägers) kommt und keine Lust habt, auf 15 verschiedenen Terminalservern und X lokalen PCs neue Drucker wieder direkt per IP zu konfigurieren - was aktuell so vorgefunden wurde.

Ich fand das mit den Sicherheitsgruppen und KIX eigentlich OK... wenn's läuft.

 

KIX ist out, GPP ist in. ;)

[Markus Butz 10]

Hallo zusammen,

 

das Thema hatte einige Zeit geruht, in der diverse Probleme bei der Replikation der zahlreichen DCs zu lösen waren, dann noch die Richtlinie konfiguriert, jetzt sieht es aktuell recht viel versprechend aus.

 

Auch die GPP Sachen habe ich mir angeschaut und durchgespielt - eine schöne Sache - wenn ich das bei diesem Kunden jedoch nicht kurzfristig nachrüsten werde.

 

Zunächst einmal ein ganz herzliches DANKE an euch alle!!

 

Markus