Schlagwort-Archive: Exchange

SMTP-Probleme unter Exchange 2010

Ab und zu schicken wir einen Newsletter an bis zu 10.000 Empfänger. Dazu verwenden wir ein extra Programm, das die Mails anonym per SMTP am Exchangeserver abliefert. Unter Exchange 2003 war das nie ein Problem. Vor ein paar Wochen habe ich die Migration auf Exchange 2010 durchgeführt und seitdem dauert der Versand ein Vielfaches. Zuerst hatte ich das “TarpitInterval” in Verdacht, das jede anonym abgelieferte Mail um (im Standard) 10 Sekunden verzögert. Dadurch soll die Funktion des Servers bei Spamattacken erhalten werden. Das TarpitInterval kann man in der Exchangepowershell wie folgt auf eine Sekunde reduzieren:

set-ReceiveConnector "Connector" -TarpitInterval 00:00:01

Alternativ kann man natürlich auch eine gesicherte Verbindung einrichten, dann greift diese Verzögerung sowieso nicht. Für mein Newsletterproblem brachte das noch nicht wirklich etwas, jedoch wurden dadurch Mailscans von den Kopierern beschleunigt.

Für die verzögerte Annahme der Massenmails war der Parameter “MaxAcknowledgementDelay” verantwortlich. Exchange bestätigt die Annahme einer Mail in einem bestimmten Zeitfenster, das über diesen Parameter gesetzt wird. Gebraucht wird dies für die Shadow-Redundanz bei hochverfügbaren Systemen. Fällt ein Transportserver aus, wird trotzdem sichergestellt, dass keine Mail verloren geht. Im Standard steht dieser Parameter auf 30 (!) Sekunden. Sprich es kann 30 Sekunden dauern, bis das OK zurückkommt, dass die Mail übertragen wurde.

Abschalten kann man diese Verzögerung in der Shell:

set-ReceiveConnector "Connector" -MaxAcknowledgementDelay 0

Mehr zum Thema:

Grundlegendes zur Shadow-Redundanz

Konfigurieren von Shadow-Redundanz

Kaspersky Security 8 für Microsoft Exchange Server stürzt ständig ab

Auf unserem Exchange 2010 haben wir Kaspersky Security 8 für Microsoft Exchange Server als zusätzlichen Virenscanner laufen. Seit heute Nacht gab es ein Problem mit dem zugehörigen Dienst. Dieser beendete sich ständig selbst und die eigene Überwachung startete den sofort wieder neu. Das Ergebnis war, dass der Exchangeserver die weiße Fahne hisste und seinen Dienst einstellte. Im Ereignisprotokoll fand sich dann folgender Eintrag:

Name der fehlerhaften Anwendung: kavscmesrv.exe, Version: 8.0.5286.0, Zeitstempel: 0x4cb3fa77
Name des fehlerhaften Moduls: UpdSdk.dll, Version: 8.0.1.24, Zeitstempel: 0x4c3d9a47
Ausnahmecode: 0xc0000409
Fehleroffset: 0x0000f2e0
ID des fehlerhaften Prozesses: 0x2554
Startzeit der fehlerhaften Anwendung: 0x01cb96acf8030876
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security 8.0 for Microsoft Exchange Servers\kavscmesrv.exe
Pfad des fehlerhaften Moduls: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security 8.0 for Microsoft Exchange Servers\UpdSdk.dll
Berichtskennung: 43c59b99-02a0-11e0-9d68-78e7d1e811f8

Wie in der Fehlermeldung schon beschrieben steht, war die Datei UpdSdk.dll schuld, die wohl mit einem der letzten Updates fehlerhaft ausgeliefert wurde. Kaspersky hat nach rund einem Tag reagiert und eine berichtigte Datei (Beta) nachgeschoben, die man aber manuell einspielen muss:

How to restore KSE 8.0 functions:
1. Download and extract the archive on a host with Kaspersky Security 8.0 – server part installed.  updsdk.zip ( 443.47KB )
2. Close the Kaspersky Security 8.0 console.
3. Rename the updsdk.dll in the application folder.
4. Copy the updsdk.dll file you have downloaded into the application folder.
5. Start the Kaspersky Security 8.0 console and run a database update task.

Mit dieser Datei funktioniert es wieder problemlos. Der Witz an der Sache ist aber, dass man ohne Anmeldung nicht ins Supportforum kommt.

Das ist bereits das zweite Mal, dass Kaspersky mit einem fehlerhaften Update einen meiner Server abschießt. Ungefähr vor zwei Jahren war es aber weit dramatischer. Da musste man zur Fehlerbehebung an jedem Client Hand anlegen.