Cmo funciona DNS Parte 1

En una red con Windows y TCP/IP, cada mquina tiene en realidad dos nombres: uno llamado Nombre NetBIOS y otro
llamado Hostname. Estos nombres son asignados a los equipos durante la instalacin, y son usados tanto por las
aplicaciones como por los que usamos los equipos y recursos de la red. En sistemas Pre-Windows 2000, el nombre que
se le asigna a una mquina durante la instalacin es el Nombre NetBIOS, este tiene una longitud mxima de 16
caracteres, aunque slo son utilizables 15, pues el dieciseisavo tiene uso reservado. Admite algunos smbolos (por
ejemplo _). Pero si vamos a las propiedades de TCP/IP vemos que tambin tiene asignado un hostname que por
omisin el sistema trata que sea igual al Nombre NetBIOS.

A partir de Windows 2000, en cambio, el nombre asignado durante la instalacin es el hostname que puede tener hasta
255 caracteres (Microsoft soporta hasta 24), pero que es mucho ms restrictivo ya que slo puede contener letras,
nmeros y el signo -. En estos sistemas si miramos en el lugar donde se cambia el nombre, notaremos que tambin
existe un Nombre NetBIOS pero que no lo podemos cambiar separadamente del hostname. De cualquier forma, y
esto es importante, en una red TCP/IP siempre que nos referimos a un equipo usando alguno de estos nombres, el
sistema necesita obtener qu direccin IP corresponde a dicho nombre. A este proceso se lo llama Resolucin de
Nombres.

Existen mtodos para resolver Nombre NetBIOS y mtodos diferentes para resolver hostnames. Si no tiene muy claro
el concepto es interesante que vea Resolucin de Nombres de Mquina (DNS, WINS, HOSTS, LMHOSTS, y etcteras).
En esta nota tratar de ver con cierto nivel de detalle la resolucin de hostname lo cual nos lleva indefectiblemente a
cmo trabaja el servicio DNS.

Lo hacemos como un cuento para que sea ms ameno? Haba una vez un grupo de gente muy estudiosa trabajando
con las primeras redes TCP/IP que cuando necesitaban acceder a otro equipo lo identificaban directamente escribiendo
la correspondiente direccin IP, y eso funcionaba perfectamente. Si, funcion perfectamente hasta que se fueron
agregando ms y ms mquinas y ya era difcil recordar esos nmeros (direccin IP) para cada uno de los equipos. A
partir de eso se busc algo que fuera ms fcil de recordar: un alias o apodo para cada mquina ya que eso es mucho
ms fcil para que un humano lo recuerde. Y as naci el hostname. Luego en cada mquina se deba tener un archivo
de texto que especificara qu direccin IP corresponda a cada alias (hostname). Esto es el archivo HOSTS. Este es un
mtodo muy eficiente para resolver nombres, pero tiene el inconveniente que hay que tenerlo y actualizarlo en cada
mquina.

Mientras Internet, o en ese entonces Arpanet, eran pocos equipos y con muy poca variacin esto fue una solucin. Segn
se cuenta, en el MIT (Massachusetts Institute of Technology) se mantena el archivo HOSTS central. Bastaba que cuando
se agregaba o cambiaba un equipo se avisara, y que peridicamente uno se trajera una copia actualizada y la
distribuyera entre sus equipos. Esto era muy bueno, pero a medida que sigui creciendo, se fue poniendo cada vez ms
difcil el mantenimiento del HOSTS central por su tamao, y como si fuera poco comenzaron los problemas por la colisin
de nombres, no poda haber dos mquinas con el mismo hostname.

Cmo se solucion esto. La solucin pas por dos puntos fundamentales:

Descentralizar la administracin

Armar una estructura jerrquica que solucionara las colisiones de nombres

As naci DNS (Domain Name System o Domain Name Server). En ese momento ya haban varias empresas
comerciales incorporadas, como as tambin agencias gubernamentales, universidades, etc. Por lo tanto se convino en
que cada una de ellas deba mantener un servidor de nombres (Name Server) que resolviera sus propios nombres.
Luego los clientes tenan configurado que cuando tuvieran que resolver un nombre le preguntaran a su servidor de
nombres (Name Server). Mientras el administrador local se ocupara de mantener manualmente sus propios mapeos de
nombre todo funcionaba perfectamente dentro de la propia organizacin. Esta base de datos donde se anotan los
nombres y su correspondiente direccin IP, se llama ZONA.

Hasta ac todo bien, pero slo se resuelve dentro de la propia organizacin, entonces cmo se hace cuando se quiere
acceder a un equipo que est en otra empresa u organizacin? Bien, para resolver esto se dispuso poner un servidor de

1 | Page
nombres que se encargara de resolver *solamente* los servidores de nombres de cada organizacin. Y estos ltimos
deban conocer a este servidor de nombres padre. Entonces funcionara de esta forma, cuando un cliente tiene que
resolver un nombre, se lo pregunta a su servidor de nombres, si ste lo puede resolver utilizando su propia ZONA,
responde segn se dice en forma Autoritaria o Autoritativa, pues tiene los datos localmente.

Pero si no tuviera los datos localmente entonces le preguntar al servidor de nombres padre para saber qu servidor de
nombres en particular le puede dar la respuesta. Este servidor de nombres padre le indicar al servidor de nombres
local a qu servidor de nombres debe preguntarle para obtener la respuesta final.

