Gast Geschrieben 4. Januar 2010 Melden Teilen Geschrieben 4. Januar 2010 Hallo zusammen wir haben folgende Strukur: Wir haben 4 Standorte die alle in einer AD Domain bzw. AD Struktur sind. An jedem Standort gibt es einen Bridgehead der jeweils mit den anderen 3 redet und an einen DC intern weiterrepliziert. Nun mussten heute Kennwörter geändert werden. Benutzer meldeten dass es sehr lange dauerte bis er die Änderungen speichert. Wir haben aber dann festgestellt dass mehrere Benutzer sich nicht an einem DC an ihrem Standort anmelden, sondern an einem DC an der anderen Site die die Änderung noch nicht repliziert bekamn was den Fehler verursachte. Ich habe mit Repadmin und DCDIAG alles gechecked das sieht auch soweit alles gut aus. Meine Frage, wie kann ich überprüfen welchen GC der jeweilige Client nehmen soll bzw wie kann ich das einstellen. Das Replikationsintervall kann ich leider nicht reduzieren, da 30 Minuten bei uns sein müssen. Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 4. Januar 2010 Melden Teilen Geschrieben 4. Januar 2010 Hi, ich würde tippen, daß die IP-Subnetze und Sites nicht korrekt zugeordnet sind. Wie genau sind diese eingerichtet - die Client Subnetze liegen am korrekten Standort? Das läßt sich ggf. mit NLTEST recht schnell gegenprüfen. Handelt es sich ausschließlich um 2003er DCs oder sind auch 2008er (eventuell RODCs) mit dabei? Viele Grüße olc Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 4. Januar 2010 Melden Teilen Geschrieben 4. Januar 2010 (bearbeitet) Servus, An jedem Standort gibt es einen Bridgehead der jeweils mit den anderen 3 redet und an einen DC intern weiterrepliziert. ja, das ist "per Design" so. Der Knowledge Consistency Checker (KCC), genauer ISTG, wählt an jedem AD-Standort einen Domänencontroller als Bridgeheadserver aus. Meine Frage, wie kann ich überprüfen welchen GC der jeweilige Client nehmen soll bzw wie kann ich das einstellen. Das Replikationsintervall kann ich leider nicht reduzieren, da 30 Minuten bei uns sein müssen. Der GC spielt doch in deinem Fall keine Rolle! Ändert ein Benutzer sein Kennwort, repliziert der DC auf dem der Benutzer sein Kennwort geändert hat, umgehend das neue Kennwort zum DC der die FSMO-Rolle des PDC-Emulators innehat. Authentisiert sich der Benutzer danach an einem DC der das neue Kennwort noch nicht kennt, fragt der DC bevor er dem Benutzer die Anmeldung verweigert beim PDC-Emulator nach, ob ihm ein neueres Kennwort vorliegt. Falls ja, kann sich der Benutzer anmelden und falls nicht, schlägt die Anmeldung fehl. Der PDC-Emulator hat bei der Kennwortfrage das letzte Wort. Der DC "pusht" das neue Kennwort zum PDC-Emulator sogar dann, wenn der PDC-Emulator an einem anderen AD-Standort steht. Dabei greift der DC auch nicht auf die Bridgeheadserver an jedem AD-Standort zurück. Der DC auf dem das Kennwort geändert wurde, nutzt stattdessen eine RPC-Verbindung zum PDC-Emulator um das Kennwort zu aktualisieren. Der PDC-Emulator repliziert dann das neue Kennwort anschließend über das normale Replikationsverfahren an alle weiteren DCs. Ist allerdings der PDC-Emulator z.B. wegen Überlastung nicht erreichbar oder die RPC-Verbindung schlägt fehl, wird die Kennwortänderung ebenfalls über das normale Replikationsverfahren an alle DCs inklusive dem PDC-Emulator repliziert. http://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx#w2k3tr_repup_how_huzs Aber die Frage ist viel eher: Warum authentisiert sich der Client an einem DC aus einem anderen AD-Standort? Das sollte zuerst geklärt werden. Denn der Client versucht sich standardmäßig "immer" an einem DC aus "seinem" AD-Standort anzumelden. Lies dir mal diesen Artikel durch: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort bearbeitet 4. Januar 2010 von Daim Zitieren Link zu diesem Kommentar
Gast Geschrieben 4. Januar 2010 Melden Teilen Geschrieben 4. Januar 2010 Vielen Dank für die Informationen ich werde das ganze mal überprüfen. Das die Domain noch im niedrigsten Level (Windows2000) läuft ist okay oder ? Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 4. Januar 2010 Melden Teilen Geschrieben 4. Januar 2010 Vielen Dank für die Informationen ich werde das ganze mal überprüfen. Das die Domain noch im niedrigsten Level (Windows2000) läuft ist okay oder ? Das hat zumindest auf das Verhalten einer Kennwortänderung keinen Bezug. Natürlich ist es stets ratsam, auf den höchstmöglichen Domänen- sowie Gesamtstrukturfunktionsmodus zu wechseln (sofern möglich), um von den Vorteilen die der neue Modus bietet zu profitieren. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus Zitieren Link zu diesem Kommentar
Gast Geschrieben 5. Januar 2010 Melden Teilen Geschrieben 5. Januar 2010 Vielen Dank für die Tips aber eventuell suche ich auch an der ganz falschen Stelle. Um das Problem näher zu beschreiben: Benutzer meldet sich an und wird um PW Änderung gebeten. PW wird geändert. Er baut mit dem PNAgent eine Verbindung zu Citrix auf und bekamt da die Fehlermeldung das PW wäre falsch. Nach einer gewissen Zeit kann er sich dann mit seinem PW anmelden. Irgendjemand eventuell einen anderen Ansatz? Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 5. Januar 2010 Melden Teilen Geschrieben 5. Januar 2010 Moin, der Client befindet sich vermutlich in einer anderen Site als der Citrix-Server. Daher muss er die Replikation abwarten. Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.