Nota: Este artículo fue publicado originalmente en 2012. Algunos pasos, comandos o versiones de software pueden haber cambiado. Consulta la documentación actual de Exchange para la información más reciente.

¿Qué es Store.exe?

Si alguna vez has iniciado sesión como administrador en un Microsoft Small Business Server (SBS) o en un servidor de correos empresarial, probablemente hayas abierto el Administrador de Tareas y reaccionado con susto al ver que un simple proceso llamado store.exe está consumiendo 16GB, 32GB, o hasta 64GB continuos de RAM — dejando solo unos pocos megabytes disponibles en el resto del equipo.

store.exe no es un virus, es el Microsoft Exchange Information Store. Y es el corazón absoluto del servidor Microsoft Exchange. Este servicio es responsable de montar y administrar localmente el motor de base de datos Extensible Storage Engine (ESE), el lugar donde se guardan estrictamente los buzones, archivos adjuntos de correos, agendas, y directorios públicos de todos los empleados en la compañía.

Si no tienes una derivación de Microsoft Exchange instalada o configurada dentro de tu red corporativa o Active Directory, este proceso sería catalogable como sospechoso; de lo contrario, si cuentas con Exchange Server en tu ambiente de red o DMZ local, store.exe es 100% legal y completamente crítico.

¿Por qué consume hasta la última gota de memoria RAM?

El comportamiento en el que store.exe literalmente se apropia del 90% de un servidor por sí solo es enteramente intencional.

Las operaciones sobre bases de datos hechas por Exchange Server son intensivas en recursos de disco duro (I/O). Para proporcionar a los clientes ofimáticos conectados a Outlook corporativo una capacidad de refresco rápida (y a prueba de miles de emails, archivos adjuntos abriéndose y modificando la estructura al unísono), el almacén ‘Information Store’ precariza recursos, recurriendo de forma drástica al un esquema de Asignación Dinámica del Caché.

A muy breves rasgos esto implica un proceso agresivo: Exchange sube y almacena la base activa en curso enteramente e insertándola directo a la Memoria RAM disponible. Con el obvio principio lógico de que leer miles de emails por segundo en RAM toma apenas nanosegundos (vs esperar a las altas latencias de la aguja física o interfaces leyendo desde un disco duro magnético de red o NAS local).

Por ende, store.exe está programado intencionalmente por Microsoft para apoderarse de hasta la última fracción de memoria instalada. Si de pronto te parece que tu servidor Exchange se congelaba y subes tus baras de 16GB ECC originales empujándolo al nuevo marco con 32GB en DDR ampliado; de inmediato, store.exe sentirá gozo de capturar toda tu inversión rebasando la totalidad del espacio a su nuevo nivel: apoderar y ocupar los 32GB llenos.

Pero ¿Esto significa que colapsará?

Respuesta corta: No. Esa asignación hiper-masiva es completamente dinámica. Esto quiere decir store.exe actúa como monopolizador solo en ausencia de otras demandas. Si por ejemplo de la nada Windows Server reporta una llamada crítica en memoria, una petición de un servidor SQL que comparte rol de espacio o IIS que levanta temporalmente sitios Intranet — store.exe reacciona abriendo su puño y entregando inmediatamente fracciones masivas al pool global del servidor previniendo cualquier falla fatal de paginado (“paging”) o crasheo interno de otros perfiles corporativos en marcha.

¿Puedo eliminarlo o forzar un bloqueo? (Task Kill)

No lo hagas. Finalizar store.exe desbordaría trágicamente todas las operaciones de los buzones, expulsará inmediatamente y permanentemente cualquier empleado corporativo en sesión intentando adjuntar o enviar un correo electrónico por webmail u Outlook (Desktop) y te abres por completo al daño y corrupciones en las bases de datos transaccionales, dañándolo irrevocablemente.

Guía cómo re-educar o Límite duro manual (Threshold) a Store.exe

Existen condiciones atípicas y controladas de escenarios múltiples en redes (A veces conviviendo Exchange forzosamente al mismo tiempo como file server corporativo AD general o control de Dominio) en dónde el proceso interno dinámico a veces no reacciona o libera lo suficientemente rápido como quisiéramos ante inmensa presión y se exige limitar un tope duro.

