Instalando Exchange 2007 en una organización Exchange 2003


Por Daniel Seveso


Seguramente ahora que el producto está liberado al público (casi SP1 al escribir este artículo), tu preocupación ya no es meramente instalar Exchange 2007 para probarlo, sino cómo instalarlo en tu actual organización. Voy a dedicar unos momentos entonces a la coexistencia.  Este artículo considera un escenario de un solo grupo administrativo y un solo grupo de enrutamiento o Routing Group en Exchange 2003, donde se instalará Exchange 2007 como paso inicial de una migración a la nueva versión.



Planificación de la instalación


Independientemente si tu organización tiene uno o más servidores de Exchange 200x, siempre tienes que planificar cualquier cambio para tu ambiente en particular. Este artículo no está pensado como guía de instalación, solo representa un ejemplo en un ambiente simplificado para que tengas idea de lo que involucra. Puedes utilizar los recursos en TechNet como guía para esta planificación.


El escenario aquí presentado es de transición. No es una migración a una nueva organización de Exchange 2007 sino la incorporación de los servidores a la organización existente, posterior movimiento de la información de usuarios, terminando con el retiro de los servidores Exchange 200x.


Es importante destacar que una vez que la organización se compone únicamente de servidores Exchange 2007 no es posible instalar versiones previas de Exchange. El siguiente esquema representa las distintas fases de la integración.



 


Para este ejercicio, he elegido un escenario sencillo aunque bastante común. Una organización nativa con dos servidores Exchange 2003. Los aspectos relevantes están marcados en la siguiente figura:


          Unico Administrative Group (First Administrative Group)


          Dos servidores Exchange 2003 – NETE2K3 y NETE2K3FE  back-end y front-end respectivamente


          Unico Routing Group (First Routing Group)


          Un conector de salida a internet (SMTP Connector)



 


Confirmando requerimientos


Exchange 2007 puede ser instalado en organizaciones que estén en modo nativo Exchange 2000 ó Exchange 2003 y puede coexistir en combinación con ambas versiones. Si todavía estás en modo mixto tendrás que quitar los servidores Exchange 5.5 de tu organización si es que los hay, y luego cambiar a modo nativo.


Otro detalle a tomar en cuenta es que Exchange 2007 no permite actualización desde una versión previa de Exchange en el mismo servidor.  Por lo que necesariamente tendremos una nueva máquina de 64bits corriendo alguno de los sistemas operativos de 64 bits soportados.


Antes de instalar Exchange 2007 deberás asegurarte que tu ambiente cumpla con los requisitos básicos para su instalación. Lo mejor es correr el “Exchange 2007 Readiness Check” de la herramienta ExBPA.



Instalación del primer servidor Exchange 2007


La instalación del primer Exchange 2007 creará un grupo de seguridad universal llamado ExchangeLegacyInterop con el que se dan permisos a los servidores Exchange 200x para que puedan enviar mensajes a Exchange 2007. También crea el Exchange Administrative Group (FYDIBOHF23SPDLT), el Exchange Routing Group (DWBGZMFD01QNBJR) y el conector correspondiente que conecta con el routing group existente.


El proceso de instalación, incluye los prerrequisitos (Microsoft .NET Framework 2.0, MMC 3.0 y Microsoft Windows PowerShell), la preparación de Active Directory, y la instalación de cada rol de Exchange 2007.


Al correr el setup de  Exchange Server 2007, se verificarán además los prerrequisitos  para los roles elegidos, indicando si tienes que instalar componentes adicionales. Por ejemplo, si instalas CAS te pedirá instalar Common Components y WWW Services de IIS, etc.


Antes de iniciar la instalación, te recomiendo correr el Exchange 2007 Readiness Check, que es una de las pruebas incluidas en la herramienta Exchange Best Practicews Analyzer 2.8 o superior.