As como est planteado hasta ahora, todo funcionara, pero por variadas razones se hizo un poco ms complejo, no
mucho no asustarse. En lugar que todo el mundo tuviera un nico servidor padre se agruparon por rubro. Es de decir el
que resolva los que eran nombres comerciales se agruparon en uno, los gubernamentales en otro, los educativos en
otro, etc. etc. Arriba de todos estos, si haba un nico padre. Con un poco de imaginacin vemos que estamos
construyendo un rbol, o ms precisamente las races de un rbol. Todos las organizaciones comerciales colgando de
un servidor de nombres que maneja los COMerciales, y otras organizaciones gubernamentalescolgando del que
maneja los GOVernamentales, y educativas colgando del que maneja los EDUcativos, etc. Y por arriba de todo, o
sea el que conoce quienes son los que manejan a los COMerciales, GOVernamentales, EDUcativos, etc. hay un servidor
de nombres que sabe quines son estos ltimos.

Bueno, a esta altura paremos con los cuentos y vamos a cosas ms reales. Cada nudo de este rbol invertido que
estamos haciendo se llama Dominio de DNS o Dominio de Internet. Ms adelante daremos una mejor definicin. En la
parte inferior tenemos los dominios, por ejemplo: hp, microsoft, ibm, etc. que cuelgan del dominio com; nasa,
whitehouse, etc. que cuelgan del gov; purdue, mit, etc. que cuelgan de edu; y podemos seguir con los diferentes
grupos, que cada uno ya se imagina: org, net,mil y el que cada pas tiene a este nivel (ar, es, mx, etc.). Arriba de cada
uno de esos dominios de primer nivel hay otro servidor de nombres que slo conoce quienes son los servidores de com,
gov, edu, etc.

Lo que tuvieron problemas es para designar el nombre de este dominio raz, no hubo forma de ponerse de acuerdo, por
lo que qued sin nombre (un poco de humor). Es verdad se llama con el carcter nulo, pero como los humanos no lo
podemos representar y no lo podemos ver se lo representa por un punto (.). Como cada organizacin es responsable y
debe mantener la resolucin de nombres de su dominio, entonces cumplimos el primer objetivo que es distribuir el
mantenimiento.

Cada mquina (usemos la palabra host para ser ms tcnicos) necesita identificarse dentro de este rbol en una forma
nica (unvoca). Y esto se logra mediante el camino que va desde el propio host hasta el dominio raz. As por ejemplo
un host que est en el sitio de hp y tiene hostname server1 se identifica como: server1.hp.com. (Si, con punto al final)
y otro que tambin se llame server1 pero que est en el MIT, se llamar server1.mit.edu.. Este nombre que identifica
unvocamente cada host en el rbol se llama FQDN (Fully Qualified Domain Name) que todos los usamos cuando
escribimos un URL de Internet, aunque no sepamos que esa parte se llame as. Aunque nadie pone el punto final de un
FQDN, todas las aplicaciones lo dan por descartado y funcionan bien. Ms, cuando ms adelante veamos el contenido
de una Zona, veremos que el sistema agrega el . aunque no lo escribiramos. Lleg el momento de poner las cosas en
su lugar y ver cmo funciona esto. Vamos a suponer que en este momento se pone todo en funcionamiento, o sea que
no hay ninguna informacin almacenada en memoria de ningn equipo, solamente lo que tenga en su propia zona.

Cada servidor de una organizacin conoce solamente los nombres de su propia organizacin, y la direccin IP del (los en
realidad) servidores del dominio raz. El (los) servidor del domino raz conoce slo los DNS que tiene justo abajo, o sea
primer nivel (.com, .edu, .mil, .ar, .mx, etc.) Y los servidores de primer nivel slo conocen a los DNS de cada
organizacin. En la situacin anterior, un usuario en, supongamos, hp quiere acceder a server1.microsoft.com. Por lo
tanto en el equipo cliente un componente software llamado Resolver se encarga de preguntar al DNS que tenga
configurado para que le diga qu direccin IP tiene dicho host. Los Resolvers suelen ser de mal carcter (humor) as que
la pregunta es algo as como: dime que IP tiene server1.microsoft.com o dime que no sabes, no acepto referencias o
medias respuestas) A esto tipo de pregunta se la llama Recursive Query, exige respuesta concreta por s o por no.

Como el servidor DNS de hp no tiene localmente en su propia zona nada de microsoft.com sale a buscar al nico DNS
externo que conoce, el DNS del dominio raz. Las preguntas que hacen los servidores DNS a otros DNS generalmente
son de tipo Iterative Query (Dime lo ms que puedas, acepto referencias).Este le va a responder con una referencia,
que es lo ms que puede; algo as como preguntale al servidor de com, por lo tanto el servidor DNS de hp ahora le
pregunta al de com quien le dir que pregunte al de microsoft que finalmente dar la respuesta solicitada, al servidor

2 | Page
DNS de hp, que devolver el dato correspondiente al cliente que origin todo, y que finalmente podr hacer la conexin
correspondiente.

Cada pregunta que hizo el servidor DNS para resolver el pedido del cliente, recibi conjuntamente con la respuesta, un
parmetro denominado TTL (Time To Live) que corresponde a cunto tiempo puede tener la informacin en memoria y
considerarla vlida (cachear que le decimos)

Dentro del tiempo de los TTLs, si otro cliente repite la pregunta, el DNS devolver la informacin correcta sin necesidad
de ir a buscar afuera. O inclusive si le preguntaran por serve1.microsoft.com podra preguntar directamente al DNS de
microsoft.com. O inclusive si le preguntaran por server.ibm.com no comenzara por el raz, sino directamente por el DNS
de com.

DNSs Primarios, Secundarios y Master Parte 2

