Preguntas y respuestas sobre ExchangeAlineación de particiones de disco y planeamiento para SCR, entre otros temas

Henrik Walther

P Actualmente estoy planeando una migración de Exchange Server 2003 a una nueva organización de Exchange Server 2007. Para replicar las carpetas públicas en la nueva organización planeo usar la herramienta Microsoft® InterOrganization Replication (IORepl). Pero he oído que IORepl no es compatible con un servidor Exchange 2007 de destino y que se debe incorporar un servidor Exchange 2003 en la organización de Exchange de destino.

R Aunque ha habido rumores acerca de que no se admite la réplica de datos de disponibilidad o carpetas públicas entre una organización de Exchange 2003 y una organización de Exchange 2007, eso no es cierto. De hecho, se admite totalmente el uso de IORepl en un servidor que tenga instaladas las herramientas de administración de Exchange 2007 sin otras funciones de servidor de Exchange 2007. No obstante, tenga en cuenta que también debe instalar el cliente MAPI (interfaz de programación de aplicaciones de mensajería) de Microsoft Exchange Server y CDO (Collaboration Data Objects) en el servidor, ya que no se proporcionan como parte de la instalación del producto base.

P Estoy realizando un diseño de Exchange Server 2007 para una organización grande que consta de 150.000 puestos y necesito calcular el número de servidores de catálogo global que necesita la infraestructura de mensajería de Exchange 2007. ¿Podrían ayudarme?

Faltaría más. Esa es la razón principal por la que existe esta columna. En primer lugar, es importante saber que el número de servidores de catálogo global necesarios (o más específicamente, cuántos núcleos, y no nos referimos a los procesadores) se calcula según el número total de núcleos de servidor de buzones de Exchange 2007 que se planea usar. Tenga en cuenta que el número de núcleos de servidor de catálogo global se calcula sólo según los servidores de buzones; no se incluyen otras funciones de servidor de Exchange 2007: acceso de cliente, transporte de concentradores, mensajería unificada o transporte perimetral. Aunque las demás funciones de servidor de Exchange 2007 influyen en el número de servidores de catálogo global necesarios, el número de servidores de buzones que están implementados influye en las demás funciones de servidor de Exchange 2007, lo que significa que puede calcular el número necesario de servidores de catálogo global según el número de servidores de buzones.

Además, el número de núcleos de catálogo global depende de si usan controladores de dominio de 32 o 64 bits en la infraestructura de Active Directory®. Con controladores de dominio de 32 bits se usa una proporción de 4 a 1, lo que significa que debe planear el disponer de un núcleo de catálogo global por cada cuatro núcleos de servidor de buzones. Con los controladores de dominio de 64 bits, la proporción es de 8 a 1. De este modo, por ejemplo, si implementa servidores de buzones de Exchange 2007 con ocho núcleos instalados y usa controladores de dominio de 64 bits, necesitará un servidor de catálogo global por servidor de buzones de Exchange 2007. Finalmente, al usar controladores de dominio de 64 bits, asegúrese de instalar suficiente memoria para que toda la base de datos de Active Directory (archivo NTDS.DIT) se pueda almacenar en caché en la memoria.

P En la respuesta anterior se explican las recomendaciones en relación con el número de servidores de catálogo global por servidor de buzones de Exchange 2007. ¿Cómo calculo el número de funciones de servidor de transporte de concentradores y acceso de cliente de Exchange 2007 que debo implementar?

R Tal como sugiere la respuesta anterior, el número de servidores de acceso de cliente y de transporte de concentradores de Exchange 2007 (o más específicamente, núcleos de servidor) que debe implementar está vinculado al número de núcleos de servidor de buzones. No existe ninguna regla definitiva aunque, por norma general, se trata de un núcleo de servidor de acceso de cliente por cuatro núcleos de servidor de buzones (proporción 4 a 1) y un núcleo de servidor de transporte de concentradores por siete núcleos de servidor de buzones (7 a 1). El último dato se refiere a servidores de transporte de concentradores sin análisis antivirus instalado. Con un producto de análisis antivirus instalado, como Forefront Security para Exchange, la proporción por lo general se acerca más a un núcleo de servidor de transporte de concentradores por cada cinco núcleos de servidor de buzones (proporción 5 a 1).

P He oído que no se recomienda instalar más de ocho núcleos de procesador en un servidor Exchange 2007. ¿Es verdad? Y si lo es, ¿por qué?

