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

La publicación de recursos de Exchange usando un servidor como Forefront Threat Management Gateway es bastante sencilla aunque requiere de varias tareas previas en la preparación del entorno.

Todo lo que se explica a continuación está basado en el manual “Publishing Exchange Server 2010 with Forefront Unified Access Gateway 2010 and Forefront Threat Management Gateway 2010” que encontraréis aquí. ´

La única particularidad es que en nuestro entorno sólo existirá una tarjeta de red (NIC) que tendrá 2 IPs

• – 192.168.130.236 para OWA y ActiveSync
• – 192.168.139.237 para Outlook Anwhere.

1.Preparación de los componentes para publicar recursos en TMG

Suponemos que Forefront TMG ya está instalado y configurado en nuestro nuevo entorno. Una vez realizada la configuración del producto, vamos a generar los recursos necesarios para publicar OWA y Microsoft ActiveSync. De Outlook Anywhere ya hablaremos otro día dado que queremos usar delegación Kerberos para su publicación.

Para los dos primeros generaremos un único listener. Este listener se llamará “Exchange Listener”.

1.1.Exchange Listener

Para crear el listener abrimos la consola, Firewall Policy y en el menú de la derecha, en “Toolbox” y con el botón derecho, “New Web Listener”

Le damos el nombre de Exchange Listener y continuamos

Escogemos la opción de conexión SSL entre los equipos

Escogemos la red “Internal” y procedemos a su configuración, donde elegiremos la IP acabada en .236 de las 2 que disponemos.

Seleccionamos el certificado de nuestra empresa (midominio.es) que hemos instalado previamente, y continuamos con el asistente.

El tipo de autenticación será por formularios y contra el Directorio Activo.

Habilitamos el SSO para “midominio.local” y continuamos.

Y finalizamos el asistente.

1.2 Server Farm

Lo siguiente a realizar es la creación de una granja de servidores, que en este caso será la formada por los CAS del nuevo entorno.

Para crear la Server Farm abrimos la consola, Firewall Policy y en el menú de la derecha, en “Toolbox” y con el botón derecho, “New Server Farm”

Le damos el nombre de CAS Exchage 2010 Farm y continuamos.

Añadimos los dos servidores CAS buscándolos en el AD

Modificamos la ruta de comprobación de disponibilidad de los servidores a https://*/rpc

Y finalizamos el asistente.

Con todos los componentes necesarios creados

Vamos a generar las distintas reglas de publicación para cada aplicación.

2. Reglas de publicación para OWA y ActiveSync

2.1 Regla de publicación de OWA

Con los elementos necesarios creados, vamos a proceder a generar las reglas de publicación para OWA

Vamos a la parte izquierda de la consola, en Firewall Policy, botón derecho “New” –> “Exchange Web Client Access Publishing Rule…” y lanzamos el Asistente.

Damos un nombre a la regla

Seleccionamos del desplegable “Exchange 2010” y “Outlook Web Access” y continuamos con el Asistente

Escogemos la opción de Servidores web balanceados

Y conexión SSL entre el cliente y los servidores

Proporcionamos un nombre interno para el clúster de CAS que en este caso es “cas.midominio.es”

Seleccionamos la Server Farm creada anteriormente y proseguimos.

Proporcionamos el nombre con el que vamos a publicar externamente el OWA, webmail.midominio.es, y proseguimos con el Asistente.

Seleccionamos el listener generado

Autenticación básica

Para todos los usuarios autenticados en el dominio

Y finalizamos el Asistente.

2.1.1 Reconfiguración de la seguridad de los CAS

Después de generar la regla de publicación para OWA desde TMG, hemos de realizar una modificación de la seguridad en los CAS para OWA para que todo funcione correctamente.

2.2 Regla de publicación de ActiveSync

Con los elementos necesarios creados, vamos a proceder a generar las reglas de publicación para Microsoft Active Sync

Vamos a la parte izquierda de la consola, en Firewall Policy, botón derecho “New” –> “Exchange Web Client Access Publishing Rule…” y lanzamos el Asistente.

Damos un nombre a la regla

