De cómo ser IT Pro y no morir en el intento

Después de proceder a la instalación de los binarios de Exchange es el turno de realizar su configuración.

Empezaremos por los roles de CAS y HT donde deberemos dejar las mismas configuraciones que hayamos encontrado en el entorno viejo del cual migraremos los buzones. El primer rol que se configura es el de CAS.

1.1.Configuración de la organización

Los primeros pasos de configuración corresponden al nivel de organización Exchange. En este caso, se dejan los valores por defecto resultantes de la instalación del producto.

1.2 Configuración del servidor

1.2.1 Instalación de certificados

Para poder habilitar los servicios de OWA, ActiveSync y OutlookAnywhere, es necesario proceder a la importación de los certificados digitales emitidos por una autoridad de certificación como VeriSign o Thawte

Esta importación en Exchange se debe hacer desde la EMS con el comando Import-ExchangeCertificate, aunque también es posible hacerlo desde la EMC

Después de importar el certificado, debemos habilitarlo para los servicios requeridos.

El cmtlet a usar es Enable-ExchangeCertificate. Se habilitará para los servicios IIS y SMTP, tal como está en el entorno actual.

1.2.2 Activación de Outlook Anywhere

Una vez instalados y activados los certificados, se procede a habilitar el servicio de Outlook Anywhere. El nombre sobre el que publicaremos este servicio es https://outlookanywhere.midominio.com

Desde la propia EMS, ejecutamos el cmdlet Enable-OutlookAnywhere, en ambos servidores CAS, y cuya sintaxis completa es la siguiente

Enable-OutlookAnywhere -Server ‘CAS1’ –ExternalHostname ‘https://outlookanywhere.midominio.com’ -DefaultAuthenticationMethod ‘NTLM’ -SSLOffloading $true

El resultado de ese cmdlet es el que se ve en la captura de pantalla.

1.2.3 Configuración del Autodiscover y servicios internos

Estableceremos la dirección de Autodiscover en “outlookanywhere.midominio.com” en que cada servidor CAS para que la autoconfiguración de los clientes Outlook funcione correctamente con el cmdlet Set-ClientAccessServer y Get-ClientAccessServer

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://outlookanywhere.midominio.com/Autodiscover/Autodiscover.xml

1.2.4 Configuración del EWS para Outlook Anywhere

Estableceremos la dirección de EWS en “outlookanywhere.midomino.com” en que cada servidor CAS para que el acceso de los clientes por Outlook Anwyhere sea el adecuado, tanto internamente como externamente. Usaremos Set-WebServicesVirtualDirectory y Get-WebServicesVirtualDirectory

Get-WebServicesVirtualDirectory  | Set-WebServicesVirtualDirectory -externalurl https://outlookanywhere.midominio.com/EWS/Exchange.asmx

1.3 Configuración del Availability Service

Para poder mantener las agendas y calendarios sincronizados entre distintas organizaciones Exchange con comunicación “Inter-forest” hemos de dar permisos cruzados a ambos sistemas para que puedan consultar el servicio de “Availability”. Esto se realiza con el siguiente cmdlet de PowerShell sobre los servidores con el rol de CAS.

Get-ClientAccessServer | Add-ADPermission -Accessrights Extendedright -Extendedright «ms-Exch-EPI-Token-Serialization» -User «mi_dominio\Exchange servers»

Add-AvailabilityAddressSpace -Forestname mi_dominio -AccessMethod PerUserFB -UseServiceAccount:$true

Add-AvailabilityAddressSpace –Forestname midominio.com -AccessMethod PerUserFB -UseServiceAccount:$true

Y en los CAS del dominio origen

Get-ClientAccessServer | Add-ADPermission -Accessrights Extendedright -Extendedright «ms-Exch-EPI-Token-Serialization» -User «midominio\Exchange servers»

Add-AvailabilityAddressSpace -Forestname midominio -AccessMethod PerUserFB -UseServiceAccount:$true

