83319
May 10, 2011
4595
9
0
Exchange fällt in der Nacht meisten aus
Morgen Cummunity,
wir haben seit einigen Tagen immer wieder das Phönomen, dass über Nacht der Excange Server ausfällt und unsere Nachtschichtkollegen so gut wie keine Verbindung zum Server haben. Da kuriose dabei ist, dass sich das ganze ab 06:00 Morgens wieder gibt, sodass wir am Tag keinen Fehler am Exc mitbekommen.
Die Sicherung der Exc DB verläuft ohne irgendwelche Fehler und es werden auch in dieser Zeit definitv keine Wartungsarbeiten durchgeführt.
Im Log haben wir folgende Event´s protokolliert:
Information Store (7716) First Storage Group: A bad page link (error -327) has been detected in a B-Tree (ObjectId: 158, PgnoRoot: 619) of database E:\ExchangeServer\PostfachSpeicher\Standort\priv1.edb (24932307 => 24932308, 1684300900).
An exception with code 0xc00000fd was thrown in module C:\WINDOWS\system32\ntdll.dll; some parameters and their values were <Exception address - a61dbaa4>. A significant section of the call stack is in the data section.
Unexpected error <<0xc1050000 - Network problems are preventing connection to the Microsoft Exchange Server computer. An unexpected, unknown error has occurred. Microsoft Exchange Server Information Store ID no: 80040115-0514-000006bf>> occurred.
The MAPI call 'OpenMsgStore' failed with the following error:
The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.
The MAPI provider failed.
Microsoft Exchange Server Information Store
ID no: 8004011d-0526-00000000
Unexpected error <<0xc1050000 - The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000>> occurred.
Wie schon erwähnt, treten diese Probleme NUR in der Nacht zwischen 02:00 - 06:00 auf. Erschwerende kommt leider hinzu dass wir aufgrund der leider etwas veralteten Backupsoftware (Backup Exec 10d) nur die gesamte Exc DB recovern können und keine einzelnen Postfächer !!
BITTE UM HILFE !!!
lg
wir haben seit einigen Tagen immer wieder das Phönomen, dass über Nacht der Excange Server ausfällt und unsere Nachtschichtkollegen so gut wie keine Verbindung zum Server haben. Da kuriose dabei ist, dass sich das ganze ab 06:00 Morgens wieder gibt, sodass wir am Tag keinen Fehler am Exc mitbekommen.
Die Sicherung der Exc DB verläuft ohne irgendwelche Fehler und es werden auch in dieser Zeit definitv keine Wartungsarbeiten durchgeführt.
Im Log haben wir folgende Event´s protokolliert:
Information Store (7716) First Storage Group: A bad page link (error -327) has been detected in a B-Tree (ObjectId: 158, PgnoRoot: 619) of database E:\ExchangeServer\PostfachSpeicher\Standort\priv1.edb (24932307 => 24932308, 1684300900).
An exception with code 0xc00000fd was thrown in module C:\WINDOWS\system32\ntdll.dll; some parameters and their values were <Exception address - a61dbaa4>. A significant section of the call stack is in the data section.
Unexpected error <<0xc1050000 - Network problems are preventing connection to the Microsoft Exchange Server computer. An unexpected, unknown error has occurred. Microsoft Exchange Server Information Store ID no: 80040115-0514-000006bf>> occurred.
The MAPI call 'OpenMsgStore' failed with the following error:
The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.
The MAPI provider failed.
Microsoft Exchange Server Information Store
ID no: 8004011d-0526-00000000
Unexpected error <<0xc1050000 - The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000>> occurred.
Wie schon erwähnt, treten diese Probleme NUR in der Nacht zwischen 02:00 - 06:00 auf. Erschwerende kommt leider hinzu dass wir aufgrund der leider etwas veralteten Backupsoftware (Backup Exec 10d) nur die gesamte Exc DB recovern können und keine einzelnen Postfächer !!
BITTE UM HILFE !!!
lg
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 165940
Url: https://administrator.de/contentid/165940
Printed on: April 23, 2024 at 13:04 o'clock
9 Comments
Latest comment
Moin,
"bad page link" Fehler sind ein Anzeichen dafür dass die Datenbank korrupt ist.
Das kann z.B. bei der Erweiterung der DB auffallen oder bei der Defragmentierung.
Zuerst mal prüfen ob ein Antivirenprogramm das Verzeichnis der Exchange-DB scannt oder ein Hardware-Fehler vorliegt.
Wenn diese Probleme ausgeschlossen sind, und die DB immer noch diesen Fehler aufweist, ist ein Restore einer Sicherung mit einer nicht korrupten Version angesagt. Da dies schon einige Tage her ist und Symantec offensichtlich den Fehler nicht bemerkt, solltest du prüfen, ob der Inhalt der Sicherungen überhaupt brauchbar ist.
Alternativ kannst du versuchen die DB zu reparieren (eseutil /p; isinteg -fix) und die Postfächer mit ExMerge verschieben.
ACHTUNG: Verluste von Daten sind dabei einzukalkulieren.
Es gibt einige 3rd-party-tools die bei solchen recoverys gute Dienste leisten und aus kompletten DBs einzelne Postfächer extrahieren können.
"bad page link" Fehler sind ein Anzeichen dafür dass die Datenbank korrupt ist.
Das kann z.B. bei der Erweiterung der DB auffallen oder bei der Defragmentierung.
Zuerst mal prüfen ob ein Antivirenprogramm das Verzeichnis der Exchange-DB scannt oder ein Hardware-Fehler vorliegt.
Wenn diese Probleme ausgeschlossen sind, und die DB immer noch diesen Fehler aufweist, ist ein Restore einer Sicherung mit einer nicht korrupten Version angesagt. Da dies schon einige Tage her ist und Symantec offensichtlich den Fehler nicht bemerkt, solltest du prüfen, ob der Inhalt der Sicherungen überhaupt brauchbar ist.
Alternativ kannst du versuchen die DB zu reparieren (eseutil /p; isinteg -fix) und die Postfächer mit ExMerge verschieben.
ACHTUNG: Verluste von Daten sind dabei einzukalkulieren.
Es gibt einige 3rd-party-tools die bei solchen recoverys gute Dienste leisten und aus kompletten DBs einzelne Postfächer extrahieren können.
Mahlzeit,
kann ich auch während des Betriebes versuchen die DB zu reparieren ?? Was aber absolut eigenartig ist, dass am Tag absolut keine Fehler auftreten, wo eigentlich kein Unterschied zum Abend/nach ist.
Kann es sein, dass die Smantec Software hier quertreibt ??
Ich habe jetzt mal zu Sicherheit, die AV Software deinstalliert und den Exc aus der Überprüfung ausgeschlossen
kann ich auch während des Betriebes versuchen die DB zu reparieren ?? Was aber absolut eigenartig ist, dass am Tag absolut keine Fehler auftreten, wo eigentlich kein Unterschied zum Abend/nach ist.
Kann es sein, dass die Smantec Software hier quertreibt ??
Ich habe jetzt mal zu Sicherheit, die AV Software deinstalliert und den Exc aus der Überprüfung ausgeschlossen
Während des Betriebs geht das nicht - die DB muss dazu (mit den mir bekannten Tools) exklusiv gesperrt werden.
Darin könnte auch das Problem mit einer nicht geeigneten Sicherungssoftware liegen.
Was läuft denn alles um die Zeit?
Du kannst Dir auch eine Kopie der DB ziehen und damit einen Integritätscheck machen.
Darin könnte auch das Problem mit einer nicht geeigneten Sicherungssoftware liegen.
Was läuft denn alles um die Zeit?
Du kannst Dir auch eine Kopie der DB ziehen und damit einen Integritätscheck machen.
Das ist ja das was ich nicht vertehe, die Sicherung für den Exc ist durchschnittlich um 2 uhr morgens fertig, ohne Fehlermeldungen, wenn in der Zeit der Sicherung mal der Mailverkehr ausfällt, ok. Aber heute kam ein Kollege der Nachtschicht zu mir und meinte eben, dass in der Nacht kein Mailverkehr möglich ist, da die Verbindung zu, exc weg ist.
Und in der Nacht sind nicht wirklich viele Kollegen da die Mailen können. Es sieht so aus, als wenn der Server je weniger er gebraucht wird, desto mehr kommen die Fehler. Heute seit 08:00 bis jetzt kein einziges Mal dass sich wer gemeldet hätte, dass die Mails nicht gehen.
Und in der Nacht sind nicht wirklich viele Kollegen da die Mailen können. Es sieht so aus, als wenn der Server je weniger er gebraucht wird, desto mehr kommen die Fehler. Heute seit 08:00 bis jetzt kein einziges Mal dass sich wer gemeldet hätte, dass die Mails nicht gehen.
Zitat von @83319:
Mahlzeit,
kann ich auch während des Betriebes versuchen die DB zu reparieren ?? Was aber absolut eigenartig ist, dass am Tag absolut
keine Fehler auftreten, wo eigentlich kein Unterschied zum Abend/nach ist.
Irgend etwas muss doch aber anders sein?Mahlzeit,
kann ich auch während des Betriebes versuchen die DB zu reparieren ?? Was aber absolut eigenartig ist, dass am Tag absolut
keine Fehler auftreten, wo eigentlich kein Unterschied zum Abend/nach ist.
Kann es sein, dass die Smantec Software hier quertreibt ??
Natürlich könnte das sein.Von welcher Symantec Software sprechen wir und wie ist diese konfiguriert?
Ich habe jetzt mal zu Sicherheit, die AV Software deinstalliert und den Exc aus der Überprüfung ausgeschlossen
Einen Server/PC ohne AV zu betreiben ist relativ leichtsinnig.Wesentlich besser ist es dann, diese Software entsprechend den Vorgaben der Hersteller (MS, Symantec) für die entsprechenden Systeme zu konfigurieren.
Das Ausschließen der Exchange-Datenbank ist sehr wichtig, denn dafür sollte entweder eine Speziallösung zum Scannen (Mailsecurity for Exchange) oder aber ein Gateway-Scanner genutzt werden, keinesfalls jedoch ein dateibasierter Scanner.
Tach,
sodale schön langsam ist wirklich Feuer am Dach. Ich bekomme mittlerweile ca. alle 5 min im eventlog die Meldung dass die DB defekt ist. Die user können (einstweilen noch) mit outlook arbeiten ohne
Fehlermeldungen. puh
Soweit so schlecht !! Jetzt hätte ich eben versucht, die Sicherung des Exchanges, Backuo Exec 10d, von gestern herzunehmen, die DB zu reparieren (somit muss ich die User nicht offline nehmen) und diese dann wiederherzustellen. Dass ein paar Mails verloren gehen, ist klar, aber ich glaub mit dem könnten wir leben.
Kennst Du einen Weg, wie ich die Bandsicherung des Exc dazu bewegen kann mir diese Sicherung auf eine externe HDD wiederherzustellen ?? Denn irgendwie beisst sich die Katze in den Schwanz, denn wenn ich die Exc Sicherung wieder herstellen möchte, geht das nicht, da ich Sicherungen nur auf Exc Severn wiederherstellen kann. Kennst du einen anderen weg ??
sodale schön langsam ist wirklich Feuer am Dach. Ich bekomme mittlerweile ca. alle 5 min im eventlog die Meldung dass die DB defekt ist. Die user können (einstweilen noch) mit outlook arbeiten ohne
Fehlermeldungen. puh
Soweit so schlecht !! Jetzt hätte ich eben versucht, die Sicherung des Exchanges, Backuo Exec 10d, von gestern herzunehmen, die DB zu reparieren (somit muss ich die User nicht offline nehmen) und diese dann wiederherzustellen. Dass ein paar Mails verloren gehen, ist klar, aber ich glaub mit dem könnten wir leben.
Kennst Du einen Weg, wie ich die Bandsicherung des Exc dazu bewegen kann mir diese Sicherung auf eine externe HDD wiederherzustellen ?? Denn irgendwie beisst sich die Katze in den Schwanz, denn wenn ich die Exc Sicherung wieder herstellen möchte, geht das nicht, da ich Sicherungen nur auf Exc Severn wiederherstellen kann. Kennst du einen anderen weg ??
Hast Du schon einen Integritätscheck der Datenbank gemacht? Oder nur den Fehler einfach ignoriert?
Die Sicherung von gestern ist nicht sehr hilfreich wenn die Datenbank schon einige Tage länger korrupt ist.
Was erwarteste Du da drauf? Dass die Sicherung da eine korrigierte Version der DB drauf hat? Ich tippe eher auf entweder nichts oder größtenteils unbrauchbar.
Vorab: ich kenne mich mit Symantec-Sicherung nicht aus.
Wie sichert Deine Version denn? Einzelne Postfächer oder nur die ganze DB? Wenn es die ganze DB ist, dann kannst Du die einfach an einen anderen Ort sichern (muss ja nicht direkt ein externes Laufwerk sein wenn das mit Symantec nicht klappt, es reicht ein anderes Verzeichnis).
Aber auch bei der wiederhergestellten DB musst Du prüfen ob diese defekt ist.
WICHTIG: DATENVERLUST möglich.
Sollte die gesicherte Version nur Bruchteile der ursprünglichen DB enthalten und Du spielst die ins produktive System ein, dann würde ich nicht darauf wetten, dass Outlook die fehlenden Daten wiederherstellt oder diese DB überhaupt akzeptiert.
Ohne die User für eine Weile vom Exchange zu trennen wird es aber nicht gehen.
Wie Du geschrieben hast, sind die Outlook-Postfächer noch OK (scheinbar).
Sicher alle Outlook-Postfächer und öffentlichen Ordner.
Dann kannst Du die Exchange-DB mit Bordmitteln "reparieren". (oder nimm ein Tool, z.B.: http://www.ontrack.de/exchange
Was verloren geht, kannst Du aus den Sicherungen (möglicherweise) restaurieren. (PowerControls kann auch einzelne Daten extrahieren; hat mir schon sehr gute Dienste geleistet bei einem Fall wie Deinem (Fehler im Log vom Admin lange Zeit ignoriert) ;) )
Und noch was: Verlier nicht noch mehr Zeit - besser wird die DB von alleine nicht. Wenn der Exchange anfangen sollte Daten zu löschen und die Offline-Dateien von Outlook synchronisiert wirds noch unlustiger.
Die Sicherung von gestern ist nicht sehr hilfreich wenn die Datenbank schon einige Tage länger korrupt ist.
Was erwarteste Du da drauf? Dass die Sicherung da eine korrigierte Version der DB drauf hat? Ich tippe eher auf entweder nichts oder größtenteils unbrauchbar.
Vorab: ich kenne mich mit Symantec-Sicherung nicht aus.
Wie sichert Deine Version denn? Einzelne Postfächer oder nur die ganze DB? Wenn es die ganze DB ist, dann kannst Du die einfach an einen anderen Ort sichern (muss ja nicht direkt ein externes Laufwerk sein wenn das mit Symantec nicht klappt, es reicht ein anderes Verzeichnis).
Aber auch bei der wiederhergestellten DB musst Du prüfen ob diese defekt ist.
WICHTIG: DATENVERLUST möglich.
Sollte die gesicherte Version nur Bruchteile der ursprünglichen DB enthalten und Du spielst die ins produktive System ein, dann würde ich nicht darauf wetten, dass Outlook die fehlenden Daten wiederherstellt oder diese DB überhaupt akzeptiert.
Ohne die User für eine Weile vom Exchange zu trennen wird es aber nicht gehen.
Wie Du geschrieben hast, sind die Outlook-Postfächer noch OK (scheinbar).
Sicher alle Outlook-Postfächer und öffentlichen Ordner.
Dann kannst Du die Exchange-DB mit Bordmitteln "reparieren". (oder nimm ein Tool, z.B.: http://www.ontrack.de/exchange
Was verloren geht, kannst Du aus den Sicherungen (möglicherweise) restaurieren. (PowerControls kann auch einzelne Daten extrahieren; hat mir schon sehr gute Dienste geleistet bei einem Fall wie Deinem (Fehler im Log vom Admin lange Zeit ignoriert) ;) )
Und noch was: Verlier nicht noch mehr Zeit - besser wird die DB von alleine nicht. Wenn der Exchange anfangen sollte Daten zu löschen und die Offline-Dateien von Outlook synchronisiert wirds noch unlustiger.
Zitat von @Petabyte:
Hast Du schon einen Integritätscheck der Datenbank gemacht? Oder nur den Fehler einfach ignoriert?
Hast Du schon einen Integritätscheck der Datenbank gemacht? Oder nur den Fehler einfach ignoriert?
Nein leider noch nicht, denn nachdem die user "normal" mit Outlook arbeiten können, hoffte ich dass es wie vor ein paar tagen der AV Scanner war, dem ist aber leider nicht so
Die Sicherung von gestern ist nicht sehr hilfreich wenn die Datenbank schon einige Tage länger korrupt ist.
Was erwarteste Du da drauf? Dass die Sicherung da eine korrigierte Version der DB drauf hat? Ich tippe eher auf entweder nichts
oder größtenteils unbrauchbar.
Nein, ich erwarte mir keine korrigierte version, sondern ich wollte die korrupt gesicherte DB sozusagen offline reparieren und dann wieder einspielen, ohne die jetzige DB angreifen zu müssen.
Vorab: ich kenne mich mit Symantec-Sicherung nicht aus.
Wie sichert Deine Version denn? Einzelne Postfächer oder nur die ganze DB? --> ja die ganze DB inkl. Benutzerdaten Dienste usw.
Wenn es die ganze DB ist, dann kannst Du die> einfach an einen anderen Ort sichern (muss ja nicht direkt ein externes Laufwerk sein wenn das mit Symantec nicht klappt, es
reicht ein anderes Verzeichnis). --> externes Laufwerk deshalb, da die DB alles in allem ca 200 GB gross ist
Aber auch bei der wiederhergestellten DB musst Du prüfen ob diese defekt ist.
WICHTIG: DATENVERLUST möglich.
Sollte die gesicherte Version nur Bruchteile der ursprünglichen DB enthalten und Du spielst die ins produktive System ein,
dann würde ich nicht darauf wetten, dass Outlook die fehlenden Daten wiederherstellt oder diese DB überhaupt
akzeptiert.
Ohne die User für eine Weile vom Exchange zu trennen wird es aber nicht gehen.
Aber auch bei der wiederhergestellten DB musst Du prüfen ob diese defekt ist.
WICHTIG: DATENVERLUST möglich.
Sollte die gesicherte Version nur Bruchteile der ursprünglichen DB enthalten und Du spielst die ins produktive System ein,
dann würde ich nicht darauf wetten, dass Outlook die fehlenden Daten wiederherstellt oder diese DB überhaupt
akzeptiert.
Ohne die User für eine Weile vom Exchange zu trennen wird es aber nicht gehen.
Mein Plan wäre via GPO den Exchange Cache zu aktivieren um zumindest lokal eine Sicherung der Emails zu haben
Wie Du geschrieben hast, sind die Outlook-Postfächer noch OK (scheinbar).
Sicher alle Outlook-Postfächer und öffentlichen Ordner.
Dann kannst Du die Exchange-DB mit Bordmitteln "reparieren". (oder nimm ein Tool, z.B.: http://www.ontrack.de/exchange
Was verloren geht, kannst Du aus den Sicherungen (möglicherweise) restaurieren. (PowerControls kann auch einzelne Daten
extrahieren; hat mir schon sehr gute Dienste geleistet bei einem Fall wie Deinem (Fehler im Log vom Admin lange Zeit ignoriert) ;)
)
Und noch was: Verlier nicht noch mehr Zeit - besser wird die DB von alleine nicht. Wenn der Exchange anfangen sollte Daten zu
löschen und die Offline-Dateien von Outlook synchronisiert wirds noch unlustiger.
Ich dachte Du hast den Cache schon aktiviert (da die User mit Outlook arbeiten ohne Fehler)
Problem dabei ist, dass die OST-Datei sich recht schnell synchronisiert (und eben auch Daten löscht). Eine "Sicherung" ist das nicht. Das kannst Du nur mit einem Export erreichen - evt. fallen dabei auch die User auf, die von dem Problem in der DB betroffen sind.
Bevor Du viel mit der Sicherung probierst:
Nimm die DB offline und kopier die auf eine andere Platte. Wenn Du eine interne nimmst, sollte das in wenigen Minuten erledigt sein (ist doch eh gleich Mittag).
Problem dabei ist, dass die OST-Datei sich recht schnell synchronisiert (und eben auch Daten löscht). Eine "Sicherung" ist das nicht. Das kannst Du nur mit einem Export erreichen - evt. fallen dabei auch die User auf, die von dem Problem in der DB betroffen sind.
Bevor Du viel mit der Sicherung probierst:
Nimm die DB offline und kopier die auf eine andere Platte. Wenn Du eine interne nimmst, sollte das in wenigen Minuten erledigt sein (ist doch eh gleich Mittag).
