WINS

                                                               


                                                        WINS   

1. .-DEFINICIÓN:

El Servicio de nombres Internet de Windows (WINS) proporciona una base de datos distribuida en la que se registran y consultan asignaciones dinámicas de nombres NetBIOS para los equipos y grupos usados en la red. WINS asigna direcciones IP a los nombres NetBIOS y se diseñó para solucionar los problemas que ocasiona la resolución de nombres NetBIOS en entornos con rutas. WINS es la mejor alternativa para la resolución de nombres NetBIOS en entornos con rutas que utilicen NetBIOS sobre TCP/IP.

Los nombres NetBIOS ya se usaban en versiones anteriores de los sistemas operativos Microsoft® Windows® para identificar y encontrar equipos y otros recursos compartidos o agrupados que son necesarios para registrar o resolver nombres, y usarlos en la red.

Los nombres NetBIOS son necesarios para establecer servicios de red en las versiones anteriores de los sistemas operativos de Microsoft. Aunque el protocolo de nombres NetBIOS puede utilizarse con otros protocolos de red además de TCP/IP, WINS se diseñó específicamente para ser usado con NetBIOS sobre TCP/IP (NetBT).

WINS simplifica la administración del espacio de nombres NetBIOS en las redes TCP/IP. En la ilustración siguiente se muestra una serie de eventos habituales en los que participan clientes y servidores WINS.

En este ejemplo tienen lugar los siguientes hechos:

1. Un cliente WINS, HOST-A, registra sus nombres locales NetBIOS en WINS-A, el servidor WINS que tiene configurado.
2. Otro cliente WINS, HOST-B, consulta WINS-A para encontrar la dirección IP del HOST-A en la red.
3. WINS-A responde que la dirección IP de HOST-A es 192.168.1.20.

WINS reduce el uso de difusiones IP locales para la resolución de nombres NetBIOS y permite a los usuarios encontrar fácilmente sistemas en redes remotas. Dado que los registros WINS se realizan de forma automática cada vez que un cliente se inicia y se une a la red, la base de datos WINS se actualiza automáticamente cuando se producen cambios en la configuración de direcciones dinámicas. Por ejemplo, cuando un servidor DHCP emite una dirección IP nueva o modificada a un equipo cliente habilitado para WINS, se actualiza la información WINS correspondiente a ese cliente. Esta operación no requiere que un usuario o un administrador de la red efectúe ningún cambio manualmente.

Notas

• El protocolo WINS se basa en los protocolos definidos para el servicio de nombres NetBIOS especificado en los documentos RFC 1001 y 1002, y además es compatible con ellos, por lo que puede funcionar conjuntamente con cualquier otra implementación de estos RFC.
• La replicación de los datos de nombres NetBIOS en WINS se basa en una tecnología propiedad de Microsoft y no puede interoperar con otros servidores de nombres NetBIOS.

WINS consta de dos componentes principales: el servidor WINS y los Clientes WINS.

El servidor WINS controla las solicitudes de registro de nombres de los clientes WINS y registra sus nombres y sus direcciones IP; asimismo, responde a las consultas de nombres NetBIOS que emiten los clientes y devuelve la dirección IP del nombre consultado si se encuentra en la base de datos del servidor.

Además, como se muestra en la ilustración siguiente, los servidores WINS pueden replicar el contenido de sus bases de datos (que contienen asignaciones de nombres de equipo NetBIOS y direcciones IP) en otros servidores WINS. Cuando un cliente habilitado para WINS (como una estación de trabajo de las subredes 1 ó 2) se inicia en la red, su nombre de equipo y su dirección IP se envían en una solicitud de registro directamente al servidor WINS principal que tienen configurado, WINS-A. Como WINS-A es el servidor que registra dichos clientes, se dice que es el propietario de los registros de los clientes en WINS.

