Recipient Update Service en Exchange 2000 y Exchange 2003 - Part II

Recipient Update Service en Exchange 2000 y Exchange 2003

Parte II – Seguimiento de problemas

Por: Daniel Alberto Seveso

La idea de esta serie es proveer información acerca de cómo identificar problemas en el componente “Recipient Update Service” (de aquí en adelante identificado por su sigla en inglés RUS. En la Parte I, hemos cubierto conceptos básicos sobre el servicio. En este artículo cubriremos el seguimiento de problemas (troubleshooting).

Los síntomas más comunes que puede presentar el servicio de RUS, son los siguientes: a) que las direcciones de correo (proxyaddresses) no son configuradas a los objetos mailbox-enabled, b) que tome mucho tiempo en estampar las direcciones o c) que los objetos sean configurados con direcciones incorrectas.

¿Que estrategia podemos usar para un efectivo seguimiento de un problema de RUS?

- Trabajar en una instancia de RUS en particular en caso de existir más de una (configurar el Update interval de las instancias que no vamos a investigar en “Never run”)

- Aumentar el Diagnostic Logging en el servidor de Exchange

- Realizar el seguimiento con un usuario nuevo para las pruebas

- No utilizar la opción “Rebuild” como método de seguimiento, ya que esta opción se comporta en forma similar a “Update” con la diferencia que actualizará todos los objetos del directorio y tomará mucho más tiempo en finalizar.

- Realizar las pruebas directamente en el controlador de dominio (en adelante “DC”) configurado en el RUS para evitar demoras de replicación.

- Revisar el Application Log del Event Viewer en el servidor de Exchange revisando las consultas y acciones del servicio.

- Verificar cuantos tipos de direcciones electrónicas (o proxy address generator) existen en la organización, revisando las Recipient Policies (por ejemplo: SMTP, X400, CCMAIL, RFAX, NOTES, etc.)

- Tomar acciones para descartar problemas de red (como por ejemplo desactivar “Teaming” o configurar la velocidad de Switches y tarjetas de red a velocidad fija en lugar de “Autosense”.

Luego de haber determinado el servidor de Exchange donde corre el servicio de RUS que queremos revisar, aumentamos el tamaño del Application Log del servidor si es necesario para estar seguros de no perder eventos, y aumentamos el Diagnostic Logging al máximo según la siguiente tabla:

¿Cuáles son los problemas más comunes que puede experimentar el servicio de RUS?

- Problema con permisos al acceder a Active Directory, comúnmente cuando tenemos ambientes multi-dominio

- Generadores de direcciones con problemas o inexistentes (de Microsoft o de terceros) pueden evitar la configuración de todas las direcciones electrónicas definidas en las Recipient policies

- Filtros mal definidos en las Recipient policies

- Falla en la comunicación con los DCs (problemas de red)

- Problemas relacionados con el componente de acceso al directorio (DSAccess)

- Defecto de código o BUGs en el componente

¿Como podemos seguir los pasos del RUS?

Lo primero es aislar cual es el servidor de RUS que presenta el problema. Si solamente hay un servidor, no tenemos que preocuparnos por esto. Si han leído la Parte I de este artículo, será fácil ahora determinar cual instancia es la que tiene problemas. Primero debemos preguntarnos ¿en que dominio se encuentran los usuarios del problema?, o ¿sucede para los objetos en la partición de configuración? En caso que suceda para objetos de dominio, puede que tengamos varias instancias de RUS corriendo para ese dominio, por lo que tendremos (si aún no lo sabemos) que ir deshabilitando las instancias y ver cual es la que tiene problemas. Para inhabilitar una instancia de RUS, simplemente configuramos el “Update Interval: ” en las propiedades de la instancia a “Never run” y tratamos de inducir el problema utilizando la instancia activa. Una vez que identificamos la instancia con problemas, también habremos identificado el servidor de RUS y el DC asociado a esa instancia.

Si el problema lo tienen objetos en la partición de configuración, (por ejemplo objetos de Public Folder Store) la instancia a trabajar será la “Recipient Update Service (Enterprise Configuration)”. En este artículo discutiremos problemas para objetos de dominio que son los más comunes.

Para inducir el problema, recomiendo utilizar un nuevo objeto (por ejemplo un nuevo usuario) en lugar de usar un objeto existente. Puede que sea necesario hacer diferentes pruebas, así que estén preparados para crear varios usuarios. Usar números correlativos para el nombre cuando creamos más de un usuario suele ser buena idea.

Comencemos desde el principio…

Dijimos que RUS está implementado en el módulo Abv_dg.dll que se carga dentro del servicio MSExchangeSA. Cuando iniciamos el servicio de MSExchangeSA, RUS tiene que iniciar y hacer un “descubrimiento” de su ambiente. Este descubrimiento le permite saber a RUS:

- Cuantas instancias de RUS hay en la organización

- Si alguna de ellas debe ser manejada por si mismo

- La configuración de dicha instancia

- Dominio a cargo

- Controlador de dominio a conectarse

Esta es la secuencia de eventos durante el “descubrimiento” (algunos eventos accesorios se han omitido por claridad):

En este punto y con estos eventos, podemos asegurar que:

a) RUS inició correctamente