Para crear restricciones sobre el nivel de recursos del cual el Caché nunca debe cruzar; es necesario forzar configuraciones y entrar en ediciones mediante ADSI Edit.

Advertencia Extrema: Modificar un atributo dentro de Active Directory sin cautela tiene alta probabilidad de averiar completamente toda su jerarquía de conectividad perimetral. En este marco de modificaciones en Exchange; un tope drásticamente apretado destrozará a Exchange, obligando a las redes a operar con lentitudes severas de consulta de los discos locales al denegar sus tiempos habituales.

Dicho lo anterior, aquí indicamos la ruta del límite físico y su alteración al marco regulatorio general:

  1. Ejecuta ADSI Edit (adsiedit.msc) vía comandos rápidos ejecutar dentro de tu Servidor de Controlador de Dominio principal, o en tu equipo local principal donde subyace el buzón físico y panel local principal.
  2. Selecciona Connect To / Conectar a… haciendo click secundario/botón derecho en la herramienta superior raíz.
  3. El primer campo será Seleccionar bajo que nombre y contexto seleccionar ahí lo pertinente y usar contexto de particiones y marcar Configuración (Configuration). Pulse Aceptar o (OK).
  4. Proceda bajo el esquema arbóreo expandible buscando el nudo correspondiente bajo su esquema como se muestra usualmente : CN=Configuration, DC=sudominio, DC=local -> CN=Services -> CN=Microsoft Exchange -> CN=Su Organizacion Local -> CN=Administrative Groups -> CN=Exchange Administrative Group -> CN=Servers -> CN=Nombre original asignado en la red a este servidor PC -> CN=InformationStore
  5. Al situarse visualmente ante uno que declare a nivel objeto el literal CN=InformationStore despliegue propiedades del mismo por click derecho Propiedades/Properties.
  6. En aquella interminable cuadrilla del centro identifique minuciosamente por orden el vector: msExchESEParamCacheSizeMax.
  7. Seleccionar atributo por un doble touch y elegir acción rápida o submenú de edición inferior (Edit).

Precaución Matemática, Calculo obligatorio para la Base de límite de Paginas de Extensible

¡Alto!: El dígito unitario tecleado por inserción NO debe equivaler nominalmente directo a Gigabytes (ni Giga, Tera, Mega). El bloque requiere estar transformado e inserto exclusivamente calculado utilizando “Bloques Internos (Páginas)” (Paging Values).

  • En el estándar y las reglas de motor a través para arquitecturas y distribuciones equivalentes a los Exchange 2010/2013/2016 se precalculó un bloque = Exactamente 32 Kilobytes (32KB). Así que necesitas multiplicadores escalables en base a esto para lograr los tamaños tradicionales requeridos deseados:

Formula Ejemplo. Supongamos se te ha solicitado asignar a Exchange solo exactamente y sin flexibilizaciones 4 Gigabytes (4GB) puros de Memoria RAM estancado al proceso Store:

  1. Transforma de valor 4 Gigas a Unidad Kilos correspondientes y multiplicadores: 4GB equivale 4,194,304 KB
  2. Pasa a una división matemática por factor original constante del motor 32KB en base de bloques natos (Paging Values): 4194304 / 32 = Valor decimal: 131072
  3. Introduce con delicadeza en el campo interior textual blanco y guardarlo en el editor interno: 131072 dentro del bloque y atributo de nombre msExchESEParamCacheSizeMax que abrimos momentos antes en ADSI Edit.

Aprieta Guardar / Aceptar(OK). Como todos los ciclos primarios en un servidor en demanda; será mandatorio purgar en caliente o hacer relanzamiento el sub-servicio completo desde services.msc identificándolo como servicio principal oficial Microsoft Exchange Information Store (o equivalente). Notifique el evento pues expulsará la conectividad en todas las sedes o despachos vinculados de forma abrupta antes de que éste enlace nuevamente limitando exitosa o permanentemente tal cual el parámetro recién estructurado dentro la ram global en tu sistema interno para siempre.

Artículos Relacionados