onkel87
Goto Top

Exchange Datenbank schon 3 mal defekt dieses Jahr

Ich habe zwischen den Jahren mein Server virtualisiert auf ESX-I soweit so gut - alles funktionierte, irgendwann habe ich dann noch zusätzlich einen neuen Account für einen Mitarbeiter erstellt. Eines Morgens geht noch alles bis ca. 10Uhr von einmal hatte ich keinen Outlook zugriff somit bin auf den Server und sehe unter SystemManger der Postfachspeicher ist nicht bereitgestellt, als ich dann bereitstellen wollte kam eine Fehlermeldung. Datenwiederherstellung es lief wieder alles weiter....

Mitlerweile ist das jetzt schon 3x passiert und da wir in der Firma sehr auf Mails Kalender und Kontakte angewiesen sind ist sowas sehr schlimm. Zur gegebenheit:

- MS Windows SBS 2003 32bit File, Domäne, Exchange
- MS Windows 2008 64bit Branchensoftware
- MS Windows 2003 32bit Terminal

Clients Outlook 2007

Nun dachte ich es liegt vllt. an dem neuen account und habe ihn gelöscht und neu erstellt, heute hatte ich das gleiche Problem wieder, 8Uhr ging alles ca. 11Uhr Crash.

Ich bin nun echt verzweifelt und suche nach dem Fehler....Habt ihr eine Idee? Wäre dankbar um jede Idee...

Das Ereignisprotokoll habe ich hochgeladen:

Anwendungen: http://www.fileuploadx.de/595874
System: http://www.fileuploadx.de/49030


Ich dank euch jetzt schon.

Falls ihr noch Infos brauch einfach schreiben.

Content-ID: 134185

Url: https://administrator.de/contentid/134185

Ausgedruckt am: 22.11.2024 um 13:11 Uhr

nic7575
nic7575 23.01.2010 um 19:45:29 Uhr
Goto Top
Hallo,

Du wirst Deine Streamingdatei reparieren müssen. -> http://support.microsoft.com/kb/320705/de

Im Systemprotokoll fällt aber auf, dass Du offenbar ein massives NTP-Problem hast. Die Zeit hüpft auf Deinem Server wild hin und her. Ist das vielleicht ne virtuelle Maschine ? VMWare ?

Bevor Du das Zeitproblem nicht in den Griff bekommst wird Dir der Exchange immer wieder abstürzen !
rs-schmid
rs-schmid 23.01.2010 um 20:24:53 Uhr
Goto Top
Hallo,

lies diesen Artikel mal.
http://support.microsoft.com/kb/896143/en-us

Backups sind vorhanden ?

Gruss Roland
rs-schmid
rs-schmid 23.01.2010 um 21:00:03 Uhr
Goto Top
Zitat von @nic7575:
Bevor Du das Zeitproblem nicht in den Griff bekommst wird Dir der Exchange immer wieder abstürzen !

den ntp dienst sollte er in den griff kriegen, glaube aber nicht, dass das die ursache ist.
vermute es sind folgen des umzugs des SBS2003 auf die virtuelle maschine.
exchange datenbank inkonsistent oder log files weg oder oder oder.
würde die möglichen ursachen in dem artikel durcharbeiten.
http://support.microsoft.com/kb/896143/en-us

