Cambios en la conectividad entre sitios de acceso de cliente de RPC

 

Artículo original publicado el miércoles, 30 de mayo de 2012

Hace casi dos años, presenté una sesión llamada High Availability Design Considerations en TechEd Norteamérica 2010. Durante la sesión, describí los cambios que estábamos realizando para que se produjera la conectividad MAPI después de mover buzones y tras eventos *over de bases de datos entre sitios. Desafortunadamente, dada la complejidad de los cambios que necesitábamos introducir y el escaso tiempo para hacer pruebas del que disponíamos antes de la publicación del Service Pack 1, tuvimos que cortar esta característica. Posteriormente, aunque intenté por todos los medios dar prioridad a este trabajo, tampoco pudimos implementar estos cambios en el Service Pack 2.

Lamentablemente, no siempre se puede cortar una característica con precisión de cirujano, y en el SP1 se dejó una parte de los cambios en el código. Por ejemplo, puede que hayas observado que el cmdlet Set-DatabaseAvailabilityGroup tiene una propiedad llamada AllowCrossSiteRPCClientAccess. Puedes cambiar el valor de esta propiedad booleana tanto como quieras que, desafortunadamente, no tendrá ningún efecto en el comportamiento del producto (lo sé... por eso esta imagen me parece extrañamente relevante):

Comportamiento de la conectividad de acceso de cliente de RPC entre sitios (RTM, SP1, SP2 a SP2-RU2)

Pero estoy divagando. Vamos a tratar primero una serie de aspectos básicos.

Con Exchange 2010, se instituyó un cambio principal en la forma en que los clientes se conectan y tienen acceso a los datos relacionados del buzón. A diferencia de las versiones anteriores, los clientes ya no se conectan directamente al Almacén de información del rol de servidor Buzón de correo para tener acceso a los datos del buzón. En lugar de eso, los clientes se conectan a un conjunto de servicios en el rol de servidor Acceso de clientes (CAS) y los servicios del rol de CAS obtienen acceso a los datos del buzón mediante MAPI/RPC desde el propio servidor Buzón de correo en nombre del usuario que se conecta. Es como si fuera una capa de abstracción.

Básicamente, se realizó un sencillo cambio de forma que la conectividad MAPI relacionada con el buzón de correo pase por el servicio de acceso de cliente de RPC en el rol de servidor Acceso de clientes. Para facilitar esta capa de abstracción, se hicieron cambios para que los objetos de base de datos dejarán de ser objetos secundarios de servidores Buzón de correo. Se agregó una nueva propiedad a la base de datos del buzón de correo, RPCClientAccessServer, que define el legacyExchangeDN que se debe usar para tener acceso a la base de datos concreta. Esta propiedad utiliza un nombre de dominio completo (FQDN) como su valor. Para garantizar que tienes una elevada disponibilidad y tolerancia a errores en caso de que se produzca un error en el CAS, este valor debe ser el FQDN de una matriz de CAS de carga equilibrada. Este FQDN de carga equilibrada es lo que denominamos matriz de servidor de acceso de cliente de RPC.

Para obtener más información, consulta las entradas de Brian Day en las que desmitifica el objeto de matriz de CAS, Parte 1 y Parte 2.

Experiencia con Outlook típica

Todas las versiones de Outlook se comportan de manera coherente en un escenario con un único centro de datos (o un solo sitio de Active Directory). El extremo de RPC del perfil de Outlook es la matriz de servidor de acceso de cliente de RPC (o un CAS específico si por alguna razón no has creado la matriz, cosa que deberías haber hecho, y, si no sabes por qué, lo repito: lee las entradas de Brian). Cuando se produce un error en el DAG (error de base de datos, de servidor, etc.), el extremo de RPC no cambia, por lo que Outlook sigue conectándose a la misma matriz de servidor de acceso de cliente de RPC. Si se produce un error en la matriz de CAS (error de CAS, del equilibrador de carga, etc.), el extremo de RPC no cambia, por lo que Outlook seguirá intentando conectarse a la matriz de servidor de acceso de cliente de RPC.

Todas las versiones de Outlook también se comportan de forma coherente en un escenario de cambio de centro de datos, siempre que sigas nuestras instrucciones. ¿A qué se debe esto? En un cambio de centro de datos, cambias la dirección IP de la entrada DNS de la matriz del servidor de acceso de cliente de RPC principal para que señale ahora a la matriz del servidor de acceso de cliente de RPC del centro de datos en espera. La detección automática sigue entregando la matriz del servidor de acceso de cliente de RPC principal como el extremo de RPC. Los clientes existentes de Outlook no necesitan reconfigurar nada; una vez actualizada la caché de DNS en el cliente, este simplemente se conectará al extremo que ahora reside en el centro de datos en espera. Para llegar a comprender por completo por qué funciona esto, debes entender que ni al cliente ni al CAS les importa demasiado el sitio en el que el CAS existe. Simplemente aceptan que se pueden conectar y que el CAS al que el cliente está conectado puede facilitar el acceso al buzón de correo.

