Benutzer mit den meisten Antworten
*GELÖST* Exchange Server 2007 - Inter Site Link keine SMTP-Verbindung

Frage
-
Hallo Community,
ich stoße gerade an die Grenze und habe keine Idee mehr...
folgendes Szenario:
Es existiert eine Exchange Org auf 2 Standorte verteilt. Site 1 und Site 2 sind via IPSec-Tunnel miteinander verbunden.
Die Firewalls auf beiden Seiten sind offen.
Ich erreiche problemlos alle Systeme auf Site 1 und Site 2 via RDP, PING, SMB, CIFS etc.
DNS-Replikation perfekt. AD-Replikation perfekt.
Konstellation Site 1:
1 x Exchange Server 2007, SP3 UR12, HUB, CAS, DB
1 x DC01 2008 R2
Konstellation Site 2:
1 x Exchange Server 2007, SP3 UR12, HUB, CAS, DB
1 x DC02 2008 R2
InterSite Link via AD-Standort S und F erstellt.
Server sind den richtigen Standorten und Subnetzen zugeordnet, alles gut soweit...
Jetzt verschiebe ich testweise ein Postfach von Site 1 nach Site 2 und es funktioniert.
Jetzt möchte ich eine Mail von Postfach Sitze 2 in ein Postfach Site 1 schicken. Nix, die Mail bleibt in OWA im Ordner Entwürfe hängen und kommt nie am Exchange Transport an. Nichts in der Warteschlange, gar nichts. Als hätte ich Sie nie geschickt. Also prüfe ich die Basis. Verbindung via PING auf die IP`s, kein Problem. Verbindung via PING auf den NETBIOS Namen, kein Problem (FQDN sowieso). Aber jetzt...
Verbindungen auf SMTP Port 25
Telnet von DC01 auf Exchange an Site 2 --> funktioniert
Telnet von Exchange Site 1 --> Exchange Site 2 --> fehlgeschlagen
Telnet von Exchange Site 2 --> Exchange Site 1 --> funktioniert
Telnet von DC02 auf Exchange Site 2 --> funktioniert
Zusammengefasst:
Ich komme von jedem System via Telnet auf den Exchange an Site 2, außer vom Exchange der Site 1.
Exchange Management Console und Shell funktionieren ebenfalls problemlos...
Jemand ne Idee für mich?
- Bearbeitet X_Troubleshooter_X Mittwoch, 5. Februar 2014 13:26
Antworten
-
Hallo,
natürlich will ich Euch die Antwort nicht schuldig bleiben...
Beide Standorte sind, wie bereits beschrieben, via IPSEC miteinander verbunden, auf beiden Seiten ist der Access für alle Dienste aktiviert.
Auf der primären Seite existieren 2 WAN-Leitungen. Um nun das Routing sauber zu realisieren, wurde hier ein Policy Based Routing eingerichtet, welches sämtlichen SMTP-Traffic vom Mailserver auf eine bestimmte WAN-Leitung beschränkte.
Eine neue Policy mit neuer Route ins entfernte IPSec-Netz und alles war gut...
Problem gelöst...
Danke für alle Gedanken zum Thema...
- Als Antwort markiert Alex Pitulice Mittwoch, 5. Februar 2014 13:32
Alle Antworten
-
Ich kann via Telnet von Exchange Site 1 bspw. den Port 587, 443 und auch 80 auf Exchange in Site 2 erreichen...
Die Firewall ist an allen Systemen aus. Testweise sogar für alle Profile...
Ja, auch eine Verbindung auf den DC in Site 2 ist möglich.
RDP, Telnet etc...
- Bearbeitet X_Troubleshooter_X Dienstag, 28. Januar 2014 18:58
-
Hallo X Troubleshooter X,
hast Du in der Zwischenzeit die Ursache des Problems vielleicht gefunden?
Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Hallo,
natürlich will ich Euch die Antwort nicht schuldig bleiben...
Beide Standorte sind, wie bereits beschrieben, via IPSEC miteinander verbunden, auf beiden Seiten ist der Access für alle Dienste aktiviert.
Auf der primären Seite existieren 2 WAN-Leitungen. Um nun das Routing sauber zu realisieren, wurde hier ein Policy Based Routing eingerichtet, welches sämtlichen SMTP-Traffic vom Mailserver auf eine bestimmte WAN-Leitung beschränkte.
Eine neue Policy mit neuer Route ins entfernte IPSec-Netz und alles war gut...
Problem gelöst...
Danke für alle Gedanken zum Thema...
- Als Antwort markiert Alex Pitulice Mittwoch, 5. Februar 2014 13:32
-
Hallo,
danke Dir für die schnelle und ausführliche Rückmeldung. :)
Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.