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:

 

Servicio

Categoría

MSExchangeAL

LDAP Operations

MSExchangeAL

Address List Synchronization

MSExchangeSA

Proxy Generation (Solamente disponible en Exchange 2003)

 

¿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):

 

; El System Attendant carga y ejecuta el módulo Abv_dg.dll

 

Event ID     : 9006

Category     : General

Source       : MSExchangeSA

Type         : Information

Message      : Microsoft Exchange System Attendant is loading 'ABV_DG.DLL'.

 

Event ID     : 9008

Category     : General

Source       : MSExchangeSA

Type         : Information

Message      : Microsoft Exchange System Attendant is starting 'ABV_DG.DLL'.

 

; Los eventos 8011 y 8012 son consultas y respuestas LDAP respectivamente hechas

; al DC que se indica en el evento. La respuesta no nos dará el resultado, pero sí

; la cantidad de objetos que corresponden a esa consulta.

; La siguiente consulta inspecciona el atributo msExchAddressListServiceBL para

; determinar si el servidor local está asociado a alguna instancia de RUS. Si no

; lo está, RUS para de procesar. En cualquier caso, RUS realizará la misma consulta

; cada 1 min. en busca de algún cambio

 

Event ID     : 8011

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Searching directory dc.mylab.com at base 'CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' using filter '(&(cn=EX)(objectclass=msExchExchangeServer)(!(IsDeleted=TRUE)))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; msExchAddressListServiceBL; msExchComputerLink; VersionNumber.

 

 

; Luego de confirmar que el servidor local está asociado a alguna instancia de RUS,

; el siguiente evento es la consulta de  por un objeto msExchAddressListService

; (instancias de RUS) que no esté borrado (o tombstone)

 

 

Event ID     : 8011

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Searching directory dc.mylab.com at base 'CN=Recipient Update Services,CN=Address Lists Container,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' using filter '(&(objectCategory=msExchAddressListService)(!(IsDeleted=TRUE)))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; msExchMasterServiceBL; activationSchedule; activationStyle; msExchAddressListServiceLink; msExchDomainLink; msExchServer1AuthenticationCredentials; msExchServer1AuthenticationPassword; msExchEncryptedPassword; msExchServer1NetworkAddress; msExchExportContainers; msExchReplicateNow; msExchDoFullReplication; msExchServer1LastUpdateTime; msExchServer1HighestUSN; msExchServer1PageSize; msExchPollInterval; msExchServer1Flags; VersionNumber; msExchServer1HighestUSNVector; msExchProcessedSids; msExchDomainGlobalGroupSid; msExchDomainLocalGroupSid; msExchDomainGlobalGroupGuid; msExchDomainLocalGroupGuid; gatewayProxy.

  

; Y el siguiente evento nos responde que ha encontrado dos objetos (la organización

; en el ejemplo tiene solo dos instancias de RUS, la de dominio y la de “Enterprise

; Configuration”). Si esta consulta devuelve 0 objetos como resultado significa que

; RUS no ve los objetos de RUS en el directorio por alguna razón.

 

Event ID     : 8012

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Search of directory dc.mylab.com at base 'CN=Recipient Update Services,CN=Address Lists Container,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' returned 2 objects.

 

; Mas adelante en el proceso de descubrimiento, RUS consulta Active Directory para

; conocer las “Recipient Policies” que contienen la información sobre las

; direcciones de e-mail a aplicar en los objetos. Una instalación nueva de Exchange

; nativo tiene solo una Recipient Policy, llamada “Default Policy”)

 

Event ID     : 8011

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Searching directory dc.mylab.com at base 'CN=Recipient Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' using filter '(|(objectCategory=msExchRecipientPolicy)(objectCategory=msExchSystemPolicy))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; objectCategory; purportedSearch; msExchSearchContainers; msExchPurportedSearchUI; msExchPolicyOrder; msExchPolicyOptionList; gatewayProxy; disabledGatewayProxy; msExchMandatoryAttrs; msExchADCOptions; msExchProxyGenOptions; displayName; msExchHideFromAddressLists; showInAdvancedViewOnly; msExchALObjectVersion; showInAddressBook; replPropertyMetaData; replicatedObjectVersion; ReplicationSignature; WhenChanged; WhenCreated; USNchanged; USNcreated; ObjectVersion; isDeleted; msExchProcessedSids; heuristics; msExchServerGroups; msExchServerGlobalGroups.

 

 

Event ID     : 8012

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Search of directory dc.mylab.com at base 'CN=Recipient Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' returned 1 objects.

 

; De igual forma que la consulta anterior RUS también consulta Active Directory por

; las “System Policies”, que aplican a los objetos según su naturaleza de

; “Hidden DL Membership”, “Mail Enable Recipient” y “Mailbox Enable User”.

; Tanto las Recipient Policies como las System Policies van a instruir a RUS acerca

; de que atributos estampar a los usuarios

 

