mailbox databases dismounting frequently without followable reason

[BroBias 5]

I have a 3 node DAG (EX2016, current patchlevel), 2 in "main" AD site and 1 in backup site. It's about 400 users homed in 9 mailbox databases currently. Since a few days on of the nodes in the main AD site doesn't keep db mounts anymore.

So, when i e.g. do a manual switchover, the db is mounted properly for some seconds. Then a store transient error occurs, results in a disablement of "readfrompassive" feature, dismounts the db again and failing over to node 1 again or node 3 - depending the load.

The "error structure" respectively the "process" happening when switching active copies to this server is always the same. I can reproduce it with every database on this server.

1. Manual or automatic switchover to "node2" occurs, starting with Event 2090 informing about.
2. Followed by 5 ESE informational events telling the log reply and db attaching.
3. Then "MSExchangeIS" reports that the feature component "readfrompassive" (1061) has been re-enabled.
4. Then the first error occurs "1001 - MSExchangeIS - MSEXCH info store encountered an internal logic error"
5. Followed by an unhandled exception "1002 - processid perf counter (0) does not match actual process id.."
6. Followed by a watson report error (4999) of the M.E.Store.Worker
7. Only then the next error provides a bit (!) more information: "489 ESE - attempt to open edb-file for read only access failed with system error 32 (used by another process)"
8. This is then followed by some Windows Error Reporting events (informational, 1001), some informational MSExchangeIS events (1021,40008,40036) ...
9. Followed by another bunch of ESE events telling about log replays of the db about to be mounted ... ??
10. Funny enough ...: Only then "MSExchangeIS - 40008" reports that the db has been mounted successfully.
11. Stopping worker process (1021)
12. Starting MapiAddressBookAppPool (2000,2001)
13. "MSExchange Mid-Tier Storage" informs about "PICW Core feature not enabled" (11000)
14. Now another 4999 error is logged about "MSExchangeDelivery, M.ExchangeStoreProvider, M.E.M.S.DeliveryItem..." crashing > stacktrace result "MS.Mapi.CrossServerConnectionPolicy.Apply"
15. Followed by 2 Windows Error Reporting informational events
16. And finally followed by a ExchangeStoreDB event (126) informing about that a db copy on this server caused an error which resulted in dismounts. The reason should be looked up in previous events (see above ^^)

Referring this it looks like that the server is trying to mount a db 3 times by default .... ? Every time it results in more or less same error events.

What i have already tried:

• purge one of the passive copies on problematic node, delete related files and recreate the passive copy again newly
  • Try to reproduce: Still failing as described above.
• Review file/folder permissions on db and log storage locations (separated disks/volumes).
  • Actually there was an issue with partially incorrect permissions -> corrected all ownership back to administrators group and re-applied default permissions
    • Unfortunately, this had also no effect at all - still same failing while activating db copy on this node
• Sending server to maintenance mode and shut down, check dbs with eseutil: all in dirty shutdown state (but still mounting even though only for a short time??)
• Read tons of kb articles and forum discussions related to such and similar behavior - no further insights unfortunately.

Any help, ideas, tipps & tricks are highly appreciated. :)

[Damian 1.519]

Hello and Welcome on Board!

 

First: When you walk into a room full of people, it's nice to say "Hello".

Second: MCSEboard.de is a german speaking community. Not everyone is fluent in English, so we prefer contributions in German. Please keep this in mind in the future, thank you.

 

With regards

Damian

[testperson 1.673]

Hi,

 

since we are a german speaking Microsoft community it would be nice if you could post in german. Nevertheless one maybe a more or less short and painless approach: Decomission the faulty server, rebuild it from scratch and place it back in the DAG.

 

da wir eine deutschsprachige Microsoft Community sind, wäre es schön, wenn du auf deutsch posten könntest. Trotzdem ein evtl. kurz und schmerzloser Ansatz zur Lösung: Nimm den defekten Server außer Betrieb, installiere ihn neu und integriere ihn wieder in die DAG.

 

HTH

Jan

[BroBias 5]

Hey grüßt euch alle miteinander :)

 

Aye, ich war gestern etwas in Eile, frage sehr selten "extern" nach Unterstützung in beruflichen Belangen und hab deshalb sicher so einiges misachtet ^^

