dmks.23

Also nach einiger Beobachtung scheint es tatsächlich unnötige Sorge gewesen zu sein.

Logs wurden überall von Zeit zu Zeit abgeschnitten. Es muss hier also einen Grenzwert geben, der das Entfernen regelt. Wo der liegt hab ich aber nicht herausfinden können.

Meine Vermutung ab 1GB an Logfiles wird angefangen zu bereinigen. Die größe des Log-Files selbst spielt dabei eine untergeordnete Rolle.

vor 44 Minuten schrieb tesso:

Sind evtl. die Logs noch nicht in alle Datenbanken geschrieben worden? Arbeitet ihr mit verzögerten Kopien?

Also ich hab jetzt immer nur die anzahl der Logs verglichen passiv und aktiv und naja Eventlog ist halt leer. Kann ich das über die shell live loggen, für eine DB?

Hatten wir auch schon bereits in Vermutung, aber wurde hier nicht eingerichtet.

vor 3 Minuten schrieb cj_berlin:

Moin,

wenn der Zeitstempel korrekt gesetzt wird, scheint alles zu funktionieren. In einer DAG werden ja mehr Logs vorgehalten, wenn mehrere Kopien vorhanden sind, daher würde ich etwas mehr Zeit zwischen den Backups verstreichen lassen, so dass vielleicht ein paar Tausend Logs auflaufen, und dann schauen, wieviele davon verschwinden.

Ja täglich grüßt das Murmeltier. Du hast recht, eben grade reingeschaut Logs wurden abgeschnitten. Nun Frage ich mich wo liegt hier für Exchange die Grenze, weiß das jemand?

vor 16 Stunden schrieb NorbertFe:

Wieviele Logs sind das und welches Backupprodukt nutzt ihr? Wenn "zu wenige" Logs vorhanden sind, werden die ggf. erst beim nächsten Mal entfernt. Kenne ich vom Kunden mit Veam und 4 Node Cluster.

500 Logs waren es bei der größten DB. Wir nutzen Dell Networker, das mit Veam habe ich auch schon gelesen, traf aber bei uns nicht zu, weil das Problem ja auch bereits beim Windows Backup besteht.

vor 15 Stunden schrieb cj_berlin:

Danke für das Vertrauen darauf, dass wir alle Event IDs von Exchange auswendig können.

Aber mal anders gefragt: Nach einem Backup mit zwei Kopien, wird da der Backup-Zeitstempel auf der Datenbank gesetzt? Falls ja, hast Du kein Problem, und es sind in der Tat "zu wenige" Logs.

Haha ja sorry deine Aussagen waren so kompetent, da dachte ich du weißt das auswendig :d

Die Zeitstempel vom Backup werden korrekt gesetzt.

vor 15 Stunden schrieb tesso:

Die Fehler geben her das du den Server neustarten solltest. Wenn das nicht hilft ein Ticker bei MS eröffnen sollst.

Server wurden auch neugestartet, jedoch ohne Erfolg.

vor 12 Minuten schrieb cj_berlin:

Moin,

 

wenn Logs nicht gelöscht werden können, wird es im Application EventLog protokolliert. Auch wenn sie abgeschnitten werden, wird es dort protokolliert. Dass man nach dem Hinzufügen und Entfernen von Kopien den Information Store neu starten muss, hast Du berücksichtigt?

Sicherst Du die aktive oder die passive Kopie? Falls die aktive Kopie klappt und die passive nicht, ist die Cluster-Kommunikation kaputt.

Exchange schneidet die Logs nicht auf Null an, sondern behält einige. Vor Einführung der DAG waren das, meine ich, acht (á 5 MB), ab Exchange 2010 sind es mehr, allerdings á 1MB, 100 könnte hinkommen.

 

Der Fehler kommt bei passiven, sowie aktiven Kopien zu Stande.

Ja Information Store wurde mehrfach neugestartet. Die Datenbanken haben wir auch zum Tests einmal über die Shell erstellt. Ohne Erfolg

Folgende Logs finde ich im Application Log:

Quelle: ESE  ID: 225

Quelle: MSEXCHRepl ID: 2046

Jedoch keine Warnung oder Fehler

Wir haben auf anderen Datenbanken auch deutlich mehr Log-Files, ca. 500. Dort befinden sich Logs die schon älter als ein Monat sind.

Hi Leute,

ich hab einen Exchange-Server hier, welcher nach Einrichtung des DAG die Logs nicht automatisch löscht.

Fehlermeldung im Truncating Log finde ich leider auch keine.

Sobald ich die DB-Kopie entferne und eine Vollsicherung durchführe (Windows Backup), werden die Logs auch korrekt entfernt. Ist eine DB-Kopie vorhanden passiert nichts.

Updatestand: CU12 + aktuelle Windoofupdates'

Alle DB's liegen auf eigenen Laufwerken, sowie dessen Logs.

Als eigentliche Backuplösung wird in diesem Falle Dell verwendet. Der Fehler lässt aber wie schon erwähnt mit dem WindowsBackup nachstellen.

VSSwriter wurde bereits geprüft > alles i.O.

DB's wurden neu erstellt und Postfächer migriert. Da hätte ich noch die Frage müssen die Logs mindestens 100MB groß sein bevor der Exchange Server anfängt Diese zu löschen?

Grüße,

DerMarKuS

vor 21 Minuten schrieb NorbertFe:

Du hast dafür 3 Jahre gebraucht? :)

 

Danke für die Rückmeldung

Haha nein Firma gewechselt und dabei ist mir aufgefallen, dass ich ja mal hier einen Account hatte

Letzlich hab ich dann via adsiedit die DB weggeworfen. Dank dir

vor 14 Stunden schrieb Nobbyaushb:

Was gibt  Get-Mailbox -Arbritration aus?

Garnichts auf der betroffenen DB. Gleiches gilt für AuditLog, PublicFolder,

Es wurden die Monitoring Postfächer verschoben und HealthMailboxes entfernt.

Exchange 2016 CU12 ist installiert

Nein das denke ich auch nicht.

Nur finde ich keine System-Postfächer mehr auf der zu löschenden DB.

Und die Healthmailboxes wurden wie erwähnt auch entfernt.

Hallo liebe Community,

Ich habe heute bei unseren Exchange Systempostfächer umgezogen, weil ich eine alte DB entfernen wollte.

Dabei wurden versehentlich die Monitoring Mailboyen mit verschoben und ich bekomme die Datenbank nicht gelöscht.

Im Anschluss kamen korrupte Healthmailboxes dazu. Entsprechend dazu wollte ich Diese neu erstellen. Ab diesen Moment sind die öffentlichen Ordner im Outlook verschwunden. Die Inhalte sind jedoch noch da und wenn ich als Dom-Admin mir die Postfächer einbinde erhalte ich auch die öffentlichen Ordner.

Nach dem Nerustart des Healthmanagers werden keine neuen Healthmailboxes erstellt. Im Internet finde ich nur den gängigen Workaround. Hat hier einer eine Idee was ich tun kann?