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

Seguimos con la serie de entradas sobre la migración de bosques AD. Si recordáis los datos obtenidos en el análisis deberíamos tener suficientes datos para una versión inicial del diseño de nuestra solución.

Por supuesto este diseño ha de cumplir con los mínimos que nos diga el cliente pero también hemos de tener la libertad para generar un nuevo entorno funcional, adecuado y escalable en el futuro.

En la solución inicial propuesta tendríamos:

1. Un mínimo de dos Controladores de dominio para garantizar un mínimo de alta disponibilidad
2. Un mínimo de máquinas para tener una estructura Exchange en alta disponibilidad. En este caso deberían ser 4, como en el entorno analizado.
3. Un equipo que haga las funciones de OCS, dado que no está soportado la migración inter-forest de este software.
1. Posibilidad de instalar un Lync 2010
4. Un plan de migración de ILM. En su defecto, montar un FIM 2010 y coordinar su entrada en funcionamiento
5. Procesos de migración de servidores: SQL, FileServer, antivirus, Print Servers, etc.
6. Procesos de migración de usuarios, buzones, equipos, etc.
7. Revisión de las GPOs
8. Revisión de login scripts, si hubiera más de uno.

Sobre esta base generaremos la documentación necesaria, un Project con los hitos obtenidos y a obtener e iremos solicitando la creación de máquinas virtuales necesarias para cada rol en concreto.

Hay que tener en cuenta que, además, necesitaremos un equipo que usaremos como servidor de migración de recursos así como repasar todos los pasos necesarios para instalar la herramienta de Microsoft que realizará estos pasos: ADMT en su versión 3.2 para nuestro caso, y toda su documentación bien aprendida

Marc

Dentro del parche acumulátivo para el IE 9 de este mes de agosto, los chicos de Microsoft «suben» la build del IE9 de la 9.0.1 a la 9.0.2

http://blogs.msdn.com/b/ie/archive/2011/08/09/ie-9-0-2-available-via-windows-update.aspx

Después de aplicar el parche, IE se muestra como sigue:

De la anterior fase de análisis hemos de ser capaces de detectar problemas. Por ejemplo se me ocurren varios, totalmente inventados, que podrían ser:

1. Existe un único bosque con un dominio padre.
1. El nivel funcional del bosque es Windows Server 2003
2. El nivel funcional del dominio es Windows Server 2003
3. Todos los roles del bosque y dominio están en un único DC
2. Existen 3 DCs: Dos con Windows Server 2008 R2, Español y uno con Windows Server 2003 R2
3. El login script está escrito en formato kik y proviene de un entorno Windows NT4. Además, este script no se ha ido manteniendo ni revisando teniendo un tamaño en páginas de 27.
1. La aplicación de ese script es mediante un .bat asociado a cada cuenta de usuario en el AD. Esta estructura de aplicación no es ágil ni facilita su mantenimiento ni cambio rápido en caso de necesidad
2. Se acuerda con el cliente depurar el script y convertirlo a .VBS para aplicarlo por GPO a nivel de dominio.
4. Hay unos 350 usuarios y 200 grupos, tanto de seguridad como de distribución
5. Hay creadas múltiples GPOs pero la gran mayoría no se usan, están mal aplicadas o sencillamente no están aplicadas.
1. Antes de realizar la migración, se deberá depurar qué GPOs son útiles y cuales no.
6. A nivel de DNS, existe una zona integrada en el AD pero sin manteminiento automático
1. Se sugirere activar el Aging & scavenging
7. Hay tres sites con 2 DCs en uno, el tercero en un segundo site mientras que el tercer site no tiene DC asociado.
1. Las subnets de los Sites para cada zona del AD no están correctamente definidos ni por supuesto asociados.
8. A nivel de servicios DHCP, este servicio sólo lo proporciona uno único equipo que además actúa como DC.
1. Se detectan muchas reservas de IPs en algunas zonas
2. Se analiza la opción de exportar e importar el servicio de DHCP entre diferentes dominios siguiendo el DHCP Server Migration Guide
3. Como paso posterior, se suguiere al cliente dividir el servicio DHCP entre dos equipos siguiendo la regla del 80/20 y aplicando un concepto nuevo de Windows Server 2008 R2: DHCP Split Scope
9. El entorno de correo está compuesto por 4 servidores Windows Server 2008 R2 sobre los cuales corre un Exchange 2010, sin SP1 ni ningún tipo de Roll-Up
1. Dos servidores tienen los roles de HT y CAS mientras que los otros dos forman un clúster DAG
2. Los servicios de OWA, ActiveSync y Outlook Anywhere se publican vía Forefront TMG 2010
10. El File Server es, además, uno de los DCs del dominio a migrar. Esto implica que este servidor no puede migrarse si no es degradado antes en su función de Controlador de Dominio. Además, ese File Server tiene un software de gestión de cuotas de una tercera empresa
11. El Print Server es un Windows 2000 Server – fuera de soporte – que el cliente informa que no se deberá migrar porque los servicios de impresión se están moviendo a otro servidor. El problema es que ese otro servidor es uno de los DCs del dominio, sobre el que corre un Windows Server 2008 R2
12. El servidor de antivirus es una versión de McAfee no soportada y totalmente obsoleta. Se decide, junto con el cliente, montar un nuevo servidor ePO desde cero en el futuro nuevo dominio y migrar manualmente los equipos cliente.
13. Se detecta un servidor ILM 2007 FP1 que se usa para sincronizar las contraseñas del AD contra dos servidores Sun LDAP. De acuerdo con el cliente, se decide no migrar ese ILM y montar un FIM 2010 en el nuevo dominio.
14. Se localizan varios servidores SQL con distintas versiones que van desde SQL 2000 Enterprise pasando por la MDE, SQL Server 2005, SQL 2005 Express y SQL Server 2008 donde se apoyan múltiples servicios.
15. Se encuentran varias cuentas de servicio en el AD que levantan una o varias instancias de los servidores SQL, servicios de anti-spam (IronPort) y servicios de proxy (BlueCoat)