Nuestro nuevo servidor Exchange 2007 será instalado en un Windows 2003 server llamado NETE12-1. Al correr ExBPA en NETE12-1 veremos un aviso de que el schema no ha sido actualizado para Exchange 2007. La preparación de Active Directory, incluida la actualización del schema, puede realizarse tanto como parte del proceso de setup, o cada paso en forma separada. La separación de los procesos de preparación, permite correr los diferentes procesos con diferentes cuentas para cubrir los casos donde la administración del directorio, schema y Exchange son separadas.  La preparación de AD consta de los siguientes procesos que pueden ser invocados como opciones del setup (ej: setup /PrepareSchema):


          PrepareLegacyExchangePermissions: Otorga permisos a los servidores Exchange 200x a través del grupo Exchange Enterprise Servers en el nuevo Exchange-Information property set (grupo de propiedades definidas por Exchange)


          PrepareSchema: Agrega nuevos atributos y clases al schema, y modifica atributos y clases existentes para soportar los nuevos objetos en Exchange 2007.


          PrepareAD: Prepara el dominio local para la instalación de Exchange 2007. Configura los objetos globales de Exchange, crea los grupos de seguridad de Exchange en el dominio raíz y establece los permisos en los objetos de configuración de Exchange. Este proceso también crea los objetos que representan el Administrtive Group y el Routing Group de Exchange 2007.


Se puede verificar que este proceso finalizó correctamente confirmando la creación de la OU Microsoft Exchange Security Groups con los 5 grupos universales que aparecen en la figura:



 


          PrepareDomain: Hace parte del trabajo de PrepareAD. Prepara solo el dominio local (por ejemplo un child domain). No es necesario ejecutar este proceso en el dominio local si ya se corrió PrepareAD. Si tienes un ambiente multi-dominio, este proceso debe ser ejecutado en cada dominio donde instales Exchange 2007 o haya usuarios de Exchange 2007.


En nuestro escenario, correremos la instalación con una cuenta Enterprise Admin en un único dominio, que además es Full Exchange Administrator, por lo que no será necesario correr los procesos en forma independiente. Cuando analizamos luego el ExchangeSetup.log del primer servidor instalado, podemos ver que el proceso de setup corrió la preparación automáticamente:


[0] Setup is determining what organization-level operations to perform.
[0] Setup has detected a missing value. Setup is adding the value PrepareLegacyExchangePermissions.
[0] Setup has detected a missing value. Setup is adding the value PrepareSchema.
[0] Setup has detected a missing value. Setup is adding the value PrepareOrganization.
[0] Setup has detected a missing value. Setup is adding the value PrepareDomain.


Volviendo al reporte de ExBPA, también veremos un warning avisando que no hemos configurado la supresión de actualizaciones en la tabla de ruteo de Exchange 200x.  No es necesario implementar la supresión de actualizaciones de ruteo en base a la disponibilidad del conector cuando tenemos un sólo routing group connector entre Exchange 200x y Exchange 2007, lo cual aplica para nuestro escenario. En ambientes más complejos, con más routing groups y más de un routing group connector entre 200x y 2007 debemos suprimir la propagación de estos cambios configurando la clave de registry en los bridgehead servers de estos conectores.


HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters
SuppressStateChanges (Dword) = 1



 



Instalación de Roles


Con la instalación del primer servidor, instalaré los roles Mailbox, Client Access y Hub Transport para tener un servidor completamente funcional.


Cuando corremos setup.exe, presentará el siguiente diálogo indicando que prerrequisitos están instalados y cuales faltan instalar. Las líneas de prerrequisitos en el diálogo, contienen el link a los puntos de instalación de cada componente. Una vez instalado el prerrequisito, el asistente de instalación mostrará el mismo grisado indicando que ya ha sido instalado.



En este caso, estoy instalando sobre un Windows 2003 R2 por lo que MMC 3.0 ya está instalado. Para completar los requerimientos, instalamos Microsoft.Net Framework 2.0 y PowerShell 1.0.