Una de los primeros y an vigente requerimientos en Internet es que hay que soportar tolerancia a fallas, y por lo tanto
para resolver los nombres de un dominio hay que poner por lo menos dos servidores DNS, no importa si el Dominio es
chico o va a recibir muy pocos pedidos de resolucin. Se imaginan el trabajo de tener que mantener no slo los
registros creados y modificados manualmente en un servidor sino en por lo menos dos?. Bueno, esto se solucion, hay
un servidor que mantiene una base (la Zona) con privilegios de Lectura y Escritura, y peridicamente le transfiere los
datos (transferencia de Zona) a uno o ms servidores DNS. Estos ltimos slo tienen permiso de Lectura sobre la Zona.
De esta forma cualquiera tiene los datos para responder, pero los cambios se realizan slo una vez. Cuando un servidor
DNS contiene una Zona sobre la que puede no slo Leer sino adems Escribir, se dice que es el Servidor Primario para
dicha Zona. Los otros servidores de DNS que reciben una copia de slo lectura, son Servidores Secundarios para dicha
Zona. Cuando un servidor obtiene su Zona por transferencia desde otro, a ese otro se lo llama el Master Server. Un
DNS que mantenga una Zona Secundaria, puede obtenerla tanto desde el que tiene la Zona Primaria, como adems
desde otro que contenga una Zona Secundaria. La operacin de copiar la zona desde un DNS a otro se llama
Transferencia de Zona.

Tipos de Registros

Un Registro en una Zona DNS, corresponde a una entrada, un rengln, en la Zona, pero no es tan fcil como muchos
piensan, slo un nombre (hostname) y su correspondiente IP. Hay varios tipos de registros, veamos los ms importantes:

SOA (Start of Authority Principio de Autoridad): El SOA indica cul es el servidor que mantiene la Zona
Primaria. El SOA slo indica el FQDN del servidor, no indica su direccin IP. Slo puede haber un SOA por Zona.
Por ser el SOA, es siempre el primer registro.
NS (Name Server Servidor de Nombres): Existen tantos registros NS como servidores DNS tengan copia de la
Zona, ya sea esta primaria o no. El NS slo indica el FQDN del servidor, no indica su direccin IP.
A (Host): Este es el tipo de registro que justamente todos esperamos, contiene un Hostname (nombre de equipo)
y su correspondiente direccin IP.
CNAME (Canonical Name o Alias): Es justamente eso, un alias. En la prctica nunca un servidor web se llama
www, o un servidor de correo se llama mail, etc. Un ejemplo de uso: se necesita cambiar el servidor que da el
servicio de web, por otro: simplemente cambio el CNAME para que apunte al nuevo, y para los que acceden es
totalmente tansparente. Otro caso, una pequea empresa donde se usa el mismo servidor para www, correo, etc.
Hay varios CNAMEs pero todos apuntan al mismo FQDN. Desde afuera nadie sabe que estn accediendo al
nico servidor disponible.
MX (Mail Exchanger): Cuando enviamos un correo electrnico, nuestro cliente de correo lo que hace es enviar el
mensaje a nuestro servidor de correo; nuestro servidor de correo debe averiguar quin es el servidor de correo
del dominio de destino. Esto es lo que permite este registro MX.
SRV (Service Locator): Este registro permite a los clientes encontrar servicios de red. Por ejemplo los clientes de
Active Directory usan este registro para encontrar a los Controladores de Dominio. Preguntan por quin provee el
servicio LDAP.
PTR (Pointer): El registro PTR, se utiliza slo en las Zonas Inversas que veremos en una futura nota. La Zona
Inversa o tambin conocida como Zona Reversa, lo que permite es resolver un nombre a partir de una direccin
IP. El A permite dado el nombre conocer la IP. El PTR permite dada la IP conocer el nombre.

Cmo Funciona DNS Integracin con Active Directory - Parte 3

3 | Page
Una de los grandes cambios que comenz Windows Server 2000 y que fue mejorado cada vez ms con las nuevas
versiones Windows 2003, Windows 2008 y Windows 2008-R2, es la posibilidad de integrar la zona en el Directorio Activo
Active Directory. Lo primero que debemos considerar es que el servicio DNS es fundamental para el funcionamiento de
Active Directory, es uno de los requerimientos para su funcionamiento por los siguientes usos:

Los clientes buscan a los Controladores de Dominio a travs de DNS. Esto es fundamental para que tanto los
equipos como los usuarios puedan autenticarse en el Dominio.
Los Controladores de Dominio se encuentran entre s a travs del servicio DNS. Esto permite la replicacin del
Directorio Activo entre ellos.
Los Controladores de Dominio encuentran a los que tienen la funcionalidad de Catlogo Global usando el
servicio DNS. Inclusive un Controlador de Dominio lo pregunta al DNS aunque l mismo sea Catlogo Global

Si hay un problema de configuracin del servicio DNS los problemas que se pueden presentar son mltiples y muchos
graves. Para nombrar slo algunos ejemplos:

Un cliente que demora en arrancar 15 minutos o ms

Un Controlador de Dominio que demora en arrancar casi una hora
Problemas de autenticacin de usuarios
Problemas de replicacin entre Controladores de Dominio
Y muchos ms. Hasta he visto una ocasin donde los usuarios no podan cerrar sesin, la finalizaba el timeout
interno de 10 minutos

Por lo tanto es fundamental tener una buena estructura de DNS, e integrarla en Active Directory tiene ventajas
importantes. Primero una aclaracin bsica, para poder integrar DNS en Active Directory el servicio debe estar
instalado en un Controlador de Dominio, y a partir de eso obtendremos las siguientes ventajas:

