Exchange Queue & A Aumenta el tamaño de datos adjuntos desconcertante, duplicación de carpetas públicas etc.

Henrik Walther

P infraestructura de mensajería de nuestra organización se basa en Exchange Server 2007. Tenemos un límite de tamaño de mensajes relativamente estricto de 12 MB establecer a través de la organización.

Se ha observado un comportamiento extraño que parece estar relacionado con el tamaño de archivos adjuntos a un mensaje. Al enviar un mensaje de correo electrónico a un usuario externo, vamos a decir que, datos adjuntos 11MB, el mensaje se entregado al destinatario como se esperaba. Pero si se reenvía este mensaje (incluidos los datos adjuntos) al remitente de la red interna, el remitente obtiene un informe de no entrega (NDR), que indica que el mensaje es mayor que el límite de sistema actual o que el buzón del destinatario está lleno.

Después de tomar un vistazo cerrar el problema, podemos ver que en algún momento después de que el mensaje abandona la organización, aumenta el tamaño de los datos adjuntos por aproximadamente un 30 por ciento. La cuestión es, ¿por qué hacer adjunto tamaños aumentan al enviar y recibir mensajes de correo electrónico a través de Internet? ¿Y es más importante, este comportamiento esperado?

A la respuesta corta es Sí. Esto suele ser comportamiento esperado, no sólo para Exchange Server 2007, sino también para versiones anteriores de Exchange Server, así como cualquier otro sistema de mensajería que admite MIME (extensiones multipropósito de correo Internet) y utiliza base64 para codificar datos adjuntos. Cuando un usuario de Exchange interno envía un mensaje a un destinatario dentro de la organización de Exchange, el mensaje no requiere ninguna conversión de contenido. Esto significa que no verá el mensaje o datos adjuntos aumenten de tamaño cuando éstos se envíen. Los mensajes enviados a destinatarios externos, por otro lado, es posible que requieren conversión de contenido.

Un mensaje de SMTP estándar (también conocido como un mensaje de texto sin formato) consta de un sobre de mensaje y el contenido del mensaje, el encabezado de mensaje y el cuerpo del mensaje. Estos elementos se basan en texto de US-ASCII de 7 bits sin formato. Cuando un mensaje contiene elementos que no son texto US-ASCII sin formato, se deben codificar los elementos. Cuando se trabaja con dicha contenido que no sea de texto, incluidos los datos adjuntos, MIME se utiliza para codificar. Tanto Exchange 2007 y versiones anteriores de Exchange Server utilizan el algoritmo base64 para codificar datos adjuntos. Y el inconveniente de Base64 es que bloats los datos adjuntos por 33%.

En Exchange 2007, excepto cuando Outlook Web Access se utiliza, más relacionados con transporte conversión de contenido se realiza en el servidor de transporte del concentrador. Para obtener una explicación detallada, vea el tema "descripción conversión de contenido" en technet.microsoft.com/library/bb232174.

P están en el medio de una transición de Exchange 2003 a Exchange 2007. Todos los buzones de usuario se han movido a servidores de buzón de Exchange 2007, que han configurado mediante la replicación continua de clústeres (CCR). Actualmente se se replican todas las carpetas públicas desde nuestro servidor de carpetas públicas de Exchange 2003 heredado en un servidor de buzones en función de la CCR. Sin embargo, hemos descubierto durante las pruebas que cuando se produce una conmutación por error con pérdidas en el clúster CCR, la base de datos de carpetas públicas no se ponga en conexión en el otro nodo. No se también puede montar se manualmente después de la conmutación por error.

Tenemos un entorno de laboratorio que refleja nuestra infraestructura de Exchange 2007 en el entorno de producción y pruebas muestran que el problema se produce aquí también. No vemos este problema con cualquiera de las bases de datos de buzones en cualquiera de los clústeres CCR en que se produce una conmutación por error con pérdidas, por lo que parece relacionar estrictamente bases de datos en clústeres CCR de carpetas públicas. Puesto que desee conseguir redundancia es true para todos los bases de datos, incluidos la base de datos de carpetas públicas, ¿tiene cualquier visión de lo que causaría este comportamiento?

A los métodos de replicación utilizan por la CCR y por la replicación de carpetas públicas de Exchange 2007 son dos bestias muy diferentes. A causa de ello, no se recomienda que se combinan de varias bases de datos carpeta pública en una organización de Exchange con los servidores de buzones en función de CCR, si una de las bases de datos carpeta pública está alojada en un servidor de buzones en función de la CCR. Puede hacerlo realidad durante una transición, y el grupo de productos de Exchange admite con una base de datos alojado en un servidor de buzones en función de la CCR y, por ejemplo, un servidor de Exchange 2003 heredado de carpetas públicas. Pero es muy recomendable que quita la base de datos carpeta pública del servidor de buzones no basado en CCR ha replicado datos de carpeta pública después de todo.

