Bink.nu | File Server Capacity Tool v1.2- 64 bit – Bink.nu
sábado, 10 de septiembre de 2011
Sin comentarios
Archivo
Archivo para sábado, 10 de septiembre de 2011
Migración de bosques AD: configuración de un DAG en los MBX en Exchange 2010 SP1
sábado, 10 de septiembre de 2011
Sin comentarios
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.
Próxima acción, publicar el servicio de correo en Internet a través de Forefront TMG que hará de Reverse Proxy para OWA, ActiveSync y Outlook Anywhere el cual ya hemos configurado.
Marc
Migración de bosques AD: configuración de los HT en Exchange 2010 SP1
sábado, 10 de septiembre de 2011
Sin comentarios
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
Próximo paso, crear un DAG con los dos MBX que hemos instalado….
Marc
Migración de bosques AD: configuración de los CAS en Exchange 2010 SP1
sábado, 10 de septiembre de 2011
Sin comentarios
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