R Sí, es verdad. Aunque Exchange Server 2007 se beneficia considerablemente de la instalación de procesadores con varios núcleos, el número máximo de núcleos que debe instalar en un servidor Exchange 2007 es ocho. Más específicamente, de hecho sólo dos funciones de servidor de Exchange 2007 se pueden beneficiar del uso de núcleos adicionales (hasta ocho): Transporte de concentradores y Buzón. Y sólo se aplica a servidores Exchange 2007 muy ocupados que sirven millones de mensajes al día y almacenan miles de cuentas.

El grupo de productos de Exchange realmente ha efectuado pruebas con 12 núcleos de procesador instalados en un servidor de buzones de Exchange 2007 y ha apreciado efectos negativos en el rendimiento de almacenamiento y en la escalabilidad. También observaron que la latencia media de llamada a procedimiento remoto (RPC) se duplicó al pasar de 8 a 16 núcleos.

A menos que espere servidores de buzones extraordinariamente ocupados, por lo general es suficiente con cuatro núcleos de procesador. Para obtener información adicional y consideraciones de procesador para las demás funciones de servidor de Exchange 2007, consulte technet.microsoft.com/aa998874.

P Actualmente estamos llevando a cabo una migración entre bosques de una organización de Exchange 2000 y Exchange 2003 a una nueva organización de Exchange 2007. No obstante, cuando intentamos mover un buzón del bosque de origen con el cmdlet Move-Mailbox con el parámetro -SourceMailboxCleanupOptions DeleteSourceMailbox especificado, aparece el siguiente error:

"Aunque se movió el buzón al servidor Exchange de destino y se quitó del servidor de Exchange de origen, se produjo un error al eliminar los atributos del buzón del usuario de buzón de origen. La versión del sistema operativo del controlador de dominio 'file01' es 5.0 (2195) Service Pack 4. La versión mínima requerida es 5.2 (3790) Service Pack 1."

Existe un controlador de dominio basado en Windows Server® 2003 (que también es un servidor de catálogo global) en el bosque de origen, pero parece que no se puede especificar el controlador de dominio en el bosque de origen que se debe usar, ya que el parámetro –DomainController sólo puede indicar un controlador de dominio o un servidor de catálogo global en el bosque de destino. ¿Estoy en lo cierto? Si es así, ¿hay alguna solución?

R Es correcto. No se puede especificar un controlador de dominio o un servidor de catálogo global del bosque de origen como parte del cmdlet Move-Mailbox; el controlador de dominio (servidor de catálogo global) se seleccionará automáticamente. Existe un par de soluciones, pero ninguna de ellas parece muy adecuada. La primera es retirar cualquier controlador de dominio basado en Windows® 2000 del bosque de origen, pero sé que normalmente no es posible. La segunda solución puede resultar útil en su situación. El cmdlet Move-Mailbox necesita usar un controlador de dominio que también actúe de servidor de catálogo global, lo que significa que puede resolver el problema si quita la función de servidor de catálogo global de cualquier servidor Windows 2000 del bosque de origen. He empleado este método con éxito en un par de escenarios de migración, así que definitivamente merece la pena probarlo.

P ¿Se puede instalar un servidor de acceso de cliente, transporte de concentradores o buzones de Exchange 2007 en un sitio de Active Directory como, por ejemplo, Estados Unidos y después enviar el servidor a otro sitio de Active Directory como, pongamos, Dinamarca? Si se admite esta acción, ¿el servidor Exchange 2007 detectaría la nueva pertenencia a sitio de Active Directory automáticamente o se tendría que intervenir manualmente?

R Sí, este escenario se admite por completo y no se requiere intervención manual. Los servicios Inicio de sesión en red (NetLogon) y Topología de Active Directory de Microsoft Exchange (MSExchangeADTopology) se ocupan de la pertenencia a sitio para un servidor Exchange 2007. Si el servidor cambia de pertenencia a sitio, el servicio MS­ExchangeADTopology actualiza automáticamente el atributo de sitio del servidor, denominado atributo msExchServerSite. Tal como muestra la figura 1, se puede ver el atributo msExchServerSite con una herramienta como ADSIEdit.

Figura 1 Presentación del atributo msExchServerSite (haga clic en la imagen para ampliarla)

Si desea profundizar en el modo en que los sitios de Exchange 2007 y Active Directory se relacionan entre sí, le recomiendo que consulte la sección de la documentación de Exchange 2007 denominada "Descripción del enrutamiento basado en sitios de Active Directory" en technet.microsoft.com/aa998825.

P ¿En un servidor de buzones de Exchange 2007 con la replicación continua local (LCR) habilitada para las bases de datos de buzones, se puede usar Microsoft Data Protection Manager 2007 (DPM 2007) para hacer copia de seguridad del buzón mediante la copia de base de datos de buzones pasiva?

