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

Recipient Update Service en Exchange 2000 y Exchange 2003

Parte I – Conceptos básicos

Por: Daniel 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. Para evitar confusión en la nomenclatura, describiré los términos técnicos relacionados a opciones y componentes de Exchange con su nombre en inglés tal como aparecerían en artículos la base de conocimientos de Microsoft)

Durante incidentes de soporte en los que personalmente he trabajado, he percibido que no en todos los casos hay una buena comprensión de la función de RUS en la organización. Cuantas instancias de RUS son necesarias, como identificar y hacer seguimiento a los problemas, administración y operación son varios de los puntos donde encontramos la mayor carencia. Este artículo inicial apunta a clarificar conceptos básicos relacionados con el servicio.

¿Que es RUS?

RUS es un subproceso que ejecuta bajo el servicio Microsoft Exchange System Attendant, implementado en Abv_dg.dll. Su función es actualizar atributos relacionados a la mensajería en objetos del Active Directory (objetos mail-enabled y mailbox-enabled tales como usuarios, contactos, grupos o carpetas públicas). RUS evalúa y actualiza estos objetos en base a políticas cuando estos objetos son creados o modificados. El atributo USNChanged es utilizado por RUS para saber que objetos han sido creados o modificados.

Cuando un usuario es creado en Active Directory y marcado como mailbox-enabled (usando la opción de crear buzón durante la creación del usuario o posteriormente a través de los Exchange Tasks), debe ser procesado por el RUS antes de poder realizar cualquier operación relacionada con mensajería. Por ejemplo, crear un perfil de mapi en un cliente, recibir un correo, conectarse a Outlook Web Access, verse en la lista global de direcciones o crear el buzón físicamente en el Information Store, son todas operaciones relacionadas con mensajería que no pueden realizarse antes de que RUS procese dicho objeto.

¿Cuáles son los atributos que RUS actualiza?

Las actualizaciones que RUS efectúa corresponden a cuatro diferentes categorías:

Recipient Policy – Configura el atributo proxyAddresses a usuarios basado en las Recipient Policies. Este atributo refleja todas las posibles direcciones de un objeto para los diferentes tipos de direcciones (smtp, X400, CCMAIL, etc.) y corresponde a lo que vemos en la pestaña E-mail Addresses de las propiedades del objeto. El atributo mail (representa el smtp reply address o dirección smtp por omisión) y textEncodedORAddress también son atributos configurados por RUS.

Address List – Configura el atributo showInAddressBook basado en las listas de direcciones configuradas en Exchange. Este atributo define a que listas pertenece un determinado objeto y es utilizado para resolver nombres en Microsoft Outlook y otros clientes MAPI. Este atributo también es necesario para poder crear un perfil MAPI en una estación de trabajo.

System Policy – Configura los atributos homeMDB , homeMTA y msExchHomeServerName si al menos uno de ellos existe. No cambia el atributo si ya existe en el objeto.

Configura el atributo msExchMailboxGuid si no está presente. Configura el atributo legacyExchangeDN si el objeto es mail-enabled y no está configurado. Configura el atributo displayName al valor del atributo mailNickname si es que no está configurado.

Para grupos que tienen la opción “Hide group from Exchange address lists” (hideDLMembership=True), agrega permisos en el Access Control List (ACL) del grupo para que sus miembros no sean vistos por los usuarios.

Otras tareas – Configura permisos en las ACL del contenedor "cn=Microsoft Exchange System Objects,DC=domain,DC=com" reflejando los derechos administrativos configurados con el Delegate Wizard. Verifica los miembros del grupo de seguridad Exchange Enterprise Servers y agrega los grupos Exchange Domain Servers si falta alguno.

Cada una de estas categorías es manejada por un componente o provider dentro de RUS, por lo que es posible, en caso de problemas con uno de estos componentes, que los objetos sean configurados parcialmente.

El siguiente es un volcado de los atributos de un usuario mailbox-enabled marcando las propiedades configuradas por RUS (algunos atributos fueron excluidos a efectos de claridad). Los atributos en amarillo, son los configurados por RUS.

¿Cuántos tipos de RUS existen?

Existen dos tipos de RUS que son configurados automáticamente cuando se instala el primer servidor de Exchange 200x en el dominio.

Uno es responsable de la actualización de objetos del sistema de Exchange en el contenedor de configuración de Active Directory. Hay solamente un RUS de este tipo en la organización de Exchange y por lo tanto en el Forest de Active Directory. Esto se debe a que solamente hay un contenedor de configuración por cada forest de Active Directory. Este RUS aparece como “Recipient Update Service (Enterprise Configuration) ” bajo el contenedor de Recipient Update Services en el Exchange System Manager (en adelante ESM).

El segundo tipo de RUS es responsable de procesar los objetos de la partición de dominio de Active Directory. Como en un forest de Active Directory puede haber más de un dominio, debe haber una instancia de este tipo de RUS por cada dominio en el forest donde haya destinatarios, usuarios o servidores de Exchange. Una particularidad de este segundo tipo de RUS es que puede haber más de una instancia del servicio por dominio. Más adelante cuando discutamos cuanto demora RUS para actualizar los objetos, veremos las ventajas (o desventajas) de tener más de un RUS para un dominio de Active Directory. Este tipo de RUS aparece como “Recipient Update Service (<dominio>) ” bajo el contenedor de Recipient Update Services en el ESM. DomainPrep debe ser ejecutado en cada dominio donde RUS trabaja, incluso cuando no existan servidores de Exchange en dicho dominio.

