Archivo

Archivo para la categoría ‘Dia a dia’

Migración de bosques AD: problemas con NLB y Kerberos

miércoles, 28 de septiembre de 2011 Sin comentarios

Como no todo funciona a la primera en esta vida, después de tener unas semanas montado el nuevo entorno, los clientes empiezan a dar errores de validación o la solicitan repetidamente cosa que obliga a rascar un poco y ver que todo viene por el uso de NLB y Kerberos para securizar las comunicaciones.

Rascando un poco más, encontramos un artículo de Microsoft relativo al problema y cómo solucionarlo: Using Kerberos with a Client Access Server Array or a Load-Balancing Solution

Ahora toca parase un rato, analizar el artículo y reconstruir la parte del entorno que está fallando, validarla y esperar a que los problemas queden solucionados.

Marc

Categories: Dia a dia Tags: , , ,

Migración bosques AD: migración de usuarios, correo y equipos

martes, 20 de septiembre de 2011 Sin comentarios

Lo prometido la semana pasada, una explicación de cómo se deberían migrar los recursos de usuario de un bosque a otro una vez tenemos la infraestructura mínima montada debería ir por aquí:  

Listado de tareas

  1. Preparación del buzón del usuario
  2. Migración del usuario
  3. Migración del buzón
  4. Migración del equipo
  5. Activación del usuario en Lync y actualización del cliente OCS 2007 R2 a Lync 2010

Preparación del buzón del usuario

Todos los comandos de PowerShell que se muestran a continuación se han ejecutado desde el servidor con el rol de CAS

La preparación para la migración de un usuario se requiere de la ejecución del cmdlet “Prepare-MoveRequest.ps1” que está en la ruta “C:\Program Files\Exchange Server\V14\Scripts” en cualquiera de los servidores Exchange que componen la plataforma.

Para ejecutarlo, hemos de abrir la Exchange Management Console (EMC) e ir a la ruta indicada.

Como pasos previos, debemos definir en dos variables los usuarios/passwords que el script necesita para la migración. Para ello, en la EMC ejecutamos

$Remote = Get-Credential

Donde almacenaremos las credenciales de un usuario con permisos de Domain Admin del dominio origen (mi_dominio.es)

$Local = Get-Credential

Donde almacenaremos las credenciales de un usuario con permisos de Domain Admin del dominio destino (midominio.es)

Una vez almacenados los datos de conexión entre dominios, procedemos a ejecutar el script Prepare-MoveRequest.Ps1 siguiendo exactamente la sintaxis que se muestra a continuación:

.\Prepare-MoveRequest.Ps1 -Identity <UsuarioAMigrar>@midominio.es –RemoteForestDomainController dcviejo.mi_dominio.es -RemoteForestCredential $Remote -LocalForestDomainController dc1.midominio.es -LocalForestCredential $Local -UseLocalObject -Verbose

El resultado tiene que ser parecido al siguiente

image

Y nos indica que todo ha funcionado correctamente.

Migración del usuario

La migración del usuario entre bosques de ejecutará con la herramienta ADMT instalada en el servidor “migrador” del dominio destino: migrador.midominio.es

Para evitar problemas en esta fase y sobretodo en la de migración del equipo, usaremos un Domain Admin del dominio origen para hacer login en el sistema y realizar todos los pasos.

Abrimos la herramienta ADMT

image

Una vez abierta la herramienta, botón derecho sobre el texto Active Directory Migration Tool y, en este punto, escoger “User Account Migration Wizard”

image

Arrancar el Asistente pasando la pantalla de bienvenida y completamos los valores de los dominios de origen y destino así como de los DCs a los que nos conectaremos.

image

Avanzamos hasta la pantalla de selección de usuario a migrar.

image

Escogemos el usuario a migrar después de buscarlo en el AD origen.

image

Y continuamos con el asistente.

image

Procedemos con el asistente donde marcaremos que queremos migrar la contraseña actual del usuario (Migrate passwords).

En el caso de que el DC origen no esté seleccionado, debemos escoger el DC que tiene el servicio de Password Export Tool (PES) instalado como servidor del cual haremos la extracción del password, tal como se ve en la siguiente captura de pantalla.

image

