none
Exchange 2007 (SBS2008) - Postfachspeicher wird nicht bereitgestellt RRS feed

  • Frage

  • Hallo Community,

    zu diesem Thema gibt's im Netz ja Threads ohne Ende, die ich (gefühlt) inzwischen alle doppelt durchgearbeitet habe. ;-) Leider habe ich zu dem konkreten Problem keine Lösung gefunden. Also hoffe ich auf euch!

    Folgendes Phänomen habe ich in einem Netz mit SBS2008:

    Nach einem Stromausfall, bei dem leider die USV versagte, lief der SBS hoch, konnte nur den Postfachspeicher nicht bereitstellen (Public Folders wurden bereitgestellt).

    Folgende Events wurden gemeldet:

    Quelle: ESE, Ereignis-ID: 485
    MSExchangeIS (2240) First Storage Group: Fehler beim Versuch, Datei "C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00tmp.log" zu löschen, mit Systemfehler 32 (0x00000020): "Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. ". Fehler -1032 (0xfffffbf8) bei der Operation zum Löschen von Dateien.

    Quelle: ESE, Ereignis-ID: 412
    MSExchangeIS (2240) First Storage Group: Kopfzeile der Protokolldatei C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00.log konnte nicht gelesen werden. Fehler -501.

    Quelle: MSExchangeIS, Ereignis-ID: 9518
    Fehler Protokolldatei ist beschädigt. beim Starten von Speichergruppe /DC=local/DC=xx/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=First Organization/CN=Administrative Groups/CN=Exchange Administrative Group(FYDIBOHF23SPDLT)/CN=Servers/CN=SBS01/CN=InformationStore/CN=First Storage Group im Microsoft Exchange Server-Informationsspeicher.
    Storage Group - Initialization of Jet failed.

    Also, erst mal alle Exchange-Daten an einen sicheren Ort kopiert und Status der DB geprüft: eseutil /mh sagte mir, dass sich die Datenbank im "dirty shutdown"-Status befindet, also habe ich es zunächst mit Softrepair (eseutil /r) versucht, was leider nicht half. Ich habe viel hin und her probiert, aber letztendlich konnte ich nur mit eseutil /p die Datenbank wieder in einen konsistenten Status bringen. Die anschließende Defragmentierung mit eseutil /d lief ebenfalls ordnungsgemäß. Nun wollte ich mit isinteg –s server –test
    allfoldertests prüfen, was jedoch folgenden Fehler bringt:

    Isinteg cannot initiate verification process. Please review the log file for more information.

    Im Ereignisprotokoll kommen wieder die gleichen Fehler, wie oben. Ich hatte alle Dateien aus dem Protokollpfad entfernt, bis auf die e00.log und die e00tmp.log.

    Da ich nicht weiter kam und ja auch die e00.log laut Event nicht gelesen werden konnte, habe ich auch versucht, diese beiden Dateien zu entfernen. Die e00.log konnte ich löschen, nur die e00tmp.log verweigert jeden Versuch, sie umzubenennen oder zu entfernen, da angeblich ein anderes Programm darauf zugreift. Also habe ich mit Unlocker, ProcessExplorer und LockHunter versucht herauszufinden, was da blockt. Nur leider sagen alle Programme, dass da nichts ist… Selbst, wenn man abgesichert mit Eingabeaufforderung hochfährt, lässt sich die Datei nicht entfernen. Nun findet man bei Microsoft den (nachvollziehbaren) Hinweis, dass ein AntiVirus-oder Backup-Programm die Datei sperren könnte. Ist hier nicht der Fall. Ich habe alle entsprechenden Programme deinstalliert – ohne Erfolg.

    Normalerweise würde man nun wohl sagen, Datensicherung zurückspielen; wer auch immer die Sicherung (BackupExec) eingerichtet hat, wurde leider vergessen, den Information Store mit auszuwählen. Insofern stehen wir nun vor der Misere, die vorhandenen Daten zwingend wieder gangbar zu machen.

    Für konstruktive Vorschläge wäre ich euch sehr dankbar!

    Viele Grüße aus dem Norden,
    Björn


    Bjoern Specketer Elsner Datensysteme GmbH

    Freitag, 4. Januar 2013 09:02

Antworten

  • Hallo Christian,

    eins vorweg: Exchange is back@work!

    Zur Lösung: völlig unsinnigerweise funktionierte es zwar nicht, die e00tmp.log zu löschen oder umzubenennen, aber: der übergeordnete Ordner konnte umbenannt werden!?! Daraufhin hat Exchange beim Start des Informationsspeichers die Datenbank einwandfrei bereitgestellt. Der Transportdienst wollte zwar auch nicht gleich, aber nachdem die Transaktionsprotokolle einmal geleert wurden, ging auch das.

    Auf jeden Fall vielen Dank für die nette Konversation und ein schönes Wochenende!

    Viele Grüße,
    Björn


    Bjoern Specketer Elsner Datensysteme GmbH

    Freitag, 4. Januar 2013 12:07