Tolerancia a Fallas. Ya que todos los Controladores de Dominio pueden escribir en la base de Active Directory,
cualquier Controlador de Dominio que tenga el servicio DNS funciona como si tuviera la zona primaria, esto es,
acepta cambios.
Seguridad en la Transferencia de Zonas: La replicacin de la informacin de las Zonas, se hace como parte de la
replicacin de Active Directory. Esto hace que la misma se haga en forma cifrada y protegida.
Seguridad en las Actualizaciones Dinmicas: En cada Zona integrada, e inclusive en cada registracin hay una
lista de control de acceso (ACL, similar a los permisos sobre archivos) que indica quin puede registrarse o
modificar registros. Por omisin slo los equipos miembros del Dominio. O inclusive puede usarse para
delegacin de la administracin de la Zona en otros usuarios o grupos.
Aprovechamiento de enlaces WAN: Como la informacin de la Zona se replica como parte de Active Directory, si
en el mismo hemos configurados Sitios (Sites), Subredes (Subnets) y Enlaces (Link), se replicar en forma
compactada y de acuerdo a la programacin que tengamos entre Sitios (Sites).
Configuracin de Zonas: Adems, si hemos dejado que la promocin (DCPROMO.EXE) haya instalado y
configurado el servicio DNS, o bien lo podramos tambin hacerlo manualmente, se crean dos Zonas con
diferente mbito de replicacin. Esto se logra mediante la utilizacin de Application Partitions.

Si por ejemplo supongamos que nuestro Dominio Active Directory se llama Dominio.sufijo, entonces se
crearn dos Zonas. Una se llamar Dominio.sufijo y se replicar a todos los Controladores de Dominio del
propio Dominio que tengan el servicio DNS instalado. La otra se llamar _msdcs.dominio.sufijo y se replicar a
todos los Controladores de Dominio del Bosque (Forest) que tengan el servicio DNS instalado. Es muy
importante que la zona _msdcs.dominio.sufijo sea accesible a todos los Controladores de Domino de nuestro
Bosque, ya que esta Zona del Dominio Raz es la nica que contiene los registros (SRV) de los Catlogo Global.

Active Directory Replication A fondo Parte 1

Comencemos por tratar de corregir un error muy comn como es hablar de: PDC (Primary Domain Controller), o
Controlador de Dominio Principal o inclusive de Controlador Principal del Dominio. Esta funcin no existe ms hace aos,
slo lleg hasta Windows Server NT 4.0. Slo queda un FSMO Rol llamado Emulador de PDC (PDC Emulator) que en

4 | Page
realidad no tiene casi relacin. En ambiente Windows Server NT 4.0 haba un nico Controlador de Dominio que poda
hacer modificaciones en el directorio, y era justamente el PDC. Pero a partir de ambiente de Dominio con Windows
Server 2000 no es ms as. Una de las importantes caractersticas de Active Directory es justamente que cualquier
Controlador de Dominio del Dominio puede hacer modificaciones en la base de Active Directory.

Y por qu se mantiene el trmino PDC, aunque se emulado? bueno, porque histricamente este equipo manejaba
adems otras funciones, y adems por razones de compatibilidad con sistemas operativos anteriores en las versiones
que soportaban compatibilidad con NT 4.0, y luego en las versiones que soportan compatiblidad con las que soportaban
NT 4.0. Por ejemplo si el Dominio todava admita Controladores de Dominio NT 4.0, o si haba viejos sistemas operativos
cliente (Win95/98) que no tenan instalado el DS Client y no saban que un usuario poda cambiar su contrasea en
cualquier Controlador de Dominio. Otra funcin de compatibilidad, si se usa el entorno de red de XP/W2003, que es
creado por el servicio Browser (Examinador), entonces este Emulador PDC cumple la funcionalidad de Domain Master
Browser. Pero de todas formas tiene algunas caractersticas especiales que sigue manejando como ser:

Es el principal servidor de tiempo contra el cual sincronizan el resto de los Controladores de Dominio del
Dominio, y los Emuladores PDC de los Sub-Dominios.
Es donde se pone foco cada vez que editamos una Group Policy.
Recibe replicacin preferencias de los cambios de contraseas

Las Particiones (Naming Context) de Active Directory. Si cualquier Controlador de Dominio acepta cambios, es
importante conocer cmo se propagarn dichos cambios al resto de los Controladores de Dominio, tanto del Bosque
como del propio Dominio, ya que diferentes tipos de datos tienen diferentes alcances de replicacin. La base de Active
Directory (NTDS.DIT) aunque es un nico archivo en realidad contiene varias particiones, teniendo cada una su propio
mbito de replicacin. Tendremos por los menos tres particiones y seguramente alguna ms como ya veremos. Cada una
de estas particiones se denomina Naming Context o NC.

Esquema (Schema): este NC contiene toda la definicin de atributos y clases de Active Directory, como as
tambin configuraciones internas importantes. Su mbito de replicacin es a todos los Controladores de Dominio
del Bosque
Configuration (Configuracin): esta tambin se replica a todos los Controladores de Dominio del Bosque, y
contiene informacin sobre los Dominos que integran el Bosque, la configuracin de Sitios, Enlaces, Redes, etc.
e inclusive hasta configuracin de algunas aplicaciones a nivel de Bosque como es el caso de Exchange
Dominio (Domain): este NC es la que contiene todos los objetos de nuestro Domino, usuarios, grupos, etc. (una
parte de las GPOs ya que adems hay otra parte en la carpeta SYSVOL). Esta se replica en todos los
Controladores de Domino del propio Dominio, y finalmente una rplica parcial a los Global Catalog (Catlogo
Global)

