Migración de AD de SBS2011 a 2012 R2 y nuevo dominio

Tenemos un server SBS2011 existente, y nos gustaría migrar a un nuevo server R2 2012. Idealmente, nos gustaría hacer esto en un nuevo dominio – 1. nos gustaría reorganizar las OUs para eliminar el "SBS" llamado cosas (es decir, todos los usuarios no están en los usuarios, que están en SBSUsers, etc ..) y 2. nos gustaría ir a un nombre de dominio que está más en línea con las mejores prácticas (subdomain.ourdomain.com en lugar de name.local).

Estoy tratando de averiguar la mejor manera de hacer esta migration. La mayoría de las cosas que he leído dicen que migrar agregando el nuevo DC al dominio existente, promoviéndolo, dejando todo sincronizado y luego rebajando el antiguo. Sin embargo, esto no aborda ninguna de nuestras preocupaciones en relación con el nombre o la reorganización.

También pensé en algo quizás algo cruzado, pero de lo que puedo decirle necesita ya sea ADMT (no soportado para 2012), o posiblemente una herramienta de pago (no es una opción probable, ya que somos una organización sin fines de lucro y tienen un presupuesto mínimo para esto).

Por último, podría exportar los usuarios e importarlos, pero esto parece que implicaría diferentes pasos para los usuarios, computadoras, grupos, etc … y me preocupa lo bien que se acoplaría. También, nuevamente hasta donde puedo decir, sin una de las herramientas antedichas (y posiblemente incluso no entonces!) Todavía no puedo hacerlo sin hacer que todos los usuarios reajusten sus passwords.

Exchange no es una variable aquí (¡no lo creo!), Ya que lo estamos migrando a Office 365, y por simplicidad no añadir SSO por ahora, hasta que todo lo demás se ordera.

¿Hay una opción que me falta que nos permita cumplir con todos nuestros criterios – la capacidad de cambiar el nombre de dominio y mantener el layout de OU estándar en lugar de SBS, no comprar una costosa herramienta de terceros, y no tener impacto en la count de usuario / passwords ?

Exchange 2007 y versiones más recientes le impiden realizar un cambio de nombre de dominio . Puesto que usted dice que está abandonando el intercambio de premisas, eso no es un factor. Eso abre la puerta para lo que creo sería un process mucho más fácil que cualquier tipo de creación de un nuevo bosque o dominio:

  • Complete la migration a Office 365 y elimine Exchange de su entorno de SBS 2011.

  • Agregue un DC temporal a su dominio existente y migre AD (y todas las funciones de FSMO) del server SBS, devolviendo el server SBS de nuevo a un miembro de dominio en el process. (Después de este punto tendrá 21 días para completar la migration.)

  • Realizar el cambio de nombre de dominio.

  • Agregue su DC W2K12 R2 permanente y rebaje / quite el DC temporal.

  • Renombrar / mover las OUs (GPO, etc) en AD a su gusto.

  • Migrar cualquier otra function fuera de la máquina SBS y desactivarla.

El CD temporal no es estrictamente necesario, pero probablemente lo haría (porque soy supersticioso). El cambio de nombre de dominio suena difícil, pero sin Exchange es realmente bastante sencillo. Si estás preocupado, haz un simulacro de tu entorno usando máquinas virtuales en una networking aislada y pruébalo (preferiblemente usando una copy real de tu AD "cosechada" de tu networking de producción y colocada en el entorno virtual).

Vas a tener que abandonar la autoridad de certificación pnetworkingeterminada que creó la configuration de SBS 2011 cuando haces esto, también. El desmantelamiento de una empresa CA no es realmente tan difícil, tampoco, suponiendo que no lo esté utilizando para nada. (Si es así, no importa qué estrategia de migration tome, tendrá que preocuparse por eso.)

Cuando termines, tendrás un nuevo y shiny nombre de dominio, tus OUs se verán como lo quieras, todas las passwords de los usuarios estarán intactas y todos los orderadores miembros del dominio tendrán trusts de dominio intactos.

Planificado, probado y ejecutado correctamente, el cambio de nombre y migration del dominio de producción puede tardar sólo un par de horas en completarse. (Obviamente, el time que pasas en la planificación y testings anteriores te pagará dividendos inmensos cuando realmente haces lo real).

(También exportaría partes de la nueva máquina W2K12R2 que reflejaba las partes exportadas por la antigua máquina SBS y agregaría la máquina SBS como un alias DNS al nuevo server.A continuación, los accesos directos existentes, UNCs, etc, sólo trabajo "después de la migration.)

Editar:

No sé por qué la gente consigue tan cagey alnetworkingedor del renombre del dominio. Necesitas planearlo y ejecutarlo metódicamente, pero ha sido indoloro para mí. He hecho tres renombres del dominio de la producción y no tenía ninguÌ n problema (con exception olvidado largo de FQDNs en uso en los dispositivos incorporados que necesitaron ser cambiados). Dos entornos tuvieron Exchange 2003 y uno no. Uno tenía un solo DC, los otros dos tenían varios DCs. Me burlé de los dos primeros (los entornos que tenían Exchange) en VMs, pero el tercero sólo corrió en la networking de producción w / o mockup (porque era tan simple – DC único, no Exchange).

Aquí está el punto de vista desde arriba, "Realizar el cambio de nombre de dominio", desglosado en pasos.

En términos de artículos de Microsoft, prefiero: Cómo funciona el nombre de dominio El artículo contiene una gran cantidad de background superfluo, pero los pasos básicos están allí.

Para un bosque de dominio único con un único DC, el process es bastante indoloro:

  • Desactive cualquier raíz de CA de empresa.

  • Cree una nueva zona DNS integrada de AD para el nuevo nombre de dominio.

  • Establezca el nivel funcional del bosque en Windows 2003 o superior.

  • Ejecute rendom /list para generar el file de descripción del bosque ( Domainlist.xml ).

  • Edite el file Domainlist.xml para reflejar los nuevos nombres de dominio DNS y NetBIOS.

  • Ejecute el rendom /showforest , que muestra el file Domainlist.xml de una manera "amigable" y revise la salida para asegurarse de que realizó las modificaciones adecuadas.

  • Ejecute el command rendom /upload para instalar el nuevo nombre de dominio en Active Directory. En este momento no se produce ningún cambio de nombre, solo estás preparando AD para cambiar el nombre. En un ambiente multi-DC esto iniciaría la replicación de las instrucciones de cambio de nombre a todos los DCs.

  • Ejecute el command rendom /prepare para verificar la disponibilidad para cambiar el nombre. En un entorno multi-DC, este command comtesting cada DC para asegurar que todos ellos han recibido las instrucciones de cambio de nombre. El cambio de nombre no puede comenzar hasta que todos los DC hayan replicado las instrucciones de cambio de nombre. (Es necesario que el cambio ocurra en todas las réplicas de la database de AD casi simultáneamente.) Una vez que haya ejecutado rendom /prepare no podrá agregar nuevos dominios al bosque o DCs al dominio hasta que haya ejecutado rendom /clean ).

  • Ejecute el command rendom /execute para ejecutar el cambio de nombre. Esto instruye a los DCs para realizar el cambio de nombre. Cada DC cambiará su database AD en un modo de mantenimiento de un solo usuario, realizará el cambio de nombre y reiniciará de nuevo en un estado operativo normal.

  • Una vez que todos los DC hayan completado el renombre, ejecute 'Gpfixup' con los nombres de dominio antiguos y nuevos apropiados para actualizar cualquier reference al nombre de dominio antiguo al nuevo nombre en Objetos de directiva de grupo.

  • Cambie el sufijo DNS primario en cada DC porque no cambian automáticamente . No sé por qué Microsoft no tenía estos cambios automáticamente, pero no lo hicieron. Reinicie el DC nuevamente después de realizar este cambio.

  • Reinicie todos los equipos miembros de dominio dos veces. Esto no tiene que ser hecho inmediatamente (guardé un dominio en este estado por un par de semanas). Los equipos miembros del dominio "detectarán" que se ha realizado un cambio de nombre de dominio y se actualizan automáticamente durante estos dos reinicios.

  • Una vez que haya reiniciado todos los equipos miembro del dominio, ejecute dos veces el command rendom /clean para borrar las instrucciones de cambio de nombre de AD y devolver el dominio a un estado operativo normal.

  • Elimine la zona DNS del dominio antiguo de AD una vez que haya migrado los loggings de miembros que no pertenezcan al dominio.

Como he dicho – un solo dominio, un único entorno de DC es simple porque no tiene que preocuparse por la replicación de las instrucciones de cambio de nombre de dominio o ser capaz de ponerse en contacto con todos los DC.

En cuanto a los efectos secundarios:

  • Debe saber que los nombres de la raíz de DFS del dominio cambiarán. Si tiene la installation de software de directiva de grupo procedente de routes de DFS de dominio, verá reinstalaciones de software (porque el cliente de directiva de grupo creerá que el software no está instalado).

  • Si /clean el dominio demasiado pronto (antes de que se hayan reiniciado todos los equipos miembros dos veces), podría ejecutar un estado en el que tenga máquinas que deben separarse manualmente y volver a conectarse al dominio.

  • En entornos más grandes verá un mayor tráfico de replicación mientras se instalan las nuevas zonas DNS.