7
Exchange 2007 Transportdienst startet nicht, auch nach Löschen vom Queue-Verzeichnis
Guten Tag,
Nach hartem Ausschalten kann der Exchangeserver keine Nachrichten mehr übermitteln, Der Transportdienst lasst sich nicht starten. Zuerst mahnte er das Fehlen bestimmter Trnxxxxx.log an, jetzt, nachdem ich das Queue-Verzeichnis geplättet habe, erstellt er zwar Teile der Daten neu, aber (aus Ereignisanzeige, Fehlerquelle MSExchangetransport, Fehlernummer 17005):
Transportvorgang für Maildatenbank: Die Datenbank konnte nicht geöffnet werden, weil eine Protokolldatei fehlt oder fehlerhaft ist. Der Microsoft Exchange-Transportdienst wird beendet. Möglicherweise ist eine manuelle Wiederherstellung oder Reparatur der Datenbank erforderlich. Die Ausnahme ist Microsoft.Exchange.Isam.IsamDatabaseDirtyShutdownException: Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown. (-550)
bei Microsoft.Exchange.Isam.?A0x4cb6fe23.HandleError(Int32 err)
bei Microsoft.Exchange.Isam.?A0x4cb6fe23.CallW(Int32 errFn)
bei Microsoft.Exchange.Isam.Interop.MJetAttachDatabase(MJET_SESID sesid, String file, MJET_GRBIT grbit)
bei Microsoft.Exchange.Isam.Interop.MJetAttachDatabase(MJET_SESID sesid, String file)
bei Microsoft.Exchange.Transport.Storage.DataSource.OpenDatabase().
Eine mail.que existiert nicht. Eine tmp.edb existiert nicht. Wird das Queue-Verzeichnis gelöscht, legt er es beim Startversuch brav an, um dann zu scheitern.
In meiner Verzweiflung habe ich den Exchangeserver schon aus dem Backup als Anwendung wiederhergestellt. Mit keinem Erfolg.
Was nun?!
Gruss,
der onkel
Nach hartem Ausschalten kann der Exchangeserver keine Nachrichten mehr übermitteln, Der Transportdienst lasst sich nicht starten. Zuerst mahnte er das Fehlen bestimmter Trnxxxxx.log an, jetzt, nachdem ich das Queue-Verzeichnis geplättet habe, erstellt er zwar Teile der Daten neu, aber (aus Ereignisanzeige, Fehlerquelle MSExchangetransport, Fehlernummer 17005):
Transportvorgang für Maildatenbank: Die Datenbank konnte nicht geöffnet werden, weil eine Protokolldatei fehlt oder fehlerhaft ist. Der Microsoft Exchange-Transportdienst wird beendet. Möglicherweise ist eine manuelle Wiederherstellung oder Reparatur der Datenbank erforderlich. Die Ausnahme ist Microsoft.Exchange.Isam.IsamDatabaseDirtyShutdownException: Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown. (-550)
bei Microsoft.Exchange.Isam.?A0x4cb6fe23.HandleError(Int32 err)
bei Microsoft.Exchange.Isam.?A0x4cb6fe23.CallW(Int32 errFn)
bei Microsoft.Exchange.Isam.Interop.MJetAttachDatabase(MJET_SESID sesid, String file, MJET_GRBIT grbit)
bei Microsoft.Exchange.Isam.Interop.MJetAttachDatabase(MJET_SESID sesid, String file)
bei Microsoft.Exchange.Transport.Storage.DataSource.OpenDatabase().
Eine mail.que existiert nicht. Eine tmp.edb existiert nicht. Wird das Queue-Verzeichnis gelöscht, legt er es beim Startversuch brav an, um dann zu scheitern.
In meiner Verzweiflung habe ich den Exchangeserver schon aus dem Backup als Anwendung wiederhergestellt. Mit keinem Erfolg.
Was nun?!
Gruss,
der onkel
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: 253956
Url: https://administrator.de/contentid/253956
Ausgedruckt am: 25.11.2024 um 23:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo Onkel,
dann wirst du wohl oder Übel eine Datenbankrettung bzw. repair machen müssen, da sich sich deine Datenbank im Dirty shutdown befindet.
Exchange Datenbankrettung:
Zustandüberprüfen:
Eseutil /mh
Wenn bei Konsistenz „Dirty shut down“ steht, Recovery Mode starten
1.
Ins Log Verzeichnis gehen schauen wie die log Datei *.chk heißt (meistens E00.chk kann aber abweichen)
2.
*.chk datei löschen und versuchen die Datenbank wieder bereit zu stellen, je nach wie viele logs da sind kann das ne stunde dann dauern, wenn das nicht funktionieren sollte…
1.
Folgenden befehl im CMD ausführen:
Eseutil /r e00 /de:\EXchangeDB\DB3.edb /lc:\exlog\sg3\ /a /i
passer entsprechende Datenbanknamen an
1.
Wenn das nicht hilft muss ein Repair durchgeführt werden:
Eseutil /p e:\exchangedb\db3.edb
Bei einem repair kann der Vorgang „Deleting unicode fixup table“ bis zu 16 Stunden dauern, pro Datenbank
Greetz
Criemo
dann wirst du wohl oder Übel eine Datenbankrettung bzw. repair machen müssen, da sich sich deine Datenbank im Dirty shutdown befindet.
Exchange Datenbankrettung:
Zustandüberprüfen:
Eseutil /mh
Wenn bei Konsistenz „Dirty shut down“ steht, Recovery Mode starten
1.
Ins Log Verzeichnis gehen schauen wie die log Datei *.chk heißt (meistens E00.chk kann aber abweichen)
2.
*.chk datei löschen und versuchen die Datenbank wieder bereit zu stellen, je nach wie viele logs da sind kann das ne stunde dann dauern, wenn das nicht funktionieren sollte…
1.
Folgenden befehl im CMD ausführen:
Eseutil /r e00 /de:\EXchangeDB\DB3.edb /lc:\exlog\sg3\ /a /i
passer entsprechende Datenbanknamen an
1.
Wenn das nicht hilft muss ein Repair durchgeführt werden:
Eseutil /p e:\exchangedb\db3.edb
Bei einem repair kann der Vorgang „Deleting unicode fixup table“ bis zu 16 Stunden dauern, pro Datenbank
Greetz
Criemo
nach dem Repair kannste dann die Datenbank bereitstellen und den Transportdienst erneut starten!
Hallo,
Der Informations-Speicher startet und steht zur Verfügung. Benutzer können auf Ihr Postfach zugreifen. Aber ich kann ja mal trotzdem einen eseutil /MH darauf loslassen... So wirklich glaube ich aber nicht, das es daher kommt.
Gruss, der Onkel
Der Informations-Speicher startet und steht zur Verfügung. Benutzer können auf Ihr Postfach zugreifen. Aber ich kann ja mal trotzdem einen eseutil /MH darauf loslassen... So wirklich glaube ich aber nicht, das es daher kommt.
Gruss, der Onkel
Das hat damit nichts zu tun.
es steht eindeutig da....
es steht eindeutig da....
Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown. (-550)
Servus,
nun ist es so - und das ohne Deinen Willen zur Hilfe irgendwie kränken zu wollen - dass die Datenbank des Exchange, in der die Postfächer sind, nichts, aber auch gar nichts mit dem Transportdienst an sich zu tun hat. Dennoch habe ich es geprüft, sie zeigt einen Clean Shutdown.
Der Transportdienst verwendet eine eigene Mail.que, die im Moment nicht existiert, und eine tmp.edb, die ebenfalls im Moment nicht existiert. Beide sollte er bei Start des Dienstes selbstständig anlegen, wenn diese fehlen. Das tut er nicht, und plus extra er findet eine unsaubere Datenbank. Ich habe auch den Pfad zur Queue in der .config geprüft, der stimmt.
Weitere Ideen - ich habe nämlich keine?!
Gruss, der Onkel
nun ist es so - und das ohne Deinen Willen zur Hilfe irgendwie kränken zu wollen - dass die Datenbank des Exchange, in der die Postfächer sind, nichts, aber auch gar nichts mit dem Transportdienst an sich zu tun hat. Dennoch habe ich es geprüft, sie zeigt einen Clean Shutdown.
Der Transportdienst verwendet eine eigene Mail.que, die im Moment nicht existiert, und eine tmp.edb, die ebenfalls im Moment nicht existiert. Beide sollte er bei Start des Dienstes selbstständig anlegen, wenn diese fehlen. Das tut er nicht, und plus extra er findet eine unsaubere Datenbank. Ich habe auch den Pfad zur Queue in der .config geprüft, der stimmt.
Weitere Ideen - ich habe nämlich keine?!
Gruss, der Onkel
HI,
Das ist ja super dass du das gemacht hast,
meine frage ist hast du das auch für die Transportdatenbank (mail.que) gemacht?
wäre ja sinnvoll?!
http://technet.microsoft.com/de-de/library/aa998231(v=exchg.80).aspx
http://exchangeserverpro.com/event-id-454-and-17003-a-corrupt-sender-re ...
Gruß
Criemo
Das ist ja super dass du das gemacht hast,
meine frage ist hast du das auch für die Transportdatenbank (mail.que) gemacht?
wäre ja sinnvoll?!
http://technet.microsoft.com/de-de/library/aa998231(v=exchg.80).aspx
http://exchangeserverpro.com/event-id-454-and-17003-a-corrupt-sender-re ...
Gruß
Criemo
Wie ich bereits schrieb, war die mail.que nicht vorhanden, und wurde auch nicht angelegt.
Sonst hätte ich die herzlich gerne geprüft.
Aaaaber, ich habe das Ding jetzt gelöst. ich habe einen neuen Pfad in der Edgetransport Config angelegt, und siehe da, dort wurde dann alles ordnungsgemäss erstellt und lief.
Was war das Problem? Die Rechte im Verzeichnis stimmten, es wurden Dateien (die Logs) angelegt (deshalb war wohl auch das Dateisystem selber intakt), usw.
Für das nächste Mal nehme ich mit: wenn eine automatische Funktion nicht tut, was sie soll, sag ihr, sie soll es woanders tun :/
Fertig,
der Onkel
Sonst hätte ich die herzlich gerne geprüft.
Aaaaber, ich habe das Ding jetzt gelöst. ich habe einen neuen Pfad in der Edgetransport Config angelegt, und siehe da, dort wurde dann alles ordnungsgemäss erstellt und lief.
Was war das Problem? Die Rechte im Verzeichnis stimmten, es wurden Dateien (die Logs) angelegt (deshalb war wohl auch das Dateisystem selber intakt), usw.
Für das nächste Mal nehme ich mit: wenn eine automatische Funktion nicht tut, was sie soll, sag ihr, sie soll es woanders tun :/
Fertig,
der Onkel
