Cuando nuestro Dominio Active Directory comprende más de un sitio físico es muy importante que configuremos el Dominio adcuadamente. De esa forma le debemos “explicar” qué sitios, generalmente geográficos, que subredes IP hay en cada uno, y cómo se conectan físicamente estos sitios
De esta forma obtendremos dos beneficios importantes: una reducción y control del tráfico de replicación entre Controladores de Dominio, y además que cuando un cliente busque un servicio de red, desde un Controlador de Dominio hasta cualquier aplicación “Site aware”, trate siempre de encontrarlo localmente sin hacer tráfico sobre enlaces WAN
En esta ocasión aprovecharé la infraestructura ya creada para la nota Windows Server 2012: Conectando Sitios por VPN (Site to Site VPN)
En la misma disponemos ya de dos sitios geográficos interconectados por medio de VPN
Vuelvo a poner el diseño que quedó de la nota anterior
DC1 ya es Controlador de Dominio de root.guillermod.com.ar y DC2 es un servidor miembro del Dominio que luego promoveremos a Controlador de Dominio
Comenzaremos configurando nuestra infraestructura de Sites, Subnets y Links
Sites: aunque no siempre es así, en la mayoría de los casos un Site lo podemos asimilar a un sitio físico, por ejemplo una sucursal, delegación u oficina remota de la organización
Subnets: estas son simplemente las subredes IP que tendremos en cada Site. En un Site inclusive podríamos tener más de una subred IP. Lo que sí debemos tener en cuenta es que no podemos usar la misma subred IP en diferentes Sites ya que de esa forma no funcionaría los Routers 🙂
Esta información de Subnets es la que permite conocer en qué Site está cada máquina
Links: estos son las conexiones físicas, independiente del medio, que conectan nuestros Sites. Una aclaración importante porque hay mucha “mentira” dando vueltas por Internet: un Link no está asociado a ningún “path” físico; eso lo manejan los Routers
Definidos los tres elementos importantes comenzaremos la configuración
La configuración por omisión la podemos ver en la consola Active Directory Sites and Services.
El sistema crea por omisión un Site llamado “Default-First-Site-Name” que contiene todas las subredes que podamos crear, y un Link llamado “DEFAULTIPSITELINK”
El motivo de esta configuración es porque si quisieramos comenzar por definir un nuevo sitio obligatoriamente tendríamos que conectarlo al “Default-First-Site-Name” mediante un Link.
Y si quisiéramos comenzar definiendo el Link, deberíamos primero crear por lo menos un segundo Site
Luego no podríamos comenzar 🙂
Veamos el aspecto que presenta Active Directory Sites and Services antes de comenzar
Podemos observar que está creado el Site por omisión, que por ahora “contiene” solamente al único Controlador de Dominio; los servidores miembros no aparecen acá, sólo los Controladores de Dominio ya que se trata de manejar la información de replicación de Active Directory
Si revisan un poco la consola verán que en Subnets no hay nada, está vacío
Pero si miran en “Inter-Site Transports” verán que hay dos carpetas que definen qué protocolo se utilizará para la replicación de Active Directory entre los Controladores de Dominio, aclaremos esto ya
La opción SMTP (si, correo electrónico) por experiencia y preguntas creo que no fue nunca utilizada. Básicamente por varios motivos: genera casi el doble de tráfico que la otra, requiere infraestructura de clave pública (mensajes firmados y cifrados para la replicación) y creo que la más importante: el Sysvol no puede replicarse por SMTP, luego la única opción es que en diferentes Sites existan Dominios diferentes, aunque estén dentro del mismo Forest (Bosque)
Resumiendo, importante limitación, configuración de servicios adicional y poca eficiencia
La segunda opción IP, que es donde está creado el “DEFAULTIPSITELINK”, en realidad es RPC (Remote Procedure Call) sobre IP, sin ninguno de los inconvenientes mencionados de la opción anterior
Como la demostración utiliza dos sitios geográficos argentinos (Buenos Aires y Mendoza), suponiendo que estoy en Buenos Aires (BAires) comenzaré renombrando el Site por omisión a BAires
A continuación con botón derecho sobre Subnets indicaré qué subnet IP se está usando en BAires
A continuación crearé el Site llamado Mendoza con botón derecho sobre Sites
Como para poder crearlo es obligatorio asociarlo a un Link utilizaré el DEFAULTIPSITELINK
Y por supuesto el sistema me da las recomendaciones del caso 🙂
Siguiendo las recomendacions, que por otra parte son requisito, en forma análoga a como lo hicimos anteriormente crearé una subred asociada al Site Mendoza
Como el DEFAULTIPSITELINK es el Link que quedó comunicando BAires con Mendoza, por claridad lo renombraré
Vamos a mirar y eventualmente cambiar algunas configuraciones que por omisión tiene este Link
Podemos corroborar que efectivamente conecta nuestros dos Sites, e inclusive podemos ver que la frecuencia de replicación entre los Sites será de 3 horas (180 minutos). En este caso he disminuído esta a 15 minutos que es lo mínimo
Si entramos por el botón “Change Schedule” podremos ver que inclusive podemos seleccionar los horarios en los que está permitida la replicación. Por ejemplo si tuviéramos enlaces muy congestionados, que sólo se replique fuera del horario laboral
Observemos cómo queda con lo hecho hasta ahora
Bien, ahora ya podemos comenzar con la promoción de DC2 a Controlador de Dominio.
No pongo las capturas de cómo agregar el Rol, lo doy por conocido, sólo veremos las capturas del proceso de promoción
Lo primero es seleccionar que promoveremos un “Controlador de Dominio adicional en un Dominio existente”
Observen que como hemos creado el Site Mendoza el sistema ya nos ofrece ponerlo en dicho Dominio, esto lo sugiere en base a la dirección IP de DC2 que configuramos que estaba en el Site Mendoza (192.168.2.0/16)
El resto es lo clásico
Luego que reinicia DC2, voy a DC1 y refresco la consola Active Directory Sites and Services y puedo observar que ya aparece DC2 en el Site Mendoza
En pocos momentos aparecerá el primer Objeto Conexión, está creado en DC1 y es que permite la replicación desde DC2 hacia DC1
Si nos apuramos y tratamos con botón derecho sobre el Objeto Conexión de forzar una replicación obtendremos el siguiente mensaje de error. Hay que dejar pasar normalmente de 15 a 30 minutos
Deberíamos aprovechar el tiempo de espera para descansar, pero yo en cambio comienzo a mirar el Event Viewer de DC1 a ver qué eventos relacionados hay
Puedo observar que hay un evento relacionado a la creación del Objeto Conexión antes mencionado
Seguido de una advertencia lógica, pues DC2 aún no ha finalizado su configuración
Me decido esperar unos minutos y finalmente aparecen ya creado ambos Objetos Conexión
El de DC2 a DC1
Y el de DC1 a DC2
Trato de forzar ahora una replicación
Pero vemos que no permite pues los Controladores de Dominio están en diferentes Sites. Me informa que se hará de acuerdo a lo programado (en el Link BAires-Mendoza)
Pero de todas formas, si lo probáramos en realidad miente un poco 😉
Lo que no puede es replicar el Sysvol, pero el NTDS.DIT lo replica
Si observamos el Event Viewer de DC2 veremos que este ahora se ha hecho cargo del Site Mendoza
Inclusive podemos notar también que es quien se ha hecho cargo de la autenticación del usuario
Y lo último, revisemos que todo esté bien, vamos a Active Directory Uses and Computers para verificar que están ambos Controladores de Dominio 😉
Hasta acá llegamos esta vez
A partir de una infraestructura que emula dos sitios geográficos hemos implementado un segundo Controlador de Dominio, en un sitio remoto, “explicándole” al sistema cómo es nuestra estructura física, y cómo están conectados los sitios
