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

Bink.nu | File Server Capacity Tool v1.2- 64 bit – Bink.nu.

Tenemos los CAS y los HT configurados. Queda el rol de MBX en el que montaremos un DAG para tener un mínimo entorno funcional en el nuevo bosque.

Vamos a ello.

Para poder implementar un clúser DAG en Exchange hemos de instalar las herramientas de Failover cluster para W2K8R2 desde el Server Manager, Add Features.

Después de la instalación y reinicio del equipo, procedemos a generar un clúster DAG desde la propia interfaz de administración de Exchange 2010 SP1

Además, para crear un clúster DAG es necesario que todos los servidores con el rol de MBX que formarán parte de este clúster (hasta 16 miembros) tengan publicados el mismo número de discos, con las mismas letras y con espacios idénticos.

Si se cumplen esas premisas, podremos generar correctamente un DAG.

1.1 Implementación del DAG

Para crear un clúster DAG es necesario abrir o bien la Exchange Management Console (EMC) o la Exchange Management Shell (EMS).

En nuestro caso optaremos por la primera opción.

Nos dirigimos a la parte de Organización, y en el Task Panel de la derecha, seleccionamos la opción de “New Database Availability Group” que nos lanzará el asistente de creación del DAG.

Vamos completando los distintos campos como se aprecia en la siguiente captura de pantalla

El nombre del clúster será “DAG”

No es necesario indicar un “Witness server” ya que por defecto escogerá el primer HT de la organización que no tenga el rol de MBX

Añadimos todos los servidores con el rol de MBX que queramos participen del DAG, en este caso los 2 nuevos servidores montados, y continuamos con el asistente.

Una vez finalizada la configuración del asistente, tenemos un clúster DAG pero sin bases de datos de buzones y sin una configuración de red para el mismo.

Asignamos un Secondary Witnes Server en el otro HT por si el primero de ellos no está disponible o falla por cualquier motivo.

Procedemos a la configuración de las redes.

Red de Heartbeat

La red de Heartbeat sólo la configuramos para que el clúster se comunique internamente pero no para que los clientes se conecten a ella por lo que dejamos habilitada la sincronización y le cambiamos el nombre de “DAGNetwork01” a un nombre más descriptivo como “DAG-Heartbeat”.

Red iSCSI

La red de iSCSI sólo la configuramos para que el clúster se comunique con la cabina de discos que publica las LUNs de las DB pero no para que los clientes se conecten a ella por lo que dejamos deshabilitada la sincronización y le cambiamos el nombre de “DAGNetwork02” a un nombre más descriptivo como “DAG-iSCSI”.

Red del clúster

Finalmente, la red de Producción la configuramos para que el clúster se comunique los clientes y también para que replique la configuración del DAG de modo interno en caso de que fallase la DAG-Heartbeat. Le cambiamos el nombre de “DAGNetwork03” a un nombre más descriptivo como “DAG-NetworkPro”.

Finalmente hemos de poner una IP fija al clúster DAG de modo que no se dependa de un servicio DHCP para acceder a las DB del DAG.

La IP del clúster DAG es la 192.168.130.157

1.2 Creación de los Mailboxes en el clúster DAG

Después de crear el clúster DAG, es necesario crear las bases de datos de buzones para dar soporte a las necesidades de la MIDOMINIO.

Hay definidos dos tipos de usuarios, en función de la jerarquía de la casa y son los usuarios VIPS y los usuarios No-Vips. Para cada tipo de usuario se generará un nuevo almacén con características de cuotas diferentes.

El proceso de generación del nuevo almacén de buzones es independiente a añadirlo al clúster DAG para obtener alta disponibilidad.

1.2.1 Almacén de buzones para los usuarios No-VIP

Para generar un nuevo almacén para los usuarios no-VIP iremos al Task Panel de la parte derecha de la consola de administración de Exchange (EMC) y seleccionaremos la opción “New Mailbox Database”.

Una vez lanzado el asistente, le daremos un nombre descriptivo, seleccionaremos el servidor de MBX que almacenará ese nuevo almacén y pulsaremos en “Siguiente”

En el siguiente punto, hemos de indicar la ruta local del servidor donde almacenaremos ese nuevo almacén. Se ha definido la unidad F: para los datos de los usuarios No-VIP y la letra G:\ para guardar los logs de transacción que genere el citado almacén.

Validamos que los datos sean correctos y proseguimos con el asistente.

Si todos los datos introducidos son correctos el asistente creará la estructura de directorios y ficheros adecuada y montará el nuevo almacén si no le decimos lo contrario.

En este punto ya tenemos el almacén de buzones para los usuarios No-VIP creado. El siguiente paso es añadir una copia al DAG para ofrecer Alta Disponibilidad (HA) en caso de fallo de alguno de los servidores de MBX.

Para proveer de esa HA, seleccionamos el nuevo almacén, botón derecho sobre él y “Add Copy”. Se nos lanzará un asistente para configurar esa HA donde básicamente nos pedirá en qué otro servidor MBX del DAG queremos generar la réplica del almacén seleccionado.

En este caso, seleccionamos el MBX contrario de donde hayamos generado el almacén y seguimos avanzando con el asistente.

Una vez finalizado el asistente, revisamos que se ha generado la copia para HA y damos por concluida la tarea.

1.2.2 Almacén de buzones para los usuarios VIP

El proceso para la generación del almacén de buzones para los usuarios VIP es análogo al anterior, exceptuando las rutas físicas donde se almacenarán los buzones.