Event ID     : 8011

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Searching directory dc.mylab.com at base 'CN=System Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' using filter '(|(objectCategory=msExchRecipientPolicy)(objectCategory=msExchSystemPolicy))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; objectCategory; purportedSearch; msExchSearchContainers; msExchPurportedSearchUI; msExchPolicyOrder; msExchPolicyOptionList; gatewayProxy; disabledGatewayProxy; msExchMandatoryAttrs; msExchADCOptions; msExchProxyGenOptions; displayName; msExchHideFromAddressLists; showInAdvancedViewOnly; msExchALObjectVersion; showInAddressBook; replPropertyMetaData; replicatedObjectVersion; ReplicationSignature; WhenChanged; WhenCreated; USNchanged; USNcreated; ObjectVersion; isDeleted; msExchProcessedSids; heuristics; msExchServerGroups; msExchServerGlobalGroups.

 

 

Event ID     : 8012

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Search of directory dc.mylab.com at base 'CN=System Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' returned 3 objects.

 

 

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:

 

; RUS consulta Active Directory por cualquier cambio en la partición de dominio

; 'DC=mylab,DC=com' entre el USNChanged 1498684 y 1498870. Esto quiere decir que

; en el ciclo anterior procesó hasta el uSNChanged 1498883. Si la propiedad USNChanged

; de nuestro objeto está entre 1498684 y 1498870, será procesado en este ciclo.

 

; Tip: En el aplication log, encontrarán múltiples eventos 8011 relativos a diferentes

; operaciones LDAP. Para localizar fácilmente el evento correcto, podemos buscar en el

; Aplication log por eventos 8011 que contengan “base 'DC” (sin las comillas dobles) en

; su descripción. Solo debemos considerar las operaciones relativas al dominio con

; problemas.

 

Event ID     : 8011

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Searching directory dc.mylab.comat base 'DC=mylab,DC=com' using filter '(&(USNChanged>=1498684)(uSNChanged<=1498870)((objectclass=*)))' and requesting attributes distinguishedName; objectGUID; LegacyExchangeDN; msExchADCGlobalNames; ObjectSID; ObjectClass; objectCategory; displayName; msExchHideFromAddressLists; hideDLMembership; ntsecuritydescriptor; showInAdvancedViewOnly; msExchALObjectVersion; showInAddressBook; msExchPolicyEnabled; givenName; sn; cn; mailNickname; targetAddress; initials; proxyAddresses; mail; textEncodedORAddress; msExchHomeServerName; msExchExpansionServerName; msExchCustomProxyAddresses; msExchPoliciesIncluded; msExchPoliciesExcluded; replPropertyMetaData; replicatedObjectVersion; ReplicationSignature; WhenChanged; WhenCreated; USNchanged; USNcreated; ObjectVersion; isDeleted; homeMDB; homeMTA; msExchMailboxGuid; msExchMailboxSecurityDescriptor; msExchResourceGUID; UserAccountControl; msExchUserAccountControl.

 

; Nótese que esta consulta puede devolver más de un objeto que ha sido modificado en

; el dominio. Todos serán procesados en el presente ciclo.

 

Event ID     : 8012

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Search of directory dc.mylab.comat base 'DC=mylab,DC=com' returned 1 objects.

 

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:

 

 

Event Type    : Information
Event Source  : MSExchangeAL
Event Category       : Address List Synchronization
Event ID      : 8330
Description   : The Recipient Update Service has completed the rebuild of DC=mylab,DC=com

 

¡RUS encontró nuestro objeto!

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

 

Event ID     : 8175

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Processing change to 'CN=test1,CN=Users,DC=mylab,DC=com'.

 

Event ID     : 8134

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Queuing request to process 'CN=test1,CN=Users,DC=mylab,DC=com'.

 

; Una vez que todos los objetos fueron encolados para procesar, aparecerá el

; siguiente evento

 

Event ID     : 8169

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Retrieved all directory changes under: 'DC=mylab,DC=com'.

 

¿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:

 

; Nuestra transacción comienza a procesarse

 

Event ID     : 8163

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Thread #930: received next Address List Transaction.

DC=mylab,DC=com

 

 

; Nuestro usuario de prueba “test1” es evaluado contra la lista “All Users”

 

Event ID     : 8129

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Evaluating directory object 'CN=test1,CN=Users,DC=mylab,DC=com' against address list 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' rule '(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))'.

DC=mylab,DC=com

 

 

; Si nuestro usuario corresponde a esa lista o política, se generará el

; Evento 8130

 

Event ID     : 8130

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' added to 'CN=test1,CN=Users,DC=mylab,DC=com'.

DC=mylab,DC=com

 

; Dependiendo del filtro, a veces Exchange necesita realizar una consulta para

; confirmar si el usuario está o no incluído en el filtro. En lugar de evaluar

; las múltiples respuestas de aplicar la consulta directa, Exchange realiza una

