Exchange TooManyObjectsOpenedException: Store.exe con alto consumo de memoria

Los administradores de Exchange Server temen el momento en que su panel de monitoreo se ilumina con errores Microsoft.Exchange.Data.Storage.TooManyObjectsOpenedException mientras el consumo de memoria de Store.exe escala mas alla de umbrales aceptables. Este error indica que uno o mas procesos han excedido el numero maximo de objetos MAPI abiertos simultaneamente en tu servidor Exchange 2013, 2016 o 2019. En este articulo, aprenderas exactamente que desencadena esta excepcion, como diagnosticar la causa raiz usando PowerShell y Performance Monitor, y como resolverlo sistematicamente antes de que impacte todo tu entorno de mensajeria.

Requisitos Previos

• Exchange Server 2013, 2016 o 2019 con la ultima actualizacion acumulativa instalada
• Acceso al Exchange Management Shell con rol de Organization Management o Server Management
• Acceso de administrador local al servidor Exchange
• Acceso a Performance Monitor (perfmon.exe)
• Familiaridad con PowerShell y cmdlets de Exchange
• Acceso al Visor de Eventos para los logs de Aplicacion y Sistema
• Comprension basica del protocolo MAPI

Entendiendo TooManyObjectsOpenedException

La excepcion TooManyObjectsOpenedException es lanzada por el Exchange Information Store (Store.exe) cuando una sesion de cliente o proceso en segundo plano abre mas objetos MAPI de los que el umbral configurado permite. Los objetos MAPI incluyen mensajes, carpetas, adjuntos, vistas de tabla y suscripciones de notificacion. Cada vez que Outlook abre una carpeta, expande una conversacion, o un agente de respaldo enumera contenidos de buzon, crea objetos MAPI que consumen memoria dentro del proceso Store.exe.

Exchange aplica estos limites a traves de politicas de limitacion para proteger la estabilidad del servidor. Cuando una sola sesion o buzon excede su conteo de objetos asignado, el Information Store genera el Event ID 9646 en el log de Aplicacion y rechaza solicitudes adicionales de objetos de esa sesion. El sintoma visible inmediato es que los clientes de Outlook afectados experimentan bloqueos, desconexiones o errores de “No se puede expandir la carpeta”, mientras que del lado del servidor se ve la memoria de Store.exe creciendo sin control.

La distincion critica aqui es entre limites por sesion y limites por buzon. Un solo usuario ejecutando Outlook con diez complementos puede tener diez sesiones separadas, cada una consumiendo objetos. El limite por sesion puede no ser excedido, pero el limite agregado por buzon aun puede superarse.

Como Funcionan los Limites de Objetos MAPI

Exchange rastrea los objetos abiertos a traves del seguimiento interno de recursos del Information Store. Cada tipo de objeto tiene su propio contador:

• Mensajes abiertos: Numero de objetos de mensaje abiertos simultaneamente
• Carpetas abiertas: Numero de objetos de carpeta retenidos en memoria
• Adjuntos abiertos: Flujos de adjuntos actualmente accedidos
• Suscripciones de notificacion: Registros de notificaciones push de clientes

Cuando cualquier contador excede su maximo configurado, el store genera la excepcion y la registra como Event ID 9646 con detalles sobre que usuario y que tipo de objeto desencadeno el limite.

Diagnosticando el Problema

Paso 1: Confirmar el Error en Logs de Eventos

Abre el Visor de Eventos y navega a Logs de Windows > Aplicacion. Filtra por Event ID 9646 con origen MSExchangeIS. El detalle del evento revela el usuario afectado, el tipo de objeto que excedio el limite y el conteo actual versus el maximo:

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".

Esto te dice inmediatamente cual buzon es problematico y que tipo de objeto se esta agotando.

Paso 2: Usar Get-StoreUsageStatistics

El cmdlet Get-StoreUsageStatistics es tu herramienta de diagnostico principal. Ejecutalo contra la base de datos de buzon afectada:

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

Esto retorna datos de consumo de recursos para todas las sesiones activas de buzon. Busca buzones con numeros anormalmente altos en SampleValue, que indican objetos abiertos excesivos.

Para enfocarte en un buzon especifico:

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

Paso 3: Verificar Estadisticas del Buzon

Usa Get-MailboxStatistics para identificar buzones con conteos de elementos inusualmente grandes que podrian contribuir al problema:

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

