En esta nota, y como continuación de la infraestructura de Active Directory que estamos creando de acuerdo al diseño aceptado, procederemos a promover un Controlador de Dominio del Dominio Raíz (root.guillermod.com.ar) en un Site remoto (Mendoza)
Hay varios motivos por los cuales puede ser conveniente que en un Site que tendrá un “dominio propio” (mza.root.guillermod.com.ar) se instale un Controlador de Dominio de uno que corresponde a otro Site
Para poner como ejemplo sólo uno: que sea habitual que usarios que tienen cuenta en root.guillermod.com.ar incien sesión en máquinas del sitio remoto Mendoza, y además se desea que en caso de problemas con el enlace WAN los mismos puedan inciar sesión sin inconvenientes
Como recordatorio, incluiré nuevamente el diagrama propuesto en la nota inicial de la infraestructura a crear. En esta nota promoveremos a Controlador de Dominio a DC3, que es un Controlador de Dominio del Dominio Raíz (root.guillermod.com.ar) pero que estará físicamente en un Site remoto (Mendoza)
Lo primero que debemos hacer es confirmar la conectividad entre las subredes IP que hemos definido
La conexión entre las redes la podemos hacer de dos formas diferentes, una “más real”, y otra más práctica para un ambiente de pruebas como el que estamos desarrollando
La “más real” podríamos hacerla utilizando dos servidores y configurar una “VPN Sitio a Sitio”. Pueden ver un ejemplo de configuración con paso a paso en Windows Server 2012: Conectando Sitios por VPN (Site to Site VPN)
La “más práctica” la pueden ver en la nota publicada en este mismo sitio con el nombre “Configurando un Router (Enrutador) Para Ambiente de Pruebas – “El Router de un hombre pobre”»
Por otro lado, como vamos a proceder a la promoción de un nuevo Controlador de Dominio debemos disponer de una nueva instalación de Windows Server 2012 (no clonar anteriores, o alternativamente ejecutar SYSPREP)
De acuerdo a lo planificado le he dado el nombre DC3, y he configurado adecuadamente IPv4
Para verificar que existe conectividad con uno de los Controladores de Dominio existentes, e inclusive que se pueden resolver los nombres, podemos probar con PING y NSLOOKUP
Como no hace falta, y a la vez ahorrar un reinicio, procederemos a configurarlo como Controlador de Dominio adicional en el Dominio existente sin necesidad de tenerlo unido previamente al Dominio, está en grupo de trabajo
Debemos instalar el Rol correspondiente, que no mostraré las capturas de pantalla porque ya lo hemos hecho muchas veces, es siempre igual, sólo mostraré desde el momento de la configuración como Controlador de Dominio
Nos aseguramos que esté marcada la opción “Add a domain controller to an existing domain”, y como la máquina está en grupo de trabajo, nos convendrá ingresar manualmente el nombre del Dominio sin usar el botón “Select”, e ingresar las credenciales correspondientes usando el botón “Change”
En la siguiente pantalla podremos observar que además de lo habitual (DNS y GC), automáticamente, gracias a que ya hemos creado los Sites, con la información de la configuración de TCP/IP se ha asignado al Site Correcto (Mendoza)
Sólo deberemos completar la contraseña DSRM
Vemos que podríamos seleccionar desde qué Controlador de Dominio se hace la replicación inicial
Trabajará unos minutos
Y reinciará automáticamente al finalizar el proceso
Cuando esté disponible podremos iniciar sesión con el administrador de Dominio, y deberíamos verificar que todo esté correctamente, pero espere… tenga un poco de paciencia, hasta que todo quede “como debe ser” suelen pasar hasta 30 minutos, así que es momento para un descanso
¿Ya volvió? bueno, continuamos entonces.Observemos si ya se han creado los Objetos Conexión entre los Controladores de Dominio
En DC1, voy a “Active Directory Sites and Services” y ya se puede observar que se ha creado el “Objeto Conexión” que replica desde DC3 hacia DC1 ¡Bien!
Si me quiero apurar y forzar una replicación en este momento, pueden que se encuentren con el siguiente cuadro, no preocuparse, esperar un poco
Si ahora en DC3 vamos a “Active Directory Sites and Services”, y dejamos pasar el tiempo suficiente (F5, F5, F5, …) ya veremos creado el Objeto Conexión, que en este caso es desde DC2 a DC3
Esto es porque DC2 ha asumido la función de “Bridgehead Server” para el Site Mendoza
Si tratamos de forzar una replicación, y no recibimos el mensaje mostrado anteriormente, nos encontraremos con otro
Es lo esperable, cuando dos Controladores de Dominio se encuentran en Sites diferentes, por omisión, la replicación se hace de acuerdo a la programación, y no se puede forzar.
En realidad es casi una mentira :-) Lo que no puede replicarse de esta forma es la replicación de la carpeta SYSVOL, la base de Active Directory (NTDS.DIT) se ha replicado
Entonces ahora ya llegó el momento de hacer algunas verificaciones adicionales para ver que todo esté funcionando correctamente
Lo primero que haré es ir a “Active Directory Users and Computers” en cualquiera de los Controladores de Dominio, y verificar que en la Unidad Organizativa Domain Controllers estén presentes las tres correspondientes máquinas
Además vamos a verificar que en DNS estén las registraciones correctas y necesarias, no sólo los registros A
Podemos ver que se han registrado en el Site Central los Controladores de Dominio de este Site
Y que DC3 se ha registrado para cubrir el Site Mendoza
En la configuración de TCP/IPv4 podemos observar que ha hecho el cambio habitual (127.0.0.1)
Podemos cambiarlo si deseamos
Es muy buena idea, además de lo hecho, revisar el “Event Viewer” por errores. Como vemos en este caso, son sólo las advertencias esperables
Dejamos hasta acá, en la próxima nota configuraremos el Controlador de Dominio de sólo lectura (RODC) para el Site Cordoba en la nota “Instalación de Active Directory – Promoción de un RODC (Read Only Domain Controller) – Nota VI»
WindowServer 
Comentarios
Excelente muy bien explicado.
Esperemos el siguiente tema
Saludos
Gracias David
Ya está casi lista la nota IV promocionando el RODC, si no llego hoy ya la publicaré seguramente mañana
Guillermo una duda, es necesario que el ITadmin de Mendoza, conozca la clave de administrador del DC3? de ser así tendría acceso completo al AD del dominio root no?
Habría alguna forma de limitar que pudiera hacer cambios en el AD del root o evitar que haga remote desktop a DC1 y DC2?
Agradecido por estas notas que despejan muchas dudas!!!!
La pregunta está relacionada justamente con una de las dificultades de la infraestructura, y viene muy bien tu pregunta
:-)
DC3 es un Controlador de Dominio del Dominio raíz (Root), es parte de «root.guillermod.com.ar». Lo único «extraño» es que este Controlador de Dominio está en un Sitio (Site) diferente, donde luego se creará un Dominio específico para el mismo.
El motivo, como fue planteado en la primera nota, es para asegurarse que los usuarios del Dominio raíz puedan iniciar sesión en el sitio Mendoza, si el enlace estuviera caído. Otro motivo podría ser porque fuera habitual que usuarios del Dominio raíz estuvieran físicamente en el sitio Mendoza
Y por lo tanto, como DC3 es un Controlador de Dominio, del Dominio raíz (root.guillermod.com.ar), es exactamente lo mismo que DC1 o DC2, solamente es que «esta lejos» :-)
Cuando comencemos con la instalación de DC4, ese es otro tema, porque este sí es de un Dominio diferente
Muchas gracias por este excelente artículo! La verdad ha sido de mucho apoyo para mi! Solamente tengo una consulta, al tener 3 DC para mi root domain, ¿cómo tendrían que quedar los «Forwarders» de cada DNS? ¿estos deben quedar solamente hacia un proveedor público o deben redirigirse entre ellos mismos? Gracias!
El tema es así, para poder resolver nombres de Internet por lo menos uno debe tener Reenviadores a los del proveedor de Internet
Suponiendo que tengas DC1, DC2 y DC3, los tres con DNS
Si DC1 y DC2 «forwardean» a DC3 y este a los del proveedor, tienes la ventaja que DC3 tendrá el «cache DNS» más completo, pero por otro lado tienes el inconveniente de poder sobrecargarlo
Si cada DC sale al ISP, no sobrecargas, pero puedes generar un poco más de tráfico porque cada uno mantiene su propio «cache DNS»
Funcionará de las dos formas
¡Muchas gracias! Solamente un detalle adicional. Actualmente tengo 2 sites distribuidos así: 2 DC en mi site «root», 1 DC de mi «root» en el site remoto, y 1 DC para el child domain en el site remoto. Pregunto: ¿En los DC que están localmente en mi site «root», debo configurar en los «forwarders» la IP del DC del child domain ubicado en mi sitio remoto? Gracias nuevamente
En lo que llamas «site root» que entiendo que en realidad es el «site central» (porque los que pueden ser «root» son los Dominios) en los DNSs en realidad debería haber una delegación al Dominio «child», no «forwarders»
¡Correcto a eso me refería a mi site central! ¿Podrías explicarme un poco más sobre la delegación? Mi intención es garantizar correctamente la resolución de nombres desde mi dominio root hacia el child. gracias!
¿Querés que escriba un curso de DNS en los comentarios de una nota? :D :D :D
Revisa las 3 notas que ya están en el blog y que explican el funcionamiento de DNS
Cómo funciona DNS – Parte 1 | WindowServer:
https://windowserver.wordpress.com/2011/05/07/cmo-funciona-dns-parte-1-2/
Cómo funciona DNS – Parte 2 | WindowServer:
https://windowserver.wordpress.com/2011/05/26/cmo-funciona-dns-parte-2/
Cómo Funciona DNS – Parte 3 – Integración con Active Directory | WindowServer:
https://windowserver.wordpress.com/2011/06/24/cmo-funciona-dns-parte-3-integracin-con-active-directory/
Jajaja, muchas gracias de verdad!
Trackbacks
[…] En la próxima nota configuraremos DC3, que es un Controlador de Dominio de “root.guillermod.com.ar” que estará ubicado en el Site Mendoza: Instalación de Active Directory – Promoviendo un Controlador de Dominio en un Site Remoto &#… […]
[…] Instalación de Active Directory – Promoviendo un Controlador de Dominio en un Site Remoto – Not… […]
[…] Instalación de Active Directory – Promoviendo un Controlador de Dominio en un Site Remoto – Not… […]
[…] Instalación de Active Directory – Promoviendo un Controlador de Dominio en un Site Remoto – Not… […]