Les administrateurs Exchange Server redoutent le moment ou leur tableau de bord de surveillance s’illumine avec des erreurs Microsoft.Exchange.Data.Storage.TooManyObjectsOpenedException tandis que la consommation memoire de Store.exe grimpe au-dela des seuils acceptables. Cette erreur indique qu’un ou plusieurs processus ont depasse le nombre maximum d’objets MAPI ouverts simultanement sur votre serveur Exchange 2013, 2016 ou 2019. Dans cet article, vous apprendrez exactement ce qui declenche cette exception, comment diagnostiquer la cause racine avec PowerShell et Performance Monitor, et comment la resoudre systematiquement avant qu’elle n’impacte l’ensemble de votre environnement de messagerie.
Prerequisites
- Exchange Server 2013, 2016 ou 2019 avec la derniere mise a jour cumulative installee
- Acces a l’Exchange Management Shell avec le role Organization Management ou Server Management
- Acces administrateur local au serveur Exchange
- Acces a Performance Monitor (perfmon.exe)
- Familiarite avec PowerShell et les cmdlets Exchange
- Acces a l’Observateur d’evenements pour les journaux Application et Systeme
- Comprehension des bases du protocole MAPI
Comprendre TooManyObjectsOpenedException
L’exception TooManyObjectsOpenedException est levee par l’Exchange Information Store (Store.exe) lorsqu’une session client ou un processus d’arriere-plan ouvre plus d’objets MAPI que le seuil configure ne le permet. Les objets MAPI incluent les messages, dossiers, pieces jointes, vues de tableau et abonnements aux notifications. Chaque fois qu’Outlook ouvre un dossier, developpe une conversation, ou qu’un agent de sauvegarde enumere le contenu d’une boite aux lettres, il cree des objets MAPI qui consomment de la memoire au sein du processus Store.exe.
Exchange applique ces limites via des strategies de limitation pour proteger la stabilite du serveur. Lorsqu’une session ou une boite aux lettres unique depasse son quota d’objets alloue, l’Information Store genere l’Event ID 9646 dans le journal Application et rejette les requetes d’objets supplementaires de cette session. Le symptome visible immediat est que les clients Outlook affectes subissent des blocages, des deconnexions ou des erreurs “Impossible de developper le dossier”, tandis que cote serveur, vous observez la memoire de Store.exe croitre sans controle.
La distinction critique ici se situe entre les limites par session et les limites par boite aux lettres. Un seul utilisateur executant Outlook avec dix complements peut avoir dix sessions separees, chacune consommant des objets. La limite par session peut ne pas etre atteinte, mais la limite agregee par boite aux lettres peut tout de meme etre depassee.
Comment fonctionnent les limites d’objets MAPI
Exchange suit les objets ouverts grace au suivi interne des ressources de l’Information Store. Chaque type d’objet possede son propre compteur :
- Messages ouverts : Nombre d’objets message ouverts simultanement
- Dossiers ouverts : Nombre d’objets dossier conserves en memoire
- Pieces jointes ouvertes : Flux de pieces jointes actuellement accedes
- Abonnements de notification : Enregistrements de notifications push des clients
Lorsqu’un compteur depasse son maximum configure, le store leve l’exception et l’enregistre en tant qu’Event ID 9646 avec des details sur l’utilisateur et le type d’objet ayant declenche la limite.
Diagnostiquer le probleme
Etape 1 : Confirmer l’erreur dans les journaux d’evenements
Ouvrez l’Observateur d’evenements et naviguez vers Journaux Windows > Application. Filtrez pour l’Event ID 9646 avec la source MSExchangeIS. Le detail de l’evenement revele l’utilisateur affecte, le type d’objet ayant depasse la limite, et le comptage actuel par rapport au 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".Cela vous indique immediatement quelle boite aux lettres est problematique et quel type d’objet est epuise.
Etape 2 : Utiliser Get-StoreUsageStatistics
Le cmdlet Get-StoreUsageStatistics est votre outil de diagnostic principal. Executez-le sur la base de donnees de boites aux lettres affectee :
Get-StoreUsageStatistics -Database "Mailbox Database 01" |
Sort-Object -Property DigestCategory -Descending |
Format-Table DisplayName, DigestCategory, SampleCount, SampleValue -AutoSizeCela retourne les donnees de consommation de ressources pour toutes les sessions actives de boites aux lettres. Recherchez les boites aux lettres avec des valeurs SampleValue anormalement elevees, indiquant des objets ouverts excessifs.
Pour cibler une boite aux lettres specifique :
Get-StoreUsageStatistics -Identity "[email protected]" |
Format-List *Etape 3 : Verifier les statistiques de la boite aux lettres
Utilisez Get-MailboxStatistics pour identifier les boites aux lettres avec un nombre d’elements anormalement eleve pouvant contribuer au probleme :
Get-MailboxStatistics -Database "Mailbox Database 01" |
Sort-Object -Property ItemCount -Descending |
Select-Object DisplayName, ItemCount, TotalItemSize, LastLogonTime -First 20Les boites aux lettres contenant des centaines de milliers d’elements dans un seul dossier sont les principales candidates pour declencher des exceptions de limite d’objets, en particulier lorsque les clients tentent de synchroniser l’integralite du dossier.
Etape 4 : Compteurs Performance Monitor
Ajoutez les compteurs suivants dans Performance Monitor pour suivre la consommation d’objets MAPI en temps reel :
- MSExchangeIS Store\Active Client Logons — total des sessions actives
- MSExchangeIS Store\Client: RPCs attempted/sec — taux de requetes
- MSExchangeIS Store\Messages Opened/sec — taux de creation d’objets
- MSExchangeIS\RPC Requests — operations RPC concurrentes
- Process(Store)\Working Set — consommation memoire de Store.exe
Creez un ensemble de collecteurs de donnees et executez-le pendant au moins quatre heures pour capturer les tendances d’utilisation en pointe. Correlez les pics de comptage de messages ouverts avec les horodatages des entrees de l’Event ID 9646.
Causes courantes
Complements Outlook defectueux
Les complements Outlook tiers sont le coupable le plus frequent. Les complements effectuant une indexation en arriere-plan, une integration avec les reseaux sociaux ou une synchronisation CRM ouvrent souvent des centaines d’objets MAPI par dossier et ne les liberent pas correctement. Un seul utilisateur avec un complement mal code peut epuiser la limite d’objets par session en quelques minutes.
Pour identifier le complement fautif, verifiez les informations du client RPC :
Get-RpcClientAccess -Server EX01 | Format-ListPuis correlez le nom de l’application cliente dans les details de l’Event ID 9646. Les coupables courants incluent les versions obsoletes de Salesforce pour Outlook, les complements Thomson Reuters et les analyseurs antivirus de messagerie.
Logiciels de sauvegarde et d’archivage tiers
Les agents de sauvegarde tels que Veeam Explorer for Exchange, Veritas Backup Exec ou Commvault utilisent frequemment MAPI ou EWS pour enumerer et lire le contenu des boites aux lettres pendant les fenetres de sauvegarde. Si le logiciel de sauvegarde est configure pour la restauration au niveau de l’element, il peut ouvrir chaque message d’une base de donnees simultanement, depassant facilement les limites d’objets.
Verifiez les planifications des taches de sauvegarde et confirmez si les evenements TooManyObjectsOpenedException coincident avec les fenetres de sauvegarde. Examinez la configuration du logiciel de sauvegarde pour les options permettant de limiter les connexions MAPI ou d’utiliser des snapshots VSS a la place.
Problemes de l’indexeur de recherche Exchange
Le Microsoft Exchange Search Host Controller (HostControllerService) et le processus d’indexation du contenu peuvent dysfonctionner et tenter de maniere repetee d’indexer les memes elements, maintenant des objets excessifs ouverts. Verifiez l’etat de l’index de recherche :
Get-MailboxDatabaseCopyStatus * |
Select-Object Name, Status, ContentIndexState, ContentIndexErrorMessageSi ContentIndexState affiche Failed ou Crawling pendant des periodes prolongees, l’indexeur peut contribuer a l’epuisement des objets. Reconstruisez l’index si necessaire :
Stop-Service MSExchangeFastSearch
Stop-Service HostControllerService
# Supprimer le dossier du catalogue d'index pour la base de donnees affectee
Remove-Item "D:\ExchangeDatabases\DB01\DB01.Single" -Recurse -Force
Start-Service MSExchangeFastSearch
Start-Service HostControllerServiceProblemes de replication des dossiers publics
Dans les environnements avec des boites aux lettres de dossiers publics, la synchronisation de la hierarchie de replication peut provoquer une creation excessive d’objets. Chaque dossier public dans la hierarchie necessite des objets ouverts pendant la synchronisation. Les organisations comptant des milliers de dossiers publics peuvent facilement depasser les limites pendant les cycles de replication.
Verifiez l’etat de la replication des dossiers publics :
Get-PublicFolderMailboxDiagnostics -Identity "PF_Mailbox01" |
Select-Object -ExpandProperty SyncInfoCorruption de la base de donnees
La corruption sous-jacente de la base de donnees ESE peut amener l’Information Store a tenter de maniere repetee d’acceder a des pages endommagees, creant et abandonnant des objets MAPI dans le processus. Si les autres causes ont ete eliminees, executez une verification d’integrite :
# Demonter la base de donnees d'abord
Dismount-Database "Mailbox Database 01" -Confirm:$false
# Executer eseutil pour la verification d'integrite
eseutil /g "D:\ExchangeDatabases\DB01\DB01.edb"
# Si des problemes sont trouves, executer la reparation
eseutil /p "D:\ExchangeDatabases\DB01\DB01.edb"
# Defragmenter pour recuperer l'espace
eseutil /d "D:\ExchangeDatabases\DB01\DB01.edb"
# Remonter
Mount-Database "Mailbox Database 01"Comparaison des limites d’objets par version d’Exchange
| Parametre | Exchange 2013 | Exchange 2016 | Exchange 2019 |
|---|---|---|---|
| Max objets par session (objtMessage) | 500 | 500 | 500 |
| Max dossiers ouverts par session | 500 | 500 | 500 |
| Max objets par boite aux lettres (total) | 16 000 | 16 000 | 16 000 |
| Max connexions RPC concurrentes | 40 | 40 | 40 |
| Delai d’expiration RPC par defaut (secondes) | 120 | 120 | 120 |
| Memoire max de Store.exe (% de RAM) | Dynamique (jusqu’a 75%) | Dynamique (jusqu’a 75%) | Dynamique (jusqu’a 75%) |
| Strategie de limitation configurable | Oui (New-ThrottlingPolicy) | Oui (New-ThrottlingPolicy) | Oui (New-ThrottlingPolicy) |
| Taille du cache ESE configurable | Oui (registre) | Oui (registre) | Oui (registre) |
Notez que bien que les limites par defaut soient identiques entre les versions, Exchange 2016 et 2019 disposent d’algorithmes ameliores de gestion de la memoire qui traitent le nettoyage des objets de maniere plus agressive qu’Exchange 2013.
Resolution etape par etape
1. Identifier la cause immediate
Examinez les 24 dernieres heures d’entrees de l’Event ID 9646 et compilez une liste des boites aux lettres affectees et des applications clientes :
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
ProviderName = 'MSExchangeIS'
ID = 9646
StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Export-Csv C:\temp\9646events.csv2. Augmenter les limites d’objets (soulagement temporaire)
Si l’impact en production est severe, augmentez temporairement la limite d’objets par session via le registre :
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value: Maximum Allowed Sessions Per User
Type: REG_DWORD
Data: 32 (par defaut 16, augmenter a 32 ou 64)Pour les limites par type d’objet, creez une strategie de limitation personnalisee :
New-ThrottlingPolicy -Name "HighObjectLimit" -RCAMaxConcurrency 40 -RCAPercentTimeInAD 100
Set-Mailbox -Identity "jsmith" -ThrottlingPolicy "HighObjectLimit"Redemarrez le service Microsoft Exchange Information Store apres les modifications du registre.
3. Traiter la cause racine
En fonction de votre diagnostic des sections precedentes :
- Complements Outlook : Desactivez le complement fautif via la Strategie de groupe ou les cles de registre des complements COM Office. Testez avec Outlook en mode sans echec (
outlook.exe /safe). - Logiciel de sauvegarde : Reconfigurez pour utiliser des snapshots bases sur VSS au lieu de l’enumeration MAPI. Planifiez les sauvegardes pendant les heures creuses.
- Indexeur de recherche : Reconstruisez le catalogue d’index de contenu pour la base de donnees affectee.
- Dossiers publics : Reduisez la taille de la hierarchie, divisez les grandes boites aux lettres de dossiers publics ou ajustez le calendrier de replication.
- Corruption de la base de donnees : Executez
eseutil /dpour une defragmentation hors ligne afin de nettoyer les incoherences de la base de donnees.
4. Mettre en place une surveillance preventive
Creez une regle de surveillance pour l’Event ID 9646 dans votre systeme de surveillance (SCOM, Zabbix ou similaire) et configurez une tache planifiee PowerShell pour suivre les comptages d’objets :
$results = Get-StoreUsageStatistics -Database "Mailbox Database 01" |
Where-Object { $_.SampleValue -gt 400 }
if ($results) {
Send-MailMessage -To "[email protected]" -Subject "Alerte Objets MAPI" `
-Body ($results | Out-String) -SmtpServer "smtp.contoso.com"
}Scenario Reel
Votre serveur Exchange 2016 commence a enregistrer l’Event ID 9646 toutes les quelques minutes un lundi matin. La memoire de Store.exe est passee de ses 24 Go habituels a 38 Go sur un serveur de 48 Go. Les utilisateurs signalent des deconnexions Outlook et un chargement lent des dossiers.
Vous executez Get-StoreUsageStatistics et decouvrez que cinq boites aux lettres appartenant a l’equipe commerciale affichent des comptages d’objets eleves. En verifiant les details de l’evenement, vous constatez que l’application cliente est identifiee comme “Client=MSExchangeRPC” avec une etiquette supplementaire pointant vers un complement CRM tiers.
Une investigation plus approfondie revele que l’equipe informatique a deploye une nouvelle version du complement Dynamics 365 pour Outlook pendant le week-end. Cette version presente un bug connu ou elle ouvre des objets message pour chaque enregistrement de contact mais ne les ferme jamais. En quelques heures, la session de chaque utilisateur commercial accumule plus de 450 objets message ouverts, approchant la limite de 500.
La resolution implique trois etapes : Premierement, vous augmentez temporairement la limite par session a 1 000 via le registre pour stopper l’hemorragie immediate. Deuxiemement, vous revenez a la version precedente du complement CRM en utilisant la Strategie de groupe. Troisiemement, vous redemarrez le service Information Store pendant la pause dejeuner pour nettoyer les objets accumules. Au cours des 24 heures suivantes, la memoire de Store.exe retrouve sa ligne de base normale de 24 Go et plus aucun evenement 9646 n’apparait.
Pieges et Cas Particuliers
Environnements Database Availability Group (DAG) : Dans un DAG, TooManyObjectsOpenedException sur un noeud ne se replique pas automatiquement vers les copies passives. Cependant, si la cause racine est un probleme au niveau de la boite aux lettres (comme un element corrompu), le probleme suivra la boite aux lettres lors du basculement de la base de donnees. Verifiez toujours les noeuds actifs et passifs.
Coexistence avec Exchange 2013 et 2016 : Pendant la coexistence de migration, les sessions proxy entre serveurs peuvent multiplier les comptages d’objets MAPI. Une seule session Outlook vers une boite aux lettres 2013 proxiee via un serveur 2016 cree des objets sur les deux serveurs. Surveillez les deux serveurs pendant la coexistence.
Mode cache versus mode en ligne : Outlook en Mode Cache Exchange ouvre moins d’objets concurrents que le Mode En Ligne car il synchronise de maniere incrementale. Cependant, la synchronisation initiale d’un profil en Mode Cache pour une grande boite aux lettres (100 000+ elements) peut temporairement faire monter les comptages d’objets au-dessus des seuils.
Boites aux lettres partagees avec de nombreux delegues : Une boite aux lettres partagee ouverte par 20 utilisateurs simultanement cree 20 sessions separees, chacune avec sa propre allocation d’objets. La limite agregee par boite aux lettres peut etre atteinte rapidement meme si aucune session individuelle n’est abusive.
Exchange hybride avec Office 365 : Les consultations hybrides de disponibilite et les deplacements de boites aux lettres inter-sites creent des sessions MAPI temporaires qui consomment des objets. Pendant les migrations par lots massives, le serveur sur site peut subir une pression d’objets provenant du point de terminaison de migration.
Resolution de Problemes
Requete de journal d’evenements pour les erreurs associees
Recherchez les evenements associes qui accompagnent frequemment TooManyObjectsOpenedException :
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 : La session a depasse le maximum d’objets de type
objtFolder - Event ID 9667 : Limite de connexion RPC depassee
- Event ID 9760 : Session MAPI deconnectee pour epuisement de ressources
Compteurs de performance ESE
Surveillez ces compteurs pour detecter les problemes au niveau de la base de donnees contribuant a la consommation memoire elevee :
- Database\Database Cache % Hit — doit etre superieur a 99%. En dessous de 95%, cela indique une memoire insuffisante ou un thrashing du cache
- Database\Database Page Evictions/sec — des valeurs elevees signifient que le cache est plein et evince activement des pages
- Database\Log Record Stalls/sec — indique une contention en ecriture pouvant entrainer une retention d’objets
La memoire de Store.exe ne diminue pas apres la correction
Si la memoire de Store.exe reste elevee apres la resolution de la cause racine, le cache ESE peut necessiter une intervention manuelle. Redemarrez le service Microsoft Exchange Information Store pendant une fenetre de maintenance :
Restart-Service MSExchangeIS -ForceDans les environnements DAG, effectuez d’abord un basculement controle de la base de donnees :
Move-ActiveMailboxDatabase "Mailbox Database 01" -ActivateOnServer EX02 -Confirm:$falsePuis redemarrez l’Information Store sur le serveur actif d’origine. Cela garantit zero temps d’arret pour les utilisateurs.
Resume
- TooManyObjectsOpenedException survient lorsque les limites d’objets MAPI sont depassees, causant une croissance de la memoire de Store.exe et des deconnexions clients
- Event ID 9646 dans le journal Application identifie la boite aux lettres affectee et le type d’objet ayant atteint la limite
- Get-StoreUsageStatistics est le cmdlet PowerShell principal pour diagnostiquer quelles boites aux lettres consomment des ressources excessives
- Les cinq causes les plus courantes sont les complements Outlook defectueux, les logiciels de sauvegarde, les defaillances de l’indexeur de recherche, les problemes de replication des dossiers publics et la corruption de la base de donnees
- Le soulagement temporaire consiste a augmenter les limites par session via le registre, mais traitez toujours la cause racine
- eseutil /d en defragmentation hors ligne resout la corruption au niveau de la base de donnees contribuant aux fuites d’objets
- Surveillez proactivement les Event IDs 9646, 9660, 9667 et 9760 pour detecter les problemes avant qu’ils n’impactent les utilisateurs
- Dans les environnements DAG, effectuez toujours des basculements controles avant de redemarrer l’Information Store