Ich bitte demütigst um Verzeihung - aufrichtig.

Ich bin auch kein "MCSE" bzw. habe mich meistens geweigert zu den Lehrgängen die certs zu machen; halte nichts davon. Ich bin seit rund 20 Jahren im Infrastrukturbereich tätig, mit professionellem Fokus auf Netzwerk/Email-Security/Compliance und produktspezifischen Fokus auf IBM Notes/Domino (nostalgie-tränen kommen hoch ...)  und eben seit etwa 8 Jahren dann auch wieder intensiv mit MSEXCH/M365/IDM/Telefonie

 

Meint ihr ich soll den initialen Post nochmal ins Deutsche übersetzen (ausgenommen die Fehlermeldungen selbst usw., klar), oder genügt das fürs Erste ? Das müsste ich sicher in den Abend schieben.

 

Bis dahin möchte ich kurz auf die bisherigen Vorschläge eingehen und auch noch aktualisieren aus meiner Perspektive:

- Im Prinzip natürlich ein valider Ansatz (Server neu aufsetzen). Ich möchte jedoch zuvor noch einige andere Maßnahmen ergreifen :)

- Nächste Schritte: komplett neue DB ins DAG + Kopie auf betroffenem Server, um zu sehen ob hier die gleichen Mount/Dismount (readfrompassive feature corruption) Events auftreten. Falls ja, würde ich z.B. auch nach Problemen am/"im" Volume/Storage selbst suchen.

--- Server shutdown und db states mit eseutil überprüfen. Soft recovery wenn sinnvoll (dirty shutdown), hard recovery vermeiden. > dann erneut verifizieren.

-----Alle passiven kopien weg, DAG auflösen, Volume auf betroffenem Server neu aufbauen (file allocation size ist eh nicht optimal) > DAG neu aufbauen und Kopien synchronisieren > dann erneut verifizieren.

 

Mir geht es im wesentlichen darum herauszuzfinden was da eigentlich schief läuft. Also nicht "nur" alles wieder zum laufen bringen, sondern auch verstehen, zumindest näherungsweise, was die Probleme verursacht.

 

Herzlichen Dank vorab für euer Mitdenken!

 

Tobias

[testperson 1.673]

vor 43 Minuten schrieb BroBias:

Ich bin auch kein "MCSE"

RAUS!

 

vor 43 Minuten schrieb BroBias:

Mir geht es im wesentlichen darum herauszuzfinden was da eigentlich schief läuft. Also nicht "nur" alles wieder zum laufen bringen, sondern auch verstehen, zumindest näherungsweise, was die Probleme verursacht.

Generell ist das eine super Einstellung und bis an eine gewisse (zeitliche) Grenze würde ich dich da auch voll unterstützen. Ich bin mittlerweile bei vielen Applikationen soweit, dass ich die Server selber als "Wegwerfware" betrachte und im Fehlerfall - je nach Applikation - einfach "in neu" migriere. Und bei Exchange: "Mach neu".

 

[Damian 1.519]

Hi

 

vor 1 Stunde schrieb BroBias:

Meint ihr ich soll den initialen Post nochmal ins Deutsche übersetzen (ausgenommen die Fehlermeldungen selbst usw., klar), oder genügt das fürs Erste ? Das müsste ich sicher in den Abend schieben.

Nein. Wer es braucht, kann den Text ja in ein Übersetzungs-Tool laden. Es soll hier in Board kein wüster Mix aus deutschen und englischen Beiträgen entstehen. Daher der Hinweis. Alles gut.

 

VG

Damian

[BroBias 5]

Hach, ich mag euch schon jetzt ;)
 

1 hour ago, testperson said:

Generell ist das eine super Einstellung und bis an eine gewisse (zeitliche) Grenze würde ich dich da auch voll unterstützen. Ich bin mittlerweile bei vielen Applikationen soweit, dass ich die Server selber als "Wegwerfware" betrachte und im Fehlerfall - je nach Applikation - einfach "in neu" migriere. Und bei Exchange: "Mach neu".

Aye, stimme dir da prinzipiell vollkommen zu. Bin nur was MSEXCH betrifft noch nicht so fit und sattelfest, wie ich das zu meinen Domino-Zeiten quasi noch war.
Deshalb der Anspruch hier tiefer zu graben; ist mein erstes mal mit so nachhaltigen db Problemen auf EXCH.

 