Y si el asistente de promocin instal y configur el servicio DNS, adems tendremos dos particiones ms.

ForestDNSZones: contiene los registros DNS que se replicarn a todos los Controladores de Dominio con
servicio DNS en el Bosque (Forest)
DomainDNSZones: contiene los registros DNS que se replicarn a todos los Controladores de Dominio con
servicio DNS en el Dominio (Domain)

Lo podemos ver fcilmente con ADSIEdit, como muestra la siguiente figura

5 | Page
Replicacin Dentro y Entre Sites (Sitios). Un tema que es importante que tengamos en cuenta antes de seguir
con el objetivo de la nota, est relacionado con la distincin de la forma de replicacin entre sitios y dentro de un sitio.
Qu es un Sitio?. Un Sitio (Site) es una o ms redes IP, con conectividad permanente, confiable y con suficiente ancho
de banda disponible para la replicacin. Habra que definir qu es suficiente ancho de banda disponible, pero esto es
muy variable de acuerdo a la estructura de nuestro Active Directory, as que por ahora consideraremos que un Sitio (Site)
es casi equivalente a un sitio fsico, donde generalmente no tenemos problemas de conectividad. Y por qu es esto?
porque la replicacin tiene distintos objetivos en cada caso. Si no tenemos problemas de conectividad, el objetivo
principal es que un cambio que se produce en un Controlador de Dominio se replique en muy poco tiempo en el resto de
los Controladores de Dominio. En cambio, si tenemos posibles restricciones de conectividad como puede suceder con
enlaces WAN, el objetivo es diferente, como por ejemplo, controlar y disminuir dicho trfico de replicacin.Dentro de un
Site (Sitio) se asume buena conectividad, y por lo tanto hay un proceso que se ejecuta (cada 15 minutos) en todos los
Controladores de Dominio denominado KCC = Knowledge Consistency Checker, que consultando los registros DNS
del resto de los Controladores de Dominio, determina los Connection objects (Objetos conexin) que son por los que
recibir datos del resto. Cada Controlador de Dominio crea los Connection Objects de forma de cumplir dos
condiciones:

Cada Controlador de Dominio, tendr por lo menos dos Connection Objects desde otros dos Controladores de
Dominio para recibir actualizaciones (Tolerancia a fallas)
Ningn Controlador de Dominio quedar a ms de tres saltos de otro. O sea que un cambio en la base, nunca
deber pasar por ms de tres Controladores de Dominio hasta llegar al ltimo

La estructura final, si la pudiramos ver sera algo as como un doble anillo de replicacin entre todos los Controladores
de Dominio, y eventualmente cruces interiores si alguno quedara a ms de tres saltos.

Si quiere graficarlo, dibujen un eptgono (polgono de 7 lados) y observen que un cambio producido en uno de
ellos pasar por no ms de tres saltos para llegar a otro. Y si agregan un octavo Controlador de Dominio, va a
haber que agregar Objetos Conexins para llegar a este ltimo.

Los valores por omisin de tiempos de replicacin dentro de un Site, son como sigue: cuando un Controlador de Dominio
acepta un cambio, pone un timer (contador) por 5 segundos durante los cuales sigue aceptando cambios. Luego de
esto le avisa a los Controladores de Dominio que replican desde l (Replication Partners) que hay cambios y que deben
actualizarse. Si hay varios, deja un intervalo de 30 segundos entre uno y otro. Luego, es responsabilidad de estos
Replication Partners ir a buscar los cambios. Y finalmente podemos decir que como el mximo perodo de aceptacin
de cambios, multiplicado por la cantidad de saltos, un cambio dentro de un Site (Sitio) puede demorar en propagarse al
resto (Converger la informacin) un mximo de 15 segundos. No es habitual ni generalmente recomendado hacer
cambios sobre estos parmetros. Esta replicacin se ejecuta siempre usando RPC (Remote Procedure Calls). Esta casi
inmediata replicacin de cambios, podra afectarnos si existieran enlaces WAN de por medio, as que como veremos a
continuacin, cuando tengamos enlaces de este tipo, lo debemos configurar para evitar un trfico que puede resultar
excesivo.

6 | Page
Entre Sites (Sitios) la replicacin se maneja de forma totalmente diferente, ya que el objetivo es controlar y disminuir el
trfico. Dentro de cada Site, hay un Controlador de Dominio que asume la funcin de ISTG = Inter-site Topology
Generator. Lo podemos ver en Active Directory Sites and Services.

ste es quien nombra al Bridgehead Server (Servidor Cabeza de Puente) que ser el que replicar con otro Site. Se
pueden configurar los Bridgehead Server preferidos por cada protocolo (IP o SMTP) pero debemos tener cuidado porque
en ese caso el sistema lo elegir solamente entre los preferidos. Si elegimos uno o varios y ninguno de esos estuviera
disponible, se cortara la replicacin entre Sites. La frecuencia de replicacin entre Sites por omisin es de 3 horas,
configurable entre 15 minutos, y una vez a la semana, y adems se pueden configurar: los das y horarios que est
habilitada la replicacin, asociarle un Costo, que no es funcin del ancho de banda, sino que es una preferencia
administrativa para definir los Objetos Conexin, cuando hay posibilidades redundantes.

Maestros de Operaciones (FSMO Roles, Flexible Single Master Operations) Parte 1

