Dando soporte y consultoría uno tiene la oportunidad de trabajar con muchas instalaciones de Exchange y como con todo producto se pueden presentar problemas, en algunos casos consecuencia de una actualización, en otros incompatibilidad con algún tipo de software, etc. Estas cosas pasan, pero lo que no queremos que suceda es que el problema sea consecuencia de un error de quien administra o implementa la plataforma, frente a este caso realmente podríamos estar en un aprieto y así sea una simple omisión nos puede costar caro.
Recuerdo hace algunos años, cuando el shell de Exchange era toda una novedad, en un cliente decidieron habilitar un buzón para todos los usuarios de la organización, al tiempo al revisar la cantidad de CAL (licencias de acceso de cliente) requeridas, el administrador se dio cuenta que figuraban muchas más en relación a usuarios que había en la empresa. Al profundizar en la situación el tema estaba en que se habían habilitado buzones a cuentas de servicio.
Al ver esto el admin decidió experimentar con el comando Remove-Mailbox (tenía sentido, quería eliminar buzones) para toda la OU donde se encontraban estas cuentas. Al rato empezaron a caer servicios, a partir de esto se notó que las cuentas de servicio no estaban funcionando y para sorpresa del administrador, estas ya no existían en Active Directory. Ya en ese punto estaba claro que el Remove-Mailbox no solo eliminó buzones, sino que también la cuenta de usuario.
Por fuera de que se debería haber usado Disable-Mailbox en lugar de Remove-Mailbox y de lo confuso que pueden resultar estos comandos el punto está en que este es el tipo de situaciones que trabajando con Exchange no queremos tener que pasar y sin llegar a este tipo de “tragedias” hay errores típicos que debemos manejar, comprender y evitar.
En este recurso compilo 7 errores que trabajando con Exchange no vas a querer cometer. Estos no tienen ningún orden en particular y en menor o mayor medida todos terminan impactando de algún modo el servicio.
ERROR #1. Dimensionar incorrectamente la unidad “C:” en Exchange
Este es un error que se encuentra con frecuencia y usualmente cuando se nota ya es demasiado tarde, se acabó el espacio en disco y los usuarios están reportando problemas con el correo.
Algunas interrogantes en este sentido:
- Qué hacer con la unidad C: en Exchange?
- De qué tamaño tendría que ser esta unidad?
Esto es algo a evaluar en cada instalación de Exchange. Si se dimensiona incorrectamente la unidad C: poco importa como haya quedado configurado el servidor.
De forma predeterminada, qué información encontramos en la unidad C: de un servidor con Exchange?
Por mencionar los titulares de mayor relevancia:
- Sistema operativo
- Archivo de Paginación
- Archivos de programa
- Exchange
- Base de transporte
- Base de datos predeterminada y logs de transacciones
- Logs de protocolo y de diagnóstico
No es poca cosa y ocupa una buena cantidad de espacio.
En muchas empresas uno encuentra prácticas donde por ejemplo las aplicaciones deben ser instaladas en unidades separadas a la del sistema operativo incluyendo el archivo de paginación. Cada uno en su propia unidad dedicada. Si bien esto no está ni “bien” ni “mal” la realidad es que en la mayoría de los casos no sería necesario. La idea es seguir las mejores prácticas y una de ellas está asociada a la simplificación, cuanto más simple sea la implementación más fácil de mantener.
Dicho esto, empecemos por el archivo de paginación, la recomendación es configurarlo de la siguiente manera:
- Estático
- Mínimo y máximo en 1.5 de la memoria RAM. Por ejemplo en un servidor con 16GB de RAM el archivo de paginación tendría que ser de 24 GB
- No exceder los 32778 MB. Por ejemplo en un servidor con 48GB de RAM el archivo de paginación sería de 32778 MB (32GB + 10MB)
En cuanto al sistema operativo, si por ejemplo pensamos en una instalación de Windows Server 2012 R2, Microsoft menciona un mínimo de 32GB con varias salvedades, no hay un tamaño recomendado, en este caso no recomendaría menos de 80 GB para un sistema en producción, esto tendría que ser suficiente para el sistema operativo y actualizaciones que vayan surgiendo.
A nivel de Archivos de Programa, debemos conocer los requerimientos de cada aplicación que vayamos a instalar por fuera de Exchange, por ejemplo agente de backup, antivirus, etc.
En particular Exchange tiene un requerimiento de al menos 30GB en la unidad de instalación, 500MB adicionales para paquetes de lenguaje de mensajería unificada (UM), en adición para la base de transporte (ver más adelante). En este caso podríamos considerar que dedicar 40 GB serían suficientes. Esto incluso consideraría los logs de protocolo y de diagnóstico.
El caso de la base predeterminada la realidad es que no tiene nada que hacer en la unidad C:, los datos de Exchange como bases y logs deberían estar en unidades formateadas en 64k. Este es un error bastante frecuente, ubicar las bases y logs en unidades con el formato predeterminado (que no es 64k). En definitiva, esta base debe ser movida.
Por último, base de transporte, en esta se aloja información de colas de mensajes, Microsoft indica que la unidad donde se encuentre esta base alojada debe tener al menos 500MB libres. El tema es que esto no nos dice que tamaño puede tener esta base, para saber esto tenemos que hacer varias cuentas incluyendo ciertos requerimientos como si se cuenta con alta disponibilidad o no. Para hacer este cálculo conviene usar la calculadora de requerimientos de Exchange.
Como el no usar la calculadora de requerimientos de Exchange es otro de los errores incluidos en este recurso no voy a entrar en detalle pero voy a dar un tamaño a modo de ejemplo para el caso de una organización con 2 servidores con Exchange con opciones de Safety net y expiración de mensajes con valores predeterminados (2 días), 500 usuarios y un perfil de mensajería con las siguientes características:
- 100 mensajes enviados / recibidos por día
- 150KB tamaño promedio de mensaje
Espacio requerido para la base de transporte: 57GB
Para el cálculo vamos a usar 60GB.
Así que tenemos:
- Sistema Operativo: 80GB
- Archivo de Paginación: 32GB (+10MB)
- Instalación de Exchange + Logs de protocolo y diagnóstico: 40GB
- Base de transporte (ejemplo 500 usuarios en DAG de 2 nodos): 60GB
Total de espacio requerido para la unidad C: 212GB
En base a esto diría de manejar un “piso” de 212GB para la unidad “C” del servidor. En caso de asignar una cantidad de espacio menor sería necesario monitorear más de cerca esta unidad, depurar logs con mayor frecuencia, etc.
ERROR #2. Adivinar los recursos necesarios para Exchange
Esto pasa mucho cuando se viene de una versión “vieja” de Exchange. Se asumen cosas y se hace una estimación de recursos en base a como funcionaba la versión anterior.
Las versiones más actuales de Exchange (2013 / 2016) requieren más memoria RAM y procesador que versiones anteriores. Uno podría hacer cálculos manuales para entender bien los requerimientos pero la realidad es que no es tan simple como puede parecer. La recomendación en todos los casos es usar la calculadora de requerimientos de Exchange.
Este error se complementa con el de dimensionamiento de la unidad C:, pero en este caso tengo en mente lo siguiente:
- Cantidad de procesadores
- Memoria RAM
- Espacio para bases de datos y logs
- IOPS requeridas a nivel de almacenamiento
El detalle de los cálculos manuales está documentado en el blog oficial del equipo de producto de Exchange, sin embargo es mucho más sencillo usar directamente la calculadora de requerimientos.
En definitiva, la calculadora de Exchange nos permite minimizar los errores a nivel de dimensionamiento de la solución y en consecuencia asegurar que el sistema este diseñado para soportar los requerimientos de la organización.
ERROR #3. Configuración de Autodiscover
Básicamente Autodiscover es el servicio que provee la información de configuración necesaria a los clientes. En particular los usuarios estarán interactuando con este servicio al conectarse desde dispositivos móviles (usando Activesync o Outlook para IOS o Android en modo no manual) o desde el cliente de escritorio Outlook (MAC / PC).
De forma predeterminada al instalar Exchange, solo se incluye configuración interna apuntando al nombre del servidor lo que usualmente deriva en errores de certificado y problemas al acceder desde Internet. Si solo se accede al correo internamente no sería tan problemático pero si accedemos al correo desde fuera de la red usando alguno de los clientes mencionados esto cobra vital importancia. Si bien no sería el único escenario para Autodiscover es uno de los más comunes.
La configuración de Autodiscover implica considerar varios aspectos:
1. Configuración de directorios virtuales y servicios web en general a nivel de Exchange (Outlook Anywhere, MAPI sobre HTTPS, ActiveSync, EWS, OAB)
2. Configuración de registros en DNS (los clientes no unidos al dominio o que acceden desde internet localizan este servicio en base a registros DNS, los clientes unidos al dominio lo hacen en base a una consulta al directorio, específicamente al SCP o Service Connection Point)
3. Configuración apropiada del certificado
Una vez configurado el servicio y todas sus dependencias es conveniente validar la conectividad desde el siguiente sitio:
ERROR #4. Configuración de certificado para Exchange
En este sentido, el error más típico es dejar el certificado predeterminado (auto firmado) o cuestionarse si comprar un certificado público o usar uno emitido por una CA interna.
A largo plazo el no comprar un certificado público genera más trabajo y dolores de cabeza que pagar el costo anual de un certificado de terceros como por ejemplo de Digicert o Godaddy.
Si bien es cierto que en algún caso muy específico puede tener sentido usar un certificado interno, esto en general no es una buena práctica.
Microsoft deja bien claro cuáles son las buenas prácticas asociadas al tipo de certificado a utilizar en Exchange (a continuación fragmento obtenido de Technet usando la traducción automática):
Procedimiento recomendado: Usar un certificado de terceros de confianza. A fin de evitar que los clientes reciban errores relativos a certificados que no son de confianza, el certificado que el servidor de Exchange use debe proceder de alguien en quien el cliente confíe. Si bien la mayoría de los clientes se puede configurar de forma que confíe en cualquier certificado o emisor de certificado, resulta más sencillo usar un certificado de terceros de confianza en el servidor de Exchange. Esto es así porque casi todos los clientes ya confían en sus certificados raíz. Existen varios emisores de certificados de terceros que ofrecen certificados configurados expresamente para Exchange.
Artículo original de Microsoft:
Por mi parte, dada la confusión que genera este tema y la cantidad de casos de soporte relacionados, hace algún tiempo escribí un ebook (gratuito) dedicado a Certificados en Exchange.
En este ebook vas a encontrar todo el detalle necesario para evitar complicaciones a largo plazo incluyendo temas como:
- Selección de tipo de certificado
- Certificado auto firmado vs Interno vs Público
- Diagrama de flujo de decisión
- Configuración general de certificados
- Mejores prácticas
- Errores típicos de configuración
Acceso a ebook de Guía de certificados para Exchange
ERROR #5. Olvidar la renovación del certificado de Exchange
Este puede parecer un simple olvido pero es uno que impacta inmediatamente en el usuario final. Todos los usuarios recibiendo errores de certificado, nada divertido para el administrador de Exchange.
Si bien el Centro de Administración de Exchange (EAC) incluye una notificación automática, es muy fácil pasarla por alto y en versiones anteriores esta no existía.
Una de las cosas que hago a nivel de Exchange es el mantenimiento en varias organizaciones, realmente no estoy pendiente de cuando se vence un certificado, por este motivo tengo un recordatorio configurado en Outlook y un par de semanas antes del vencimiento me aparece la notificación, de esta manera puedo manejar el tema de forma proactiva y sin presión.
En definitiva, sea con Outlook u otro mecanismo, configurar un recordatorio para la renovación del certificado de seguridad.
ERROR #6. Configurar un DNS público en la tarjeta de red de Exchange
Este error lo he visto a todo nivel, configurar un DNS público (externo) en la placa de red del servidor con Exchange (o por ejemplo en controladores de dominio) va a tener un impacto negativo.
Esto en general se hace con la intención de que se resuelvan nombres internos usando un servidor interno y nombres externos usando un DNS de un ISP por ejemplo, pero esta no es la forma y deriva en todo tipo de errores.
En qué caso podríamos necesitar que un servidor con Exchange resuelva nombres externos (internet) ?
Uno de los casos más comunes es cuando el servidor con Exchange envía correo directamente hacia Internet sin usar un Smarthost. En este escenario Exchange debe ser capaz de resolver los registros MX de otras organizaciones con la finalidad de localizar los servidores que proveen servicios de correo.
Si Exchange envía correo directo hacia Internet tenemos 2 opciones:
- Configurar los servidores DNS internos para que puedan resolver nombres externos. Esto se puede hacer configurando Reenviadores (Forwarders) o Root Hints.
- Configurar en las propiedades del servidor un DNS externo específico (a nivel de configuración de Exchange). En caso de Exchange 2013 / 2016 esto lo encontramos en el EAC – Servidores:
ERROR #7. Exclusiones de antivirus para Exchange
La configuración de las exclusiones en el antivirus de sistema de archivos en el servidor con Exchange es de vital importancia para el correcto funcionamiento.
El no configurar excepciones a este nivel deriva en distintos errores que pueden ir desde problemas de rendimiento, errores al activar una base en otro servidor (si se encuentra replicada en DAG), hasta corrupción entre otros.
Microsoft tiene un documento extenso dedicado a este tema, la recomendación es trabajar con el proveedor de la solución de Antivirus y asegurarse que se encuentren configuradas todas las excepciones, esto incluye rutas, extensiones y procesos:
- Exclusiones de antivirus de sistema de archivos para Exchange 2013
- Exclusiones de antivirus de sistema de archivos para Exchange 2016
Este es un error que me he encontrado muchas veces trabajando con Exchange, en general el proveedor del Antivirus indica que está todo configurado y en el servidor encontramos un comportamiento extraño, archivos bloqueados, etc.
En principio cuando se presenta esta situación no queda otra que “probar” que el problema no viene por el lado de Exchange sino que por el lado del Antivirus, una de las opciones que tenemos para esto es usar Process monitor, esta herramienta nos permite ver cómo están trabajando los distintos procesos. Si vemos el proceso del antivirus escaneando componentes de Exchange podríamos decir que seguramente el problema venga por ahí.
Con esto llegamos al final del artículo, por más información teórica y práctica sobre Exchange, ver el siguiente recurso para miembros VIP del sitio (videos de entrenamiento):