Exchange Server-Administratoren fuerchten den Moment, wenn ihr Ueberwachungs-Dashboard mit Microsoft.Exchange.Data.Storage.TooManyObjectsOpenedException-Fehlern aufleuchtet, waehrend der Speicherverbrauch von Store.exe ueber akzeptable Schwellenwerte steigt. Dieser Fehler zeigt an, dass ein oder mehrere Prozesse die maximale Anzahl gleichzeitig geoeffneter MAPI-Objekte auf Ihrem Exchange 2013-, 2016- oder 2019-Server ueberschritten haben. In diesem Artikel erfahren Sie genau, was diese Ausnahme ausloest, wie Sie die Ursache mit PowerShell und Performance Monitor diagnostizieren und wie Sie sie systematisch beheben, bevor sie Ihre gesamte Messaging-Umgebung beeintraechtigt.

Voraussetzungen

  • Exchange Server 2013, 2016 oder 2019 mit dem neuesten kumulativen Update installiert
  • Exchange Management Shell-Zugang mit der Rolle Organization Management oder Server Management
  • Lokaler Administratorzugriff auf den Exchange Server
  • Zugang zu Performance Monitor (perfmon.exe)
  • Vertrautheit mit PowerShell und Exchange-Cmdlets
  • Zugang zur Ereignisanzeige fuer Anwendungs- und Systemprotokolle
  • Verstaendnis der MAPI-Protokollgrundlagen

TooManyObjectsOpenedException verstehen

Die TooManyObjectsOpenedException wird vom Exchange Information Store (Store.exe) ausgeloest, wenn eine Client-Sitzung oder ein Hintergrundprozess mehr MAPI-Objekte oeffnet, als der konfigurierte Schwellenwert erlaubt. MAPI-Objekte umfassen Nachrichten, Ordner, Anhaenge, Tabellenansichten und Benachrichtigungsabonnements. Jedes Mal, wenn Outlook einen Ordner oeffnet, eine Konversation erweitert oder ein Backup-Agent Postfachinhalte auflistet, werden MAPI-Objekte erstellt, die Speicher innerhalb des Store.exe-Prozesses verbrauchen.

Exchange setzt diese Limits durch Drosselungsrichtlinien zum Schutz der Serverstabilitaet durch. Wenn eine einzelne Sitzung oder ein Postfach sein zugewiesenes Objektkontingent ueberschreitet, erzeugt der Information Store die Event ID 9646 im Anwendungsprotokoll und lehnt weitere Objektanfragen von dieser Sitzung ab. Das unmittelbar sichtbare Symptom ist, dass betroffene Outlook-Clients Haenger, Verbindungsabbrueche oder “Ordner kann nicht erweitert werden”-Fehler erleben, waehrend serverseitig der Speicher von Store.exe unkontrolliert waechst.

Die kritische Unterscheidung liegt hier zwischen Limits pro Sitzung und Limits pro Postfach. Ein einzelner Benutzer, der Outlook mit zehn Add-Ins ausfuehrt, kann zehn separate Sitzungen haben, die jeweils Objekte verbrauchen. Das Limit pro Sitzung wird moeglicherweise nicht erreicht, aber das aggregierte Limit pro Postfach kann dennoch ueberschritten werden.

Wie MAPI-Objektlimits funktionieren

Exchange verfolgt offene Objekte ueber das interne Ressourcen-Tracking des Information Store. Jeder Objekttyp hat seinen eigenen Zaehler:

  • Offene Nachrichten: Anzahl gleichzeitig geoeffneter Nachrichtenobjekte
  • Offene Ordner: Anzahl der im Speicher gehaltenen Ordnerobjekte
  • Offene Anhaenge: Aktuell zugegriffene Anhangsstroeme
  • Benachrichtigungsabonnements: Push-Benachrichtigungsregistrierungen von Clients

Wenn ein Zaehler sein konfiguriertes Maximum ueberschreitet, loest der Store die Ausnahme aus und protokolliert sie als Event ID 9646 mit Details darueber, welcher Benutzer und welcher Objekttyp das Limit ausgeloest hat.