El siguiente paso es el más importante de todos, por lo que hemos de cerciorarnos no dejar sin marcar las opciones que se muestran en la siguiente captura.

image

Proporcionar los datos de un usuario Domain Admin para completar el proceso de migrar el SID del usuario.

image

Marcar todas las opciones que se muestren en la siguiente pantalla del asistente.

image

Seguir con el asistente dejando las opciones por defecto hasta la pantalla

image

Finalizar con el asistente y proceder con la migración del usuario

image

image

IMPORTANTE: Después de migrar el usuario, hay que desmarcar la opción de que cambiar el password en el siguiente inicio de sesión y marcar el password no caduca.

Migración del buzón

Como paso previo, debemos definir en una variable, el usuario/password que el script necesita para la migración. Para ello, en la EMC ejecutamos

$Remote = Get-Credential

Después de preparar al usuario y migrar los atributos no pertenecientes a Exchange con la herramienta ADMT, debemos ejecutar un “New-MoveRequest” para mover el buzón entre los dos entornos de correo.

La sintaxis exacta a seguir es la siguiente:

New-MoveRequest -Identity <UsuarioAMigrar> -RemoteLegacy -TargetDatabase «<DBDestinoAMigrar>» -RemoteGLobalCatalog ‘dc1.mi_dominio.es’ -RemoteCredential $Remote -TargetDeliveryDomain midominio.es

image

Para ver el proceso de migración del mismo, ejecutaremos el cmdlet

Get-MoveRequestStatistics -id “nombreDelUsuario”

image

Después de migrar el buzón, procederemos a migrar el equipo entre los dos dominios.

Migración del equipo

Abrimos la herramienta ADMT en el servidor “migrador.midominio.es”

image

Una vez abierta la herramienta, botón derecho sobre el texto Active Directory Migration Tool y, en este punto, escoger “Computer Migration Wizard”

image

Arrancar el Asistente pasando la pantalla de bienvenida y avanzamos hasta la pantalla de selección del equipo a migrar.

image

Escogemos el equipo a migrar después de buscarlo en el AD origen.

image

Y continuamos con el asistente.

Marcamos todas las opciones de conversión de seguridad para el equipo

image

A nivel de seguridad local, escogemos la opción “Add” para que se añadan los valores del nuevo dominio al equipo que vamos a migrar

image

Seguir con el asistente aceptando los valores por defecto hasta la pantalla de resolución de conflictos siguiente

image

Finalizar el asistente el cual nos lanzará la pantalla de migración del equipo y que sólo deberemos seguir y esperar a que finalice.

Activación del usuario en Lync

Después de migrar el usuario, el buzón y el qeuipo, procederemos a dar de alta en el servidor Lync del nuevo entorno al usuario migrado.

Abrir la consola de gestión de Lync, introduciendo el login/password cuando lo solicite

image

Ir a “Users” y “Enable users”

image

Buscamos al usuario acabado de migrar pulsando en “Add”

image

image

Lo seleccionamos y le asignamos un “Pool” dejando el resto de valores por defecto

image

Pulsamos sobre “Enable” y se nos deberá mostrar en la lista de usuarios con Lync habilitado

image

Una vez dado de alta el nuevo usuario en el nuevo entorno de Lync, se procederá a actualizar el cliente en el equipo del usuario.

Finalmente, y una vez finalizadas todas las fases, deberemos realizar una validación de todo el proceso de migración siguiendo estos sencillos pasos.

  1. Hacer login con el usuario migrado en el nuevo dominio y comprobar que lo hace correctamete y sin errores.
  2. Comprobar que el nuevo login script realiza el mapeo de unidades de red correctamente.
  3. Validación acceso la cuenta de Exchange migrada desde el cliente Outlook
  4. Validación acceso a la nueva OAB del nuevo entorno desde el cliente Outlook
  5. Validación acceso a la nueva plataforma Lync con el cliente actualizado.

Este proceso se debe realizar para todos los usuarios a migrar. Cuando esta fase esté acabada, se podrá iniciar la fase de migración de los servidores de un bosque a otro.

Pero eso será otro día.

Marc

Migración de bosques AD: resumen de la infraestructura montada

lunes, 19 de septiembre de 2011 Sin comentarios