Alle Antworten

  • Hi Bjoern,

    Da ich nicht weiter kam und ja auch die e00.log laut Event nicht gelesen werden konnte, habe ich auch versucht, diese beiden Dateien zu entfernen. Die e00.log konnte ich löschen, nur die e00tmp.log verweigert jeden Versuch, sie umzubenennen oder zu entfernen, da angeblich ein anderes Programm darauf zugreift. Also habe ich mit Unlocker, ProcessExplorer und LockHunter versucht herauszufinden, was da blockt. Nur leider sagen alle Programme, dass da nichts ist… Selbst, wenn man abgesichert mit Eingabeaufforderung hochfährt, lässt sich die Datei nicht entfernen. Nun findet man bei Microsoft den (nachvollziehbaren) Hinweis, dass ein AntiVirus-oder Backup-Programm die Datei sperren könnte. Ist hier nicht der Fall. Ich habe alle entsprechenden Programme deinstalliert – ohne Erfolg.

    hast du mal chkdsk laufen lassen und das Dateisystem geprüft?


    Viele Grüße
    Christian

    Freitag, 4. Januar 2013 09:13
    Moderator
  • Hallo Christian,

    ja, chkdsk ist auch schon durch. Hat nichts wirklich gravierendes gefunden und somit leider auch nicht geholfen.

    Viele Grüße,
    Björn


    Bjoern Specketer Elsner Datensysteme GmbH

    Freitag, 4. Januar 2013 09:17
  • Hi Bjoern,

    du hast alle Dienste beendet und kommst nicht mal im abgesicherten Modus auf die Datei? Das ist schon komisch...

    Kannst du die Partition neu erstellen, damit die wirklich blank und sauber ist?


    Viele Grüße
    Christian

    Freitag, 4. Januar 2013 09:24
    Moderator
  • Hi Christian,

    Partition neu erstellen? Könnte kontraproduktiv sein, da sich das Log-Verzeichnis dummerweise auf dem Systemlaufwerk befindet... (Ich war's nicht!)

    Ich hatte ja auch schon versucht, eine neue MailboxDB anzulegen; nur da innerhalb der Storage-Group Logs immer das gleiche Verzeichnis nutzen, klappt nicht mal das.

    Die einzige Variante zur Löschung der Datei, die mir grad noch eingefallen ist, wäre folgende:
    Ich hatte noch nicht erwähnt, dass der SBS in einem ESXi-Host läuft. Man könnte ja den SBS runter fahren und einer anderen virtuellen Maschine die virtuelle HDD mit einhängen und von dort löschen...

    Viele Grüße,
    Björn


    Bjoern Specketer Elsner Datensysteme GmbH

    Freitag, 4. Januar 2013 09:34
  • Hi Bjoern Specketer,

    Hi Christian,

    Partition neu erstellen? Könnte kontraproduktiv sein, da sich das Log-Verzeichnis dummerweise auf dem Systemlaufwerk befindet... (Ich war's nicht!)

    den Inhalt solltest du wieder füllen, aber wenn es in einer ESX-Umgebung läuft, kannst du auch gleich eine neue HDD erstellen.

    Die einzige Variante zur Löschung der Datei, die mir grad noch eingefallen ist, wäre folgende:
    Ich hatte noch nicht erwähnt, dass der SBS in einem ESXi-Host läuft. Man könnte ja den SBS runter fahren und einer anderen virtuellen Maschine die virtuelle HDD mit einhängen und von dort löschen...

    da bin ich mal gespannt...


    Viele Grüße
    Christian

    Freitag, 4. Januar 2013 10:04
    Moderator
  • Hallo Christian,

    eins vorweg: Exchange is back@work!

    Zur Lösung: völlig unsinnigerweise funktionierte es zwar nicht, die e00tmp.log zu löschen oder umzubenennen, aber: der übergeordnete Ordner konnte umbenannt werden!?! Daraufhin hat Exchange beim Start des Informationsspeichers die Datenbank einwandfrei bereitgestellt. Der Transportdienst wollte zwar auch nicht gleich, aber nachdem die Transaktionsprotokolle einmal geleert wurden, ging auch das.

    Auf jeden Fall vielen Dank für die nette Konversation und ein schönes Wochenende!

    Viele Grüße,
    Björn


    Bjoern Specketer Elsner Datensysteme GmbH

    Freitag, 4. Januar 2013 12:07
  • Hi Bjoern,

    danke für die Rückmeldung jetzt kannst du deinen Beitrag als Antwort markieren, damit der Thread geschlossen wird.

    Schönes Wochenende...


    Viele Grüße
    Christian

    Freitag, 4. Januar 2013 19:12
    Moderator