Consideraciones importantes para la consolidación de sitios en modo mixto

Última modificación del tema: 2006-08-16

Antes de consolidar sitios de Microsoft® Exchange, debe familiarizarse con las siguientes recomendaciones y requisitos previos para la consolidación de sitios, así como con los problemas que pueden surgir durante y después de la consolidación de sitios:

• Actualice los equipos cliente a Microsoft Office Outlook®** 2003**   Antes de consolidar sitios, actualice los equipos cliente del sitio remoto a Outlook 2003 y active el modo de intercambio en caché. El modo de intercambio en caché es un componente importante de la consolidación de sitios porque los usuarios remotos pueden trabajar desde su caché local con o sin una conexión de red. La actualización de Outlook en los equipos cliente y la activación del modo de intercambio en caché crea una copia local del buzón de un usuario. Al crear la copia local antes de mover buzones, evita el pesado tráfico de descarga que se produce al esperar hasta que se mueven los buzones fuera del sitio local. Esta estrategia resulta especialmente útil en aquellos casos en los que el ancho de banda de la red entre el sitio remoto y el sitio central es limitado. Si bien se permiten equipos cliente con versiones anteriores de Outlook y otras aplicaciones de correo electrónico, estos equipos cliente no pueden aprovechar el modo de intercambio en caché. Además, para reducir al mínimo los problemas de soporte técnico, debe pensar en incorporar el aprendizaje de los usuarios finales de Outlook 2003 y su preparación dentro del proceso de actualización.

• Actualice el ADC al SP1 de Exchange 2003   Utilice la versión del SP1 de Exchange 2003 del Conector de Active Directory (ADC), que contiene nuevas funciones que limpian objetos y listas de distribución después de la consolidación de sitios. Cuando mueve buzones entre sitios, el ADC actualiza los objetos de usuario y todos los grupos de distribución a los que pertenecen los usuarios; por tanto, los cambios se replican entre los directorios y los usuarios pueden seguir recibiendo correo.

• Consolide dominios de Microsoft Windows® **si es posible.   **Para evitar problemas con el establecimiento de delegados, la publicación de certificados del Servicio de administración de claves y la actualización de grupos mediante Outlook, se recomienda que consolide los dominios remotos de Windows y los buzones de Exchange simultáneamente. El servicio de directorio Microsoft Active Directory® requiere que Outlook utilice un servidor de catálogo global situado en el mismo dominio que el objeto que Outlook está intentando actualizar. En el ejemplo de delegar el acceso al buzón, si un usuario cuyo objeto de usuario se encuentra en el dominio remoto inicia sesión en Outlook en el dominio central, el usuario no podrá establecer delegados. Esto se debe a que Outlook está dirigido al dominio central, pero los objetos de usuario se encuentran en el dominio remoto. El servidor de catálogo global del dominio central contiene una copia de sólo lectura de los objetos de directorio que residen en otros dominios. Si no puede consolidar Exchange y dominios de Windows simultáneamente, puede configurar la siguiente clave del Registro en el cliente de Outlook para que utilice un servidor de catálogo global del dominio central donde se encuentran los objetos de directorio:

  Ubicación:	HKEY_CURRENT_USER\Software\Microsoft\Exchange \Exchange Provider
  Name:	Servidor DS
  Tipo:	REG_SZ (cadena)
  Valor:	<nombre de dominio completo del servidor de catálogo global>

• Aplique la revisión del ajustador de coherencia del Servicio de directorio/Almacén de información (DS/IS) y utilice el ajustador para conservar el acceso a las carpetas públicas de Exchange 5.5   Si mueve usuarios y grupos al sitio central antes de mover carpetas públicas de Exchange 5.5, las listas de control de acceso (ACL) de las carpetas públicas serán incorrectas y los usuarios no podrán tener acceso a dichas carpetas. Hay dos opciones para evitar este problema:

  • Opción 1: después de mover usuarios y grupos puede ejecutar el ajustador de coherencia de DS/IS para actualizar las ACL de las carpetas públicas con la nueva información de usuarios y grupos.

  • Opción 2: puede replicar las carpetas públicas en el sitio central primero y, después, mover usuarios y grupos. Asegúrese también de que las referencias a carpetas públicas estén habilitadas en los conectores.

    Nota

    Antes de empezar a consolidar sitios de Exchange 5.5, aplique la revisión para el ajustador de coherencia DS/IS de Exchange 5.5 a todos los servidores de carpetas públicas de Exchange 5.5 (disponible en https://go.microsoft.com/fwlink/?linkid=3052&kbid=836489). Esta revisión garantiza que, después de un movimiento entre sitios, las ACL de las carpetas públicas se actualizarán correctamente de forma que los usuarios y los grupos tengan un acceso continuado a las carpetas públicas.

• Planifique una descarga completa de la libreta de direcciones sin conexión   Antes de mover varios buzones entre sitios, debe determinar si tiene suficiente ancho de banda como para permitir una descarga completa de la libreta de direcciones sin conexión para todos los equipos cliente de Outlook de todos los sitios remotos. Para obtener más información acerca de por qué se produce una descarga completa de la libreta de direcciones sin conexión, consulte "Descarga de la libreta de direcciones sin conexión" más adelante en este tema.

• Actualice los perfiles de Outlook después de mover buzones   Después de mover buzones entre grupos administrativos debe actualizar los perfiles de Outlook para que los usuarios puedan iniciar sesión en los buzones reubicados. La herramienta para actualización de perfiles de Exchange (Exprofre.exe) es una herramienta de la línea de comandos que se ejecuta en los equipos cliente para actualizar automáticamente los perfiles de Outlook de los usuarios. Exprofre.exe modifica el perfil predeterminado de Outlook, de forma que los usuarios puedan iniciar sesión correctamente en sus buzones después del traslado. Esta herramienta está disponible en el sitio Web de herramientas y actualizaciones de Exchange Server 2003 (https://go.microsoft.com/fwlink/?linkid=21316).

Descarga de la libreta de direcciones sin conexión

Los equipos cliente de Outlook que utilizan el modo de intercambio en caché necesitan una libreta de direcciones sin conexión para resolver las direcciones de correo electrónico. La libreta de direcciones sin conexión está almacenada en un servidor de carpetas públicas. Se realiza una descarga completa de la libreta de direcciones sin conexión en las situaciones siguientes:

• Cuando consolida un sitio, todos los usuarios de ese sitio que utilizan el modo de intercambio en caché y cuyos buzones de hayan movido recibirán una descarga completa de la libreta de direcciones sin conexión. Esta descarga se produce la primera vez que estos usuarios inician Outlook después de mover los buzones.
• Cuando se realiza una serie de cambios importantes en el directorio (por ejemplo, cuando mueve un gran número de buzones entre sitios o cuando realiza cambios en la topología de Exchange), todos los usuarios de todos los sitios que utilicen el modo de intercambio en caché recibirán una descarga completa de la libreta de direcciones sin conexión.

Para obtener más información acerca del impacto de las descargas completas de la libreta de direcciones sin conexión y de las situaciones en las que se producen, consulte el artículo 839826 de Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?linkid=3052&kbid=839826).

Esta descarga puede ocasionar problemas de rendimiento tanto en la red como en Outlook. A la hora de determinar la duración de la descarga de la libreta de direcciones sin conexión, tenga en cuenta el ancho de banda de las conexiones de red con todos los sitios remotos, la cantidad de datos que se deben transferir y la latencia de la conexión de red. Puede estimar la cantidad de datos que se van a transferir si multiplica el tamaño de la libreta de direcciones sin conexión por el número de usuarios del sitio remoto.

La latencia de red es la cantidad de tiempo que tarda una transferencia de datos de un punto de la red a otro. La latencia es un factor que influye a la hora de determinar con qué rapidez se satura la conexión de red. Con una latencia elevada, la velocidad de transferencia de datos es más lenta, lo que significa que la conexión de red tarda más tiempo en saturarse. Por el contrario, una latencia más corta significa que los datos fluyen más rápidamente, lo que aumenta la probabilidad de que se sature la conexión si hay varios clientes descargando simultáneamente la libreta de direcciones sin conexión.

Antes de mover varios buzones entre sitios debe averiguar si tiene suficiente ancho de banda como para permitir una descarga completa de la libreta de direcciones sin conexión para todos los usuarios de Outlook del sitio remoto. También debe evaluar el impacto de la descarga sobre la red en función de la cantidad de datos que hay que mover y de la latencia de red.

Funcionalidad de disponibilidad

Cuando su organización está en modo mixto y utiliza el asistente Mover buzón para mover buzones entre sitios, el asistente actualiza los objetos de usuario correspondientes con el nuevo atributo legacyExchangeDN. Como el asistente actualiza el atributo legacyExchangeDN, no necesita mover las carpetas del sistema de disponibilidad. Los datos de disponibilidad de los usuarios vuelven a publicarse con el nuevo atributo legacyExchangeDN después de que el usuario inicie sesión en el nuevo buzón.

Limitaciones conocidas del proceso de consolidación de sitios

En esta sección se describen las limitaciones conocidas de la consolidación de sitios. El proceso de consolidación de sitios se ve afectado por diversos factores, como el orden en que se realizan los pasos, el tiempo que tarda en replicarse la información del directorio y el tiempo que se tarda en replicar los datos de Exchange entre sitios. Además, al mover buzones y usuarios entre sitios pueden verse afectadas otras características de correo. Debe familiarizarse con todos los problemas conocidos que se enumeran aquí antes de empezar a diseñar la consolidación de sitios.

• El tráfico de red aumentará cuando se muevan buzones   Al mover buzones entre sitios, debe contar con un tráfico de red adicional entre los sitios. El tráfico adicional es igual a los tamaños combinados de los buzones que piensa mover.

• Aumentará el tráfico de replicación de directorios   Cuando se mueven buzones desde sitios de Exchange 5.5 a un sitio central de Exchange cabe esperar mayor tráfico de replicación de directorios mientras el ADC actualiza los usuarios y los grupos de distribución y quita los objetos anteriores del sitio remoto. La duración de este proceso depende del tamaño del entorno, la velocidad de replicación entre los sitios de Exchange 5.5, y la velocidad de replicación entre Exchange 5.5 y Active Directory. De manera predeterminada, la limpieza de directorios se realiza cada doce horas. En los entornos pequeños, la limpieza de directorios puede realizarse durante la próxima sesión de replicación automática; sin embargo, en los entornos grandes puede ser necesaria más de una sesión.

  Importante

  Para acelerar la limpieza de directorios, puede iniciar la replicación en el Administrador del Conector de Active Directory y el programa Administrator de Exchange 5.5.

• Aumentará el tráfico de replicación de carpetas públicas   Cuando utiliza la herramienta de migración de carpetas públicas de Exchange (pfMigrate) para mover carpetas públicas al sitio central, aumenta el tráfico mientras se actualiza la jerarquía de carpetas públicas y se replica el contenido de las carpetas públicas entre los sitios. La herramienta pfMigrate y el ajustador de coherencia DS/IS hacen que aumente el tráfico de replicación.

• Los archivos de carpetas sin conexión almacenados en caché que están en formato ANSI no se vuelven a crear automáticamente en formato Unicode después de trasladar buzones de Microsoft Exchange Server 5.5.   Los archivos de carpetas sin conexión almacenados en caché (.ost) de los usuarios y los archivos de libreta de direcciones sin conexión (.oab) permanecen en formato ANSI después de trasladar los buzones de Exchange Server 5.5 a un equipo que ejecuta Exchange Server 2003 o Microsoft Exchange 2000 Server. Un archivo de carpetas sin conexión (.ost) almacenado en caché en formato ANSI tiene un límite de tamaño de 2 GB y, dado que este archivo está en formato ANSI, el archivo de libreta de direcciones sin conexión también utiliza este formato. Además, para la solución que se ofrece en el artículo 841207 de Knowledge Base, es necesario descargar por completo la libreta de direcciones sin conexión en todos los equipos cliente afectados. Esta descarga puede aumentar el tráfico de red de manera significativa.
  Para obtener más información acerca de este tema y para leer la solución a los archivos de carpetas sin conexión almacenados en caché que se crean en formato ANSI en lugar de en formato Unicode en Exchange 2003 o en Exchange 2000, consulte el artículo 841207 de Knowledge Base "Un archivo de carpeta sin conexión almacenada en caché de Outlook 2003 se crea en formato ANSI en lugar de Unicode en Exchange 2003 o en Exchange 2000" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=841207).
  Para obtener más información acerca del uso de Unicode con Outlook 2003, consulte Configuración de las opciones de Unicode en Outlook 2003 (en inglés) (https://go.microsoft.com/fwlink/?LinkId=33526).

• Los delegados pueden perder su acceso   Para conservar el acceso delegado en Outlook, mueva a la vez a los administradores y a sus delegados desde el sitio remoto de Exchange 5.5 al sitio central. Si no es posible moverlos a la vez, mueva al administrador antes que al delegado o vuelva a conceder derechos de acceso al delegado después del traslado.

• Es preciso volver a designar los destinatarios del diario   Un destinatario del diario es un usuario que se ha configurado para recibir todos los mensajes archivados para un almacén del buzón. Antes de mover el destinatario del diario entre sitios, asigne a otro usuario diferente la designación de destinatario. Después del movimiento puede volver a designar al usuario como destinatario del diario.

• Las reglas de la Bandeja de entrada pueden no funcionar   Si el buzón de un usuario no reside en un servidor con el SP1 de Exchange 2003, las reglas de la Bandeja de entrada basadas en otros usuarios que se hayan movido entre sitios no funcionarán porque ha cambiado el atributo legacyExchangeDN de los usuarios que se han movido. Sin embargo, el usuario puede volver a crear las reglas. Si el buzón del usuario reside en un servidor con el SP1 de Exchange 2003, las reglas seguirán funcionando. Este problema no afecta a los usuarios cuyos buzones se han movido; sólo afecta a los usuarios que tienen reglas basadas en usuarios que se han movido. Una vez que los buzones de todos los usuarios se encuentren en servidores con el SP1 de Exchange 2003, las reglas volverán a funcionar.

• Los nombres de usuario pueden no aparecer brevemente en la GAL de Exchange 5.5   En Exchange 5.5, los nombres de usuario que se han movido entre sitios pueden desaparecer de la lista global de direcciones (GAL) durante un breve período de tiempo hasta que se complete la replicación de directorios. Durante este tiempo, el objeto original de Exchange 5.5 del sitio remoto está oculto mientras el nuevo objeto de Exchange 5.5 se replica al nuevo sitio. La GAL de Exchange 2003 no se ve afectada.

• Algunos usuarios pueden recibir informes de no entrega después de la migración   Después de mover buzones desde Exchange 5.5 al sitio central, si los usuarios de Exchange 5.5 que no se han movido responden al correo de los usuarios de Exchange 5.5 que sí se han movido, recibirán un informe de no entrega (NDR). Esta situación se producirá hasta que se complete la replicación de directorios de Exchange 5.5. Para evitar esta situación, puede forzar la replicación si selecciona Replicar ahora en el Administrador de ADC. Otra opción consiste en redirigir el correo de Exchange 5.5 a través de un servidor cabeza de puente de Exchange 2000 o Exchange 2003 porque estos servidores pueden reenviar el correo al nuevo buzón.

  Nota

  Para eliminar los NDR, quite los conectores entre los sitios de Exchange 5.5 y cree conectores con el sitio central de forma que todo el correo se enrute a través del sitio central o a través de un servidor de Exchange 2003.

• Un usuario autorizado debe realizar una acción del calendario para volver a publicar datos de disponibilidad para buzones de recursos   Los datos de disponibilidad no se transfieren al nuevo servidor cuando mueve buzones entre sitios. Para los usuarios, los datos de disponibilidad se publican en los nuevos servidores quince minutos después de que el usuario inicie sesión en el buzón o realice una acción del calendario (como crear o aceptar una convocatoria de reunión). Sin embargo, para los buzones de recursos (como las salas de reunión), alguien que tenga acceso al buzón de recursos debe abrir el buzón y realizar una acción del calendario para volver a publicar la información de disponibilidad.

• El Servicio de administración de claves necesita la exportación de certificados   El Servicio de administración de claves sigue funcionando después de un movimiento entre sitios si está utilizando certificados X.509 v3, pero no si está utilizando certificados v1. Con los certificados v1, los usuarios que se movieron entre sitios pueden descifrar el correo anterior, pero no pueden firmar ni cifrar mensajes nuevos. Si está utilizando el Servicio de administración de claves, antes de mover usuarios entre sitios, exporte los certificados incluso aunque el mismo servidor del Servicio de administración de claves ofrezca servicio al sitio central. Después del movimiento, importe los certificados en el servidor del Servicio de administración de claves del sitio central. Ejecute la herramienta para actualización de perfiles de Exchange (Exprofre.exe) después del movimiento.

• Exchange Conferencing Server necesita un cambio al modo nativo   Si está ejecutando Exchange Conferencing Server, debe cambiar primero al modo nativo de Exchange y, después, consolidar sitios. De esta forma evitará problemas con los atributos legacyExchangeDN y garantizará un funcionamiento continuado de Exchange Conferencing Server.