En este ejemplo, el servidor WINS-A tiene clientes locales (es decir, clientes de la subred 2 en la que se encuentra) que se registran en él y remotos (clientes ubicados en la subred 1 situados al otro lado de un enrutador). Un segundo servidor WINS, WINS-B, se encuentra en la subred 3 y sólo posee asignaciones para los clientes locales que se registran desde su misma subred. WINS-A y WINS-B pueden completar más tarde la replicación de sus bases de datos para que los registros de los clientes de las tres subredes estén en las bases de datos WINS de ambos servidores. Para obtener más información, vea Replicación WINS.

2.- ADMINISTRANDO EL SERVIDOR WINS

Administrar WINS desde la línea de comandos

Los comandos de Netsh para WINS pueden utilizarse como alternativa a la administración llevada a cabo desde la consola y constituyen una herramienta de línea de comandos completa y totalmente equivalente que permite administrar servidores WINS. Esto resulta útil en las situaciones siguientes:

• Se pueden usar comandos en modo interactivo, en el símbolo del sistema de Netsh, para mejorar la capacidad de administración de servidores WINS en redes de área extensa (WAN) sobre vínculos de red de baja velocidad.
• Al administrar una gran cantidad de servidores WINS, se pueden usar comandos en modo por lotes para crear secuencias de comandos y automatizar tareas administrativas repetitivas que deben realizarse en todos los servidores WINS.

Para obtener más información acerca de cómo usar los comandos de Netsh para WINS, vea Utilizar las herramientas de línea de comandos de WINS.

Notas

• Para obtener toda la información referente a los comandos de Netsh para WINS (incluida la sintaxis y los parámetros), vea Comandos Netsh para WINS.
• Para obtener un ejemplo de cómo utilizar comandos de Netsh para WINS en archivos por lotes y secuencias de comandos, vea Ejemplo de Netsh WINS.
• Los términos Persona Non Grata y Persona Grata hacen referencia a las características de los servidores WINS de Windows Bloquear registros para estos propietarios y Aceptar registros sólo de estos propietarios, respectivamente.
• Para obtener más información acerca de Netsh, vea La utilidad de línea de comandos Netsh.

Usar asignaciones estáticas

Actualizado: enero de 2005

Se aplica a: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

Usar asignaciones estáticas

Las entradas de asignación de nombre a dirección pueden agregarse a WINS de dos formas distintas:

• Dinámicamente: los clientes con WINS se ponen en contacto directamente con un servidor WINS para registrar, liberar o renovar sus nombres NetBIOS en la base de datos del servidor.
• Manualmente: un administrador, mediante una consola WINS o con herramientas de línea de comandos, agrega o elimina entradas de asignación estática en la base de datos del servidor.

Las entradas estáticas sólo son útiles cuando hay que agregar una asignación de nombre a dirección a la base de datos del servidor para un equipo que no usa directamente WINS. Por ejemplo, en algunas redes, los servidores que usan otros sistemas operativos no pueden registrar un nombre NetBIOS directamente en un servidor WINS. Aunque esos nombres se pueden agregar y resolver con un archivo Lmhosts o mediante consultas a un servidor DNS, también existe la posibilidad de usar una asignación de WINS estática.

Migrar asignaciones estáticas a dinámicas

A diferencia de las asignaciones dinámicas, que caducan y se quitan de WINS automáticamente con el paso del tiempo, las asignaciones estáticas pueden permanecer en WINS de forma indefinida a menos que se lleve a cabo una acción administrativa.

De forma predeterminada, si durante un proceso de actualización WINS recibe una asignación de tipo dinámico y otra de tipo estático para el mismo nombre, conservará la estática. Sin embargo, puede utilizar la característica Sobrescribir asignaciones estáticas únicas en este servidor (migrar), que se incluye en WINS, para cambiar ese comportamiento.

Por ejemplo, en la ilustración siguiente se demuestra el comportamiento predeterminado de migración de un servidor WINS, WINS-A, cuando recibe una solicitud de registro de un cliente WINS, Host C, que desafía a una asignación estática ya existente en la base de datos del servidor.

En este ejemplo, WINS-A impide el registro del cliente y la actualización de la información asignada estáticamente para el equipo Host C. En la ilustración siguiente se repite la misma situación pero, en este ejemplo, la característica de migración ha sido activada en WINS-A.