Hay algunas operaciones en Active Directory que deben ejecutarse con ciertas precauciones. Veamos un
ejemplo. Imaginemos un administrador haciendo cambios en el Esquema de Active Directory desde un
Controlador de Dominio en el sitio A. Mientras otro administrador en el sitio B, sin saber que ya est en
proceso la modificacin del Esquema, tambin hace cambios en el Esquema, slo que los cambios que se
hacen casi simultneamente en los diferentes sitios son incompatibles qu suceder cuando la replicacin
trate de hacer la convergencia de datos? estaramos en un problema grave.

Cmo podramos evitar situaciones como la anterior? bien, la solucin es sencilla: no importa desde qu
equipos modifiquen el Esquema, siempre se har, an si es necesario remotamente, en un determinado
Controlador de Dominio: El Maestro de Esquema. De esta forma, no se producirn incompatibilidades, si uno
es incompatible con otro simplemente uno no se aceptar. Vamos a describir los 5 FSMO Roles. Hay dos
roles que son a nivel de Bosque, o sea que hay uno de esos roles en todo el Bosque de Active Directory.
7 | Page
Y hay tres roles que son a nivel de Dominio, en cada Dominio Active Directory estn esos tres roles. Para
saber qu Controlador de Dominio tiene qu roles, aunque lo podemos hacer con la interfaz grfica, hay un
comando mucho ms simple. Desde un CMD.EXE ejecutamos: NETDOM QUERY FSMO

Maestros de Operacin a nivel de Bosque

Maestro de Esquema (Schema Master): Slo un Controlador de Dominio del Dominio raz lo va a tener.
Cualquier cambio que se haga en el Esquema, no importa desde dnde, la herramienta de edicin del
Esquema se enfocar en el que tenga este rol. Si queremos ver quin tiene este rol usando la interfaz grfica,
debemos primero registrar una DLL. Desde una lnea de comando (CMD.EXE) ejecutada como administrador
ejecutar: REGSVR32 SCHMMGMT.DLL

Luego crear una MMC.EXE cargando el componente Esquema de Active Directory

Luego con botn derecho sobre Esquema de Active Directory, elegimos Maestro de Operaciones

8 | Page
Maestro de Nomenclatura de Dominios (Domain Naming Master): La funcin que provee es garantizar la
unicidad de los nombres de los Dominios que se agreguen al Bosque. Esto es necesario porque podra darse
el caso, por ejemplo, que dos administradores desconectados entre s, traten de dar de alta
simultneamente el mismo subdominio. Usando la interfaz grfica si queremos saber quin tiene el rol,
debemos abrir la consola Dominios y Confianzas de Active Directory, y con botn derecho sobre la raz de la
carpeta elegimos Maestros de Operaciones

Maestros de Operacin a nivel de Dominio