Add-AvailabilityAddressSpace –Forestname midominio.com -AccessMethod PerUserFB -UseServiceAccount:$true

1.4 Configuración del clúster NLB

Para poder configurar la Alta Disponibilidad en el Servicio de CAS, se decide montar y configurar el Servicio NLB de Windows Server 2008 R2 SP1 incluido en el sistema.

Primero de todo, instalamos en cada servidor de CAS el servicio desde Server Manager, Add Features. Una vez instalado, procedemos a su configuración.

El nombre para el clúster NLB que servirá al CAS array será cas.midominio.com mientras que la IP será la 192.168.130.5

1.5 Creación de un CAS Array

Antes de proceder a la creación del CAS Array, hemos de crear una entrada Host (A) en el DNS del dominio que relacione el nombre del CAS Array con la IP de balanceo del NLB tanto a nombre interno en MIDOMINIO.local como en la parte pública que sirve los servicios de Internet “MIDOMINIO.COM” para el acceso externo con el uso de certificados.

New-ClientAccessArray -FQDN «cas.midominio.com» -Site «Backend»

Después de crear el CAS Array, hemos de asociarlo a los MBX

El cmdlet a usar es

Get-MailboxDatabase | Set-MailboxDatabase –RPCClientAccessServer “cas.midominio.com”

Podemos revisar que está correctamente asociado con

Get-MailboxDatabase | fl

1.6 Habilitar la opción MRSProxy para realizar la migración

Para poder realizar el proceso de migración, es necesario habilitar el servicio “MRSProxy” en los servidores CAS del dominio “remoto” tal como se describe en http://technet.microsoft.com/en-us/library/ee732395.aspx

Siguiente paso, configurar el rol de Hub Transport donde se creará un conector de correo “Cross-forest” para recibir/enviar correos entre ambos sistemas de ambos bosques

Marc

Contiuando con el proceo iniciado en la anterior entrada, procederemos a instalar los distintos roles del entorno Exchange

1.1 Instalación de los roles de HT y CAS

El primer rol que hay que instalar siempre en una organización Exchange 2007 o superior es el del Client Access Server (CAS). Según el diseño de la solución, también se instalará el rol de Hub Transport (HT) conjuntamente con el del CAS.

Estos dos roles estarán redundados al instalarse en dos servidores cuyos nombres serán CAS1 y CAS2.

Para iniciar la instalación, hemos de proceder a instalar una serie de pre-requisitos como son la instalación del .NET Framework 3.5.1 incluido en el propio Windows Server 2008 R2 SP1

El siguiente paso es arrancar el instalador del producto, escoger las opciones de idioma y seleccionar el punto 4 “Install Microsoft Exchange”

Se lanzará un asistente donde podemos realizar la instalación propiamente dicha.

Escogemos la instalación “Custom Exchange Server Installation” y marcamos la casilla “Automatically install Windows Server roles and features requierde for Exchange Servers”.

De este modo, el propio programa de instalación añadirá los distintos componentes de Windows necesarios para proceder a instalar Exchange 2010 SP1

Avanzamos en el Asistente y escogemos los roles de Hub Transport Role y Client Access Role

Automáticamente se selecciona la opción de “Management Tools” y se desmarca la opción de “Edge Transport Role”

Ante la opción de configurar los CAS con una dirección de acceso desde Internet, de momento escogemos no configurarlo.

Una vez completados estos pasos, el programa de instalación realiza una serie de comprobaciones en el sistema

Si el check es correcto, procedemos a la instalación del producto.

Una vez completada la instalación, reiniciamos el equipo y comprobamos que todos los servicios se levantan correctamente y no hay errores en el Visor de sucesos del sistema.

1.2 Instalación del rol de MBX

El siguiente rol que se instalará será el del Maiblox (MBX). Este rol estará redundado al instalarse en dos servidores cuyos nombres serán DAG1 y DAG2.

De nuevo, lanzamos el instalador del producto, escogemos las opciones de idioma y seleccionamos el punto 4 “Install Microsoft Exchange”

