Exchange 2010 SP3 schließt offene Verbindungen nicht

[addy0604 11]

Guten Morgen zusammen und noch eine gesundes neues Jahr :)

 

Für unseren Exchange hat das Jahr schlecht aufgehört und noch schlechter angefangen. Ich habe nämlich für mein Problem noch keine Lösung gefunden und hoffe, ihr hättet einen Idee.

Zu meiner Umgebung:

Eine Windows-Domäne mit überwiegend 2008 R2 Servern. Ein Exchange 2010 SP3 (seit einer Woche RU16). Alles virtuell unter VMware.

Ende November ist der Exchange nachts stehen geblieben. Im Eventlog stand jede Menge mit "Could not find any available Domain Controller".

Backup ist abgebrochen, weil kein Zugriff auf den Server. Keine ein- und ausgehende Mails, keine Zugriff über Outlook oder OWA.

Server am nächsten Morgen neu gestartet, alles geht wieder. Das macht er allerdings alle 8 Tage.

Mit den Fehlern im Eventlog konnte ich irgendwie keine Ursache finden. Dann bin ich plötzlich über eine "Warnung" gestolpert, die unmittelbar vor dem Abschmieren des Servers ins Eventlog geschrieben wurde: Warnung Ereignis 4227 Tcpip - TCP/IP konnte keine ausgehende Verbindung herstellen....

 

Nach etwas Recherche bin ich auf den Registry-Eintrag TCPTimedWaitDelay gestoßen und hab ihn, wie in einigen Foren empfohlen, auf 30 gesetzt.

Momentan läuft der Server seit 7 Tagen. netstat -a zeigt mir allerdings wieder kiloweise Verbindungen zur Firewall an, die auf SCHLIESSEN_WARTEN stehen, aktuell 65534. Ist das normal?

Ich will nicht unbedingt warten bis der Server kommende Nacht wieder stehen bleibt, mein Vorstand steigt mir aufs Dach.

 

Ich habe auch gelesen, das man mit deaktivieren und aktivieren der NIC diese Verbindungen wieder freigeben kann. Ich kann natürlich einen Batch-Datei jede Nacht laufen lassen, die die NIC kurzzeitig deaktiviert. Damit hätte ich zwar das Problem umgangen, aber nicht gelöst.

 

Ich sollte vielleicht noch erwähnen, das etwa zum gleichen Zeitpunkt die Server von der alten VMware 5.1 Umgebung auf neue Hardware und eine VMwaren 6 Umgebung umgehoben wurde. VMware-Tools sind aktualisiert und alle anderen Server laufen völlig normal. Deshalb habe ich das als Ursache "eigentlich" erst mal ausgeschlossen.

 

Ich hab mal ein paar Screenshots mit angehangen, "mhbfw01" ist unsere Firewall (Sophos UTM9)

 

Bin momentan etwas ratlos. Der Server lief bis jetzt völlig problemlos seit mehr als 4 Jahren.

 

Grüße

Matthias

[djmaker 95]

Du könntest ein Ticket bei VMware aufmachen . . . . siehe auch https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007842

[addy0604 11]

Hallo djmaker,

 

ich gehe die Sachen morgen mal durch und halte dich auf dem Laufenden...

[massaraksch 41]

Hi,

 

Exchange stellt auf diesen hohen dynamischen Ports normalerweise RPC-Verbindungen zu Clients im internen Netz her. Kannst ja mal schauen, welcher Prozeß das ist (Parameter -o bei netstat gibt die PID aus, oder mit TCPView.exe von Microsoft/Sysinternals gleich der Klarname).

 

Sind die Clients "hinter" der Firewall (vom Exchange aus gesehen)?

 

Wurde etwas an der Firewall geändert? Oder hat sich etwas am Server beim Umstieg auf die neue VMWare geändert? Evtl. neue IP-Adresse? Konfiguration an der Firewall angepaßt... Portfreigaben etc.?

 

Nachtrag:

Man kann die Nutzung der dyn. Ports auch einschränken auf fixed Ports, siehe

https://technet.microsoft.com/en-us/library/ee332317(v=exchg.141).aspx

(Abschnitt "Configure IP Ports")

bearbeitet 4. Januar 2017 von massaraksch

[Nobbyaushb 1.471]

Moin,

bevor du auf fixed Ports gehst - welche Netzwerkkarte war vorher in der VM, welche ist das jetzt?

 

;)

[addy0604 11]

Hallo,

 

vielen Dank für die Antworten.

Ich bin fündig geworden. Mit TCPView (danke an massaraksch) konnte ich sehen, das der Antipam-Prozess vom Kaspersky for Exchange alle paar Sekunden eine neue Verbindung hergestellt, aber die alten nicht freigibt. Sie behalten den Status "Schießen_warten".

 

Ich machen dann mal einen Call bei Kaspersky auf. Dieser Beitrag kann geschlossen werden.

 

Vielen Dank an alle Beteiligten...

 

Grüße

Matthias