Como podéis ver, un buen análisis nos tiene que dar como mínimo la información suficiente para generar la documentación escrita necesaria para generar un Visio que nos de una visión rápida de todo el entorno.

Siguiente paso, diseñar la solución de migración. Otro día.

Marc

Aprovechando que tengo algo de tiempo libre – que no mucho – voy a intentar ir describiendo las diferentes fases que se deberían seguir en todo proceso de migración de bosques de Directorio Activo.

Obviamente, y digo «obviamente» porque siempre debería ser así, lo primero que hay que realizar es un análisis lo más exhaustivo posible del entorno a migrar.

Como puntos a tener en cuenta necesitamos conocer:

1. Número de dominios en el bosque
1. Nivel funcional del bosque
2. Número de Domain Controllers que componen ese Directorio Activo por dominio, en el caso de que dentro de ese bosque se detecte más de un dominio
1. Características de esos DCs
2. Nivel funcional del dominio
3. Número de sites que componen cada dominio
4. Login script que se aplica al dominio y su alcance
5. Número de GPOs, alcance y aplicación de las mismas
6. Número de usuarios y grupos
7. Número de servidores DNS así como las zonas que estén configuradas en los mismos
8. Número de servidores DHCP, si los hay y cómo están configurados
1. Integrados en el AD, equipos Windows.
2. No integrados en el AD y servidos por equipos no unidos al dominio, como routers, servidores no-Windows, etc.
9. Qué otros servicios hay en el dominio
1. Entorno de correo
2. Servicios y servidores de mensajería instantánea
3. Entorno de bases de datos
4. Servicios de telefonía IP, si aplica
5. Servidores de impresión
6. Servidores de antivirus
7. Servidores de ficheros
10. Infraestructura de red y direccionamiento de la misma.

Con todos esos datos y los que se vayan «descubriendo» según se avanza el análisis deberíamos ser capaces de plantear un diseño de migración entre dominios/bosques lo más transparente y robusto posible.

Pero esto ya os lo contaré en la próxima «entrega»

Marc

No estaría mal que, después de «Saludar» ponga en qué ando metido últimamente, que vendría a ser desde finales de Mayo.

Pues nada raro. Es un proyecto para un cliente que consiste en hacer una migración completa de su bosque Windows a uno nuevo. Y no es que el bosque, llamémosle «viejo» no funcione no es que sencillamente el nombre FQDN del mismo no cumple con los estándares de la RFC.

Y porqué no los cumple. Bien… se llama «mi_dominio.local» (obviamente, el nombre no es el real por temas de NDA). Si bien ese nombre FQDN no es correcto, no habían tenido problemas con él ya que se generó una zona secundaria con el nombre «miempresa.com» y todo se resolvía por ese otro dominio hasta que… se decidió integrar una cabina de discos la cual dijo que con ese nombre no hacía un join al dominio y que de allí no pasaba.

Tampoco es que al sistema de correo, un Exchange 2010, le gustase mucho, sobretodo al intentar instalar el SP1 del mismo así que… a migrar de bosque toca a algo parecido a «midominio.local»

Lo bueno es que sólo son 200 usuarios y 250 cuentas de correo.

Lo malo, que tienen casi todos los productos de Microsoft instalados en diferentes versiones y sabores. Es decir:

• SQL 2000, 2005 y 2008, en versiones Standard y Express (MDE para la 2000)
• Servidores con Windows 2000, 2003, 2008 y 2008 R2, en Español e Inglés y distintos niveles de parcheado.
• OCS 2007 R2
• ILM 2007 con FP1 pero sin SP1 para sincronizar passwords con servidores LDAP de Sun en la capa de aplicación
• Clientes Windows XP SP3
• El citado Exchange 2010
• Blackberry Enterprise Server con sus BB
• Clientes ActiveSync que, básicamente, son iPhone y iPad
• Forefront TMG 2010 SP1 con una configuración algo particular para publicar OWA, ActiveSync y Outlook Anywhere
• La gran mayoría de esos equipos, excepto los clientes XP, bajo dos entornos VMWare que se estaba consolidando

Nostamal, nada mal. Sólo faltaba un SCCM y un SCOM para acabar de liarla .

Bien, pues como todo en esta vida lo primero que se hizo (o hice) fue pasarme unas 2 semanas analizando en entorno donde encontramos:

• Servidores DNS integrados en 3 DCs dentro de 2 sites (aunque había 3 de definidos)
• La no asociación de las subnets a los sites
• Login script heredado de NT4 y escrito en KIK
• Un sólo servidor DHCP
• El FileServer era también DC en Windows Server 2003 SP2, sin R2
• Servidor ePO totalmente fuera de soporte. Por no estar no estaba ni en el listado de productos de McAfee

Las otras 2 siguientes, pensando en cómo montar todo desde cero e intentando que fuera de la mejor manera posible.

Finalmente, y es en lo que estoy, realizando pruebas de laboratorio, procedimentando y documentando todos los pasos, errores, workarounds y demás cosas para cuando se inicie esa migración de usuarios, grupos, buzones, equipos y servidores sea lo menos traumática posible.

Ya iré detallando fases… si es que las queréis conocer

Saludos,

Marc