Das Problem diagnostizieren

Schritt 1: Den Fehler in den Ereignisprotokollen bestaetigen

Oeffnen Sie die Ereignisanzeige und navigieren Sie zu Windows-Protokolle > Anwendung. Filtern Sie nach Event ID 9646 mit der Quelle MSExchangeIS. Das Ereignisdetail zeigt den betroffenen Benutzer, den Objekttyp, der das Limit ueberschritten hat, und den aktuellen Zaehlerstand im Vergleich zum Maximum:

Event ID: 9646
Source: MSExchangeIS
Description: Mapi session "/o=Organization/ou=Exchange Administrative Group/cn=Recipients/cn=jsmith"
exceeded the maximum of 500 objects of type "objtMessage".

Dies zeigt Ihnen sofort, welches Postfach problematisch ist und welcher Objekttyp erschoepft wird.

Schritt 2: Get-StoreUsageStatistics verwenden

Das Cmdlet Get-StoreUsageStatistics ist Ihr primaeres Diagnosewerkzeug. Fuehren Sie es gegen die betroffene Postfachdatenbank aus:

Get-StoreUsageStatistics -Database "Mailbox Database 01" |
    Sort-Object -Property DigestCategory -Descending |
    Format-Table DisplayName, DigestCategory, SampleCount, SampleValue -AutoSize

Dies gibt Ressourcenverbrauchsdaten fuer alle aktiven Postfachsitzungen zurueck. Suchen Sie nach Postfaechern mit ungewoehnlich hohen SampleValue-Werten, die auf uebermassig viele offene Objekte hinweisen.

Um ein bestimmtes Postfach zu untersuchen:

Get-StoreUsageStatistics -Identity "[email protected]" |
    Format-List *

Schritt 3: Postfachstatistiken pruefen

Verwenden Sie Get-MailboxStatistics, um Postfaecher mit ungewoehnlich hohen Elementzahlen zu identifizieren, die zum Problem beitragen koennten:

Get-MailboxStatistics -Database "Mailbox Database 01" |
    Sort-Object -Property ItemCount -Descending |
    Select-Object DisplayName, ItemCount, TotalItemSize, LastLogonTime -First 20

Postfaecher mit Hunderttausenden von Elementen in einem einzigen Ordner sind Hauptkandidaten fuer das Ausloesen von Objektlimit-Ausnahmen, insbesondere wenn Clients versuchen, den gesamten Ordner zu synchronisieren.

Schritt 4: Performance Monitor-Zaehler

Fuegen Sie die folgenden Zaehler in Performance Monitor hinzu, um den MAPI-Objektverbrauch in Echtzeit zu verfolgen:

  • MSExchangeIS Store\Active Client Logons — Gesamtzahl aktiver Sitzungen
  • MSExchangeIS Store\Client: RPCs attempted/sec — Anfragerate
  • MSExchangeIS Store\Messages Opened/sec — Objekterstellungsrate
  • MSExchangeIS\RPC Requests — gleichzeitige RPC-Operationen
  • Process(Store)\Working Set — Speicherverbrauch von Store.exe

Erstellen Sie einen Datensammler-Satz und fuehren Sie ihn mindestens vier Stunden lang aus, um Spitzenauslastungsmuster zu erfassen. Korrelieren Sie Spitzen bei offenen Nachrichtenzaehlungen mit den Zeitstempeln der Event ID 9646-Eintraege.

Haeufige Ursachen

Fehlerhafte Outlook-Add-Ins

Outlook-Add-Ins von Drittanbietern sind der haeufigste Verursacher. Add-Ins, die Hintergrundindizierung, Social-Media-Integration oder CRM-Synchronisierung durchfuehren, oeffnen oft Hunderte von MAPI-Objekten pro Ordner und geben sie nicht ordnungsgemaess frei. Ein einzelner Benutzer mit einem schlecht programmierten Add-In kann das Objektlimit pro Sitzung innerhalb von Minuten erschoepfen.

