Jump to content

BNO

Members
  • Gesamte Inhalte

    10
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von BNO

  1. Ich hab das Problem sauber beheben können. Grundvorraussetzung ist dabei aber ein existierendes Backup der Datenbank. Hier mal mein Vorgehen für alle mit dem gleichen Problem: Problematik: Durch einen Ausfall des RAID Systems, auf dem die Postfachdatenbank unseres Exchange 2010 lag, geriet die Datenbank in den Status "Dirty Shutdown". Ein Softrepair brachte das Ergebnis, dass die Logdateien 589c - 589f fehlten. Der Exchange hatte aber, da die Log-Dateien auf C: liegen, weiter in die Logs geschrieben und bereits bei 58A0 weiter gemacht. Lösung: Grundvorraussetzung ist ein Backup der Postfachdatenbank, im Grunde ist es egal ob diese im "Dirty Shutdown" hängt oder diese sauber ist. Wichtig ist im Falle eines "Dirty Shutdown" Zustandes, dass die Log-Dateien, die von der Datenbank noch benötigt werden, vorhanden und intakt sind. WICHTIG: Nachdem das Backup eingespielt wurde NICHT einfach ein Soft-Repair starten, da dann der aktuelle Log-Status in die Datenbank geschrieben wird und somit auch für die Datenbank die fehlenden Log-Einträge benötigt werden. Wir gehen also wie folgt vor: 1. Aktuelle Datenbank sichern (nur für den Fall der Fälle) 2. Sichern Sie auch die Transaktions-Logs 3. Alte Sicherung der Datenbank einspielen 4. In das Verzeichnis mit den Log-Dateien wechseln 5. Den Befehl eseutil /mh "Pfad zur Datenbank" ausführen. Damit wird der Header der Datenbankdatei ausgelesen. Unter dem Punkt "Logs required" finden wir die Log-Einträge, die von dieser Datenbank benötigt werden. Steht hier 0-0 ist eh alles in Ordnung. Wir gehen hier aber jetzt davon aus, dass dort Einträge auftauchen, die Datenbank also im "Dirty Shutdown" Status hängt. 6. Die Zeile "Logs required" beinhaltet am Ende in Klammern die IDs der Log-Einträge die benötigt werden, bitte überprüfen ob diese vorhanden sind, wenn dies nicht der Fall ist muss die Datenbank entweder von einer Datenbank die "Clear Shutdown" ist ersetzt werden oder man muss eine Hard-Recovery machen. 7. Kommen wir nun zum wichtigen Teil: Wir suchen uns die letzte Log-Datei von der wir wissen das bis zu Ihr die Log-Dateien konsistent sind. Nehmen wir als Beispiel die Einträge aus der Problematik, d.h. wir wissen, dass die Dateien 589c - 589f fehlen, daraus resultiert, dass die letzte konsistente Log-Datei 589b war. Um die Kollisionen mit den nicht vorhandenen Dateien zu beseitigen, löschen wir alle Dateien die nach 598b generiert wurden. In unserem Fall alles von 58A0 und neuer inkl. der E00.log (bzw. die Datei mit Ihrem Log-Datei Präfix, das Ihre Datenbank verwendet). 8. Löschen Sie auch die E00.chk, die sogenannte Checkpoint Datei. 9. Benennen Sie nun die Datei 598b in E00.log um (oder in das Log-Datei Präfix, das Ihre Datenbank verwendet). 10. Führen Sie nun den Befehl eseutil /ml aus. Dies bewirkt eine Prüfung der Log-Konsistenz. Wenn keine anderen Dateien Fehlen oder beschädigt sind, sollte der Vorgang erfolgreich abgeschlossen werden. Sollte dies nicht der Fall sein, wiederholen Sie entsprechend die Schritte 7 bis 9 mit den neuen Informationen und führen danach den genannten Befehl erneut aus. Beachten Sie, dass im Falle einer "Dirty Shutdown" Datenbank die benötigten Log-Dateien erhalten bleiben müssen. 11. Sobald die Log-Dateien wieder konsistent sind können wir dazu über gehen das Soft-Repair auszuführen. eseutil /r E00 Je nach Größe der Datenbank kann dieser Vorgang eine ganze Weile dauern. E00 entspricht hier wieder ihrem Log-Datei Präfix. Der Vorgang sollte nun erfolgreich durchgeführt werden und Ihre Datenbank "Clear Shutdown" sein, dies kann mit dem Befehl aus Schritt 5 überprüft werden. 12. Fahren Sie Ihre Exchange Dienste hoch, die Datenbank sollte einwandfrei eingebunden werden. Disclaimer: Diese Anleitung basiert auf meinen Erfahrungen und ich garantiere nicht, dass diese zum Erfolg führen muss. Anwendung auf eigene Gefahr.
  2. Okay, die Dateien sind alle vorhanden, auch die 587c.
  3. Hi, danke für die schnelle Antwort. Das ist ja gerade der Witz. Die .edb liegt auf dem RAID, die Logs aber noch auf der System-Platte, auf der nichts passiert ist. Ich hab jetzt mal ein eseutil /mh ausgeführt, hier das Ergebnis: C:\Program Files\Microsoft\Exchange Server\V14\Bin> \Microsoft\Exchange Server\V14\Mailbox\Mailbox Data ase 2011101616.edb" Extensible Storage Engine Utilities for Microsoft(R Version 14.01 Copyright (C) Microsoft Corporation. All Rights Res Initiating FILE DUMP mode... Database: G:\Program Files\Microsoft\Excha x Database 2011101616\Mailbox Database 2011101616.e DATABASE HEADER: Checksum Information: Expected Checksum: 0x0da81422 Actual Checksum: 0x0da81422 Fields: File Type: Database Checksum: 0xda81422 Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,17 Engine ulVersion: 0x620,17 Created ulVersion: 0x620,17 DB Signature: Create time:10/16/2011 16:41:47 cbDbPage: 32768 dbtime: 10641939 (0xa26213) State: Dirty Shutdown Log Required: 22652-22672 (0x587c-0x5890) Log Committed: 0-22673 (0x0-0x5891) Log Recovering: 0 (0x0) GenMax Creation: 12/12/2011 10:07:53 Shadowed: Yes Last Objid: 4671 Scrub Dbtime: 0 (0x0) Scrub Date: 00/00/1900 00:00:00 Repair Count: 0 Repair Date: 00/00/1900 00:00:00 Old Repair Count: 0 Last Consistent: (0x5234,8,1F) 12/01/2011 10:33: Last Attach: (0x5235,9,86) 12/01/2011 10:33: Last Detach: (0x0,0,0) 00/00/1900 00:00:00 Dbid: 1 Log Signature: Create time:10/16/2011 16:41:45 OS Version: (6.1.7600 SP 0 NLS ffffffff.ffff Previous Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Incremental Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Copy Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Differential Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 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 ECC Fix Success Count: none Old ECC Fix Success Count: none ECC Fix Error Count: none Old ECC Fix Error Count: none Bad Checksum Error Count: none Old bad Checksum Error Count: none Last checksum finish Date: 00/00/1900 00:00:00 Current checksum start Date: 00/00/1900 00:00:00 Current checksum page: 0 Operation completed successfully in 0.141 seconds. Wie zu sehen ist, ist die Checksumme okay. Dank dieser Ausgabe bin ich aber einen Schritt weiter gekommen: Log Required: 22652-22672 (0x587c-0x5890) Log Committed: 0-22673 (0x0-0x5891) Die Log mit der ID 5891 ist vorhanden, auch die Log 5890 ist vorhanden. Ich werd mal schauen von welchem Zeitraum die 587c ist, vielleicht krieg eich die aus einer Sicherung wieder raus.
  4. Hallo zusammen, ich habe folgendes Problem mit einem Exchange 2010 Server auf einem SBS2011: Im besagten Server ist das RAID heute down gegangen, wegen eines Festplatten Defekts, dieses konnte aber wiederbelebt werden und das eigentlich ohne Datenverluste. Jedoch schmeißt mir der ESE Dienst den folgenden Fehler: Information Store (2068) Mailbox Database 2011101616: Datenbank G:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 2011101616\Mailbox Database 2011101616.edb benötigt die Protokolldateien 22652-22673 für eine erfolgreiche Wiederherstellung. Es wurden nur Protokolldateien gefunden, die bei 22653 beginnen. Und danach den Fehler 454 vom ESE. Nun habe ich die Anleitung ESE 454 -515: Missing Required Transaction Log File von Microsoft befolgt, jedoch mit mäßigem Erfolg. An der Stelle wo für Exchange 2007 beschrieben ist, wo der Log-Pfad ist, sind die Informationen nicht mehr aktuell für den 2010. Nun hab ich mich selber auf die Suche gemacht und Log-Einträge unter C:\Program Files\Microsoft Exchange\V14\Mailbox\Mailbox Database 2011101616 gefunden. Entsprechend habe ich auch eseutil /ml .... ausgeührt. Mit dem Ergebnis, dass die Log-Dateien in Takt sind. Jedoch ist die Datei mit der Ziffer 22653, die laut Fehlermeldung noch vorhanden sein soll nicht darunter und diese ist auf dem Server nicht zu finden. Ich hab mir die Zeitstempel der Dateien auch mal angeschaut, diese scheinen auch alle durchgängig zu sein und auch die Nummerierung stimmt soweit auch. Ich hab zu dem Thema noch diesen Artikel gefunden: Source: ESE Event ID: 452 (Exchange 8.0) - Technet Events And Errors Message Center: Message Details Wobei dort primär "radikale" Wege beschrieben werden. Hat einer einen Tipp für mich, wie ich das Problem vom Tisch kriege?
  5. Ne, ich hab den Fehler gefunden: Der Mensch vor dem Bildschirm :) Hatte vergessen zur erwähnen, dass das Quell System momentan eine VM ist und aus irgend einem Grunde (obwohl ich sie zuvor deaktiviert hatte) war auf dem Host System für die Quelle die Windows Firewall wieder an. Deaktiviert und jetzt läufst. Trotzdem vielen, vielen, vielen Dank für die Unterstützung.
  6. Ja, habe einen neuen Benutzer mit der Basis Rolle Domain-Benutzer angelegt und diesen nachträglich zu den Gruppen Domain-Admins, Organisation-Admins und Schema-Admins hinzugefügt. Die vollständige Antwort Datei gibt's im Anhang. In der Log steht das hier: [1432] 111016.142942.5165: Setup: Completed networking configuration, now checking migration information. [1432] 111016.142942.8845: Setup: Pinging old server name. [1432] 111016.142942.9025: Setup: Ping reply status = Success [1432] 111016.142943.0055: Setup: Connecting to domain and validating credentials. [1432] 111016.142943.0915: Setup: Networking might not ready, retry 1 here [1432] 111016.142943.5936: Setup: Networking might not ready, retry 2 here [1432] 111016.142944.0966: Setup: Networking might not ready, retry 3 here [1432] 111016.142944.6006: Setup: ShowPage() indicated that the migration information is not right Ja, beide Server hängen am gleichen Switch.
  7. Also die 2. Netzwerkkarte wird halt automatisch vom SBS Setup deaktiviert. Ich bin so vorgegangen: 1. Quellserver aufgeräumt 2. Updates installiert 3. DNS Bereinigt 4. Das SBS Migration Tool ausgeführt, Prüfung alles okay und Antwort Datei generiert 5. USB Stick mit Antwort Datei in den Zielserver gesteckt 6. Installation auf Zielserver ausgeführt 7. Nach der automatischen Konfiguration von Quell- und Zielserver IP bricht mir das Setup beim Schritt zur Anmeldung am Quellserver mit oben genannten Fehler ab. Danach bin ich hingegangen und hab mit dcdiag die Integrität des Active Direktors auf dem Quellserver nochmals überprüft, genauso wie den DNS. Alles in bester Ordnung. Alle anderen Rechner haben auch normalen Zugriff auf den Server von den Latenzen und auch vom DNS her, nur nicht der, auf dem das 2011 Setup ausgeführt wird. [uPDATE] Hier mal die Struktur des Netzes: 192.168.2.1 <- ROUTER 192.168.2.254 <- Quellserver (DNS, DHCP, AD, DC, ...) 192.168.2.250 <- Zielserver Wenn ihr weitere Infos braucht, nur zu.
  8. Sowas hatte ich mir ursprünglich auch gedacht. Aber dem ist leider nicht so. Im übrigen kommt der SBS 2011 auch mit mehr als einer Netzwerkkarte aus halt wohl nur nicht bei der Migration. Hab auch schon versucht Windows so zu überlisten, dass ich eine der Netzwerkkarten komplett deinstalliere, leider läd sich Windows die Treiber zügig nach.
  9. Hi, bin gerade dabei besagtes Vorhaben in die Tat um zu setzen. Server Vorbereitungen einwandfrei, alle Active Direcory und DNS Tests die so empfohlen wurden in diversen Artikeln alle perfekt durch gelaufen. Nur leider bin ich Opfer des Phänomens geworden, dass der SBS 2011 den Quellserver nicht findet. Andere Clients die ich im gleichen LAN habe laufen einwandfrei inkl. DNS, Gateway etc.. Nur der SBS 2011 kriegt die Domäne nicht so aufgelöst wie es sein soll. Ich kann den Server pingen und der Server kann auch den Quellserver pingen, wobei letztres mit riesigen Latenzen verbunden ist. Ich hab jetzt so ziemlich jedes Howto durch geschaut um raus zu finden wie ich das Problem lösen kann. Nur dummer weise kann ich eine Sache nicht testen, nämlich nur eine LAN-Karte zu verwenden. Das Intel Server Board das ich im Einsatz habe erlaubt scheinbar nur das abschalten des LAN Boot-Roms, aber nicht das abschalten der NICs an sich. Da der Server so bald wie möglich wieder Fit sein muss, bin ich für alle Tips und Ratschläge dankbar. Viele Grüße!
  10. Hallo zusammen, ich habe ein etwas unkonventionelles Projekt vor mir, nämlich die Umstellung eines Server 2008 mit Exchange 2007 auf einen Small Business Server 2011 Standard. Ich suche schon seit Tagen im Netz nach Erfahrungsberichten, bin aber bis jetzt leider nicht fündig geworden. Wenn jemand in dieser Richtung Erfahrungen hat, die bei diesem Prozess hilfreich sein könnten, würde ich mich sehr freuen. Gruß, BNO
×
×
  • Neu erstellen...