Como se muestra en la ilustración modificada, al habilitar la característica de migración en WINS-A se permite que las asignaciones estáticas introducidas anteriormente para Host B y C sean sobrescritas por los equipos cliente WINS que tratan de registrarse dinámicamente, con lo que se actualizan las entradas correspondientes a esos nombres. Esta característica es útil para simplificar la actualización de clientes NetBIOS antiguos, del tipo nodo b (sólo de difusión), que se actualizan posteriomente para hacerlos compatibles con WINS.

Importante

• No agregue nunca asignaciones estáticas para equipos que pueden usar directamente WINS. De hacerlo, se pueden producir problemas, como tareas adicionales necesarias para migrar, eliminar o desechar esas asignaciones en un entorno WINS con replicación.

Notas

• Puede agregar entradas estáticas de forma interactiva mediante la consola WINS, herramientas de línea de comandos o si importa un archivo Lmhosts.
• La característica Sobrescribir asignaciones estáticas únicas en este servidor (migrar) se diseñó principalmente para migrar registros de clientes antiguos que no son WINS y que no se podían registrar por sí mismos en WINS. Algunos nombres de grupo especiales, como los nombres de dominio [1Ch], no se ven afectados por esta configuración.

3.-Configurar la replicación WINS

Antes de configurar la replicación (o réplica), debe diseñar y repasar detenidamente la topología de replicación que va a utilizar en WINS. En el caso de redes de área extensa (WAN), esta fase de preparación puede resultar fundamental para el éxito de la implementación y utilización de WINS. En general, WINS ofrece las siguientes opciones y posibilidades para que elija la que prefiera al configurar la replicación:

• En el caso de un entorno WAN, puede configurar la replicación WINS manualmente.
• En el caso de redes locales de gran tamaño, puede ser aconsejable configurar WINS de forma que la replicación se produzca en un entorno LAN.
• Si se trata de instalaciones de LAN pequeñas o limitadas, puede habilitar y usar la configuración automática de asociados de WINS para simplificar la configuración de la replicación.
• En instalaciones de mayor tamaño o más globales, puede configurar WINS a través de dominios Windows NT en los que no se confía.

Replicación a través de redes de área extensa

Las dos cuestiones más importantes relativas al planeamiento que deben tenerse en cuenta al configurar la replicación WINS son:

• Si va a realizarse a través de vínculos WAN de baja velocidad.
• El período requerido para que todos los cambios replicados en la base de datos WINS converjan y se consiga coherencia en la red.

La frecuencia de la replicación de la base de datos WINS entre los servidores WINS es uno de los aspectos más importantes del planeamiento. La base de datos del servidor WINS debe replicarse con la frecuencia suficiente para garantizar que el tiempo de inactividad de un único servidor WINS no llegará a afectar a la confiabilidad de la información de asignación en los restantes servidores WINS. Sin embargo, el intervalo de tiempo entre replicaciones no debe llegar a ser tan reducido que interfiera con el rendimiento de la red.

La topología de la red puede influir al decidir la frecuencia de la replicación. Por ejemplo, si la red tiene varios concentradores conectados entre sí por medio de vínculos WAN relativamente lentos, puede configurar la replicación de la base de datos WINS de forma que se realice con menos frecuencia entre los servidores WINS situados en los vínculos lentos que en aquellos otros que forman parte de una red de área local o están situados en vínculos WAN rápidos. De este modo se reduce el tráfico en los vínculos lentos y se eliminan problemas de congestión entre el tráfico de replicación y las consultas de nombres de clientes WINS.

Por ejemplo, como se demuestra en la ilustración siguiente, los intervalos usados al configurar la replicación de extracción en los servidores WINS pueden calcularse en función de la proximidad entre los servidores y la probabilidad de que haya o no un vínculo de alta velocidad que conecte entre sí a los servidores configurados como asociados de replicación.