Um das fehlerhafte Add-In zu identifizieren, pruefen Sie die RPC-Client-Informationen:

Get-RpcClientAccess -Server EX01 | Format-List

Korrelieren Sie dann den Namen der Client-Anwendung in den Details der Event ID 9646. Haeufige Verursacher sind veraltete Versionen von Salesforce fuer Outlook, Thomson Reuters-Add-Ins und Antivirus-E-Mail-Scanner.

Backup- und Archivierungssoftware von Drittanbietern

Backup-Agenten wie Veeam Explorer for Exchange, Veritas Backup Exec oder Commvault verwenden haeufig MAPI oder EWS, um Postfachinhalte waehrend der Sicherungsfenster aufzulisten und zu lesen. Wenn die Backup-Software fuer die Wiederherstellung auf Elementebene konfiguriert ist, kann sie jede Nachricht in einer Datenbank gleichzeitig oeffnen und dabei leicht die Objektlimits ueberschreiten.

Pruefen Sie die Zeitplaene der Backup-Auftraege und stellen Sie fest, ob die TooManyObjectsOpenedException-Ereignisse mit den Sicherungsfenstern korrelieren. Ueberpruefen Sie die Konfiguration der Backup-Software auf Optionen zur Drosselung von MAPI-Verbindungen oder zur Verwendung von VSS-Snapshots.

Probleme mit dem Exchange-Suchindexer

Der Microsoft Exchange Search Host Controller (HostControllerService) und der Inhaltsindizierungsprozess koennen fehlfunktionieren und wiederholt versuchen, dieselben Elemente zu indizieren, wobei uebermassig viele Objekte offen gehalten werden. Pruefen Sie den Zustand des Suchindex:

Get-MailboxDatabaseCopyStatus * |
    Select-Object Name, Status, ContentIndexState, ContentIndexErrorMessage

Wenn ContentIndexState ueber laengere Zeitraeume Failed oder Crawling anzeigt, traegt der Indexer moeglicherweise zur Objekterschoepfung bei. Erstellen Sie den Index bei Bedarf neu:

Stop-Service MSExchangeFastSearch
Stop-Service HostControllerService

# Indexkatalogordner fuer die betroffene Datenbank loeschen
Remove-Item "D:\ExchangeDatabases\DB01\DB01.Single" -Recurse -Force

Start-Service MSExchangeFastSearch
Start-Service HostControllerService

Replikationsprobleme oeffentlicher Ordner

In Umgebungen mit Postfaechern fuer oeffentliche Ordner kann die Hierarchiesynchronisierung der Replikation eine uebermassige Objekterstellung verursachen. Jeder oeffentliche Ordner in der Hierarchie erfordert waehrend der Synchronisierung offene Objekte. Organisationen mit Tausenden von oeffentlichen Ordnern koennen waehrend der Replikationszyklen leicht die Limits ueberschreiten.

Pruefen Sie den Replikationszustand der oeffentlichen Ordner:

Get-PublicFolderMailboxDiagnostics -Identity "PF_Mailbox01" |
    Select-Object -ExpandProperty SyncInfo

Datenbankkorruption

Zugrunde liegende ESE-Datenbankkorruption kann dazu fuehren, dass der Information Store wiederholt versucht, auf beschaedigte Seiten zuzugreifen, wobei MAPI-Objekte erstellt und aufgegeben werden. Wenn andere Ursachen ausgeschlossen wurden, fuehren Sie eine Integritaetspruefung durch:

# Datenbank zuerst dismounten
Dismount-Database "Mailbox Database 01" -Confirm:$false

# eseutil fuer Integritaetspruefung ausfuehren
eseutil /g "D:\ExchangeDatabases\DB01\DB01.edb"

# Bei gefundenen Problemen Reparatur ausfuehren
eseutil /p "D:\ExchangeDatabases\DB01\DB01.edb"