Hay una actualización de .NET que es necesario instalar para que sea posible la instalación de Exchange. Si no lo instalas previamente el setup te indicara que lo tienes que hacer proveyéndote el siguiente link para su instalación. El artículo que describe esta actualización es KB926776.


Luego lanzamos la instalación de Exchange (Step 3) e indicamos el servidor NETE2K3FE como Bridgehead en el wizard. Elegí el NETE2K3FE a fines ilustrativos, pero en una situación práctica, sería más conveniente rutear los mensajes directamente al servidor de mailboxes NETE2K3 y ahorrarnos el salto por NETE2K3FE.


Cuando la instalación finaliza, obtendremos el resultado del wizard para cada una de las tareas de instalación requeridas.



Luego de instalado Exchange 2007, el Exchange System Manager mostrará la siguiente configuración:



Se habrán creado el nuevo Administrative Group (FYDIBOHF23SPDLT) y Routing Group (DWBGZMFD01QNBJR), el objeto correspondiente al nuevo servidor NETE12-1 y un Routing Group Connector (NETE12-1-NETE2K3FE y NETE2K3FE-NETE12-1 respectivamente) que provee conectividad entre Exchange 2007 y el existente “First Routing Group”. Este conector es creado automáticamente durante la instalación del primer servidor con rol Hub Transport, y se encargará del flujo de mensajes entre Exchange 2003 y Exchange 2007. Un punto importante es que este Routing Group Connector, y ningún conector que tenga un bridgehead Exchange 2007, se puede administrar usando Exchange System Manager. Es necesario usar Set-RoutingGroupConnector cmdlet del Exchange Management Shell.



Consolas de administración


Como habrán notado, la interface de administración cambió de nombre. Exchange System Manager es Exchange 2000 o 2003, Exchange Management Console es Exchange 2007. Con alguna excepción, no existe interoperabilidad entre las herramientas de administración, por lo que los objetos creados por Exchange 2007 deberán ser administrados por Exchange Management Console (EMC) o Exchange Management Shell (EMS) y los creados por Exchange 2003 seguirán siendo administrados mediante Exchange System Manager (ESM). Algunos de los objetos como las listas de direcciones pueden ser “Actualizadas” para poder ser administradas por EMC o EMS. Si intentamos administrar una lista de direcciones que no ha sido actualizada (por ejemplo “All Users”) con EMC tendremos el siguiente aviso:



Si intentamos administrar uno de los Routing Group Connectors creados por Exchange 2007 mediante ESM, también tendremos el aviso correspondiente:



Las carpetas públicas también estan afectadas por esta restricción. Las carpetas públicas de Exchange 2000/2003 se administran via ESM, mientras que las de 2007 se administran con EMC o EMS.


 


Prueba de funcionamiento


A este punto, Exchange 2007 se encuentra en funcionamiento (o por lo menos es lo que esperamos J). Aunque muchas de las tareas post-instalación aún están pendientes, podemos verificar la funcionalidad e integración del nuevo servidor. El Event Viewer y los logs de instalación, son buenos recursos por donde comenzar si sospechas de algún problema. (ExchangeSetup.log y ExchangeSetup.msilog los encuentras ahora en C:\ExchangeSetupLogs)


Crea un usuario en Exchange 2007 (usando EMC) y envía un mensaje desde un usuario en Exchange 2003. Si tienes un ambiente como el anteriormente descrito, el mensaje se transmitirá desde el servidor de Mailbox NETE2K3 al Front-End NETE2K3FE y luego al nuevo servidor NETE12-1. La razón por la cual el mensaje pasa por el Front-End, es porque NETE2K3FE es el “bridgehead” del Routing Group Connector “NETE2K3FE-NETE12-1” que conecta el First Routing Group con el mundo Exchange 2007.


Puedes verificar y responder el mensaje recibido en NETE12-1 usando OWA, accediendo directamente en el servidor Exchange 2007 a la nueva dirección https://NETE12-1/owa.