En este ejemplo, dos servidores WINS (SEA-WINS y ATL-WINS) están situados en Seattle y Atlanta. Otros dos servidores (MEX-WINS y SYD-WINS) están situados fuera de Estados Unidos, en Ciudad de México y Sydney. Dado que SEA-WINS y ATL-WINS están conectados por medio de un vínculo WAN de alta velocidad, pueden configurarse para que la replicación tenga lugar cada hora. En el caso de los servidores ubicados fuera de Estados Unidos, los intervalos de replicación pueden ser mayores, de entre 3 y 12 horas, ya que estas conexiones se realizan a través de vínculos de baja velocidad.

Planear el período de convergencia

El período de convergencia es el tiempo necesario para replicar una nueva entrada en una base de datos WINS desde el servidor WINS propietario de la entrada a todos los restantes servidores WINS en la red. Al planear la creación de nuevos servidores WINS, debe decidir cuál es el período de convergencia aceptable en la red.

En el ejemplo anterior, si un cliente WINS de Seattle registra su nombre en el servidor WINS que aparece en la ilustración como SEA-WINS, otros clientes WINS de ubicaciones remotas podrían hacer una consulta en busca de ese nombre de cliente y no encontrarlo en WINS. En algunos casos, si la dirección del cliente ha cambiado, las ubicaciones remotas sólo tendrían, en las bases de datos de su servidor local, una asignación correspondiente a la antigua dirección IP del cliente.

Los clientes WINS que realicen una consulta en cualquiera de los otros servidores WINS de la ilustración (es decir, en ATL-WINS, MEX-WINS o SYD-WINS) sólo recibirán una respuesta positiva y correcta cuando la asignación nueva o actualizada se haya replicado totalmente desde el servidor WINS propietario de la misma, SEA-WINS, en todos los demás servidores. Las replicaciones desde SEA-WINS pueden iniciarse de dos formas distintas:

• Se envía un desencadenador de replicación de inserción según la frecuencia de actualizaciones realizadas en SEA-WINS.
• Se envía un desencadenador de replicación de extracción a los restantes servidores WINS según el valor seleccionado en Intervalo de réplica dePropiedades de Asociados de replicación en SEA-WINS.

Con esta configuración, una entrada nueva o actualizada en SEA-WINS sólo se replicará cuando caduque el intervalo de la replicación de extracción, aunque las consultas que se hagan en sitios remotos en busca de la asignación del nuevo nombre puedan no dar resultado hasta más tarde. La causa es que el intervalo de replicación para ATL-WINS es de una hora, de tres horas para MEX-WINS y de doce horas para SYD-WINS. En este caso, el período de convergencia de WINS se calcula de la siguiente forma:

12 hours + 2 * (1 hour) = 14 hours

En realidad, las solicitudes de consultas de nombres pueden obtener un resultado antes de que transcurra el período de convergencia. Esto sucede cuando las entradas se replican a través de una ruta más corta que la correspondiente al peor caso. También sucede cuando se supera el umbral deNúmero de cambios en el Id. de versión antes de la réplica, en la configuración de la replicación de inserción, antes de que caduque el Intervalo de réplica en la configuración de la replicación de extracción. En este caso, la replicación de la entrada nueva se produce antes. Cuanto más larga es la ruta de replicación, mayor es el período de convergencia.

Notas

• Cuando todos los administradores hayan configurado su servidor WINS, puede usar la opción Replicar ahora (en la consola WINS) para iniciar inmediatamente la replicación entre los servidores WINS configurados.
• Cuando se produce la replicación, puede utilizar la opción Mostrar registros para ver los registros de la base de datos de un servidor WINS remoto. Sin embargo, para realizar cambios en la base de datos WINS remota, debe haber iniciado una sesión en una cuenta que tenga los derechos de usuario necesarios en los respectivos dominios a los que pertenecen ambos servidores implicados.
• La replicación también se puede producir entre dos servidores independientes y aislados que formen parte de un mismo grupo de trabajo.

Replicación a través de redes de área local

Al configurar la replicación WINS en redes de área local (LAN), las cuestiones que se deben tener en cuenta son similares a las que se han mencionado en los entornos WAN, aunque menos críticas.