Seleccionamos del desplegable “Exchange 2010” y “Exchange ActiveSync” y continuamos con el Asistente

Escogemos la opción de Servidores web balanceados

Y conexión SSL entre el cliente y los servidores

Proporcionamos un nombre interno para el clúster de CAS que vuelve a ser es “cas.midominio.es”

Seleccionamos la Server Farm proseguimos.

Proporcionamos el nombre con el que vamos a publicar externamente ActiveSync que será el mismo usado para OWA, webmail.midominio.es, y proseguimos con el Asistente.

Seleccionamos el listener generado

Autenticación básica

Para todos los usuarios autenticados en el dominio

Y finalizamos el Asistente.

Marc

Decíamos ayer… y continuamos con la instalación de Microsoft Lync Server 2010.

1.1 Instalación y configuración de Microsoft Lync 2010

Una vez tenemos la topología publicada, podemos proceder a instalar el producto Microsoft Lync 2010 como tal.

Para ello, escogemos la opción “Install or Update Lync Server System” del asistente de despliegues, el cual nos guiará en la instalación final del producto.

Iniciamos el “Step 1” pulsando en Run

Cuando la ejecución finalice correctamente, cerramos este asistente.

Una vez finalizado, iniciamos el “Step 2” pulsando de nuevo en “Run”

Se iniciará un asistente para la instalación de los componentes necesarios de Lync Server

Lo ejecutamos hasta que finalice.

El tercer paso es el más importante de todos, dado que en el “Step 3” instalaremos los certificados necesarios para el correcto funcionamiento de Lync Server

Primero de todo, hemos de realizar la petición de generación de un certificado para el equipo “lync.midominio.com”

Completamos el asistente con todos los datos necesarios, asegurándonos que todos los nombres que hemos definido en el Topology Builder aparecen antes de finalizar la petición.

Seleccionamos los SIP domains

Validamos los datos

Y acabamos con el asistente.

Después de procesar la petición de generación del certificado en la CA instala el Lync, procedemos a importar el nuevo certificado generado.

Después de la importación, sólo queda asignarlo a los servicios de Lync

Después de asignar el nuevo certificado, ya podemos proseguir con el último paso.

El último paso el “Step 4”, inicia los servicios de Lync en el equipo

Arrancamos el asistente y pulsamos en “Next”

Para validar que, efectivamente, los servicios están arrancados, vamos a la parte de Servicios del sistema

Y esto es todo… para una instalación Starndard sin salida o acceso desde Internet.

Marc

Seguimos con la serie de artículos que relatan la migración de todo un bosque de Directorio Activo. Hoy hablaremos de la instalación de Microsoft Lync 2010.

En nuestro entorno fictício original existe un Microsoft Office Communication Server 2007 R2 (OCS para los amigos… y enemigos) que no soporta una migración inter-forest por lo que se opta por una plataforma nueva y a la última versión del procuto: Microsoft Lync 2010.

Puestos en antecedentes, empezamos con el lío donde se verá que la instalación del producto es algo especial.

Microsoft Lync 2010

El nuevo servidor de Lync se llamará “lync” y tendrá la IP “192.168.130.172”. La versión del software es la Standard que incluye una instalación de SQL Express 2008 SP1

Las características hardware del equipo son:

• – 2 CPUs
• – 8 GB de RAM
• – Disco de 40 GB de sistema

Como sistema operativo, se escoger Windows Server 2008 R2 SP1 en idioma inglés.

1.1 Preparación del entorno para Lync 2010

La instalación de Microsoft Lync 2010 requiere de la instalación del .NET Framework 3.5 SP1, incluido en el propio servidor.

Para instalarlo, debemos ir a “Server Manager”, escoger la opción “Add features” y seleccionar .NET Frameowrk 3.5.1. Features

También es necesario instalar varios componentes del IIS, procedimiento que se hará ejecutando el comando

ServerManagerCmd.exe -Install Web-Server Web-Http-Redirect Web-Scripting-Tools Web-Windows-Auth Web-Client-Auth Web-Asp-Net Web-Log-Libraries Web-Http-Tracing Web-Basic-Auth