# Defragmentieren zur Speicherrueckgewinnung
eseutil /d "D:\ExchangeDatabases\DB01\DB01.edb"

# Wieder mounten
Mount-Database "Mailbox Database 01"

Vergleich der Objektlimits nach Exchange-Version

ParameterExchange 2013Exchange 2016Exchange 2019
Max Objekte pro Sitzung (objtMessage)500500500
Max offene Ordner pro Sitzung500500500
Max Objekte pro Postfach (gesamt)16.00016.00016.000
Max gleichzeitige RPC-Verbindungen404040
Standard-RPC-Timeout (Sekunden)120120120
Max Speicher von Store.exe (% RAM)Dynamisch (bis zu 75%)Dynamisch (bis zu 75%)Dynamisch (bis zu 75%)
Drosselungsrichtlinie konfigurierbarJa (New-ThrottlingPolicy)Ja (New-ThrottlingPolicy)Ja (New-ThrottlingPolicy)
ESE-Cache-Groesse konfigurierbarJa (Registrierung)Ja (Registrierung)Ja (Registrierung)

Beachten Sie, dass die Standardlimits zwar ueber alle Versionen hinweg identisch sind, Exchange 2016 und 2019 jedoch ueber verbesserte Speicherverwaltungsalgorithmen verfuegen, die die Objektbereinigung aggressiver als Exchange 2013 handhaben.

Schrittweise Loesung

1. Die unmittelbare Ursache identifizieren

Ueberpruefen Sie die letzten 24 Stunden der Event ID 9646-Eintraege und erstellen Sie eine Liste der betroffenen Postfaecher und Client-Anwendungen:

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    ProviderName = 'MSExchangeIS'
    ID = 9646
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Export-Csv C:\temp\9646events.csv

2. Objektlimits erhoehen (voruebergehende Entlastung)

Wenn die Auswirkungen auf die Produktion schwerwiegend sind, erhoehen Sie voruebergehend das Objektlimit pro Sitzung ueber die Registrierung:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value: Maximum Allowed Sessions Per User
Type: REG_DWORD
Data: 32 (Standard ist 16, auf 32 oder 64 erhoehen)

Fuer Limits pro Objekttyp erstellen Sie eine benutzerdefinierte Drosselungsrichtlinie:

New-ThrottlingPolicy -Name "HighObjectLimit" -RCAMaxConcurrency 40 -RCAPercentTimeInAD 100
Set-Mailbox -Identity "jsmith" -ThrottlingPolicy "HighObjectLimit"

Starten Sie den Microsoft Exchange Information Store-Dienst nach Registrierungsaenderungen neu.

3. Die Grundursache beheben

Basierend auf Ihrer Diagnose aus den vorherigen Abschnitten:

  • Outlook-Add-Ins: Deaktivieren Sie das fehlerhafte Add-In ueber Gruppenrichtlinien oder die Office COM-Add-In-Registrierungsschluessel. Testen Sie mit Outlook im abgesicherten Modus (outlook.exe /safe).
  • Backup-Software: Konfigurieren Sie die Verwendung von VSS-basierten Snapshots anstelle der MAPI-Enumeration. Planen Sie Backups ausserhalb der Spitzenzeiten.
  • Suchindexer: Erstellen Sie den Inhaltsindexkatalog fuer die betroffene Datenbank neu.
  • Oeffentliche Ordner: Reduzieren Sie die Hierarchiegroesse, teilen Sie grosse Postfaecher fuer oeffentliche Ordner auf oder passen Sie den Replikationszeitplan an.
  • Datenbankkorruption: Fuehren Sie eseutil /d fuer eine Offline-Defragmentierung aus, um Datenbankinkonistenzen zu bereinigen.

4. Praeventive Ueberwachung implementieren

Erstellen Sie eine Ueberwachungsregel fuer Event ID 9646 in Ihrem Ueberwachungssystem (SCOM, Zabbix oder aehnlich) und richten Sie eine geplante PowerShell-Aufgabe ein, um Objektzaehlungen zu verfolgen:

$results = Get-StoreUsageStatistics -Database "Mailbox Database 01" |
    Where-Object { $_.SampleValue -gt 400 }
if ($results) {
    Send-MailMessage -To "[email protected]" -Subject "MAPI-Objekt-Warnung" `
        -Body ($results | Out-String) -SmtpServer "smtp.contoso.com"
}

Praxisbeispiel

Ihr Exchange 2016-Server beginnt an einem Montagmorgen alle paar Minuten Event ID 9646 zu protokollieren. Der Speicher von Store.exe ist von den ueblichen 24 GB auf 38 GB bei einem Server mit 48 GB gestiegen. Benutzer melden Outlook-Verbindungsabbrueche und langsames Laden von Ordnern.

Sie fuehren Get-StoreUsageStatistics aus und stellen fest, dass fuenf Postfaecher des Vertriebsteams erhoehte Objektzaehlungen aufweisen. Bei der Ueberpruefung der Ereignisdetails sehen Sie, dass die Client-Anwendung als “Client=MSExchangeRPC” identifiziert wird, mit einem zusaetzlichen Tag, der auf ein CRM-Add-In eines Drittanbieters verweist.

Weitere Untersuchungen ergeben, dass das IT-Team am Wochenende eine neue Version des Dynamics 365-Add-Ins fuer Outlook bereitgestellt hat. Diese Version hat einen bekannten Fehler, bei dem sie Nachrichtenobjekte fuer jeden Kontaktdatensatz oeffnet, aber nie schliesst. Innerhalb weniger Stunden akkumuliert jede Sitzung der Vertriebsmitarbeiter ueber 450 offene Nachrichtenobjekte und naehert sich dem Limit von 500.

Die Loesung umfasst drei Schritte: Erstens erhoehen Sie voruebergehend das Limit pro Sitzung auf 1.000 ueber die Registrierung, um die unmittelbare Blutung zu stoppen. Zweitens setzen Sie das CRM-Add-In ueber Gruppenrichtlinien auf die vorherige Version zurueck. Drittens starten Sie den Information Store-Dienst waehrend der Mittagspause neu, um die angesammelten Objekte zu bereinigen. In den naechsten 24 Stunden kehrt der Speicher von Store.exe auf seine normale Baseline von 24 GB zurueck und es treten keine weiteren 9646-Ereignisse auf.

Stolperfallen und Sonderfaelle

Database Availability Group (DAG)-Umgebungen: In einem DAG repliziert sich TooManyObjectsOpenedException auf einem Knoten nicht automatisch auf passive Kopien. Wenn die Grundursache jedoch ein Problem auf Postfachebene ist (wie ein beschaedigtes Element), folgt das Problem dem Postfach beim Datenbank-Failover. Ueberpruefen Sie immer sowohl aktive als auch passive Knoten.

Koexistenz mit Exchange 2013 und 2016: Waehrend der Migrationskoexistenz koennen Proxy-Sitzungen zwischen Servern die MAPI-Objektzaehlungen vervielfachen. Eine einzelne Outlook-Sitzung zu einem 2013-Postfach, die ueber einen 2016-Server proxied wird, erstellt Objekte auf beiden Servern. Ueberwachen Sie beide Server waehrend der Koexistenz.

Cache-Modus versus Online-Modus: Outlook im Exchange-Cache-Modus oeffnet weniger gleichzeitige Objekte als der Online-Modus, da es inkrementell synchronisiert. Die anfaengliche Synchronisierung eines Cache-Modus-Profils fuer ein grosses Postfach (100.000+ Elemente) kann jedoch voruebergehend die Objektzaehlungen ueber die Schwellenwerte erhoehen.

Gemeinsame Postfaecher mit vielen Stellvertretern: Ein gemeinsames Postfach, das von 20 Benutzern gleichzeitig geoeffnet wird, erstellt 20 separate Sitzungen, jede mit ihrer eigenen Objektzuweisung. Das aggregierte Limit pro Postfach kann schnell erreicht werden, auch wenn keine einzelne Sitzung missbreauchlich ist.

Exchange-Hybrid mit Office 365: Hybride Frei/Belegt-Abfragen und standortuebergreifende Postfachverschiebungen erstellen temporaere MAPI-Sitzungen, die Objekte verbrauchen. Waehrend grosser Batch-Migrationen kann der lokale Server Objektdruck vom Migrationsendpunkt erfahren.

Fehlerbehebung

Ereignisprotokollabfrage fuer verwandte Fehler

Suchen Sie nach verwandten Ereignissen, die TooManyObjectsOpenedException haeufig begleiten:

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    ProviderName = 'MSExchangeIS'
    ID = 9646, 9660, 9667, 9760
    StartTime = (Get-Date).AddDays(-7)
} | Group-Object Id | Select-Object Name, Count | Sort-Object Count -Descending
  • Event ID 9660: Die Sitzung hat das Maximum an Objekten vom Typ objtFolder ueberschritten
  • Event ID 9667: RPC-Verbindungslimit ueberschritten
  • Event ID 9760: MAPI-Sitzung wegen Ressourcenerschoepfung getrennt

ESE-Leistungszaehler

Ueberwachen Sie diese Zaehler, um Probleme auf Datenbankebene zu erkennen, die zum hohen Speicherverbrauch beitragen:

  • Database\Database Cache % Hit — sollte ueber 99% liegen. Unter 95% deutet auf ungenuegenden Speicher oder Cache-Thrashing hin
  • Database\Database Page Evictions/sec — hohe Werte bedeuten, dass der Cache voll ist und aktiv Seiten verwirft
  • Database\Log Record Stalls/sec — deutet auf Schreibkonflikte hin, die zu Objektretention fuehren koennen

Store.exe-Speicher sinkt nach der Behebung nicht

Wenn der Speicher von Store.exe nach der Behebung der Grundursache erhoeht bleibt, benoetigt der ESE-Cache moeglicherweise manuelle Intervention. Starten Sie den Microsoft Exchange Information Store-Dienst waehrend eines Wartungsfensters neu:

Restart-Service MSExchangeIS -Force

In DAG-Umgebungen fuehren Sie zuerst eine kontrollierte Datenbank-Umschaltung durch:

Move-ActiveMailboxDatabase "Mailbox Database 01" -ActivateOnServer EX02 -Confirm:$false

Starten Sie dann den Information Store auf dem urspruenglichen aktiven Server neu. Dies stellt sicher, dass es keine Ausfallzeit fuer die Benutzer gibt.

Zusammenfassung

  • TooManyObjectsOpenedException tritt auf, wenn MAPI-Objektlimits ueberschritten werden, was zu Speicherwachstum von Store.exe und Client-Verbindungsabbruechen fuehrt
  • Event ID 9646 im Anwendungsprotokoll identifiziert das betroffene Postfach und den Objekttyp, der das Limit erreicht hat
  • Get-StoreUsageStatistics ist das primaere PowerShell-Cmdlet zur Diagnose, welche Postfaecher uebermassige Ressourcen verbrauchen
  • Die fuenf haeufigsten Ursachen sind fehlerhafte Outlook-Add-Ins, Backup-Software, Suchindexer-Ausfaelle, Replikationsprobleme oeffentlicher Ordner und Datenbankkorruption
  • Voruebergehende Entlastung durch Erhoehung der Sitzungslimits ueber die Registrierung, aber beheben Sie immer die Grundursache
  • eseutil /d zur Offline-Defragmentierung behebt Korruption auf Datenbankebene, die zu Objektlecks beitraegt
  • Ueberwachen Sie proaktiv die Event IDs 9646, 9660, 9667 und 9760, um Probleme zu erkennen, bevor sie Benutzer beeintraechtigen
  • In DAG-Umgebungen fuehren Sie immer kontrollierte Umschaltungen durch, bevor Sie den Information Store neu starten

Verwandte Artikel