Dado que la velocidad de los vínculos de red que componen las LAN es superior a la de las redes WAN, puede ser admisible un aumento de la frecuencia de replicación de la base de datos WINS; para ello, se optimizan los parámetros de inserción y extracción para los asociados de replicación que actúan en la LAN. En los servidores asociados de replicación de inserción o extracción, esto se consigue al reducir los valores de Número de cambios en el Id. de versión antes de la réplica y de Intervalo de réplica con respecto a los que se utilizarían en el caso de asociados situados en vínculos más lentos de redes WAN.

Por ejemplo, entre asociados de replicación en redes LAN puede habilitarse en muchos casos que WINS utilice una conexión persistente entre los servidores. Si no se utilizara una conexión persistente, el contador normal de actualización tomaría un valor predeterminado mínimo de 20. En el caso de una conexión persistente, puede especificarse un valor menor para el contador de actualización.

Después, puede especificar un número mucho menor (entre uno y tres, por ejemplo) para el parámetro Número de cambios en el Id. de versión antes de la réplica que determina cuándo debe enviar WINS un desencadenador de replicación de inserción al otro asociado. En el caso de asociados de extracción, puede dar al parámetro Intervalo de réplica un valor en minutos, en lugar de en horas.

Como en el caso del planeamiento de la replicación en una red WAN, la base de datos del servidor WINS debe replicarse con la frecuencia suficiente que garantice que el tiempo de inactividad de un único servidor WINS no llegará a afectar a la confiabilidad de la información de asignación en los restantes servidores WINS. Sin embargo, el intervalo de tiempo entre replicaciones no debe llegar a ser tan reducido que afecte al rendimiento de la red.

Si se trata de un entorno con mucho tráfico de red, es aconsejable utilizar una herramienta de supervisión de red, como Monitor de red, para evaluar y determinar cómo optimizar la estrategia óptima de replicación WINS.

Configuración automática del asociado

Puede configurar un servidor WINS para que configure automáticamente otros equipos servidores WINS como asociados de replicación. Con este sistema automático de configuración de asociados, los restantes servidores WINS se detectan cuando se incorporan a la red y se agregan automáticamente como asociados de replicación.

La configuración automática es posible ya que cada servidor WINS anuncia su presencia en la red por medio de multidifusiones periódicas. Estos anuncios se envían en forma de mensajes IGMP a la dirección 224.0.1.24 del grupo de multidifusión (la famosa dirección IP de multidifusión que está reservada para el uso del servidor WINS).

El sistema automático de configuración de replicación supervisa esos anuncios de multidifusión procedentes de otros servidores WINS y realiza automáticamente los siguientes pasos de configuración:

• Agrega la dirección IP de los servidores detectados a su lista de asociados de replicación.
• Configura los servidores detectados como asociados de replicación de inserción y de extracción.
• Configura la replicación de extracción con un intervalo de dos horas en los servidores detectados.

Si se detecta un servidor remoto y se agrega como asociado por medio de multidifusión, se quitará como asociado de replicación cuando WINS se cierre correctamente. Para que la información de un asociado automático esté aún disponible al reiniciar WINS, debe configurar manualmente los asociados.

Para configurar manualmente la replicación con otros servidores WINS, se usa la consola WINS con el fin de especificar las funciones de cada asociado y la información correspondiente.

Notas

• La configuración automática de asociados suele ser más útil en redes pequeñas, como puede ser el caso de entornos LAN con una única subred. Sin embargo, también puede usarse en redes enrutadas. Para que la multidifusión WINS tenga lugar en redes enrutadas, el reenvío del tráfico de multidifusión se realiza mediante la configuración de enrutadores para cada subred que reenvían el tráfico de multidifusión al grupo de multidifusión reservado del servidor WINS. La dirección IP de destino para este grupo es 224.0.1.24 entre subredes enrutadas.
• Dado que los anuncios periódicos de multidifusión entre servidores WINS pueden aumentar el tráfico en la red, la configuración automática de asociados sólo se recomienda cuando el número de servidores WINS instalados en la red accesible es pequeño (normalmente, tres o menos).

Replicación entre dominios en los que no se confía