Ein paar kleine Schritte weiter bin ich bereits:

 

- Brandneue DB direkt auf "Problemserver" erstellt und eingehängt: Keine Probleme. Auch eine dorthin migrierte Testmailbox läuft einwandfrei.

- Aktuell läuft ein fresh reseed einer der kleineren existierenden dbs, alle db -und logfiles zuvor gelöscht. Dauert noch ne Weile...

--- Falls diese dann wieder sauber eingehängt bleibt, wäre das der erste Ansatz das Thema langfristig in den Griff zu bekommen. Allerdings dauert das Reseeding ne gefühlte Ewigkeit bei ca. 4 TB Daten :/

- Sobald ich mit dem Step zuvor fertig bin, werd ich die Kiste nochmal komplett in die maintenance schicken und offline nehmen. Alle betroffenen dbs dürften in nem "Dirty Shutdown" state sein, weshalb ich mal ein softrepair drüber laufen lassen will, um zu sehen ob das evtl. bereits hilft.

Halte euch auf dem Laufenden. Alleine meine Gedanken hier reflektieren zu können hilft einfach schon ungemeint. 

[NorbertFe 2.016]

vor 4 Minuten schrieb BroBias:

Aye, stimme dir da prinzipiell vollkommen zu. Bin nur was MSEXCH betrifft noch nicht so fit und sattelfest, wie ich das zu meinen Domino-Zeiten quasi noch war.
Deshalb der Anspruch hier tiefer zu graben; ist mein erstes mal mit so nachhaltigen db Problemen auf EXCH.

Wär ja dann erst recht ein Grund. ;)

[Dukel 451]

vor 52 Minuten schrieb BroBias:

--- Falls diese dann wieder sauber eingehängt bleibt, wäre das der erste Ansatz das Thema langfristig in den Griff zu bekommen. Allerdings dauert das Reseeding ne gefühlte Ewigkeit bei ca. 4 TB Daten :/

 

https://learn.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/storage-configuration?view=exchserver-2019

Du kennst die Empfehlung von 200 GB ohne DAG und 2 TB mit DAG?

 

Zitat

Supported: Approximately 16 terabytes.

Best practice:

• 2 terabytes or less.
• Provision for 120 percent of calculated maximum database size.

 

[NorbertFe 2.016]

Wie kommt man mit 400 Usern 9 Datenbanken auf eine DB Größe von 4TB? Oder ist das die Gesamtmenge über alle DBs?

[testperson 1.673]

  

vor 53 Minuten schrieb BroBias:

wie ich das zu meinen Domino-Zeiten quasi noch war

Puh, du lässt aber auch gar kein "Fettnäpfchen" aus. 

 

 

vor 54 Minuten schrieb BroBias:

Deshalb der Anspruch hier tiefer zu graben; ist mein erstes mal mit so nachhaltigen db Problemen auf EXCH.

Ihr solltet neben eurer Testumgebung auch noch eine produktive Umgebung betreiben.  Das kann man zwar alles so machen, wäre mir aber tatsächlich zu heikel.

[BroBias 5]

Ok, also ganz grundsätzlich: Ich hab die Umgebung vor ca. 1,5 Jahren von einem schon länger abwesenden übernommen. Nebst Einführung Teams Direct Routing, External Mail Security Anbieter ersetzen und vieler++++ anderer offener Baustellen, war da vergleichsweise wenig Zeit mich wirklich angemessen um die EXCH Umgebung zu kümmern ^^

 

Ich kenne die Empfehlungen hinsichtlich DB-sizes, ja. Alle Server sind bereits Enterprise-lizensiert (waren sie anfangs nicht), aber ich bemühe mich aktuell die db sizes wieder um die 2-400B zu bekommen; warum? -> server laufen auf vm infra, storage (disks) sind nicht vernünftig konfiguriert und die volumes auch 0 an EXCH best practices angelehnt. U.a. führt das dazu, dass die db maintenance auf keiner db jemals abgeschlossen wird. Das bekomme ich in den Griff, wenn die dbs so um die 200 - 400 GB sind, dann läuft die maintenance sauber durch.