b) El RUS en el servidor local tiene una instancia asociada de la cual es responsable

c) RUS pudo leer la configuración de los objetos de RUS en Active Directory.

Algunos problemas que pueden suceder a este punto incluyen:

I) Que Abv_dg.dll no pueda ser cargada por MSExchangeSA, por problemas de corrupción, inconsistencia de versiones o problemas de disco.

II) Que Abv_dg.dll no pueda leer la información de los objetos de RUS en el directorio (partición de configuración en Active Directory) por falta de permisos, problema de acceso al DC, o problemas en la configuración de DSAccess en el servidor de Exchange.

III) Que algunas de las propiedades leídas de los objetos en Recipient Policies o System Policies no sean correctas

IV) Que problemas de resolución de nombres impidan resolver nombre de servidores en las propiedades de RUS

Cualquiera de estos problemas, causará que RUS no pueda actualizar los atributos a los objetos a su cargo en Active Directory.

Nota: Abv_dg.dll no corre en servidores “Front End”, por lo tanto, no verán los eventos anteriores, inclusive el 9008 si el servidor está configurado como Front End Server.

OK, RUS ya conoce el ambiente… ¿Cómo RUS determina que objetos procesar?

RUS procesa los objetos en base al atributo USNChanged cada vez que un ciclo de actualización se dispara. El atributo USNChanged contiene un valor que representa el número de cambio en Active Directory en el DC local. El número de cambio se actualiza en el DC local cada vez que un objeto se crea o es modificado y el valor se graba en el la propiedad USNChanged del objeto modificado o creado. RUS recuerda cual fue el último USNChanged procesado en el DC asociado, y procesará desde ese número hacia delante en el próximo ciclo.

Como vimos en la Parte I, varios de los atributos son configurados por RUS en forma condicional, es por esto que siempre conviene probar con un nuevo objeto en lugar de modificar uno existente para aumentar su USNChanged y ser considerado por RUS.

Luego de haber creado un nuevo objeto en las condiciones del problema (por ejemplo un usuario “test1”), podemos usar LDP.exe, ADSIEDIT.msc u otra herramienta compatible con LDAP versión 3 para consultar la propiedad USNChanged del objeto de prueba. Una vez que tenemos el valor de USNChanged, podemos consultar el log de aplicaciones y determinar exactamente cuando comienza el proceso de actualización de ese objeto.

El RUS de dominio, utiliza la consulta definida en el siguiente ejemplo para consultar por cambios:

En este punto y con estos eventos, podemos asegurar que:

a) RUS está detectando cambios en el dominio 'DC=mylab,DC=com'

b) RUS ha detectado al menos un objeto con cambios para procesar (seguramente nuestro usuario “test1”)

Algunos problemas que pueden suceder a este punto incluyen:

I) Que el evento 8012 no sea registrado. Significa que tenemos un problema con el DC, quien no devuelve el resultado de la consulta.

II) Que el evento 8012 devuelva “0 Objects” como resultado, sabiendo, por el rango de USNChanged, que debería haber retornado nuestro objeto de prueba “test1”. Este caso puede ocurrir cuando Exchange no tiene permisos para acceder a los objetos del dominio consultado. Los permisos de las cuentas de Exchange a los diferentes dominios es otorgado por el proceso de “Domainprep” a través del grupo “Exchange Enterprise Servers” el cual incluye todos los grupos “Exchange Domain Servers” de cada dominio, los que incluyen a su vez las cuentas de máquina de cada servidor Exchange en el dominio. Este problema puede ocurrir si Domainprep no ha sido ejecutado para el dominio bajo prueba, o si la cuenta de máquina del servidor Exchange que ejecuta RUS no está dentro del grupo Exchange Domain Servers del dominio.

¿Cada cuanto tiempo va a dispararse un ciclo de detección de cambios?

Si la configuración de “Update Interval” de RUS está configurada para “Always run”, el proceso de detección de cambios se realizará aproximadamente cada minuto. Si tenemos un “Update Interval” más espaciado, será necesario utilizar la opción de “Update Now” desde el menú de contexto de la instancia de RUS en el Exchange System Manager.

¿Cuál es la diferencia entre “Update Now” y “Rebuild”?

