Exchange 2003/2007, Spam, postfix, Debian, DNS

Ein Spamfilter ist gut und schön. Aber ein einmal statisch eingerichtete Filter wird von Zeit zu Zeit immer schlechter. Daher ist es sinvoll von Anfang an eine Möglichkeit zu implementieren anhand derer man den Spamfilter ständig “trainieren” kann.Die einfachste Möglichkeit ist Spammails die nicht als Spam markiert wurden zum lernen zu verwenden. Das gleiche Prinzip kann man verwenden um nicht Spammails auch als diese beandeln zu lassen.

Um dies alles möglichst einfach für den Endanwender zu realisieren beschreibe ich hier die Möglichkeit Spam & nicht Spammails in öffentlichen Ordnern zu sammeln und zur Verarbeitung an sa-learn zu übergeben . . .

[download]

Es kann bei dem Betrieb eines Exchange Servers immer wieder zu Probleme kommen. Wichtig ist in dem Fall nur, dass Sie die richigen Entscheidungen treffen anderfalls verlieren Sie Zeit oder im schlimmsten Fall Daten.

Bevor Sie anfangen zu handeln, nehmen Sie sich einen Zettel und schreiben Sie sich folgende Informationen auf.

Systeminformationen sammeln

• letzte Sicherung vom ____._____.________
• Was sagt der Eventlog
• seit wann existiert der Fehler
• was passierte in dem Zeitraum an den beteiligten System (Exchange, AD, Domain Controller, DNS-Server)
• welchen Status hat die Datenbank (mounted/umounted)?
• Prüfen Sie den freien Speicherplatz auf allen Laufwerken und beteiligten Systemen
• Speichergruppen- oder Postfachproblem?
• Gibt es Fehler/Probleme bei der DNS oder Wins Auflösung?
• ist der Globale Katalog verfügbar (welcher DC hält den GC)
• liegt ein Hardware defekt vor?
• Reicht es ein backup wiederherzustellen oder muss der aktuelle Datenbestand um jeden Preis gesichert werden

Nachdem Sie all diese Informationen zusammen getragen haben schauen Sie sich die Betreffende Datenbank an.

1. Muss verhindert werden, dass weiterhin E-Mails auf dem betroffenen System eingehen?

Diese Frage ist garnicht so uninteressant. Sollten Sie auf der Partition auf der die Log-Dateien liegen nicht mehr viel oder keinen Speicherplatz mehr haben, müssen Sie unter Umständen den Exchange Transport Dienst stoppen um zu vermeiden, dass die Festplatte ganz volläuft oder Ihr Reperaturversuch, der unter Umständen einige Zeit dauern kann, gestört wird, weil auf einmal der Speicherplatz alle ist.

2. Dismounten Sie die Datenbank

Für faste alle Reperaturarbeiten ausgenommen einder Datenbank Wiederherstellung muss die DB offline genommen werden.

Machen Sie insofern Sie genügend Speicherplatz haben eine Sicherung der DB+check Datei sowie ALLER Logs der entsprechenden Speichergruppe. Achten Sie bei einem CCR darauf, dass Sie auch die E00.log erwischen, denn diese ist nur auf dem aktiven Knoten vorhanden. Eine Sicherung der Log-Dateien am passiven Knoten wäre damit nicht ausreichend

3. Prüfen der Vollständigkeit der Transaktionslogs

D:\Programme\Exchsrvr\MDBDATA>d:\Programme\Exchsrvr\bin\eseutil.exe /ml E00 > log.txt
Initiating FILE DUMP mode...

Verifying log files...
     Base name: E00

      Log file: D:\Programme\Exchsrvr\MDBDATA\E000002B.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E000002C.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E000002D.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E000002E.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E000002F.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000030.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000031.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000032.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000033.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000034.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000035.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000036.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E0000037.log - OK
      Log file: D:\Programme\Exchsrvr\MDBDATA\E00.log - OK

No damaged log files were found.

Operation completed successfully in 5.31 seconds.

Dieser Vorgang dauert etwas, Sie können daher schonmal weiter gehen.

3. Konsistenz der Datenbank prüfen

eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.edb" | find /i "consistent"
Last Consistent: (0x38,F3,5C) 03/04/2007 22:52:12

Das Datum ermöglicht Ihnen, festzustellen wann die Datenbank das letzte mal konsistent war. Dies kann für die Auswahl des Backups von interesse sein.

4. shutdown status der Datenbank prüfen

eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.edb" | find /i "shutdown"
State: Clean Shutdown

Ein Dirty Shutdown ist immer schlecht. Liegt dieser Fall vor, sollten Sie folgende Schritte versuchen

• Defragmentierung
• Log-Replay
• erneute Defragmentierung
• Soft Repair
• Hard Repair (es gehen sehr wahrscheinlich Daten verloren)

5. prüfen von wann das letzte backup ist – ist die auch physikalisch noch vorhanden?

eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.edb"
Previous Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Previous Incremental Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Current Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Current Shadow copy backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

6. prüfen welche Logs für eine Konsistente DB benötigt werden

eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.edb" | find /i "Log Required"
Log Required: 0-0 (0x0-0x0) eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.stm" | find /i "Log Required"
Log Required: 0-0 (0x0-0x0)

In diesem Fall werden keine Log-Dateien benötigt. Steht bei “Log Required” etwas anderes, stellen Sie sicher das die Log-Dateien alle noch vorhanden sind.

Sollten Sie wirklich keine Logs für eine Konsistente DB benötigen und die Log partition lediglich voll gelaufen sein, so ist es das beste die Log Datei Sequenz zurücksetzten.

7. evtl. Signatur der Datenbank prüfen

eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.edb" | find /i "DB Signature"
DB Signature: Create time:09/20/2006 22:06:10 Rand:214080366 Computer:

eseutil /mh "D:\programme\Exchsrvr\MDBDATA\priv1.stm" | find /i "DB Signature"
DB Signature: Create time:09/20/2006 22:06:10 Rand:214080366 Computer:

8. Log Datei Sequenz zurück setzten

Um die Log Sequenz zurück zu setzten müssen Sie sicherstellen, dass die DB in einem “Clean Shutdown” Status ist und keine weiteren Log Dateien benötigt werden. Anschließend verschieben Sie alle Log-Dateien sowie chk Dateien in einen anderen Ordner und mounten Sie die DB erneut. Exchange fängt nun an neue log-Dateien mit von bei Null an beginnenden Sequenznummer zu erstellen.

restore.env

Haben Sie eine Datenbank aus einer Sicherung wiederhergestellt und die Log-Dateien noch nicht replayed können Sie – insofern nur die wiederhergestellten Log-Dateien replayed werden müssen – dies anhand der restore.env machen.

eseutil /cc /T restore.env

Defragmentierung

eseutil /d "D:\programme\Exchsrvr\MDBDATA\priv1.edb"

Log Replay

Um die Datenbank auf den aktuellen Stand zu bringen, können die Log-Dateien manuell eingespielt werden. Dazu begeben Sie sich in den Ordner der Log-Dateien.

eseutil /R E00 /i /dD:\programme\Exchsrvr\MDBDATA\

soft repair (Eseutil)

1. Heben Sie die Bereitstellung des Öffentlichen- sowie des Postfachspeichers auf.
2. starten Sie dem soft repair Vorgang
   eseutil /r E00 /l ..\MDBDATA
3. Prüfen Sie den Status sowie die Checksumme der Datenbank erneut
4. Informationsspeicher wieder bereitstellen
5. Eventlog & Systemmanager überprüfen
   Hard repair (Eseutil)
   Das Hard repair sollte nur dann verwendet werden wenn:
   nicht mehr alle Logfiles zur Reparatur vorhanden sind
   sich die Datenbank trotz aller benötigten Logfiles nicht bereitstellen lässt

hard repair (eseutil)

Es gehen bei einem hard repair in der Regel Daten verloren!

1. Heben Sie die Bereitstellung aller zu reparierenden Informationsspeicher auf.
2. reparieren Sie die Datenbanken (Exchange 2007 hat keine stm-Dateien mehr)
   eseutil /p ..\mdbdata\priv1.edb /s ..\mdbdata\priv1.stm
   eseutil /p ..\mdbdata\pub1.edb /s ..\mdbdata\pub1.stm
3. Prüfen Sie den Status der Datenbanken
   eseutil /mb ..\mdbdata\priv1.edb
4. Anschließend die Dateien *.chk, *.log löschen so das nur noch die eigentlichen Datenbanken vorhanden sind.
5. DB mit ISInteg auf Integrität prüfen
6. Informationsspeicher wieder bereitstellen
7. Eventlog & Systemmanager überprüfen

Integrität prüfen (ISInteg)

1. Bereitstellung des Informationsspeichers aufheben
2. Integrität prüfen (es wird an der DB nichts verändert)
   isinteg -s <server> -test alltests
3. Wenn Fehler gefunden wurden, dann reparieren
   isinteg –s <server> -fix -test alltests
4. Informationsspeicher wieder bereitstellen
5. Eventlog & Systemmanager überprüfen

Hinweis zum CCR

•  nur auf dem aktiven Knoten sind alle Log-Dateien vorhanden. Auf dem Passiven fehlt die E0x.log
• Ein Backup auf dem aktiven Knoten bei einer nicht konsistentes des CCR bringt Ihnen nichts außer einem Backup. Die Log-Dateien bleiben aller erhalten. Erst nach einer Erfolgreiche Replizierung aller Logs auf den Passiven Knoten werden die nicht mehr benötigten logs gelöscht.
• Haben Sie Probleme mit einer DB halten Sie zuerst die Speichergruppenreplikation an. Dies ermöglicht Ihnen auf dem aktiven Knoten das Problem zu lösen, während Sie auf dem passiven ein Backup der Daten haben. Dies geht allerdings nur, wenn die Log-Partition der entsprechenden Speichergruppe noch über ausreichend Plattenplatz verfügt.