Exchange Server mit falschem Active Directory-Standort

Unser Exchange 2013-Server hat plötzlich begonnen, Fehler wegen fehlerhafter Replikation zwischen Standorten (es sollte keine Replikation geben, da es keinen anderen Server gibt) sowie einige andere Probleme zu protokollieren, die in Zusammenhang zu stehen scheinen.

Wir haben zwei Standorte, die über VPN verbunden sind. Dies ist die Konfiguration der Active Directory-Standorte:
An jedem Standort befinden sich mehrere Subnetze, und das Routing zwischen den Subnetzen und den Standorten funktioniert einwandfrei.

Die IP-Adresse des Exchange-Servers lautet 10.10.0.26und wird auf demselben Hyper-V-Host wie ein 10.10.0.21Domänencontroller ausgeführt, wobei die IP -Adresse (im Bild XXXX-DC01) als Teil der IP-Adresse festgelegt ist Default-First-Site.
Server in Sites

Der Exchange-Server glaubt, dass er sich auf der YGXXX-Site befindet:
Geben Sie hier die Bildbeschreibung ein

Ich habe NTLOGON.LOG aktiviert, aber die einzigen verwandten Informationen scheinen zu sein:
Geben Sie hier die Bildbeschreibung ein

Wie kann ich herausfinden, warum der Server die falsche Site auswählt?

active-directory exchange exchange-2013

— Yakatz
quelle

Vom Mitgliedsserver über Telnet zu den Ports 88, 389, 445 usw. Ihrer standortlokalen Domänencontroller. Ich würde das Netzwerk jetzt so hart beschuldigen, wenn ich Sie wäre, aber dann konfigurieren sich Firewalls mitten in der Nacht spontan neu, nur um mich wütend zu machen, wo ich arbeite.

— Ryan Ries

@ RyanRies Diese und andere scheinen alle offen zu sein. Die Windows-Firewall ist auf DC deaktiviert, und der Exchange-Server und der DC befinden sich auf demselben Hyper-V-Server. Ich habe jedoch gerade festgestellt, dass sie sich auf verschiedenen virtuellen Switches befinden (in diesem Fall auch als verschiedene physische Netzwerkports bezeichnet). Könnte das das tun?

— Yakatz

Der Microsoft-Artikel KB247811, Wie sich Domänencontroller in Windows befinden, ist hier hilfreich.

Das heißt, hier ist eine Liste von Dingen, die ich überprüfen würde, wenn Sie sie noch nicht ausprobiert haben:

Führen Sie dcdiag.exe auf allen Domänencontrollern aus, um festzustellen, ob bei der Replikation Probleme aufgetreten sind. Vielleicht möchten Sie auch die Ereignisprotokolle überprüfen - manchmal finde ich sie leichter zu lesen als die dcdiag-Ausgabe.
Stellen Sie sicher, dass die IP-Adresse des XXXX-DC01-Servers in den DNS-Servern aufgeführt ist, die in den Netzwerkverbindungseigenschaften Ihres Exchange-Servers aufgeführt sind. Wenn der YG-Standort-DC dort aufgeführt ist, sollten Sie ihn entfernen, wenn er keine sinnvolle Redundanz bietet.

Testen Sie auf Ihrem Exchange-Server die DNS-Suche:

c:\> nslookup
Default Server: XXXX-DC01.xxxxxxxxx.edu
Address: 10.10.0.21

> set q=SRV
> _ldap._tcp.xxxxxxxxx.edu

Wenn Sie keine Antwort erhalten, die auf Ihren ersten Standort-DC verweist, liegt ein DNS-Konnektivitätsproblem, ein DNS-Serverproblem und / oder ein FSMO-Problem vor.
Wenn Sie eine gute Antwort erhalten, versuchen Sie, eine LDAP-Abfrage für die als Ergebnis zurückgegebenen DC-Server auszuführen. In Anbetracht Ihres Setups sind wahrscheinlich bereits Active Directory-Benutzer und -Computer (dsa.msc) auf dem Exchange-Server installiert. Führen Sie das vom Exchange-Server aus. Klicken Sie mit der rechten Maustaste auf das Stammobjekt in der Hierarchie und stellen Sie eine Verbindung zu Ihrem XXXX-DC01-Domänencontroller her. Wenn Sie keine Verbindung herstellen können, wissen Sie, dass Sie ein LDAP-Problem haben, entweder mit dem Dienst auf dem DC oder mit der Verbindung und Authentifizierung von der Exchange-VM.
Wenn Sie eine Verbindung über dsa.msc herstellen können, besteht mein letzter Vorschlag darin, die FSMOs zu überprüfen. Dies ist wahrscheinlich nicht das Problem, aber es lohnt sich, es zu überprüfen. Stellen Sie sicher, dass an jedem Standort ein Domänencontroller mit einem globalen Katalog vorhanden ist (die GC-Eigenschaft kann in den NTDS-Objekteigenschaften des Servers in Active Directory-Standorten und -Diensten geändert werden) und dass das Schema-Master-FSMO kein globaler Katalogserver ist. Alternativ können Sie einfach alle Server zu globalen Katalogservern machen. Das Festlegen aller Optionen ist eine hirntote Option. Wenn Sie jedoch eine kleine Verzeichnisstruktur haben, die nur selten aktualisiert wird, ist dies nicht das Schlimmste auf der Welt.

— Howard Miller
quelle

DNS ist in Ordnung. Alle unsere DCs sind bereits GCs. Vom Exchange-Server aus ist einer der drei am ersten Standort nicht erreichbar (tatsächlich der alte Exchange-Server, der ebenfalls ein Domänencontroller war - seltsam, da er den Exchange auf diesem System für die Postfachreplikation kontaktieren kann). Könnte es nur sein, dass man versucht, diesen zu kontaktieren und dann die Site zu wechseln?

— Yakatz

Sie haben geschrieben "Es sollte keine Replikation geben, da es keinen anderen Server gibt". Also meinen Sie , dass es verwendet werden Exchange auf dem Server , und es verwendet , um replizieren OK , wenn es noch installiert wurde, oder meinen Sie , dass Exchange noch da ist - nur vielleicht nicht so aktiv genutzt - und die neuere Exchange - Server kann immer noch mit ihm reden? In beiden Fällen möchten Sie möglicherweise untersuchen, warum ein Teil des Datenverkehrs zwischen ihnen als "nicht erreichbar" fehlschlägt.

— Howard Miller

Auf den Servern ist keine Replikation eingerichtet, aber der neue Server sagt immer wieder, dass die Replikation fehlgeschlagen ist, weil er glaubt Site B, dass die Mailbox-Datenbank vorhanden ist und weiß, dass sie sich in der Postfachdatenbank befinden sollte Site A. Exchange auf dem alten System verfügt derzeit über keine Postfachdatenbanken, sodass eine Replikation nicht einmal möglich ist.

— Yakatz

Warum sind dann noch Exchange-Komponenten auf dem älteren Server installiert? Wenn Sie sie nicht benötigen, deinstallieren Sie sie. Wenn Sie dies tun, migrieren Sie ihre Funktionen auf den neuen Server. Dann deinstallieren Sie sie.

— Howard Miller

Arbeiten an der Deinstallation, aber noch nicht fertig ...

— Yakatz