Los buzones con cientos de miles de elementos en una sola carpeta son candidatos principales para desencadenar excepciones de limite de objetos, especialmente cuando los clientes intentan sincronizar la carpeta completa.

Paso 4: Contadores de Performance Monitor

Agrega los siguientes contadores en Performance Monitor para rastrear el consumo de objetos MAPI en tiempo real:

• MSExchangeIS Store\Active Client Logons — total de sesiones activas
• MSExchangeIS Store\Client: RPCs attempted/sec — tasa de solicitudes
• MSExchangeIS Store\Messages Opened/sec — tasa de creacion de objetos
• MSExchangeIS\RPC Requests — operaciones RPC concurrentes
• Process(Store)\Working Set — consumo de memoria de Store.exe

Crea un conjunto de recopiladores de datos y ejecutalo durante al menos cuatro horas para capturar patrones de uso pico. Correlaciona los picos en conteos de mensajes abiertos con las marcas de tiempo de las entradas del Event ID 9646.

Causas Comunes

Complementos de Outlook Defectuosos

Los complementos de terceros para Outlook son el culpable mas frecuente. Los complementos que realizan indexacion en segundo plano, integracion con redes sociales o sincronizacion con CRM frecuentemente abren cientos de objetos MAPI por carpeta y no los liberan correctamente. Un solo usuario con un complemento mal programado puede agotar el limite de objetos por sesion en minutos.

Para identificar el complemento infractor, verifica la informacion del cliente RPC:

Get-RpcClientAccess -Server EX01 | Format-List

Luego correlaciona el nombre de la aplicacion cliente en los detalles del Event ID 9646. Los infractores comunes incluyen versiones desactualizadas de Salesforce para Outlook, complementos de Thomson Reuters y escaneadores de correo antivirus.

Software de Respaldo y Archivado de Terceros

Los agentes de respaldo como Veeam Explorer for Exchange, Veritas Backup Exec o Commvault frecuentemente usan MAPI o EWS para enumerar y leer contenidos de buzon durante ventanas de respaldo. Si el software de respaldo esta configurado para recuperacion a nivel de elemento, puede abrir cada mensaje en una base de datos simultaneamente, excediendo facilmente los limites de objetos.

Verifica los programas de trabajos de respaldo y confirma si los eventos de TooManyObjectsOpenedException se correlacionan con ventanas de respaldo. Revisa la configuracion del software de respaldo para opciones de limitar conexiones MAPI o usar snapshots VSS en su lugar.

Problemas del Indexador de Busqueda de Exchange

El Microsoft Exchange Search Host Controller (HostControllerService) y el proceso de indexacion de contenido pueden funcionar mal e intentar repetidamente indexar los mismos elementos, manteniendo objetos excesivos abiertos. Verifica la salud del indice de busqueda:

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

Si ContentIndexState muestra Failed o Crawling por periodos extendidos, el indexador puede estar contribuyendo al agotamiento de objetos. Reconstruye el indice si es necesario:

Stop-Service MSExchangeFastSearch
Stop-Service HostControllerService

# Eliminar la carpeta del catalogo de indice para la base de datos afectada
Remove-Item "D:\ExchangeDatabases\DB01\DB01.Single" -Recurse -Force

Start-Service MSExchangeFastSearch
Start-Service HostControllerService

Problemas de Replicacion de Carpetas Publicas

En entornos con buzones de carpetas publicas, la sincronizacion de jerarquia de replicacion puede causar creacion excesiva de objetos. Cada carpeta publica en la jerarquia requiere objetos abiertos durante la sincronizacion. Las organizaciones con miles de carpetas publicas pueden exceder facilmente los limites durante ciclos de replicacion.

Verifica la salud de replicacion de carpetas publicas:

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

Corrupcion de Base de Datos

La corrupcion subyacente de la base de datos ESE puede causar que el Information Store intente repetidamente acceder a paginas danadas, creando y abandonando objetos MAPI en el proceso. Si se han eliminado otras causas, ejecuta una verificacion de integridad:

# Desmontar la base de datos primero
Dismount-Database "Mailbox Database 01" -Confirm:$false

# Ejecutar eseutil para verificacion de integridad
eseutil /g "D:\ExchangeDatabases\DB01\DB01.edb"

# Si se encuentran problemas, ejecutar reparacion
eseutil /p "D:\ExchangeDatabases\DB01\DB01.edb"

# Desfragmentar para recuperar espacio
eseutil /d "D:\ExchangeDatabases\DB01\DB01.edb"

