Preguntas y respuestas acerca de Exchange
Instalación de Exchange 2003/2007 en un entorno de Exchange 2010
Henrik Walther
Pregunta: ¿Es posible instalar Exchange 2003 ó 2007 en una organización Exchange 2010 pura?
Respuesta: Si se trata de un entorno virgen de Exchange 2010 (una organización Exchange que consta sólo de servidores Exchange 2010 y nunca ha implementado versiones anteriores de Exchange), la respuesta es no. Si pasó de Exchange 2007 a Exchange 2010 y el último servidor Exchange 2007 ya se retiró, la respuesta es nuevamente no. No podrá instalar Exchange 2007 más tarde en esta organización porque ahora se considera una organización Exchange 2010 pura.
Si planea pasar de Exchange 2003 a Exchange 2010 y ya preparó el bosque de Active Directory mediante la instalación de Exchange 2010, nuevamente no puede instalar un servidor Exchange 2007 en la organización. A propósito, recibirá una advertencia que menciona esto al instalar el primer Exchange 2010 en una organización Exchange 2003 pura (ver Figura 1).
.jpg)
Figura 1 La instalación advierte que no puede instalar Exchange 2007 en la organización después de prepararla mediante la instalación de Exchange 2010.
De manera que si cree que necesitará un servidor Exchange 2007 en algún momento, debe mantener un servidor Exchange 2007 en la organización después de pasar de Exchange 2007 a Exchange 2010. O bien, si está pasando de Exchange 2003 a Exchange 2010, debe implementar un servidor Exchange 2007 en la organización antes de preparar el bosque de AD mediante la instalación de Exchange 2010.
Pregunta: Actualmente usamos Exchange 2007 como el sistema de mensajería en nuestro entorno empresarial. Acabamos de actualizar todas nuestras máquinas cliente de Windows XP a Windows 7 y estamos teniendo problemas para instalar las herramientas de administración de Exchange 2007 (SP2) en los nuevos clientes con Windows 7. ¿Alguna cosa especial que debamos tener en mente al instalar las herramientas de administración de Exchange 2007 en Windows 7?
Respuesta: Como Exchange Server 2007 se desarrolló antes de Windows 7, sus herramientas no se admiten en este sistema operativo. El grupo de productos Exchange eligió centrar sus esfuerzos en Exchange 2010, el cual por supuesto sí es compatible con Windows 7.
Lamentablemente, el desarrollo de software siempre está sujeto a restricciones de presupuesto y recursos, y éstas impusieron algunas limitaciones cuando el producto Exchange tuvo que decidir acerca de proporcionar soporte técnico para instalar las herramientas de Exchange en Windows 7. Una consideración importante fue el hecho de que aproximadamente el 65% de todos los clientes que usan Exchange todavía siguen con Exchange 2003 y pasan directamente a Exchange 2010.
La solución es instalar Exchange 2007 Service Pack 3 en los clientes con Windows 7. Sí, oyó bien. Basado en los comentarios de los clientes, el grupo de productos Exchange ha decidido lanzar Exchange 2007 SP3 en la segunda mitad de 2010, lo cual agregará soporte técnico para instalar las herramientas de Exchange 2007 en clientes con Windows 7 y Exchange 2007 en servidores con Windows Server 2008 R2. Puede leer más acerca de los planes para lanzar Exchange 2007 SP3 aquí: https://msexchangeteam.com/archive/2009/11/30/453327.aspx.
Pregunta: Como preparación para una migración planeada de Exchange 2007 a Exchange 2010, instalé un entorno de laboratorio con dos bosques separados de Active Directory. El bosque de AD origen contiene una organización Exchange 2007 y el bosque de AD destino contiene una organización Exchange 2010.
Me parece recordar que cuando realicé una migración entre bosques de Exchange 2003 a Exchange 2007, la organización destino no requirió necesariamente que las cuentas de usuario de Active Directory ya hubieran migrado al bosque de AD destino.
Después de tratar de mover algunos buzones de Exchange 2007 entre bosques a una organización Exchange 2010, parece que los desplazamientos de buzones entre bosques con Exchange 2010 se comportan diferente al equivalente de Exchange 2007.
¿Puede explicar cómo mover buzones entre bosques cuando el destino es una organización Exchange 2010?
Respuesta: Tiene razón en que los desplazamientos de correos entre bosques en Exchange 2010 no funcionan como lo hacían en Exchange 2007.
Tal como indica, el cmdlet Move-Mailbox de Exchange 2007 no requirió necesariamente las cuentas de AD para migrar al bosque de AD antes de desplazar el buzón asociado. El cmdlet Move-Mailbox de Exchange 2007 comprobaba si había alguna cuenta de AD en el bosque de AD destino que coincidiera con alguna dirección proxy (direcciones SMTP), ObjectSID (masterAccountSID, objectSID y sidHistory) origen o legacyExchangeDN (dirección x500 registrada en el objeto de usuario). Si se encontraba una coincidencia, se habilitaba el correo de la cuenta de AD coincidente en el bosque de AD destino. Si no se encontraba una coincidencia, el cmdlet Move-Mailbox creaba una cuenta deshabilitada de usuario de AD con el buzón habilitado.
Con Exchange 2010, las cosas han cambiado. Primero, el cmdlet Move-Mailbox ya no se usa. Este cmdlet se reemplazó por el nuevo y moderno cmdlet New-Move, el cual, a propósito, trae consigo varias mejoras bastante buenas. Además, al mover buzones entre bosques mediante el cmdlet New-Move Request, Exchange 2010 espera encontrar un usuario de correo válido e intenta hacer coincidir la cuenta origen con una cuenta destino mediante msExchMailboxGUID. A diferencia de Exchange 2007, no tratará de hacer coincidir una cuenta destino mediante los atributos mencionados anteriormente. Esto significa que antes de que pueda hacer desplazamientos entre bosques con Exchange 2010, debe aprovisionar el bosque de AD destino con usuarios de correo.
A propósito, a diferencia de Exchange 2007, ahora puede mover buzones entre bosques mediante la Consola de administración de Exchange 2010 (ver Figura 2). Tan sólo debe agregar la organización Exchange desde el bosque de AD destino a EMC primero.
.jpg)
Figura 2 Ventana de solicitud de desplazamiento remoto de Exchange 2010
Puede crear usuarios de correo en la organización Exchange 2010 destino mediante el script PrepareMoveRequest.ps1 descrito en esta sección o en Microsoft TechNet o mediante Identity Lifecycle Management (ILM) 2007 FP1 (con la revisión más reciente que habilitará el aprovisionamiento de Exchange 2010 para ILM 2007 FP1) o mediante Forefront Identity Management (FIM 2010), el cual está actualmente disponible en una release candidate 1 y saldrá al mercado más tarde el primer trimestre de 2010.
Pregunta: Nuestra organización actualmente tiene implementado Exchange 2007. Tenemos una solución de alta disponibilidad que consta de 4 servidores de Exchange 2007: dos servidores que tienen los roles del servidor Transporte de concentradores y de acceso de cliente instalados, y dos servidores que actúan como nodos del clúster del servidor del buzón en un clúster de replicación continua de clústeres (CCR). Los servidores de Exchange 2007 en que están instalados los roles del servidor Transporte de concentradores y de acceso de cliente se han configurado en un NLB de Windows a fin de equilibrar la carga y proporcionar una conmutación por error automática para las conexiones entrantes cliente y de SMTP. Esta solución funciona bien, pero ahora que se lanzó Exchange 2010, deseamos pasar a esta versión de servidor de Exchange más reciente. No sólo hay varias características nuevas que deseamos utilizar, sino que además hemos escuchado que podemos reducir la cantidad de servidores de Exchange a dos sin perder las funciones de HA que ya conocemos.
¿Existen consideraciones especiales que debamos tener en cuenta antes de pasar a una solución HA de Exchange que consta de sólo dos servidores?
Respuesta: Sí, a fin de crear una solución de mensajería de Exchange 2007 altamente disponible con conmutación por error automática y sin ningún punto de error a nivel de hardware o almacenamiento, necesitaba un total de cuatro equipos: dos servidores con los roles del servidor Transporte de concentradores y de acceso de cliente de Exchange 2007 instalados, y dos que actúan como nodos en un clúster basado en replicación continua de clústeres (CCR).
El Transporte de concentradores posee equilibrio de carga integrado y conmutación por error para comunicación al interior del sitio y lo puede hacer redundante mediante mecanismos por turnos DNS. Pero como el rol de servidor de acceso de cliente no incluye ninguna funcionalidad de equilibrio de carga, normalmente también tenía que configurar estas dos máquinas como nodos en un clúster de equilibrio de carga de red de Windows (WNLB) para proporcionar equilibrio de carga y conmutación por error automática para conexiones entrantes desde clientes y servidores en Internet y otras redes externas.
Las dos máquinas que actúan como nodos del clúster en el clúster de CCR tenían los roles de servidor de buzón activo y pasivo instalados respectivamente, de manera que el servidor del buzón en clúster (CMS) podía cambiar o conmutar por error a cualquiera de los dos nodos. Por último, dedicaba uno de los servidores de front-end como testigo del recurso compartido (tercer voto) en el clúster de CCR.
Como probablemente ya sabe, CCR (y SCC, LCR y SCR en este caso) se ha eliminado de Exchange 2010. En su lugar, Exchange 2010 introduce una nueva característica denominada Grupos de disponibilidad de base de datos (DAG). Esta características usa la misma tecnología de sincronización que CCR y SCR combinadas, pero tiene tantas características nuevas y tantas otras funciones que es significativamente mejor que CCR y SCR. Un aspecto interesante de Exchange 2010 es que es compatible con otros roles de Exchange 2010 (Transporte de concentradores, acceso de cliente e incluso mensajería unificada) instalados en el mismo servidor en el cual tiene un rol de servidor de buzón que se ha agregado a un DAG. Esto significa que ya no necesita dedicar dos máquinas como servidores front-end para los roles del servidor del Transporte de concentradores y de acceso de cliente. Simplemente instale todos los roles de Exchange 2010 requeridos en las dos máquinas y listo, tiene una solución de mensajería basada en Exchange 2010 completamente redundante. Bueno, casi. Sí, sonaba demasiado bueno para ser verdad, ¿no es así?
Pues verá, como los DAG usan el componente de Clúster de conmutación por error de Windows (WFC) hasta cierto punto (principalmente latido y la base de datos del clúster), no puede configurar los dos servidores como nodos en un NLB de Windows, ya que no admite el uso de ambos WFC y WNLB en el mismo servidor. Esto no se ha admitido desde Windows NT 4.0 y se debe a posibles conflictos de uso compartido de hardware entre el servicio de clústeres y WNLB. Lea este artículo de KB para obtener más información: https://support.microsoft.com/default.aspx?kbid=235305.
Esto significa que debe usar un dispositivo externo de equilibrio de carga/conmutación por error como equilibrador de la carga basado en hardware. Además, tenga en cuenta que este equilibrador deber ser redundante, así que necesita un mínimo de dos dispositivos.
Aunque todavía usa WFC y aunque DAG es una característica de Enterprise Edition, en realidad no necesita Exchange 2010 Enterprise Edition para utilizar DAG. A diferencia del CCR de Exchange 2007, DAG también se incluye con la Standard Edition de Exchange 2010. Pero tenga en cuenta que está limitado a un total de cinco bases de datos (incluidas copias de base de dato activas y pasivas) en este escenario.
Como instala los roles de CAS y HT en la misma máquina que el rol de servidor de buzón y es un servidor miembro de DAG, puede ahorrarse dos máquinas y dos licencias de Standard Edition de Windows 2008 y Exchange 2010. Si aún no tiene un equilibrador de carga externo en su entorno, puede usar un dispositivo equilibrador de carga virtual o comprar un equilibrador de carga basado en hardware. Por supuesto, necesita un servidor que actúe como el servidor testigo también, pero aunque es una práctica recomendada, no tiene que ser necesariamente un servidor de Exchange. Podría ser cualquier servidor de archivos de Windows 2003/2008 de su entorno.
Henrik Walther es un MVP experto certificado de Microsoft de Exchange 2007 y Exchange con más de 15 años de experiencia en el campo de TI. Trabaja como arquitecto tecnológico para Trifork Infrastructure Consulting (Microsoft Gold Certified Partner con base en Dinamarca) y como escritor técnico para Biblioso Corp. (una empresa con base en Estados Unidos que se especializa en documentación administrada y servicios de localización).