9
SPOF Problem mit einem 2003 DC
Kommunikation in übergeordnete Domain
Unsere Domain ist eine SubDomain einer grösseren Struktur. Dienste wie Exchange und diverse Applikationen werden in der übergeordneten Domain zur Verfügung gestellt. Wir haben fünf Doamincontroller in unserer SubDomain. Nun zum Problem. Wenn der Domaincontroller am Hauptstandort, welcher als Bridgehead nach oben fungiert (inkl. GC), nicht online ist, kann man aus unserer Domäne nicht nach oben zugreifen. Die Exchangeverbindungen aus Outlook gehen nicht mehr sowie diverse Applikationen bringen die Fehlermeldung, dass der RPC Server nicht verfügbar sei und starten auch nicht mehr. Was für eine Funktion im speziellen ist da nicht redundant bzw. haben wir falsch konfiguriert?
Danke im Voraus für alle Tips!
Danke im Voraus für alle Tips!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 80249
Url: https://administrator.de/contentid/80249
Printed on: April 26, 2024 at 09:04 o'clock
9 Comments
Latest comment
Sehr warscheinlich liegt das am GC. Fehlt er, schlagen Anmeldungen fehl. Was aber auch sein kann, das der Bridgehead noch andere rollen besitzt. Du solltest aber auf jeden fall dafür sorgen das du einen funktionierenden GC ODER die Option "zwischenspeichern der universellen Gruppenmitgliedschaften" aktiviert hast.
Danke, werd ich überprüfen. Den GC haben wir auch auf anderen DCs. Der Schema Owner und der Naming Master sind in der übergeordneten domain. Infrastructure Master sowie PDC Emulator und RID sind auf anderen DCs in unserer Domain. Unser SPOF-DC hat lediglich den GC und führt DNS aus. Hat diese Bridgeheadfunktion etwas spezielles auf sich? Gruss
Jepp. Der Bridgehead ist der Server, der die Replikation an andere Standorte übernimmt. Fällt dieser aus, übernimmt normalerweise ein anderer diese Funktion. Es sei denn
1) Er wurde als einziger, statischer Bridgehead konfiguriert
ODER
2) die restlichen Server befinden sich in einem Netz, das nicht an die anderen standorte geroutet wird.
Schema und Domain Naming Master sind typischerweise in der ersten Domäne der Gesammtstruktur. Jede Domäne hat 3 weitere FSMO's. Der RID vergibt Sicherheitskennungen, der inframaster kümmert sich um Gruppenbezüge und änderungen an Benutzer/Gruppenkonten und der PDC Emulator wird primär für ältere Systeme und bei fehlgeschlagenen authentifizierungen angesprochen. Der GC enthält einen Index bestimmter Objekte in der gesamten AD-Struktur.
Daneben gibt es noch einige andere Funktionen für die diese Dienste benötigt werden. Ich schätze mal du weißt was die FSMO's machen.
Also, wenn die Meldung "RPC Server nicht verfügbar" beim Ausfall des Bridgehead erscheint, sollte man zuerst einmal herusfinden was der client in diesem Moment versucht. Am besten einmal einen Netzwerksniffer am client gestartet und geprüft wo er versucht zu verbinden. meistens sieht man schon am Protokoll/Port welche Funktion da aufgerufen wird. RPC wird eigentlich nicht für GC abfragen verwendet. Am besten einen alten Rechner mit XP/Outlook und Wireshark ausgestattet, die IP des Bridgehead auf localhost umgeleitet (am einfachsten in die hosts-file schreiben) und in wireshark schauen was passiert.
1) Er wurde als einziger, statischer Bridgehead konfiguriert
ODER
2) die restlichen Server befinden sich in einem Netz, das nicht an die anderen standorte geroutet wird.
Schema und Domain Naming Master sind typischerweise in der ersten Domäne der Gesammtstruktur. Jede Domäne hat 3 weitere FSMO's. Der RID vergibt Sicherheitskennungen, der inframaster kümmert sich um Gruppenbezüge und änderungen an Benutzer/Gruppenkonten und der PDC Emulator wird primär für ältere Systeme und bei fehlgeschlagenen authentifizierungen angesprochen. Der GC enthält einen Index bestimmter Objekte in der gesamten AD-Struktur.
Daneben gibt es noch einige andere Funktionen für die diese Dienste benötigt werden. Ich schätze mal du weißt was die FSMO's machen.
Also, wenn die Meldung "RPC Server nicht verfügbar" beim Ausfall des Bridgehead erscheint, sollte man zuerst einmal herusfinden was der client in diesem Moment versucht. Am besten einmal einen Netzwerksniffer am client gestartet und geprüft wo er versucht zu verbinden. meistens sieht man schon am Protokoll/Port welche Funktion da aufgerufen wird. RPC wird eigentlich nicht für GC abfragen verwendet. Am besten einen alten Rechner mit XP/Outlook und Wireshark ausgestattet, die IP des Bridgehead auf localhost umgeleitet (am einfachsten in die hosts-file schreiben) und in wireshark schauen was passiert.
OK. Danke für den Input. Wo sieht man genau wer denn nun Bridgeheadserver ist bzw. ob dieser statisch oder dynamisch konfiguriert ist? Gruss
AD Standorte und Dienste -> [Standort] -> Servers
Auf der rechten Seite siehst du nun ob einer der Server bevorzugter Bridgehead ist. Ist keiner konfiguriert, bestimmt die Topologieerkennung welcher verwendet wird. Das siehst du dann mit dem Tool "Active Directory replication Monitor" auf den SupportTools.
Auf der rechten Seite siehst du nun ob einer der Server bevorzugter Bridgehead ist. Ist keiner konfiguriert, bestimmt die Topologieerkennung welcher verwendet wird. Das siehst du dann mit dem Tool "Active Directory replication Monitor" auf den SupportTools.
Unter Sites ans Services ist bei keinem unserer DCs die Rolle des Bridgeheads eigetragen. Den Replmon hab ich mal gestartet. Dort steht bei allen unter "Preferred Bridgehead" no. Hast Du eine Erklärung hierfür? Einer muss doch diese Rolle erhalten haben? Wurde dies evtl. manuell entfernt? falls ja, würde doch die Automatik wieder greifen?
Sie greift. Wenn im replmon kein server als "Bevorzugter Bridgehead" angegeben ist, "regeln" die vorhandenen das unter sich.
Zurück zu deinem Problem (Bridgehead kann so etwas nicht verursachen, da reine Infrastrukturkomponente).
Hast du schon einmal den Test auf einem Client mit einem Sniffer probiert? Besorg dir Wireshark (free), starte einen Capture, trenne die Verbindung zum Server, starte Outlook, warte auf die Fehlermeldung und stoppe den capture wieder. Falls du hilfe bei der Auswertung benötigst, kannst du mich gern anschreiben. Nur bitte stell das File auf keinen Fall ins Netz.
Zurück zu deinem Problem (Bridgehead kann so etwas nicht verursachen, da reine Infrastrukturkomponente).
Hast du schon einmal den Test auf einem Client mit einem Sniffer probiert? Besorg dir Wireshark (free), starte einen Capture, trenne die Verbindung zum Server, starte Outlook, warte auf die Fehlermeldung und stoppe den capture wieder. Falls du hilfe bei der Auswertung benötigst, kannst du mich gern anschreiben. Nur bitte stell das File auf keinen Fall ins Netz.
OK, werd ich versuchen. Melde mich sobald ich mehr weis. Gruss
Wir haben den Fehler behoben. Wir hatten ein Problem mit den Kerberos Tickets. Lösung: "Kerberos key distribution center" Dienst deaktivieren, Server neu starten, Replikation ausführen, Dienst wieder starten.
Gruss und danke trotzdem für die aktive Mithilfe!
Gruss und danke trotzdem für die aktive Mithilfe!