Está en la página 1de 89

Directivas de grupo en Windows server 2008

A continuación veremos como implementar algunas directivas usadas en


Windows server 2008
1. El primero hacer será crear grupos y usuarios:
Grupo: killers
• Manuel
• Carlos

Grupo: timers
• Bruno
• Benji

Para empezar crearemos los grupos y usuarios esto lo puedes hacer entrando
a:
Inicio/herramientas administrativas/administración de equipo/usuarios y grupos
locales.

Usuarios: clic derecho usuario nuevo, nombre de usuario, contraseña, confirmar


contraseña (cualquier contraseña para que después el usuario ponga la propia)
en categoría escogemos el usuario debe cambiar contraseña en el siguiente
inicio de sesión por ultimo crear.
Esto lo hacemos para crear los cuatro usuarios.

Grupos: clic derecho grupo nuevo, nombre de el grupo en miembros le das


agregar pones el nombre de el usuario anteriormente creado y le das
comprobar, aceptar y por ultimo crear asi agregas los usuarios a cada grupo.
Esto mismo lo haces para crear ambos grupos.

2. Ahora implementaremos las siguientes políticas o directivas locales.

Directivas de configuración de equipo

Todas las políticas a establecer se hacen en inicio/ejecutar/gpedit.msc de allí se


desprende todo.

La vigencia máxima de la contraseña para todos los usuarios de la


 Configuración de equipo/configuración de Windows/configuración de
seguridad/directivas de cuenta/directivas de contraseña/vigencia máxima de la
contraseña. (15 días)

Las contraseñas deben cumplir con los requisitos de complejidad por defecto de
Windows Server ¿Cuáles son estos requerimientos?
 Configuración de equipo/configuración de Windows/ configuración de
seguridad/directivas de cuenta/directivas de contraseña/la contraseña debe
cumplir los requisitos de complejidad. (Habilitar)

La contraseña debe contener:


Mayúsculas (de la A la Z)
Minúsculas (de la a la z)
Números base 10 (0 al 9)
Caracteres no alfanuméricos (#, %, &)

Los usuarios que requieran cambiar su contraseña no podrán usar un password


que se haya usado antes por lo menos desde los 2 últimos cambios.
 Configuración de equipo/configuración de Windows/configuración de
seguridad/directivas de cuenta/directivas de contraseña/exigir historial de
contraseñas. (Se coloca 2)

Apagar la maquina según el grupo que la utilice


 Configuración de equipo/configuración de Windows/ configuración de
seguridad/ directivas locales/asignación de derechos de usuario/apagar el
sistema doble clic para agregar usuario o grupos agregas a Manuel y Carlos y
les das comprobar nombres aceptar, los usuarios de grupo killers aplicar y
aceptar).

Cambiar la hora de la máquina local


 Configuración de equipo/ configuración de Windows/ configuración de
seguridad /directivas de cuenta/ directivas locales/asignación derechos de
usuario/cambiar la hora del sistema doble clic para abrir agregar usuarios o grupo
agregas a Bruno y Benji y les das comprobar nombres aceptar los usuarios del
grupo timers aplicar y aceptar.

Todos los usuarios tendrán las siguientes restricciones al usar el navegador


Internet Explorer: No podrán eliminar el historial de navegación, No se permitirá
el cambio de proxy ya que todos los usuarios usarán el mismo proxy
(172.20.49.51:80), Configuración del historial deshabilitada, no permitir el cambio
de las directivas de seguridad del navegador.
 Configuración de equipo /plantillas administrativas/componentes de
Windows/Internet Explorer /deshabilitar la configuración del historial doble clic
para abrir escogen deshabilitada, aplicar aceptar

 Para el proxy hay que hacer las siguientes cosas:


 Configuración de equipo /plantillas administrativas/componentes de
Windows /Internet Explorer /configuración de proxy por equipo y no por usuario
doble clic para abrir escogen habilitada, aplicar y aceptar.
 Configuración de usuario/configuración de Windows/ configuración de
seguridad/mantenimiento de Internet Explorer/conexión/ configuración de los
servidores proxy doble clic para abrir escogemos habilitar configuración de proxy
ponemos el proxy y el puerto también escogemos utilizar el mismo servidor proxy
para todas la direcciones aplicar y aceptar.
 Configuración de equipo/plantillas administrativas/componentes de
Windows /Internet Explorer/panel de control de internet/deshabilitar la pagina
general doble clic para abrir escoger deshabilitada aplicar y aceptar.
 Configuración de equipo/plantillas administrativas/componentes de
Windows /Internet Explorer/panel de control de internet/deshabilitar la pagina
seguridad doble clic para abrir escoger deshabilitada aplicar y aceptar.
Desactivar la ventana emergente de reproducción automática
 Configuración de equipo/plantillas administrativas/componentes de
Windows /directivas de reproducción automática doble clic para abrir escoger
deshabilitada aplicar y aceptar.

No permitir el apagado remoto de la máquina


 Configuración de equipo/plantillas administrativas/componentes de
Windows /opciones de apagado/ desactivar interfaz de apagado remoto
heredada doble clic para abrir escoger deshabilitada aplicar y aceptar.

Aplicar cuotas de 50MB para todos los usuarios locales y remotos (Esta es un
cuota muy baja y es usada solo para fines académicos)
 Configuración de equipo/plantillas administrativas/sistema/cuota de
disco/ limite de cuota y nivel de aviso predeterminados doble clic para abrir
propiedades de limite de cuota y nivel de aviso predeterminados escoger
habilitada en valor poner 50 unidades MB aplicar y aceptar.

Directivas de configuración de usuario:

La página principal que se cargará para cada usuario cuando abra su navegador
será:
http://www.sudominio.com (Página institucional de su empresa)
 Configuración de usuario/configuración de Windows/mantenimiento de
Internet Explorer/direcciones URL/ direcciones URL importantes doble clic para
abrir escogen personalizar URL de la pagina principal allí pone la URL de la
pagina escogida por ejemplo http://www.kthe.com aplicar y aceptar.

Restricción de sitios. El administrador será el único con la contraseña de


supervisor para el Asesor de Contenidos.
 Configuración de usuario/configuración de Windows/ mantenimiento de
Internet Explorer/seguridad/zonas de seguridad y clasificación de contenido
doble clic para abrir allí busca en clasificación de contenido escogen importar la
configuración actual de restricciones de contenido y modificar configuración en
este buscan sitios aprobados colocan la URL que vana restringir le dan nunca
luego van en esa misma ventana a general cambiar contraseña de supervisor
aquí ponen su contraseña propia y aplicar y aceptar cuando cierre esa ventana
aceptar a la de restricciones y listo.

Ocultar la unidad C:\ (NOTA: Esto no restringirá el acceso a dicha unidad)


 Configuración de usuario/plantillas administrativas/Componentes de
Windows / Explorador de Windows / Impedir acceso a las unidades desde “Mi
PC” doble clic para abrirlo escogen deshabilitada aplicar y aceptar.

Ocultar el menú opciones de carpeta del menú de herramientas.


 Configuración de usuario/Plantillas Administrativas /Componentes de
Windows /Explorador de Windows /Quitar el menú opciones de carpeta del menú
Herramientas doble clic para abrir escoger deshabilitada aplicar y aceptar
Limitar tamaño de la papelera de reciclaje.
 Configuración de usuario/Plantillas Administrativas/Componentes de
Windows / Explorador de Windows /Tamaño de la papelera de reciclaje doble
clic para abrir escoger habilitada poner en numero por ejemplo 100MB aplicar y
aceptar

No permitir que se ejecute Messenger.


 Configuración de usuario/Plantillas Administrativas/ Sistema/ No ejecutar
aplicaciones de Windows especificadas doble clic para abrir escoger
habilitada dar clic en mostrar agregar msnmsgr.exes agregar aplicar y aceptar.

Ocultar elementos del escritorio para los usuarios.


 Configuración de usuario/Plantillas Administrativas/ Escritorio/Ocultar y
deshabilitar todos los elementos del escritorio doble clic para abrir escoger
habilitada aplicar y aceptar

Bloquear Barra de tareas.


 Configuración de usuario/ Plantillas Administrativas / Menú Inicio y barra
de tareas/ Bloquear barra de tareas doble clic para abrir escoger habilitada
aplicar y aceptar.

Acceso de lecto-escritura a medios extraíbles- denegado


 Configuración de usuario/ Plantillas Administrativas/Sistema/ Acceso de
almacenamiento extraíble/ Discos extraíbles: Denegar el acceso de escritura
/Discos extraíbles: Denegar el acceso de lectura a cada una doble clic para abrir
escoger habilitada aplicar y aceptar.

Direcctivas generales
En este apartado, y siguiendo con el planteamiento expuesto en el anteriormente, asignaremos
directivas de grupo de primer nivel en el dominio "MiCentro.edu", para que dichas directivas de
grupo sean aplicadas de forma común a todos los usuarios y equipos del dominio "MiCentro.edu".

Si hubiera alguna contradicción entre alguna directiva de grupo de usuario y de equipo


definidas ambas en el dominio "MiCentro.edu", prevalecerían las de equipo frente a las de
usuario.

Para definir las directivas de grupo globales deseadas para nuestro centro, deberemos
lanzar Administración de directivas de grupo desde las Herramientas administrativas y
situarnos sobre la directiva Default Domain Policy del dominio "MiCentro.edu", pulsar sobre ella
con el botón derecho del ratón para elegir en el desplegable mostrado a continuación la
opción Editar, tal y como vemos en la imagen inferior.
Como resultado de la acción anterior pasará a mostrarse la siguiente ventana, en la cual
podremos observar que para la directiva de dominio por defecto (Default Domain Policy)
podemos interactuar con directivas que pueden ser aplicadas a los usuarios del dominio
(Configuración de usuario) y otras que pueden serlo a los equipos del dominio (Configuración
del equipo). Las directivas que pueden ser definidas para cada tipo de objeto en general no son
similares, si bien algunas de ellas sí son comunes; en caso de que definamos 2 políticas
contradictorias en dos entradas similares, una en equipos y otra en usuarios, prevalecerá la
primera de ellas.
Tanto para los equipos como para los usuarios, la primera directiva de grupo susceptible de ser
configurada está relacionada con la Configuración de software; por la importancia que tiene
esta política en particular le dedicaremos íntegramente un apartado con posterioridad. De hecho
en su momento utilizaremos la entradaConfiguración del equipo para configurar todo el
software que se instalará en los equipos clientes de nuestro centro.

En relación con la configuración de las directivas o políticas de grupo de los equipos,


anteriormente ya indicamos como configurar para la directiva del dominio ciertos cambios
relativos a las configuraciones de las contraseñas de los usuarios, a fin de que el sistema pudiera
admitir validaciones de usuarios sin contraseña. En este instante procederemos a configurar en
este apartado otras directivas que deseamos que se apliquen de modo global en los equipos de
nuestro centro, con independencia del sistema operativo del equipo cliente que tengan instalado.

Por ejemplo, si deseamos que en nuestros equipos clientes no pueda utilizarse Windows
Messenger, actuaremos sobre la directiva No permitir que se ejecute Windows Messenger,
ubicada en Configuración de equipo → Directivas → Plantillas
administrativas → Componentes de Windows → Windows Messenger, situándonos sobre
ella y haciendo doble clic sobre la misma.
Como resultado de la acción anterior será mostrada la siguiente ventana, en la cual activaremos
el radio botónHabilitada, tras lo cual pulsaremos en ella sobre el botón Aceptar.
Una vez configurada la directiva de grupo anterior, podremos comprobar que será aplicada
convenientemente, pues su Estado pasa a tomar el valor Habilitada, tal y como vemos en la
imagen inferior.
Podemos comprobar que la cantidad de directivas susceptibles de ser aplicadas a los
equipos del dominio y a los usuarios del dominio es ingente, y es imposible abordarlas todas en
el ámbito de este apartado, así pues el administrador del sistema deberá analizar cuales de ellas
son de interés en su entorno laboral, a fin de habilitarlas para su implantación. En el momento
de elaborar esta documentación podíamos obtener una información exhaustiva sobre las
directivas de grupo que se pueden configurar en un equipo Windows Server 2008 en la dirección
URL http://technet.microsoft.com/en-us/windowsserver/bb310732

Al margen de la configuración de directiva de grupo de equipo realizada anteriormente, no


realizaremos más configuraciones globales en relación los equipos del dominio.

Centrémonos pues ahora en las directivas de la entrada Configuración de usuario, que serán
las que aplicaremos de forma común a los usuarios del dominio. Al igual que ocurría con las
directivas de equipo, existen multitud de directivas configurables, y será el administrador quien
deberá determinar a su criterio cuales deben de aplicarse; nosotros incidiremos en aquellas que
hemos considerado más interesantes.

Por ejemplo en la entrada Configuración de usuario → Directivas → Configuración de


Windows →Mantenimiento de Internet Explorer → Interfaz de usuario del explorador,
haremos doble clic sobre la directiva Título del explorador.
En la ventana mostrada a continuación podremos personalizar el título del explorador, activando
la casillaPersonalizar barras de título y posteriormente tecleando en la caja de texto
correspondiente la cadenaMiCentro, de modo que cuando un usuario autenticado en el dominio
cargue el navegador del equipo cliente correspondiente, en la barra del título del
navegador Internet Explorer se muestre el texto Microsoft Internet Explorer proporcionado
por MiCentro; completaremos el proceso pulsando en la ventana de la imagen inferior sobre el
botón Aceptar.
Otra directiva de grupo de usuario que podemos configurar es la relativa a la configuración del
proxy en el navegador del cliente (si es que disponemos de un proxy en nuestra red), proxy por
el cual deseamos que salgan a Internet todos los equipos del centro.

En nuestro caso no configuraremos la directiva de grupo indicada en el párrafo anterior, al


no tener instalado un proxy en nuestra red, si bien se cita dicha directiva porque en un momento
determinado su aplicación puede resultar muy interesante.

Para habilitar dicha configuración nos situaríamos en la directiva Configuración de los