R Aunque se puede usar DPM 2007 para hacer copia de seguridad de las bases de datos de buzones mediante el nodo pasivo de un entorno de replicación continua en clúster (CCR) de Exchange 2007, no se admite al tratar con copias de base de datos de buzones en un entorno LCR de Exchange 2007.

P Se puede migrar una base de datos de servidor de buzones de correo en clúster (CMS) de Exchange Server 2007 a un servidor de buzones de correo independiente, pero ¿se puede montar una base de datos no clúster en un CMS de Exchange 2007 basado en SCC (clúster de copia única) o CCR?

R Debido a que un almacén de información de Exchange Server 2007 no conoce el tipo de servidor en el que se encuentra, se admite por completo el montaje de una base de datos no clúster CMS basado en CCR o SCC.

P Según el artículo disponible en technet.microsoft.com/bb508861, el servicio de mensaje de cuota (QMS) de Exchange Server no se admite en un servidor Exchange 2003 en clúster. Sin embargo, ¿este servicio se admitirá en el futuro para Exchange 2003 o para entornos en clúster de Exchange 2007?

R La herramienta QMS de Exchange Server no se admitirá en los CMS de Exchange 2003 en el futuro. Además, la herramienta QMS no se admite con servidores de buzones de Exchange 2007 en clúster (tampoco para no clúster). Pero si usa Exchange 2007 en su organización, realmente no hay motivo para instalar la herramienta QMS, ya que en Exchange está incluida la misma funcionalidad de forma nativa. Para obtener más información acerca del modo de administrar los mensajes de cuota en Exchange 2007, consulte technet.microsoft.com/bb232089.

P ¿Conoce alguna documentación de referencia que enumere los atributos que se establecen en usuarios u objetos de grupo de Active Directory cuando estas entidades están habilitadas para buzón o correo, respectivamente?

R En la referencia del modelo de permisos divididos en la documentación de Exchange 2007 se enumeran estos atributos. Encontrará el artículo en technet.microsoft.com/bb430782.

P ¿Existe algún modo de designar un servidor de transporte de concentradores de Exchange 2007 como un servidor cabeza de puente para el flujo de correo interno en nuestra infraestructura de mensajería de Exchange 2007. La idea sería, por ejemplo, que todo el correo enviado desde el sitio de Active Directory 1 al sitio de Active Directory 2 se enrutara mediante el servidor de transporte de concentradores A (que se encuentra en el sitio de Active Directory 1) al servidor de transporte de concentradores B (que se encuentra en el sitio de Active Directory 2) y viceversa. ¿Funcionará esto?

R No. Para que funcione, el servidor de buzones en los sitios de Active Directory debe saber si los destinatarios se encuentran en otro sitio de Active Directory. La función de servidor de buzones de Exchange 2007 no tiene integrado dicho mecanismo.

A menos que el servidor de transporte de concentradores se instale localmente en un servidor de buzones, éste siempre equilibrará la carga de las conexiones entre los servidores de transporte de concentradores en el mismo sitio de Active Directory. (Si la función de servidor de transporte de concentradores está instalada en el servidor de buzones, siempre se preferirá el servidor de transporte de concentradores que esté en el mismo equipo físico que el servidor de buzones.)

Sólo después de la categorización Exchange 2007 sabrá dónde se encuentra el buzón de correo del destinatario. Lo más cerca que puede estar de conseguir este objetivo es usar el parámetro SubmissionServerOverrideList con el cmdlet Set-MailboxServer para crear una lista estática de servidores de transporte de concentradores que debe usar un servidor de buzones, tal como se muestra en la figura 2 (consulte technet.microsoft.com/bb232193).

Figura 2 Configuración del servidor de buzones (haga clic en la imagen para ampliarla)

Esto significa que si especificó el servidor de transporte de concentradores A o B, el servidor de buzones siempre usará dicho servidor de transporte de concentradores, no sólo para los mensajes enviados a los destinatarios de un sitio específico sino para todos los sitios de Active Directory, así como para la entrega de mensajes locales. Debido a que esto, en teoría, supondría una posibilidad de error, no aconsejo que se use este método.

P Estoy planeando instalar servidores de buzones de Exchange Server 2007 SP1 en Windows Server 2008 y estaba considerando la posibilidad de alinear discos. Sé que con Exchange Server 2003 o Exchange Server 2007 instalados en servidores con Windows Server 2003, se recomienda crear particiones que contengan los archivos de registro de transacciones y los almacenes de buzones con la herramienta diskpart para mejorar el rendimiento global. Según las recomendaciones del fabricante también se aconseja alinear la partición de almacenamiento. Si el fabricante no ofrece ninguna recomendación, el procedimiento recomendado de Microsoft sugiere el uso de un valor de 64 KB.

