none
Exchange 2007 Kopierstatus = Fehler RRS feed

  • Frage

  • Hey Leute,

    ich habe ein Problem mit meinem Exchnage. Die Festplatten sind leider plötzlich voll gelaufen und die DB's wurde offline geschaltet leider aber nicht alle sauber. Also habe ich einige der Protokolle gelöscht und auf dem Cluster einen Schwenk gemacht. Dannach sind alle DB's wieder online gegangen. Nun steht aber in der Exchange-verwaltungskonsole im Bereicht "Postfach" - "Datenbankverwaltung" in der Spalte "Kopierstatus" bei einigen DB's = Fehlerfrei, Initialisieren und Fehler.

    Ich habe nun in dem Eventmanager nachgeschaut und folgendes entdeckt:

    Ereignistyp:    Fehler
    Ereignisquelle:    MSExchangeRepl
    Ereigniskategorie:    Dienst
    Ereigniskennung:    2067
    Datum:        29.05.2012
    Zeit:        13:35:44
    Benutzer:        Nicht zutreffend
    Computer:    ClusterNode2
    Beschreibung:
    Die neu kopierte Protokolldatei h:\SG7\inspector\E06.log für ger-cluster\SG7 ist fehlerhaft. Erneutes Seeding des passiven Knotens ist erforderlich. Verwenden Sie das Cmdlet 'Update-StorageGroupCopy' in der Exchange-Verwaltungsshell, um ein erneutes Seeding auszuführen.

    Kann mir da jemand helfen die Fehler zu beseitigen?

    PS. was bedeutet eigentlich "Initialesieren" in Kopierstatus?

    Vielen Dank.

    Dienstag, 29. Mai 2012 11:48

Antworten

  • Hi homermg,

    insgesamt ein abenteuerliches Vorgehen, das Du da gewählt hast, aber das ist ja nicht die Frage.

    Den Status "Initialisieren" kannst Du am ehesten beseitigen, wenn Du die Datenbanken der betreffenden Speichergruppe dismountest und anschließend wieder mountest (Bereistellung aufheben + Datenbank bereitstellen). Empfehlenswert ist das außerhalb der Service-Zeit. Wenn der Speichergruppenkopierstatus auf "initialisieren" stehenbleibt, dann sind aktive und passive Kopie grundsätzlich in Ordnung, es wird nur nicht korrekt angezeigt.

    Anders bei den Speichergruppenkopien, die im Fehler stehen, hier muss ein Reseeding der Datenbanken her:

    - Anmelden auf dem passiven Knoten

    - Aussetzzen der CCR-Replikation auf der Exchange Management Shell: Suspend-StorageGroupCopy -identity "<CMS>\<StorageGroupname>"

    - Anstoßen des Reseeding mit Überschreiben der bestehenden Dateien: Update-StorageGroupCopy -identity "<CMS>\<StorageGroupname>" -DeleteExistingFiles

    - Nach dem Seeding die Wiederaufnahme der CCR-Replikation: Resume-StorageGroupCopy -identity "<CMS>\StorageGroupname"

    CMS ist hier der Platzhalter für Clustered Mailbox Server, also der Name unter dem die Clients den Server ansprechen.

    Für die Zukunft:

    - untersuchen, warum die Platten vollgelaufen sind, evtl. mal das Backup überprüfen, es scheint als seien hier keine Logs abgeschnitten worden (sonst hättest Du nicht einfach paar davon löschen können).

    - eine Monitoring-Lösung ins Auge fassen

    - sich mit eseutil vertraut machen (um nachschauen zu können, welche Logs ggf. fehlen oder welche wirklich gelöscht werden können)

    Viel Erfolg und Grüße,

    Markus

    • Als Antwort markiert homermg Dienstag, 29. Mai 2012 15:15
    Dienstag, 29. Mai 2012 12:29

Alle Antworten

  • Hi homermg,

    insgesamt ein abenteuerliches Vorgehen, das Du da gewählt hast, aber das ist ja nicht die Frage.

    Den Status "Initialisieren" kannst Du am ehesten beseitigen, wenn Du die Datenbanken der betreffenden Speichergruppe dismountest und anschließend wieder mountest (Bereistellung aufheben + Datenbank bereitstellen). Empfehlenswert ist das außerhalb der Service-Zeit. Wenn der Speichergruppenkopierstatus auf "initialisieren" stehenbleibt, dann sind aktive und passive Kopie grundsätzlich in Ordnung, es wird nur nicht korrekt angezeigt.

    Anders bei den Speichergruppenkopien, die im Fehler stehen, hier muss ein Reseeding der Datenbanken her:

    - Anmelden auf dem passiven Knoten

    - Aussetzzen der CCR-Replikation auf der Exchange Management Shell: Suspend-StorageGroupCopy -identity "<CMS>\<StorageGroupname>"

    - Anstoßen des Reseeding mit Überschreiben der bestehenden Dateien: Update-StorageGroupCopy -identity "<CMS>\<StorageGroupname>" -DeleteExistingFiles

    - Nach dem Seeding die Wiederaufnahme der CCR-Replikation: Resume-StorageGroupCopy -identity "<CMS>\StorageGroupname"

    CMS ist hier der Platzhalter für Clustered Mailbox Server, also der Name unter dem die Clients den Server ansprechen.

    Für die Zukunft:

    - untersuchen, warum die Platten vollgelaufen sind, evtl. mal das Backup überprüfen, es scheint als seien hier keine Logs abgeschnitten worden (sonst hättest Du nicht einfach paar davon löschen können).

    - eine Monitoring-Lösung ins Auge fassen

    - sich mit eseutil vertraut machen (um nachschauen zu können, welche Logs ggf. fehlen oder welche wirklich gelöscht werden können)

    Viel Erfolg und Grüße,

    Markus

    • Als Antwort markiert homermg Dienstag, 29. Mai 2012 15:15
    Dienstag, 29. Mai 2012 12:29
  • super vielen vielen Dank!

    Jetzt habe ich nur noch eine Sache noch. bei einer DB steht unter dem Status zwar "Bereitgestellt" aber unter dem "Kopiestatus" Angehalten
    Kannst du mir da auch weiterhelfen?

    VG

    Sorry hat sich schon erledigt habe die CCR-Replikation angehalten und wieder gestartet

    Danke dir

    • Bearbeitet homermg Dienstag, 29. Mai 2012 15:15
    Dienstag, 29. Mai 2012 15:12
  • Genauso; wenn der Befehl Suspend-StorageGroupCopy abgesetzt ist, dann siehst Du in der GUI "Angehalten" im Kopierstatus.

    In der GUI hieße es dann auch "Speichergruppenkopie wieder aufnehmen"; Shell wäre Resume-StorageGroupCopy.

    Gruß,

    Markus


    MCSE:Messaging

    Dienstag, 29. Mai 2012 16:30