Ambos procesos son en esencia lo mismo. La única diferencia entre ambos es que con “Rebuild” comenzamos desde el USNChanged = 0 (o sea que RUS procesaría todos los objetos del directorio nuevamente). A los efectos de troubleshooting nunca es recomendado ejecutar “Rebuild”, porque deberíamos esperar mucho tiempo a que RUS terminase de procesar todos los objetos del dominio, sin ninguna ventaja para nuestro trabajo.

Si se ha ejecutado “Rebuild” por error, podemos saber el avance del proceso comparando el último evento 8011 conteniendo la consulta anterior con el USNChanged de un objeto recién creado. Al final del proceso de Rebuild se verá un evento similar a este:

¡RUS encontró nuestro objeto!

Estamos seguros de que nuestro objeto fue identificado cuando veamos el los siguientes eventos en el Application Log:

¿Qué listas de direcciones y políticas le serán aplicadas a nuestro objeto de prueba?

Una vez que el requerimiento de cambio ha sido encolado, RUS procesará cada transacción en cola, evaluando el objeto procesado contra cada lista de direcciones (en adelante AL) y políticas definidas en Exchange.

Por lo tanto, serán generados los siguientes eventos en relación a nuestro usuario de prueba:

Examinando los eventos 8130 veremos cuantas listas de direcciones y políticas aplican para este usuario. Esto significa que el filtro definido para esta AL o política (el filtro de cada AL o política se encuentra definido en el atributo purportedSearch de su objeto), incluye al usuario. Sin embargo, NO significa que todas las “Recipient Policies” que incluyen a nuestro objeto serán aplicadas. Solo la Recipient Policy de mayor prioridad será aplicada. Entraré en este tema con más detalle en mi próximo artículo RUS Parte III.

Las listas de direcciones SI serán aplicadas, tantas como correspondan a nuestro usuario de prueba.

En este punto y con estos eventos, podemos asegurar que:

a) RUS está comparando el usuario para cada AL y política (se generará un evento 8129 para cada AL y cada política definida en Exchange).

b) RUS ha detectado las listas de direcciones y políticas que aplican a nuestro objeto de prueba.

Algunos problemas que pueden suceder a este punto incluyen:

I) El objeto en proceso deberá ser evaluado por todas las listas de direcciones y políticas definidas en Exchange. Por lo tanto, deberá aparecer un evento 8129 por cada una de ellas. Si alguna de las listas de direcciones o políticas no tiene un evento 8129 correspondiente, significa que RUS no está viendo ese objeto en el directorio. Esto puede ser causado por un problema de permisos.

II) Problemas de replicación entre el DC utilizado por RUS y el DC utilizado como ConfigDC por DSAccess (pueden confirmar cual es este DC yendo a las propiedades del servidor de Exchange en la pestaña de “Directory Access”. Exchange lee las AL y Recipient Policies del ConfigDC, no del DC al que RUS apunta.

III) Si una AL o política que debería aplicarse al usuario, tiene un evento 8129 asociado pero no un evento 8130, esto significa que RUS no considera que el filtro de esta AL o política incluya nuestro usuario de prueba. Esto puede deberse a problemas de configuración del AL o política o errores en la definición de su filtro LDAP. Ante la duda si un filtro de LDAP incluye a nuestro objeto de prueba, podemos ejecutarlo utilizando LDP o la función “Find Now” de las Recipient Policies o la función “Preview” de las listas de direcciones en el Exchange System Manager. Hay políticas como las “System Policies”, para las que no hay forma de confirmar su filtro mediante Exchange System Manager, por lo tanto se deberá copiar su propiedad purportedSearch y ejecutarla como filtro de una búsqueda LDAP con LDP.exe o Adsiedit.msc.

IV) Si el filtro para una AL o política incluye atributos marcados como “Linked Value Replication o LVR” (homeMDB por ejemplo, que es el atributo que identifica el Mailbox Store donde el mailbox de un usuario reside, es un LVR), puede que la consulta no devuelva los resultados que esperamos y por ende, que ocurra la aplicación de la política incorrecta. LVR es una marca hecha en cada atributo que indica a Active Directory como manejar la replicación de ese objeto hacia el resto de los DCs. Si el “Forest” de Active Directory está configurado en modo nativo (Windows 2000 DCs no conocen de LVR por lo tanto esta funcionalidad que optimiza la replicación no es expuesta en modo mixto), los atributos marcados como LVR serán replicados con posterioridad a los atributos que no estan marcados como LVR. Esto hace que si creamos un usuario en un DC remoto, cuando este objeto se replica al DC al que apunta RUS, no tendrá el atributo LVR actualizado. Si tenemos por ejemplo una AL que agrupa los usuarios de un Mailbox Store y utilizamos el atributo homeMDB para su filtro, cuando RUS evalúe este filtro no incluirá a nuestro usuario, ya que homeMDB todavía no ha sido replicado al DC apuntado por RUS. El artículo KB903291 describe este problema.