Lo que está experimentando en su entorno de mensajería de Exchange es normal. Cuando se tienen varias bases de datos carpeta pública y una de ellas está alojada en un servidor de buzones en función de la CCR, la base de datos carpeta pública del servidor de buzones en función de la CCR no se pueden poner en conexión durante un (es decir, una interrupción no programada con pérdidas conmutación por error.

En realidad, la base de datos de carpetas públicas no se poner en línea antes del nodo anteriormente activo se abre nuevo. Además, todos los archivos de registro de transacciones para el grupo de almacenamiento en el que se aloja la base de datos de carpetas públicas deben estar disponibles.

Si esto no es una opción, debe ser la primera línea de defensa restaurar el almacén de carpetas públicas desde la última copia de seguridad buena, reproducir a través de los registros disponibles y reseed, a continuación, el otro nodo de la base de datos restaurada. Como alternativa, el almacén de carpetas públicas se puede crear desde el principio. En este caso, se debe recuperar el nodo activo original y debe crearse una nueva base de datos de carpetas públicas y hayan replicado de datos de carpetas públicas desde otro servidor de carpetas públicas en la organización de Exchange.

Lo que puede parecer extraño es que cuando se realiza una interrupción lossless (programada), se ponga en conexión la base de datos de carpetas públicas. Éste es comportamiento esperado. Para obtener más información consulte "clúster continua replicación y públicas carpeta Databases" en el " Planeamiento de la replicación continua de clúster."

P todos los servidores de buzón de nuestra infraestructura de mensajería de Exchange 2007, en función se configuran mediante CCR. Estamos muy satisfechos con la forma de CCR funciona, pero tiene una pregunta que esperamos que puede responder.

Cuando mantenimiento con conexión se ejecuta cada noche, una de las tareas es la desfragmentación en línea. ¿Cómo se garantizar que obtener desfragmentar las bases de datos en el nodo pasivo en un clúster CCR durante el mantenimiento con conexión?

A la desfragmentación en línea tarea, que elimina los elementos marcados para su eliminación y, a continuación, se activa el espacio usado por estos elementos en espacio en blanco, generará nuevos archivos de registro de transacciones durante el proceso. Los archivos de registro transacción generados en el nodo CCR activo se replicará en el nodo pasivo, lo que los cambios que se realiza a las bases de datos en el nodo pasivo, así.

Teniendo esto en cuenta, asegúrese de que programar la ventana de mantenimiento con conexión para que los no entre en conflicto con la ventana copia de seguridad, como esto obliga a la desfragmentación en línea para detener. No que la desfragmentación necesariamente tiene que realizar cada día, cada semana o incluso cada dos semanas para dicho propósito. En el pasado, orientación del grupo del producto Exchange especifica tener completar menos cada dos semanas de desfragmentación en línea. Pero que cambia con Exchange Server 2007 SP1, como entorno de cada organización es diferente. Para obtener más detalles en esta nueva orientación, vea la entrada de blog en el Blog del equipo de Microsoft Exchange.

P está planeando utilizar Exchange 2007 CCR para lograr la redundancia es true para nuestros servidores de buzón. Actualmente, buscas en cómo el transporte contenedor se utiliza combinado con CCR para asegurarse de que no se pierden durante una conmutación por error con pérdidas desde el nodo CCR activo en el nodo pasivo. ¿Sabe de cualquier transporte contenedor trampas que se deben tener en cuenta?

El transporte de un contenedor garantiza que tengan una pérdida de datos mínimos durante una conmutación por con pérdidas error de un nodo a otro en un servidor de buzones de Exchange 2007 que utiliza la CCR. Para ello, redelivering los mensajes que se han enviado recientemente al servidor buzón. Durante una conmutación por error con pérdidas, es probable real se perderán algunas transacciones de los archivos de registro y, debido de esto, datos reales así. Como se indicó, el transporte contenedor redelivers los mensajes que se han enviado recientemente en el servidor de buzones y lo que garantiza que se restauran datos perdidos durante el error con pérdidas. Sin embargo, ya que es sólo los mensajes que se entregan a través del servidor concentrador de transporte en el que el transporte contenedor reside, datos, como tareas y calendario los elementos creados cercano a la conmutación por error con pérdidas se perderán.

P está planeando actualmente una migración de una organización Exchange 2003 cross-forest a una organización Exchange 2007 en un nuevo bosque Active Directory. Ampliamente nos han estudiado la documentación de migración cross-forest " Cómo transición de un único bosque a entre bosques", que indica que se deben crear una confianza de bosque y no una confianza externa entre los bosques. ¿Por qué es lo que no se puede utilizar una confianza externa?

A aunque la documentación de Exchange 2007 de TechNet indica que se debe utilizar una confianza de bosque en lugar de una confianza externa, no significa que no puede usar una confianza externa. De hecho, una confianza externa funciona bien para una migración de Exchange cross-forest, pero hay un inconveniente. Debe especificar una cuenta con los permisos apropiados tener acceso a un controlador de dominio del bosque de confianza cuando se crea un buzón vinculado (consulte la figura 1 ), debido a que no se puede utilizar las credenciales de la ha iniciado, en el usuario sin importar qué permisos se han asignado.

Figura 1 especificación de una cuenta en la página de cuenta principal cuando se crea un buzón vinculado

P nuestra organización que se acaba transición a Exchange 2007, y hasta ahora estamos muy satisfechos con la nueva versión, con una posible excepción. Nuevo cuando se nos se utiliza Exchange 2003 SP2, pudimos configurar nuestro entorno de modo que se muestra el nombre sencillo mostrar de un buzón de usuario como remitente de un mensaje saliente. Para nuestro dismay, hemos no sido puede encontrar una característica similar en Exchange 2007. Por favor, no indique nos que esta característica es que faltan en Exchange 2007.

A esta característica era, de hecho, falta de RTM de Exchange 2007, hacia la derecha hasta Exchange 2007 SP1 informe actualización 4 (RU4) se lanzó volver en de 2008 de octubre. Con Service Pack 1 RU4, es posible una vez más, igual que con Exchange 2003 SP2, configurar Exchange para mostrar el nombre para mostrar simple en los mensajes salientes. Esta tarea puede realizarse mediante el cmdlet Set-RemoteDomain de Windows PowerShell con el parámetro –Use­SimpleDisplayName. Por ejemplo, para habilitar los nombres para mostrar simple en los mensajes salientes que se envían al dominio contoso.com, utilice el comando que se muestra en la figura 2 .

La Figura 2 los nombres de presentación simple con para mensajes salientes

P ¿cuál es la recomendación para desfragmentar las copias de base de datos en el nodo pasivo en un servidor de buzón de Exchange 2007-CCR-basado? ¿Se Exchange se convierten en preocupe si las bases de datos de uno de los nodos de la CCR se desfragmenta, pero no los de los demás nodos?

A si es necesaria una desfragmentación sin conexión, se deben siempre realizarse en el nodo activo del clúster CCR, nunca en el nodo pasivo. Tenga en cuenta también que si lo hace una desfragmentación sin conexión de uno o más bases de datos en el nodo activo, una reinicialización completa de las bases de datos determinados en el nodo pasivo se requiere.

Esto significa, por ejemplo, que, si tiene una base de datos 200GB (cuando se utiliza la CCR, el tamaño recomendado de base de datos es 200GB al replicar a través de una red de 1 GB), tardará varias horas para desfragmentar, (una buena regla general es 2 a 4 GB por hora). Pero una vez finalizado el proceso de desfragmentación, también deberá replicar 200GB de datos en el nodo pasivo. Si archivo trasvase se produce a través de la red pública, esto podría afectar al rendimiento de red general experimentado por los usuarios finales.

En la mayoría de los casos, el motivo para realizar una desfragmentación off­line es quitar los espacios en blanco en la base de datos para reducir el tamaño de la base de datos. Pero esto es rara vez es necesario ya que se reutilizar un espacio en blanco antes de una base de datos crece más. ¿Y realmente no importa si dispone de espacio disponible en la base de datos o en el disco,?

Si tiene varios gigabytes de espacio en blanco en una base de datos y desea quitarlo, un método mucho mejor es mover todos los buzones de la base de datos y en una nueva.

Henrik Walther es un principal de certificado de Microsoft: Exchange 2007 y MVP de Exchange con más de 14 años de experiencia en el negocio de TI. Trabaja como un arquitecto de tecnología de Interprise Consulting (un socio de oro de Microsoft en Dinamarca) y como un escritor técnico para Biblioso Corporation (una compañía de Estados Unidos que está especializada en servicios de documentación y localización administrados).