Es posible establecer un sistema de replicación WINS entre uno o varios servidores WINS pertenecientes a dominios entre los que no existe una relación de confianza. Para ello, no es necesario que disponga de una cuenta de usuario válida en el dominio en el que no confía. Para configurar la replicación, un administrador de cada servidor WINS debe usar la consola WINS para configurar manualmente ese servidor de forma que permita esta replicación.

4.-MIGRANDO DE WINS A DNS

En este documento se explican los pasos para poder migrar un directorio activo basado en “Windows Server 2003” o “Windows Server 2008” a “Windows Server 2008 R2”, además de indicar los pasos recomendables a seguir o los requisitos a tener en cuenta.

Para migrar el Directorio Activo a Windows 2008 R2, debemos realizar los siguientes pasos:

0. Pre. Confirmar que nuestro Directorio Activo es coherente, la replicación entre todos los controladores de dominio es correcta y estaría bien hacer una pequeña limpieza de los metadatos. Además de cumplir con los requisitos.

Primero de todo, deberemos elevar el nivel funcional de nuestro bosque y de nuestro(s) dominios a “Windows Server 2003”. Desde la consola “Dominios y confianzas de Active Directory”, con botón derecho en cada dominio > “Elevar el nivel funional del dominio…”. Posteriormente realizaremos lo mismo para nuestro bosque desde la misma consola, con botón derecho en “Dominios y confianzas de Active Directory” > “Elevar el nivel funional del bosque…”

Podremos confirmar que nuestro directorio activo funciona correctamente gracias a herramientas tipo:

• DCDIAG. Ejecutando “dcdiag.exe > FICHERO_DE_LOG” para obtener los diagnosticos de cada controlador de dominio. Además analiza el estado de uno o todos los controladores de dominio en un bosque e informa de cualquier problema para facilitar la resolución del mismo.
• REPADMIN. Ejecutando “repadmin.exe /showreps > FICHERO_DE_LOG” comprobaremos que las réplicas entre sitios y entre controladores de dominio es correcta.
• GPOTOOL. Ejecutando “gpotool.exe > FICHERO_DE_LOG” comprobaremos el estado de cada directiva que tengamos en nuestro Directorio Activo, podemos tener fallos en la replicación y tener la misma GPO en diferentes sitios con diferentes configuraciones.

1. Preparación del Directorio Activo para poder soportar controladores de dominio Windows 2008 R2. Previamente nuestros controladores de dominio serán Windows 2000 SP4 o superiores, http://www.bujarra.com/?p=3718

2. Promocionar un nuevo controlador de dominio Windows Server 2008 R2 en nuestro Directorio Activo.

• Para promocionar un servidor Windows 2008 R2 a controlador de dominio deberemos ejecutar la utilidad dcpromo.exe en el servidor y previamente le instalaremos la función de “Servicios de dominio de Active Directory”.
• Una vez tengamos un controlador de dominio de escritura siempre podremos agregar uno de lectura o RODC. Si queremos información sobre cómo usar script’s con dcpromo podemos consultar http://support.microsoft.com/kb/947034 para usar archivos de respuesta.

3. Configuraciones en el servidor DNS:

• Transferencias de zona. Se deben configurar transferencias de zona al nuevo servidor. Desde la consola DNS de cualquer servidor, en las propiedades de la zona nos vamos a la pestaña “Transferencias de zona”, habilitaremos la opción “Permitir transferencias de zona” y “Sólo a los servidores nombrados en la ficha Servidores de nombres”. Nos vamos a la pestaña “Servidores de nombres” y agregamos si no estuviese el servidor DNS destino.
• Cambios en los equipos clientes. Deberemos de cambiar dicha configuración en nuestro servidor DHCP apuntando a los nuevos servidores DNS o directamente en los equipos (si tienen direccionamiento de IP fija) siguiendo este documento:http://www.bujarra.com/?p=802.

4. Migrar FSMO al nuevo servidor. A parte de transferir los roleshttp://www.bujarra.com/?p=3711, deberemos comprobar que el nuevo controlador de dominio es “Catálogo Global”, desde la herramienta “Sitios y servicios de Active Directory” > “Sites” > SITIO > “Servers” > SERVIDOR > Propiedades de “NTDS Settings”, que tenga marcado “Catálogo Global”.