Después de esta serie de artículos, podemos decir que ya estamos preparados para iniciar la migración de usuarios, grupos, buzones y equipos de los usuarios.

A modo de resumen, tenemos

  1. Un nuevo dominio con relaciones de confianza.
  2. Un nuevo entorno Exchange 2010 y su publicación en Internet (I y II)
  3. Un nuevo servidor de Lync
  4. Un equipo que se usará como migrador de los recursos.

Próximos pasos, empezar a mover a los usuarios y todo lo que vaya asociado a ellos, que a fin de cuentas es lo más importante en toda migración y lo que más tiempo va a consumir… pero también es lo más sencillo de explicar dado que es todo bastante mecánico.

Marc

Migración de bosques AD: esquema de cómo se han publicado los recursos de Exchange hacia Internet

sábado, 17 de septiembre de 2011 Sin comentarios

Y como una imagen vale más que mil palabras, he aquí una de resumen de la publicación de OWA, ActiveSync y Outlook Anywhere de nuestro Exchange 2010 SP1

Exchange2010

Sencillo, verdad?


Marc

Migración de bosques AD: publicación de Outlook Anywhere usando Delegación Kerberos

viernes, 16 de septiembre de 2011 Sin comentarios

Si ayer publicábamos OWA y ActiveSync a través de TMG de la manera “estandard”, hoy toca complicarnos un poco la vida y subir un nivel.

La configuración de este entorno se ha realizado siguiendo el manual Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAGdescargable desde aquí.

Al igual que en el anterior artículo, necesitamos de unas configuraciones previas para publicar Outlook Anywere (OA en adelante)

Nuestro entorno, recuerdo, tiene una NIC con dos IPs

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

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

Vamos a proceder a crear un nuevo listerner para OA distinto al ya creado para OWA y ActiveSync. Los pasos son análogos a los de OWA pero lo llamaremos “Outlook Anywhere Listener” y usaremos la IP acabada en .237

image

Por otro lado, la autenticación no será “Básica” sino “SSL”.

image

No crearemos ninguna Server Farm nueva ya que usaremos la creada para OWA y ActiveSync

2. Regla de publicación de Outlook Anywhere

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

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.

image

Damos un nombre a la regla

image

Seleccionamos del desplegable “Exchange 2010” y “Outlook Anywhere (RPC/HTTP(s))” y continuamos con el Asistente

image

Escogemos la opción de Servidores web balanceados

image

Y conexión SSL entre el cliente y los servidores

image

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

image

Seleccionamos la Server Farm ya creada y proseguimos.

image

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

Seleccionamos el listener anteriormente

image

Autenticación por delegación Kerberos. Completamos el nombre del SPN con http/* dado que al usar una granja de servidores para el balanceo no sabemos a cuál de los dos servidores se le dirigirá la petición de acceso vía Outlook Anywhere

image

Para todos los usuarios autenticados en el dominio

image

Y finalizamos el Asistente.

Pero esto no ha acabado, todavía quedan cosas a modificar en las cuentas de los equipos dentro del Directorio Activo. Vamos a ver qué nos falta.

3. Asignanción de entradas SPN en la cuenta del servidor de TMG que presenta los CAS en Internet

Para que la delegación Kerberos (KDC) funcione correctamente, se han de asigrnar sendas entradas SPN para que los servidores CAS respondan al nombre “cas1.midominio.local” y “cas2.midominio.local” en la cuenta del servidor TMG del Directorio Activo de nuestra organización.

Para ello, abrimos la consola de administración del dominio en uno de los DC, seleccionamos la cuenta del servidor TMG ubicada en Servidores –> Equipos Exchange. Vamos a la pestaña “Delegation” y pulsamos sobre “Add”.

Buscamos los servidores CAS1 y CAS2, y los añadimos

image

Y seleccionamos el servicio “http” para ambos servidores

image

El resultado final tiene que ser el siguiente:

image

Sólo queda configurar un equipo para que use “oa.midominio.es” con autentiación NTLM

image

y acceder desde fuera de nuestra red para validar que el nuevo entorno funciona.

image


Una vez llegados hasta aquí ya tenemos la infraestructura mínima para proceder a migrar los usuarios entre los dominios, pasos que se explicarán en entradas sucesivas.

Marc