Finalmente, se ha de instalar Silverlight para poder usar la consola de Lync para administrar el producto.

Después de cumplir con los requerimientos iniciales para lanzar la instalación del producto, lanzamos el programa de instalación de Microsoft Lync, ubicado en la ruta Setup\amd64\Setup.exe dentro del DVD de instalación el cual nos solicitará la instalación de VC++ Redistributable 2008.

Una vez finalizada la instalación del Runtime de VC++, se inicia el programa de instalación propiamente dicho

Cambiamos la ubicación destino a E:\Microsoft Lync Server 2010 y proseguimos con la instalación.

Aceptamos el EULA

Lanzamos la preparación del Active Directory para que extienda el Schema del bosque, añada las clases necesarias al dominio y genere los grupos de seguridad necesarios para que el producto funcione correctamente.

Acto seguido, escogemos la opción “Prepare first Standard Edition server”.

Este asistente nos iniciará uno de los pasos necesarios para instalar Lync, como son la instalación de SQL Express 2008 SP1 y la preparación del servidor para tener los datos necesarios para instalar la herramienta de definición de topologías de servidores de Lync.

Una vez finalizar la instalación del SQL Express y su DB asociada de nombre “RTC”, instalamos el Topology Builder.

Al iniciar el asistente del Topology builder, nos empezará a solicitar los datos mínimos para poder definir el tipo de instalación del producto, el SIP que tendrán los usuarios, las rutas de acceso a los recursos, etc.

El nombre que usaremos como SIP primario es el mismo que actualmente se tiene para el entorno de OCS y que es “midominio.com”. No se añaden, de momento, SIPs secundarios.

Definimos el nombre del site donde se instalará Lync. Este nombre ha de coincidir con el del equipo.

Finalizamos el asistente que nos lanzará un segundo asistente para que definamos el pool de conexiones de Lync.

El nombre del pool ha de coincidir con el del servidor, por tanto, lo ponemos y seguimos con el proceso y el pool a crear debe ser para la versión Standard del producto.

Vamos aceptando los valores por defecto del resto de pantallas del asistente hasta llegar a la configuración de la DB.

Como DB para almacenar los datos, y dado que la versión que se instala de Lync es la Standard, no podemos cambiar los valores definidos en el asistente, por lo que procederemos con el siguiente paso de la instalación.

Como directorio para compartir, definimos E:\LyncShare a nivel de sistema e introducimos la ruta “LyncShare” en el asistente

Nota: Es aconsejable haber compartido previamente la carpeta antes de decirle al programa de instalación que la use

Dejamos como external URL la que nos sugiera el asistente.

Finalizamos el asistente y publicamos esta topología. Para ello, debemos ir al menú de la derecha del Topology builder y escoger “Publish topology” lo cual hará que se lance un asistente de publicación.

Ejecutamos el asistente para publicar la topología

Y el resultado tiene que ser satisfactorio, tal como se muestra en la siguiente captura de pantalla.

Una vez llegados a este punto, no tenemos instalado el servicio de Lync sino que hemos definido su estructura en nuestra organización y publicada en el Directorio Activo.

1.2 Generación del certificado para los servicios de Microsoft Lync

Para que Lync Server funcione correctamente, es necesario generar un certificado interno que haga coincidir el nombre del servidor con el del servicio a publicar. Para ello, instalaremos una Root CA en el propio servidor de Lync.

Abrimos el Server Manager, vamos a Roles y añadimos el “Active Directory Certificate Services”

Seleccionamos Certification Authority y Web Enrollment y proseguimos con el asistente.

El tipo de CA ha de ser Entrerpise y Root CA

Generamos una nueva clave privada.

Corregimos el nombre de la CA para que sea “midominio-CA” y proseguimos.

Damos 20 años de validez al certificado interno

Finalizamos la instalación.

Y nuestro entorno ya está listo para generar y procesar peticiones de certificados para cuando la instalación de Lync genere la petición nuestro entorno sea capaz de procesarla y no detener la instalación del producto.

Aunque para ver cómo acaba la instalación deberemos esperar un poco…

Marc

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