# Remontar
Mount-Database "Mailbox Database 01"

Comparativa de Limites de Objetos por Version de Exchange

Parametro	Exchange 2013	Exchange 2016	Exchange 2019
Max objetos por sesion (objtMessage)	500	500	500
Max carpetas abiertas por sesion	500	500	500
Max objetos por buzon (total)	16,000	16,000	16,000
Max conexiones RPC concurrentes	40	40	40
Timeout RPC predeterminado (segundos)	120	120	120
Memoria max de Store.exe (% de RAM)	Dinamico (hasta 75%)	Dinamico (hasta 75%)	Dinamico (hasta 75%)
Politica de limitacion configurable	Si (New-ThrottlingPolicy)	Si (New-ThrottlingPolicy)	Si (New-ThrottlingPolicy)
Tamano de cache ESE configurable	Si (registro)	Si (registro)	Si (registro)

Nota que aunque los limites predeterminados son identicos entre versiones, Exchange 2016 y 2019 tienen algoritmos mejorados de gestion de memoria que manejan la limpieza de objetos de forma mas agresiva que Exchange 2013.

Resolucion Paso a Paso

1. Identificar la Causa Inmediata

Revisa las ultimas 24 horas de entradas del Event ID 9646 y compila una lista de buzones afectados y aplicaciones cliente:

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. Aumentar Limites de Objetos (Alivio Temporal)

Si el impacto en produccion es severo, aumenta temporalmente el limite de objetos por sesion via registro:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value: Maximum Allowed Sessions Per User
Type: REG_DWORD
Data: 32 (predeterminado es 16, aumentar a 32 o 64)

Para limites por tipo de objeto, crea una politica de limitacion personalizada:

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

Reinicia el servicio Microsoft Exchange Information Store despues de cambios en el registro.

3. Abordar la Causa Raiz

Basandote en tu diagnostico de las secciones anteriores:

• Complementos de Outlook: Deshabilita el complemento infractor via Politica de Grupo o las claves de registro de complementos COM de Office. Prueba con Outlook en modo seguro (outlook.exe /safe).
• Software de respaldo: Reconfigura para usar snapshots basados en VSS en lugar de enumeracion MAPI. Programa respaldos durante horas de baja demanda.
• Indexador de busqueda: Reconstruye el catalogo de indice de contenido para la base de datos afectada.
• Carpetas publicas: Reduce el tamano de la jerarquia, divide buzones grandes de carpetas publicas o ajusta el programa de replicacion.
• Corrupcion de base de datos: Ejecuta eseutil /d para desfragmentacion fuera de linea para limpiar inconsistencias de la base de datos.

4. Implementar Monitoreo Preventivo

Crea una regla de monitoreo para Event ID 9646 en tu sistema de monitoreo (SCOM, Zabbix o similar) y configura una tarea programada de PowerShell para rastrear conteos de objetos:

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

Escenario del Mundo Real

Tu servidor Exchange 2016 comienza a registrar Event ID 9646 cada pocos minutos un lunes por la manana. La memoria de Store.exe ha escalado de sus habituales 24 GB a 38 GB en un servidor de 48 GB. Los usuarios reportan desconexiones de Outlook y carga lenta de carpetas.

Ejecutas Get-StoreUsageStatistics y descubres que cinco buzones pertenecientes al equipo de ventas muestran conteos elevados de objetos. Verificando los detalles del evento, ves que la aplicacion cliente se identifica como “Client=MSExchangeRPC” con una etiqueta adicional apuntando a un complemento CRM de terceros.

Una investigacion adicional revela que el equipo de TI implemento una nueva version del complemento de Dynamics 365 para Outlook durante el fin de semana. Esta version tiene un error conocido donde abre objetos de mensaje para cada registro de contacto pero nunca los cierra. En pocas horas, la sesion de cada usuario de ventas acumula mas de 450 objetos de mensaje abiertos, acercandose al limite de 500.

La resolucion involucra tres pasos: Primero, aumentas temporalmente el limite por sesion a 1,000 via registro para detener el sangrado inmediato. Segundo, reviertes el complemento CRM a la version anterior usando Politica de Grupo. Tercero, reinicias el servicio Information Store durante el almuerzo para limpiar los objetos acumulados. Durante las siguientes 24 horas, la memoria de Store.exe regresa a su linea base normal de 24 GB y no aparecen mas eventos 9646.

Errores Comunes y Casos Especiales