Gruss Roland
nic7575
nic7575 23.01.2010 um 21:27:27 Uhr
Goto Top
Also wenn die Logfiles ständig mit wirren Timestamps gescrieben werden versagt mein Exchange sofort den Dienst ! Da ich nicht weiß ob der TO wirklich das ganze in ner VM betreibt ist das ganze auch nur ne Vermutung von mir (-;

Vielleicht bekommen wir ja noch weitere Info's ....
rs-schmid
rs-schmid 23.01.2010 um 21:54:42 Uhr
Goto Top
ja, ohne weitere info's bleibt es spekulativ
aber fest steht, dass sein exchange store dismountet ist.
hinweise für das warum stehen ja bereits in der ereignisanzeige anwendungen
onkel87
onkel87 24.01.2010 um 13:31:43 Uhr
Goto Top
erstmal vielen dank....

gestern abend war es schon wieder....die abstände werden kürzer.... face-sad face-sad

Das mit der Zeit habe ich rechts unten ganz normal bei der Uhr geschaut -> ist aktuell
bei den VMWARE Tools ist die Zeit Sync ausgeschalten mit dem Host.
DHCP hab ich den Zeitserver noch drin.
GIbts da sonst noch was?

http://support.microsoft.com/kb/896143/en-us
-> gehen dabei datenverloren?

Umzug von REAL to Virtuell der Datenbank habe ich so gemacht:
Exchange Dienste aus; MDBDATA ordner kopiert und die Dienste wieder gestartet ging dann am anfang problemlos. (1Woche)

Virenschutz mach ich jetzt auch noch einen neuen drauf.

Gibt es tools womit ich die Datenbank überprüfen kann?
onkel87
onkel87 24.01.2010 um 13:48:49 Uhr
Goto Top
C:\Programme\Exchsrvr\MDBDATA

dort habe 3665 Dateien!!! das ist doch nicht normal oder?

priv1.edb
priv1.stm
pub1.edb
tmp.edb
pub1.stm
E00.chk

der rest sind .log
rs-schmid
rs-schmid 24.01.2010 um 19:07:35 Uhr
Goto Top
Zitat von @onkel87:
http://support.microsoft.com/kb/896143/en-us
-> gehen dabei datenverloren?

backup oder offline kopie sollte schon da sein, mit der datenbank spielt man nicht ohne backup zu haben.
Ist denn der alte exchange (vor dem umzug) noch existent?

Umzug von REAL to Virtuell der Datenbank habe ich so gemacht:
Exchange Dienste aus; MDBDATA ordner kopiert und die Dienste wieder gestartet ging dann am anfang problemlos. (1Woche)

bist du so vorgegangen ? (blauer Text)


1. WICHTIG: Zuallerst den Organisationsnamen des bestehenden Exchange rausschreiben (sieht man im Exchange Systemmanager, oberste Ebene "Organisationsname (Exchange)")...
2. Empfängerrichtlinie und SMTP-Connector rausschreiben.
3. Postfach + öffentlicher Speicher im Exchange System-Manager beenden (Bereitstellung aufheben)
4. Anschließend den Dienst "Microsoft Exchange-Informationsspeicher" im Dienstemanager des Servers ebenfalls beenden. Dann die Speicher aus dem Exchange-Unterverzeichnis MDBDATA namens (pub1.edb, pub1.stm, priv1.edb, priv1.stm) wegsichern (kopieren). Zur Info: Das nennt man Offlinesicherung. Andere Dateien werden zur Wiederherstellung nicht gebraucht !
5. WICHTIG: Der Organisationsnamen des neu aufgesetzten Exchange MUSS ZWINGEND genau so heißen, wie der alte, sonst kann später die Datenbank nicht eingepatcht werden, der neue Servername kann anders lauten, wenn man eine neue Maschine aufsetzt und die Datenbank dort einpatchen will.
6. Dann Exchange komplett deinstallieren, incl. der Organisation im Active Directory. Bei der Deinstallation wird man aufgefordert die Postfächer zu deaktivieren, bzw. zu löschen, dass ist aber kein Problem und kann man problemlos tun, da die Datenbank weggesichert wurde, die Postfächer bleiben darin erhalten.
7. Wenn möglich (wenn sonst nichts im IIS läuft) auch den IIS komplett deinstallieren (incl. SMTP, ASP.NET, NNTP, usw.), rebooten und den IIS nochmal komplett neu installieren. Am besten vor der Neuinstallation des IIS auch das ganze Verzeichnis C:\Inetpub löschen.
8. Anschließend Exchange komplett neu installieren, auf eine andere Partition/Verzeichnis, oder in das gleiche Verzeichnis, das alte Verzeichnis dann vorher nach _Old umbennen. (setup /forestprep und setup /domainprep) nochmals ausführen.
9. Neue Installation nach Reboot beginnen und gleichen/alten Organisationsnamen ohne (Exchange) verwenden. Auch gleichen Installationsaccount nehmen. Nach erfolgreicher Installation, alle SP's und Patches einspielen, die auch vorher drauf waren. Wenn Exchange dann fehlerfrei läuft (Eventlogs checken), bei Postfachspeicher und Öffentlichem Speicher im Systemmanager die Bereitstellung aufheben und den Dienst Microsoft Informationsspeicher beenden.
10. Neu angelegte Dateien im MDBDATA Verzeichnis komplett löschen (sind sowieso ohne Inhalt), und die gesicherten Postfachspeicher priv1.edb, priv1.stm, pub1.edb, pub1.stm in das gleiche Verzeichnis MDBDATA reinkopieren oder verschieben. Ich empfehle aber kopieren. Macht man Mist, kann man's noch mal wiederholen, wenn man das unveränderte Original noch hat !!!!
11. Im Systemmanager von Exchange auf Postfachspeicher und Öffentlichem Speicher einstellen, das die Datenbanken bei einer Wiederherstellung überschrieben werden dürfen.
12. Rebooten und er sollte die Datenbanken eingepatcht haben und die öffentlichen Ordner und Postfächer sollten wieder da sein.
13. Wenn er die Datenbanken nicht starten konnte, diese im Verzeichnis MDBDATA mit eseutil /p priv1.edb, bzw. eseutil /p pub1.edb reparieren und dann mit eseutil /d priv1.edb und eseutil /d pub1.edb defragmentieren und booten wiederholen. Defragmentieren evt. mehrmals wiederholen !!!
14. Dafür vorher am besten die Umgebungsvariable Path auf LW:\Exchangeverzeichnis\bin erweitern.
15. WICHTIG: Der Dienst "Microsoft Exchange Informationsspeicher" muss zur Reparatur und Defragmentierung gestartet sein, die Speicher im Exchange Systemmanager jedoch nicht !
16. Anschließend noch auf dem Postfachspeicher mit Rechtsklick ein "Cleanup" ausführen (keinesfalls "leeren" wählen, dies löscht die zum löschen markierten Postfächer endgültig) und die Postfächer, die jetzt rot markiert sind wieder mit ihren Usern im Active Directory verbinden. Diverse Systempostfächer sind jetzt doppelt vorhanden, die rot markierten können gelöscht werden. BE CAREFULL!
17. Achtung: Nur die im Exchange Systemanager rot markierten im Postfachspeicher löschen, keinesfalls die Systemmailbox die im Active Directory rot markiert ist. Diese wird benötigt, und wird in der Standardansicht auch nicht angezeigt !!!
18. Exchange ist jetzt neu installiert und benutzt die vorher weggesicherte alte 2000/2003 Datenbank. Alle User-Mails und öffentlichen Ordner sind nach wie vor vorhanden.
19. Am Schluss Empfängerrichtlinie und SMTP-Connector wieder einstellen und alle Probleme sollten endgültig gelöst sein.
20. WICHTIG: Exchange 2003 setzt die maximale Größe zu empfangender/versendbarer Mail bei einer Erstinstallation standardmäßig auf 10240KB, also 10MB. Evt. anpassen wenn nötig.



Gibt es tools womit ich die Datenbank überprüfen kann?

ja, ESEUTIL (in konsole ausführen)
(z.B. eseutil /k "c:\program files\exchsrvr\mdbdata\pub1.edb" prüft den public folder store)
(z.B. eseutil /k "c:\program files\exchsrvr\mdbdata\priv1.edb" prüft den mailbox store)

Gruss Roland
rs-schmid
rs-schmid 24.01.2010 um 19:55:15 Uhr
Goto Top
Zitat von @onkel87:
C:\Programme\Exchsrvr\MDBDATA

dort habe 3665 Dateien!!! das ist doch nicht normal oder?

priv1.edb
priv1.stm
pub1.edb
tmp.edb
pub1.stm
E00.chk

der rest sind .log

nein, nicht wirklich, theoretisch sind 1048575 Protokolldateien pro speichergruppe möglich,
die *.log files sind transaktionsfiles.
in den transaktionsfiles werden änderungen vorerst festgehalten, bevor sie in die datenbank geschrieben werden.
(user senden/erhalten mails etc. etc.)
die letzte heisst immer E00.log
mit diesen files ließe sich die eventuell inkonsistente exchange datenbank konsistent machen (Roll Forward)
dein exchange dürfte sehr lange fürs herunterfahren brauchen

Gruss Roland
GuentherH
GuentherH 24.01.2010 um 20:13:47 Uhr
Goto Top
Hallo.

und da wir in der Firma sehr auf Mails Kalender und Kontakte angewiesen sind ist sowas sehr schlimm
dort habe 3665 Dateien!!! das ist doch nicht normal oder?

Diese beiden Sätze passen doch zusammen, wie die sprichwörtiche Faust aufs Auge. Wie kann es sein, dass Mail und Kalender extrem wichtig ist, aber keine ordentliche Datensicherung durchgeführt wird.

Bei einer ordentlichen Datensicherung mit NT-Backup oder einem Backupprogramm mit Exchange Agent werden die Transaktionslogs nach einer korrekten Datensicherung gelöscht.

- führe zuerst eine ordentliche Datensicherung durch
- überprüfe deinen Virenscanner, ob auch wirklich alle Exchange Verzeichnisse ausgeschlossen sind

LG Günther
rs-schmid
rs-schmid 24.01.2010 um 20:58:29 Uhr
Goto Top
ja, die vielen transaktionsfiles sprechen für kein ordentliches backup
sonst wären sie -wie du schon gesagt hast- gelöscht, weil nämlich in datenbank geschrieben.

Gruss Roland
onkel87
onkel87 24.01.2010 um 22:50:09 Uhr
Goto Top
Hallo,

also backup machen wir täglich intern und extern mit Acronis SBS 10.
das ist natürlich komisch wenn das nich klappt - weil lt. Log von Acronis funktioniert es.

Bei den ganzen Fehlern zur Zeit habe ich immer ein Snapshot zurückgespielt von ESXI statt acronis,kann es mit dem zusammen hängen?

Ich haben ESEUTIL durchlaufen lassen hier die Ergebnisse:

http://www.2shared.com/file/10879750/c61371dc/exchange1.html
http://www.2shared.com/file/10879750/c61371dc/exchange1.html

Ich habe das ganze mit VMWare Converter damals in den ESXI virtualisiert und wo dann alles lief und die arbeitsplätze noch auf der real maschine,
war natürlich der datenbestand zu alt dann habe ich jeweils die dienste von exchange beendet und den MDBDATA ordner rüberkopiert und die dienste gestartet
dann ging wieder alles!

Die Datenbank läuft grad wieder alles gut bis morgen evtl. dann ist Sie wieder defekt!?
Was wäre die beste Lösung damit ich das Problem weg bekomme?
Was soll ich mit dem Zeitproblem machen? Wo hab ich noch eine möglichkeit das einzustellen zu kontrollieren?

danke!
GuentherH
GuentherH 24.01.2010 um 23:20:25 Uhr
Goto Top
Hallo.

also backup machen wir täglich intern und extern mit Acronis SBS 10.

Sorry, das ist ein Image Programm und kein Backup Programm

das ist natürlich komisch wenn das nich klappt - weil lt. Log von Acronis funktioniert es.

Klar, zeigt Acronis nichts an, es kann ja mit dem Exchange nicht umgehen, dazu gibt es von Acronis ein eigenes Programm

Was wäre die beste Lösung damit ich das Problem weg bekomme?

Konfiguriere die Datensicherung mit NT-Backup. Das Backupfile kannst du ja dann mit Acronis noch wegsichern

Was soll ich mit dem Zeitproblem machen?

Verwende einen externen Zeitserver. Die Boardsuche hilft dir zu diesem Thema.

Als kleiner Tipp. Poste das nächste Mal nur die Fehlermeldungen aus dem Ereignisprotokoll, die interessant bzw. für das Thema relevant sind. Es ist etwas mühsam sich wenn man zuerst warten muss um ein File downzuladen, und sich dann erst die relevanten Daten selbst heraussuchen muss.

LG Günther
onkel87
onkel87 24.01.2010 um 23:31:21 Uhr
Goto Top
ok danke - das Problem steht halt noch nach wie vor.

Eine Frage wie kann ich am schnellsten den Postfachspeicher etc. löschen damit ich eine neue Datenbank erstellen kann?
Ich muss sonst alle Postfächer erst löschen.

Ich würde gerne die Datenbank einfach neu machen das ich ein für alle mal das Problem weg habe.
Alternativ habe ich noch eine Festplatte vor der virtualisieurng. kann ich da irgendwelche Daten rüberkopieren sprich diese
GuentherH
GuentherH 25.01.2010 um 00:02:02 Uhr
Goto Top
Hallo.

Eine Frage wie kann ich am schnellsten den Postfachspeicher etc. löschen damit ich eine neue Datenbank erstellen kann?

- Bereitsstellung des Postfachspeichers aufheben
- EDB und STM Datei wegkopieren
- Transaktionslogs wegkopieren
- Postfachspeicher bereitstellen, nach einer Fehlermeldung wird der neue Postfachspeicher erzeugt und bereit gestellt

Ich würde gerne die Datenbank einfach neu machen das ich ein für alle mal das Problem weg habe

Wieso bist du dir da so sicher?

- Führe doch endlich eine korrekte Sicherung. Da bei der Datensicherung mit NT-Backup ein Konsistenzprüfung der Datenbank durchgeführt wird, erhältst du entsprechend Meldungen, wenn mit der Datenbank etwas faul ist.
- Überprüfe deinen Virenscanner, ob auch wirklich alle Exchange Verzeichnisse vom Virenscan ausgeschlossen sind
- Behebe dein Zeitproblem

LG Günther
onkel87
onkel87 25.01.2010 um 00:06:49 Uhr
Goto Top
ich spiele mein Snapshot zurück und innerhalb 10min mittlerweile ist die datenbank defekt
Da schaff ich das backup nicht.

Zeitproblem liegt daran das wenn ich den Snapshot zurückspiele dann ist die Zeit für 2-3min auf der Snapshotzeit. -> Zeit ist soweit alles korrekt eingestellt
Virenschutz programm deinstalliere ich jetzt komplett zum test (AVIRA SBS)
NTBackup mach ich.

Das Problem ist nur wir müssen morgen arbeiten und wenn der exchange nicht läuft komm ich immer wieder ins schleudern und spiele den snapshot zurück.
onkel87
onkel87 25.01.2010 um 00:20:46 Uhr
Goto Top
NTBACKUP fehlgeschlagen:

Sicherungsstatus
Vorgang: Sicherung
Aktives Sicherungsziel: Datei
Mediumname: "system-state-exchange.bkf erstellt am 25.01.2010 um 00:18"

Volumeschattenkopie-Erstellung: Versuch 1.
Sicherung von "SRV01\Microsoft Information Store\Erste Speichergruppe"
Sicherungssatz #1 auf Medium #1
Sicherungsbeschreibung: "Satz am 25.01.2010 um 00:18 erstellt"
Mediumname: "system-state-exchange.bkf erstellt am 25.01.2010 um 00:18"

Sicherungsart: Normal

Sicherung begonnen am 25.01.2010 um 00:18.
'Microsoft Information Store' wurde von 'Fehler wurde von einem ESE-Funktionsaufruf zurückgegeben (d).
' bei einem Aufruf von 'HrESEBackupGetLogAndPatchFiles()' zurückgegeben. Zusätzliche Daten: '-'.'Microsoft Information Store' wurde von 'Funktionen werden in ungültiger Reihenfolge aufgerufen.
' bei einem Aufruf von 'HrESEBackupClose()' zurückgegeben. Zusätzliche Daten: '-'.
Der Vorgang wurde beendet.
Sicherung abgeschlossen am 25.01.2010 um 00:21.
Verzeichnisse: 3
Dateien: 4
Bytes: 1.590.731.340
Zeit: 2 Minuten und 57 Sekunden


Der Vorgang wurde nicht ordnungsgemäß ausgeführt.

GuentherH
GuentherH 25.01.2010 um 07:42:47 Uhr
Goto Top
Hallo.

Der Fehler sagt eigentlich, das mit deinen Transaktionslogs etwas im Argen ist. Lösche diese, geh dabei so vor wie hier beschrieben und führe anschließend ein neues Backup durch - http://www.petri.co.il/mount_exchange_database_when_e00log_is_missing.h ...

LG Günther
onkel87
onkel87 25.01.2010 um 08:17:51 Uhr
Goto Top
ich habe heute nacht noch eine neue datenbank aufgesetzt -> ntbackup -> alles wieder gut!
Jetzt hoffe ich das dass so bleibt.

Danke! für die Informationen!