Solución de problemas de replicación de carpetas públicas - Parte 4: consejos de Exchange Server 2007/2010
Artículo original publicado el lunes, 28 de noviembre de 2011
Entrada original en el blog estadounidense: 11 de enero de 2008
Hace dos años, publiqué una serie de artículos dividida en tres partes sobre cómo solucionar problemas de replicación de carpetas públicas. La parte 1 explicaba la replicación de datos nuevos, la parte 2 trataba la replicación de datos existentes, y la parte 3 abarcaba el proceso de eliminación de réplicas y algunos problemas comunes que encontramos con Exchange 2003. Con esta entrada, quiero actualizar esa serie de artículos para Exchange 2007.
En Exchange 2007, la replicación de carpetas públicas funciona como siempre lo ha hecho, básicamente. Siguen siendo válidos los pasos de solución de problemas de las tres primeras partes de la serie, pero las herramientas de administración han cambiado, y los problemas comunes que encontramos con Exchange 2007 son un poco distintos; esto es lo que voy a comentar.
Cambios en las herramientas de administración
El registro de eventos sigue siendo la mejor herramienta para filtrar los problemas de replicación y encontrar dónde está el fallo. En la parte 1, proponía aumentar el registro de Replicación entrante y Replicación saliente al nivel máximo. Sigo proponiéndolo pero, con Exchange 2007, se usa el cmdlet Set-EventLogLevel para configurar "MSExchangeIS\9001 Public\Replication Incoming Messages" y "MSExchangeIS\9001 Public\Replication Outgoing Messages" en el nivel Expert.
En la parte 2, expliqué cómo se usan las opciones Sincronizar jerarquía y Sincronizar contenido de ESM para forzar un mensaje de estado y para hacer que finalice el tiempo de espera de todas las entradas de reposición pendientes. Puede seguir haciéndolo en Exchange 2007 a través de los cmdlets Update-PublicFolderHierarchy y Update-PublicFolder. También están disponibles en la herramienta de administración de carpetas públicas de SP1, como Actualizar jerarquía cuando está seleccionada la raíz de Carpetas públicas y, como Actualizar contenido, cuando está seleccionada una carpeta pública determinada. Puede usarlas desde la línea de comandos, de modo que son mucho más flexibles que las opciones de Exchange 2003. Por ejemplo, ahora es muy fácil hacer que finalice el tiempo de espera de las entradas de reposición de todas las carpetas que contienen una réplica en su servidor Exchange 2007: solo hace falta usar el comando "Get-PublicFolderStatistics | Update-PublicFolder". Para hacer esto en Exchange 2003, eran necesarios muchos clics.
En la parte 3, describí cómo usar la vista de Instancias de carpetas públicas para comprobar si ha finalizado la eliminación de una réplica. En Exchange 2007, se usa el comando Get-PublicFolderStatistics para ver esa misma información.
Problemas comunes en Exchange 2007
El síntoma más habitual que he encontrado hasta ahora es un error del controlador del almacén. Por ejemplo, se envía una respuesta de reposición a un servidor Exchange 2007 pero, si se observa el registro de aplicaciones de 2007, el evento de replicación entrante nunca llega. El seguimiento de mensajes muestra que el mensaje de replicación llegó al servidor concentrador de transporte y, a continuación, se produjo un error en el controlador del almacén.
Puede ocurrir por diversos motivos y, afortunadamente, no suele ser muy difícil de solucionar. El mejor método para resolver este problema es usar el Seguimiento de canalización y el Seguimiento de conversión de contenido, disponibles en el servidor concentrador de transporte. Si ejecuta "Get-TransportServer | fl", verá varios parámetros relacionados:
PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Archivos de programa\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVIDOR01-IS@contoso.com
Para averiguar por qué se produce un error de la respuesta de reposición en el controlador del almacén, configure la PipelineTracingSenderAddress de modo que coincida con la dirección SMTP del almacén de carpetas públicas que envía la respuesta de reposición. A continuación, asigne a ContentConversionTracingEnabled el valor $true y, a PipelineTracingEnabled, el valor $true, y reproduzca el problema. Después, vaya a la carpeta que especifique la PipelineTracingPath. Allí debería encontrar una subcarpeta con el nombre ContentConversionTracing, y la carpeta InboundFailures dentro de ella. En la carpeta InboundFailures, verá un archivo EML que contiene el propio mensaje de replicación y un archivo TXT que incluye información sobre el error. El comienzo del archivo TXT suele dar pistas útiles sobre el motivo del error.
Por ejemplo, en algunos casos hemos observado este resultado en el archivo TXT:
Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories
Error = Element 0 in the multivalue property is invalid..
En este caso, el problema está en la propiedad Categories. Esto ocurre cuando la carpeta pública en cuestión contiene elementos en los que la propiedad Categories se ha dejado en blanco, por ejemplo, asignándole un solo espacio, en lugar de estar vacía realmente. Para comprobarlo, puede entrar en Outlook y elegir la opción de ver los elementos por Categoría. Verá que hay dos conjuntos de elementos diferentes con "None". Para corregir el problema, solo tiene que dejar vacía la Categoría de todos los elementos "None" en Outlook. Es posible que tenga que asignarles alguna otra categoría y, a continuación, volver a cambiarla a None. Cuando la propiedad Categories esté realmente vacía, solo tendrá un conjunto de elementos con "None", y los elementos se replicarán correctamente.
Otro ejemplo:
Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
Error = Email2AddrType is too long: maximum length is 9, actual length is 35..
En este caso, está indicando que el problema se encuentra en Email2AddrType. Descubrimos que, por alguna razón, se había rellenado con la dirección de correo electrónico completa en ciertos contactos, en lugar de contener solamente el tipo de dirección, como 'SMTP' o 'EX'. Al corregir esa propiedad, los elementos pudieron replicarse.
A veces, se produce un error en el controlador del almacén y no se identifica ninguna propiedad concreta como causa del problema; por ejemplo, en este resultado:
Microsoft.Exchange.Data.Storage.ConversionFailedException: Message content has become corrupted. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: Content conversion failed due to corrupt TNEF (violation status: 0x00000800)
Este es el error que aparece cuando el problema es el que se describe en KB 936000. Al aplicar la corrección en el servidor Exchange 2003 que está generando este mensaje de replicación, se corregirá ese problema.
El concepto que se debe recordar de todo esto es que Exchange 2007 realiza muchas validaciones de propiedades para evitar que los datos incorrectos entren en el almacén. Esto es bueno, pero puede evitar que los datos de las carpetas públicas de los servidores Exchange 2003 se repliquen hasta que se corrija el contenido en el servidor con 2003. ContentConversionTracing puede ayudar a identificar estos problemas y, a menudo, señala la propiedad exacta que los causa.
Hay otro problema común que se puede identificar con ContentConversionTracing, pero no lo provoca ningún problema real del contenido. El archivo TXT de la carpeta InboundFailures será como sigue:
Microsoft.Exchange.Data.Storage.ConversionFailedException: The content conversion limit has been exceeded.
at Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
at Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
at Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)
InboundConversionOptions:
- preferredCharset: iso-8859-1
- trustAsciiCharsets: True
- isSenderTrusted: False
- imceaResolveableDomain: contoso.com
- preserveReportBody: False
- clearCategories: True
- userADSession:
- recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
- clientSubmittedSecurely: False
- serverSubmittedSecurely: False
ConversionLimits:
- maxMimeTextHeaderLength: 2000
- maxMimeSubjectLength: 255
- maxSize: 2147483647
- maxMimeRecipients: 12288
- maxRecipientPropertyLength: 1000
- maxBodyPartsTotal: 250
- maxEmbeddedMessageDepth: 30
- exemptPFReplicationMessages: True
En primer lugar, observe que la primera línea señala que "The content conversion limit has been exceeded" (Se ha superado el límite de conversión de contenido). En general, los mensajes de replicación de carpetas públicas no tienen límite de tamaño ni restricciones similares; entonces, ¿por qué se produce este error en el mensaje? Vea que "isSenderTrusted" es False. Esto significa que el mensaje llegó a través de una conexión SMTP no autenticada. El servidor remitente no consiguió autenticarla o no lo intentó. Este problema es muy similar al que describí en la sección Problemas comunes de la parte 3, en el que un error de autenticación provoca un error en el verbo XEXCH50 de Exchange 2003. Como el servidor remitente no realizó la autenticación, el servidor Exchange 2007 aplica al mensaje los límites de tamaño habituales. Si se trata de un mensaje de replicación de contenido con más de 250 archivos adjuntos (no sería raro en una respuesta de reposición de contenido), se produce un error porque se supera el límite. Pasa a menudo cuando un administrador ha creado otro conector de recepción que no admite la autenticación, pero lo ha configurado de modo que escuche a la IP interna, en lugar de a la externa. Si no es este el motivo, es posible que tenga que usar una captura de Netmon para identificar el problema, como expliqué en la parte 3.
Conclusión
Con esto, debería quedar explicado todo lo necesario para identificar problemas de replicación de carpetas públicas en entornos con Exchange 2007. Todos los pasos de resolución de problemas anteriores siguen siendo válidos; la única diferencia es que han cambiado las herramientas administrativas y algunos problemas. ¡Espero que esto ayude!
Esta entrada de blog es una traducción. Encontrará el artículo original aquí: Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips