Migración a Office 365 (1/2)

jueves, 24 de mayo de 2012 Sin comentarios

Hola,

Si hace un par de días hablaba de mi primera vez, hoy me voy a limitar a poner “No es para tanto” Thumbs up. Pero es como todo, lo desconocido da miedo y respeto.

La intención de esta entrada es, simplificando mucho, explicar los pasos mínimos para realizar una migración de un Exchange 2007 SP3 a Office 365, y empezaremos por definir la arquitectura mínima y necesaria para poder llevar a cabo el proceso.

 

¿Qué necesitamos?

Leer. Básicamente. El proceso de preparación de una infraestructura on-premise para migrar al cloud no es complicada pero sí un poco larga y laboriosa.

Microsoft recomienda dos estrategias, con implementación de Single Sign-On (SSO) o sin ella. En este caso, usaremos la primera con SSO.

Para poder montar un sistema de SSO requerimos de al menos dos equipos nuevos en nuestro dominio: un servidor donde montar Active Directory Federation Services (AD FS) y otro, en la DMZ, con Active Directory Federation Services Proxy  (AD FSP) ambos en versión 2.0 (de descarga separada)

AD FS sirve para federar nuestra organización con Office 365 usando comunicación de 2048 bits en SSL. El segundo servidor, como se puede deducir, sirve para no exponer directamente nuestro AD a Internet.

El montar correctamente este servicio nos garantiza en un 99% que todo funcione correctamente y es esencial puesto que si no funciona, no podremos continuar con nuestra migración.

image

image

La información detallada y más técnica la encontrarés en este link.


Con esta primera fase completada, ya podemos acometer la segunda también muy importante: sincronizar nuestro AD con Office 365

El proceso, al igual el anterior requiere de leer otra vez. Viene todo descrito en este otro link y básicamente consiste en 

– Crear la empresa en Office 365, por un lado

– Realizar varios procesos como instalar Microsoft Online Services Module for Windows PowerShell en el equipo que tiene el rol de AD FS

image

– Ejecutar 3 cmdlets que federarán nuestra empresa en la nube con nuestro AD (se generará un token de seguridad y una claim rule en el AD FS)

$cred=Get-Credential

image

Connect-MsolService -Credential $cred

image

Convert-MsolDomainToFederated –DomainName nuestroDominio.com


Acabada esta fase, ya podremos sincronizar nuestra empresa en la nube con nuestro AD. A partir de ahora, todas las acciones se realizarán desde el Portal de Office 365 al que accederemos desde

image

Una vez dentro del portal, nos dirigimos a Administración –> Usuarios

image

Y buscamos “Sincronización de Active Directory” que es lo necesitamos para “rellenar” nuestra nube con los usuarios de nuestro AD.

image

Habilitamos la opción (y nos asustamos Winking smile)

image

Después de esperar cierto tiempo (Microsoft indica hasta 24 horas) sólo queda instalar la herramienta Sincronización de directorios para que este servicio se encargue de tener al día nuestro AD y nuestro Office 365

image

Una vez instalado, lanzaremos una sincronización inicial que se irá repitiendo regularmente

image

image


Si hemos llegado hasta aquí, enhorabuena, ya nos queda recorrer la otra mitad del camino: migrar Exchange 2007 SP3 pero dejaremos este tema para otro día Smile with tongue out.

 

Saludos,

Marc

Categories: Dia a dia Tags: , ,

Mi primera vez

lunes, 21 de mayo de 2012 Sin comentarios

Con Office 365, mal pensados Smile 

Pues sí, niños y niñas, por fin tengo la oportunidad de trabajar con un cliente que quiere portar su infraestructura a la nube y, por supuesto, a la de nube de Microsoft y su Office 365.

De todos es sabido que la crisis actual afecta las finanzas y las empresas se plantean la reducción de costes así que algunos clientes de mi empresa han decidido migrar.

El caso que me va a aocupar estas semanas (no muchas) es la de migrar Exchange 2007 SP3 y Sharepoint además de configurar Lync Online. Y… estoy entusiasmado por varios motivos: porque ya era hora, porque es algo nuevo y porque es un pequeño reto personal.

Veremos como va que ya nos hemos encontrado con el primer escollo: los certificados necesarios para el AD FS y el AD FS Proxy y no porque sea complicado el montaje sino porque ya hay un AD FS implantado y funcionando con un certificado… autorfirmado que tiene vinculado el CRM de la empresa.

Así que el primer reto consiste en cambiar ese certificado por uno público sin romper el CRM Hot smile.

 

Saludos,

Marc

Otra serie de MCTS…

martes, 15 de mayo de 2012 Sin comentarios

Después de un descanso semi-forzado en el tema de las certificaciones, vamos a por otra que es parte de mis objetivos dentro de la empresa Winking smile.

Esta vez voy a por el 70-659 TS: Windows Server 2008 R2, Server Virtualization

Toca recopilar material de estudio, repasar, sacar tiempo de debajo de las piedras y… aprobar, no Smile with tongue out?

Veremos…

 

Saludos,

Marc

Registros DNS, DHCP Server, Name Protection. De locos

