Exchange 2016: STOREDRV; mailbox server is offline (ID 4009)

Die folgende Mail hat mich vor ein paar Tagen erreicht und ich denke die Lösung könnte auch anderen weiterhelfen. Es handelt sich um einen einzelnen Exchange 2016 Server auf Windows Server 2012 R2. Hier einmal ein Auszug des Problems aus der Mail:

Nun bin ich aber am Ende meines Lateins und wollte mich erkundigen ob du eventuell einen solchen Fehler in deinen Exchange Installationen auch schon einmal hattest.. Mein Exchange Server «stirbt» fast Täglich mit folgenden Effekten:

• Mails werden nicht mehr zugestellt und ich erhalte eine Fehlermeldung in der Queue Übersicht (siehe PrintScreen im Anhang)
• Vereinzelte Benutzer können sich nicht mehr mit dem Exchange Server verbinden (in der Verbindungsübersicht zählt er die Verbindungsversuche endlos hoch – es kommt aber keine Verbindung mehr zustande).

Derzeit umgehe ich das mit einem Reboot des Information Store und des RPC Client Access Dienstes. Das läuft dann wieder ein paar Stunden und schon habe ich denselben Fehler wieder.

Ein kleiner Screenshot war auch angehangen:

Hier einmal der Text der Meldung:

432 4.3.2 STOREDRV; mailbox server is offline; STOREDRV.Deliver.Exception:ConnectionFailedTransientException.MapiExceptionNetworkError; Failed to process message due to a transient exception with message Underlying MAPI stream threw exception

Ich hatte bereits eine Vermutung wo das Problem liegt und daraufhin das Eventlog angefordert. Netterweise wurde mir das Eventlog zur Verfügung gestellt und auch ein Zeitpunkt genannt, wann das Problem zu Letzt aufgetreten ist.

Im Anwendungsprotokoll wurde der folgende Fehler protokolliert:

Quelle: MSExchange Availability

ID:: 4009

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: Unable to open connection for mailbox MAILBOX SMTP:EMAIL-Adresse. Exception returned is: Microsoft.Exchange.Data.Storage.StorageTransientException: The process failed to get the correct properties. —> Microsoft.Mapi.MapiExceptionRpcServerTooBusy: MapiExceptionRpcServerTooBusy: Unable to get properties on object. (hr=0x80004005, ec=2419)

Hiermit war dann auch die Ursache klar:

Der Server hat also viel zu tun. Um zu vermeiden das einzelne Benutzer zu viele Systemressourcen auf dem Server verbrauchen und damit andere Benutzer und/oder das System ausbremsen, gibt es Throttling Policies. Throttling Policies begrenzen die Ressourcen die ein einzelner Benutzer in Anspruch nehmen kann.

Ich stellte dann sicherheitshalber noch eine Rückfrage:

Haben bei euch viele Benutzer mehrere Postfächer geöffnet? Wie viele Postfächer sind in einer Datenbank?

Die Antwort auf meine Frage:

Anzahl Postfächer würde ich auf ca. 450 tippen und ja, die meisten meiner User (habe ca 80-100 concurrent user) haben mehrere (bis zu 20) Postfächer offen.

In diesem Fall waren alle Postfächer in einer Datenbank gespeichert.

Dem Problem auf der Spur

Ich habe empfohlen eine weitere Datenbank anzulegen und 50% der Postfächer in die neue Datenbank zu verschieben. Hier sollte ein ausgewogenes Verhältnis herrschen um die Last möglichst gleichmäßig zu verteilen. Daher sollten nicht alle Power User in eine neuen Datenbank verschoben werden, sondern nur die Hälfte, der Rest kann dann mit weniger aktiven Postfächern aufgefüllt werden. So lässt sich meist ein recht ausgeglichenes Verhältnis von Datenbankgröße und Last herstellen. Ein Exchange Server 2016 Standard Edition kann maximal 5 gemountete Datenbanken pro Server verwalten (Enterprise Edition: 100 gemountete Datenbanken pro Server).

Durch die Nutzung mehrerer Datenbanken lässt sich die Last also besser verteilen. Auch im Hinblick auf Backup und Restore machen mehrere Datenbanken Sinn, beim Backup kann je Datenbank ein Stream geöffnet werden (wenn entsprechende Software eingesetzt wird) und dadurch der Durchsatz des Backups erhöht werden. Auch die Restore Zeiten können sich verbessern, anstatt im Fehlerfall eine große Datenbank aus dem Backup wiederherzustellen, reicht es ggf. aus eine von mehreren kleineren Datenbanken wiederherzustellen.

Zurück zu den Throttling Policies:

In der Standardeinstellung gibt es für alle Exchange 2016 Server eine globale Throttling Policy. In dieser Policy wird unter anderem die Anzahl gleichzeitiger Verbindungen je Benutzer/Client/Protokoll definiert. Für den aktuellen Fall ist besonders ein Wert wichtig: RCAMaxConcurreny

The RcaMaxConcurrency parameter specifies how many concurrent connections an RPC Client Access user can have against an Exchange server at one time. A connection is held from the moment a request is received until the connection is closed or the connection is otherwise disconnected (for example, if the user goes offline). If users attempt to make more concurrent requests than their policy allows, the new connection attempt fails. However, the existing connections remain valid.

Quelle: https://docs.microsoft.com/en-us/powershell/module/exchange/server-health-and-performance/set-throttlingpolicy?view=exchange-ps

RCAMaxConcurreny legt also den Wert gleichzeitiger Verbindungen je Client fest. In der Standardeinstellungen sind es 40:

Get-ThrottlingPolicy | ft name,RcaMaxConcurrency

In dem vorliegenden Fall haben manche Benutzer allerdings bis zu 20 Postfächer geöffnet. Hier mal ein Screenshot für meinen Benutzer der 2 Postfächer geöffnet hat:

Hier sieht man 5 Verbindungen, 3 für das primäre Postfach (mein Eigenes) und 2 für das zusätzliche Postfach. Hochgerechnet auf 20 Postfächer ergibt sich folgendes:

3 Verbindungen für das eigene Postfach und 20 x 2 Verbindungen für die zusätzlichen Postfächer. In Summe 43 Verbindungen. Die Policy lässt allerdings zur 40 gleichzeitige Verbindungen zu.

Scheinbar bezieht sich der Wert RCAMaxConcurreny der Throttling Policy allerdings auch auf die Datenbank, denn alle Verbindungen können aufgebaut werden, wenn 10 der Postfächer in DB1 und die weiteren 10 Postfächer in DB2 gespeichert werden. Somit würden in Summe nur 23 Verbindungen gegen DB1 (Eigenes Postfach + 10 weitere Postfächer) und 20 Verbindungen gegen DB2 (10 weitere Postfächer) laufen.

Dies konnte ich bisher aber nicht abschließend verifizieren.

Die Lösung des Problems

Letztendlich wurden zwei Maßnahmen umgesetzt, die das Problem behoben haben:

Es wurde eine zusätzliche Datenbank angelegt und die Postfächer möglichst gleichmäßig anhand von Postfachgröße und Aktivität der Benutzer verteilt.

Es wurde eine zusätzliche Throttling Policy erstellt und der Wert für den Parameter RCAMaxConcurreny angehoben:

New-ThrottlingPolicy -Name FrankysWebPolicy -ThrottlingPolicyScope Organization -RcaMaxConcurrency 80

Bisher ist das Problem nicht wieder aufgetreten.