Escogemos la instalación “Custom Exchange Server Installation” y marcamos la casilla “Automatically install Windows Server roles and features requierde for Exchange Servers”.

De este modo, el propio programa de instalación añadirá los distintos componentes de Windows necesarios para proceder a instalar Exchange 2010 SP1

Avanzamos en el Asistente y escogemos el rol de Mailbox

Automáticamente se selecciona la opción de “Management Tools” y se desmarca la opción de “Edge Transport Role”

Como en el entorno nuevo no van a existir clientes de correo Outlook 2003, seleccionamos la opción de “No” en la siguiente pantalla del asistente y continuamos con la instalación

Una vez completados estos pasos, el programa de instalación realiza una serie de comprobaciones en el sistema

Una vez completada la instalación, reiniciamos el equipo y comprobamos que todos los servicios se levantan correctamente y no hay errores en el Visor de sucesos del sistema.

Después del reinicio, podemos comprobar que la instalación es correcta

1.3 Instalación del último Roll-Up en el nuevo entorno Exchange 2010 SP1

Antes de seguir configurando el sistema, procederemos a actualizarlo con el último Roll-Up liberado por Microsoft. En este caso el Roll-Up 4 versión 2.

Lanzamos el Asistente de instalación

Seguimos los pasos que nos indique y esperamos a que se complete su instalación.

Después de la instalación y aunque no lo pide, reiniciamos los equipos y comprobamos que todo se inicia sin errores.

Siguiente paso, configurar el entorno pero será otro día

Marc

1 Introducción

Con esta nueva entrada iniciamos una serie de diferentes artículos con el objetivo el reflejar los pasos seguidos para generar un nuevo entorno Microsoft Exchange en Windows Server 2008 R2 SP1 para poder realizar la migración de buzones de correo desde el dominio viejo.

2 Nuevo entorno Exchange

El nuevo bosque/dominio se llamará “midominio.local” y estará compuesto inicialmente por los Controladores de dominio “DC1” y “DC2”, con las IPs 192.168.130.152 y 192.168.50.50

Los equipos que compondrán la arquitectura Exchange estarán ubicados en la subnet de la red donde está ubicado DC2

2.1 Preparación del Schema

Antes de poder iniciar la instalación del Exchange, hemos de preparar el Schema del nuevo bosque para soportar las clases requeridas por el producto. Para ello, procederemos a extender el esquema con el coman do “setup.com /PrepareSchema (o /ps) desde el Command Prompt del servidor donde iniciaremos la instalación del producto.

Una vez finalizado el proceso, debemos esperar a que los DCs repliquen los nuevos atributos y clases.

Una vez finalizada correctamente la replicación de los cambios, hemos de proceder a extender las propiedades del Directorio Activo (AD)

2.2 Preparación del AD

Para realizar la preparación del AD, hemos de ir de nuevo al Command Prompt y ejecutar el comando “setup.com” con los parámetros /PrepareAD (o /p). Opcionalmente también podemos especificar el nombre de la organización Exchange.

En este caso el nombre escogido para la organización es “Organizacion”. El comando para establecer el nombre de la organización es /OrganizationName (o /on)

Una vez finalizado el proceso, debemos esperar de nuevo la replicación de los cambios en el AD.

Llegados a este punto, ya podemos proceder a instalar los distintos servidores Exchange y sus roles tal como se describe en la siguiente entrada.

Marc

Siguiendo con lo mío… y sabiendo que ya hay muchos post, enlaces y tutos de cómo crear una Relación de confianza entre bosques, voy a añadir mi granito de arena con mi propia entrada del tema.

Antes de nada, hemos de resolver el tema de la “localización” de los dominios entre sí por lo que usaremos una característica ya incluída en Windows Server 2003: los Conditional Forwarders

