Este es el primer artículo de la serie de Preguntas y Respuestas.
En este “PR1” vamos a abordar las siguientes consultas (entre paréntesis las iniciales de quien envió la pregunta):
- (MP) En qué medida es bueno ir eliminando los ficheros de log diarios? Hay manera automatizada desde la configuración de Exchange de hacerlo?
- (MP) Es recomendable separar las cuentas en diferentes bases de datos a fin de que el fichero edb no crezca demasiado?
- (VR) No sé de cuanto es exactamente el límite de las BD en Exchange, depende del disco duro? o tienen un tamaño especificado?
- (CR) Qué diferencias hay entre una dirección X.400 y el LegacyExchangeDN?
- (CR) Por qué cuando haces una migración Cross-Forest, tienes que crear un contacto en el bosque anterior (del cuál migras) y tiene que apuntar a una “ExternalEmailAddress”?
1. (MP) En qué medida es bueno ir eliminando los ficheros de log diarios? Hay manera automatizada desde la configuración de Exchange de hacerlo?
Los archivos de logs de transacciones se acumulan de forma predeterminada hasta ocupar todo el espacio en disco. Por fuera de esto, los logs no deberían ser eliminados manualmente.
Para manejar esta situación usualmente tenemos 2 opciones:
- Realizar un respaldo full (y posteriores full o incrementales)
- Habilitar Circular Logging (registro circular)
En general la recomendación es la opción 1, por este motivo en muchas empresas se dan cuenta que el respaldo no esta funcionando cuando se quedan sin correo.
Por qué se quedan sin correo?
Porque las bases se desmontan por falta de espacio en la unidad de logs.
Como alternativa podemos ir por la opción 2 y habilitar el registro circular. Con circular logging habilitado se utiliza un juego de logs que en lugar de acumularse se sobreescriben.
En principio lo ideal es no utilizar circular logging porque esto sobreescribe la secuencia de logs. Mantener esta secuencia puede ser muy importante para determinados escenarios de restauración. En definitiva salvo casos bien específicos la recomendación es no habilitar esta característica.
De no haber requerimientos muy particulares lo más conveniente es contar con una buena estrategia de respaldos ya que de esta manera los logs son truncados automáticamente en el proceso. En adición se debe verificar cada tanto que realmente esten funcionando.
A tener en consideración que en entornos con DAG la replicación debe estar funcionando correctamente para que los logs se depuren, ya sea que se opte por usar respaldos o habilitar circular logging.
Por más info sobre respaldo y circular logging ver la sesión de entrenamiento de backup.
2. (MP) Es recomendable separar las cuentas en diferentes bases de datos a fin de que el fichero edb no crezca demasiado?
Podríamos decir que esto sería una buena práctica pero todo depende de los requerimientos.
En particular, esto depende principalmente de 2 cosas:
- Requerimientos asociados a los tiempos de respaldo y restauración. Por mencionar un ejemplo simplificado, si existe un requerimiento que indica que las bases de datos deben poder ser restauradas en menos de 2 horas y el dispositivo que se utiliza para restaurar puede hacerlo a un máximo de 50 GB por hora, es claro que no podríamos dejar que una base de datos alcance los 100GB. En adición tendríamos que considerar el tiempo que pasa entre que se detecta el problema y se pone todo el proceso en marcha, etc.
- Cantidad de bases de datos soportadas según la versión. La versión Standard de Exchange (2010/2013/2016) soporta un máximo de 5, mientras que la Enterprise un máximo de 100.
En muchos casos también el separar las bases puede simplificar desde el punto de vista administrativo, por ejemplo creando una base de datos dedicada a cada área o separando usuarios convencionales de usuarios “VIP” y en base a esto asignar cuotas y limites dependiendo del rol.
En definitiva, cómo realizar la separación y distribución va a depender de los requerimientos, pero en términos generales teniendo en cuenta lo mencionado es preferible manejar múltiples bases chicas que manejar una base muy grande.
3. (VR) No sé de cuanto es exactamente el límite de las BD en Exchange, depende del disco duro? o tienen un tamaño especificado?
En Exchange 2010, 2013 y 2016 el tamaño máximo de base de datos va a depender de la versión:
- La versión Standard de Exchange de forma predeterminada soporta un tamaño máximo de base de datos de 1TB (1024GB). Mediante la edición del registro es posible modificar este valor pero con varias limitantes por lo que en principio no sería recomendado.
- La versión Enterprise de Exchange no tiene un límite específico pero se estima aproximadamente en 16TB.
4. (CR) Qué diferencias hay entre una dirección X.400 y el LegacyExchangeDN?
Este tema tiene raíz en la época en la que Exchange utilizaba su propio directorio (no Active Directory).
X.400
Por aquel entonces el mecanismo nativo de transporte se basaba en X400 (en lugar de SMTP), por lo que se utilizaban direcciones de tipo X.400. A diferencia de una dirección SMTP que utiliza un formato alias «@» dominio de correo, las direcciones de tipo X400 se componen de varios elementos incluyendo país y organización entre otros.
Los destinatarios de correo eran identificados por Exchange en base a un atributo denominado «obj-dist-name» (nombre distinguido). El obj-dist-name guardaba la ruta del objeto dentro del directorio.
Un destinatario a su vez en este caso tendría al menos una dirección de tipo X.400.
Sobre X.500 y mensajes de rebote (NDR)
Los clientes de correo como Outlook guardan en cache el identificador interno en lugar de la dirección X400. Entonces si por algun motivo el atributo Obj-Dist-Name cambia, cuando un cliente responde un correo «viejo» al no poder localizarse un objeto con el Obj-Dist-Name que se usó en el mensaje original se genera un NDR.
Las direcciones X.500 resuelven esta situación.
Si se modifica el Obj-Dist-Name de un objeto, simplemente se agrega una dirección de tipo X500 con el valor anterior. De esta manera este objeto puede ser encontrado en base al Obj-Dist-Name o las direcciones X500 que tenga.
Sobre LegacyExchangeDN
A partir de Exchange 2000 se empieza usar Active Directory como directorio.
Por cuestiones de compatibilidad era necesario almacenar en algun lado el valor de nombre distinguido usado en el directorio de Exchange para localizar objetos. Para esto utilizamos el atributo LegacyExchangeDN.
Lo mismo mencionado anteriormente en relación al Obj-Dist-Name aplica al caso de LegacyExchangeDN.
O sea que si el LegacyExchangeDN por algún motivo cambia, es necesario agregar una dirección X500 con el LegacyExchangeDN anterior (ver ejemplo con Exchange 2010).
SMTP, X.400 y X.500
Hasta Exchange 2003 se mantuvo soporte completo para X.400, incluso se asignaban direcciones X400 de forma predeterminada.
Por este motivo si venimos de versiones viejas de Exchange podemos encontrar usuarios con direcciones X400 en adición a SMTP.
Se pueden eliminar las direcciones X.400?
Salvo algún caso muy excepcional, la respuesta es si, se pueden eliminar las direcciones X400 sin inconvenientes. Exchange no las utiliza.
Se pueden eliminar las direcciones X.500?
Si bien como mecanismo de transporte ya hace tiempo que usamos SMTP, internamente para localizar objetos se usan el LegacyExchangeDN y las direcciones X.500. A diferencia de las direcciones X400, en el caso de las X.500 no necesariamente podremos eliminarlas, esto va a depender de si se siguen utilizando o no.
En general agregamos los X500 asociados a un LegacyExchangeDN más antiguo (probablemente por una migración). Con esto evitamos los NDR cuando se responden correos viejos o se utiliza el cache de nombres de un cliente de correo. Esto en principio podríamos decir que sería temporal ya que con el paso del tiempo la tendencia sería que se utilicen los nuevos valores.
En definitiva, en algunos casos se puede eliminar el X.500, en otros no. Antes de proceder sería necesario entender bien el escenario.
5. (CR) Por qué cuando haces una migración Cross-Forest, tienes que crear un contacto en el bosque anterior (del cuál migras) y tiene que apuntar a una “ExternalEmailAddress”?
Ver primero la respuesta del punto 4
En general uno escucha sobre X500 y LegacyExchangeDN dentro del contexto de una migración de Exchange.
Al migrar un destinatario a un nuevo bosque, el LegacyExchangeDN cambia. Dado que Exchange lo utiliza internamente para localizar objetos, cuando alguien por ejemplo responde un correo enviado antes de la migración (o sea con el LegacyExchangeDN anterior) esto va a generar un NDR.
Qué podemos hacer para evitar estos NDR?
Tenemos varias opciones, pero el objetivo en todos los casos es el mismo: poder localizar un objeto con el LegacyExchangeDN correspondiente.
En un escenario de migración entre bosques, dependiendo de la estrategia, una de las opciones puede ser crear un contacto con una dirección de correo externa (ExternalEmailAddress) apuntando a la organización de Exchange del nuevo bosque.
Este contacto tiene un LegacyExchangeDN distinto al que estuvo asociado originalmente con el usuario antes de ser migrado, por lo que debemos conseguir que cuando un cliente de correo ya sea respondiendo un correo viejo (con el LegacyExchangeDN del usuario antes de ser migrado) o utilizando el cache de nombres, pueda ubicar el destinatario en cuestión. Para esto le agregamos al contacto creado en el «bosque viejo» una dirección X500 que incluya el LegacyExchangeDN original del usuario migrado.
De esta manera entre otras cosas, al responder un correo anterior a la migración se encuentra el LegacyExchangeDN usando el X500 del contacto, posteriormente al tener una dirección de correo externa se envia el correo a la nueva organización.
Así que dejamos por acá este primer artículo, deja tus comentarios más abajo si te queda alguna duda.
Si tenés alguna consulta sobre Exchange y querés que las respuestas sean publicadas en el sitio podes suscribirte y responder el correo de bienvenida con tu pregunta.
Semanalmente se van a ir respondiendo las de mayor interés.
Deja una respuesta