Die ganze Umgebung sukzessive auf neue, und dann sauber konfigurierte, Hardware zu migrieren ist in Planung, aber wird halt noch bis 2024 dauern bis ich damit loslegen kann; bis dahin muss ich improvisieren. Zu den Zahlen:

Prinzipiell sind rund 550 mbx (user/shared) auf 4 dbs verteilt, wobei eine db rund 1++ TB groß war; insgesamt sprechen wir von ca. 5,7TB mbx-daten. Ich habe hier jedoch bereits begonnen eine der dbs zu splitten, weshalb sie aktuell nun auf 8 dbs verteilt sind. Das sollen noch mehr werden. Mindestens 2 weitere dbs hatte ich vor zu splitten, um die Größe pro db zu reduzieren.
Was habt ihr denn da so für Erfahrungen aber welcher Anzahl dbs dieses "Verhältnis" zu ESE evtl. wieder kippt ? ^^

 

Zum vorliegenden Problem: Selbst ein vollständiges Löschen einer passiven Kopie im DAG, sicherstellen, dass auch das dazugehörige AD-Objekt weg ist, und anschließende Neuerstellung der db copy auf dem passive node, manuelles seeding .... keine Chance. Sobald diese db copy gemountet werden soll, beginnt wieder eingangs beschriebenes Fehlverhalten. Das leuchtet mir echt nicht ein (weil neue copy) und macht auch wenig Hoffnung, dass eseutil hier noch Abhilfe schaffen kann.

Auch die Volume/Folder/File Berechtigungen für die neu erstellte Kopie entsprechend nun wieder exakt den Berechtigungen wie auch auf dem "main server"; keine Verbesserung ... 

Das ist echt seltsam. Was kann dazu führen, dass selbst eine neu gezogene Kopie von einer intakten db auf nem intakten Server im Anschluss in die gleichen Fehler reinläuft wie zuvor ? Da muss doch irgendwas im Argen sein, dass mit der db gar nichts zu tun hat .... ?

[Sunny61 806]

vor 33 Minuten schrieb testperson:

Puh, du lässt aber auch gar kein "Fettnäpfchen" aus. 

Domino Server war nicht das Schlechteste auf der Welt. ;)

[BroBias 5]

7 minutes ago, Sunny61 said:

Domino Server war nicht das Schlechteste auf der Welt. ;)

Aye, weine ihnen sehr vieles nach und bin da auch grundsätzlich und immer bereit für ne Diskussion  
Wollte allerdings das Faß in diesem Thread hier jetzt nicht noch weiter aufmachen xDD

Ok, nächstes Update: Es wird immer spannender

 

Im vorherigen Post hab ich ja noch mit einer neuen kopie einer existierenden DB gearbeitet ... jetzt mal mit was frischem:

 

(1) Ich erstelle eine komplett neue, leere DB auf dem Problemserver (!) , migriere eine test-mbx rein, lege ne aktive kopie auf einen der anderen server..... mit dieser db kann ich problemlos switchover machen auf den anderen server und wieder zurück: 0 Probleme.

(2) Ich erstelle eine komplett neue, leere DB auf dem main server (auf dem aktuell alle CAS Anfragen landen, generell der "main server", bisher stabil und ohne auffälligkeiten hinsichtlich dbs etc.). Dann lege ich eine neue aktive Kopie auf den Problemserver, manuelles seeding .... , keine mbx in dieser db  ----> sobald ich diese passive kopie auf dem problem server mounten will geht das gleiche Fehlverhalten wieder los.

Was macht denn das nun für einen Sinn ? 

[Dukel 451]

Was ist dein Ziel?

 

Willst du die Ursache herausfinden / verstehen? Zieh de Microsoft Support hinzu oder einen Dienstleister.

 

Willst du Funktionierende Server / DB's haben? Erstelle (einen) neue(n) Server & Datenbanken und verschiebe die Postfächer dort hinein und entferne den kaputten oder alle bisherigen Server.

 

Btw. du musst nicht auf mehrere 100 GB herunter. 2 TB Datenbanken sind auch kein Problem. Hier hast du evtl. ein anderes Thema.

Ich hab bei einem Kunden eine Umgebung mit 24x 2 TB Datenbanken in einer DAG und es gibt keine solchen Probleme.

bearbeitet 20. Juli 2023 von Dukel