Configuración del servicio de RUS

Cada instancia del servicio de RUS sea de dominio o “Enterprise Configuration” aparece bajo el contenedor de Recipient Update Services (CN=Recipient Update Services,CN=Address Lists Container,CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com), representada como un objeto del contenedor de configuración de Active Directory. Cada uno de estos objetos almacena la configuración de cada instancia de RUS.

Hay cuatro valores fundamentales en la configuración de una instancia de RUS los cuales pueden verse en sus propiedades en el ESM:

Domain (msExchDomainLink) – Dominio de Active Directory donde esta instancia actualizará objetos.

Exchange Server (msExchAddressListServiceLink) – Este es el servidor de Exchange que ejecuta físicamente el servicio de RUS.

Windows Domain Controller (msExchServer1NetworkAddress) – Este es el controlador de domino donde RUS detectará cambios y actualizará los objetos de acuerdo a las políticas antes mencionadas.

Update Interval (activationSchedule) – Permite configurar cada cuanto tiempo RUS va a detectar cambios en el controlador de dominio y actualizar los objetos correspondientes. Si esta opción está configurada para correr siempre (Always Run) RUS correrá aproximadamente cada minuto. Bajo ESM, es posible ejecutar “Update Now” desde el menú de contexto de cada instancia. Este comando tendrá precedencia sobre el Update Interval y provocará que RUS comience su ciclo inmediatamente.

¿Cuanto tiempo pasa desde que se crea el objeto mailbox-enabled hasta que todos los atributos estén efectivamente configurados?

Esta es una pregunta es muy importante para los administradores, ya que determina cuanto tiempo vamos a demorar en que un usuario pueda utilizar su correo electrónico luego de creado. Sin embargo, no tiene una única respuesta. Este tiempo dependerá de múltiples factores, incluyendo latencia de replicación de Active Directory, configuración de sitios de Active Directory y en qué domain controller se cree el objeto. Paso a explicar con simples ejemplos:

Escenario 1 - Tomemos un escenario básico para una organización de un dominio, con un servidor de Exchange (EX1) y un controlador de dominio de Active Directory (DC1). Las instancias de RUS están necesariamente configuradas para usar el único controlador de domino y el único servidor de Exchange en la organización. Supongamos que tenemos la configuración de Update Interval en “Always run”. Cuando creamos un objeto mailbox-enabled (digamos un usuario con una casilla de correo en el servidor de Exchange), el objeto se creará en DC1. En cuanto RUS comience su ciclo consultará a DC1, por lo que sabrá que hay un nuevo objeto a procesar, procesará el objeto, e inmediatamente el usuario podrá crear un profile MAPI, acceder a OWA o recibir un mensaje.

Escenario 2 – Digamos que ahora tenemos un nuevo sitio (Site2) de Active Directory con un segundo controlador de dominio DC2. Si creamos el usuario en DC2, RUS no verá el nuevo usuario inmediatamente, porque estará consultando a DC1. Recién cuando la replicación de Active Directory haya replicado el objeto de DC2 a DC1, RUS será capaz de procesarlo. Una vez que RUS procesa este objeto, un usuario en el Site2 todavía no será capaz de crear su perfil, porque DC2 todavía no tiene información de que el usuario haya sido procesado por RUS sino hasta que nuevamente la replicación de Active Directory replique el objeto modificado en DC1 to DC2. Sin embargo el usuario será capaz de recibir mensajes y consultar OWA, porque Exchange consultará a DC1 para obtener la información del usuario.

Escenario 3 – Supongamos ahora que instalamos un nuevo servidor de Exchange (EX2) en Site2. La situación del escenario 2 se mantiene, pero si la casilla de correo del usuario es creada en el servidor EX2, este no podrá consultar OWA, recibir mensajes o crear su perfil MAPI hasta que el objeto modificado por RUS sea replicado por Active Directory desde DC1 a DC2. Esto ocurre porque EX2 estará consultando las propiedades del usuario para operaciones de mensajería en DC2.

Presentados estos escenarios es ahora más fácil imaginar como varios saltos de replicación de Active Directory, replicación agendada y enlaces lentos pueden influir aún más en el tiempo en cuestión.

Los escenarios 2 y 3 representan las situaciones donde podríamos tener varias instancias de RUS y evitar los ciclos de replicación de Active Directory. Por ejemplo en el escenario 3 podríamos crear una segunda instancia de RUS corriendo en EX2 procesando en DC2. Como desventaja de tener varias instancias, puedo mencionar que el seguimiento de problemas es una de ellas, ya que cualquiera de las instancias puede modificar el objeto complicando el seguimiento.

Tendremos dos artículos más sobre RUS entrando en aspectos de seguimiento de problemas en la Parte II y en cómo funciona la aplicación de políticas (Recipient Policies) en conjunto con RUS en la Parte III.

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

Nos vemos en el próximo.