miércoles, 9 de mayo de 2012 Sin comentarios

Hola,

Llevo unos días (bueno, son unos meses con días alternos Smile with tongue out) con un pequeño pero desesperante problema de registros DNS, un DHCP Server y cambios de comportamiento con “Name Protection” si lo activo o no.

Os detallo el entorno.

  • Tres controladores de dominio Windows Server 2008 R2 con servicio de DNS
  • Un servidor DHCP también con Windows Server 2008 R2 con usuario definido para registrar las entradas DNS de modo seguro y autorizado en el grupo “DNSProxyUpdate” del AD.
  • El lease de los diferentes scopes del DHCP están configurados entre 1 y 4 horas.
  • Un parque de clientes Windows XP SP3 y Windows 7, tanto físicos como en entorno VDI, que suman unos 1.500 equipos

El problema

Si se usa el servidor DHCP para realizar el registro, éste tarda de 15 a 30 minutos en generar la entrada “Host (A)” en la zona DNS . Esto provoca un problema cuando el bróker de los equipos VDI intenta resolver el nombre de los clientes (necesario para funcionar) dado que no los encuentra y falla.

Se ha intentado forzar el registro automático mediante una política para que sea el propio cliente VDI quien se registre, pero el registro es creado con la cuenta del cliente (el owner) y no con la del DHCP. Esto provoca que cuando se destruyen las máquinas VDI, los registros no son borrados de la zona DNS, lo que provoca que existan muchos registros obsoletos con los problemas de resolución de nombres que eso conlleva.

En el caso de equipos no-VDI esta problemática no se manifiesta (aunque siguen tardando 30 minutos en registrarse en su zona) y el owner del registro DNS es la cuenta definida en el server DHCP.

Para añadir más lío al tema, se habilita la funcionalidad “Name Protection” en el servidor DHCP con lo que se consigue que registro de los clientes (VID y no-VDI) se realice de forma casi instantánea pero sigue siendo el owner de la entrada del DNS la cuenta de máquina y no la definida en el servidor.

También mencionar que se tiene habilitado aging en la zona, pero no scavenging por temas de carga en los DCs (aunque sería factible activarlo.

La solución

Qué solución hemos aplicado para tener lo que queremos como es que el DHCP registre en el DNS de modo casi instantáneo las entradas correspondientes a cada equipo?

Sencillo: abrir un caso con Microsoft Hot smile

 

Saludos,

Marc

P.D: Seguiremos informando…

Migración de un DHCP de 2003 a 2008 R2

miércoles, 2 de mayo de 2012 Sin comentarios

Hola a todos,

 

Hoy, una entrada sencilla pero no por ello menos interesante. Vamos a explicar, paso a paso, cómo migrar un servicio DHCP desde un Windows Server 2003 R2 de 32 bits a un flamamente Windows Server 2008 R2.

Para poder migrar correctamente el servicio DHCP desde un 2003 a un 2008 R2, se deben cumplir unos pasos previos para hacer que los cmdlets de PowerShell sean compatibles entre ambos sistemas.

  1. Por tanto, el primer paso es instal·lar Microsoft PowerShell 1.0 o superior en nuestro servidor origen Windows Server 2003 R2
  2. En el servidor destino, esto es, nuestro Windows Server 2008 R2 debemos añadir la Feature “Windows Server Migration Tools”
  3. Una vez instaladas estas herramientas, generaremos el paquete de instalación para las mismas herramientas pero para ser usadas en 2003 R2.
    1. El cmdlet a usar es “PS C:\Windows\System32\ServerMigrationTools\ .\SmigDeploy.exe /package /architecture x86 /os WS03 C:\temp”
  4. Instalamos el paquete generado en el servidor origen.
  5. Realizamos unb backup del actual DHCP, desde la propia consola
  6. Abrimos la consola de PowerShell del servidor origen y ejecutarmos la orden “.\Servermigration.psc1” que abrirá una nueva consola con los módulos para ejecutar la exportación de los datos del servicio DHCP
  7. Llegados a este punto, empieza el lío con el cmdlet Export-SmigServerSetting –FeatureID DHCP, el cual tardará un poco y nos pedirá una ruta y un password para almacenar los datos en un fichero.
  8. Copiamos el fichero generado al servidor destino, nuestro Windows Server 2008 R2
  9. E iniciamos la importación desde una ventana de PowerShell con privilegios elevados. El cmdlet que usaremos es Import-SmigServerSetting -FeatureID DHCP -Verbose –Force
  10. Dado que este proceso requiere de mantener la IP del servidor origen, paramos el viejo (o mejor le ponemos otra IP) y la “trasladamos” al nuevo.
  11. Iniciamos la consola de DHCP, y desde ella arrancamos el servicio. Autorizamos el servidor y… hemos acabado Smile with tongue out
  12. Basta validar que nuestros equipos renuevan las IPs y listo, a otra cosa.

Todas estas acciones se han realizado siguiendo la guia oficial de Microsoft: DHCP Server Migration Guide (http://technet.microsoft.com/en-us/library/dd379535(v=ws.10).aspx)

 

Saludos,

Marc

Categories: Dia a dia Tags: , ,