3
Verbindung zur Mailbox Database nicht möglich, Server 2012 und Exchange 2013
Ich habe jetzt schon mehrfach auf einem Server 2012 Exchange 2013 installiert. Insoweit gibt es hinsichtlich der Installation und Konfiguration auch keine Probleme. Bei jeder dieser Installationen tritt bei mir das Phänomen auf, dass nach einiger Zeit, manchmal im Stundenrhythmus, manchmal erst nach zwei Tagen, der Mailtransport eingestellt wird. Alle möglichen Infos dazu, insbesondere zur DNS Konfiguration habe ich schon ausprobiert. Auch lässt sich der Transportservice nicht neu starten. Dieser hängt dann im Status "wird beendet". Nur ein Neustart des ganzen Servers behebt das Problem. Danach werden auch alle Mails, egal ob intern oder extern, die in dieser Zeit in der Warteschlange hängen geblieben waren, ausgeliefert. Wenn man die Warteschlangenanzeige aufruft, wird folgendes angezeigt:
Zuvor steht im Status auch mal "Wiederholen".
Ich finde einfach nicht, woran es liegt. Insbesondere habe ich für die DNS Lookups auch in der Exchange Verwaltungskonsole eine manuelle Konfiguration angegeben, wobei ich für intern die IP des Servers, und für externe Lookups zusätzlich die IP des Routers angegeben habe. Versendet wird via Smart Host, allerdings gab es dort auch keine Probleme, ich folgte nur einem Tipp. Die Mailbox Database befindet sich auf dem Server selbst. Wieso kann dann auf einmal keine Verbindung mehr hergestellt werden? Alle Tests zur Namensauflösung mit nslookup funktionieren fehlerfrei. Auch wenn das System hängt wird mir mit get-servicehealth in der Exchange Verwaltungsshell alles fehlerfrei angezeigt.
Weiß jemand die Lösung für dieses Problem?
28.05.2013;
Kleines Update:
Nach endlosem Durchforsten diverser Foren konnte ich immer noch keine brauchbare Lösung finden. Es gibt aber wohl sehr viele mit diesem Problem. Allerdings konnte ich jetzt feststellen, dass die Verbindung zur Mailbox Database sofort wieder hergestellt wird, wenn man den Dienst "RAS und Routing" neu startet, und zwar ohne Reboot des ganzen Servers.
Ich finde einfach nicht, woran es liegt. Insbesondere habe ich für die DNS Lookups auch in der Exchange Verwaltungskonsole eine manuelle Konfiguration angegeben, wobei ich für intern die IP des Servers, und für externe Lookups zusätzlich die IP des Routers angegeben habe. Versendet wird via Smart Host, allerdings gab es dort auch keine Probleme, ich folgte nur einem Tipp. Die Mailbox Database befindet sich auf dem Server selbst. Wieso kann dann auf einmal keine Verbindung mehr hergestellt werden? Alle Tests zur Namensauflösung mit nslookup funktionieren fehlerfrei. Auch wenn das System hängt wird mir mit get-servicehealth in der Exchange Verwaltungsshell alles fehlerfrei angezeigt.
Weiß jemand die Lösung für dieses Problem?
28.05.2013;
Kleines Update:
Nach endlosem Durchforsten diverser Foren konnte ich immer noch keine brauchbare Lösung finden. Es gibt aber wohl sehr viele mit diesem Problem. Allerdings konnte ich jetzt feststellen, dass die Verbindung zur Mailbox Database sofort wieder hergestellt wird, wenn man den Dienst "RAS und Routing" neu startet, und zwar ohne Reboot des ganzen Servers.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 206023
Url: https://administrator.de/contentid/206023
Ausgedruckt am: 18.11.2024 um 07:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo
Ich hatte ja schon fast an mir gezweifelt, aber wir haben hier seit der Installation eines Exchange 2013 auf einem Server 2012 das selbe Problem.
Es scheint als würde der Exchange, wenn man auf dem selben Server Routing & RAS konfiguriert, im Laufe der Zeit sehr viele Connections auf die RAS-IP Adresse Port 444 öffnen (per default die Exchange Backend Website im IIS). Diese bleiben anschließend alle in einem SYN_RECEIVE Status hängen und das führt letzten Endes dazu, dass der Transport Dienst des Exchange seine Arbeit einstellt.
Ich habe bereits versucht die Exchange Backend Website von allen IPs auf die eigentliche lokale IP des Servers zu beschränken (im IIS über Bindungen), allerdings führte dies dazu, dass danach der Postfachzugriff für die lokalen User über Outlook nicht mehr funktionierte.
Bin über jede Idee in dieser Sache dankbar.
Grüße
Thorsten
Ich hatte ja schon fast an mir gezweifelt, aber wir haben hier seit der Installation eines Exchange 2013 auf einem Server 2012 das selbe Problem.
Es scheint als würde der Exchange, wenn man auf dem selben Server Routing & RAS konfiguriert, im Laufe der Zeit sehr viele Connections auf die RAS-IP Adresse Port 444 öffnen (per default die Exchange Backend Website im IIS). Diese bleiben anschließend alle in einem SYN_RECEIVE Status hängen und das führt letzten Endes dazu, dass der Transport Dienst des Exchange seine Arbeit einstellt.
Ich habe bereits versucht die Exchange Backend Website von allen IPs auf die eigentliche lokale IP des Servers zu beschränken (im IIS über Bindungen), allerdings führte dies dazu, dass danach der Postfachzugriff für die lokalen User über Outlook nicht mehr funktionierte.
Bin über jede Idee in dieser Sache dankbar.
Grüße
Thorsten
Hallo,
ähnlich ging es mir, da auch ich verzweifelte. Die Ursache liegt aber im Produkt. Hier ein link zu einem Forum im Microsoft Technet:
http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/threa ...
Ich habe die Tipps, die allesamt als workaround und nicht als Lösung aufzufassen sind, angewendet. Jetzt laufen alle drei Server seit fast 4 Tagen ohne den bekannten Ausfall. Doch dieser Zustand stellte sich auch nicht sofort ein, sondern erst ein "wenig später". Eine Lösung hätte sofort "gewirkt", und ich erwarte schon das nächste Mal.
Aber der Reihe nach:
Man muss wie in dem Beitrag beschrieben das integrierte Scannen nach Malware abschalten.
Der Servername muss nicht nur im DNS auf die lokale IP verweisen, sondern auch in der host Datei müssen diese Einträge vorgenommen werden.
Zusätzlich habe ich noch in der Exchange Verwaltung die DNS lookups manuell auf die lokale IP, und für extern auch auf den Router eingestellt, sodass die RAS und Routing IP "unberücksichtigt" bleibt. Dasselbe habe ich im DNS selbst nochmal gemacht. Nur in der Forward Zone, die den FQDN der Domäne trägt, habe ich den zweiten IP Eintrag, der auf die RAS Adresse verweist, belassen. Bei allen anderen Zonen habe ich den Eintrag entfernt.
Wie gesagt, das ist alles nur "Gefummel", das keinen Anspruch auf die Bezeichnung "Lösung" hat. Wenn man aber im Beitrag liest, dass auch der Microsoft Support ratlos ist, hat man ja wohl kaum eine Wahl.
Die von dir getroffene Feststellung, dass viele Connections im SYN_RECEIVE State offen bleiben und das Problem verursachen, hatte ich noch gar nicht dabei bemerkt. Allerdings fand ich in den Logdateien (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Mailbox\Connectivity\Submission), dass eine Verbindung zur Mailbox nicht hergestellt werden konnte, weil diese als "unhealthy" markiert wurde. Mangels DAG konnte auch keine andere "valid" Database verbunden werden. Eine Abfrage in diesem Status mit "Get-MailboxDatabaseCopyStatus -Identity XXX | Format-List" ergibt aber, dass der Status sehr wohl "healthy" ist. Es ist auf jeden Fall die Kombination Server 2012, Exchange 2013 in Verbindung mit RAS und Routing, die hier ursächlich ist.
ähnlich ging es mir, da auch ich verzweifelte. Die Ursache liegt aber im Produkt. Hier ein link zu einem Forum im Microsoft Technet:
http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/threa ...
Ich habe die Tipps, die allesamt als workaround und nicht als Lösung aufzufassen sind, angewendet. Jetzt laufen alle drei Server seit fast 4 Tagen ohne den bekannten Ausfall. Doch dieser Zustand stellte sich auch nicht sofort ein, sondern erst ein "wenig später". Eine Lösung hätte sofort "gewirkt", und ich erwarte schon das nächste Mal.
Aber der Reihe nach:
Man muss wie in dem Beitrag beschrieben das integrierte Scannen nach Malware abschalten.
Der Servername muss nicht nur im DNS auf die lokale IP verweisen, sondern auch in der host Datei müssen diese Einträge vorgenommen werden.
Zusätzlich habe ich noch in der Exchange Verwaltung die DNS lookups manuell auf die lokale IP, und für extern auch auf den Router eingestellt, sodass die RAS und Routing IP "unberücksichtigt" bleibt. Dasselbe habe ich im DNS selbst nochmal gemacht. Nur in der Forward Zone, die den FQDN der Domäne trägt, habe ich den zweiten IP Eintrag, der auf die RAS Adresse verweist, belassen. Bei allen anderen Zonen habe ich den Eintrag entfernt.
Wie gesagt, das ist alles nur "Gefummel", das keinen Anspruch auf die Bezeichnung "Lösung" hat. Wenn man aber im Beitrag liest, dass auch der Microsoft Support ratlos ist, hat man ja wohl kaum eine Wahl.
Die von dir getroffene Feststellung, dass viele Connections im SYN_RECEIVE State offen bleiben und das Problem verursachen, hatte ich noch gar nicht dabei bemerkt. Allerdings fand ich in den Logdateien (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Mailbox\Connectivity\Submission), dass eine Verbindung zur Mailbox nicht hergestellt werden konnte, weil diese als "unhealthy" markiert wurde. Mangels DAG konnte auch keine andere "valid" Database verbunden werden. Eine Abfrage in diesem Status mit "Get-MailboxDatabaseCopyStatus -Identity XXX | Format-List" ergibt aber, dass der Status sehr wohl "healthy" ist. Es ist auf jeden Fall die Kombination Server 2012, Exchange 2013 in Verbindung mit RAS und Routing, die hier ursächlich ist.
Hallo,
einen Monat später kann ich sagen, dass es bei keinem einzigen Server mehr zu den zuvor beschriebenen Ausfällen gekommen ist. Wenn auch in sich nicht ganz schlüssig, so kann ich doch die Frage als gelöst bezeichnen.
einen Monat später kann ich sagen, dass es bei keinem einzigen Server mehr zu den zuvor beschriebenen Ausfällen gekommen ist. Wenn auch in sich nicht ganz schlüssig, so kann ich doch die Frage als gelöst bezeichnen.