; consulta por el filtro con base en el propio objeto que se está procesando,

; utilizando su GUID. Si el evento 8012 devuelve 1 objeto, quiere decir que la

; AL o política aplica al usuario. El siguiente es un ejemplo del mismo

 

Event ID     : 8129

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Evaluating directory object 'CN=test1,CN=Users,DC=mylab,DC=com' against address list 'CN=Users on EX,CN=All Address Lists,CN=Address Lists Container,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com' rule '(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(msExchHomeServerName=/O=MyOrg/OU=AG/cn=Configuration/cn=Servers/cn=EX)) ))))'.

DC=mylab,DC=com

 

Event ID     : 8011

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Searching directory dc.mylab.comat base '<GUID=22DAF9A030B1C14A9ADED31EA3186D3A>' using filter '(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(msExchHomeServerName=/O=MyOrg/OU=AG/cn=Configuration/cn=Servers/cn=EX)) ))))' and requesting attributes ObjectClass; ReplPropertyMetaData.

DC=mylab,DC=com

 

Event ID     : 8012

Category     : LDAP Operations

Source       : MSExchangeAL

Type         : Information

Message      : Search of directory dc.mylab.comat base '<GUID=22DAF9A030B1C14A9ADED31EA3186D3A>' returned 1 objects.

DC=mylab,DC=com

 

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:

 

Event ID     : 3006

Category     : Proxy Generation

Source       : MSExchangeSA

Type         : Information

Message      : Policy provider instance processing recipient.

 

Recipient DN: CN=test1,CN=Users,DC=mylab,DC=com

 

Current recipient proxies:

 

Applicable policies:

       CN=Default Policy,CN=Recipient Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com

       CN=YAMAHA,CN=Recipient Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com

 

Chosen policy: CN=YAMAHA,CN=Recipient Policies,CN=MyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mylab,DC=com

 

Proxies of chosen policy:

       SMTP:@mylab.com

       X400:c=US;a= ;p=MyOrg;o=AG;

 

Proxies in change list:

 

Proxies to generate:

       SMTP:@mylab.com

       X400:c=US;a= ;p=MyOrg;o=AG;

 

Conflicts during generation:

 

Proxies generated:

       SMTP:test1@mylab.com

       X400:c=US;a= ;p=MyOrg;o=AG;s=test1;

 

Proxies written to recipient:

       SMTP:test1@mylab.com

       X400:c=US;a= ;p=MyOrg;o=AG;s=test1;

 

 

; Si RUS está funcionando correctamente, el objeto de prueba será modificado, porque

; era un objeto nuevo sin atributos de mensajería. Este es el evento resultante de

; la actualización del objeto indicando los atributos actualizados al objeto:

 

Event ID     : 8039

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Completed the transaction...

dn: <GUID=22DAF9A030B1C14A9ADED31EA3186D3A>

changetype: Modify

showInAddressBook:add:CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=MyOrg,CN=Micro...

: CN=Users on EX,CN=All Address Lists,CN=Address Lists Container,CN=dse...

: CN=oal2 Address List,CN=All Address Lists,CN=Address Lists Container,CN=MyOrg,...

: CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Cont...

mail:test1@mylab.com

textEncodedORAddress:c=US;a= ;p=MyOrg;o=AG;s=test1;

proxyAddresses:SMTP:test1@mylab.com

: X400:c=US;a= ;p=MyOrg;o=AG;s=test1;

msExchPoliciesIncluded:add:{792C1A95-72CB-4B71-B8DC-F1B21C38F61F},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}

msExchUserAccountControl:2

msExchALObjectVersion:53

objectGUID:22DAF9A030B1C14A9ADED31EA3186D3A

-

 

DC=mylab,DC=com

 

 

; Si el objeto no necesita ser modificado (p.ej. no hubo ningún cambio y el objeto

; fue procesado a consecuencia de un Rebuild

 

Event ID     : 8160

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : No change required for CN=test1,CN=Users,DC=mylab,DC=com.

DC=mylab,DC=com

 

; Finalmente los siguientes eventos aparecerán confirmando la transacción exitosa

 

Event ID     : 8035

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Successfully modified entry 'CN=test1,CN=Users,DC=mylab,DC=com' on directory DC.mylab.com.

DC=mylab,DC=com

 

 

Event ID     : 8167

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Modified the object: 'CN=test1,CN=Users,DC=mylab,DC=com'.

DC=mylab,DC=com

 

 

Event ID     : 8133

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Calculations complete on 'CN=test1,CN=Users,DC=mylab,DC=com'.

DC=mylab,DC=com

 

 

Event ID     : 8162

Category     : Address List Synchronization

Source       : MSExchangeAL

Type         : Information

Message      : Thread #930: waiting for next Address List transaction.

DC=mylab,DC=com

 

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

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

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

http://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

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

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

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

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

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

Linked value replication y RUS

http://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.