13
SBS 2003 Exchange Server nach Backup nicht erreichbar
Guten Morgen liebe Leute.
Ich verzweifel hier gerade an einem SBS 2003 Exchange Server.
In der Hoffnung das hier jemand ein Wunder vollbringen kann, bettel ich nach HILFE
Vorgeschichte:
Server mit RAID 1 2x74GB HDD
Die 2. Platte ist ausgefallen und wurde ersetzt. Beim Rebuild ist festgestellt worden, dass Platte 1 ebenfalls Fehler hat und somit konnte das Rebuild nicht durchgeführt werden.
Fazit: Auch HDD1 musste getauscht und Server neu aufgesetzt werden.
SBS2003 wurde installiert und über ntbackup die Wiedrherstellung durchgeführt.
System läuft ohne Fehler, Programme, Freigaben etc alles vorhanden.
Nur der ExchangeServer macht mir Kummer.
Nach dem der Server wieder das war, was er sein sollte wurde von mir das Backup für die Erste Speichergruppe eingespielt.
Das Backup meldetet keine Fehler.
Im System Manager sehe ich die Pfade zu den Daten (2. Partition RAID5 - nicht betroffen vom Ausfall)
POP Connector hat die alten Daten wieder.
Nun das Problem:
Die User/CLients bekommen den ExchangeServer als nicht verbunden angezeigt.
2 Fehler in den Ereignissen:
Ereignistyp: Fehler
Ereignisquelle: MSExchangeIS
Ereigniskategorie: Allgemein
Ereigniskennung: 9518
Datum: 23.09.2011
Zeit: 08:46:41
Benutzer: Nicht zutreffend
Computer: SRV-DC-01
Beschreibung:
Fehler Aktuelle Protokolldatei fehlt. beim Starten von Speichergruppe /DC=local/DC=xx-xxx/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=xx-xxx/CN=Administrative Groups/CN=erste administrative gruppe/CN=Servers/CN=SRV-DC-01/CN=InformationStore/CN=Erste Speichergruppe im Microsoft Exchange Server-Informationsspeicher.
Storage Group - Initialization of Jet failed.
Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
Ereignistyp: Fehler
Ereignisquelle: MSExchangeSA
Ereigniskategorie: MAPI-Sitzung
Ereigniskennung: 9175
Datum: 23.09.2011
Zeit: 08:51:24
Benutzer: Nicht zutreffend
Computer: SRV-DC-01
Beschreibung:
Der MAPI-Aufruf 'OpenMsgStore' ist mit dem folgenden Fehler fehlgeschlagen:
Der Microsoft Exchange Server-Computer steht nicht zur Verfügung. Das Netzwerk antwortet nicht, oder der Server wurde für Wartungsarbeiten heruntergefahren.
Der MAPI-Provider ist fehlgeschlagen.
Microsoft Exchange Server-Informationsspeicher
ID no: 8004011d-0526-00000000
Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
Hier stehe ich vor der Wand... das Grosse "G" hat mir nicht geholfen, auch wenn es ähnliche Probleme aufgezeigt hat.
Ist hier jemand der diesen Fehler kennt, jemand der im Exchange fit ist um mich durch zu lotsen?
Ich hoffe jemand kann mein Wochenende retten .. danke für jeden Tip.
Grüsse
Joey
Ich verzweifel hier gerade an einem SBS 2003 Exchange Server.
In der Hoffnung das hier jemand ein Wunder vollbringen kann, bettel ich nach HILFE
Vorgeschichte:
Server mit RAID 1 2x74GB HDD
Die 2. Platte ist ausgefallen und wurde ersetzt. Beim Rebuild ist festgestellt worden, dass Platte 1 ebenfalls Fehler hat und somit konnte das Rebuild nicht durchgeführt werden.
Fazit: Auch HDD1 musste getauscht und Server neu aufgesetzt werden.
SBS2003 wurde installiert und über ntbackup die Wiedrherstellung durchgeführt.
System läuft ohne Fehler, Programme, Freigaben etc alles vorhanden.
Nur der ExchangeServer macht mir Kummer.
Nach dem der Server wieder das war, was er sein sollte wurde von mir das Backup für die Erste Speichergruppe eingespielt.
Das Backup meldetet keine Fehler.
Im System Manager sehe ich die Pfade zu den Daten (2. Partition RAID5 - nicht betroffen vom Ausfall)
POP Connector hat die alten Daten wieder.
Nun das Problem:
Die User/CLients bekommen den ExchangeServer als nicht verbunden angezeigt.
2 Fehler in den Ereignissen:
Ereignistyp: Fehler
Ereignisquelle: MSExchangeIS
Ereigniskategorie: Allgemein
Ereigniskennung: 9518
Datum: 23.09.2011
Zeit: 08:46:41
Benutzer: Nicht zutreffend
Computer: SRV-DC-01
Beschreibung:
Fehler Aktuelle Protokolldatei fehlt. beim Starten von Speichergruppe /DC=local/DC=xx-xxx/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=xx-xxx/CN=Administrative Groups/CN=erste administrative gruppe/CN=Servers/CN=SRV-DC-01/CN=InformationStore/CN=Erste Speichergruppe im Microsoft Exchange Server-Informationsspeicher.
Storage Group - Initialization of Jet failed.
Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
Ereignistyp: Fehler
Ereignisquelle: MSExchangeSA
Ereigniskategorie: MAPI-Sitzung
Ereigniskennung: 9175
Datum: 23.09.2011
Zeit: 08:51:24
Benutzer: Nicht zutreffend
Computer: SRV-DC-01
Beschreibung:
Der MAPI-Aufruf 'OpenMsgStore' ist mit dem folgenden Fehler fehlgeschlagen:
Der Microsoft Exchange Server-Computer steht nicht zur Verfügung. Das Netzwerk antwortet nicht, oder der Server wurde für Wartungsarbeiten heruntergefahren.
Der MAPI-Provider ist fehlgeschlagen.
Microsoft Exchange Server-Informationsspeicher
ID no: 8004011d-0526-00000000
Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
Hier stehe ich vor der Wand... das Grosse "G" hat mir nicht geholfen, auch wenn es ähnliche Probleme aufgezeigt hat.
Ist hier jemand der diesen Fehler kennt, jemand der im Exchange fit ist um mich durch zu lotsen?
Ich hoffe jemand kann mein Wochenende retten .. danke für jeden Tip.
Grüsse
Joey
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: 173576
Url: https://administrator.de/forum/sbs-2003-exchange-server-nach-backup-nicht-erreichbar-173576.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
es sieht so aus als ob Logdateien zum Starten der datenbank fehlen. Hast du schon mal in deiner Verwaltungskonsole versucht deinen datenbankdateien bereit zu stellen.
Mit dem dem Tool esutil kanns du die Konsistenz der Datenbank überprüfen.
Gruß
Ulrike
es sieht so aus als ob Logdateien zum Starten der datenbank fehlen. Hast du schon mal in deiner Verwaltungskonsole versucht deinen datenbankdateien bereit zu stellen.
Mit dem dem Tool esutil kanns du die Konsistenz der Datenbank überprüfen.
Gruß
Ulrike
bzw. du hast wahrscheinlich sogar eine Logdatei zu viel.
Mach mal das, was Ulrike vorgeschlagen hat: Prüfe durch Aufruf von eseutil /mh <Datenbankdatei> den Status der Datenbanken. Da sollte eigentlich nach einem Restore der Datenbanken ein Log-Required 0-0 stehen. Wenn das der Fall ist, dann benenne mal die E00.LOG um und versuche dann den Informationsspeicher zu starten.
Gruß
Hubert
Mach mal das, was Ulrike vorgeschlagen hat: Prüfe durch Aufruf von eseutil /mh <Datenbankdatei> den Status der Datenbanken. Da sollte eigentlich nach einem Restore der Datenbanken ein Log-Required 0-0 stehen. Wenn das der Fall ist, dann benenne mal die E00.LOG um und versuche dann den Informationsspeicher zu starten.
Gruß
Hubert
Hallo und Danke schonmal. Hier habe ich die ESEUTIL Logs:
C:\Programme\Exchsrvr\bin>eseutil /k E:\Exchsrvr\MDBDATA\priv1.edb
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating CHECKSUM mode...
Database: E:\Exchsrvr\MDBDATA\priv1.edb
Streaming File: E:\Exchsrvr\MDBDATA\priv1.STM
Temp. Database: TEMPCHKSUM5776.EDB
File: E:\Exchsrvr\MDBDATA\priv1.edb
Checksum Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
732291 pages seen
0 bad checksums
223 uninitialized pages
0 wrong page numbers
0x30b1911 highest dbtime (pgno 0x293)
45769 reads performed
2860 MB read
17 seconds taken
168 MB/second
17701396 milliseconds used
386 milliseconds per read
531 milliseconds for the slowest read
46 milliseconds for the fastest read
File: E:\Exchsrvr\MDBDATA\priv1.STM
ERROR: database was not shutdown cleanly (dirty shutdown)
Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was
not shutdown cleanly. Recovery must first be run to properly complete database
operations for the previous shutdown.) after 23.563 seconds.
File: E:\Exchsrvr\MDBDATA\priv1.edb
Checksum Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
732291 pages seen
0 bad checksums
223 uninitialized pages
0 wrong page numbers
0x30b1911 highest dbtime (pgno 0x293)
45769 reads performed
2860 MB read
17 seconds taken
168 MB/second
17701396 milliseconds used
386 milliseconds per read
531 milliseconds for the slowest read
46 milliseconds for the fastest read
File: E:\Exchsrvr\MDBDATA\priv1.STM
ERROR: database was not shutdown cleanly (dirty shutdown)
Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was
not shutdown cleanly. Recovery must first be run to properly complete database
operations for the previous shutdown.) after 23.563 seconds.
Bevor ich jetzt irgendetwas unternehme.... brauche ich Euch .... kann ich einfach ein Recovery durchführen oder sollte ich etwas vorher machen?
C:\Programme\Exchsrvr\bin>eseutil /k E:\Exchsrvr\MDBDATA\priv1.edb
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating CHECKSUM mode...
Database: E:\Exchsrvr\MDBDATA\priv1.edb
Streaming File: E:\Exchsrvr\MDBDATA\priv1.STM
Temp. Database: TEMPCHKSUM5776.EDB
File: E:\Exchsrvr\MDBDATA\priv1.edb
Checksum Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
732291 pages seen
0 bad checksums
223 uninitialized pages
0 wrong page numbers
0x30b1911 highest dbtime (pgno 0x293)
45769 reads performed
2860 MB read
17 seconds taken
168 MB/second
17701396 milliseconds used
386 milliseconds per read
531 milliseconds for the slowest read
46 milliseconds for the fastest read
File: E:\Exchsrvr\MDBDATA\priv1.STM
ERROR: database was not shutdown cleanly (dirty shutdown)
Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was
not shutdown cleanly. Recovery must first be run to properly complete database
operations for the previous shutdown.) after 23.563 seconds.
File: E:\Exchsrvr\MDBDATA\priv1.edb
Checksum Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
732291 pages seen
0 bad checksums
223 uninitialized pages
0 wrong page numbers
0x30b1911 highest dbtime (pgno 0x293)
45769 reads performed
2860 MB read
17 seconds taken
168 MB/second
17701396 milliseconds used
386 milliseconds per read
531 milliseconds for the slowest read
46 milliseconds for the fastest read
File: E:\Exchsrvr\MDBDATA\priv1.STM
ERROR: database was not shutdown cleanly (dirty shutdown)
Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was
not shutdown cleanly. Recovery must first be run to properly complete database
operations for the previous shutdown.) after 23.563 seconds.
Bevor ich jetzt irgendetwas unternehme.... brauche ich Euch
.... kann ich einfach ein Recovery durchführen oder sollte ich etwas vorher machen?Zitat von @ulrike:
Hallo,
es sieht so aus als ob Logdateien zum Starten der datenbank fehlen. Hast du schon mal in deiner Verwaltungskonsole versucht
deinen datenbankdateien bereit zu stellen.
Mit dem dem Tool esutil kanns du die Konsistenz der Datenbank überprüfen.
Gruß
Ulrike
Hallo,
es sieht so aus als ob Logdateien zum Starten der datenbank fehlen. Hast du schon mal in deiner Verwaltungskonsole versucht
deinen datenbankdateien bereit zu stellen.
Mit dem dem Tool esutil kanns du die Konsistenz der Datenbank überprüfen.
Gruß
Ulrike
Hallo Ulrike,
Wie kann ich die Datenbankdateien bereit stellen über die Konsole ..bzw wo.
Logfile von ESEutil weiter unten
Danke für die Hilfe.
Joey
Log Required: 5786-5786 (0x169a-0x169a)/
Das ist leider nicht das was Du sehen wolltest. Eine Idee für mehr?
Hier noch der LOG.
C:\Programme\Exchsrvr\bin>eseutil /mh E:\Exchsrvr\MDBDATA\priv1.edb
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: E:\Exchsrvr\MDBDATA\priv1.edb
File Type: Database
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,11
Engine ulVersion: 0x620,11
Created ulVersion: 0x620,9
DB Signature: Create time:06/26/2008 16:01:58 Rand:2902501 Computer:
cbDbPage: 4096
dbtime: 50778866 (0x306d2f2)
State: Dirty Shutdown
Log Required: 5786-5786 (0x169a-0x169a)/
Streaming File: Yes
Shadowed: Yes
Last Objid: 6606
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00
Repair Count: 0
Repair Date: 00/00/1900 00:00:00
Last Consistent: (0x167A,16B4,C1) 09/06/2011 08:03:31
Last Attach: (0x167A,16B5,132) 09/06/2011 08:03:32
Last Detach: (0x0,0,0) 00/00/1900 00:00:00
Dbid: 1
Log Signature: Create time:06/26/2008 16:01:57 Rand:2899889 Computer:
OS Version: (5.2.3790 SP 2)
Previous Full Backup:
Log Gen: 5778-5779 (0x1692-0x1693)
Mark: (0x1693,1EE8,19D)
Mark: 09/13/2011 00:52:13
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: 5786-0 (0x169a-0x0)
Mark: (0x169A,2661,121)
Mark: 09/14/2011 00:51:51
Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00
cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0
Patch Current Full Backup:
Log Gen: 5786-5786 (0x169a-0x169a)
Mark: (0x169A,2661,121)
Mark: 09/14/2011 00:51:51
Operation completed successfully in 3.0 seconds.
Das ist leider nicht das was Du sehen wolltest. Eine Idee für mehr?
Hier noch der LOG.
C:\Programme\Exchsrvr\bin>eseutil /mh E:\Exchsrvr\MDBDATA\priv1.edb
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: E:\Exchsrvr\MDBDATA\priv1.edb
File Type: Database
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,11
Engine ulVersion: 0x620,11
Created ulVersion: 0x620,9
DB Signature: Create time:06/26/2008 16:01:58 Rand:2902501 Computer:
cbDbPage: 4096
dbtime: 50778866 (0x306d2f2)
State: Dirty Shutdown
Log Required: 5786-5786 (0x169a-0x169a)/
Streaming File: Yes
Shadowed: Yes
Last Objid: 6606
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00
Repair Count: 0
Repair Date: 00/00/1900 00:00:00
Last Consistent: (0x167A,16B4,C1) 09/06/2011 08:03:31
Last Attach: (0x167A,16B5,132) 09/06/2011 08:03:32
Last Detach: (0x0,0,0) 00/00/1900 00:00:00
Dbid: 1
Log Signature: Create time:06/26/2008 16:01:57 Rand:2899889 Computer:
OS Version: (5.2.3790 SP 2)
Previous Full Backup:
Log Gen: 5778-5779 (0x1692-0x1693)
Mark: (0x1693,1EE8,19D)
Mark: 09/13/2011 00:52:13
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: 5786-0 (0x169a-0x0)
Mark: (0x169A,2661,121)
Mark: 09/14/2011 00:51:51
Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00
cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0
Patch Current Full Backup:
Log Gen: 5786-5786 (0x169a-0x169a)
Mark: (0x169A,2661,121)
Mark: 09/14/2011 00:51:51
Operation completed successfully in 3.0 seconds.
Halklo
Wenn die Datenbank im Status "Dirty Shutdown" ist, dann kannst du sie nicht bereitstellen.
Wenn das System nach Logdateien fragt, dann ist doch erst einmal die Frage, ob du die benötigten Dateien überhaupt hast.
Irgendwie scheint da aber schon länger was im Argen gelegen zu haben (befürchte ich...)
Gruß
Hubert
Wenn die Datenbank im Status "Dirty Shutdown" ist, dann kannst du sie nicht bereitstellen.
Wenn das System nach Logdateien fragt, dann ist doch erst einmal die Frage, ob du die benötigten Dateien überhaupt hast.
Irgendwie scheint da aber schon länger was im Argen gelegen zu haben (befürchte ich...)
Gruß
Hubert
Hallo,
er sagt dir ja welches Logfile du benötigst,
Log Required: 5786-5786 (0x169a-0x169a )
Versuche erstmal das zu finden und mit eseutil /r kannst du es anhängen ( aber vorher alles mal sichern Datenbank und Logfiles) wenn du es nicht mehr hast bleibt dir nur eseutil /p dann ist der Stand deiner Datenbank aber der 13.09.
Im TechNet steht eseutil auch ganz gut beschrieben.
Uli
er sagt dir ja welches Logfile du benötigst,
Log Required: 5786-5786 (0x169a-0x169a )
Versuche erstmal das zu finden und mit eseutil /r kannst du es anhängen ( aber vorher alles mal sichern Datenbank und Logfiles) wenn du es nicht mehr hast bleibt dir nur eseutil /p dann ist der Stand deiner Datenbank aber der 13.09.
Im TechNet steht eseutil auch ganz gut beschrieben.
Uli
Salute,
Log File ist nicht mehr vorhanden gewesen, so habe ich eseutil /p ausgeführt.
Ich habe beide Datenbanken .edb's reparieren lassen. Eseutil meldete keine Fehler und der Vorgang wurde erfolgreich abgeschlossen.
Der Server wurde zudem neugestartet. Da ich immer noch den einen Fehler habe "Mapi-Sitzung" könnte ich Eure Hilfe immer noch gebrauchen.
Hier der gesamte Fehler:
Ereignistyp: Fehler
Ereignisquelle: MSExchangeSA
Ereigniskategorie: MAPI-Sitzung
Ereigniskennung: 9175
Datum: 23.09.2011
Zeit: 14:07:39
Benutzer: Nicht zutreffend
Computer: SRV-DC-01
Beschreibung:
Der MAPI-Aufruf 'OpenMsgStore' ist mit dem folgenden Fehler fehlgeschlagen:
Der Microsoft Exchange Server-Computer steht nicht zur Verfügung. Das Netzwerk antwortet nicht, oder der Server wurde für Wartungsarbeiten heruntergefahren.
Der MAPI-Provider ist fehlgeschlagen.
Microsoft Exchange Server-Informationsspeicher
ID no: 8004011d-0526-00000000
Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
Ich komm mit dem Fehler nicht klar... ich habe eindeutig zu wenig Exchange Erfahrung ..muss ich iwie mal ändern.
Freue mich über jede Hilfe.
Grüsse Joey
Log File ist nicht mehr vorhanden gewesen, so habe ich eseutil /p ausgeführt.
Ich habe beide Datenbanken .edb's reparieren lassen. Eseutil meldete keine Fehler und der Vorgang wurde erfolgreich abgeschlossen.
Der Server wurde zudem neugestartet. Da ich immer noch den einen Fehler habe "Mapi-Sitzung" könnte ich Eure Hilfe immer noch gebrauchen.
Hier der gesamte Fehler:
Ereignistyp: Fehler
Ereignisquelle: MSExchangeSA
Ereigniskategorie: MAPI-Sitzung
Ereigniskennung: 9175
Datum: 23.09.2011
Zeit: 14:07:39
Benutzer: Nicht zutreffend
Computer: SRV-DC-01
Beschreibung:
Der MAPI-Aufruf 'OpenMsgStore' ist mit dem folgenden Fehler fehlgeschlagen:
Der Microsoft Exchange Server-Computer steht nicht zur Verfügung. Das Netzwerk antwortet nicht, oder der Server wurde für Wartungsarbeiten heruntergefahren.
Der MAPI-Provider ist fehlgeschlagen.
Microsoft Exchange Server-Informationsspeicher
ID no: 8004011d-0526-00000000
Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
Ich komm mit dem Fehler nicht klar... ich habe eindeutig zu wenig Exchange Erfahrung ..muss ich iwie mal ändern.
Freue mich über jede Hilfe.
Grüsse Joey
hgrüezi und hallo
ich habe gerade einen Beitrag im www gefunden: http://www.mcseboard.de/ms-exchange-forum-80/inkonsistente-exchange2003 ...
Das beschreibt so ziemlich genau meinen derzeitigen Stand und ich denke ich habe nur die gleiche Möglichkeit... löschen der DBs und neu.
Ein gutes hat das Ganze, Exchange war so gut konfiguriert, dass er nur für Kalender genutzt wurde. Somit gehen nur diese Daten hobs.
Ich werde ein Backup von allen psd's erstellen und dann die DB's auf dem Server "neu" anlegen.
Sofern nicht noch jemand eine Wunderlösung für mich hat
Danke allen die zur Seite gestanden haben... vielleicht denk ich am WE nicht an diesen Mist
grüsäli
Joey
ich habe gerade einen Beitrag im www gefunden: http://www.mcseboard.de/ms-exchange-forum-80/inkonsistente-exchange2003 ...
Das beschreibt so ziemlich genau meinen derzeitigen Stand und ich denke ich habe nur die gleiche Möglichkeit... löschen der DBs und neu.
Ein gutes hat das Ganze, Exchange war so gut konfiguriert, dass er nur für Kalender genutzt wurde. Somit gehen nur diese Daten hobs.
Ich werde ein Backup von allen psd's erstellen und dann die DB's auf dem Server "neu" anlegen.
Sofern nicht noch jemand eine Wunderlösung für mich hat
Danke allen die zur Seite gestanden haben... vielleicht denk ich am WE nicht an diesen Mist
grüsäli
Joey
Ich hoffe, du hast (für alle Fälle) ein Backup vom "status quo" gemacht...
Wenn du die eine Datenbank nun schon zwangskonsistent gesetzt hast, dann solltest du
1. nicht vergessen, dass es auch noch eine Datenbank für Öffenliche Ordner gibt. Prüfe also nicht nur den Status der priv1.edb. auch die pub1.edb kann den Start des IS verhindern
2. Nach der Nutzung von eseutil /p muss die Datenbank anschließend unbedingt überprüft werden. Neben eseutil kommt dabei isinteg zum Einsatz
Du solltest dir schon im klaren sein, was eine Hardrecovery der Datenbank bewirkt. Der Store wird gemountet, auch wenn die Datenbankdatei in sich nicht konsistent ist. Wenn du jetzt nicht dafür sorgst, dass die Datenbank(en) wieder in einen einwandfreien Zustand versetzt werden, dann wird dich das Problem früher oder später garantiert wieder einholen.
btw hätte dir vielleicht auch jemand mit Exchange-Erfahrung das Problem auch anderweitig lösen können...
btw2 - das an einem Controller zwei Festplatten mit Fehlern hängen sollte eigentlich nicht vorkommen. Dazu gibts bei den meisten Geräten "Verify"-Tasks, damit genau das nicht passiert...
Gruß
Hubert
Wenn du die eine Datenbank nun schon zwangskonsistent gesetzt hast, dann solltest du
1. nicht vergessen, dass es auch noch eine Datenbank für Öffenliche Ordner gibt. Prüfe also nicht nur den Status der priv1.edb. auch die pub1.edb kann den Start des IS verhindern
2. Nach der Nutzung von eseutil /p muss die Datenbank anschließend unbedingt überprüft werden. Neben eseutil kommt dabei isinteg zum Einsatz
Du solltest dir schon im klaren sein, was eine Hardrecovery der Datenbank bewirkt. Der Store wird gemountet, auch wenn die Datenbankdatei in sich nicht konsistent ist. Wenn du jetzt nicht dafür sorgst, dass die Datenbank(en) wieder in einen einwandfreien Zustand versetzt werden, dann wird dich das Problem früher oder später garantiert wieder einholen.
btw hätte dir vielleicht auch jemand mit Exchange-Erfahrung das Problem auch anderweitig lösen können...
btw2 - das an einem Controller zwei Festplatten mit Fehlern hängen sollte eigentlich nicht vorkommen. Dazu gibts bei den meisten Geräten "Verify"-Tasks, damit genau das nicht passiert...
Gruß
Hubert
Zitat von @joeyschweiz:
Das beschreibt so ziemlich genau meinen derzeitigen Stand und ich denke ich habe nur die gleiche Möglichkeit... löschen
der DBs und neu.
Ein gutes hat das Ganze, Exchange war so gut konfiguriert, dass er nur für Kalender genutzt wurde. Somit gehen nur diese
Daten hobs.
Ich werde ein Backup von allen psd's erstellen und dann die DB's auf dem Server "neu" anlegen.
Das beschreibt so ziemlich genau meinen derzeitigen Stand und ich denke ich habe nur die gleiche Möglichkeit... löschen
der DBs und neu.
Ein gutes hat das Ganze, Exchange war so gut konfiguriert, dass er nur für Kalender genutzt wurde. Somit gehen nur diese
Daten hobs.
Ich werde ein Backup von allen psd's erstellen und dann die DB's auf dem Server "neu" anlegen.
Naja - die Wunderlösung hast du doch schon
- prüfe erst mal ob alle Datenbanken einwandfrei sind.Wenn beide Datenbankdateien einwandfrei sind, dann lösche mal die übrig gebliebenen Log-Dateien und versuche noch einmal den Store zu mounten. Die Dateien hast du eh "zwangsabgehängt". Da du ja ganz sicher ein Backup gemacht hattest, kannst du nun eh nichts mehr kaputter machen, als es schon gewesen ist ;)
Und dein gegenwärtiger Stand ist nicht der gleiche, wie im verlinkten Artikel. Dort konnte der TO wohl den Inhalt der Postfächer in eine PST exportieren. Das geht aber nur dann, wenn der Cachemodus aktiv gewesen ist und der Inhalt entsprechend aus der lokal abgelegten OST-Datei entnommen werden kann. In deiner lokalen pst-Datei stehen keine Inhalte der Eychange-Datenbank
Mein ultimativer Tipp: Kopiere den allerersten Stand aus dem Backup zurück (Da du ja die Datenbank aus ntbackup zurückgesichert hattest mache vielleicht genau das noch einmal...) und hole dir jemanden ins Haus, der sich mit der Problematik etwas besser auskennt.
Wobei mich eine Aussage wie
POP Connector hat die alten Daten wieder.
dann auch gleich wieder ein wenig stutzig macht. Du hast nicht wiklich den Server versucht "live" in Betrieb zu nehmen, obwohl ganz sicher bei jedem Startd es Srevers eine Melung kommen dürfte, dass ein Dienst nicht gestartet werden konnte ?!
Wozu überhaupt ein POP Connector, wenn du doch schreibst, dass der Server nur Kalendereinträge hostet ?
So ganz werde ich aus deinem Szenario nicht schlau...
edit: und damit du mal eine Vorstellunbg hast, auf wie dünnem Eis du dich bewegst eine Link zum Microsoft Technet, wo geschrieben steht:
Microsoft recommends that you follow these best practices when repairing a database:
Do not allow a repaired database to remain in production for an extended period of time.
Do not use the Eseutil repair option when backup is available.
Danke.
Ich habe die Log Dateien gelöscht (verschoben)
Info und Postfachspeicher liessen sich starten. Keine Fehlermeldungen mehr im Protokoll.
Soweit so gut.... Exchange Server ist wieder da und mein testclient verbunden und es sieht alles gut aus.
Jetzt muss ich nur ordentlich lesen wie ich eine neue datenbank anlege und die alte "reparierte" in diese migriere.
Oder nicht?
Danke @ all
Ich habe die Log Dateien gelöscht (verschoben)
Info und Postfachspeicher liessen sich starten. Keine Fehlermeldungen mehr im Protokoll.
Soweit so gut.... Exchange Server ist wieder da und mein testclient verbunden und es sieht alles gut aus.
Jetzt muss ich nur ordentlich lesen wie ich eine neue datenbank anlege und die alte "reparierte" in diese migriere.
Oder nicht?
Danke @ all
Wie du eien neue Datenbank alegst, hast du ja bereits im andern Artikel gefunden.
Mach ansonsten genau das, was Microsoft in dem von mir verlinkten Artikal schreibt:
Repairing databases involves the following three stages, in this order:
Eseutil is run in /P mode to perform a database page-level and table-level repair
Eseutil is run in /D mode to fully rebuild indexes and defragment the database
ISInteg is then run to repair the database at the application level
Auf jeden Fall kannst du jetzt lokal vom Client aus wieder auf die Information der Datenbank zugreifen und den Inhalt der Postfächer in pst-Dateien exportieren
Mach ansonsten genau das, was Microsoft in dem von mir verlinkten Artikal schreibt:
Repairing databases involves the following three stages, in this order:
Eseutil is run in /P mode to perform a database page-level and table-level repair
Eseutil is run in /D mode to fully rebuild indexes and defragment the database
ISInteg is then run to repair the database at the application level
Auf jeden Fall kannst du jetzt lokal vom Client aus wieder auf die Information der Datenbank zugreifen und den Inhalt der Postfächer in pst-Dateien exportieren