servidores proxy, ubicada en Configuración de usuario → Directivas → Configuración de
Windows → Mantenimiento de Internet Explorer → Conexión, haciendo doble clic sobre la
misma para proceder a su configuración.
En la ventana mostrada como resultado de la acción anterior, activaríamos la casilla Habilitar
configuración de proxy e indicaríamos la dirección del proxy y el puerto de salida, así como las
posibles excepciones para las direcciones locales, si procediera; como indicamos anteriormente
en nuestro caso no vamos a configurar esta directiva, pues en este instante no dispondremos de
un servidor proxy instalado en nuestra red, pero creemos interesante comentarla porque con
posterioridad podríamos disponer de dicho servidor proxy; así pues en la ventana de la imagen
inferior pulsaremos finalmente sobre el botón Cancelar.
En la misma entrada, es decir en Configuración de usuario → Directivas → Configuración
de Windows →Mantenimiento de Internet Explorer → Conexión, podemos configurar la
directiva Cadena del agente de usuario, cadena que el navegador enviará a los servidores web
visitados a fin de identificarse frente a ellos; en nuestro caso personalizaremos la cadena de
información que el usuario enviará a los servidores web visitados a través del navegador de la
estación de trabajo del dominio, activando la casilla Personalizar cadena que se anexará a la
cadena del agente de usuario, y tras ello tecleando en la caja de texto correspondiente el
valorMiCentro, para pulsar finalmente en dicha ventana sobre el botón Aceptar.
También podemos definir los favoritos y vínculos que deseamos se añadan a los navegadores
de nuestros usuarios del dominio; a través de la directiva de grupo Favoritos y Vínculos ubicada
en la entradaConfiguración de usuario → Directivas → Configuración de
Windows → Mantenimiento de Internet Explorer → Direcciones URL; para ello haremos
doble clic sobre la directiva indicada, y en la nueva ventana mostrada agregaremos aquellas
URLs que deseamos que aparezcan en Favoritos a los usuarios de nuestro centro; para agregar
una URL a Favoritos, en la ventana mostrada pulsaremos sobre el botón Agregar URL y en la
nueva ventana indicaremos en la caja de texto "Nombre" el nombre descriptivo de la URL
(Google en este caso) y en la caja de texto "Dirección URL" la correspondiente al favorito que
deseamos agregar (http://www.google.es en este caso), para completar el proceso pulsando
sobre el botón Aceptar en dicha ventana, de modo que finalmente la ventana correspondiente a
la directiva de grupo de Favoritos y vínculospresente el aspecto mostrado en la imagen inferior,
momento en el que pulsaremos en ella sobre el botónAceptar.
En la misma entrada anterior, Configuración de usuario → Directivas → Configuración de
Windows →Mantenimiento de Internet Explorer → Direcciones URL, pero en la
directiva Direcciones URL importantes, podemos especificar la página de inicio que deseamos
se muestre por defecto en los navegadores de los usuarios del dominio; para ello haremos doble
clic en dicha directiva, mostrándose la siguiente ventana, en la cual activaremos la
casilla Personalizar URL de la página principal, tras lo cual en la caja de texto adjunta
indicaremos la dirección http://www.micentro.edu, tal y como vemos en la imagen inferior;
finalmente pulsaremos sobre el botón Aceptar para validar los datos introducidos en dicha
ventana.
La dirección URL indicada como página de inicio de los
navegadores http://www.micentro.edu, ahora mismo no estará disponible, de modo que
cuando desde una estación de trabajo lancemos el navegador no se encontrará dicha página
web, provocándose un error; ¿por qué la configuramos entonces como página de inicio de los
navegadores de los usuarios del dominio de nuestro centro?, el motivo de ello es que más
adelante, cuando abordemos el capítulo correspondiente al servidor IIS, definiremos un sitio Web
denominado "www" en el dominio "micentro.edu", e incluiremos en nuestro servidor DNS una
entrada host correspondiente a www.micentro.edu apuntando a la dirección IP de nuestro
servidor web, de modo que a partir de ese momento, cuando un usuario del dominio cargue el
navegador en la estación de trabajo del dominio donde haya iniciado sesión, se abrirá la página
web principal de la Intranet de nuestro centro http://www.micentro.edu.

Además de las directivas propias del navegador, para los usuarios del dominio también existen
otras directivas de interés; una de ellas, sobre todo si disponemos de un servidor proxy en la red,
es Deshabilitar el cambio de configuración de proxy, existente en la entrada Configuración
de usuario → Directivas → Plantillas Administrativas → Componentes de
Windows → Internet Explorer; si en esta directiva seleccionamos la opción Habilitada,
impediremos que los usuarios puedan modificar en sesión de trabajo la configuración del proxy,
pues las opciones del proxy aparecerán atenuadas e inaccesibles; en nuestro caso pulsaremos
sobre el botón Cancelar y no la habilitaremos en este instante, si bien aunque no dispusiéramos
de un proxy actualmente en nuestra red, podríamos configurarla igualmente para evitar que los
alumnos puedan configurar su salida a Internet a través de un proxy situado en Internet, evitando
de ese modo los potenciales filtros que pudiéramos haber configurado para evitar la navegación
por páginas web indebidas.
Llegados a este punto, hemos definido las directivas de grupo de Default Domain Policy, es
decir aquellas directivas del dominio "MiCentro.edu" que van a aplicarse a todos los usuarios y
equipos del dominio (salvo a los objetos contenidos bajo la unidad organizativa Domain
Controllers, por expreso deseo nuestro cuando bloqueamos la herencia de directivas de grupo
sobre dicha unidad organizativa).

Procederemos pues a cerrar la ventana correspondiente al editor de la directiva Default Domain


Policy, y tras ello haremos clic sobre dicha directiva, pasando a ser mostrada la ventana de la
imagen inferior.
Nada más hacer clic sobre la directiva de grupo Default Domain Policy, se nos presentará
la siguiente ventana informativa, en la que activaremos la casilla No volver a mostrar este
mensaje, tras lo cual pulsaremos en ella sobre el botón Aceptar.

Hasta este instante hemos configurado directivas de grupo globales para los usuarios y equipos
del dominio, y lo que vamos a hacer a continuación es definir las directivas de grupo de aplicación
particular para cada tipo de equipo y usuario. Anteriormente creamos las unidades
organizativas Equipos WXP, Equipos W7, Profesores, y Alumnos para dicho fin, las 2
primeras para definir directivas de grupo de equipo y las dos últimas para configurar directivas
de grupo de usuario.

En relación con las directivas particulares para cada equipo en función de su sistema operativo,
queremos indicar en este apartado que la única directiva particular que será configurada para los
equipos del dominio es la relativa a la instalación de software, pues el resto de configuraciones
serán de carácter general y ya se han efectuado en la directiva Default Domain Policy tratada
anteriormente; como comentamos al inicio de este apartado, dedicaremos por su importancia,
un apartado completo a las directivas de equipo de configuración de software, por lo cual
obviaremos detallarlas en este instante.

Así pues, centrémonos en las directivas de grupo de usuario particulares, para las cuales
creamos anteriormente las unidades organizativas Profesores y Alumnos.

En primer lugar deberemos situarnos sobre la unidad organizativa sobre la que queremos
interactuarProfesores en este caso, y sobre ella pulsar con el botón derecho del ratón para
seleccionar la opción Crear un GPO en este dominio y vincularlo aquí en el desplegable
correspondiente, para proceder a crear directiva de grupo asociada a esta unidad organizativa.

El hecho de haber creado anteriormente una unidad organizativa, no implica que se haya
creado un objeto directiva de grupo asociado a dicha unidad organizativa, es más, seremos
nosotros mediante el proceso anterior quienes crearemos dicho objeto directiva de grupo
asociándose automáticamente a la unidad organizativa donde haya sido creado.

En la nueva ventana mostrada como resultado de la acción anterior, teclearemos en la caja de


texto "Nombre", el nombre con el que deseamos reconocer a la nueva directiva de
grupo, Directiva de Grupo Profesores en este caso, tal y como vemos en la imagen inferior,
tras lo cual en ella pulsaremos sobre el botón Aceptar.
Una vez completada la acción anterior, podremos comprobar la existencia de una nueva GPO
de nombreDirectiva de grupo Profesores en la unidad organizativa Profesores.

Una vez que ha sido creada la Directiva de Grupo Profesores, procederemos a su edición
pulsando sobre ella con el botón derecho del ratón para elegir la opción Editar en el desplegable
correspondiente, tal y como vemos en la imagen inferior.
Como resultado de la acción anterior se muestra el editor de administración de directiva de grupo
con las configuraciones propias de la directiva Directiva de grupo Profesores, que actualmente
no tendrá configuración alguna.
Aunque la ventana de edición de las directivas de grupo es la misma para cualquier
directiva, los valores que muestra en cada instante son los propios de cada directiva de grupo
que estemos editando, de ahí que en este caso el editor de directivas de grupo no tenga definida
configuración alguna, al mostrar las configuraciones actuales de la directiva Directiva de grupo
Profesores recién creada.

Para los profesores de nuestro dominio configuraremos la directiva de grupo Limitar el tamaño
del perfilubicada en Configuración de usuario → Directivas → Plantillas
Administrativas → Sistema → Perfiles de usuario, haciendo doble clic sobre la directiva y
activando la casilla Habilitada, para posteriormente indicar el valor 30.000 Kb. (30 Mb.) como
tamaño máximo de almacenamiento para los profesores; además activaremos la casilla Notificar
al usuario cuando se exceda el espacio de almacenamiento de perfiles, con el fin de que se
le informe cuando exceda dicho límite, tras lo cual confirmaremos la configuración realizada
pulsando sobre el botón Aceptar en dicha ventana.
Esta directiva de grupo no la hacemos de ámbito global, de modo que afectara a todos los
usuarios del dominio, profesores y alumnos, debido a que estos últimos tienen un perfil obligatorio
y por tanto el tamaño de su perfil no sufrirá variación alguna, por lo que no tendría sentido alguno
aplicar dicha directiva a los alumnos.

En este caso, y por no alargar aun más este extenso apartado, esta será la única configuración
de directiva que llevaremos a cabo para los profesores del centro, con lo cual podemos cerrar el
editor de administración de la directivas de grupo Directiva de Grupo Profesores, y volver a la
ventana de Administración de directivas de grupo.

Una vez configuradas las directivas de grupo que serán aplicadas exclusivamente a los
profesores, el siguiente paso consiste en personalizar las políticas que serán aplicadas a los
alumnos del centro, para lo cual deberemos crear un objeto directiva de grupo de
nombre Directiva de grupo Alumnos en la unidad organizativa Alumnos siguiendo los mismos
pasos que llevamos a cabo para crear para los profesores la correspondiente directiva. Una vez
creada dicha directiva de grupo Directiva de Grupo Alumnos, la editamos de igual modo que
hicimos para la de los profesores, esto es, situándonos sobre dicha directiva y a continuación
pulsando sobre ella con el botón derecho del ratón para elegir la opción Editar en el desplegable
correspondiente.
Para los alumnos, al igual que para los profesores, configuraremos como muestra una única
directiva de grupo, concretamente y por seguridad, limitaremos a nuestros la configuración de la
barra de tareas mediante la directiva Bloquear la barra de tareas situada en Configuración de
usuario → Directivas → Plantillas Administrativas → Menú inicio y barra de tareas,
haciendo doble clic sobre la misma y activando la opciónHabilitada en la nueva ventana
mostrada, para finalmente pulsar sobre el botón Aceptar en la misma.
Tras completar la acción anterior cerraremos secuencialmente las ventanas correspondientes
al Editor de Administración de directivas de grupo y a la Administración de directiva de
grupo, para dar por concluido este apartado.

A partir de este instante, cuando un usuario del dominio se conecte desde un equipo cliente,
todas las directivas globales definidas anteriormente (de equipo y de usuario) y todas las
particulares definidas en función del tipo de usuario que es, se le aplicarán de modo efectivo. Por
ejemplo podemos validarnos en un equipo cliente con las credenciales de un alumno, y
comprobar, por ejemplo que no podemos ejecutar Windows Messenger (directiva global de
equipo) y que tenemos bloqueada la barra de tareas (directiva particular de usuario que sólo se
aplica a los alumnos); si por contra nos validamos en dicho equipo con las credenciales de un
profesor, la barra de tareas no estaría desbloqueada, pero por contra no podríamos ejecutar la
aplicaciónWindows Messenger.

Obviamente hemos pasado muy por encima de muchas directivas interesantes, debido a la gran
cantidad de ellas existentes; el administrador del dominio deberá analizar una por una cuales
son de su interés y aplicarlas en su caso; para entender perfectamente el funcionamiento de
cualquier directiva de grupo, podremos hacer doble clic sobre cualquiera de ellas, y situarnos a
continuación sobre la pestaña Explicación en la ventana mostrada, obteniendo un detallado
resumen de su funcionalidad, tal y como vemos en la imagen inferior.
Una cuestión importante es que las directivas asignadas a los usuarios pueden ser modificadas
por éste en sesión (por ejemplo cambiar la página de inicio del navegador), pero los cambios
realizados no serán almacenados, de forma que la próxima vez que el usuario inicie sesión en
cualquier máquina del dominio, se le volverán a aplicar las directivas definidas por el
administrador del dominio para dicho usuario, obviando aquellas configuraciones que el usuario
hubiera podido realizar (en el ejemplo indicado cuando lance el navegador, se le volverá a
mostrar como página de inicio la definida por el administrador en la directiva correspondiente).

redireccion de carpetas windows server 2003


Introducción al
redireccionamiento de
carpetas
Personas que lo han encontrado útil: 5 de 7 - Valorar este tema

Se aplica a: Windows Server 2008 R2

Redireccionamiento de carpetas
La configuración y los archivos de usuario suelen almacenarse en el perfil de usuario local, en la
carpeta Usuarios. Sólo se puede tener acceso a los archivos de los perfiles de usuario locales
desde el equipo actual, lo que dificulta a los usuarios que usan más de un equipo el trabajo con
sus datos y la sincronización de configuraciones entre varios equipos. Existen dos tecnologías
para solucionar este problema: los perfiles móviles y el redireccionamiento de carpetas. Ambas
tecnologías presentan ventajas y pueden usarse individual o conjuntamente para crear una
experiencia de usuario coherente en diferentes equipos. Asimismo, proporcionan opciones
adicionales para los administradores de los datos de usuario.
La redirección de carpetas permite que los administradores redirijan la ruta de acceso de una
carpeta a una nueva ubicación. La ubicación puede ser una carpeta del equipo local o un
directorio de un recurso compartido de archivos de red. Los usuarios pueden trabajar con
documentos en un servidor como si éstos se encontraran en una unidad local. Los documentos
de la carpeta están disponibles para el usuario desde cualquier equipo de la red. La redirección
de carpetas se encuentra en Configuración de Windows en el árbol de consola cuando se
modifica la directiva de grupo basada en el dominio mediante la Consola de administración de
directivas de grupo (GPMC). La ruta de acceso es [Nombre del objeto de directiva de
grupo]\Configuración de usuario\Directivas\Configuración de Windows\Redirección de
carpetas.

Cambios recientes en la redirección de carpetas


La redirección de carpetas incluye las siguientes características:

 La capacidad de redirigir más carpetas en las carpetas del perfil de usuario que en
versiones anteriores del sistema operativo Windows. Incluye las
carpetas Contactos,Descargas, Favoritos, Vínculos, Música, Juegos
guardados, Búsquedas y Vídeos.

 La capacidad de aplicar la configuración de las carpetas redirigidas a equipos con


Windows® 2000, Windows 2000 Server®, Windows XP o Windows Server 2003. Tiene la
opción de aplicar la configuración que se establezca en Windows Server® 2008 R2,
Windows® 7, Windows Server 2008 o Windows Vista® sólo a los equipos que ejecuten
dichos sistemas operativos o aplicarla también a los equipos que ejecuten versiones
anteriores del sistema operativo Windows. Para los sistemas operativos Windows
anteriores, puede aplicar la configuración a las carpetas que se pueden redirigir. Son las
carpetas Datos de programa, Escritorio, Mis documentos, Mis imágenes y Menú
Inicio. Esta opción está disponible en la ficha Configuración de las Propiedades de la
carpeta, en Seleccione la configuración de redireccionamiento para
[nombreDeCarpeta].

 La opción para configurar las carpetas Música, Imágenes y Vídeos según la


carpeta Documentos. En los sistemas operativos Windows anteriores a Windows Vista,
estas carpetas eran subcarpetas de la carpeta Documentos. Al configurar esta opción se
resuelven los problemas relacionados con las diferencias de nomenclatura y estructura
de carpetas entre los sistemas operativos Windows anteriores y más recientes. Esta
opción está disponible en la ficha Destino de las Propiedades de la carpeta,
enConfiguración.

 La capacidad de redirigir la carpeta Menú Inicio a una ruta de acceso específica para
todos los usuarios. En Windows XP, la carpeta Menú Inicio solamente puede redirigirse
a una carpeta de destino compartida.

Características redirección de carpeta en


Windows

Windows proporciona la capacidad para redirigir las carpetas de usuario concretas a las
ubicaciones del servidor, utilizando una extensión de directiva de grupo denominada
Redirección de carpetas.

Muchos administradores pueden desear utilizar la redirección de carpetas de manera que las
carpetas de un usuario se redirijan de forma automática a una carpeta creada recientemente
para cada usuario. En este artículo se explica cómo redirigir a la nueva ubicación de carpeta y los
permisos de la Lista de control de acceso (ACL) de NTFS mínimos que se necesitan para
completar la redirección correctamente.

Configuración
La redirección de carpetas es una directiva de grupo de usuario. Esto significa que un usuario
para quien configure la redirección de carpetas debe tener una directiva de grupo vinculada a
alguna estructura de carpetas donde su objeto de usuario esté subordinado, como un sitio,
dominio o unidad organizativa.

Cuando crea la directiva de grupo y la vincula al objeto de carpeta adecuado, un administrador


puede designar qué carpetas redirigir y dónde. Para ello, el administrador necesita ir a la
ubicación siguiente en el objeto de directiva de grupo:

Configuración del usuario\Configuración de Windows\Redirección de carpetas

En las propiedades de la carpeta, puede elegir la redirección básica o avanzada de las carpetas,
y designar la ruta de acceso del sistema de archivos del servidor a la que se debería redirigir la
carpeta.
La variable %USERNAME% se puede utilizar como parte de la ruta de acceso de la redirección,
permitiendo así que el sistema cree de forma dinámica una carpeta recientemente redirigida
para cada usuario a quien se aplique el objeto de directiva.

Requisitos de seguridad
Si configura Redirección de carpetas para crear subcarpetas nuevas para cada usuario, ese
usuario necesita permisos ACL en los recursos compartidos y NTFS suficientes para crear la
subcarpeta en la ubicación adecuada.

Cuando un usuario no tiene permisos de ACL en los recursos compartidos y ACL suficientes, su
carpeta no se redirige y puede ver uno de los mensajes de sucesos siguientes en el registro de
sucesos de aplicación local:

Id. del suceso: 101

Usuario: nombreDeUsuario

Equipo: nombreDeEquipo

Descripción:
No se pudo realizar la redirección de la carpeta nombreDeCarpeta. No se pudieron crear
directorios nuevos para la carpeta redirigida. La carpeta está configurada para ser redirigida a
\\nombreDeServidor\nombreDeRecursoCompartido\%nombreDeUsuario%, la ruta de acceso
expandida final era \\nombreDeServidor\nombreDeRecursoCompartido\nombreDeUsuario.
Ocurrió el siguiente error:
Acceso denegado.

O bien

Id. del suceso: 101

Usuario: nombreDeUsuario

Equipo: nombreDeEquipo

Descripción:

Error al realizar la redirección de los datos de aplicación de las carpetas. Los archivos de la
carpeta redirigida no se pudieron mover a la nueva ubicación. La carpeta está configurada para
ser redirigida a rutaDeAcceso. Los archivos se estaban moviendo
desde rutaDeAcceso a rutaDeAcceso. Ocurrió el siguiente error: la estructura del descriptor de
seguridad no es válida.

Para obtener información adicional sobre los permisos que se requieren para un recurso
compartido que hospedará las carpetas redirigidas, haga clic en el número de artículo siguiente
para verlo en Microsoft Knowledge Base:

274443 Cómo crear dinámicamente carpetas redirigidas con seguridad mejorada mediante el
redireccionamiento de carpetas en Windows 2000 y en Windows Server 2003
Derechos de usuarios

Configurar la seguridad de
usuarios y grupos
Actualizado: enero de 2005
Se aplica a: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1,
Windows Server 2003 with SP2

Configurar la seguridad de usuarios y grupos


Para proteger un equipo y sus recursos, debe decidir qué tareas y acciones pueden realizar los
usuarios o grupos de usuarios. Las tareas y acciones que un usuario o un grupo de usuarios
pueden realizar dependen de los derechos de usuario que les asigne. Por ejemplo, si un
miembro de confianza del grupo Usuarios necesita supervisar el registro de seguridad, puede
concederle el derecho "Administrar auditoría y registro de seguridad" en lugar de agregar el
usuario a un grupo con más privilegios, como el grupo Administradores. De la misma forma,
puede proteger un objeto, como un archivo o una carpeta, si asigna permisos.
Algunas de las tareas más comunes son Para asignar derechos de usuario en el equipo
local, Para asignar derechos de usuario en toda la organización y Para definir, ver, cambiar o
quitar permisos de archivos y carpetas. Para obtener más información acerca de otras tareas
para configurar la seguridad de usuarios y grupos, vea Procedimientos de control de acceso.

Para asignar derechos de usuario en el equipo local


1. Abra Configuración de seguridad local.

2. En el árbol de la consola, haga clic en Asignación de derechos de usuario.

¿Dónde?

o Configuración de seguridad/Directivas locales/Asignación de derechos de


usuario

3. En el panel de detalles, haga doble clic en el derecho de usuario que desea modificar.

4. Lleve a cabo una de las acciones siguientes y, después, haga clic en Aceptar.

o Para agregar un usuario o grupo, haga clic en Agregar un usuario o grupo.


En Seleccionar Usuarios o Grupos, escriba el nombre de usuario o grupo que
desea agregar y haga clic en Aceptar.

o Para quitar un usuario o un grupo, selecciónelo en la lista y, a continuación,


haga clic en Quitar.

Notas
 Para llevar a cabo este procedimiento, debe ser miembro del grupo Administradores en
el equipo local o tener delegada la autoridad correspondiente. Si el equipo está unido a
un dominio, los miembros del grupo Administradores de dominio podrían llevar a cabo
este procedimiento. Como práctica recomendada de seguridad, considere la posibilidad
de utilizar la opción Ejecutar como para llevar a cabo este procedimiento.

 Para abrir Directiva de seguridad local, haga clic en Inicio, seleccione Configuración,
haga clic en Panel de control, haga doble clic en Herramientas administrativas y, a
continuación, haga doble clic en Directiva de seguridad local.

Para asignar derechos de usuario en toda la


organización
1. Abra Usuarios y equipos de Active Directory.

2. En el árbol de la consola, haga clic con el botón secundario del <i>mouse</i> (ratón)
en el objeto cuya configuración de seguridad desea modificar.

3. Haga clic en Propiedades y, a continuación, en la ficha Directiva de grupo.

4. Haga clic en Modificar para abrir el objeto de directiva de grupo que desea modificar.
O bien, haga clic en Nuevo para crear un nuevo objeto de directiva de grupo y, a
continuación, haga clic en Modificar.

5. En el árbol de la consola, haga clic en Asignación de derechos de usuario.

¿Dónde?

o objetoDeDirectivaDeGrupo [nombreDeEquipo] Directiva/Configuración del


equipo/Configuración de Windows/Configuración de seguridad/Directivas
locales/Asignación de derechos de usuario

6. En el panel de detalles, haga doble clic en el derecho de usuario que desea modificar.

7. Si la opción de seguridad no se ha definido todavía, active la casilla de


verificación Definir esta configuración de directiva.

8. Lleve a cabo una de las acciones siguientes y, después, haga clic en Aceptar.

o Para agregar un usuario o grupo, haga clic en Agregar un usuario o grupo.


En Seleccionar Usuarios o Grupos, escriba el nombre de usuario o grupo que
desea agregar y haga clic en Aceptar.

o Para quitar un usuario o un grupo, selecciónelo en la lista y, a continuación,


haga clic en Quitar.

Notas

 Para llevar a cabo este procedimiento, debe ser miembro del grupo Administradores de
dominio o del grupo Administradores de organización de Active Directory, o bien debe
tener delegada la autoridad correspondiente. Como práctica recomendada de
seguridad, considere la posibilidad de utilizar la opción Ejecutar como para llevar a cabo
este procedimiento. Para obtener más información, vea Grupos locales
predeterminados, Grupos predeterminados y Usar Ejecutar como.

 Para abrir Usuarios y equipos de Active Directory, haga clic en Inicio y en Panel de
control, haga doble clic en Herramientas administrativas y, a continuación, haga
doble clic en Usuarios y equipos de Active Directory.

 Si utiliza un servidor o una estación de trabajo unida al dominio, puede abrir Usuarios y
equipos de Active Directory si hace clic en Inicio, en Ejecutar, escribe mmc y hace clic
en Aceptar. En el menú Archivo, haga clic en Agregar o quitar complemento,
en Agregar, haga doble clic en Usuarios y equipos de Active Directory, haga clic
enCerrar y, después, en Aceptar.

 Cuando cree una directiva nueva haga siempre una prueba en una unidad organizativa
experimental antes de aplicarla a la red.

 Al cambiar una opción de configuración de seguridad, una vez que hace clic
en Aceptar, el cambio tendrá efecto la próxima vez que se actualice la configuración.

 La configuración de seguridad se actualiza cada 90 minutos en una estación de trabajo


o un servidor, y cada 5 minutos en un controlador de dominio. La configuración se
actualiza también cada 16 horas, con independencia de que se produzcan cambios o
no.

Para definir, ver, cambiar o quitar permisos de


archivos y carpetas
1. Abra el Explorador de Windows.

2. Haga clic con el botón secundario en el archivo o carpeta para los que desea establecer
permisos, haga clic en Propiedades y, después, en la ficha Seguridad.

3. Realice una de estas acciones:

o Para definir permisos para un grupo o un usuario que no aparezca en el


cuadro Nombres de grupos o usuarios, haga clic en Agregar. Escriba el
nombre del grupo o el usuario para el que desea definir permisos y, a
continuación, haga clic en Aceptar.

o Para cambiar o quitar permisos de un grupo o usuario existentes, haga clic en el


nombre del grupo o usuario.

4. Realice una de estas acciones:

o Para permitir o denegar un permiso, en el cuadro Permisos de Usuario o


grupo, active la casilla de verificación Permitir o Denegar.

o Para quitar el grupo o usuario del cuadro Nombres de grupos o usuarios,


haga clic en Quitar.

Notas
 Para abrir el Explorador de Windows, haga clic en Inicio, seleccione Todos los
programas, Accesorios y, a continuación, haga clic en Explorador de Windows.

 En la familia de Windows Server 2003, el grupo Todos ya no incluye Inicio de sesión


anónimo.

 Es posible definir los permisos de archivos y carpetas sólo en las unidades con formato
para utilizar NTFS.

 Si las casillas de verificación en Permisos de Usuario o grupo están sombreadas o si el


botón Quitar no está disponible, el archivo o la carpeta ha heredado permisos de la
carpeta principal. Si desea obtener más información, vea Cómo afecta la herencia a los
permisos de archivos y carpetas.

 Al agregar un usuario o grupo nuevo, este usuario o grupo tendrá de manera


predeterminada los permisos Leer y ejecutar, Mostrar el contenido de la
carpeta y Lectura.

Información sobre diferencias funcionales


 Es posible que el servidor funcione de forma distinta según la versión y la edición del
sistema operativo instalado, de los permisos de la cuenta y de la configuración de los
menús. Para obtener más información, vea Ver Ayuda en Web.

Visión general de la consola DNS

Procesos DNS y las


interacciones
Este tema aún no ha recibido ninguna valoración - Valorar este tema

Procesos DNS y las interacciones implican a las comunicaciones entre clientes y servidores DNS
durante la resolución de consultas DNS y actualización dinámica de DNS y entre servidores DNS
durante la administración de zona y de resolución de nombre. Procesos secundarios y las
interacciones dependen de la compatibilidad con tecnologías como Unicode y WINS.
Cómo funcionan las consultas DNS
Cuando un cliente DNS necesita buscar un nombre en un programa, consulta los servidores
DNS para resolver el nombre. Cada mensaje de consulta que el cliente envía contiene tres tipos
de información, se especifica una pregunta para el servidor responder:

1. Un DNS dominio nombre especificado, indicado como un nombre de dominio


completo (FQDN).

2. Un tipo de consulta especificada, que puede especificar un registro de recursos (RR) por
tipo o un tipo especializado de operación de consulta.
3. Una clase especificada para el nombre de dominio DNS. Los servidores DNS que
ejecutan el sistema operativo Windows, esto se debe especificar siempre como la clase
de Internet (IN).

Por ejemplo, el nombre especificado podría ser el FQDN de un equipo, como "host-
a.ejemplo.Microsoft.com." y el tipo de consulta especificado para buscar una dirección (A) RR
con ese nombre. Piense en una consulta DNS como un cliente de formular una pregunta de dos
partes de un servidor, como "¿tiene los registros de recursos de un equipo llamado
'nombrehost.ejemplo.Microsoft.com'?" Cuando el cliente recibe una respuesta del servidor, lee y
interpreta la contestada RR a, la dirección IP del equipo al que preguntó por el nombre de
aprendizaje.
Las consultas DNS resuelven en un número de diferentes maneras. Un cliente a veces puede
responder una consulta localmente utilizando información almacenada en caché obtenida de
una consulta anterior. El servidor DNS puede utilizar su propia caché de la información de
registro de recursos para responder una consulta. Un servidor DNS puede consultar también o
póngase en contacto con otros servidores DNS en nombre del cliente solicitante para resolver
completamente el nombre y, a continuación, enviar una respuesta al cliente. Este proceso se
conoce como recursividad.
Además, el propio cliente puede intentar ponerse en contacto con los servidores DNS
adicionales para resolver un nombre. Cuando un cliente lo hace, utiliza consultas adicionales e
independientes, según las respuestas de referencia de los servidores. Este proceso se conoce
como la iteración.
En general, el proceso de consulta DNS se produce en dos partes:

 Una consulta de nombre comienza en un equipo cliente y se pasa a una resolución, el


servicio cliente DNS, para la resolución.

 Cuando la consulta no se puede resolver localmente, se pueden consultar servidores


DNS según sea necesario para resolver el nombre.

Estos dos procesos se explican con más detalle en las secciones siguientes.
Parte 1: Resolución del servicio cliente DNS
La figura siguiente muestra una visión general del proceso de consulta DNS completo.
Visión general del proceso de consulta DNS
Como se muestra en los pasos iniciales del proceso de consulta, se utiliza un nombre de
dominio DNS en un programa en el equipo local. La solicitud, a continuación, se pasa para el
servicio cliente DNS para la resolución mediante la información almacenada en caché
localmente. Si se puede resolver el nombre consultado, se responde a la consulta y se completa
el proceso.
La caché de resolución local puede incluir información de nombres obtenida de dos orígenes
posibles:

 Si un archivo Hosts está configurado localmente, las asignaciones de nombre a


dirección de host de ese archivo se cargan en la memoria caché cuando se inicia el
servicio cliente DNS.

 Registros de recursos obtenidos en las respuestas a consultas DNS anteriores se


agregan a la caché y se mantienen durante un período de tiempo.

Si la consulta no coincide con una entrada en la caché, el proceso de resolución continúa con el
cliente consulta un servidor DNS para resolver el nombre.
Parte 2: Consultar un servidor DNS
Como se indica en la figura anterior, el cliente consulta un servidor DNS preferido. El servidor
utilizado durante la consulta inicial cliente-servidor está seleccionado de una lista global.
Cuando el servidor DNS recibe una consulta, comprueba primero si puede responder la consulta
con autoridad basada en información de registro de recursos contenido en una zona
configurada localmente en el servidor. Si el nombre consultado coincide con un RR
correspondiente en la información de zona local, el servidor responde con autoridad y utiliza
esta información para resolver el nombre consultado.
Si no existe ninguna información para el nombre consultado, a continuación, el servidor
comprueba si puede resolver el nombre utilizando la información almacenada localmente en
caché de consultas anteriores. Si aquí se encuentra una coincidencia, el servidor responde con
esta información. De nuevo, si el servidor preferido puede responder con una respuesta positiva
coincidente desde su caché al cliente solicitante, se realiza la consulta.
Si el nombre consultado no encuentra una respuesta coincidente en su servidor preferido: desde
su información de caché o la zona, puede continuar el proceso de consulta, mediante la
recursividad para resolver completamente el nombre. Esto implica la asistencia de otros
servidores DNS para ayudar a resolver el nombre. De forma predeterminada, el servicio cliente
DNS solicita al servidor que utilice un proceso de recursividad para resolver completamente los
nombres en nombre del cliente antes de devolver una respuesta.
Para el servidor DNS realice la recursión correctamente, primero necesita información de
contacto útil acerca de otros servidores DNS en el espacio de nombres de dominio DNS.Esta
información se proporciona en forma de sugerencias de raíz, una lista de RR preliminar que
puede utilizarse el servicio DNS para localizar otros servidores DNS que tienen autoridad para la
raíz del árbol del espacio de nombres de dominio DNS. Los servidores raíz tienen autoridad para
el dominio raíz y los dominios de nivel superior en el árbol de espacio de nombres de dominio
DNS.
Al utilizar sugerencias de raíz para encontrar los servidores raíz, un servidor DNS es capaz de
completar el uso de la recursividad. En teoría, este proceso permite a un servidor DNS localizar
los servidores que tienen autoridad para cualquier otro nombre de dominio DNS utilizado en
cualquier nivel en el árbol del espacio de nombres.
Por ejemplo, considere el uso del proceso de recursividad para buscar el nombre "host-
b.ejemplo.Microsoft.com." cuando el cliente consulta un único servidor DNS. El proceso se
produce cuando un cliente y servidor DNS se inician y no localmente ya almacenado en caché la
información disponible para ayudar a resolver una consulta de nombre. Se supone que el
nombre consultado por el cliente es un nombre de dominio que el servidor no tiene
conocimiento local, basándose en sus zonas configuradas.
En primer lugar, el servidor preferido analiza el nombre completo y determina que necesita la
ubicación del servidor que está autorizado para el dominio de nivel superior "com".A
continuación, utiliza una consulta iterativa a "com" DNS server para obtener una referencia al
servidor "microsoft.com". A continuación, una respuesta de referencia proviene del servidor
"microsoft.com" al servidor DNS para "ejemplo.Microsoft.com".
Por último, se contacta con el servidor "ejemplo.Microsoft.com.". Dado que este servidor
contiene el nombre consultado como parte de sus zonas configuradas, responde con autoridad
al servidor original que inició la recursividad. Cuando el servidor original recibe la respuesta que
indica que se obtuvo una respuesta con autoridad a la consulta solicitada, reenvía esta
respuesta al cliente solicitante y se completa el proceso de consulta recursiva.
Aunque el proceso de consulta recursiva puede consumir muchos recursos cuando se realiza
como se describe anteriormente, tiene algunas ventajas de rendimiento del servidor DNS. Por
ejemplo, durante el proceso de recursividad, el servidor DNS realiza la búsqueda recursiva
obtiene información acerca del espacio de nombres de dominio DNS. Esta información se
almacena en caché por el servidor y puede volver a utilizarse para ayudar a acelerar la respuesta
de consultas subsiguientes que utilizan o concuerdan con ella. Con el tiempo, esta información
almacenada en caché puede crecer hasta ocupar una parte importante de recursos de memoria
del servidor, aunque se limpia siempre que el servicio DNS se activa y desactiva.
Las tres cifras siguientes ilustran el proceso por el cual el cliente DNS consulta los servidores en
cada adaptador.
Consultar el servidor DNS, parte 1
Consultar el servidor DNS, parte 2
Consultar el servidor DNS, parte 3
El servicio cliente DNS consulta los servidores DNS en el siguiente orden:

1. El servicio cliente DNS envía la consulta de nombre para el primer servidor DNS en la
lista del adaptador preferido de los servidores DNS y espera un segundo para una
respuesta.

2. Si el servicio cliente DNS no recibe una respuesta desde el primer servidor DNS en un
segundo, envía la consulta de nombre a los primeros servidores DNS en todos los
adaptadores que son posibles y espera dos segundos para una respuesta.

3. Si el servicio cliente DNS no recibe una respuesta desde cualquier servidor DNS dentro
de dos segundos, el cliente DNS servicio envía la consulta a todos los servidores DNS en
todos los adaptadores que son posibles y espera a que otro de dos segundos para una
respuesta.
4. Si el servicio cliente DNS sigue sin recibir una respuesta desde cualquier servidor DNS,
envía la consulta de nombre a todos los servidores DNS en todos los adaptadores que
son posibles y espera cuatro segundos para una respuesta.

5. Si el servicio cliente DNS no recibe una respuesta desde cualquier servidor DNS, el
cliente DNS envía la consulta a todos los servidores DNS en todos los adaptadores que
son posibles y espera ocho segundos de una respuesta.

Si el servicio cliente DNS recibe una respuesta positiva, deja de consultar el nombre, agrega la
respuesta a la caché y devuelve la respuesta al cliente.
Si el servicio cliente DNS no ha recibido una respuesta desde cualquier servidor dentro de los
ocho segundos, el servicio cliente DNS responde con un tiempo de espera. También, si no ha
recibido una respuesta desde cualquier servidor DNS en un adaptador determinado, a
continuación, para los 30 segundos, el servicio cliente DNS responde a todas las consultas
dirigidas a servidores en que el adaptador con un tiempo de espera y no consulta los servidores.
Si en cualquier momento el cliente DNS servicio recibe una respuesta negativa de un servidor,
quita todos los servidores de ese adaptador de examen durante esta búsqueda. Por ejemplo, si
en el paso 2, el primer servidor de adaptador alternativo a dio una respuesta negativa, el
servicio cliente DNS no enviará la consulta a cualquier otro servidor en la lista para el adaptador
alternativo a.
El servicio cliente DNS realiza el seguimiento de los servidores que responden las consultas de
nombres más rápidamente y sube servidores o hacia abajo en la lista basándose en cómo
rápidamente responden a consultas de nombres.
La figura siguiente muestra cómo el cliente DNS consulta cada servidor en cada adaptador.
Resolución de nombres de hosts múltiples

Respuestas de consultas alternativas


La descripción anterior de las consultas DNS se supone que el proceso finaliza con una
respuesta positiva devuelta al cliente. Sin embargo, las consultas pueden devolver otras
respuestas también. Estas son las respuestas de consulta más comunes:

 Una respuesta con autoridad

 Una respuesta positiva


 Una respuesta de referencia

 Una respuesta negativa

Una respuesta con autoridad es una respuesta positiva devuelta al cliente y entregado con el bit
de autoridad en el mensaje DNS para indicar que la respuesta se obtuvo de un servidor con
autoridad directa para el nombre consultado.
Una respuesta positiva puede constar de los consultados RR o una lista de registros de recursos
(también llamada un RRset) que se ajusta al nombre de dominio DNS consultado y el tipo de
registro especificado en el mensaje de consulta.
Una respuesta de referencia contiene registros de recursos adicionales no especificados por
nombre o tipo de la consulta. Este tipo de respuesta se devuelve al cliente si no se admite el
proceso de recursividad. Los registros deben actuar como respuestas de referencia útiles que el
cliente puede utilizar para continuar la consulta mediante la iteración.Una respuesta de
referencia contiene datos adicionales como, por ejemplo, los registros de recursos que no sea el
tipo de consulta. Por ejemplo, si el nombre de host consultado era "www" y no RR a para este
nombre se han encontrado en esta zona pero se encontró en su lugar un RR CNAME para
"www", el servidor DNS puede incluir esa información al responder al cliente. Si el cliente es
capaz de utilizar la iteración, puede hacer consultas adicionales con la información de referencia
en un intento para resolver completamente el nombre por sí mismo.
Una respuesta negativa del servidor puede indicar que se encontró uno de dos resultados
posibles mientras el servidor intentaba procesar y resolver de forma recursiva la consulta
completamente y con autoridad:

 Un servidor con autoridad informó de que el nombre consultado no existe en el espacio


de nombres DNS.

 Un servidor con autoridad informó que el nombre consultado existe, pero no existe
ningún registro del tipo especificado para ese nombre.

La resolución pasa los resultados de la consulta, en forma de una respuesta positiva o negativa,
al programa solicitante y almacena en caché la respuesta.
Si la respuesta resultante de una consulta es demasiado larga para ser enviarse y resolverse en
un único paquete de mensaje UDP, el servidor DNS puede iniciar una conmutación por error
respuesta a través del puerto TCP 53 para responder al cliente completamente en un TCP sesión
conectada.
Deshabilitar el uso de la recursividad en un servidor DNS se realiza generalmente cuando los
clientes DNS se limitan a la resolución de nombres en un servidor DNS específico, como el que
se encuentra en una intranet. También puede deshabilitar la recursividad cuando el servidor
DNS no puede resolver nombres DNS externos y se espera que los clientes conmuten por error
a otro servidor DNS para la resolución de estos nombres. Si deshabilita la recursividad en el
servidor DNS, no podrá utilizar reenviadores en el mismo servidor.
De forma predeterminada, los servidores DNS utilizan varios tiempos predeterminados cuando
se realiza una recursiva de consultas y ponerse en contacto con otros servidores DNS. Estos
valores predeterminados son:

 Un intervalo de reintento de recursividad de 3 segundos. Es la longitud de tiempo que


espera el servicio DNS antes de reintentar una consulta realizada durante una búsqueda
recursiva.

 Un intervalo de tiempo de espera de recursividad de 8 segundos. Es la longitud de


tiempo que espera el servicio DNS antes una búsqueda recursiva que se ha reintentado.
En la mayoría de los casos, estos parámetros no es necesario ajustar. Sin embargo, si utiliza
búsquedas recursivas a través de un vínculo de baja velocidad de área extensa (WAN), es
posible que pueda mejorar el rendimiento del servidor y completar la consulta realizando
pequeños ajustes en la configuración.
Cómo funciona la iteración
Iteración es el tipo de resolución de nombres utilizado entre clientes y servidores DNS cuando
están en vigor de las siguientes condiciones:

 El cliente solicita el uso de la recursividad, pero se deshabilita la recursividad en el


servidor DNS.

 El cliente no solicita el uso de la recursividad cuando consulta el servidor DNS.

Una solicitud iterativa de un cliente indica al servidor DNS que el cliente espera que la mejor
respuesta del servidor DNS pueda proporcionar inmediatamente, sin ponerse en contacto con
otros servidores DNS.
Cuando se utiliza la iteración, un servidor DNS responde a un cliente basado en su propio
conocimiento específico sobre el espacio de nombres con respecto a los datos de nombres que
se consulta. Por ejemplo, si un servidor DNS de la intranet recibe una consulta de un cliente
local para "www.microsoft.com", podría devolver una respuesta de su caché de nombres. Si el
nombre consultado no está almacenado actualmente en la caché de nombres del servidor, el
servidor puede responder al proporcionar una remisión: es decir, una lista de NS y RR de otros
servidores DNS que están más cerca del nombre consultado por el cliente.
Cuando se utiliza la iteración, un servidor DNS puede ayudar en una resolución de la consulta
de nombre además de devolver su mejor respuesta propia al cliente. Para las consultas iterativas
más, un cliente utiliza su lista de servidores DNS configurada localmente para ponerse en
contacto con otros servidores de nombres en todo el espacio de nombres DNS si su servidor
DNS principal no puede resolver la consulta.
El servicio cliente DNS de Windows Server 2008 no realiza recursividad.
Cómo funciona el almacenamiento en caché
Cuando los servidores DNS procesan las consultas del cliente mediante la recursión o iteración,
descubren y adquieren un almacén significativo de información sobre el espacio de nombres
DNS. A continuación, el servidor almacena en caché esta información.
Almacenamiento en caché, proporciona una manera de acelerar el rendimiento de la resolución
DNS para posteriores consultas de nombres populares, y reducir considerablemente el tráfico de
consultas relacionadas con DNS en la red.
Como los servidores DNS realizan consultas recursivas en nombre de clientes, almacenan
temporalmente en caché los registros de recursos. Los registros de recursos almacenados en
caché contienen información obtenida de los servidores DNS que tienen autoridad para
nombres de dominio DNS aprendidos durante las consultas iterativas para buscar y responder
por completo una consulta recursiva realizaron en nombre de un cliente. Más tarde, cuando
otros clientes realizan consultas nuevas que solicitan información de RR que coincide con los
registros de recursos almacenados en caché, el servidor DNS puede utilizar la información
almacenada en caché de RR para responderlas.
Cuando se almacena en caché la información, un valor de tiempo de vida (TTL) se aplica a todos
los registros de recursos almacenados en caché. Siempre y cuando el TTL para un registro de
recursos almacenados en caché no caduque, un servidor DNS puede seguir en caché y utilizar
los RR de nuevo al responder a consultas de sus clientes que coincidan con estos registros de
recursos. Almacenamiento en caché TTL utilizados por los registros de recursos en la mayoría de
las configuraciones de zona se asignan valores el TTL mínimo (predeterminado) que se
establece en la zona de inicio de autoridad (SOA) RR. De forma predeterminada, el mínimo TTL
es de 3.600 segundos (una hora) pero se puede ajustar o, si es necesario, se pueden establecer
TTLs caché individuales en cada RR.

Nota

De forma predeterminada, el servicio de servidor DNS utiliza un archivo de sugerencias de raíz, cache.dns, que se
el equipo servidor. Este archivo contiene los RR de a y NS para los servidores raíz del espacio de nombres DNS (lo
intranet).Cuando se inicia el servicio servidor DNS, se consulta la lista de servidores raíz para obtener una lista ac
consulta se utilizan para actualizar el archivo de sugerencias de raíz. También se realiza periódicamente mientras
las sugerencias de raíz por un administrador, estos cambios se vuelven a escribir el archivo de sugerencias de raí

Búsqueda inversa
En la mayoría de las búsquedas DNS, los clientes suelen realizar una búsqueda directa, que es
una búsqueda basada en el nombre DNS del otro equipo, como se almacena en un RR de
dirección (A). Este tipo de consulta espera una dirección IP como los datos de recursos para la
respuesta a.
DNS también proporciona un proceso de búsqueda inversa, que permite a los clientes para
utilizar una dirección IP conocida durante una consulta de nombre y para buscar un nombre de
equipo según su dirección. Una búsqueda inversa adopta la forma de una pregunta, como
"Puede decirme el nombre DNS del equipo que utiliza la dirección IP 192.168.1.20?"
DNS no se diseñó originalmente para admitir este tipo de consulta. Un problema de
compatibilidad con el proceso de consulta inversa es la diferencia en cómo se organiza el
espacio de nombres DNS y nombres de los índices y cómo se asignan direcciones IP. Si el único
método disponible para contestar la pregunta anterior fuera buscar todos los dominios en el
espacio de nombres DNS, una consulta inversa sería tardan mucho tiempo y requerir un
procesamiento demasiado para ser útil.
Para resolver este problema, un dominio especial llamado el dominio in-addr.arpa fue definido
en los estándares de DNS y reservado en el espacio de nombres DNS de Internet para
proporcionar una forma práctica y confiable para realizar consultas inversas. Para crear el
espacio de nombres inverso, los subdominios dentro del dominio in-addr.arpa se crean con el
orden inverso de los números en la notación decimal con puntos de direcciones IP.
Este orden inverso de los dominios para cada valor de octeto es necesario porque, a diferencia
de los nombres DNS, cuando las direcciones IP se leen de izquierda a derecha, se interpretan de
forma opuesta. Cuando una dirección IP se lee de izquierda a derecha, se ve desde su
información más generalizada (una dirección IP de red) en la primera parte de la dirección a la
información más específica (una dirección IP de host) contenida en los últimos octetos.
Por este motivo, se debe invertir el orden de los octetos de la dirección IP al generar el árbol del
dominio in-addr.arpa. Las direcciones IP del árbol DNS in-addr.arpa pueden delegarse a las
empresas, ya que se les asigna un conjunto específico o limitado de direcciones IP dentro de las
clases de direcciones definidas en Internet.
Por último, el árbol del dominio in-addr.arpa, como se crea en DNS, requiere que escriba un RR
adicional — el RR de puntero (PTR) — definirse. Este RR se utiliza para crear una asignación en
la zona de búsqueda inversa que normalmente corresponde a un host (A) RR con nombre para
el nombre de equipo DNS de un host en su zona de búsqueda directa.
El dominio in-addr.arpa se aplica para su uso en todas las redes TCP/IP que se basan en el
protocolo de Internet versión 4 (IPv4) direccionamiento. El Asistente para zona nueva supone
automáticamente que se utiliza este dominio cuando se crea una nueva zona de búsqueda
inversa.
Si está instalando DNS y zonas de búsqueda inversa de configurar una protocolo de Internet
versión 6 red (IPv6), puede especificar un nombre exacto en el Asistente para nueva zona. Esto
le permitirá crear zonas de búsqueda inversa en la consola DNS que se puede utilizar para
admitir redes IPv6, que utilice un nombre de dominio especial diferente, el dominio ip6.int.
Para obtener información acerca de IPv6 y DNS, incluyendo ejemplos de cómo crear y utilizar
nombres de dominio ip6.int tal como se describe en RFC 1886 ("DNS Extensions to support IP
version 6"), consulte Información de referencia DNS .

Nota

La configuración de los RR PTR y zonas de búsqueda inversa para identificar hosts mediante consultas inversas es
implementación DNS estándar. No debe utilizar las zonas de búsqueda inversa, aunque algunas aplicaciones en r
seguridad.

Ejemplo: Consulta inversa (para redes IPv4)


La siguiente figura muestra un ejemplo de una consulta inversa iniciada por un cliente DNS
(host-b) para aprender el nombre de otro host (host-a) basándose en su dirección IP,
192.168.1.20.
Consulta inversa

El proceso de consulta inversa como se muestra en esta figura se produce en los siguientes
pasos:

1. El cliente, "host-b", consulta al servidor DNS para un RR de puntero (PTR) asigna a la


dirección IP 192.168.1.20 a "host-a".

Dado que la consulta es para los registros PTR, la resolución invierte la dirección y anexa
el dominio in-addr.arpa al final de la dirección inversa. Esto forma el nombre de
dominio completo ("20.1.168.192.") que se va a buscar en una zona de búsqueda
inversa.

2. Después de que se encuentra, el servidor DNS autorizado para "20.1.168.192" puede


responder con la información del registro PTR. Esto incluye el nombre de dominio DNS
para "host-a," completar la búsqueda inversa.

Tenga en cuenta que si la consulta inversa nombre no es el servidor DNS puede responder,
puede utilizar la resolución DNS normal (recursión o iteración) para localizar un servidor DNS
con autoridad para la zona de búsqueda inversa y que contiene el nombre consultado. En este
sentido, el proceso de resolución de nombres utilizado en una búsqueda inversa es idéntico de
una búsqueda directa.

Nota

La consola DNS proporciona un medio para configurar una zona de búsqueda inversa con subredes "sin clases" c
configurar una zona en el dominio in-addr.arpa para un conjunto limitado de direcciones IP asignadas donde se u
con esas direcciones.

Reenvío
Un reenviador es un servidor DNS de una red que se utiliza para reenviar consultas DNS para
nombres DNS externos a servidores DNS fuera de la red. También puede enviar consultas según
nombres de dominio específicos mediante reenviadores condicionales.
Un servidor DNS de una red se designa como reenviador haciendo que los otros servidores DNS
en la red le reenvíen las consultas que se pueden resolver localmente en ese servidor DNS. Al
utilizar un reenviador, puede administrar la resolución de nombres fuera de la red, como los
nombres en Internet y mejorar la eficiencia de resolución de nombres para los equipos de la red.
Dirigir las consultas de nombre utilizar reenviadores
La figura siguiente ilustra cómo nombres externos se dirigen las consultas utilizando
reenviadores.
Consultas de nombres externo dirigidas utilizar reenviadores

Sin necesidad de un servidor DNS específico designado como reenviador, todos los servidores
DNS pueden enviar consultas fuera de una red utilizando sus sugerencias de raíz.Como
resultado, mucha información de DNS interna y posiblemente fundamental, puede quedar
expuesta en Internet. Además de este problema de privacidad y seguridad, este método de
resolución puede producir un gran volumen de tráfico externo que resulta costoso e ineficiente
para una red con una conexión a Internet lenta o una empresa con altos costos de servicio de
Internet.
Al designar un servidor DNS como reenviador, que dicho reenviador responsable de controlar el
tráfico externo, lo que limita la exposición del servidor DNS a Internet. Un reenviador generará
una memoria caché de gran tamaño de la información de DNS externo, ya que todas las
consultas DNS externas en la red se resuelven a través de él. En un corto período de tiempo, un
reenviador se resuelven una buena parte de las consultas DNS externas utilizando estos datos
en caché y, por tanto, reducir el tráfico de Internet a través de la red y el tiempo de respuesta
para los clientes DNS.
Comportamiento de un servidor DNS configurado para utilizar el
reenvío
Un servidor DNS configurado para utilizar un reenviador se comportará de forma diferente
desde un servidor DNS que no está configurado para utilizar un reenviador. Un servidor DNS
configurado para utilizar un reenviador se comporta como sigue:

1. Cuando el servidor DNS recibe una consulta, intenta resolver esta consulta mediante las
zonas primarias y secundarias que hospeda y su caché.

2. Si no se puede resolver la consulta utilizando estos datos locales, reenviará la consulta


al servidor DNS designado como reenviador.

3. El servidor DNS esperará brevemente una respuesta del reenviador antes de intentar
ponerse en contacto con los servidores DNS especificados en sus sugerencias de raíz.

Cuando un servidor DNS envía una consulta a un reenviador envía una consulta recursiva al
reenviador. Esto es diferente de la consulta iterativa que un servidor DNS enviará a otro servidor
DNS durante la resolución de nombres estándar (resolución de nombres que no implique un
reenviador).
Secuencia de reenvío
La secuencia en la que se utilizan los reenviadores configurados en un servidor DNS está
determinada por el orden en que se enumeran las direcciones IP en el servidor DNS.Después de
que el servidor DNS reenvía la consulta al reenviador con la primera dirección IP, espera un
breve período una respuesta de ese reenviador (según configuración de tiempo de espera del
servidor DNS) antes de reanudar las operaciones con la siguiente dirección IP. Este proceso
continúa hasta que recibe una respuesta afirmativa de un reenviador.
A diferencia de la resolución convencional, donde un tiempo de ida y vuelta (RTT) está asociada
con cada servidor, las direcciones IP en la lista de reenviadores no están ordenadas según el
tiempo de ida y vuelta y deben ordenarse manualmente para cambiar la preferencia.
Los reenviadores y delegación
Un servidor DNS configurado con un reenviador y que aloja una zona principal utilizará su
información de delegación antes de reenviar las consultas. Si no existe ningún registro de
delegación para el nombre DNS de la consulta, el servidor DNS utilizará sus reenviadores para
resolver la consulta.
Los servidores raíz y reenviadores
Un error común al configurar el reenvío es intentar configurar el reenvío en los servidores raíz
de un espacio de nombres DNS privado. El objetivo de intentar configurar el reenvío en
servidores raíz para un espacio de nombres DNS privado es reenviar todas las consultas de fuera
del sitio a servidores DNS de Internet. Los servidores raíz no pueden configurarse con reenvío
estándar. Si se consulta un servidor raíz sobre cualquier nombre de dominio, a continuación,
hará referencia a un servidor DNS que puede responder a la pregunta (desde sus zonas locales,
caché), o responderá con un error (NXDOMAIN), pero no se puede configurar para enviar a
servidores específicos.

Nota
Un servidor raíz puede configurarse con un reenviador condicional. Reenvío condicional puede utilizarse para en
nombres DNS independientes, aunque los servidores DNS de los dominios de nivel superior en el espacio de nom
resolución.

Reenviadores condicionales
Un reenviador condicional es un servidor DNS en una red que se utiliza para reenviar consultas
DNS de acuerdo con el nombre de dominio DNS de la consulta. Por ejemplo, un servidor DNS
puede configurarse para reenviar todas las consultas que reciba para los nombres que terminen
con widgets.ejemplo.com a la dirección IP de un servidor DNS o a las direcciones IP de varios
servidores DNS.
Resolución de nombres de intranet
Un reenviador condicional puede utilizarse para mejorar la resolución de nombres para
dominios dentro de su intranet. Resolución de nombres de intranet puede mejorarse mediante
la configuración de servidores DNS con reenviadores para nombres de dominio internos
específicos. Por ejemplo, todos los servidores DNS del dominio widgets.ejemplo.com pueden
configurarse para reenviar consultas para nombres que terminen con prueba.ejemplo.como a
los servidores DNS autorizados para merged.widgets.example.com, eliminando así el paso de
consultar los servidores raíz de ejemplo.com, o quitar el paso de configuración de servidores
DNS en la zona widgets.ejemplo.com con zonas secundarias para prueba.ejemplo.com.
Resolución de nombres de Internet
Los servidores DNS pueden utilizar reenviadores condicionales para resolver consultas entre los
nombres de dominio DNS de las empresas que comparten información. Por ejemplo, dos
compañías, Widgets Toys y Tailspin Toys, quieren mejorar cómo los clientes DNS de Widgets
Toys resuelvan los nombres de los clientes DNS de Tailspin Toys. Los administradores de
Tailspin Toys informan a los administradores de Widgets Toys acerca del conjunto de servidores
DNS de la red de Tailspin Toys que Widgets puede enviar consultas para el dominio
muñecas.tailspintoys.com. Los servidores DNS dentro de la red de Widgets Toys están
configurados para reenviar todas las consultas de nombres que terminen con
muñecas.tailspintoys.com a los servidores DNS designados en la red para Tailspin Toys. Por
tanto, no es necesario que los servidores DNS de la red de Widgets Toys consultar sus
servidores raíz internos o los servidores raíz de Internet, para resolver consultas de nombres que
terminen con muñecas.tailspintoys.com.
Actualización dinámica
Actualización dinámica permite a los equipos cliente DNS registren y actualicen dinámicamente
sus RR con un servidor DNS cuando se producen cambios. Esto reduce la necesidad de
administración manual de registros de la zona, especialmente para los clientes que con
frecuencia, mover o cambiar las ubicaciones y utilizar DHCP para obtener una dirección IP.
Los servicios de cliente y servidor DNS admiten el uso de las actualizaciones dinámicas, como se
describe en RFC 2136, "Actualizaciones dinámicas en el sistema de nombres de dominio". El
servicio servidor DNS permite la actualización dinámica se activan o desactivan en una base de
cada zona en cada servidor configurado para cargar una zona principal estándar o integrada de
directorio. De forma predeterminada, el servicio cliente DNS de Windows Server 2008
actualizará dinámicamente host (A) RR de DNS cuando se configuran para TCP/IP. El servicio
servidor DNS de Windows Server 2008 está configurado de forma predeterminada, para permitir
sólo actualizaciones dinámicas seguras. Debe cambiar esta configuración si va a utilizar sólo la
actualización dinámica.
Descripción de protocolo
RFC 2136 presenta un nuevo formato de mensaje o código de operación denominado
UPDATE. El mensaje de actualización puede agregar y eliminar los registros de recursos de una
zona específica como prueba de requisitos previos. Actualización es atómica, es decir, se deben
satisfacer todos los requisitos previos o ninguna operación de actualización llevará a cabo.
Como en cualquier implementación de DNS convencional, se debe confirmar la actualización de
zona en un servidor DNS principal para esa zona. Si un servidor DNS secundario recibe una
actualización, se reenviará la topología de replicación hasta que alcance el servidor DNS
principal. En el caso de una zona integrada en Active Directory, una actualización de un registro
de recursos en una zona puede enviarse a cualquier servidor DNS que se ejecutan en un
controlador de dominio de Active Directory cuyo almacén de datos contiene la zona.
Un proceso de transferencia de zona siempre bloquea una zona para que un servidor DNS
secundario recibe una vista coherente al transferir los datos de zona. Cuando la zona está
bloqueada, ya no puede aceptar actualizaciones dinámicas. Si la zona es grande y se bloquea
frecuentemente para fines de transferencia de zona, se reducirán a los clientes de actualización
dinámica y el sistema puede volverse inestable. El servicio servidor DNS de Windows Server
2008 pone en cola las solicitudes de actualización que ha llegado durante la transferencia de
zona y los procesa una vez finalizada la transferencia de zona.
Cómo actualizan sus nombres DNS en equipos cliente y servidor
De forma predeterminada, los equipos configurados estáticamente para TCP/IP intentan
registrar dinámicamente los RR de puntero (PTR) para las direcciones IP configuradas y
utilizadas por sus conexiones de red instaladas y de host (A). Todos los equipos guardan los
registros según su FQDN.
Los siguientes valores predeterminados se aplican también a cómo actualizan sus nombres DNS
en equipos:

 De forma predeterminada, el cliente DNS de Windows XP no intenta realizar


actualizaciones dinámicas a través de una conexión de red privada virtual (VPN) o
acceso remoto. Para modificar esta configuración, puede modificar la configuración
avanzada de TCP/IP de la conexión de red particular o modificar el registro.

 De forma predeterminada, el cliente DNS no intenta realizar actualizaciones dinámicas


de zonas de dominio de nivel superior (TLD). Cualquier zona en el nombre de una sola
etiqueta se considera una zona TLD, por ejemplo, com, edu, en blanco, mi-empresa.

 De forma predeterminada, la parte del sufijo DNS principal del FQDN de un equipo es el
mismo que el nombre del dominio de Active Directory al que está unido el equipo.Para
permitir diferentes sufijos DNS principales, un administrador de dominio puede crear
una lista restringida de sufijos permitidos modificando el atributo msDS-
AllowedDNSSuffixes en el contenedor de objeto de dominio. Este atributo es
administrado por el administrador del dominio mediante Interfaces de servicio de
Active Directory (ADSI) o el protocolo ligero de acceso a directorios (LDAP).

Se pueden enviar actualizaciones dinámicas para cualquiera de los siguientes motivos o eventos:

 Una dirección IP es agregada, eliminada o modificada en la configuración de las


propiedades de TCP/IP para cualquiera de las conexiones de red instalados.

 Una concesión de dirección IP cambia o renueva con el servidor DHCP cualquiera de las
conexiones de red instalados, por ejemplo, cuando se inicia el equipo o si laipconfig
/renew se utiliza el comando.
 El comando ipconfig /registerdns se utiliza para forzar manualmente una actualización
del registro de nombre de cliente en DNS.

 Durante el inicio, cuando se enciende el equipo.

 Un servidor miembro se promueve a controlador de dominio.

Cuando uno de los eventos anteriores desencadena una actualización dinámica, el servicio
cliente DHCP (no el servicio cliente DNS) envía actualizaciones. Esto está diseñado para que si se
produce un cambio en la información de dirección IP debido a DHCP, se realizan las
actualizaciones correspondientes en DNS para sincronizar asignaciones de nombre a dirección
para el equipo. El servicio cliente DHCP realiza esta función para todas las conexiones de red
utilizadas en el sistema, incluidas las conexiones no está configuradas para utilizar DHCP.
Este proceso de actualización supone que los valores predeterminados están disponibles para
los servidores que ejecutan Windows Server 2008 de la instalación. Los nombres específicos y
actualización de comportamiento es ajustable donde se configuran las propiedades avanzadas
de TCP/IP para utilizar la configuración de DNS no predeterminada.
También en el nombre completo de equipo (o nombre principal) del equipo, los nombres DNS
específicos de la conexión adicionales se pueden configurar y opcionalmente registrados o
actualizar en DNS.
Ejemplo: Trabajos de actualización dinámica
Actualizaciones dinámicas normalmente se solicitan cuando cambia el nombre DNS o la
dirección IP del equipo. Por ejemplo, supongamos que un cliente llamado "antiguohost" está
configurado en las propiedades del sistema con los siguientes nombres:

Nombre del equipo antiguohost

Nombre de dominio DNS del equipo ejemplo.Microsoft.com

Nombre completo de equipo antiguohost.ejemplo.Mi


En este ejemplo, no hay nombres de dominio DNS específicos de la conexión están
configurados para el equipo. Más tarde, el equipo se cambia el nombre de "antiguohost" a
"nuevohost", en los siguientes cambios de nombre en el sistema:

Nombre del equipo nuevohost que conllev

Nombre de dominio DNS del equipo ejemplo.Microsoft.com

Nombre completo de equipo nuevohost.ejemplo.Mi


Después de aplica el cambio de nombre de Propiedades del sistema, se solicitará que reinicie
el equipo. Cuando el equipo reinicia Windows, el servicio cliente DHCP realiza la siguiente
secuencia de actualización de DNS:

1. El servicio cliente DHCP envía una consulta de tipo SOA con el nombre de dominio DNS
del equipo.

El equipo cliente utiliza el FQDN configurado actualmente del equipo (como


"nuevohost.ejemplo.Microsoft.com") como el nombre especificado en esta consulta.
2. El servidor DNS autorizado para la zona que contiene el FQDN del cliente responde a la
consulta de tipo SOA.

Las zonas principales estándar, el servidor principal (propietario) devuelto en la


respuesta de consulta SOA es fijo y estático. Siempre coincide con el nombre DNS
exacto tal y como aparece en el RR SOA almacenado con la zona. Si, sin embargo, la
zona que se está actualizada está integrada en directorio, cualquier servidor DNS que se
ejecuta en un controlador de dominio para el dominio de Active Directory en el FQDN
puede responder y insertar dinámicamente su propio nombre como el servidor principal
(propietario) de la zona en la respuesta de consulta SOA.

3. El servicio cliente DHCP intenta ponerse en contacto con el servidor DNS principal.

The client processes the SOA query response for its name to determine the IP address
of the DNS server authorized as the primary server for accepting its name. It then
proceeds to perform the following sequence of steps as needed to contact and
dynamically update its primary server:

o It sends a dynamic update request to the primary server determined in the SOA
query response.

o If the update succeeds, no further action is taken.

o If this update fails, the client next sends an NS-type query for the zone name
specified in the SOA record.

o When it receives a response to this query, it sends an SOA query to the first
DNS server listed in the response.

o After the SOA query is resolved, the client sends a dynamic update to the server
specified in the returned SOA record.

o If the update succeeds, no further action is taken.

o If this update fails, then the client repeats the SOA query process by sending to
the next DNS server listed in the response.

4. After the primary DNS server that can perform the update is contacted, the client sends
the update request and the DNS server processes it.

The contents of the update request include instructions to add A (and possibly PTR) RRs
for “newhost.example.microsoft.com” and remove these same record types for
“oldhost.example.microsoft.com”, the name that was previously registered.

The DNS server also checks to ensure that updates are permitted for the client
request. For standard primary zones, dynamic updates are not secured, so any client
attempt to update succeeds. For Active Directory–integrated zones, updates are secured
and performed using directory-based security settings. For more information, see
“Secure dynamic update” later in this topic.

Dynamic updates are sent or refreshed periodically. By default, computers send a refresh once
every seven days. If the update results in no changes to zone data, the zone remains at its
current version and no changes are written. Updates result in actual zone changes or increased
zone transfer only if names or addresses actually change.
Note that names are not removed from DNS zones if they become inactive or are not updated
within the refresh interval (seven days). DNS does not use a mechanism to release or tombstone
names, although DNS clients do attempt to delete or update old name records when a new
name or address change is applied.
When the DHCP Client service registers A and PTR RRs for a computer, it uses a default caching
Time To Live (TTL) of 15 minutes for host records. This determines how long other DNS servers
and clients cache a computer’s records when they are included in a query response.
DNS and DHCP clients and servers
Windows DHCP clients are dynamic update-aware and can initiate the dynamic update
process. A DHCP client negotiates the process of dynamic update with the DHCP server when
the client leases an IP address or renews the lease, determining which computer updates the A
and PTR RRs of the client. Depending on the negotiation process, the DHCP client, the DHCP
server, or both, update the records by sending the dynamic update requests to the primary DNS
servers that are authoritative for the names that are to be updated.
Clients and servers that are running versions of Windows earlier than Windows 2000 do not
support dynamic update. The Windows Server 2008 DHCP Server service can perform dynamic
updates on behalf of clients that do not support the DHCP Client service FQDN option (which is
described in the following section). For example, clients that are running Microsoft
Windows® 95, Windows 98, and Windows NT do not support the FQDN option. However, this
functionality can be enabled in the DNS tab of the server properties for the DHCP console. The
DHCP server first obtains the name of legacy clients from the DHCP REQUEST packet. It then
appends the domain name given for that scope and registers the A and PTR RRs.
In some cases, stale PTR or A RRs can appear on DNS servers when the lease of a DHCP client
expires. For example, when a DHCP client running Windows Vista® or Windows Server 2008
tries to negotiate a dynamic update procedure with a DHCP server running Windows NT 4.0, the
DHCP client must register both A and PTR RRs itself. Later, if the client running Windows 2000 is
improperly removed from the network, the client cannot deregister its A and PTR RRs and they
become stale.
If a stale A RR appears in a zone that allows only secure dynamic updates, no computer is able
to register any other RR for the name in that A RR. To prevent problems with stale PTR and A
RRs, you can enable the aging and scavenging feature. For more information about the aging
and scavenging feature, see “Understanding aging and scavenging” in this topic.
To provide fault tolerance for dynamic updates, consider Active Directory integration for those
zones that accept dynamic updates from Windows Server 2008 network-based clients. To speed
up the discovery of authoritative DNS servers, you can configure each client with a list of
preferred and alternate DNS servers that are primary for that directory-integrated zone. If a
client fails to update the zone with its preferred DNS server because the DNS server is
unavailable, the client can try an alternate server. When the preferred DNS server becomes
available, it loads the updated, directory-integrated zone that includes the update from the
client.
Dynamic update process for network connections configured by DHCP
To negotiate the dynamic update process, the DHCP client sends its FQDN to the DHCP server
in the DHCPREQUEST packet by using the DHCP Client service FQDN option. The DHCP server
then replies to the DHCP client by sending a DHCP acknowledgment (DHCPACK) message that
includes the FQDN option (option code 81).
The following table lists the fields of the FQDN option of the DHCPREQUEST packet.
Fields in the FQDN option of the DHCPREQUEST packet
Field Explanation

Code Specifies the code for this option (81).

Len Specifies the length, in octets, of this option (minimum of 4).

Flags Can be one of the following values:


0. Client wants to register the A RR and requests that the server update the PTR RR
1. Client wants server to register the A and PTR RRs.
3. DHCP server registers the A and PTR RRs regardless of the request of the client.

RCODE1 and The DHCP server uses these fields to specify the response code from the A and PTR
RCODE 2 and to indicate whether it attempted the update before sending DHCPACK.

Domain Name Specifies the FQDN of the client.


The conditions under which DHCP clients send the FQDN option and the actions taken by DHCP
servers depend on the operating system that the client and server are running and how the
client and server are configured.
The client requests a dynamic update depending on whether it is running Windows Server 2008
or earlier. It also depends on the client configuration. Clients can take any of the following
actions:

 By default, the Windows Server 2008 DHCP Client service sends the FQDN option with
the Flags field set to 0 to request that the client update the A RR, and the DHCP Server
service updates the PTR RR. After the client sends the FQDN option, it waits for a
response from the DHCP server. Unless the DHCP server sets the Flags field to 3, the
client then initiates an update for the A RR. If the DHCP server does not support or is
not configured to perform registration of the DNS record, then no FQDN is included in
the DHCP server’s response and the client attempts registration of the A and PTR RRs.

 If the DHCP client is running a Windows operating system earlier than Windows 2000, or
if the client is Windows 2000 and it is configured not to register DNS resource records,
then the client does not send the FQDN option. In this case, the client does not update
either record.

Depending on what the DHCP client requests, the DHCP server can take different actions. If the
DHCP client sends a DHCPREQUEST message without the FQDN option, behavior depends on
the type of DHCP server and how it is configured. The DHCP server can update both records if it
is configured to update records on behalf of DHCP clients that do not support the FQDN option.
In the following cases, the DHCP server does not perform any action:

 The DHCP server (for example, a server running Windows NT 4.0) does not support
dynamic update.

 The DHCP server is running Windows Server 2008 and is configured not to do dynamic
updates for clients that do not support the FQDN option.
 The DHCP server is running Windows Server 2008 and is configured not to register DNS
resource records.

If the Windows network–based DHCP client requests that the server updates the PTR RR but not
the A RR, behavior depends on the type of DHCP server and how it is configured.The server can
perform any of the following actions:

 If the DHCP server is running Windows Server 2008 and is configured not to perform
dynamic updates, its response does not contain the FQDN option and does not update
either RR. In this case, the DHCP client attempts to update both the A and PTR RRs, if it
capable.

 If the DHCP server is running Windows Server 2008 and is configured to update
according to the request of the DHCP client, the server attempts to update the PTR
RR. The DHCP server DHCPACK message to the DHCP client contains the FQDN option
with the Flags field set to 0, confirming that the DHCP server updates the PTR
record. The DHCP client then attempts to update the A RR, if it is capable.

If the DHCP server is running Windows Server 2008 and is configured to always update A and
PTR both records, the DHCP server attempts to update both RRs. The DHCP server DHCPACK
message to the DHCP client contains the FQDN option with the Flags field set to 3, notifying the
DHCP client that the DHCP server updates A and PTR records. In this case, the DHCP client does
not attempt to update either RR.
Dynamic update process for statically configured and remote access
clients
Statically configured clients and remote access clients do not rely on the DHCP server for DNS
registration. Statically configured clients dynamically update their A and PTR RRs every time they
start and then every 24 hours in case the records become corrupted or need to be refreshed in
the DNS database.
Remote access clients can dynamically update A and PTR RRs when a dial-up connection is
made. They can also attempt to withdraw, or deregister, the A and PTR RRs when the user closes
down the connection explicitly. Computers running Windows Server 2008 with a remote access
network connection attempt the dynamic registration of the A and PTR records corresponding
to the IP address of this connection. By default, the DNS Client service on Windows XP does not
attempt dynamic update over a remote access or VPN connection. To modify this configuration,
you can modify the advanced TCP/IP settings of the particular network connection or modify the
registry.
In all operating systems, if a remote access client does not receive a successful response from
the attempt to deregister a DNS resource record, or if for any other reason fails to deregister a
resource record within four seconds, the DNS client closes the connection. In such cases, the
DNS database might contain a stale record.
If the remote access client fails to deregister a DNS resource record, it adds a message to the
event log, which you can view by using Event Viewer. The remote access client never deletes
stale records, but the remote access server attempts to deregister the PTR RR when the client is
disconnected.
By default, Windows Server 2008 DNS Client service dial-up networking clients do not attempt
to update A and PTR records automatically. Due to the nature of their business, it is common
that ISPs do not enable dynamic updating of DNS information by their customers. If you use an
ISP that does not support dynamic update, configure the connection properties to prevent the
computer from performing dynamic updates.
Dynamic update process for multihomed clients
If a dynamic update client is multihomed (has more than one network connection and
associated IP address), it registers all IP addresses for each network connection. If you do not
want it to register these IP addresses, you can configure the network connection to not register
IP addresses.

Important

This behavior was changed in Windows Server 2008. Previously, a multihomed client would register only the first
default. For more information, see Microsoft Knowledge Base article 975808.

The dynamic update client does not register all IP addresses with the DNS servers in all
namespaces that the computer is connected to. For example, a multihomed computer,
client1.noam.example.com, is connected to both the Internet and the corporate intranet. Client1
is connected to the intranet by adapter A, a DHCP adapter with the IP address
172.16.8.7. Client1 is also connected to the Internet by adapter B, a remote access adapter with
the IP address 10.3.3.9. Client1 resolves intranet names by using a name server on the intranet,
NoamDC1, and resolves Internet names by using a name server on the Internet, ISPNameServer.
Time to Live
Whenever a dynamic update client registers in DNS, the associated A and PTR RRs include the
Time to Live (TTL), which by default is set to 10 minutes for records registered by the Net Logon
service, and 15 minutes for records registered by the DHCP Client service. If the DNS Server
service dynamically registers records for its own zones, the default TTL is 20 minutes. You can
change the default setting in the registry. A small value causes cached entries to expire sooner,
which increases DNS traffic but decreases the risk of cached records becoming
outdated. Expiring entries quickly is useful for computers that frequently renew their DHCP
leases. Long retention times are useful for computers that renew their DHCP leases infrequently.
Resolving name conflicts
When the DNS Client service attempts to register an A record and it discovers that the
authoritative DNS zone already contains an A record for the same name but with a different IP
address, by default, the DNS Client service attempts to replace the existing A record (or records)
with the new A record containing the IP address of the DNS client. As a result, any computer on
the network can modify the existing A record unless secure dynamic update is used. Zones that
are configured for secure dynamic update allow only authorized users to modify the resource
record.
You can change the default setting so that the DNS Client service ends the registration process
and logs the error in Event Viewer, instead of replacing the existing A record.
Secure dynamic update
DNS update security is available only for zones that are integrated into Active Directory. When
you integrate a zone into Active Directory, access control list (ACL) editing features are available
in the DNS console so you can add or remove users or groups from the ACL for a specified zone
or resource record. ACLs are for DNS administration access control only, and do not influence
DNS query resolution.
By default, dynamic update security for DNS servers and clients are handled as follows:

 DNS clients attempt to use unsecured dynamic update first. Si se rechaza una
actualización no segura, los clientes intentan utilizar la actualización segura.
Además, los clientes usan una directiva de actualización que les permite intentar
sobrescribir un registro de recursos previamente registrado, a menos que estén
bloqueados específicamente por la actualización de seguridad.

 Después de una zona pasa a ser integrada en Active Directory, servidores DNS que
ejecutan Windows Server 2008 (predeterminado) para permitir sólo actualizaciones
dinámicas seguras.

Cuando se utiliza el almacenamiento de información de zona estándar, el valor


predeterminado para el servicio servidor DNS es no permitir actualizaciones dinámicas
en sus zonas. Para las zonas que están integrados en el directorio o utilice el
almacenamiento estándar basado en archivo, puede cambiar la zona para permitir
actualizaciones dinámicas, lo que permite todas las actualizaciones que se acepten.

Actualización dinámica es una reciente adicional especificación estándar DNS, definida


en RFC 2136. Para obtener más información acerca de RFC, consulte Información de
referencia DNS .

El registro dinámico de registros de recursos DNS se puede restringir el uso de las


entradas del registro.

Cómo funciona la actualización dinámica segura


El proceso de actualización dinámica segura se describe como sigue:

 Para iniciar una actualización dinámica segura, el cliente DNS primero inicia el proceso
de negociación de contexto de seguridad durante el cual los símbolos se pasan entre
cliente y servidor mediante TKEY RR. Al final del proceso de negociación, se establece el
contexto de seguridad.

 A continuación, el cliente DNS envía la solicitud de actualización dinámica (que contiene


los registros de recursos de agregar, eliminar o modificar datos) al DNS server, firmado
utilizando el contexto de seguridad previamente establecidos y pasar la firma en el
registro de recursos TSIG, incluido en el paquete de actualización dinámica.

 El servidor intenta actualizar Active Directory mediante las credenciales del cliente y
envía el resultado de la actualización al cliente. Estos resultados están firmados con el
contexto de seguridad y pasan la firma en el RR TSIG incluido en la respuesta.

Proteger el proceso de actualización dinámica


El proceso de actualización dinámica segura se describe como sigue:

1. El cliente DNS consulta el servidor DNS preferido para determinar qué servidor DNS
está autorizado para el nombre de dominio está intentando actualizar. El servidor DNS
preferido responde con el nombre de la zona y el servidor DNS principal que está
autorizado para la zona.

2. El cliente DNS intenta una actualización dinámica estándar y, si la zona está configurada
para permitir sólo actualizaciones dinámicas seguras (la configuración predeterminada
para las zonas integradas en Active Directory), el servidor DNS rechaza la actualización
no segura. Si la zona se ha configurado para actualización dinámica estándar en lugar
de actualización dinámica segura, el servidor DNS hubiera aceptado intento del cliente
DNS para agregar, eliminar o modificar registros de recursos de esa zona.

3. El cliente DNS y el servidor DNS iniciar la negociación de TKEY.

4. En primer lugar, el cliente DNS y el servidor DNS negocian un mecanismo de seguridad


subyacente. Los clientes de actualización dinámica de Windows y DNS servidores puede
sólo puede usar el protocolo Kerberos.

5. A continuación, mediante el mecanismo de seguridad, el cliente DNS y el servidor DNS


verificación sus identidades respectivas y establecer el contexto de seguridad.

6. El cliente DNS envía la solicitud de actualización dinámica al servidor DNS, firmado


utilizando el contexto de seguridad establecidos. La firma se incluye en el campo de
firma del RR TSIG que se incluye en el paquete de solicitud de actualización dinámica. El
servidor DNS comprueba el origen del paquete de actualización dinámica utilizando el
contexto de seguridad y la firma TSIG.

7. El servidor DNS intenta agregar, eliminar o modificar registros de recursos en Active


Directory. O no puede realizar la actualización depende de si el cliente DNS tiene los
permisos adecuados para realizar la actualización y si se han satisfecho los requisitos
previos.

8. El servidor DNS envía una respuesta al cliente DNS que indica si se puede realizar la
actualización, firmada mediante el contexto de seguridad establecidos. La firma se
incluye en el campo de firma del RR TSIG que se incluye en el paquete de respuesta de
actualización dinámica. Si el cliente DNS recibe una respuesta falsa, lo ignora y espera
una respuesta firmada.

Seguridad para los clientes DHCP que no admiten la opción FQDN


Los clientes DHCP de Windows que no admiten la opción FQDN (opción 81) no son capaces de
actualizaciones dinámicas. Si desea que los registros a y PTR para estos clientes que se registran
dinámicamente en DNS, debe configurar el servidor DHCP para realizar actualizaciones
dinámicas en su nombre.
Sin embargo, que el servidor DHCP para realizar actualizaciones dinámicas seguras en nombre
de los clientes DHCP que no admiten la opción de FQDN es indeseable porque cuando un
servidor DHCP realiza una actualización dinámica segura en un nombre, que el servidor DHCP se
convierte en el propietario de ese nombre y sólo este servidor DHCP puede actualizar cualquier
registro para ese nombre. Esto puede causar problemas en algunas circunstancias.
Por ejemplo, suponga que el servidor DHCP DHCP1 creó un objeto para el
nt4host1.example.com de nombre y después dejó de responder, y que posteriormente el
servidor DHCP, DHCP2, intentó actualizar un registro para el mismo nombre,
nt4host1.example.com. En esta situación, DHCP2 no es capaz de actualizar el nombre porque no
posee el nombre. En otro ejemplo, suponga que DHCP1 ha agregado un objeto para el
nt4host1.example.com de nombre y, a continuación, el administrador ha actualizado
nt4host1.example.com a un equipo basado en Windows 2000. Porque el equipo basado en
Windows 2000 no posee el nombre, no sería capaz de actualizar los registros DNS para el
nombre.
Para resolver este problema, se proporciona el grupo de seguridad integrado denominado
DnsUpdateProxy. Si se agregan todos los servidores DHCP como miembros del grupo
DnsUpdateProxy, registros de un servidor pueden actualizarse por otro servidor si se produce
un error en el primer servidor. Además, como todos los objetos creados por los miembros del
grupo DnsUpdateProxy no están protegidos, el primer usuario (que no es un miembro del
grupo DnsUpdateProxy) para modificar el conjunto de registros asociados con un DNS el
nombre, se convierte en su propietario. Cuando se actualizan los clientes antiguos, por lo tanto,
puede tomar posesión de sus registros de nombres en el servidor DNS. Si todos los servidores
DHCP registrar registros de recursos de clientes antiguos es un miembro del grupo
DnsUpdateProxy, se eliminan los problemas comentados anteriormente.
Protección de los registros mediante el grupo DnsUpdateProxy
Los nombres de dominio DNS registrados por el servidor DHCP no son seguros cuando el
servidor DHCP es un miembro del grupo DnsUpdateProxy. Como resultado, no utilice este
grupo en una zona Active Directory integrado-que permite sólo actualizaciones dinámicas
seguras sin tomar medidas adicionales para permitir que los registros creados por miembros del
grupo para protegerse.
Para proteger contra registros no protegidos, o para permitir a los miembros del grupo
DnsUpdateProxy registren registros en zonas que permitir sólo actualizaciones dinámicas
seguras, DNS y DHCP de Windows Server 2008 le permiten crear una cuenta de usuario
dedicada y configurar servidores DHCP para realizar actualizaciones dinámicas de DNS con las
credenciales de cuenta de usuario (nombre de usuario, contraseña y dominio). Las credenciales
de cuenta dedicado de un usuario pueden utilizarse en varios servidores DHCP.
La cuenta de usuario dedicada es una cuenta de usuario estándar que se utiliza sólo para
proporcionar servidores DHCP con las credenciales para el registro de actualización dinámica de
DNS. Cada servidor DHCP proporcionará estas credenciales al actualización de registrar los
nombres de los clientes DHCP con DNS dinámico. La cuenta de usuario dedicada se crea en el
mismo bosque donde reside el servidor DNS principal para la zona que se actualizará. La cuenta
de usuario dedicada también se encuentra en otro bosque siempre y cuando el bosque reside
en tiene una confianza de bosque establecida con el bosque que contiene el servidor DNS
principal para la zona que se actualizará.
Cuando está instalado en un controlador de dominio, el servicio servidor DHCP hereda los
permisos de seguridad del controlador de dominio y tiene autoridad para actualizar o eliminar
cualquier registro DNS que está registrado en una zona segura integrada en Active Directory
(incluidos los registros que se registraron de forma segura por otros equipos que ejecutan
Windows Server 2008, incluidos los controladores de dominio). Cuando está instalado en un
controlador de dominio, configure el servidor DHCP con las credenciales de la cuenta de usuario
dedicada para evitar que el servidor de heredar y posiblemente utilice incorrectamente, el poder
del controlador de dominio.
Configurar una cuenta de usuario dedicada y configurar el servicio servidor DHCP con las
credenciales de cuenta en las siguientes circunstancias:

 Un controlador de dominio está configurado para funcionar como un servidor DHCP.

 El servidor DHCP está configurado para realizar actualizaciones dinámicas de DNS en


nombre de los clientes DHCP.

 Las zonas DNS para actualizar el servidor DHCP están configuradas para permitir sólo
actualizaciones dinámicas seguras.

Una vez haya creado una cuenta de usuario dedicada, puede configurar servidores DHCP con las
credenciales de cuenta de usuario mediante la consola DHCP o mediante el comando Netsh
(netsh dhcp server set dnscredentials).
Nota

 Si las credenciales proporcionadas pertenecen a un objeto (como, por ejemplo, un equipo) que es miemb
siguiente objeto para registrar el mismo registro de nombre en DNS se convertirá en propietario del regi

 Si ha especificado las credenciales (nombre de usuario, dominio y contraseña) que utiliza el servidor DHC
estas credenciales no se copiarán con copia de seguridad sincrónica o asincrónica. Después de restaura u
nuevas credenciales.

Controlar el acceso de actualización a las zonas y nombres


Se controla el acceso a las zonas DNS y registros de recursos almacenados en Active Directory
ACL. Las ACL pueden especificarse para el servicio de servidor DNS, toda una zona o para
nombres DNS específicos. De forma predeterminada, cualquier usuario autenticado de Active
Directory puede crear a los RR PTR en cualquier zona. Después de un propietario nombre ha
sido creado para una zona (independientemente del tipo de registro de recursos), sólo los
usuarios o grupos especificados en la ACL para ese nombre que tienen permiso de escritura
están habilitados para modificar los registros correspondientes a ese nombre. Aunque este
enfoque es deseable en la mayoría de los casos, algunas situaciones especiales deben
considerarse de forma independiente.
Grupo DNSAdmins
De forma predeterminada, el grupo DNSAdmins tiene control total de todas las zonas y
registros en el dominio de Windows Server 2008 en el que se especifica. Para que un usuario
pueda enumerar las zonas de un dominio específico de Windows Server 2008, el usuario (o un
grupo al que pertenece el usuario) debe estar inscrito en el grupo DNSAdmin.
Es posible que un administrador de dominio que no desee conceder control total a todos los
usuarios enumerados en el grupo DNSAdmins. Normalmente, esto sería el resultado si un
administrador de dominio que desea conceder control total para una zona específica y control
de sólo lectura para las demás zonas en el dominio de un conjunto de usuarios. Para ello, el
Administrador de dominio puede crear un grupo independiente para cada una de las zonas y
agregar usuarios específicos a cada grupo. A continuación, la ACL para cada zona contendrá un
grupo con control total para esa zona sólo. Al mismo tiempo, todos los grupos se incluirán en el
grupo DNSAdmins, que se puede configurar para disponer de permisos de sólo lectura. Como
consecuencia de hechos que ACL de una zona siempre contiene el grupo DNSAdmins, todos los
usuarios incluidos en los grupos específicos de la zona tendrán permiso de lectura para todas
las zonas en el dominio.
Reservar nombres
La configuración del servicio de servidor DNS predeterminado de permitir que cualquier usuario
autenticado crear un nuevo nombre en una zona no puede ser suficiente para entornos que
requieren un alto nivel de seguridad. En tales casos, la ACL predeterminada puede cambiarse
para permitir la creación de objetos en una zona a ciertos grupos de usuarios. Nombre de
administración de las ACL proporciona otra solución para este problema. Un administrador
puede reservar un nombre en una zona con el resto de la zona abierto para la creación de los
objetos por todos los usuarios autenticados. Para ello, un administrador crea un registro para el
nombre reservado y establece la lista adecuada de grupos o usuarios de la ACL. Como
resultado, sólo los usuarios enumerados en la ACL podrán registrar otro registro con el nombre
reservado.
Descripción de la caducidad y borrado
Los servidores DNS de Windows Server 2008 admiten características de compactación y
caducidad. Estas características se proporcionan como mecanismo para realizar la limpieza y
eliminación de registros de recursos obsoletos, que se pueden acumular en datos de zona con
el tiempo.
Con la actualización dinámica, los registros de recursos se agregan automáticamente a zonas
cuando los equipos se inician en la red. Sin embargo, en algunos casos, no se quitan
automáticamente cuando los equipos abandonan la red. Por ejemplo, si un equipo registra su
propio host (A) RR al inicio y luego no se desconecta de la red, no se puede eliminar su host (A)
RR. Si la red tiene usuarios y equipos móviles, esta situación puede producirse con frecuencia.
Si no, la presencia de RR obsoletos en los datos de zona puede causar algunos problemas. Los
siguientes son ejemplos:

 Si un gran número de RR obsoletos permanece en las zonas del servidor, eventualmente


pueden ocupar espacio de disco del servidor y causar transferencias de zona
innecesariamente largas.

 Servidores DNS que cargan zonas con RR obsoletos podrían utilizar información
obsoleta para responder a consultas de cliente, puedan causar los clientes experimenten
problemas de resolución de nombres en la red.

 La acumulación de RR obsoletos en el servidor DNS puede degradar su rendimiento y


capacidad de respuesta.

 En algunos casos, la presencia de un RR obsoleto en una zona podría impedir que un


nombre de dominio DNS se está utilizando otro equipo o dispositivo host.

Para resolver estos problemas, el servicio servidor DNS tiene las siguientes características:

 Marca de tiempo, según la fecha actual y la hora establecida en el equipo servidor,


cualquier registro de recursos agregado dinámicamente a zonas de tipo
principal.Además, las marcas de tiempo se registran en las zonas principales estándar
donde está habilitada la compactación y caducidad.

 Para los registros de recursos que se agregan manualmente, se utiliza un valor de marca
de tiempo de cero, indicando que no se ven afectados por el proceso de caducidad y
pueden permanecer sin limitaciones en los datos de zona a menos que se cambien sus
marcas de tiempo o eliminarlos.

 Caducidad de registros de datos locales, basados en una período de tiempo, para


cualquier zona elegible de actualización especificado. Zonas de tipo principal que se
cargan mediante el servicio servidor DNS son elegibles para participar en este proceso.

 Borrado de cualquier registro de recursos que persiste más allá del período de
actualización especificado. Cuando un servidor DNS realiza una operación de
compactación, puede determinar que los registros de recursos han caducado hasta el
punto de convertirse en obsoletos y eliminarlos de datos de zona. Los servidores se
pueden configurar para realizar automáticamente operaciones de compactación
repetitivas o se puede iniciar una operación de compactación inmediata en el servidor.
Nota

De forma predeterminada, el mecanismo de caducidad y borrado para el servicio servidor DNS está desh
todos los parámetros. De lo contrario, el servidor podría configurar accidentalmente para eliminar regist
accidentalmente, no sólo los usuarios no se resolverán consultas para ese registro, pero cualquier usuari
en zonas configuradas para actualizaciones dinámicas seguras.

El servidor utiliza el contenido de cada marca de tiempo de RR específicos, junto con otras y las
propiedades de compactación que se pueden ajustar o configurar, para determinar cuándo
compactar los registros.
Requisitos previos para la caducidad y borrado
Antes de que se pueden utilizar la caducidad y borrado de DNS, deben cumplirse varias
condiciones:

1. Caducidad y el borrado deben habilitarse en el servidor DNS y en la zona.

De forma predeterminada, la caducidad y borrado de registros de recursos está


deshabilitada.

2. Registros de recursos se deben agregar dinámicamente a las zonas o modificarse


manualmente para utilizarse en operaciones de compactación y.

Normalmente, sólo los registros de recursos que se agregan dinámicamente mediante el


protocolo de actualización dinámica de DNS se están sujetos a la caducidad y borrado.
Sin embargo, puede habilitar la compactación de otros registros de recursos agregados a través
de medios no dinámicos. Para los registros agregados a las zonas de esta manera, cargando un
archivo de zona basada en texto de otro servidor DNS o agregarlos manualmente a una zona, se
establece una marca de tiempo de cero. Esto hace que estos registros no válido para uso en
operaciones de compactación y.
Para cambiar este valor predeterminado, puede administrar estos registros individualmente,
para restablecer y permitirles usar un valor de marca de tiempo actual (no cero). Esto permite
que estos registros se convierten en caducar y ser borrado.

Nota

En el caso de una zona se cambie de principal estándar a integrada en Active Directory, es posible que desee hab
zona.Para habilitar la caducidad para todos los registros existentes en una zona, puede utilizar el comando AgeA
herramienta de línea de comandos dnscmd.

De compactación y terminología
La siguiente lista indica nuevos o revisados términos que se han introducido para
específicamente tratar de caducidad y borrado.
Hora actual del servidor La fecha y hora actuales en el servidor DNS. Este número se puede
expresar como un valor numérico exacto en cualquier punto en el tiempo.
Intervalo sin actualización Un intervalo de tiempo, determinado para cada zona, limitado por
los dos sucesos siguientes:

 Valor de marca de la fecha y hora cuando el registro se actualizó por última vez y su
tiempo.

 Restablecer de la marca de fecha y hora cuando el registro vuelve seleccionable para


actualizarse y su tiempo.

Este valor es necesario para reducir el número de operaciones de escritura a la base de datos de
Active Directory. De forma predeterminada, este intervalo se establece en siete días. No se
deben aumentar para un nivel excesivamente alto, porque los beneficios de la función de
compactación y podrían perder o disminuidos.
Actualizar registro Cuando se procesa una actualización dinámica de DNS para un registro de
recursos cuando sólo la registro de recursos sello de tiempo y no otras características del
registro, se revisan. Actualizaciones suelen deberse a los siguientes motivos:

 Cuando se reinicia un equipo en la red y, si en el inicio, su nombre y la información de


dirección IP son coherentes con el mismo nombre y la información de dirección que
utilizó antes de apagarse, envía una actualización para renovar sus registros de recursos
asociados para obtener esta información.

 El equipo envía una actualización periódica mientras se está ejecutando.

 El servicio de Windows XP y Windows Server 2008 DNS cliente renueva el registro DNS
de los registros de recursos de cliente cada 24 horas. Cuando se produce esta
actualización dinámica, si la solicitud de actualización dinámica no produce una
modificación a la base de datos DNS, se considera una actualización y no una
actualización de registro de recursos.

 Otros servicios de red realizan intentos de actualización, tales como servidores DHCP,
que renovación concesiones de direcciones de cliente;servidores en cluster, que
registran y actualizan registros para un clúster;y el servicio Net Logon, que puede
registrar y actualizar registros de recursos utilizados por los controladores de dominio
de Active Directory.

Actualizar registro Cuando una dinámica de DNS se procesa actualización para un registro de
recursos donde se revisan otras características de registro, además de su marca de tiempo. Las
actualizaciones suelen deberse a los siguientes motivos:

 Cuando se agrega un nuevo equipo a la red y, en el inicio, envía una actualización para
registrar sus registros de recursos por primera vez con su zona configurada.

 Cuando un equipo con registros existentes en la zona tiene un cambio en la dirección


IP, lo que se envíen actualizaciones para sus asignaciones de nombre a dirección
revisadas en datos de zona DNS.

 Cuando el servicio Net Logon registra un nuevo controlador de dominio de Active


Directory.
Intervalo de actualización Un intervalo de tiempo, determinado para cada zona, limitado por
los dos sucesos siguientes:

 Restablecer de la marca de la primera fecha y hora cuando el registro pasa a ser


seleccionable para actualizarse y su tiempo.

 La primera fecha y hora en que se pueden ser compactarse y quitarse de la base de


datos de zona el registro.

Este valor debe ser lo suficientemente grande como para permitir que todos los clientes
actualizar sus registros. De forma predeterminada, este intervalo se establece en siete días. No
se deben aumentar para un nivel excesivamente alto, porque los beneficios de la función de
compactación y podrían perder o disminuidos.
Marca de tiempo del registro de recursos Un valor de fecha y hora utilizado por el servidor
DNS para determinar cuando realiza operaciones de compactación y la eliminación del registro
de recursos.
Período de limpieza Cuando la compactación automática está habilitada en el servidor, este
período representa el tiempo entre las repeticiones del proceso de compactación automática. El
valor predeterminado es siete días. Para prevenir el deterioro del rendimiento del servidor DNS,
el valor mínimo permitido para esta es una hora.
Servidores de compactación Un parámetro de zona avanzado y opcional que permite
especificar una lista restringida de direcciones IP para servidores DNS que están habilitados para
realizar la compactación de la zona. De forma predeterminada, si no se especifica este
parámetro, todos los servidores DNS que cargan una zona integrada de directorio (también
habilitada para la compactación) intentan realizar la compactación de la zona. En algunos casos,
este parámetro puede ser útil si es preferible que se realice la compactación sólo en algunos
servidores que cargan la zona integrada de directorio. Para establecer este parámetro, debe
especificar la lista de direcciones IP para los servidores habilitados para la zona en el parámetro
ScavengingServers de la zona. Esto puede hacerse mediante el comando dnscmd, una línea de
comandos herramienta basada en para administrar servidores DNS de Windows.
Iniciar el borrado de tiempo Una hora específica, expresada como un número. Este tiempo es
utilizado por el servidor para determinar cuándo una zona está disponible para la compactación.
Cuándo puede empezar el borrado
Una vez cumplidos todos los requisitos previos para habilitar el uso de la compactación, puede
empezar el borrado de una zona de servidor cuando la hora actual del servidor es mayor que el
valor de inicio de tiempo para la zona de compactación.
El servidor establece el valor de tiempo para iniciar el borrado por zona siempre que se produce
uno de los siguientes eventos:

 Actualizaciones dinámicas están habilitadas para la zona.

 Se aplica un cambio en el estado de la casilla de verificación Compactar registros de


recursos obsoletos . Puede utilizar la consola DNS para modificar esta configuración en
un servidor DNS aplicable o en uno de sus zonas principales.

 El servidor DNS carga una zona principal habilitada para utilizar la compactación. Esto
puede ocurrir cuando se inicia el equipo servidor o cuando se inicia el servicio de
servidor DNS.

 Cuando una zona reanuda el servicio después de haberse pausado.


Cuando se produce alguno de los eventos anteriores, el servidor DNS establece el valor de inicio
de borrado de tiempo mediante el cálculo de la siguiente suma:
Hora actual del servidor + intervalo de actualización = tiempo de compactación inicial
Este valor se utiliza como base de comparación durante las operaciones de borrado.
Ejemplo del proceso de caducidad y borrado de un registro de ejemplo
Para entender el proceso de caducidad y borrado en el servidor, tenga en cuenta el tiempo de
vida y los pasos sucesivos de un solo registro de recursos, se agrega a un servidor y la zona
donde este proceso es en efecto y, a continuación, por antigüedad y quita de la base de datos.

1. Un host DNS de ejemplo, "host-a.ejemplo.Microsoft.com", registra su host (A) RR en el


servidor DNS de una zona donde se puede utilizar la caducidad y borrado.

2. Al registrar el registro, el servidor DNS coloca una marca de tiempo en este registro
basada en la hora actual del servidor.

Después de escribir la marca de tiempo del registro, el servidor DNS no acepta


actualizaciones para este registro durante el intervalo de la zona sin actualización. Sin
embargo, puede aceptar actualizaciones antes de ese momento. Por ejemplo, si la
dirección IP para los cambios de "host-a.ejemplo.Microsoft.com", el servidor DNS puede
aceptar la actualización. En este caso, el servidor también actualiza (restablece) la hora
de registro marca.

3. Una vez transcurrido el período sin actualización, el servidor comienza a aceptar


intentos para actualizar este registro.

Tras la finalización del período sin actualización inicial, el período de actualización


inmediatamente comienza el registro de. Durante este tiempo, el servidor no suprime
los intentos para actualizar el registro de su tiempo de vida restante.

4. Durante y después del período de actualización, si el servidor recibe una actualización


para el registro, la procesa.

Esto restablece la marca de tiempo para el registro según el método descrito en el paso
2.

5. Cuando se realiza la compactación subsiguiente por el servidor para la zona


"ejemplo.Microsoft.com", el registro (y todos los demás registros de zona) examina el
servidor.

Cada registro se compara con la hora actual del servidor de la siguiente suma para
determinar si se debe quitar el registro:

Marca de tiempo de registro + intervalo sin actualización de zona + intervalo de


actualización de zona

o Si el valor de esta suma es mayor que la hora actual del servidor, se realiza
ninguna acción y el registro sigue envejeciendo en la zona.

o Si el valor de esta suma es menor que la hora actual del servidor, se elimina el
registro de los datos de zona actualmente cargados en memoria del servidor y
también del objeto DnsZone aplicable que se almacena en Active Directory para
la zona integrada en el directorio "ejemplo.Microsoft.com".
Compatibilidad con caracteres Unicode
Originalmente, los nombres de host de Internet se restringían al juego de caracteres
especificado en RFC 952 y 1123. Entre ellas incluyen la limitación de nombres para el uso de
mayúsculas y minúsculas (A-"Z", a-z), números (0-9) y guiones (-). Además, el primer carácter del
nombre DNS puede ser un número y los nombres deben codificarse y representan mediante
caracteres basados en US-ASCII.
Estos requisitos se mantuvieron cuando DNS se presentó como parte del documento RFC 1035,
una de las especificaciones de estándares DNS principales. Para utilizar DNS en configuración
internacional, este requisito tiene limitaciones significativas donde se utilizan juegos de
caracteres extendidos para nombres estándar locales.
Para quitar estas limitaciones, Microsoft amplía el soporte de caracteres DNS más allá de la
especificación RFC 1035. El servicio DNS proporciona compatibilidad predeterminada mejorada
con UTF-8, un formato de transformación de Unicode.
¿Qué es UTF-8?
UTF-8 es el conjunto de caracteres recomendado para protocolos que evolucionan a la
utilización de ASCII. El protocolo UTF-8 proporciona compatibilidad con caracteres ASCII
extendidos y traducción de UCS-2, un juego de caracteres Unicode de 16 bits que abarca la
mayoría de los sistemas de escritura del mundo. UTF-8 habilita un intervalo mucho mayor de
nombres que se pueden lograr mediante ASCII o la codificación ASCII extendida de datos de
carácter.
Los equipos que ejecutan Windows Server 2008 son UTF-8. Esto significa que cuando se recibe
o utiliza el servidor de los caracteres codificados en UTF-8, el servidor puede cargar y almacenar
estos datos en sus zonas. Aunque los servidores DNS basados en Windows admiten UTF-8,
mantienen la compatibilidad con otros servidores DNS que utilizan la codificación de datos US-
ASCII tradicional y el estándar DNS actual.
Cómo el servicio DNS implementa UTF-8
Para proporcionar compatibilidad e interoperabilidad con otras implementaciones de DNS, el
servicio DNS utiliza la conversión a minúsculas uniforme de los datos de carácter recibido. En
este proceso, el servicio DNS convierte todos los caracteres en mayúsculas que se utilizan en
datos US-ASCII estándar datos equivalentes en minúsculas para las siguientes razones:

 Para mantener la compatibilidad con los estándares DNS existentes y actuales.

 Para proporcionar interoperabilidad con implementaciones de servidor DNS que no


reconoce o admiten la codificación UTF-8.

Para comprender por qué se eligió la conversión a minúsculas uniforme, varios puntos
relacionados en primer lugar se deben considerar de las normas revisadas de Internet actuales
para DNS. Varios aspectos importantes en las normas aluden directamente a cómo los datos de
caracteres están gestionar entre servidores DNS y otros servidores y clientes. Estas son las
siguientes:

 Cualquier cadena binaria puede utilizarse en un nombre DNS. (RFC 2181)

 Los servidores DNS deben poder comparar nombres de forma entre mayúsculas y
minúsculas. (RFC 1035)

 El caso original de datos de carácter se debe conservar siempre que sea posible que los
datos se especifica en el sistema. (RFC 1035)
Porque minúsculas es una parte necesaria del núcleo del estándar DNS y conservación de
mayúsculas y es una recomendación opcional, se eligió la conversión a minúsculas uniforme
para proporcionar una solución eficaz que cumplen los estándares. Por la conversión a
minúsculas los nombres de codificación UTF-8 antes de la transmisión, otros servidores DNS
(que no admiten UTF-8) son capaces de recibir y realizar comparaciones binarias correctas de
los datos y obtener los resultados deseados.
Consideraciones para la interoperabilidad con UTF-8
El servicio servidor DNS puede configurarse para permitir o impedir el uso de caracteres UTF-8
en por servidor. Aunque otras implementaciones del servidor DNS que no sean UTF-8 puede
aceptar la transferencia de una zona que contiene nombres de codificados UTF-8, es posible
que estos servidores no podrán escribir esos nombres a un archivo de zona o volver a cargarlos
desde un archivo de zona. Los administradores deben tener cuidado al transferir una zona con
nombres UTF-8 a un servidor DNS que no es compatible con UTF-8.
Algunos protocolos restringen los caracteres permitidos en un nombre. Además, los nombres
que pretenden ser visibles globalmente (RFC 1958) deben contener sólo caracteres ASCII, como
se recomienda en RFC 1123.
El uso de UTF-8 para la transformación de caracteres Unicode no es apreciable para usuarios
generales, pero los caracteres codificados en UTF-8 pueden observarse cuando se utiliza el
Monitor de red u otra herramienta similar para analizar tráfico relacionado con DNS a través de
la red física.
Además de servidor DNS admite el formato de codificación UTF-8, el solucionador del cliente
utiliza de forma predeterminada el formato de codificación de caracteres UTF-8.
Los nombres codificados en formato UTF-8 no deben superar los límites de tamaño en el
documento RFC 2181, que especifica un máximo de 63 octetos por etiqueta y 255 octetos por
nombre. Número de caracteres es insuficiente para determinar el tamaño porque algunos
caracteres UTF-8 superan un octeto de longitud.
El protocolo de codificación UTF-8 se adapta para utilizar con implementaciones del protocolo
DNS existentes que esperan caracteres US-ASCII ya que la representación de caracteres US-
ASCII en UTF-8 es idéntica, byte a byte, a la representación US-ASCII. Las implementaciones de
cliente o servidor DNS que no reconocen caracteres UTF-8 siempre codifican los nombres en
formato US-ASCII. El servicio servidor DNS interpreta correctamente dichos nombres.
El servicio DNS proporciona la capacidad de configurar la comprobación de nombre para
permitir o restringir el uso de caracteres UTF-8 en datos DNS.
De forma predeterminada, se utiliza la comprobación de nombres UTF-8 multibyte, lo que
permite la máxima tolerancia cuando el servicio DNS procesa los caracteres. Este es el mejor
método de comprobación de nombres para los servidores DNS más privados que no
proporcionan el servicio de nombres de hosts de Internet.
Integración de la búsqueda WINS
Para utilizar el servicio de nombres Internet de Windows (WINS) es compatible para buscar
nombres DNS que no pueden resolverse mediante la consulta el espacio de nombres de
dominio DNS. Para realizar la búsqueda WINS, dos tipos de registro de recurso específico se
utilizan y se pueden habilitar para cualquier zona cargada mediante el servicio DNS:

 RR WINS, que se puede habilitar para integrar la búsqueda WINS en las zonas de
búsqueda directa

 El RR WINS-R, que se puede habilitar para integrar la solicitud de estado de adaptador


del nodo para las zonas de búsqueda inversa
Registro de recursos WINS
Los servicios WINS y DNS se utilizan para proporcionar resolución de nombres para el espacio
de nombres NetBIOS y el espacio de nombres de dominio DNS, respectivamente.Aunque DNS y
WINS pueden proporcionar un servicio de nombres útil e independiente a los clientes, WINS se
necesita, principalmente para proporcionar compatibilidad con programas que requieren
compatibilidad con nombres NetBIOS y clientes antiguos.
Sin embargo, el servicio DNS puede funcionar con WINS para proporcionar búsquedas de
nombres combinados en ambos espacios de nombres al resolver un nombre de dominio DNS
no se encontró información de zona. Para proporcionar esta interoperabilidad, un nuevo
registro (el registro WINS) se definió como parte del archivo de base de datos de zona.
La presencia de un RR WINS puede indicar al servicio DNS para utilizar WINS para buscar las
consultas directas de nombres de host o nombres que no se encuentran en la base de datos de
zona. Esta funcionalidad es especialmente útil para la resolución de nombres que requieren los
clientes que no son compatibles con WINS (por ejemplo, UNIX) para los nombres de equipos no
registrados con DNS, como los equipos Windows 95 o Windows 98.
Cómo funciona la búsqueda WINS
El siguiente es un ejemplo de un cliente DNS (host-b) consulta su servidor DNS en un intento de
buscar la dirección de otro equipo llamado "host-a.ejemplo.Microsoft.com."
Búsqueda WINS

En el paso 1, el cliente consulta su servidor DNS preferido. En los pasos 2 a 8, el proceso normal
de recursión continúa como el servidor DNS consulta otros servidores DNS en sucesión en
nombre del cliente. Este proceso finaliza en el paso 8, cuando el servidor DNS para la zona
example.microsoft.com se localiza a través de la cadena anterior de respuestas de referencia.
Cuando el servidor DNS para la zona ejemplo.Microsoft.com recibe la consulta para host-a,
busca en su zona configurada para ver si puede encontrar un RR de dirección (A) coincidente. Si
no se encuentra ningún registro y la zona está habilitada para utilizar la búsqueda WINS, el
servidor lo siguiente:

 El servidor DNS separa la parte de host del nombre (host-a) del nombre de dominio
completo de contenido en la consulta DNS.

La parte del nombre de host es la primera etiqueta en el nombre de dominio DNS


consultado antes de que se utiliza un punto en el nombre.
 A continuación, el servidor envía una solicitud de nombre NetBIOS al servidor WINS con
el nombre de host, host-a.

 Si el servidor WINS puede resolver el nombre, devuelve la dirección IP al servidor DNS.

 El servidor DNS compila un RR utilizando la dirección IP resuelta a través del servidor


WINS y devuelve este registro al servidor DNS preferido original que consultó el cliente,
host-b.

 El servidor DNS preferido, a continuación, pasa la respuesta de consulta al cliente


solicitante.

¿Cómo WINS funcionan las búsquedas inversas


También hay un registro WINS-R o entrada de búsqueda inversa WINS que se puede habilitar y
agregar a zonas de búsqueda inversa. Sin embargo, debido a que la base de datos de WINS no
está indizada por dirección IP, el servicio DNS no puede enviar una búsqueda inversa de nombre
a WINS para obtener el nombre de un equipo determinado por su dirección IP.
Debido a que WINS no proporciona la capacidad de búsqueda inversa, en su lugar el servicio
DNS envía una solicitud de estado del adaptador de nodo directamente a la dirección IP
implicada en la consulta inversa DNS. Cuando el servidor DNS obtiene el nombre NetBIOS de la
respuesta de estado del nodo, anexa el nombre de dominio DNS el nombre NetBIOS
proporcionado en la respuesta de estado del nodo y reenvía el resultado al cliente solicitante.

Actualización de sugerencias de raíz


en el servidor DNS
Personas que lo han encontrado útil: 0 de 1 - Valorar este tema

Se aplica a: Windows Server 2008 R2


Puede usar sugerencias de raíz para preparar servidores que sean autoritativos para zonas no
raíz de manera que puedan detectar servidores autoritativos que administren dominios en un
nivel superior o en otros subárboles del espacio de nombres de dominio DNS. Estas sugerencias
de raíz son fundamentales para los servidores que son autoritativos en niveles inferiores del
espacio de nombres a la hora de buscar y encontrar otros servidores bajo estas condiciones.
Para completar este procedimiento, debe pertenecer como mínimo al grupo Administradores o
un grupo equivalente. Vea los detalles relativos al uso correcto de las cuentas y pertenencias a
grupos en http://go.microsoft.com/fwlink/?LinkId=83477.
Para actualizar sugerencias de raíz en el servidor DNS

1. Abra el Administrador de DNS.


2. En el árbol de consola, haga clic en el servidor DNS correspondiente.
¿Dónde?

o DNSapplicable DNS server

3. En el menú Acción, haga clic en Propiedades.


4. Haga clic en la ficha Sugerencias de raíz.
5. Modifique las sugerencias de raíz del servidor como se indica a continuación:
o Para agregar un servidor raíz a la lista, haga clic en Agregar y, a continuación,
especifique el nombre y la dirección IP del servidor que se va a agregar a la
lista.

o Para modificar un servidor raíz en la lista, haga clic en Editar y, a continuación,


especifique el nombre y la dirección IP del servidor que se va a editar en la lista.

o Para eliminar un servidor raíz de la lista, selecciónelo en la lista y, a


continuación, haga clic en Quitar.

o Para copiar sugerencias de raíz de un servidor DNS, haga clic en Copiar desde
servidor y, a continuación, especifique la dirección IP del servidor DNS desde el
que desea copiar una lista de servidores raíz para usarlos en la resolución de
consultas. Estas sugerencias de raíz no sobrescribirán ninguna sugerencia de
raíz existente.

Consideraciones adicionales

 Para abrir el Administrador de DNS, haga clic en Inicio, seleccione Herramientas


administrativas y, a continuación, haga clic en DNS.

Referencias adicionales

 Actualización de sugerencias de raíz

 Información de seguridad para DNS

 Protección del servicio Servidor DNS

Modificar la configuración de la
transferencia de zona
Este tema aún no ha recibido ninguna valoración - Valorar este tema

Actualizado: mayo de 2008


Se aplica a: Windows Server 2008
Puede usar este procedimiento para controlar si una zona del Sistema de nombres de dominio
(DNS) se transferirá a otros servidores y cuáles son los servidores que pueden recibir la
transferencia de zona. Puede completar este procedimiento mediante el complemento
Administrador de DNS o la herramienta de línea de comandos dnscmd.
El mínimo requerido para completar este procedimiento es la pertenencia al
grupo Administradores o un grupo equivalente. Consulte los detalles relativos al uso correcto
de las cuentas y pertenencias a grupos en Grupos predeterminados locales y de
dominio (http://go.microsoft.com/fwlink/?LinkId=83477).

Modificación de la configuración de la transferencia


de zona
 Mediante la interfaz de Windows
 Mediante una línea de comandos

Para modificar la configuración de la transferencia de zona mediante la


interfaz de Windows
1. Abra el Administrador de DNS. Para abrir el Administrador de DNS, haga clic en Inicio,
seleccione Herramientas administrativas y, a continuación, haga clic en DNS.
2. Haga clic con el botón secundario en una zona DNS y, a continuación, haga clic
en Propiedades.
3. En la ficha Transferencias de zona, realice una de las acciones siguientes:
o Para deshabilitar las transferencias de zona, desactive la casilla Permitir
transferencias de zona.

o Para permitir las transferencias de zona, active la casilla Permitir transferencias


de zona.

4. Si ha permitido las transferencias de zona, realice una de las acciones siguientes:


o Para permitir las transferencias de zona a cualquier servidor, haga clic en A
cualquier servidor.

o Para permitir transferencias de zona solo a los servidores DNS que aparecen en
la ficha Servidores de nombres, haga clic en Sólo a los servidores
nombrados en la ficha Servidores de nombres.

o Para permitir transferencias de zona solo a servidores DNS específicos, haga clic
en Sólo a los siguientes servidores y, a continuación, agregue la dirección IP
de uno o más servidores DNS.

Consideraciones adicionales

 Para aumentar la seguridad de la infraestructura DNS, permita transferencias de zona


solo para los servidores DNS de los registros de recursos de servidor de nombres (NS)
para una zona o para servidores DNS especificados. Si permite que cualquier servidor
DNS realice una transferencia de zona, permitirá que se transmita información de la red
interna a cualquier host que pueda tener contacto con el servidor DNS.

Para modificar la configuración de la transferencia de zona mediante


una línea de comandos
1. Abra un símbolo del sistema Para abrir la ventana elevada del símbolo del sistema, haga
clic en Inicio, seleccione Todos los programas, Accesorios, haga clic con el botón
secundario en Símbolo del sistema y, a continuación, haga clic en Ejecutar como
administrador.
2. Escriba el siguiente comando en el símbolo del sistema y presione ENTRAR:
3. dnscmd <nombreDeServidor> /ZoneResetSecondaries <nombreDeZona>
{/NoXfr | /NonSecure | /SecureNs | /SecureList
[<direcciónIPSecundaria...>]}

Parámetro Descripción
dnscmd Herramienta de línea de comandos para administrar servidores DNS.

<nombreDeServidor> Obligatorio. Especifica el nombre de host DNS del servidor DNS. Además, p
especificar el servidor DNS en el equipo local, también puede escribir un pun

/ZoneResetSecondaries Especifica una lista de direcciones IP a las que un servidor maestro responde

<nombreDeZona> Obligatorio. Especifica el nombre de dominio completo (FQDN) de la zona.

/NoXfr Deshabilita las transferencias de zona para la zona.

/NonSecure Permite transferencias de zona a cualquier servidor DNS.

/SecureNs Permite las transferencias de zona solo a servidores DNS que figuran como in
servidor de nombres (NS).

/SecureList Permite las transferencias de zona solo a servidores DNS que especifica direc

<direcciónIPSecundaria> Obligatorio, si se especifica /SecureList. Lista de una o más direcciones IP p


transferencias de zona.
Para ver la sintaxis completa de este comando, escriba lo siguiente en el símbolo del sistema y
presione ENTRAR:
dnscmd /ZoneResetSecondaries /?
Consideraciones adicionales

 Para aumentar la seguridad de la infraestructura DNS, permita transferencias de zona


solo para los servidores DNS de los registros de recursos de servidor de nombres (NS)
para una zona o para servidores DNS especificados. Si permite que cualquier servidor
DNS realice una transferencia de zona, permitirá que se transmita información de la red
interna a cualquier host que pueda tener contacto con el servidor DNS.

Referencias adicionales

 Administración de la configuración de zonas

Servicios wins de Windows 2003 r2

Función de servidor WINS:


configurar un servidor WINS
Actualizado: enero de 2005
Se aplica a: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1,
Windows Server 2003 with SP2

Función de servidor WINS: configurar un servidor


WINS
Los servidores de Servicio de nombres Internet de Windows (WINS) asignan dinámicamente
direcciones IP a nombres de equipo (nombres NetBIOS). Esto permite a los usuarios tener
acceso a los recursos a través del nombre del equipo en lugar de a través de la dirección IP. Si
desea que el equipo realice un seguimiento de los nombres y direcciones IP de otros equipos de
la red, configúrelo como un servidor WINS.
En este tema se explican los pasos básicos que debe seguir para configurar un servidor WINS.
Cuando haya terminado de configurar un servidor WINS básico, podrá completar tareas de
configuración adicional, en función de cómo desee utilizar el servidor WINS.
En este tema se trata:
Antes de comenzar
Configurar el servidor WINS
Pasos siguientes: Completar tareas adicionales

Antes de comenzar
Antes de configurar el equipo como un servidor WINS, compruebe que:

 Está familiarizado con los conceptos básicos de WINS, tales como nombres NetBIOS,
servidores WINS, clientes WINS y asociados de replicación. Para obtener más
información, vea Descripción de WINS.

 El sistema operativo está configurado correctamente. En la familia Windows


Server 2003, WINS depende de la configuración adecuada del sistema operativo y sus
servicios. Si tiene una nueva instalación de un producto de la familia Windows
Server 2003, puede utilizar la configuración predeterminada del servicio. No se requiere
ninguna otra acción. Si ha actualizado a un producto de la familia Windows Server 2003
o si desea confirmar que los servicios están configurados correctamente para optimizar
el rendimiento y la seguridad, compruebe la configuración del servicio mediante la tabla
que se incluye en Configuración predeterminada de los servicios.

 Sabe cuántos servidores WINS necesita instalar y dónde ubicar cada servidor en la red.
Cuando agregue la función de servidor WINS, configure el servidor para mantener una
base de datos de nombres de equipo y direcciones IP. En una red de gran tamaño, es
posible que tenga que agregar la función de servidor WINS a servidores adicionales
para garantizar que los clientes siempre tengan acceso a un servidor WINS como
mínimo. Para obtener más información, vea Planear redes WINS.

 Este equipo tiene una dirección IP estática. Para obtener más información,
vea Configurar TCP/IP para direccionamiento estático.

 Todos los volúmenes de disco existentes utilizan el sistema de archivos NTFS. Los
volúmenes FAT32 no son seguros y no admiten compresión de archivos y carpetas,
cuotas de disco, cifrado de archivos ni permisos de archivo individuales.

 Firewall de Windows está habilitado. Para obtener más información, vea Habilitar
Firewall de Windows sin excepciones.
 El Asistente para configuración de seguridad está instalado y habilitado. Para obtener
más información acerca del Asistente para configuración de seguridad, veaIntroducción
al Asistente para configuración de seguridad.

Configurar el servidor WINS


Para configurar un servidor WINS, inicie el Asistente para configurar su servidor mediante una
de las acciones siguientes:

 En Administre su servidor, haga clic en Agregar o quitar función. De forma


predeterminada, Administre su servidor se inicia automáticamente al iniciar la sesión.
Para abrir Administre su servidor, haga clic en Inicio y en Panel de control, haga doble
clic en Herramientas administrativas y, a continuación, haga doble clic en Administre
su servidor.

 Para abrir el Asistente para configurar su servidor, haga clic en Inicio, haga clic en Panel
de control, haga doble clic en Herramientas administrativas y, a continuación, haga
doble clic en Asistente para configurar su servidor.

En la página Función del servidor, haga clic en Servidor WINS y, a continuación, en Siguiente.
Resumen de las selecciones
Completar el Asistente para configurar su servidor
Quitar la función de servidor WINS

Resumen de las selecciones


En la página Resumen de las selecciones, vea y confirme las opciones que haya seleccionado.
Si seleccionó Servidor WINS en la página anterior, aparecerá el siguiente mensaje:

 Instalar WINS

Para aplicar las selecciones que aparecen en la página Resumen de las selecciones, haga clic
en Siguiente. Tras hacer clic en Siguiente, aparecerá la página Configuración de
componentes del Asistente para componentes de Windows y, a continuación, se cerrará
automáticamente. En esta página no se puede hacer clic en Atrás ni en Siguiente. El Asistente
para configurar su servidor instala el servicio Servidor WINS. A diferencia de otros muchos
servicios, el servicio WINS se instala sin que el administrador tenga que escribir nada.
Si cancela Configurar el servidor, no se instalará el servicio Servidor WINS. Para instalarlo
después, reinicie Administrar su servidor y agregue la función WINS.

Completar el Asistente para configurar su servidor


Una vez configurados los componentes, el Asistente para configurar su servidor mostrará la
página Este servidor es ahora un servidor WINS. Para revisar todos los cambios que el
Asistente para configurar su servidor haya realizado en el servidor o comprobar que se ha
instalado correctamente una nueva función, haga clic en el registro de Configuración de su
servidor. El registro del Asistente para configurar su servidor se encuentra
en raízSistema\Debug\Configure Your Server.log. Para cerrar este asistente, haga clic
en Finalizar.
Para verificar que su servidor es seguro y tiene las actualizaciones más recientes, realice lo
siguiente:

1. Ejecute Windows Update. Para obtener más información, vea Windows Update.
2. Ejecute el Asistente para configuración de seguridad. Para obtener más información,
vea Introducción al Asistente para configuración de seguridad.

Quitar la función de servidor WINS


Si necesita volver a configurar el servidor para una función diferente, podrá quitar las funciones
de servidor existentes. Si quita la función de servidor WINS y éste es el único servidor WINS que
los clientes pueden utilizar para registrar y resolver los nombres de equipo, debe agregar la
función WINS a otro servidor. Además, si el servidor se configura para replicar información de
bases de datos WINS con otros servidores WINS, debe volver a configurar la replicación en los
otros servidores WINS.
Para quitar la función de servidor WINS, reinicie el Asistente para configurar su servidor
mediante una de las acciones siguientes:

 En Administre su servidor, haga clic en Agregar o quitar función. De forma


predeterminada, Administre su servidor se inicia automáticamente al iniciar la sesión.
Para abrir Administre su servidor, haga clic en Inicio y en Panel de control, haga doble
clic en Herramientas administrativas y, a continuación, haga doble clic en Administre
su servidor.

 Para abrir el Asistente para configurar su servidor, haga clic en Inicio, haga clic en Panel
de control, haga doble clic en Herramientas administrativas y, a continuación, haga
doble clic en Asistente para configurar su servidor.

En la página Función del servidor, haga clic en Servidor WINS y, a continuación, en Siguiente.
En la página Confirmación de supresión de función, revise los elementos que aparecen
en Resumen, active la casilla de verificación Quitar la función de servidor WINS y, a
continuación, haga clic en Siguiente. En la página Función de servidor WINS quitada, haga
clic en Finalizar.

Pasos siguientes: Completar tareas adicionales


Tras completar el Asistente para configurar su servidor, el equipo estará preparado para su uso
como un servidor WINS básico que puede realizar un seguimiento de direcciones IP de
servidores y proporcionar esta información cuando un cliente la solicite. Hasta este momento,
ha instalado el servicio de Servidor WINS en un servidor. Si quiere admitir clientes WINS en una
red compleja, es posible que tenga que instalar servidores WINS adicionales en otras subredes.
En la siguiente tabla se enumeran algunas de las tareas adicionales que puede desear llevar a
cabo en el servidor WINS.

Tarea Objetivo de la tarea

Ver los registros de nombres Comprobar si el servidor WINS funciona correctamente.


WINS registrados en el
servidor.

Modificar la configuración WINS utiliza varios parámetros predeterminados para la configuración


predeterminada del servidor determinan de qué forma se administran los registros de nombres NetB
WINS. datos del servidor WINS. Estos parámetros suelen ser aceptables. Pued
modificarlos en determinadas circunstancias, por ejemplo si debe efec
el nombre del host o, si es necesario, volver a numerar la red para que
utilicen un conjunto diferente de direcciones IP.

Configurar las opciones de Los servidores WINS replican cambios de la base de datos entre sí par
replicación en los servidores WINS tenga la misma información sobre los servidores de la red y la d
WINS principal y secundario. uno.

Configure los puertos para Para administrar el servidor WINS desde otros equipos de la red.
permitir la administración
remota.

Migración de dominio

Guía de migración del servidor


de Servicios de dominio de
Active Directory y DNS
Personas que lo han encontrado útil: 20 de 26 - Valorar este tema

Actualizado: abril de 2009


Se aplica a: Windows Server 2008 R2

Acerca de esta guía


Este documento proporciona instrucciones para migrar los roles de servidor Servicios de
dominio de Active Directory® (AD DS) y Sistema de nombres de dominio (DNS) desde un
servidor basado en x86 o en x64 que ejecuta Windows Server® 2003, Windows Server 2008 o
Windows Server 2008 R2 a un nuevo servidor de Windows Server 2008 R2.
Este documento describe los procedimientos recomendados para migrar un servidor AD DS y
un servidor DNS desde un hardware antiguo a otro nuevo. El administrador del servidor es el
que decide totalmente qué elementos de la instalación existente se van a migrar. Sin embargo,
junto con el rol de servidor, estos elementos normalmente incluyen la configuración, los datos,
la identidad del sistema y la configuración del sistema operativo. Este documento no hace
suposiciones sobre posibles dependencias que pudieran existir entre roles de servidor. Por
contra, de acuerdo con el objetivo de esta guía, se asume que va a migrar un servidor AD DS y
un servidor DNS desde un equipo a otro equipo de una red sin cambios de topología,
configuración de sitio, configuración de vínculos a sitios ni de configuración de subred.
Público de destino
Este documento va dirigido a administradores de tecnología de la información (TI),
profesionales de TI y otros trabajadores de conocimientos similares que sean responsables del
funcionamiento y la implementación del servidor AD DS o del servidor DNS en un entorno
administrado. Es posible que sean necesarios algunos conocimientos de scripting para realizar
algunos de los pasos de migración que se indican en esta guía.
Qué no proporciona esta guía
Los siguientes escenarios no se describen en esta guía:

 Esta guía no proporciona instrucciones de proceso para una actualización en contexto,


en la que el nuevo sistema operativo esté instalado en el hardware de servidor existente
con la opción Actualizar de la instalación de Windows.

 Esta guía no proporciona instrucciones para migrar roles de servidor que no sean de
servidor AD DS o de servidor DNS.

 Esta guía no proporciona instrucciones para determinar qué software que se esté
ejecutando en el servidor de origen es compatible con el servidor de destino Windows
Server 2008 R2. Consulte la documentación del software para obtener información
sobre los sistemas operativos compatibles.

 El proceso de migración descrito en esta guía sirve para la migración en un solo sitio.
Esta guía no ofrece instrucciones para escenarios de migración en los que el servidor de
origen y el servidor de destino estén ubicados en sitios diferentes. Además, no se tratan
algunos problemas relacionados con la replicación de la migración con respecto a la
migración de roles de servidor en un servidor cabeza de puente.

Escenarios de migración admitidos


Esta guía le proporciona instrucciones para migrar un servidor existente que ejecuta el
servidor AD DS y el servidor DNS a un servidor que ejecuta Windows Server 2008 R2. Esta guía
no contiene instrucciones para realizar la migración si el servidor de origen ejecuta varios roles.
Si el servidor ejecuta varios roles, se recomienda que diseñe un procedimiento de migración
personalizado específico para el entorno del servidor, de acuerdo con la información que se
proporciona en otras guías de migración de roles. Encontrará guías de migración de otros roles
de servidor en el TechCenter de Windows Server 2008 R2 (puede estar en
inglés) (http://go.microsoft.com/fwlink/?LinkID=128554).

Precaución

Si el servidor de origen está ejecutando varios roles, algunos pasos de migración de esta guía, como los de la conf
dar lugar a errores en otros roles que se estén ejecutando en el servidor de origen.

Esta guía también contiene otras instrucciones por separado sobre la migración del rol del
servidor DNS independiente. Para obtener más información, vea Migración de un servidor
AD DS y DNS: apéndice C: migración de DNS independiente.
Esta guía proporciona instrucciones únicamente para migrar datos y opciones de configuración
desde un servidor existente que se va a sustituir por un nuevo servidor físico o virtual basado en
x64 con un sistema operativo limpio instalado, tal y como se describe en la siguiente tabla.
Sistemas operativos compatibles

Procesador del servidor


Sistema operativo del servidor de origen Sistema operativo del serv
de origen

Basado en x86 o en Windows Server 2003 con Service Pack 2 (SP2) Windows Server 2008 R2
x64 completa y Server Core

Basado en x86 o x64 Windows Server 2003 R2 Windows Server 2008 R2


completa y Server Core

Basado en x86 o x64 Windows Server 2008, opciones de instalación Windows Server 2008 R2
completa y Server Core completa y Server Core

Basado en x64 Windows Server 2008 R2 Windows Server 2008 R2


completa y Server Core

Basado en x64 Opción de instalación Server Core de Windows Windows Server 2008 R2
Server 2008 R2 completa y Server Core
Las versiones de los sistemas operativos reflejadas en la tabla anterior corresponden a las
combinaciones de sistemas operativos y Service Packs más antiguas que se admiten. Service
Packs más recientes (si están disponibles)
Las ediciones Foundation, Standard, Enterprise y Datacenter de Windows Server se admiten
como servidores de origen o de destino. La edición Foundation Server solo se admite como
servidor de destino en determinados escenarios. Asegúrese de que comprende las limitaciones
de la edición Foundation Server antes de usarla como servidor de destino.
Son compatibles las migraciones entre sistemas operativos físicos y virtuales.
No es posible realizar la migración desde un servidor de origen a un servidor de destino que
ejecute un sistema operativo con un idioma de la interfaz de usuario (es decir, el idioma
instalado) distinto del idioma del servidor de origen. El idioma de la interfaz de usuario del
sistema es el idioma del paquete de instalación localizado que se usó al instalar el sistema
operativo Windows. Por ejemplo, no puede migrar roles, configuraciones del sistema operativo,
datos o recursos compartidos desde un equipo que ejecuta Windows Server 2008 con el idioma
de la interfaz de usuario del sistema en francés a un equipo que ejecuta Windows
Server 2008 R2 con el idioma de la interfaz de usuario del sistema en alemán.

Introducción a la migración de un servidor AD DS y


DNS
Antes de comenzar cualquier procedimiento de migración o preparación, se asumen las
condiciones siguientes:

 El servidor de origen es un controlador de dominio en funcionamiento y tiene instalado


un servidor DNS.

 El servidor de destino tiene instalado Windows Server 2008 R2. También se ha agregado
a la red como un servidor miembro con un nombre y una dirección IP estática únicos.
 Cuando se complete la migración de roles desde el servidor de origen al servidor de
destino, éste comienza a realizar las funciones del servidor de origen. El servidor de
origen se convierte en un servidor miembro, se retira y se quita de la red, o permanece
como un controlador de dominio adicional.

Introducción al proceso de migración de estos roles


Cuando realice una migración, complete los pasos siguientes:

 Planee la migración. Vea Planear una migración.

 Prepare el servidor de origen. Vea Preparar el servidor de origen.

Antes de comenzar la migración, recopile los datos de la configuración de


Active Directory o DNS del servidor de origen. Esta guía proporciona una hoja de
cálculo que puede usar para recopilar estos datos. Vea Migración de un servidor AD DS
y DNS: apéndice A: hoja de cálculo de recopilación de datos de la migración.

 Agregue a la red el nuevo servidor de Windows Server 2008 R2 basado en x64 y


conviértalo en un controlador de dominio. Vea Preparar el servidor de destino.

 Migre la configuración obligatoria. Vea Migración de un servidor AD DS y DNS: migrar


los roles de servidor AD DS y DNS.

 Compruebe que la migración se realizó correctamente. Vea Migración de un servidor


AD DS y DNS: comprobar la migración.

 Realice las tareas posteriores a la migración, en las que se incluye la posible disminución
de nivel del servidor de origen. Vea Migración de un servidor AD DS y DNS: tareas
posteriores a la migración.

 Para migrar únicamente el rol del servidor DNS, puede seguir las instrucciones por
separado de Migración de un servidor AD DS y DNS: apéndice C: migración de DNS
independiente.

En otros temas de esta guía se proporcionan más detalles acerca de estos pasos.
En la siguiente ilustración se muestra el proceso de migración.
Diferencias entre migración y actualización
Existen tres opciones para implementar un nuevo sistema operativo Windows Server 2008 R2:

 Actualización en contexto

 Instalación limpia

 Migración

Tanto la actualización en contexto como la instalación limpia tienen ventajas e inconvenientes.


En esta guía se describe la tercera opción: la migración.
Existe una diferencia entre migración y actualización en contexto. La migración es necesaria
cuando las diferencias de hardware no permiten una actualización. Dado que Windows
Server 2008 R2 es un sistema operativo basado solamente en x64, no es posible actualizar
versiones basadas en x86 de Windows Server 2003 o Windows Server 2008 a equipos que
ejecuten Windows Server 2008 R2.
Además, la migración de servidor es el mecanismo de implementación preferido en un buen
número de escenarios:

 Cuando el rendimiento de un servidor antiguo se ha reducido como resultado de


numerosas instalaciones de software, actualizaciones y revisiones

 Cuando un servidor físico se debe migrar a un servidor virtual

 Cuando un escenario requiere una migración desde una opción de instalación completa
a una opción de instalación Server Core

Puede usar las instrucciones que aparecen en esta guía para migrar la configuración y los datos
heredados al nuevo sistema operativo.
Nota

Si el hardware existente está basado en x64 pero ejecuta un sistema operativo basado en x86, también debe usa
servidor.

Métodos de actualización y migración

Método Ventaja Inconvenien

Actualización en contexto Se mantienen todas las opciones de configuración actuales. El servidor


(no se trata en esta guía) La actualiz
inactividad
por un siste
Si la actual
reversión e

Instalación limpia (no se Quita todos los datos y la configuración antiguos que ya no Debe volve
trata en esta guía) necesita.

Migración (sí se trata en Todas las opciones de configuración actuales se conservan, Se requiere
esta guía) mientras que se quitan todos los datos y la configuración garantizar
antiguos que ya no necesita.
Proporciona una ruta de transición de un entorno físico a uno
virtual y de una instalación completa a una instalación
Server Core.
Necesita un tiempo de inactividad menor ya que el servidor
antiguo sigue en funcionamiento durante la mayor parte del
proceso de migración.

Impacto de la migración
El objetivo del proceso de migración reside en que el servidor de destino realice las mismas
funciones que realizaba el servidor de origen, sin que los equipos cliente de la red perciban
ninguna interrupción de los servicios. Una vez que la migración se complete, el servidor de
destino debería poder autenticar usuarios y equipos. Los equipos cliente que usan los servicios
del servidor de origen no deberían modificarse, y los equipos cliente deberían experimentar
poca o ninguna interrupción de servicio. El servidor de destino de sustitución del servidor AD DS
o del servidor DNS gestiona todas las consultas del Protocolo ligero de acceso a
directorios (LDAP) tal y como lo hacía el servidor de origen.
En un entorno en el que los equipos cliente se configuran con un solo servidor DNS, que
también es el servidor de origen, es muy importante tener en cuenta que durante la migración
los servicios de DNS pueden verse interrumpidos temporalmente. En esta situación, los equipos
cliente no podrán resolver los nombres de dominio de las direcciones IP. Se recomienda que
durante este tiempo se configuren uno o más servidores DNS de modo que los clientes puedan
seguir resolviendo los nombres mientras se migra el servidor de origen principal.

Permisos necesarios para completar la migración


Debe tener permisos de administrador de dominio para obtener acceso a las herramientas, los
datos y la configuración que son necesarios para el proceso de migración.

Duración estimada
Normalmente, un proceso de migración de servidor AD DS y servidor DNS en un entorno
sencillo suele tardar de dos a tres horas, incluidas las pruebas. Se necesita más tiempo para
promocionar el nuevo servidor a controlador de dominio. En entornos más grandes y
complicados, la promoción a controlador de dominio puede variar mucho, en función de la
cantidad de datos que se debe replicar en el nuevo servidor y en función de la conectividad de
la red. No obstante, se recomienda usar determinadas herramientas y la opción Instalar desde el
medio (IFM) para trasladar la base de datos completa de una vez.

Escenario de migración de un servidor AD DS y DNS


Se recomienda que desarrolle un escenario de migración para los servidores que tenga en
cuenta todas las circunstancias, configuraciones y topologías especiales que puedan afectar a la
migración. Es posible que tenga que responder a preguntas sobre la migración como las
siguientes:

 ¿Tiene varias versiones de Active Directory que se replican en diferentes servidores


físicos o virtuales?

 ¿Está ubicado AD DS sólo en el mismo servidor físico o virtual?

Si va a migrar un servidor DNS, determine cómo está distribuido AD DS en el dominio. Por


ejemplo, ¿va a migrar el servidor DNS con el servidor AD DS desde el mismo equipo? Aunque el
servidor DNS se puede migrar independientemente del servidor AD DS, en la mayoría de los
casos es muy probable que ambos roles de servidor se hospeden en el mismo equipo y que se
deban migrar juntos a la vez. Por lo tanto, se recomienda que desarrolle un escenario de
migración para el servidor DNS que tenga en cuenta todas las circunstancias, configuraciones y
topologías especiales que puedan afectar a la migración del servidor DNS.
Sin embargo, esta guía sí contiene instrucciones por separado para migrar el rol del
servidor DNS independiente, en Migración de un servidor AD DS y DNS: apéndice C: migración
de DNS independiente.

Consideraciones especiales de migración


Existen determinadas configuraciones de servidor que necesitan pasos especiales antes, en el
transcurso o después de la migración. Por ahora esta guía no proporciona instrucciones de
migración para algunas de esas configuraciones. Dichos casos especiales se describen en la
sección siguiente.
Servidores de funcionamiento correcto y de funcionamiento
incorrecto
La migración puede verse afectada por el estado del servidor de origen. El estado del servidor
mide la existencia o ausencia de problemas en el servidor. Windows Server proporciona varias
formas de recopilar y guardar muchos tipos diferentes de datos del servidor. Puede usar estos
datos para establecer una línea de base que describa un servidor con funcionamiento correcto y
estado en buenas condiciones. Si el servidor pasa a un estado en malas condiciones, puede
determinar qué se ha cambiado si compara las medidas actuales con los datos de la línea de
base que recopiló cuando el servidor se encontraba en buenas condiciones.
Si los registros de eventos del servidor de origen muestran que el estado de éste no está en
buenas condiciones, existen dos formas para migrar el servidor de origen.

 Desarrollar el nuevo servidor de destino e ignorar los problemas del servidor de origen.

 Solucionar todos los problemas del servidor de origen y, a continuación, migrar todas
las opciones de configuración al servidor de destino.

Si existen problemas conocidos en el servidor de origen, tenga en cuenta el posible impacto que
dichos problemas pueden tener en la migración. El procedimiento recomendado es realizar la
migración desde un servidor de origen en buenas condiciones a un servidor de destino con el
mismo buen estado. Sin embargo, pueden darse situaciones en las que realice una migración
desde un servidor de origen que no esté en buenas condiciones. Esos casos especiales necesitan
un análisis pormenorizado.

Consulte también
Conceptos
Migración de un servidor AD DS y DNS: preparación para la migración
Migración de un servidor AD DS y DNS: migrar los roles de servidor AD DS y DNS
Migración de un servidor AD DS y DNS: comprobar la migración
Migración de un servidor AD DS y DNS: tareas posteriores a la migración
Migración de un servidor AD DS y DNS: apéndice A: hoja de cálculo de recopilación de datos de
la migración
Migración de un servidor AD DS y DNS: apéndice B: hoja de cálculo de comprobación de la
migración
Migración de un servidor AD DS y DNS: apéndice C: migración de DNS independiente

Cómo agregar, modificar o eliminar


subclaves y valores del Registro
mediante un archivo .reg

Importante: esta sección, método o tarea contiene pasos que le indican cómo modificar el
Registro. Sin embargo, la modificación incorrecta del Registro puede producir graves problemas.
Por tanto, compruebe que sigue estos pasos cuidadosamente. Para obtener mayor protección,
realice una copia de seguridad del Registro antes de modificarlo. A continuación, puede
restaurar el Registro si se produce algún problema. Para obtener más información acerca de
cómo realizar una copia de seguridad y restaurar el Registro, haga clic en el número de artículo
siguiente de Microsoft Knowledge Base:
322756 Cómo realizar una copia de seguridad del Registro y restaurarlo en Windows
En este artículo paso a paso se describe cómo agregar, modificar o eliminar subclaves y valores
del Registro mediante un archivo de entradas de Registro (.reg). Regedit.exe utiliza archivos .reg
para importar y exportar las subclaves y valores del Registro. Puede utilizar estos archivos .reg
para distribuir de forma remota los cambios del Registro en varios equipos basados en
Windows. Cuando ejecuta un archivo .reg, su contenido se combina en el Registro local. Por
consiguiente, debe distribuir los archivos .reg con precaución.

Sintaxis de archivos .reg


Un archivo .reg cuenta con la siguiente sintaxis:

versiónEditorRegistro
línea en blanco
[rutaRegistro1]
"nombreDato1"="tipoDatos1:valorDatos1"
nombreDato2"="tipoDatos2:valorDatos2"
línea en blanco
[rutaRegistro2]
"nombreDato3"="tipoDatos3:valorDatos3"

donde:

versionEditorRegistro es cualquier "Editor del Registro de Windows versión 5.00" para Windows
2000, Windows XP y Windows Server 2003 o "REGEDIT4" para Windows 98 y Windows NT 4.0. El
encabezado "REGEDIT4" también funciona en equipos basados en Windows 2000, Windows XP
o Windows Server 2003.

línea en blanco es una línea en blanco. Esto identifica el inicio de una nueva ruta del Registro.
Cada clave o subclave es una nueva ruta del Registro. Si tiene varias claves en el archivo .reg, las
líneas en blanco pueden ayudarle a examinar y solucionar problemas del contenido.

rutaRegistrox es la ruta de la subclave que contiene el primer valor que va a importar. Agregue
la ruta entre corchetes y separe cada nivel de la jerarquía con una barra diagonal inversa. Por
ejemplo:
[
HKEY_LOCAL_ MACHINE\SOFTWARE\Policies\Microsoft\Windows\System
]
Un archivo .reg puede contener varias rutas de Registro. Si la parte inferior de la jerarquía en la
instrucción de ruta no existe en el Registro, se crea una nueva subclave. El contenido de los
archivos de Registro se envía al Registro en el orden en que se especifica. Por consiguiente, si
desea crear una nueva subclave con otra por debajo de ella, debe escribir las líneas en el orden
correcto.

nombreDatox es el nombre del dato que desea importar. Si un dato del archivo no existe en el
Registro, el archivo .reg lo agrega (con el valor del dato). Si un dato existe, el valor del archivo
.reg sobrescribe el existente. Las comillas contienen el nombre del dato. Un signo igual (=) sigue
inmediatamente al nombre del dato.

tipoDeDatosx es el tipo de datos del valor del Registro y sigue inmediatamente al signo igual.
Para todos los tipos de datos distintos de REG_SZ (un valor de cadena), un signo de dos puntos
sigue inmediatamente al tipo de datos. Si el tipo de datos es REG_SZ, no incluya el valor de tipo
de datos ni los dos puntos. En este caso, Regedit.exe supone REG_SZ para el tipo de datos. En la
tabla siguiente se muestran los tipos de datos del Registro típicos:
Tipo de datos Tipo de datos en .reg
REG_BINARY hexadecimal
REG_DWORD dword
REG_EXPAND_SZ hexadecimal (2)
REG_MULTI_SZ hexadecimal (7)
Para obtener más información acerca de los tipos de datos del Registro, haga clic en el número
de artículo siguiente para verlo en Microsoft Knowledge Base:
256986 Definición del Registro de Microsoft Windows
valorDatosx sigue inmediatamente al signo de dos puntos (o al signo igual con REG_SZ) y debe
estar en el formato adecuado (por ejemplo, cadena o hexadecimal). Utilice el formato
hexadecimal para los datos binarios.

Nota: puede escribir varias líneas de datos para la misma ruta del Registro.

Nota: el archivo del Registro debe contener una línea en blanco en la parte inferior del archivo.

Adición de subclaves del Registro o adición y modificación de


valores del Registro
Para agregar una subclave o agregar o cambiar un valor del Registro, realice los cambios
adecuados en el Registro y, a continuación, exporte la subclave o subclaves adecuadas. Las
subclaves del Registro exportadas se guardan automáticamente como archivos .reg. Para
realizar cambios en el Registro y exportarlos a un archivo .reg, siga estos pasos:
1. Haga clic en Inicio y en Ejecutar, escriba regedit en el cuadro Abrir y haga clic
en Aceptar.
2. Busque la subclave que contenga el elemento o elementos del Registro que desee
cambiar y haga clic en ella.
3. Haga clic en Archivo y, después, en Exportar.

De este modo se hace una copia de seguridad de la subclave antes de realizar cualquier
cambio. Puede importar de nuevo este archivo en el Registro después si sus cambios
provocan algún problema.
4. En el cuadro Nombre de archivo, escriba un nombre de archivo para guardar el archivo
.reg con los elementos del Registro originales y, a continuación, haga clic en Guardar.

Nota: use un nombre de archivo que le recuerde al contenido, por ejemplo, una
referencia al nombre de la subclave.
5. En el panel derecho, agregue o modifique los elementos del Registro que desee.
6. Repita los pasos 3 y 4 para exportar de nuevo la subclave, pero use un nombre de archivo
diferente para el archivo .reg. Puede utilizar este archivo .reg para realizar cambios en el
Registro de otro equipo.
7. Pruebe sus cambios en el equipo local. Si ocasionan algún problema, haga doble clic en
el archivo que contenga la copia de seguridad de los datos originales del Registro para
devolverlo a su estado original. Si los cambios funcionan como se esperaba, puede
distribuir el archivo .reg que creó en el paso 6 en otros equipos utilizando los métodos
de la sección "Distribuir los cambios del Registro" de este artículo.
Eliminación de las claves y valores del Registro
Para eliminar una clave del Registro con un archivo .reg, ponga un guión (-) delante
de RegistryPath en el archivo .reg. Por ejemplo, para eliminar la subclave Test de la clave del
Registro siguiente: ponga un guión delante de la clave del Registro siguiente en el archivo .reg:
HKEY_LOCAL_MACHINE\Software\Test
El ejemplo siguiente tiene un archivo .reg con el que puede realizar esta tarea.
[
-HKEY_LOCAL_MACHINE\Software\Test
]
Para eliminar un valor del Registro con un archivo .reg, ponga un guion (-) después del signo
igual a continuación delDataItemName en el archivo .reg. Por ejemplo, para eliminar el valor del
Registro TestValue de la siguiente clave de Registro:
HKEY_LOCAL_MACHINE\Software\Test
ponga un guion después de "TestValue"= en el archivo .reg. El ejemplo siguiente tiene un
archivo .reg con el que puede realizar esta tarea.
HKEY_LOCAL_MACHINE\Software\Test

"TestValue"=-
Para crear el archivo .reg, utilice Regedit.exe para exportar la clave del Registro que desee
eliminar y, a continuación, utilice el Bloc de notas para editar el archivo .reg e insertar el guion.

Cambiar el nombre de los valores y claves del Registro


Para cambiar el nombre de una clave o valor, elimine la clave o valor, y, a continuación, cree una
nueva clave o valor con el nuevo nombre.
Distribución de cambios en el Registro
Puede enviar un archivo .reg a los usuarios en un mensaje de correo electrónico, poner un
archivo .reg en un recurso compartido de red y dirigir a él a los usuarios para que lo ejecuten, o
agregar un comando a las secuencias de comandos de inicio de sesión de los usuarios para
importar automáticamente el archivo .reg cuando inicien sesión. Cuando los usuarios ejecuten el
archivo .reg, reciben los mensajes siguientes:
Editor del Registro
¿Está seguro de que desea agregar la información en ruta de archivo .reg al Registro?
Si el usuario hace clic en Sí, recibe un mensaje similar al siguiente:
Editor del Registro
La información de la ruta del archivo .reg se ha escrito correctamente en el Registro.
Regedit.exe admite un modificador de la línea de comandos /s para no mostrar estos mensajes.
Por ejemplo, para ejecutar sin mensajes el archivo .reg (con el modificador /s) desde un archivo
de lotes de la secuencia de comandos de inicio de sesión, utilice la sintaxis siguiente:
regedit.exe /s ruta de acceso del archivo .reg
También puede utilizar Directiva de grupo o Directiva del sistema para distribuir los cambios del
Registro en la red. Para obtener información adicional, visite el siguiente sitio web de Microsoft:
http://msdn2.microsoft.com/en-us/library/ms954395.aspx
Nota: si los cambios funcionan, puede enviar el archivo de registro a los usuarios
correspondientes en la red.
Crear ámbitos

Crear un nuevo ámbito DHCP


Personas que lo han encontrado útil: 5 de 6 - Valorar este tema

Actualizado: mayo de 2009


Se aplica a: Windows Server 2008 R2
Puede usar este procedimiento para crear un nuevo ámbito DHCP por medio de la Microsoft
Management Console (MMC) para DHCP.
El mínimo requerido para realizar este procedimiento es la pertenencia al
grupo Administradores de DHCP o un grupo equivalente.
Para crear un ámbito DHCP nuevo
1. Haga clic en Inicio, en Herramientas administrativas y en DHCP. Se abre MMC para
DHCP.
2. En DHCP, haga doble clic en el nombre del servidor; por ejemplo, si el nombre del
servidor DHCP es DHCP-01.example.com, haga doble clic en DHCP-01.example.com.
3. Haga clic con el botón secundario en IPv4 y, a continuación, haga clic en Nuevo
ámbito. Se abre el Asistente para ámbito nuevo.
4. En Éste es el Asistente para ámbito nuevo, haga clic en Siguiente.
5. En Nombre de ámbito, en Nombre, escriba un nombre para el ámbito. Por ejemplo,
escriba Subred-02.
6. En Descripción, escriba una descripción del nuevo ámbito y haga clic en Siguiente.
7. En Intervalo de direcciones IP, realice lo siguiente:
a. En Dirección IP inicial, especifique la primera dirección IP del intervalo. Por
ejemplo, escriba 10.10.10.1.

b. En Dirección IP final, especifique la última dirección IP del intervalo. Por


ejemplo, escriba 10.10.10.254. Los valores de los campos Longitud y Máscara
de subredse establecen automáticamente a partir de la dirección IP que haya
especificado en Dirección IP inicial.

c. Modifique estos valores si así lo considera necesario para su esquema de


direcciones.

d. Haga clic en Siguiente.

8. En Agregar exclusiones, realice lo siguiente:


a. En Dirección IP inicial, especifique la primera dirección IP del intervalo de
exclusión. Por ejemplo, escriba 10.10.10.1.

b. En Dirección IP final, especifique la última dirección IP del intervalo de


exclusión. Por ejemplo, escriba 10.10.10.15.

9. Haga clic en Agregar y, a continuación, en Siguiente.


10. En Duración de la concesión, modifique los valores predeterminados relativos
a Días, Horas y Minutos según sea preciso para la red y, a continuación, haga clic
enSiguiente.
11. En Configurar opciones DHCP, seleccione Configurar estas opciones ahora y haga
clic en Siguiente.
12. En Enrutador (puerta de enlace predeterminada), realice una de las acciones
siguientes:
o Si no dispone de enrutadores en la red, haga clic en Siguiente.

o En Dirección IP, escriba la dirección IP del enrutador o de la puerta de enlace


predeterminada. Por ejemplo, escriba 10.10.10.10. Haga clic en Agregar y, a
continuación, en Siguiente.

13. En Nombre de dominio y servidores DNS, realice lo siguiente:


. En Dominio primario, escriba el nombre del dominio DNS que los clientes
usan para la resolución de nombres. Por ejemplo, escriba example.com.

a. En Nombre del servidor, escriba el nombre del equipo DNS que los clientes
usan para la resolución de nombres. Por ejemplo, escriba AD-DNS-01.

b. Haga clic en Resolver. La dirección IP del servidor DNS se agrega a Dirección


IP. Haga clic en Agregar, espere a que finalice la validación de la dirección IP
del servidor DNS y, a continuación, haga clic en Siguiente.

14. En Servidores WINS, realice una de las acciones siguientes:


o Si no dispone de servidores WINS en la red, haga clic en Siguiente.

o Si tiene uno o más servidores WINS implementados en la red, realice lo


siguiente con cada uno de ellos: En Nombre del servidor, escriba el nombre
del servidor WINS pertinente. Por ejemplo, escriba WINS-01. Haga clic
en Resolver. La dirección IP del servidor WINS se agrega a Dirección IP. Haga
clic en Agregar y, a continuación, en Siguiente.

15. En Activar ámbito, realice una de las acciones siguientes:


o Para activar el ámbito de forma automática inmediatamente después de que los
pasos del Asistente para ámbito nuevo se hayan completado,
seleccione Activar este ámbito ahora.

o Si desea activarlo manualmente más adelante mediante la consola MMC para


DHCP, seleccione Activar este ámbito más tarde.

16. Haga clic en Siguiente y después en Finalizar.


CÓMO: Instalar y configurar un
servidor DHCP en un grupo de
trabajo en Windows Server 2003

En este artículo paso a paso se describe cómo configurar un nuevo servidor del Protocolo de
configuración dinámica de host (DHCP) basado en Windows Server 2003 en un servidor
independiente para proporcionar administración centralizada de direcciones IP y otros valores
de configuración TCP/IP de los equipos cliente de una red.

Instalar el servicio DHCP


Para poder configurar el servicio DHCP, primero debe instalarlo en el servidor. DHCP no se
instala de manera predeterminada durante la instalación típica de Windows Server 2003
Standard Server o Windows Server 2003 Enterprise Server. Puede instalar DHCP durante la
instalación inicial de Windows Server 2003 o después de que la instalación inicial haya
terminado.

Instalar el servicio DHCP en un servidor existente


1. Haga clic en Inicio, seleccione Panel de control y, a continuación, haga clic en Agregar
o quitar programas.
2. En el cuadro de diálogo Agregar o quitar programas, haga clic en Agregar o quitar
componentes de Windows.
3. En el Asistente para componentes de Windows, en la lista Componentes, haga clic
en Servicios de red y, después, haga clic en Detalles.
4. En el cuadro de diálogo Servicios de red, active la casilla de verificación Protocolo de
configuración dinámica de host (DHCP) y, después, haga clic en Aceptar.
5. En el Asistente para componentes de Windows, haga clic en Siguiente para iniciar la
instalación. Introduzca el CD de Windows Server 2003 en la unidad de CD-ROM o de
DVD-ROM del equipo cuando se le indique. El programa de instalación copiará al equipo
el servidor DHCP y los archivos de herramientas.
6. Una vez completado el programa de instalación, haga clic en Finalizar.
Configurar el servicio DHCP
Después de instalar e iniciar el servicio DHCP, debe crear un ámbito, que es un intervalo de
direcciones IP válidas que se pueden conceder a los equipos cliente DHCP de la red. Microsoft
recomienda que cada servidor DHCP del entorno tenga al menos un ámbito que no se
superponga con ningún otro ámbito de servidor DHCP de su entorno. En Windows Server 2003,
los servidores DHCP de un dominio basado en Active Directory deben estar autorizados para
impedir que se pongan en conexión servidores DHCP falsos. Windows Server 2003 cierra todos
los servidores DHCP no autorizados que encuentra.
Crear un nuevo ámbito
1. Haga clic en Inicio, seleccione Programas, Herramientas administrativas y, a
continuación, haga clic en DHCP.
2. En el árbol de consola, haga clic con el botón secundario del mouse (ratón) en el servidor
DHCP en el que desee crear el nuevo ámbito DHCP y, a continuación, haga clic
en Ámbito nuevo.
3. En el Asistente para ámbito nuevo, haga clic en Siguiente y escriba un nombre y una
descripción para el ámbito. Puede utilizar cualquier nombre que desee, pero debe ser lo
suficientemente descriptivo para identificar el propósito del ámbito en la red (por
ejemplo, puede utilizar "Direcciones de clientes del edificio de administración"). Haga clic
en Siguiente.
4. Escriba el intervalo de direcciones que se pueden conceder como parte del ámbito, por
ejemplo, un intervalo que comience en la dirección IP 192.168.100.1 y finalice en la
dirección 192.168.100.100. Como estas direcciones se conceden a clientes, todas ellas
deben ser direcciones válidas de la red y no pueden estar en uso actualmente. Si desea
utilizar una máscara de subred diferente, escriba la nueva máscara de subred. Haga clic
en Siguiente.
5. Escriba todas las direcciones IP que desee excluir del intervalo especificado. Esto incluye
todas las direcciones del intervalo descrito en el paso 4 que puedan haberse asignado
estáticamente a varios equipos de la organización. Normalmente, los controladores de
dominio, servidores Web, servidores DHCP, servidores de Sistema de nombres de
dominio (DNS, Domain Name System) y otros servidores tienen direcciones IP asignadas
estáticamente. Haga clic en Siguiente.
6. Escriba el número de días, horas y minutos que deben transcurrir antes de que caduque
la concesión de una dirección IP de este ámbito. Esto determina el período de tiempo
que un cliente puede tener una dirección concedida sin renovarla. Haga clic
en Siguiente y, después, en Configurar estas opciones ahora para extender el asistente
de manera que incluya valores para las opciones de DHCP más comunes. Haga clic
en Siguiente.
7. Escriba la dirección IP de la puerta de enlace predeterminada que deben utilizar los
clientes que obtienen una dirección IP de este ámbito. Haga clic en Agregar para agregar
la dirección de la puerta de enlace predeterminada a la lista y, después, haga clic
en Siguiente.
8. Si hay servidores DNS en la red, escriba el nombre de dominio de la organización en el
cuadro Dominio primario. Escriba el nombre de su servidor DNS y haga clic
en Resolver para asegurarse de que el servidor DHCP puede ponerse en contacto con el
servidor DNS y determinar su dirección. Haga clic en Agregar para incluir ese servidor en
la lista de servidores DNS asignados a los clientes DHCP. Haga clic en Siguiente y,
después, si utiliza un servidor de Servicio de nombres Internet de Windows
(WINS, Windows Internet Naming Service), siga los mismos pasos para agregar el nombre
y dirección IP de ese servidor. Haga clic en Siguiente.
9. Haga clic en Activar este ámbito ahora para activar el ámbito y permitir que los clientes
obtengan concesiones del mismo, y haga clic en Siguiente.
10. Haga clic en Finalizar.
11. En el árbol de consola, haga clic en el nombre de servidor y, después, en Autorizar en el
menú Acción.
Solucionar problemas
En las secciones siguientes se explica cómo solucionar algunos problemas que pueden ocurrir al
intentar instalar y configurar un servidor DHCP basado en Windows Server 2003 en un grupo de
trabajo.
Los clientes no pueden obtener una dirección IP
Si un cliente DHCP no tiene configurada una dirección IP, suele deberse a que no pudo ponerse
en contacto con un servidor DHCP. El motivo puede ser un problema de red o que el servidor
DHCP no está disponible. Si el servidor DHCP está iniciado y otros clientes pueden obtener
direcciones válidas, compruebe que el cliente tiene una conexión de red válida y que todos los
dispositivos hardware de cliente relacionados (incluidos cables y adaptadores de red) funcionan
correctamente.

El servidor DHCP no está disponible


Si un servidor DHCP no proporciona direcciones concedidas a los clientes, suele deberse a que
el servicio DHCP no se ha iniciado. En tal caso, puede que el servidor no esté autorizado para
funcionar en la red. Si antes podía iniciar el servicio DHCP, pero se ha detenido desde entonces,
utilice el Visor de sucesos para buscar en el registro del sistema entradas que expliquen por qué
no puede iniciarlo.

Para reiniciar el servicio DHCP:

1. Haga clic en Inicio y, a continuación, en Ejecutar.


2. Escriba cmd y, a continuación, presione ENTRAR.
3. Escriba net start dhcpserver y, a continuación, presione ENTRAR.
O bien

1. Haga clic en Inicio, seleccione Panel de control, Herramientas administrativas y, a


continuación, haga clic enAdministración de equipos.
2. Expanda Servicios y Aplicaciones y, a continuación, haga clic en Servicios.
3. Localice el Servidor DHCP y haga doble clic en él.
4. Compruebe que Inicio está establecido en Automático y que Estado del servicio está
establecido en Iniciado. Si no es así, haga clic en Iniciar.
5. Haga clic en Aceptar y, a continuación, cierre la ventana Administración de equipos.