Entornos de Database Availability Group (DAG): En un DAG, TooManyObjectsOpenedException en un nodo no se replica automaticamente a copias pasivas. Sin embargo, si la causa raiz es un problema a nivel de buzon (como un elemento corrupto), el problema seguira al buzon durante la conmutacion por error de la base de datos. Siempre verifica tanto nodos activos como pasivos.

Coexistencia con Exchange 2013 y 2016: Durante la coexistencia de migracion, las sesiones proxy entre servidores pueden multiplicar los conteos de objetos MAPI. Una sola sesion de Outlook a un buzon 2013 proxiada a traves de un servidor 2016 crea objetos en ambos servidores. Monitorea ambos servidores durante la coexistencia.

Modo cache versus modo en linea: Outlook en Modo Cache de Exchange abre menos objetos concurrentes que el Modo En Linea porque sincroniza incrementalmente. Sin embargo, la sincronizacion inicial de un perfil en Modo Cache para un buzon grande (100,000+ elementos) puede elevar temporalmente los conteos de objetos por encima de los umbrales.

Buzones compartidos con muchos delegados: Un buzon compartido abierto por 20 usuarios simultaneamente crea 20 sesiones separadas, cada una con su propia asignacion de objetos. El limite agregado por buzon puede alcanzarse rapidamente incluso si ninguna sesion individual es abusiva.

Exchange hibrido con Office 365: Las consultas hibridas de libre/ocupado y los movimientos de buzon entre instalaciones crean sesiones MAPI temporales que consumen objetos. Durante migraciones masivas por lotes, el servidor local puede experimentar presion de objetos desde el endpoint de migracion.

Solucion de Problemas

Consulta de Log de Eventos para Errores Relacionados

Busca eventos relacionados que frecuentemente acompanan a 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 sesion excedio el maximo de objetos de tipo objtFolder
• Event ID 9667: Limite de conexion RPC excedido
• Event ID 9760: Sesion MAPI desconectada por agotamiento de recursos

Contadores de Rendimiento ESE

Monitorea estos contadores para detectar problemas a nivel de base de datos que contribuyen al alto consumo de memoria:

• Database\Database Cache % Hit — debe estar por encima del 99%. Por debajo del 95% indica memoria insuficiente o thrashing de cache
• Database\Database Page Evictions/sec — valores altos significan que el cache esta lleno y descartando paginas activamente
• Database\Log Record Stalls/sec — indica contencion de escritura que puede escalar a retencion de objetos

La Memoria de Store.exe No Disminuye Despues de la Correccion

Si la memoria de Store.exe permanece elevada despues de resolver la causa raiz, el cache ESE puede necesitar intervencion manual. Reinicia el servicio Microsoft Exchange Information Store durante una ventana de mantenimiento:

Restart-Service MSExchangeIS -Force

En entornos DAG, realiza primero una conmutacion controlada de base de datos:

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

Luego reinicia el Information Store en el servidor activo original. Esto asegura cero tiempo de inactividad para los usuarios.

Resumen

• TooManyObjectsOpenedException ocurre cuando se exceden los limites de objetos MAPI, causando crecimiento de memoria de Store.exe y desconexiones de clientes
• Event ID 9646 en el log de Aplicacion identifica el buzon afectado y el tipo de objeto que alcanzo el limite
• Get-StoreUsageStatistics es el cmdlet principal de PowerShell para diagnosticar que buzones consumen recursos excesivos
• Las cinco causas mas comunes son complementos de Outlook defectuosos, software de respaldo, fallas del indexador de busqueda, problemas de replicacion de carpetas publicas y corrupcion de base de datos
• El alivio temporal involucra aumentar los limites por sesion via registro, pero siempre aborda la causa raiz
• eseutil /d para desfragmentacion fuera de linea resuelve la corrupcion a nivel de base de datos que contribuye a fugas de objetos
• Monitorea proactivamente los Event IDs 9646, 9660, 9667 y 9760 para detectar problemas antes de que impacten a los usuarios
• En entornos DAG, siempre realiza conmutaciones controladas antes de reiniciar el Information Store

Articulos Relacionados

• What is Store.exe? Why Does It Use Almost All My Memory?
• Resolve X-OWA Error: Microsoft.Exchange.Data.Storage.ADUserNotFoundException
• Resolve Network Path Not Found in Exchange 2010 Management Console
• What is FSDMHost.exe?
• DFSR Event ID 4012: SYSVOL Replication Stopped