Comportamiento *over de bases de datos entre sitios

Para comprender este escenario, es importante entender que al configurar un DAG multisitio, la propiedad RPCClientAccessServer para una base de datos concreta se asocia generalmente con la matriz de servidor de acceso de cliente de RPC que se encuentra en el mismo sitio de AD que la copia de la base de datos del buzón de correo con el número de preferencia de activación más bajo. Por ejemplo:

Figura 1: Grupo de disponibilidad de base de datos expandido entre dos sitios de Active Directory

         

En el caso de que una copia de la base de datos se active en el centro de datos en espera, los usuarios seguirán aprovechando la matriz de servidor de acceso de cliente de RPC del sitio de AD en el que la base de datos del buzón de correo con el valor de preferencia de activación más bajo reside como su extremo de conectividad.

Figura 2: La base de datos MDB1 se ha activado en el sitio de Active Directory en espera

Si revisas los registros de acceso de cliente de RPC en la matriz del servidor de acceso de cliente de RPC de origen, verás lo siguiente:

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

En el caso de que la matriz del servidor de acceso de cliente de RPC del sitio de AD en el que reside la base de datos del buzón de correo con el valor de preferencia de activación más bajo deje de estar accesible para los usuarios, los clientes de Outlook no podrán conectarse a su buzón de correo que reside en el centro de datos opuesto. En otras palabras, se produce un evento de interrupción del centro de datos y resulta necesario realizar el proceso de cambio de centro de datos.

Una forma más sencilla de entender este comportamiento es que Outlook siempre se conecta al extremo de RPC configurado (suponiendo que sea accesible) independientemente del valor de la propiedad RPCClientAccessServer de la base de datos.

¿Puede el sistema cambiar alguna vez el valor de RPCClientAccessServer automáticamente?

La única vez que el sistema cambia el valor de RPCClientAccessServer en la base de datos es cuando el administrador cambia el número de ActivationPreference en la copia de la base de datos activada para que ahora tenga el valor más bajo (convirtiéndose así en la copia preferida), tal y como se muestra en la Figura 3.

Figura 3: La base de datos MDB1 se ha activado en el sitio de Active Directory en espera y la propiedad RPCClientAccessServer ha cambiado

Sin embargo, los clientes de Outlook con un perfil de Outlook existente seguirán usando el antiguo extremo de RPC en lugar del nuevo (aunque la Detección automática haya detectado el cambio). Esto se debe a que el extremo de RPC antiguo no devuelve una respuesta ecWrongServer al cliente. El extremo de RPC acepta la conexión, por lo que Outlook pasa por alto la respuesta de la Detección automática, puesto que tiene una conexión operativa. En el caso de que el antiguo extremo de RPC deje de estar accesible, Outlook 2007/2010 actualizará su configuración (Outlook 2003, por su parte, no lo haría, ya que no usa la Detección automática). En cualquier momento se puede forzar a Outlook a usar el nuevo extremo de RPC forzando una reparación del perfil.

¿Qué ocurre si el administrador actualiza manualmente el valor de RPCClientAccessServer tras un evento *over de base de datos entre sitios?

Volviendo a la Figura 2, si el administrador actualiza manualmente el valor de RPCClientAccessServer para señalar a cas-sec.contoso.com para MDB1 después de que se active la copia de la base de datos del buzón de correo en MBX-C (cuyo valor de ActivationPreference es superior a 1), los clientes de Outlook con un perfil existente continuarán usando el extremo de RPC antiguo en lugar del nuevo mientras el antiguo siga disponible (las reparaciones de perfil corregirán el problema). Los perfiles de Outlook creados después del cambio del valor de RPCClientAccessServer usarán el nuevo extremo de RPC.

Mover buzones de correo entre sitios de Active Directory

Antes de Exchange 2010, al mover buzones de correo entre servidores, el extremo de RPC de Outlook RPC se actualizaba para señalar al servidor Buzón de correo (o instancia del servidor Buzón de correo en clúster) en el que se hospedaba la base de datos en la que residía el buzón de correo. Una vez completado el movimiento del buzón de correo, el usuario del cliente de Outlook veía el siguiente cuadro de diálogo: “El administrador de Microsoft Exchange ha realizado un cambio que requiere que salga de Outlook y reinicie la aplicación”. Tras reiniciar Outlook, el cliente se conectaba al nuevo extremo de RPC.

