Exchange 2010 - DB läuft voll und Logs werden nicht abgeräumt

[massaraksch 41]

Hi,

 

evtl. mal die Queues auf "gestrandete" (defekte/große) Messages untersuchen...

Get-TransportServer | Get-Queue | ? { $_.MessageCount } | Get-Message

Mehrmals ausführen und schauen, ob da Mails drin sind, die über einen längeren Zeitraum nicht "verschwinden" (also nicht übertragen werden).

 

Die Eigenschaften der Mails anzeigen:

Get-TransportServer | Get-Queue | ? { $_.MessageCount } | Get-Message -IncludeRecipientInfo | fl

Da steht dann auch Size drin und LastError usw.

[Maraun 12]

Habs rausgefunden, Airwatch-SEG (MDM-Activesync).
Sobald auf der Maschine in der DMZ die Dienste gestoppt werden, schreibt der Exchange circa 90-100 Tlogs in 10 Minuten.
Sobald ich die Dienste wieder anstarte und Active-Sync auf den iPhone/iPad-Devices (knapp 500 Devices) funktioniert, wird das 10fache an Logs geschrieben für beide Benutzer-DBs.

[tesso 375]

Ein MDM schreibt aber keine Transaktionlogs.

Höchstens die User mit den Handys. Dafür sind es mir aber zu viele.

 

Du musst noch ein anderes Problem haben.

 

Moment: airwatch seg ist ein Mailgateway, kein MDM. Ich würde mir das Gateway anschauen, was dort für Mails durchgehen.

bearbeitet 25. April 2017 von tesso

[Maraun 12]

Hallo,

 

ja, handelt sich definitiv um das Mailgateway. Sobald dort die Airwatch-Dienste und der WWW-Dienst down sind, ist alles wieder normal.

Heute Morgen haben wir per Firewall alle internen/externen Connections unterbunden um zu sehen, ob das vom System oder den Devices kommt.
Nachdem keine Connection mehr zustande kam durch die Devices hat sich alles beruhigt von den Tlogs.
Habe jetzt mal Syncstatistiken zwischen dem 19.04. (noch keine Probleme) und den letzten Tagen erstellt (Activesyncreport.ps1). Ich sehe keine Auffälligkeiten wie mehr Hits, mehr Syncs oder irgendwas.

[Maraun 12]

Eine ganz vage Theorie, die vielleicht jemand mit Erfahrungswerten speziell Richtung ActiveSync von MDM Devices ad absurdum oder eventuell bestätigen kann.

Mitte Februar habe ich ActiveSync über unser TMG per Firewall Policy abgestellt. Seitdem kommen nur noch MDM-Geräte Per Airwatch-Mailgateway durch die DMZ auf die Mailserver mit ActiveSync.

Seit diesem Datum funktioniert unsere Mailarchivierung nicht mehr. 3rd Party Tool von metalogix, mit Journal und Postfacharchivierung.

Vor einer Woche etwa haben wir unser Backup auf Veeam umgestellt.

 

Jetzt die Theorie:

Seit der Abschaltung des MS TMGs haben wir diese Auslastung und den Plattenanwuchs auf den Postfachservern. Bisher ist es nicht aufgefallen, weil es keine Events gibt und Nachts das Backup die TLogs weggeräumt hat. Nach der Umstellung auf Veeam lief das Backup nicht sauber und die Platten liefen voll. Durch die Auslastung konnte die Mailarchiv-Software die Postfächer nicht mehr richtig erreichen bzw. Archivieren. Zu der Theorie passt, dass ich Activesync-Daten verglichen habe und keinerlei Auffälligkeiten von Tagen sehe, bei denen alles noch in Ordnung war.

Diese Theorie fußt aber darauf, dass solch eine Auslastung entweder normal ist bei 500 Devices, oder dass etwas nach wie vor 1200 Tlogs in 10 Minuten provoziert.
Wir nutzen knapp 500 MDM-Devices.

bearbeitet 28. April 2017 von Maraun

[Maraun 12]

Hallo zusammen,

muss meinen Thread hier nochmals beleben, da irgendwie keiner einen Fehler bei uns findet:

Exchange und Mailarchiv-Consultant war 2 Stunden remote auf dem System, ohne sichtbaren Erfolg.

Airwatch Support hat einen Querschnitt/Ausschnitt der Tlogs analysiert und meint, dass das ganz normale Mails udn ActiveSync-Anfragen sind.

Zahlen zu unserem Problem:

2 Datenbanken von 5 Stück in unserer DAG schreiben laufend Tlogs. Alle DBs, die DB-Copys und der ContentIndexState sind mounted und healty.

DB1
Partitionsgröße: 1.29TB
DB-Größe: 1.04TB
Postfächer: 652
Logfiles in der Stunde: 3796