¿Como confirmo cual Recipient Policy fue realmente aplicada?

Esta parte de la historia nos la informará directamente el MSExchangeSA en sus eventos de “Proxy Generation”. Pueden distinguir estos eventos en el Application Log filtrando por esta categoría.

El evento 3006 nos dirá las decisiones tomadas por el generador de direcciones e-mail (proxy generator). En su descripción podemos leer cuales Recipient Policies corresponden al usuario y cual será finalmente aplicada. Cuales son las direcciones e-mail actuales del usuario (Current recipient proxies), las de la política elegida, las que se deben generar, las generadas y las que finalmente se escriben en el objeto (Proxies written to the recipient)

Luego de este evento, dependiendo si el objeto necesita ser modificado o no, tendremos los respectivos eventos 8160 o 8039. Este es un ejemplo:

En este punto y con estos eventos, podemos asegurar que:

a) El “Proxy Generator” del servicio MSExchangeSA ha calculado el conjunto correcto de direcciones de e-mail para el usuario de prueba correspondiente a la “Recipient Policy” aplicada al mismo.

b) Que RUS ha modificado o no modificado al objeto según el caso que corresponda.

Algunos problemas que pueden suceder a este punto incluyen:

I) El usuario de prueba está realmente contemplado por una política, y se ve claramente en los eventos 8130 que es evaluado contra la misma, sin embargo las direcciones de E-mail no se actualizan y aparece el evento 8160 indicando que no es necesaria la actualización. Este problema puede ocurrir cuando el “Proxy Generator” no puede ejecutar debido a algún problema. Típicamente cuando existe algún generador de direcciones de terceros (por ejemplo productos integrados de FAX o conectores con sistemas externos), estos tienen su propio tipo de proxyAddresses, y necesitan de un módulo (dll) generador de este tipo especial de direcciones. Esta dll se instala como parte del producto de terceros y es cargada por MSExchangeSA para ser usada en la generación de estas direcciones. Si la dll está corrupta, no está localmente donde MSExchangeSA la busca o tiene algún problema de codificación, el Proxy Generator puede no seguir procesando, causando este problema.

II) Si RUS no puede efectuar una consulta de LDAP, quedará esperando la respuesta indefinidamente. Este problema puede ocurrir realmente en cualquier fase y normalmente es causado por problemas de red (pérdida de paquetes, configuración errónea de las tarjetas de red, etc.) Hay dos cosas básicas que pueden realizarse si sospechamos de un problema de red: Configurar la tarjeta de red y el puerto del switch al que el servidor está conectado a una velocidad fija de 100Mbps/ Full Duplex. Si la tarjeta está utilizando “Teaming” es buena práctica también deshabilitarlo para descartar posible incidencia de esta funcionalidad en el problema.

III) El “Proxy Generator” no es capaz de borrar el contenido del atributo GatewayProxy del objeto de RUS, luego de que se aplica una Recipient Policy usando la opción de “Apply Policy Now”, por lo tanto no es capaz de generar nuevas direcciones. El artículo KB821743 describe este problema. Cubriré la aplicación de políticas con más detalle en la próxima parte de este artículo (Parte III), ya que merece especial atención.

Referencias

822794 How to troubleshoot the Recipient Update Service by using the Application log in Exchange 2000 Server or in Exchange Server 2003

https://support.microsoft.com/default.aspx?scid=kb;EN-US;822794

288807 Troubleshooting the Recipient Update Service in Exchange Server 2003 and Exchange 2000 Server

https://support.microsoft.com/default.aspx?scid=kb;EN-US;288807

286356 Exchange Recipient Update Service does not stamp proxy addresses in Exchange 2000 Server and in Exchange Server 2003

https://support.microsoft.com/default.aspx?scid=kb;EN-US;286356

Artículos del equipo de Exchange de Microsoft acerca de RUS (Exchange Team Blog)

https://blogs.technet.com/exchange/archive/2004/07/07/175444.aspx

https://blogs.technet.com/exchange/archive/2004/07/15/184356.aspx

https://blogs.technet.com/exchange/archive/2004/07/22/191513.aspx

Linked value replication y RUS

https://blogs.technet.com/exchange/archive/2006/03/27/423248.aspx

Publicaremos un artículo más sobre RUS describiendo en detalle como funciona la aplicación de políticas (Recipient Policies) en conjunto con RUS.

Nos gustaría escuchar tus comentarios como forma de mejorar o incluir información de interés en nuestros artículos.

Nos vemos en el próximo.