Al instalar servidores de buzones de Exchange 2007 en Windows Server 2008, ¿cómo debo configurar las alineaciones de disco? ¿Se aplican las mismas reglas?

R ¿Sabe qué? Con Windows Server 2008, ya no necesita efectuar una alineación de pistas de las particiones de disco que almacenarán archivos de registro de transacciones y bases de datos de buzones de Exchange Server 2007 SP1 con la herramienta diskpart. Con Windows Server 2008 se han corregido los problemas de alineación de particiones de disco de Windows Server 2003, donde una partición siempre debe empezar en el sector 64 y, por lo tanto, se alinea mal toda la partición al usar la herramienta Administración de discos de Windows.

En el blog del equipo de Exchange en msexchangeteam.com/archive/2005/08/10/408950.aspx se puede encontrar más información acerca del problema de alineación de pistas. Además, Windows Server 2008 alinea una partición de disco mediante el uso de un límite de 1024 KB. La documentación de Exchange Server 2007 en TechNet también lo menciona en technet.microsoft.com/bb738145.

P Actualmente estamos en la fase de planificación de la implementación de la replicación continua en espera (SCR) en nuestro entorno de mensajería basado en Exchange Server 2007 SP1. Nuestra empresa es relativamente pequeña y no podemos permitirnos la implementación de más de un equipo físico con un servidor Exchange 2007 que actúe como el destino de SCR en un segundo sitio.

No estamos muy seguros de si se admiten otras funciones aparte de la función de servidor de buzones en el destino de SCR.

R Sí, el servidor Exchange SCR tanto de origen como de destino puede ejecutar otras funciones de Exchange 2007 SP1. Esto significa que se admite por completo, por ejemplo, la implementación de servidores Exchange 2007 SP1 con las funciones de servidor de acceso de cliente, transporte de concentradores y buzones instaladas y su uso como destinos de SCR.

P Nuestra organización, que se basa en un bosque de Active Directory de Windows Server 2003 y una infraestructura de mensajería de Exchange 2007, pronto necesitará fusionarse con una organización recién adquirida. Uno de los requisitos cuando se fusionen las dos organizaciones es que las listas de direcciones de Exchange 2007 estén segregadas, de modo que los usuarios de cada organización sólo puedan ver una lista de direcciones que contenga sus propios usuarios.

Me parece recordar algunos artículos de Microsoft Knowledge Base que incluían instrucciones paso a paso acerca de cómo realizar esta tarea en un entorno de Exchange 2003. ¿Qué método debe seguirse para segregar listas de direcciones en un entorno de mensajería basado en Exchange 2007?

R Se necesitaría mucho más espacio del que dispongo aquí para describir todos los pasos necesarios. Afortunadamente, Microsoft ha publicado recientemente un artículo técnico en el que se explica cómo se pueden configurar organizaciones virtuales y la segregación de listas de direcciones en Exchange 2007. El documento se puede encontrar en technet.microsoft.com/bb936719. Además, debe dedicar unos minutos a leer la publicación que incluye comentarios acerca de este documento en el blog de Dave Goldman (consulte go.microsoft.com/fwlink/?LinkId=115499).

P ¿Requiere Exchange 2007 el servicio de nombres de Internet de Windows (WINS) para funcionar correctamente?

R El producto Exchange Server 2007 no requiere WINS. Pero puede que WINS se necesite según la versión de Microsoft Office Outlook® que se use en su entorno de mensajería de Exchange Server 2007. Si su entorno de mensajería consta estrictamente de servidores Exchange 2007 y clientes de Outlook 2007 o de Outlook 2003, no se requiere WINS.

Bueno, hay una situación muy poco habitual en la que Outlook 2007 necesita WINS. Al migrar un buzón a un nuevo bosque de Exchange, la versión RTM de Outlook 2007 intentará conectarse al servidor de buzones de Exchange con el nombre NetBIOS y no el nombre de dominio completo (FQDN) del modo previsto. No obstante, este problema se ha corregido con el paquete de revisión posterior a SP1 de Outlook 2007 publicado en enero de 2008 (support.microsoft.com/?id=941275).

Si sus usuarios finales tienen Outlook 2002, siempre se requerirá WINS, ya que este cliente se basa en la resolución de nombres de NetBIOS. Específicamente no menciono los clientes de Outlook anteriores a Outlook 2002 ya que no se admiten con Exchange 2007, pero lo mismo sucedería con ellos.

Henrik Walther es Microsoft Certified Architect especializado en mensajería. Además, es MVP de Exchange y cuenta con más de 14 años de experiencia en el sector de TI. Trabaja como arquitecto de tecnología para Interprise Consulting y como escritor técnico para Biblioso Corporation.