Migración de información


Luego de haber probado el funcionamiento básico del nuevo servidor, puedes proceder a mover los buzones de usuario desde NETE2K3 a NETE12-1, usando el “Move Mailbox Wizard” incluido en EMC.




Puedes también usar el cmdlet de EMS Move-Mailbox para realizar la misma operación.


Retirando los servidores Exchange 2003


Retirar los servidores no es algo que necesites hacer inmediatamente, pero tarde o temprano terminarás haciéndolo. Esta es una de las etapas más críticas del proceso ya que hay varios aspectos en consideración. Hay una sección completa en TechNet “How to Remove the Last Legacy Exchange Server from an Organization” donde se detalla cómo llevar a la práctica los pasos necesarios y las razones para los mismos:


·         Una vez que se retira el último Exchange 2000 o 2003 de la organización, no es posible instalar ninguna versión previa a Exchange 2007. Por lo tanto, debes asegurarte que no estés usando alguna de las funcionalidades que fueron retiradas del producto, como Mobile Information Server, conector de Novell GroupWise, etc.


·         Las carpetas públicas y la generación del Offline Address Book deben ser movidas a un servidor Exchange 2007.


·         Los conectores existentes deben ser migrados a Exchange 2007 (para nuestro organización de ejemplo, el “SMTP Connector” debe ser reemplazado por un Send Connector en Exchange 2007).


·         Los “Public Folder Store” deben ser eliminados de los servidores Exchange 2003 para actualizar estructura de replicación de carpetas públicas.


·         Es necesario realizar las modificaciones para que los mensajes entrantes sean dirigidos a Exchange 2007, apuntando los registros MX externos al nuevo servidor. La misma consideración aplica a los registros A de otros servicios que estén implementados como ActiveSync, Outlook Web AccessOutlook Anywhere, POP3, IMAP4, servicio de Autodiscover, y cualquier otro Exchange Web service.


·         El Routing Group Connector que comunica el routing group de Exchange 2003 con el routing group de Exchange 2007 debe ser eliminado


·         Es necesario borrar las políticas de usuarios para Mailbox Management – pestaña Mailbox Manager Settings (Policy). NO borrar ningúna política de usuario para E-mail. Son las que tienen el tab E-mail Addresses (Policy).


·         La jerarquía de carpetas públicas debe ser movida al Administrative Group (FYDIBOHF23SPDLT), ya que será el único sobreviviente luego del proceso.


·         El Recipient Update Service (RUS) de dominio y de configuración deben ser borrados.


·         Por último se remueve Exchange 2000 o 2003 del servidor usando “Add Remove Programs” desde el panel de control.


Como pueden ver, sería algo bastante sencillo de implementar en mi pequeña organización de prueba, pero seguramente serán muchas cosas a considerar en tu ambiente de producción. Por favor planifica en forma acorde, Visita Exchange Server TechCenter en TechNet.


Hasta pronto!


Pd: Utiliza esta vía y envíanos tus sugerencias sobre temas de interés para futuros artículos en Microsoft Latam Team Blog


 

Comments (2)

  1. fegume says:

    hola no me queda muy clara la diferencia a la hora de usar:

    PrepareDomain ó/y PrepareAD.

    ponme un ejemplo, please

  2. Daniel Seveso says:

    Fegume,

    Por ejemplo, en un forest donde tienes un dominio A (root) y B (child). Allí corres PrepareAD en el dominio A, para crear todos los objetos globales de Exchange -universal groups, el container de Microsoft Exchange System Objects, etc.-, crear el dominio smtp aceptado por defaut y ademas correr todas las tareas que ejecuta el /PrepareDomain.

    Luego en el dominio B, y en cada dominio adicional si hubiese, corres solo el /PrepareDomain, que crea los grupos de seguridad de dominio, los configura como miembros de los grupos globales y asigna permisos y derechos en el dominio a los groupos globales entre otras cosas.

    Gracias por contactarnos!