Maestro RID (RID Master): Primero tenemos que explicar que es RID (Relative Identifier). Las cuentas de
usuario, las de grupo, y las de equipo, cuando son creadas en un dominio, se les asigna un SID (Security ID).
Lo podemos considerar en forma anloga a un documento personal. Es un identificador nico y que nunca es
reutilizado, aunque la cuenta original fuera eliminada. Este SID, tiene tres partes principales. La primera parte
(S-1-5-21-..) es un identificador asignado por ISO que especifica que es un identificador de seguridad
asignado a Microsoft, para uso en dominios NT, etc. La segunda parte es el identificador del Dominio, todas
las cuentas de usuario, grupo y equipo de un dominio comparten estos datos. La tercera y ltima (los
nmeros que siguen al ltimo -corresponden al RID, que es asignado en forma secuencial a partir del
nmero 1000 a cada cuenta que se crea en el Dominio. Vamos ahora a lo que nos interesa. Entiendo que
todos conocemos que una cuenta puede crearse en cualquier Controlador de Dominio ya que cualquiera de
ellos puede escribir en la base de Active Directory, pero sin embargo debemos asegurarnos que no se repitan
los SIDs asignados a cada cuenta.

La solucin pasa por tener un Controlador de Dominio que es el dueo de todos los RIDs, y que a pedido le
asigna a cada Controlador de Dominio del Dominio rangos de RIDs. Cuando en un Controlador de Dominio
este rango asignado comienza a agotarse (asigna de a 500, y cuando quedan slo 50 disponibles) los
Controladores de Dominio solicitarn al RID Master, otro rango de RIDs

9 | Page
Usando la interfaz grfica, para ver quin tiene esta funcin, hay que abrir Usuarios y Equipos de Active
Directory, botn derecho sobre el nombre del Dominio y elegir Maestro de Operaciones

Maestro de Infraestructura (Infrastructure Master): Supongamos que nuestro Active Directory consistiera
de varios Dominios. En un ambiente como este se puede dar el caso que un usuario de un Dominio-A, est
dentro de un grupo de otro Dominio-B. Por las capacidades propias de Active Directory y necesidad
podramos tener que mover la cuenta del usario (que est en Dominio-A) a otro Dominio-C. En este caso, en
los grupos del Dominio-B se deberan actualizar todas las referencias a la cuenta de usuario; antes era
usuario de Dominio-A, ahora debe ser usuario de Dominio-C. Esta es justamente la funcin del Maestro de
Infraestructura. Si queremos ver quin tiene el rol usando la interfaz grfica, es igual que en el caso anterior,
slo que esta vez seleccionamos la ficha Infraestructura

Maestro Controlador Principal de Dominio (PDC Emulator): en la poca de los Dominios con Windows NT,
no era como ahora que cualquier Controlador de Dominio aceptaba cambios en el directorio. Haba slo un
Controlador de Dominio por Dominio que aceptaba cambios, y se llamaba Controlador de Dominio Primario
(PDC = Primary Domain Controller). El resto de los Controladores de Dominio eran BDCs (Backup Domain
Controllers). Cualquera autenticaba usuarios, pero los cambios se hacan en uno en particular (el PDC) y
luego se replicaba a los otros (los BDCs). Esto ya sabemos que no es ms as, pero como siempre el tema
compatibilidad

El tema es que aunque no existe ms como PDC sigue cumpliendo algunas de las funciones que adems
cumpla el PDC, y otras nuevas.

El emulador de PDC cumple funciones de:

Es el Domain Master Browser (funcin de completar el Entorno de Red en los clientes hasta
W2003/XP)

Recibe replicacin preferencial de los cambios de contrasea de usuarios y equipos

Es el servidor de horario (Time Server) del Dominio

10 | P a g e
 Cuando desde cualquier equipo se crea o modifica una Directiva de Grupo (GPO), la consola de
edicin se trata de conectar siempre al que tiene este rol

Usando la interfaz grfica, e igualemente que en los dos casos anteriores podemos ver quin tiene este rol,
slo debemos cambiarnos a la ficha Controlador Principal de Dominio

Mover los Roles: De ser necesario, esto roles se pueden mover desde un Controlador de Dominio a otro. El
procedimiento es muy sencillo, y veremos las dos posibilidades: usando la interfaz grfica o por lnea de
comando. Lo que debemos tener en claro, es que nunca el traspaso es empujar, siempre es tirar. O sea,
no puedo desde A pasarle el rol a B, sino que desde B debo transferir el rol que tiene A. Entonces, usando la
interfaz grfica, debemos enfocar la consola que usemos (ver capturas de pantalla anteriores) y elegir el botn
Cambiar. Si aparece el mismo nombre de Controlador de Dominio en ambos renglones (como en las figuras
anteriores) es que estamos enfocados en el que tiene el rol y por lo tanto no podremos cambiarlo; debemos
re-enfocar la consola en el Controlador de Dominio destino.

SYSVOL Migration Series: Part 1 Introduction to the SYSVOL migration process

The File Replication Service (FRS) is used for replicating the contents of the SYSVOL share between Windows
domain controllers. However, Windows Server 2008 domain controllers, which are operating in the Windows
Server 2008 domain functional level, can use the DFS Replication service for replicating the contents of the
SYSVOL share. A new Windows Server 2008 feature makes it possible for administrators to migrate replication
of the SYSVOL share from FRS to the more reliable and efficient DFS Replication service. This series of blog
posts describe the procedure for migrating the replication of the SYSVOL share on Windows Server 2008
domain controllers from FRS replication to the DFS Replication service.

NOTE: The Windows Server 2008 SP2 release includes a couple of important bug-fixes in DFS
Replication that address a few customer reported issues in SYSVOL migration. If you plan to migrate
replication of the SYSVOL share to DFS Replication, it is highly recommended that you upgrade to Windows
Server 2008 SP2 first. The RTM release of Windows Server 2008 R2 includes these bug fixes.

Why migrate?

11 | P a g e
The DFS Replication service offers several advantages over the older File Replication Service (FRS). Some of
the advantages that accrue from using the DFS Replication service are:
Efficient, scalable and reliable file replication protocol which has been tested extensively to ensure data
consistency in multi-master replication scenarios.
Differential replication of changes to files using the Remote Differential Compression (RDC) algorithm,
which enhances efficiency in branch office scenarios.
Flexible scheduling and bandwidth throttling mechanisms.
Self-heals from USN journal wraps and database corruptions end user intervention and monitoring
requirement is minimal.
Provides a new UI management tool (MMC snap-in) for ease of administration.
Provides built in health monitoring tools for ease of monitoring deployments.
Improved support for Read Only Domain Controllers.

It is hence highly recommended that customers migrate replication of the SYSVOL share to the DFS
Replication service.
Migration in a nutshell
Windows Server 2008 ships a command line tool called dfsrmig.exe which can be used by an administrator to
initiate migration of SYSVOL replication from FRS to the DFS Replication service. This tool essentially sets
migration related directives in Active Directory. Thereafter, on each of the domain controllers in the domain,
when the DFS Replication service running polls Active Directory for configuration information, it notices this
migration directive and takes steps to migrate replication of SYSVOL to the DFS Replication service. The
following section explains the various migration states that are possible during this migration process in more
detail. Thus migration directives are set only once (globally) and all domain controllers in the domain notice this
directive and automatically take steps to attain the selected migration state, thus resulting in migration of
SYSVOL replication from FRS to the DFS Replication service.

Figure 1: SYSVOL Migration in a nutshell.

An analogy
Lets use a conventional analogy to understand the process of SYSVOL migration better. Joe is an old timer
who is due to retire from his job at the packaging plant this month end. Alex is supposed to take over Joes
responsibilities once Joe retires. Normally, the transition of responsibilities from Joe to Alex would work out in
four phases as shown in Figure 1.
Initially, before the transition begins, Joe is responsible for the day-to-day work where he mans the packaging
assembly line. In Stage 2 of the transition plan, Alex shadows Joe and learns the ropes. He helps package a
few units here and there, but Joe is still responsible for ensuring that daily production goals are met. In Stage
3, Alex begins to take over more of the day-to-day responsibilities from Joe right up to the point where Alex
only consults with Joe when he needs help. Finally, when Alex is ready to take on all responsibilities, Joe is
ready to retire.

12 | P a g e
 Figure 2: SYSVOL Migration an analogy.

If we extend this analogy to the process of migration of SYSVOL replication from FRS to the DFS Replication
service, we can define four states in the migration process. These are:
START state: In this state, FRS is responsible for replicating the contents of the SYSVOL share
between domain controllers. The main replication engine for the SYSVOL share on each of the domain
controllers in the domain is FRS.
PREPARED state: In the PREPARED state, the DFS Replication service makes a copy of the
contents of the SYSVOL share for itself. It then proceeds to initiate replication of its copy of the
SYSVOL folder with the DFS Replication service running on other peer domain controllers which have
migrated to the PREPARED state. At this stage of the migration process, the main replication engine
for the SYSVOL share on each of the domain controllers in the domain is still FRS.
REDIRECTED state: In the REDIRECTED state, the replication responsibility is shifted to the DFS
Replication service. The copy of the SYSVOL folder which was being replicated by the DFS Replication
service is now the one that is shared out by the Netlogon service and advertized by the domain
controller. FRS is, in the meantime, replicating the old SYSVOL folder with the FRS service running on
other peer domain controllers. At this stage of the migration process, the main replication engine for
each of the domain controllers in the domain is the DFS Replication service.
ELIMINATED state: In the ELIMINATED state, once the domain administrator has ensured that
replication is working fine, the FRS service is retired and the DFS Replication service assumes sole
responsibility for replicating the contents of the SYSVOL share between all domain controllers in that
domain.

Figure 3: Migrating from FRS replication of SYSVOL to the DFS Replication service.

Migration States: Stable States: There are four migration states which are defined as Stable Migration States
as alluded to above. During the process of migration, the administrator uses the migration tool (dfsrmig.exe) to
set a migration directive in Active Directory. This directive essentially sets a domain wide migration state (also
called global migration state) in Active Directory. This global migration state can be any one of the four stable
migration states shown in the table below.
Stable Migration States
0 START state
1 PREPARED state
2 REDIRECTED state
3 ELIMINATED state

13 | P a g e
Transition States: During migration, each domain controller takes appropriate actions locally so that it can
attain the migration stable state which has been selected for the domain by the administrator. This operation
causes the domain controller to cycle through intermediate states called Transition States. These transition
states are shown in the table below.

Transition States
4 PREPARING state
5 WAITING FOR INITIAL SYNC state
6 REDIRECTING state
7 ELIMINATING state
8 UNDO REDIRECTING state
9 UNDO PREPARING state

How migration Works: The domain administrator uses the dfsrmig.exe tool to trigger the process of SYSVOL
migration. This tool sets a migration directive in the Active Directory of the Primary Domain Controller, which is
what directs the DFS Replication service to perform SYSVOL migration the next time it polls Active Directory
for configuration information. The migration directive is an outcome of setting what is known as the global
migration state in Active Directory. This is a domain wide migration state which can assume any of the values
of the stable migration states detailed above.
When the DFS Replication service polls Active Directory for configuration information, it notices the global
migration state and takes suitable actions to bring its local migration state in sync with this global migration
state. This action is what causes the process of migration to take place. During the process of migration, when
the DFS Replication service is trying to bring the local migration state in sync with the global migration state,
the local migration state will cycle through the intermediate migration states before settling at the desired stable
migration state. This is illustrated in the state transition diagrams that follow.

Migration: The process of moving forward through the stable migration states in order to eliminate the FRS
service and replace it with the DFS Replication service for replicating the contents of the SYSVOL share is
known as migration. The state transition diagram corresponding to the migration process is as shown below:

Figure 4: State transition diagram for the migration process.

Rollback: Before domain controllers migrate to the ELIMINATED state, it is possible to roll back migration to
the PREPARED or START states. This facility is provided so that administrators can commit to the SYSVOL
migration procedure only once they are fully confident that the DFS Replication service is replicating SYSVOL
properly in their environment. It is possible to use the rollback functionality to move to the previous stable state.
When the dfsrmig.exe tool is used and the global migration state is set to the previous stable migration state,
rollback is caused. For instance, if the current global migration state is REDIRECTED and the administrator
wants to rollback migration to the PREPARED state, he can use the dfsrmig.exe tool to set the global
migration state to PREPARED. The DFS Replication service on all domain controllers will follow this directive
and rollback migration state to the PREPARED state. The state transition diagram corresponding to the
rollback process is as shown below:

14 | P a g e
 Figure 5: State transition diagram for the rollback process.

NOTE: It is not possible to rollback once migration has reached the ELIMINATED state. Therefore, it is
recommended to migrate to this state only when you are sure that SYSVOL replication is working fine using
the DFS Replication service.

Features of the SYSVOL migration process. The SYSVOL migration procedure is designed to provide the
following features:
A robust mechanism to migrate replication of the SYSVOL share from FRS to the DFS Replication
service, with reduced risk, minimal need for down-time and near zero end-user impact. This mechanism
is resilient to domain controller crashes, reboots, promotions and demotions.
Sufficiently granular control over the migration procedure for administrators. This empowers
administrators to control the process one step at a time so as to verify correct operation before changes
are committed.
Allow rollback of the migration procedure at any point in time until the last step (ELIMINATED state)
where the FRS service is eliminated. This feature enables administrators to roll back changes in case
something was to go wrong during the migration process.
Works despite Active Directory replication latencies and is hence suited to branch office domain
controller migration scenarios. In particular, the process is designed to work in instances where some
domain controllers may not know that migration has been initiated owing to Active Directory replication
latencies, since it does not assume that all domain controllers will be simultaneously reachable during
migration.
Provides mechanisms by which a domain administrator can monitor the progress of migration.

15 | P a g e