En este caso, la letra de la unidad es la E:\ mientras que los logs siguen yendo a la unidad G:\ pero en otra carpeta.

Una vez finalizado el asistente, tendremos el almacén de buzones de los usuarios VIP y sólo quedará añadir una réplica dentro del clúster DAG.

Para proveer de esa HA, seleccionamos el nuevo almacén, botón derecho sobre él y “Add Copy”. Se nos lanzará un asistente para configurar esa HA donde básicamente nos pedirá en qué otro servidor MBX del DAG queremos generar la réplica del almacén seleccionado.

En este caso, seleccionamos el MBX contrario de donde hayamos generado el almacén y seguimos avanzando con el asistente.

Después de completar el asistente, vemos que se ha generado una copia en el otro servidor de MBX y que se han replicado correctamente los datos.

1.3 Configuración de la organización

Después de generar los buzones para cada tipo de usuario, se procederá a establecer cuotas de uso de los buzones en función del tipo de usuario.

Para los usuarios No-VIP, los límites establecidos son

– 60 MB para aviso del límite de la cuota

– 72 MB para enviar

– 80 MB para enviar y recibir.

Para los usuarios VIP, los límites establecidos son

– 3,30 GB para aviso del límite de la cuota

– 3,95 GB para enviar

– 4,50 GB para enviar y recibir.

Para cada almacén de buzones se ha definido el uso de la misma Offline Address Book (OAB) que es distribuida por los CAS Servers

De momento, no hay definas Carpetas Públicas (PF) en la organización de la CMT dado que no son requeridas por las aplicaciones.

1.4 Configuración del servidor

No se realiza ninguna configuración a nivel de servidor dejando los valores por defecto.

Marc

Continuando con la configuración del nuevo entorno de Exchange iniciada con la de los CAS, procedermos a dejar “a nuestro gusto” el rol de HT.

1.1 Configuración de la organización

Los primeros pasos de configuración corresponden al nivel de organización Exchange.

Creamos un Send Connector para enviar todo el correo que no pertenezca a la organización Internet.

El conector tiene el mismo nombre que el existente actualmente en el entorno antiguo y es “Internet”.

Configuramos como SmartHosts los IronPort que hacen de applicance de envío de correo, servicio de anti-spam, etc.

Y añadimos como servidores origen de los envíos a ambos servidores CAS, cas1.midominio.local y cas2.midominio.local

Eliminamos la restricción del tamaño de envío de los correos, tal como está en el entorno a migrar.

Como dominio de correo aceptado por el sistema, y mientras dure la fase de migración entre sistemas Exchange, se configura el dominio “midominio.com” como Internal Relay. Este cambio también ha de realizarse en el entorno viejo de modo que se genere un flujo de correo interno para los usuarios migrados y los que quedan por migrar.

A la vez que se crea un Send Connector adicional para redirigir el correo de los usuarios que no estén migrados al nuevo entorno al entorno antiguo

En Transport Settings dentro de Global Settings establecemos los límites de envío y recepción de tamaños de correos para toda la organización.

1.2 Configuración del servidor

La configuración a nivel de servidor es la que viene por defecto en la instalación del producto.

1.3 Cross-Forest connector

El primer paso para crear un Cross-Forest connector con external authentication es el abrir Exchange Management Shell y ejecutar el siguiente cmdlet New-SendConnector, concretamente con la sentencia siguiente:

New-SendConnector -Name «Cross-Forest» -Usage Internal -AddressSpaces midominio.com –SmartHosts ht1.midominio.com, ht2.midominio.com -SmartHostAuthMechanism None -SourceTransportServers cas1.midominio.com, cas2.midominio.com-DNSRoutingEnabled $false

Finalmente, se han de dar los permisos adecuados al nuevo conector “Cross-Forest” ejecutando el archivo .ps1 “Enable-CrossForestConnector” que está dentro de la carpeta de scripts de Exchange 2010, en la ruta donde lo hemos instalado.

Este conector también se ha de crear en el entorno viejo de modo que también sea capaz de realizar el relay interno de correos entre ambos sistemas.

Para que cada sistema pueda recibir los correos del sistema contrario, se crearán unos Receive Connectors en los CAS del nuevo entorno y modificaran los del entorno actual para aceptar conexiones entrantes de envíos.

Para crear un Receive Connector, vamos a la parte de la EMC de Server Configuration, Hub Transport y escogemos la opción New-ReceiveConnector de las opciones del menú de la parte derecha.

Le damos un nombre significativo, el tipo es Internal y añadimos las IPs de los HT del otro dominio (HT1 y HT2) y de los IronPort

Modificamos la Autenticación desmarcando todas las casillas y en los permisos de grupos, marcamos que acepte usuarios de Exchange y usuarios anónimos.

Con esto queda configurado el rol de HT en el nuevo entorno pero para que todo funcione bien, se han de repetir los pasos de creación del Cross-Forest Connector, Recive Connector y añadir las IPs de los CAS1 y CAS2 en los servidores que tienen el rol de HT en el entorno viejo, que son HT1 y HT2

New-SendConnector -Name «Cross-Forest» -Usage Internal -AddressSpaces midominio.com –SmartHosts cas1.midominio.com, cas2.midominio.com -SmartHostAuthMechanism None -SourceTransportServers ht1.midominio.com, ht2.midominio.com-DNSRoutingEnabled $false

Marc

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