5. Despromoción de los servidores antiguos: Antes de despromocionar un controlador de dominio, tenemos que tener en cuenta qué servicios pueden depender de él, si disponemos de aplicaciones LDAP que apunten a él, o organizaciones Exchange, todo ello deberemos modificar para no tener problemas. Para despromocionar un controlador de dominio Windows 2003 o Windows 2008, ejecutaremos DCPROMO y seguiremos el asistente. Una vez finalizado el asistente y pasado un tiempo de réplica debemos comprobar que no quedan restos y si no, eliminar los antiguos controladores de dominio de las referencias que encontremos, cómo en las transferencias de zona de nuestros servidores DNS o en la Unidad Organizativa de “Domain Controllers”, ni deben salir reflejados en la consola de “Sitios y servicios de Active Directory” además de realizar una limpieza en nuestro Directorio Activo. Totalmente recomendable usarADSIEdit para una correcta limpieza.

6. Elevación del nivel funcional del bosque y del dominio.

Una vez tengamos todos los controladores de dominio basados en Windows 2008 R2, podremos elevar el nivel funcional del bosque y del dominio(s) a “Windows Server 2008 R2”. Desde la consola “Dominios y confianzas de Active Directory”, con botón derecho en cada dominio > “Elevar el nivel funional del dominio…”. Posteriormente realizaremos lo mismo para nuestro bosque desde la misma consola, con botón derecho en “Dominios y confianzas de Active Directory” > “Elevar el nivel funional del bosque…”. Novedades de las nuevas funcionalidades de Windows 2008 R2: AKI.

5.-RESUMEN:

El servidor WINS debe tener una dirección IP fija para que un ordenador cliente de WINS pueda enviar un mensaje al servidor WINS y solicitar la dirección IP del ordenador con el cual necesita comunicarse. Este mensaje no es una difusión, porque el cliente sabe la dirección IP del servidor WINS y le envía el mensaje directamente. De la misma forma, el servidor WINS conoce también la dirección IP del ordenador que envió la petición y le contesta directamente a ésta.

6.-RECOMENDACIONES:

Si mueve los archivos WINS a otra carpeta o si crea una carpeta nueva para los archivos de copia de seguridad, cree una lista de control de acceso para las nuevas carpetas que contenga únicamente la cuenta del sistema local y el grupo Administradores. Asegúrese también de que la nueva carpeta no hereda permisos no deseados de cualquier otra carpeta que esté por encima en el Explorador de Windows.

No almacene archivos WINS en carpetas personales (Mis documentos o Mis imágenes), ni en una subcarpeta de una carpeta personal.

Almacene los archivos de la base de datos WINS y los de copia de seguridad en un equipo que sea físicamente seguro y esté protegido frente a accesos no autorizados.

Active la auditoría de archivos para archivos WINS concretos con el fin de controlar qué usuarios y grupos obtienen acceso a esos archivos. Para obtener más información, vea Aplicar o modificar la configuración de directiva de auditoría de un archivo o carpeta local.

No mueva los archivos WINS a un dispositivo de almacenamiento remoto ni los asigne a una unidad o dispositivo de almacenamiento externo para el que no se haya creado ninguna lista de control de acceso. No mueva ni copie tampoco los archivos WINS en un sitio FTP anónimo ni en cualquier otra ubicación desprotegida.

7.- CONCLUSIONES:

En conclusion, WINS convierte los nombres NetBIOS a direcciones IP en una LAN o WAN.
Al igual que DNS, el Windows Internet Naming Service emplea un cliente distribuido o sistema del servidor para mantener la asignación de nombres de equipos a las direcciones IP.
Los clientes de Windows pueden ser configurados para utilizar un servidor WINS principal y uno secundario que se actualice dinámicamente con nombre y dirección IP cuando las computadoras entran y salen de la red. El comportamiento dinámico de WINS le permite ser compatible con redes DHCP. Los administradores de red generalmente instalan WINS junto con DHCP.