El objetivo es que toda petición dirigida a “mi_dominio.local” desde “midominio.local” vaya directamente a los servidores DNS autoritativos de esa zona, que serán los servidores DNS del dominio origen mientras que el resto de peticiones, usen los DNS del ISP, router o lo que haya configurado para salir a Internet.

El mismo caso pero a la inversa se hace para “midominio.local” de modo que el tráfico de consultas DNS se encamina sólo hacia los servidores que gestionan cada una de las zonas en cada uno de los bosques.

Configuración en el nuevo bosque

En las propiedades del DNS de uno de los DCs del nuevo bosque, añadimos las IPs de los DNS del otro bosque, como se ilustra en las siguientes imágenes

Configuración en el viejo bosque

En las propiedades del DNS de uno de los DCs del bosque antiguo hacemos lo mismo que antes pero a la inversa.

Y nada más, tan sencillo como esto.

Evidentemente, hemos de realizar pruebas desde ambos dominios para asegurarnos que la resolución cruzada funciona.

Otra cosa ha hacer, y se puede hacer por GPO – lo recomiendo – es forzar que la lista de sufijos DNS de la conexión incluya el dominio propio y el contrario para facilitar un orden de resolución correcto.

Una vez llegados a este punto… vamos con las…

Relaciones de confianza

Para poder migrar usuarios entre distintos bosques y/o dominios de Directorio Activo, es necesario establecer relaciones de confianza entre ambos entornos de modo que un usuario de un dominio pueda usar los recursos del otro dominio, siempre que los permisos establecidos para esos recursos brinden el correcto acceso a los mismos.

Para establecer relaciones de confianza entre dominios, debemos ir a Administrative Tools, Active Directory Domain and Trusts y, desde las propiedades del dominio, ir a la pestaña “Trusts”.

Desde aquí, escogemos la opción “New Trust” donde se lanzará un asistente que nos guiará en todo el proceso de generación de la relación de confianza entre los entornos.

Este asistente ha de ejecutarse en los dos dominios sobre los que queremos establecer la relación de confianza.

Avanzamos en el asistente

Introducimos el nombre NetBios o FQDN del dominio al que queremos establecer la relación y continuamos con el asistente.

Escogemos el tipo de confianza que vamos a establecer. En nuestro caso, a nivel de Bosque dado que ambos entornos están funcionando en modo Nativo Windows Server 2003 o superior.

La relación será bidireccional, de modo que un usuario del dominio “mi_dominio.local” pueda acceder a los recursos de “midominio.local” y viceversa.

Limitamos la creación de la relación sólo al dominio actual de modo que deberemos generar la contraria al finalizar el asistente en el otro dominio.

No limitamos el acceso entre dominios dado que la relación de confianza sólo existirá durante la transición de bosques y no necesitamos filtrar los usuarios que podrán acceder a los recursos del dominio contrario.

Establecemos un password para generar la relación de confianza. No es necesario que este password pertenezca a ningún usuario a la par que se puede cambiar en cualquier momento y revalidar la relación de confianza después del cambio.

Con todos los datos introducidos en el asistente.

Una vez finalizado el asistente, procedemos a validar la nueva relación de confianza con un usuario del dominio contrario que tenga los privilegios necesarios. Confirmamos la relación entrante.

Una vez repetido este proceso en ambos dominios, tendremos la relación de confianza totalmente funcional.

Dominio MiDominio.local

Dominio Mi_Dominio.local

Avanzaremos un poco el siguiente tema que será instalar la herramienta ADMT y configurar los dominios para permitir su uso. Así que lo primero a hacer es….proceder a la desactivación del SID Filtering. Este paso se debe hacer desde el dominio destino o nuevo, con los comandos

1. netdom trust midominio.local /domain:mi_dominio.local /quarantine:no
2. netdom trust midominio.local /domain:mi_dominio.local /EnableSIDHistory:yes

Marc

Siguiendo con la serie de entradas relativas a la migración de bosques, hoy procederemos a explicar cómo instalar la herramienta Active Directory Migration Tool

Instalando ADMT