DB2
Partitionsgröße: 1.56TB
DB-Größe: 1.42TB
Postfächer: 761
Logfiles in der Stunde: 4334

 

Dazu haben wir circa 500 mobile Devices.

Das heißt, am Tag werden pro DB etwa 35-40GB an Tlogs geschrieben, die Nachts von Veeam abgeräumt werden.

Aber warum? Traffic durch bestimmte User oder ios etc. bereits getestet.
Mailarchivierung läuft parallel und räumt Mails aus dem Journal ab. Aber die Journal-Mailbox ist mit 1,5GB abgeräumt und up-to-date.
Die Journal-Mailbox liegt in einer seperaten DB, deren Tlogs auch nicht über Standard anwachsen.

Hat jemand noch eine Idee, bezüglich des TLogs-Wachstums?

Danke und Gruß
 

bearbeitet 10. Mai 2017 von Maraun

[gelöscht 0]

Lege die Journal Mailbox mal in eine separate, dedizierte Datenbank.

 

ASR

[Maraun 12]

Hi, wobei ich erwähnen muss, dass die Journal Mailbox NICHT in einer der beiden DBs liegt, deren Tlogs so rapide ansteigen/geschrieben werden.

[Maraun 12]

Also mittlerweile sind jeweils Support-Mitarbeiter der Mailarchivierung und der MDM Lösung auf unseren Systemen gewesen, ohne den fehler zu finden.

Bzw. ist laut denen klar, dass es nicht ihre Software verursachen kann. Das Airwatch-SEG schreibt pro Mail ein IIS-Log auf dem SEG und auf dem Exchange.

Nichts wird vervielfältigt oder multipliziert. Die Zahlen mit knapp 4000 Tlogs pro Stunde, die jeweils nur für die beiden großen DBs geschrieben werden, sind nach wie vor der Fall.

Habe nur noch die Idee, die zwei DBs neu anzulegen.

Hat von Euch noch jemand einen Ansatz auf dem Exchange?

Die einzige Umstellung bisher war der Wechsel von netBackup auf Veeam als Backup.

Das Eventlog zeigt mir dauern folgendes:
Continuous replication block mode is unable to keep up with the data generation rate. Block mode has been suspended, and file mode has been resumed.

Kommt für beide DBs im Eventlog auf dem Mailboxserver.

 

Viele Grüße

Alex

[testperson 1.680]

Hi,

 

hast du mal einen Case bei Microsoft aufgemacht? Ggfs. können die den Verursacher benennen oder das Problem beheben.

 

Gruß

Jan

[Maraun 12]

Hi Jan,

 

ja habe ich.

Als die aber vernahmen, dass 3rd Party Anwendungen (Mailarchiv, MDm) involviert sind und die Tlogs sich nach dem stoppen der Airwatch SEG-Dienste wieder beruhigen,

war es das für die. Zumal darauf verwiesen wurde, dass für eine tiefere Analyse ein Premiervertrag notwendig ist.

Es würde schon mal helfen, wenn man irgendwie die Tlogs mal analysieren könnte.
Eben nochmals für beide DBs die Postfachgrößen gecheckt, aber es ist einfach kein Ausreisser oder Verursacher erkennbar.

Die Replication Block Mode Meldung ist ja nur eine Folge der vielen Tlogs, die geschrieben werden.

Gruß
Alex
 

[NorbertFe 2.035]

Na würde ich auch, wenn du das sagst. Wenn die airwatch Dienste gestoppt sind ist es also "normal"? Dann wäre meine Schlussfolgerung die selbe wie die vom pss.

[Maraun 12]

Das kann ich auch verstehen, aber gestern hatte ich zwei Airwatch-Techniker dran und ich habe mehrfach Mails von einem iPhone an mein Outlook und zurück gesendet.
Wie bereits erwähnt, fanden wir nur ganz normale einzelne IIS-Einträge für den Sendevorgang. Damit ist von Seiten Airwatch bewiesen, dass das Problem auf dem Exchange sitzt.

Es ist so, als ob er für jedes normale gesendete/empfangene Mail von einem Mailbox-User dieser beiden DBs das zigfache an Tlogs geschrieben wird.

[testperson 1.680]

Bei einer handvoll betroffener User EAS ausschalten und beobachte was die TLogs machen? Um so evtl. an den User ranzukommen?

Oder eben die User nach und nach in eine neue DB verschieben und beobachte ob und ab wann da das Problem los geht?

[Maraun 12]

Also ich habe vorher nochmals die Active Sync Datenstatistik mit anderen Tagen/Wochen verglichen. Ebenso die momentanen Mailboxgrößen auf den zwei Datenbanken.

Bei beidem ist nichts auffälliges oder etwas, das direkt ins Auge sticht.
Somit wird wohl das vorgehen mit dem Umzug in eine neue DB die einzige Vorgehensweise sein.