Tarda mucho tiempo…

Artículo original publicado el lunes, 21 de febrero de 2012

Después de nuestro reciente anuncio sobre el lanzamiento del paquete acumulativo de actualizaciones 1 para Exchange 2010 Service Pack 2, verá que lanzamos una tonelada de correcciones y quería escribir sobre una en concreto, y quizás al mismo tiempo proporcionar información de fondo sobre cómo surgen problemas como estos y qué hacemos para corregirlos.

La corrección específica se conoce como 2556113 e indica que tarda mucho tiempo para descargar una libreta de direcciones sin conexión (OAB) en una organización que usa Exchange Server 2010.

Con una descripción como esta, podría pensar que simplemente encontramos una solución para hacer que las descargas de OAB sean más "rápidas". Podría pensar que lo conseguimos simplemente mediante la eliminación aleatoria de algunos de los usuarios en la OAB, esos que no conoce, los que trabajan en el departamento de contabilidad en la planta 4, por ejemplo. O quizás intentamos reducir los detalles incluidos en la OAB, posiblemente al eliminar información como, por ejemplo, los apellidos, la ubicación de la oficina o los números de teléfono. O quizás simplemente aumentamos la velocidad de Internet. Porque eso es muy fácil.

Bueno, no hicimos eso (aunque investigamos un poco lo de aumentar la velocidad de Internet, ya que sería genial). En cambio, agregamos un poco de lógica para asegurarse de que Outlook intente descargar la OAB desde el CAS más cercano a él.

“¿Por qué?” pregunta. Bueno, eso es una buena pregunta y mi respuesta es “Tal como indica el artículo de la KB, 'considere el escenario siguiente'….”

• Hay dos sitios de Active Directory sobre una red lenta en una organización que usa Microsoft Exchange Server 2010.
• Hay un servidor de acceso de cliente de Exchange Server 2010 y un servidor de buzones de correo de Exchange Server 2010 en un sitio de Active Directory.
• Hay un servidor de acceso de cliente de Exchange Server 2010 y se agrega un usuario de Office Outlook en el otro sitio de Active Directory.
• El usuario cuyo buzón de correo se encuentra en el sitio de Active Directory diferente intenta descargar la libreta de direcciones sin conexión (OAB) de Exchange.

En este escenario, tarda mucho tiempo para descargar la OAB.

Bueno, sí, es verdad, puede tardar mucho. Si tiene una OAB de gran tamaño, puede tardar muchísimo tiempo. Pero expandamos el escenario un poco, ya que hay información de la que debe ser consciente y tener un AD con solo un CAS no parece ser una solución muy inteligente para la mayoría de la gente.

Entonces, considere este escenario más detallado:

• Hay una implementación centralizada y todos los buzones de correo se encuentran en una ubicación centralizada.
• Hay varias ubicaciones pequeñas en las que la gente se conecta para trabajar.
• Estas ubicaciones están conectadas al sitio central con redes ineficaces. Satélite, ISDN (RDSI), PSTN, dispersión troposférica(tuve un cliente que tenía uno de estos... Buenísimo, hasta que hubo una tormenta), una correa mojada, etc.
• Su OAB es grande. Tiene un tamaño considerable. No es pequeña. Elija la definición que más le guste. Sea como sea, su tamaño es suficientemente grande como para que a usted le importe.
• Su cliente de Outlook intenta descargar OAB y esta viene del centro de datos central. Igual lo intenta hacer el cliente de Outlook que usa la persona al lado y el tío raro sentado allí en la esquina de la oficinal. Todos están descargando la misma OAB, sobre el mismo trozo de correa mojada y todo es muy lento.

Con un poco de suerte verá que todos están compitiendo por el mismo ancho de banda, mientras también intentan trabajar, y aunque la tecnología del cliente BITS que se usa para las descargas de OAB es buena, no será de gran ayuda.

Entonces, agrega un CAS a cada ubicación remota. De hecho, tal como sugiere el diagrama disponible en https://technet.microsoft.com/es-es/library/bb232155.aspx. La idea es que el equipo cliente descargará la OAB que necesita del CAS local. Bueno, podría parecer una estupenda idea, pero Exchange nunca ha funcionado así. Hasta que llegó 2010 SP2 RU1…

¿Cómo funcionaba entonces? Y ¿por qué le digo que TechNet le mintió?

Para responder a la primera pregunta, la dirección URL que el cliente usa para descargar la OAB se lo proporciona el servicio Detección automática. El código de detección automática siempre ha elegido una dirección URL para la OAB que debería estar descargando del sitio de Active Directory en el que se encuentra su buzón y no el sitio de Active Directory en el que se encuentra su equipo.

Para responder a la segunda pregunta, primero debe comprender que TechNet nunca se equivoca (mis amigos de UE, como Scott Schnoll, se ponen muy sensibles si se sugiere que sus artículos son incorrectos). El tema es que a veces no es correcto desde un punto de vista concreto. En TechNet se detalla esto como parte de la especificación de PM original en el momento que 2007 se estaba diseñando. Seguramente no debería haber dicho nada, pero bueno, es la verdad. Y no se hizo. Esto sucede con un producto de software con más de 20 millones de líneas de código y las cosas cambias con frecuencia. TechNet normalmente no miente... bueno, no mucho.

Pero así funciona. Piénselo un momento; tiene una OAB de 1 GB y agrega una réplica de esta en un CAS del sitio de Active Directory remoto, donde se encuentran los usuarios. Sin embargo, estos nunca la usan (bueno, a menos que sus buzones de correo también se encuentra en el mismo sitio de Active Directory, pero ese no es el escenario, ¿no?). Sé que no es ideal y tiene el aspecto siguiente.

Outlook usa el CAS más cercano al equipo cliente para las solicitudes de detección automática del cliente (bueno, así debería hacerlo y volveremos a ello en breve), pero la dirección URL de la OAB que devuelve es para el CAS en el mismo sitio de Active Directory que el del buzón de correo. Entonces, aunque replicamos la OAB en el sitio de Active Directory B, el cliente obtiene la OAB del sitio de Active Directory A.

Entonces, un cliente de gran tamaño con muchos sitios pequeños y una enorme OAB nos dice que esto no funcionará y las descargas están consumiendo el ancho de banda WAN que tengan. Entonces, ¿qué se puede hacer? Hay varias maneras de resolver esta situación y debo agregar que esta es una de las tareas divertidas de mi trabajo, lo de buscar soluciones... es cosa de los frikis de la informática.

1. Podrían reducir el tamaño de su OAB, acelerar su WAN, trasladar las oficinas a una ubicación más cercana, etc. Ninguna de ellas es una solución factible, aunque sí lo preguntamos.
2. Podríamos crear muchos OAB con el mismo contenido y especificar en el nivel por usuario o por base de datos la OAB que el usuario debería descargar. De este modo, solo tendríamos esa OAB disponible en la ubicación remota. Por tanto, la detección automática proporcionará la única dirección URL que puede para ella, en la ubicación remota. Ahora bueno, esto suena bien, excepto que los usuarios se mueven de un sitio a otro, por lo que una descarga significaría un doble salto de red lenta... por lo que se puede descartar como solución.
3. Lo mismo sucede con los buzones de correo, si se mueven a las ubicaciones remotas... bueno, se mueven, pero esto complicaría mucho las tareas de administración y la alta disponibilidad, lo que terminará aumentando el costo.
4. Podríamos hacer una reversión de dirección IP a la asignación del sitio de Active Directory. Creo que esta era la manera original que se pensaba resolver esto y, en realidad, es bastante difícil. Es difícil porque debe asegurarse de que todas las subredes de las que vendría un cliente estén en sitios y servicios de Active Directory y luego habría que intentar realizar una ingeniería inversa del sitio de Active Directory en el que se encuentra el usuario. Luego tendría que analizar los costos de vínculo del sitio, etc.... puede hacerse una idea. Es completo y eliminado por NAT si el administrador no enumera todas las posibles subredes en los sitios y servicios de Active Directory.
5. Podríamos ‘interferir’ con DNS o el XML de detección automática para intentar hacer que el cliente piense que se está comunicando con la ubicación centralizada cuando, en realidad, se estaría comunicando con una instancia de IIS local. Nuevamente, se trata de una solución difícil y complicada para implementar, y realmente no tiene buen aspecto.
6. Hay otra cosa más, y esta es la que elegí yo porque las demás eran muy difíciles.

Vuelva a la frase del principio “Outlook usa el CAS más cercano al equipo cliente para las solicitudes de detección automática”, donde dije que volveremos a ver. Vale la pena volver a ello debido a un parámetro llamado AutoDiscoverServiceSiteScope.

AutoDiscoverServiceSiteScope es un parámetro CAS que ayuda al cliente de Outlook a asignar sitios de Active Directory a CAS con el fin de buscar el CAS más cercano al cliente para las solicitudes de detección automática. Para ello, busca los puntos de conexión del servicio (SCP), que en realidad son punteros al servicio Detección automática.

Funciona así: cuando un cliente de Outlook se inicia, se dirige al triángulo, que a veces se conoce como ‘AD’, y busca todos los SCP que la instalación de Exchange ha colocado. Con suerte encuentra muchos y cada uno contiene un atributo (Keywords) que se establece, cambia o modifica por el uso de Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB, etc. El atributo Keywords se usa para especificar qué sitios de Active Directory del que este CAS es responsable para las solicitudes de detección automática.

Cuando el cliente de Outlook encuentra más de un SCP, crea una lista de SCP utilizables al comparar el valor almacenado en el atributo Keywords con su propio sitio de Active Directory (que el servicio Netlogon local actualiza dinámicamente cuando se inicia o cambia la dirección IP).

A continuación, crea una lista; con los elementos que coinciden con este sitio de Active Directory (donde el atributo Keywords = sitio de Active Directory del cliente) o bien, si no hay coincidencias, coloca todos los SCP en la lista. Estos serán los servidores que puede usar para sus solicitudes de detección automática.

Luego comienza por el principio de la lista (que siempre se ordena por fecha de instalación) e intenta conectarse al URI incluido en el atributo ServiceBindingInformation (la ubicación del servicio Detección automática en sí). A continuación, publica el XML, obtiene una respuesta, etc. y se queda contento el resto de su vida. Aquí encontrará más información sobre estos estupendos elementos de detección automática.

¿Por qué todo esto es interesante? Bueno, el parámetro AutoDiscoverServiceSiteScope ayuda a Outlook a encontrar el CAS más cercano a la ubicación del cliente, suponiendo que el administrador ha configurado los ámbitos del sitio correctamente (y les indicamos a los administradores que así lo hagan). Por tanto, no es necesario adivinar qué CAS está más cercano al cliente una vez que obtenemos la solicitud, ya que esto ya ha sucedido para cuando la solicitud alcance al CAS.

Cuando esa solicitud alcance al CAS, buscamos la configuración para devolver al cliente, pero siempre nos olvidamos de una cosa, que la OAB que necesita el usuario podría ser local para el CAS en el que ejecutamos la respuesta. En cambio, siempre dábamos al usuario una dirección URL desde un CAS muy lejano. Y eso era lo que teníamos que corregir.

Por tanto, la solución para esto teóricamente es muy sencilla y significa que no hace falta inventar una manera de saber qué CAS es el más cercano al cliente, ya que ya tenemos uno que funciona muy bien.

Si hacemos la suposición que el administrador configuró AutoDiscoverServiceSiteScope correctamente, el CAS al que se conecta el cliente para la detección automática será el CAS más cercano al cliente. En este caso, el CAS, a la hora de establecer qué se debe devolver en el XML de detección automática, simplemente debe comprobar si tiene una copia de la OAB que debería usar el cliente y, en caso afirmativo, provoca su propia dirección URL de OAB, no la de un CAS en el sitio de Active Directory en el que se encuentra el buzón de correo del usuario. Por supuesto, si no tiene una copia de la OAB que necesita el usuario, debería prevalecer el comportamiento anterior, es decir, el CAS devolverá la dirección URL de la OAB en el sitio de Active Directory de buzones de correo.

Entonces, básicamente, el concepto tendrá el aspecto siguiente:

Eso es mucho menos pesado para la WAN, ¿no? Una copia se replica sobre la WAN y los clientes en esa ubicación ahora obtendrán la OAB desde el CAS local para ellos.

¿Qué hay que hacer para activar este nuevo comportamiento? Simplemente dos cosas: implementar SP2 RU1 en el CAS y asegurarse de que los parámetros AutoDiscoverServiceSiteScope se hayan configurado correctamente.

Espero que todo esto sea de utilidad y espero que su WAN sea grande y rápida (long fat pipe).

Greg Taylor
Director principal de programas
Experiencia del usuario de Exchange

Esta entrada de blog es una traducción. Puede consultar el artículo original en It Takes a Long Time…