Con Exchange 2010, es posible que hayas observado que al mover buzones entre sitios de AD, los usuarios no recibían este cuadro de diálogo. Además, puede que también te hayas dado cuenta de que los usuarios no tenían el extremo de RPC actualizado para reflejar la matriz del servidor de acceso de cliente de RPC asociada con la base de datos del buzón de correo en el sitio de AD en el que ahora reside el buzón de correo. Esto se debe a que el extremo de RPC antiguo no devuelve una respuesta ecWrongServer al cliente. El extremo de RPC acepta la conexión, por lo que Outlook pasa por alto la respuesta de la Detección automática, puesto que tiene una conexión operativa. En el caso de que el antiguo extremo de RPC deje de estar accesible, Outlook actualizará su configuración (Outlook 2003, por su parte, no lo haría, ya que no usa la Detección automática). En cualquier momento se puede forzar a Outlook a usar el nuevo extremo de RPC forzando una reparación del perfil.

Estoy seguro de que ahora entiendes la foto del gato sonriente de arriba.

El futuro…SP2 RU3 y más allá

Nunca perdí la esperanza de resolver estos problemas. El equipo de desarrollo de acceso de cliente de RPC, el equipo de servicio de Exchange y yo personalmente trabajamos incansablemente para implantar en el producto los dos cambios necesarios. El primero de ellos consiste en arreglar un perfil de Outlook cuando un buzón de correo sencillamente se mueve entre bases de datos en sitios de AD distintos, mientras que el segundo se aplica a situaciones en las que una base de datos entre sitios proporciona resultados *over en Outlook con un CAS que no es la opción más adecuada para la ubicación de la base de datos actualmente activada.

Movimientos de buzones de correo

De manera predeterminada, tras instalar SP2 RU3, al mover buzones de correo entre sitios de AD, se solicitará en todas las versiones de Outlook que se reinicie la aplicación y el extremo de RPC del perfil de Outlook se actualizará.

Si revisas los registros de acceso de cliente de RPC en la matriz de acceso de cliente de RPC de origen, verás lo siguiente:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Observa que la operación de RPC (ROP) es WrongServer (también llamada ecWrongServer). Esto fuerza al cliente de Outlook a realizar una detección del perfil y actualizar el perfil en base a la nueva información encontrada en el directorio. El perfil se actualiza y, después de que se reinicie el cliente, el cliente establece sus conexiones con el nuevo extremo de RPC.

¿Qué otras condiciones hacen que aparezca el cuadro de diálogo “El administrador de Microsoft Exchange ha realizado un cambio que requiere que salga de Outlook y reinicie la aplicación”?

1. Al especificar la propiedad DoNotPreserveMailboxSignature en New-MoveRequest.
2. Cuando las bases de datos de buzón de correo de origen y de destino tienen un almacén de jerarquías de carpetas públicas distinto.
3. Al mover tu buzón de correr de una versión heredada de Exchange a Exchange 2010.

Eventos *over de bases de datos entre sitios

El comportamiento de los eventos *over de bases de datos entre sitios dependerá del valor de la propiedad AllowCrossSiteRPCClientAccess de DAG.  Si estableces el valor de la propiedad AllowCrossSiteRPCClientAccess en $true, el comportamiento descrito en la sección anterior será el predeterminado. En el caso de que la base de datos se active en el centro de datos en espera, los usuarios seguirán aprovechando la matriz de acceso de cliente de RPC en el sitio de AD en el que la base de datos del buzón de correo con el valor de preferencia de activación más bajo reside como su extremo de conectividad.

Si estableces el valor de la propiedad AllowCrossSiteRPCClientAccess en $false (el valor predeterminado de la propiedad es $false), el extremo RPC del perfil de Outlook se actualizará para ser la matriz del servidor de acceso de cliente de RPC que se encuentra en el mismo sitio de AD en el que está activa y montada la base de datos. Ten en cuenta que la propiedad RPCClientAccessServer no se actualiza, ya que define el sitio preferido.

Figura 4: La base de datos MDB1 se ha activado en el sitio de Active Directory en espera y el perfil de Outlook se ha actualizado automáticamente

Si revisas los registros de acceso de cliente de RPC en la matriz del servidor de acceso de cliente de RPC de origen, verás lo siguiente:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Al igual que al mover buzones de correo, el ROP de WrongServer ROP fuerza al cliente de Outlook a realizar una detección del perfil y actualizar el perfil en base a la nueva información encontrada en el directorio. El perfil se actualiza y, después de que se reinicie el cliente, el cliente establece sus conexiones con el nuevo extremo de RPC.

Conclusión

Pues de eso se trata. Con SP2 RU3 (o una versión posterior) puedes garantizar que el perfil de los buzones de correo que se muevan entre sitios de AD se actualice correctamente. Además, en el escenario *over de bases de datos entre sitios, puedes controlar si permitir la conectividad de RPC entre sitios o si forzar al cliente de Outlook a usar la matriz del servidor de acceso de cliente de RPC que se encuentra en el mismo sitio de AD que la base de datos activada y montada (comportamiento predeterminado). Creo que resulta apropiado acabar así:

Ross Smith IV
Jefe principal de programas
Experiencia del usuario de Exchange

Esta entrada de blog es una traducción. Puedes consultar el artículo original en RPC Client Access Cross-Site Connectivity Changes