La herramienta de migración de usuarios, grupos, equipos y servidores, Active Directory Migration Tool (ADMT), se instala en un servidor de transición diferente y específico para la realización de este proceso y que, originalmente podríamos llamar “Migrador”. Lo integraremos como member server del dominio destino “midominio.local”

Esta herramienta se compone de dos partes:

1. La propia ADMT que requiere de la instalación de un SQL Express 2008 SP1
2. Y una segunda parte llamada Password Export Tool (PES) requerida para traspasar los passwords entre dominios.

La herramienta PES se instala en el servidor que tiene el PDC Emulator del dominio “mi_dominio.local” y deberá arrancar con una cuenta Domain Admin.

1.1 Instalación de SQL Express 2008 SP1

La herramienta ADMT requiere de una base de datos para funcionar que bien puede ser una instancia de un SQL Server 2005 o 2008 “completo” o las versiones SQL Express 2005 SP3 y/o SQL Express 2008 SP1

Para no complicar las cosas, se opta por instalar un SQL Express 2008 SP1. Los pasos seguidos han sido los siguientes

Lanzamos el instalador de SQL Express 2008 SP1

Dejamos que el programa de instalación haga las comprobaciones necesarias al entorno antes de proseguir con la instalación del producto

Una vez validado el entorno, procedemos a la instalación como tal

Avanzamos con el procedimiento de instalación de SQL Express

Aceptamos el CLUF

Le indicamos que genere una nueva DB.

Le indicamos que cree la nueva instancia con los valores por defecto del producto.

Se comprueba que hay suficiente espacio en el sistema para proceder a la instalación.

Escogemos cuenta local de sistema para arrancar la instancia del SQL Express

Como modo de autenticación, escogemos integrado en el sistema.

Finalizados todos los pasos del Asistente, iniciamos la instalación del producto.

Una vez finalizada la instalación, ya podemos instalar ADMT sobre esa instancia recién creada.

1.2 Instalación de Active Directory Migration Tool

Después de instalar el SQL Express 2008 SP1, procedemos con la instalación del ADMT propiamente dicho.

Lanzamos el Asistente y seguimos los pasos que nos indica

Aceptamos la licencia de uso o CLUF

Indicamos la instancia de SQL a usar, que por defecto será “SQLExpress” del equipo local

Continuamos con la instalación

Como es una instalación desde cero, no requerimos de importar los datos de otra migración anterior.

Una vez completados todos los pasos, ya tendremos la herramienta instalada y lista para su ejecución.

1.3 Instalación de Password Export Tool

Para poder migrar las contraseñas de los usuarios entre bosques y/o dominios, es necesario instalar la herramienta Password Export Tool (PES) en el servidor origen que tiene el rol de PDC Emulator.

La instalación de PES requiere de una clave de exportación que se genera desde la línea de comandos del servidor donde se instala ADMT (Migrador) y tiene la sintaxis:

admt key /option:create /sourcedomain:mi_dominio.local /keyfile:C:\Export\password.pes /keypassword:*

Después de generar la clave de exportación, la copiamos en el DC que tiene el rol de PDC y lanzamos el programa de instalación de PES, con privilegios elevados.

Seguimos el Asistente proporcionando la ruta del fichero “password.pes” cuando lo solicite. Introducimos el password que protege el fichero y finalizamos el asistente. Para concluir el proceso de instalación, reiniciamos el servidor.

Después del reinicio, comprobamos que el servicio de PES arranca correctamente

Una vez tenemos ADMT montado y configurado, deberemos lanzar diferentes pruebas para validar que el proceso de migración de usuarios, grupos y passwords de un dominio al otro funciona correctamente.

Y hasta aquí la parte referente al montaje de un nuevo bosque, el establecimiento de relaciones de confianza y la instalación de ADMT.

La siguiente serie de entradas corresponderán a la instalación y configuración de Exchange 2010 SP1 para la migración de buzones inter-forest. Espero que os gusten.

Marc