Como no es la primera vez que me pasa, y he visto en varios foros que el problema se repite a menudo, voy a exponer la forma en que he solucionado este problema, y que, al menos a mí, me ha funcionado.
El problema se produce cuando, con una tarjeta Nvidia Geforce y determinadas versiones de los drivers de Nvidia (con unas ocurre el problema y con otras no, independientemente de que sean Beta o WHQL), tenemos una salida DVI conectada a un monitor y la salida S-Video conectada con un cable S-VHS a un televisor convencional. Configuramos la TV como monitor secundario extendiendo el escritorio y la imagen se ve en blanco y negro (tonos de gris, mejor dicho).
Lo primero que se me ocurre, por lógica, es que el driver no ha detectado correctamente el país y ha configurado la salida de TV en formato NTSC. Y efectivamente así ha sido, por lo que esa salida, conectada a un televisor PAL, se verá en blanco y negro, salvo que éste soporte también NTSC y esté configurado adecuadamente. Bueno, pues tan sencillo como seleccionar en la configuración de pantalla de Nvidia el formato PAL y guardar la configuración, ¿no? Pues no.
El primer fallo que notamos es que aunque hemos cambiado de NTSC a PAL, el cuadro de selección de frecuencia sigue marcando 29/30 Hz, en lugar de los 25 Hz del PAL, sin darnos esta opción. Cuando guardamos, automáticamente vuelve a mostrar NTSC. Vamos jugando con varias de las resoluciones que nos muestra para la TV hasta que por fin se queda con una en PAL y 25 Hz.
Lo normal es que esto ocurriera a la primera y que la salida de TV se viera en color, y de hecho con unas versiones de driver ocurre así, pero con otras no, con el engorro que supone.
Evidentemente no es un problema de cable, pues el mismo está probado con otro PC conectado al mismo televisor y con la misma tarjeta gráfica (una Geforce 285) y funciona correctamente. De hecho, al iniciar Windows 7, al mostrar el escritorio se ve durante un instante la TV en color, pasando automáticamente a tonos de gris. Si desinstalamos completamente el driver de Nvidia, dejando el driver por defecto que trae Windows 7, la TV se ve en color sin problemas, por lo que está claro que el problema es del driver de Nvidia.
Lo primero que noté es que al cambiar el modo de la segunda pantalla de extensión de escritorio a clonado, la TV pasa a verse en color, pero si volvemos a cambiarla a extensión de escritorio, vuelve a gris, por mucho que intentemos cambiar los parámetros de configuración.
La solución que encontré entonces es la siguiente: en primer lugar, desinstalamos completamente los drivers de Nvidia, y una vez reiniciado el PC, eliminamos cualquier rastro, tanto en “Archivos de Programa” como en las ramas del registro HKEY_LOCAL_MACHINE\Software como en HKEY_CURRENT_USER\Software (recordar que en 64 bits también podemos encontramos subramas en Software\Wow6432Node). Una vez hecho reinstalamos el último driver de Nvidia y reiniciamos el PC.
Tras reiniciar, el driver configura únicamente la pantalla principal (el monitor), así que entramos en la configuración de Nvidia y nos vamos a la rama de configuración de múltiples pantallas. Si lo que queremos es extender el escritorio, haremos justo lo contrario, es decir, clonar la pantalla principal en la televisión (nos da igual que nos limite por ahora la resolución a 1024x768). Si el driver tiene el problema, no nos saldrá ninguna imagen en la TV (ésta dirá formato incorrecto o algo similar, o nada) o saldrá en gris, y estará marcado NTSC y 29/30 Hz. Lo que haremos es cambiar a PAL e ir seleccionando resoluciones de las que nos muestra, hasta que veamos que con una nos aparecen los 25 Hz en la selección y la TV nos muestra la imagen en gris (algo es algo); es el momento de guardar la configuración.
Tan sólo nos queda una cosa por hacer, pues lo que queríamos no es la pantalla clonada. Siempre en la configuración de pantalla de Nvidia, vamos a la configuración de múltiples pantallas y cambiamos de clonado a extensión del escritorio, aplicamos, y vemos que “milagrosamente” mantiene la última resolución y PAL seleccionadas, y además la imagen cambia a color, que es lo que queríamos.
Evidentemente la solución ideal sería que Nvidia programara correctamente esta característica en sus drivers, pero parecen pensar que todos tenemos ya televisiones planas de alta definición con entradas HDMI. Para los que todavía aguantamos con televisores CRT convencionales, habrá que seguir usando truquillos como éste para poder seguir viendo la salida conectada a la TV correctamente.
Una nueva promoción de Microsoft en la que nos propondrán retos a resolver, y con resultado de premios muy jugosos (subscripciones Visual Studio 2010 con MSDN Premium).
No cuesta nada participar, y, además de interesante, puede resultar muy productivo.
http://msdn.microsoft.com/es-es/net_minds.aspx
Preparar un pendrive para poder instalar Windows 7 arrancando un equipo con un el mismo es sencillo. Para ello necesitaremos un pendrive (evidentemente) de al menos 4 Gb, un equipo con Vista o Windows 7 y el DVD de Windows 7.
Una vez conectado el pendrive, abrimos una ventana de comando como administrador, y en primer lugar ejecutamos el comando DISKPART.
Una vez en el símbolo DISKPART>, obtenemos el Id del pendrive con el subcomando LIST DISK
Suponiendo que el identificador sea el 6, pasamos a ejecutar los siguientes comandos, siempre dentro de DISKPART:
select disk 6
clean
create partition primary
select partition 1
active
format fs=NTFS
assign
exit
El siguiente paso es hacer el pendrive autoarrancable, para lo que introducimos el DVD de Windows 7 (p.e. Unidad D:) y en la ventana de comando nos movemos a la carpeta boot del mismo y usamos el comando bootsect (asumo que el pendrive es la unidad h:):
d:
cd d:\boot
bootsect /nt60 h:
y cerramos la ventana de comando.
Ahora sólo nos queda copiar el contenido íntegro del DVD de Windows 7 al directorio raíz del pendrive y ya estará listo.
Por fin, para instalar Windows 7 con este pendrive en un equipo, sólo nos tenemos que asegurar de que en su BIOS está habilitada la opción de arrancar desde discos USB e iniciar el equipo con el disco USB conectado.
http://microsoftontheissues.com/cs/blogs/mscorp/archive/2009/07/31/windows-7-and-browser-choice-in-europe.aspx
http://news.cnet.com/8301-13860_3-10301299-56.html?part=rss&subj=news&tag=2547-1_3-0-5
Parece ser que Microsoft y la UE han llegado a un acuerdo y las versiones “E” sin navegador no llegarán a salir al mercado. Digan lo que digan algunos, es una muy buena noticia para el consumidor final, que no recibirá una versión capada en características respecto a lo que se venderá en el resto del mundo.
Lo que sí es una buena idea es que ofrezca la posibilidad de instalar otros navegadores distintos de IE8, y que sea el consumidor quien elija libremente el que quiere instalar o desinstalar (caso de IE8 si así lo desea), pero no la idea inicial de que el sistema operativo se vendiese sin ningún navegador instalado. Había opciones como descargarlo por ftp (a ver quién le explica a la sra María del quinto lo del fetepé), pero si bien son sencillas para un usuario medio o avanzado, no lo son para el usuario ocasional o primerizo, quien se podría sentir frustrado en su primera experiencia.
Y la gran pega que yo le veía a las versiones "E” es la imposibilidad de actualizar un Vista previamente instalado en el equipo. Como el Vista dispone de IE instalado, y la versión “E” no tiene posibilidad de actualizarlo, la opción consistía en vender en la UE solamente la versión de instalación nueva, sin posibilidad de actualización. Aunque personalmente prefiero la instalación en limpio, hay muchos casos en que un usuario prefiere la actualización que le mantenga todos los programas instalados con sus configuraciones, cuya migración a un sistema nuevo, sobre todo en el caso de los juegos y sus partidas guardadas (una locura, pues cada uno lo hace en un lugar diferente) puede ser una experiencia desoladora.
Por fin ha anunciado Microsoft la finalización de Windows 7. El próximo 6 de agosto estará disponible para descarga en la web de subscriptores de MSDN y Technet, siendo la fecha oficial de lanzamiento el 22 de octubre.
También estará disponible en las mismas fechas la versión servidor equivalente, Server 2008 R2, que sin ser un cambio radical como el que supuso el salto de Server 2003 a 2008, trae interesantes novedades que iremos viendo poco a poco una vez esté disponible en su versión final.
En cuanto a mi experiencia personal con las versiones previas de Windows 7, la verdad es que ha sido muy difícil encontrar errores a partir de la RC. Es tremendamente estable, rápida y compatible hacia atrás (sin comentar la opción añadida de Virtual PC con la imagen de XP). Personalmente, en mis ordenadores principales tanto de casa como del trabajo tengo instalada la RC (7100) y me funciona prácticamente todo sin problemas, tanto, que en casa ni siquiera he vuelto a arrancar la partición de Vista. La compatibilidad de los juegos es excelente, así como de la mayor parte de los programas de escritorio. En el PC del trabajo he tenido alguna pega en temas de compatibilidad, generalmente en lo que respecta a la instalación de aplicaciones de seguridad corporativas que se instalan mediante GPO y que todavía no son compatibles con W7, lo mismo que con aplicaciones de instalación remota de programas (en particular el HP Radia Software Manager, que en la versión contratada todavía no es compatible con Vista/W7). Sin embargo, en estos casos ha funcionado perfectamente la imagen de XP de Virtual PC, por lo que, aunque no sea la opción perfecta, sí vale como alternativa temporal.
Seguramente oiremos en los próximos meses que Windows 7 es lo que tenía que haber sido Vista cuando salió, y seguramente habrá algo de razón. Vista sufrió una campaña de desprestigio desde antes de salir al mercado, lo cual perjudicó en gran manera a este Sistema Operativo de Microsoft. Yo mismo reconozco que no ha sido el mejor sistema operativo que ha pasado por mis manos, aunque con un poco de maña en afinar su configuración, y sobre todo tras los service pack, ha mejorado bastante. De todas formas, en comparación, la experiencia con W7 es mucho más gratificante, sobre todo con temas como el “Grupo de Trabajo”, que facilita de forma impresionante la compartición de recursos entre los ordenadores de casa, cosa que en Vista y XP no estaba precisamente muy bien conseguida.
Un usuario me planteó en los foros de Server cómo evitar con un script que un usuario inicie sesión en TS desde determinada subred, y permitírselo sólo desde otra.
Para ello, el problema está en averiguar desde dentro de la sesión remota la dirección IP del equipo cliente desde el que se ha lanzado la sesión TS. Para hacerlo nos vamos a apoyar en la utilidad gratuita ENVTSCIP, que se puede descargar desde el siguiente enlace:
http://www.ctrl-alt-del.com.au/CAD_Utils.htm#Freeware
De todas estas utilidades, usaremos ENVTSCIP.EXE, ejecutable que habrá que poner en el servidor, en una ruta que esté en el path de todos los usuarios, como puede ser windows\system32. El archivo bat en que copiaremos el script lo asignaremos como script de inicio de sesión para los usuarios que se conectarán de forma remota por TS y cuyo origen queramos controlar, lo que podemos hacer mediante GPO, en su perfil, o en el menú de inicio de todos los usuarios. En función del número de usuarios a los que queramos aplicar esto y del número de servidores TS en los que puedan acceder nos será más cómoda una cosa que otra.
Previamente necesitaremos saber cual es el rango de IP,s de las subredes desde las que puede acceder el usuario, pues en función de ello variará la línea nº 6, “set remotenet=%remoteip:~,9%”. En este ejemplo he asumido que las direcciones IP a tratar son del tipo 192.168.1.x, clase C, por lo que la subred la definen las tres primeras cifras decimales, que en el ejemplo, incluyendo los puntos, suponen 9 caracteres. Si fuera 10.162.x.x, entonces el número de caracteres para esa subred sería 6, y así. Si queremos complicar el tema con subredes de distinto tamaño, o con máscaras que no sean múltiplos de 8 bit, todo consiste en variar un poquito el script para adaptarlo.
Una vez asignado el script, si el usuario inicia sesión TS desde un PC en la red correcta, la sesión iniciará sin problemas, pero si lo hace desde la que no queremos, la sesión se cerrará automáticamente.
Rem Inicio del Script que se ejecutará en el servidor TS. En la segunda línea de código cambiar NOMBRESERVIDORTS por el nombre real.
echo off
if not %computername% EQU NOMBRESERVIDORTS goto fin
for /f "tokens=1,2* delims=:" %%i in (' envtscip ^| find "WTS" ') do set remoteip=%%j
set remoteip=%remoteip:~1%
set remotenet=%remoteip:~,9%
if %username% EQU Pedro goto usuariored1
if %username% EQU Juan goto usuariored1
if %username% EQU Manolo goto usuariored2
if %username% EQU Paco goto usuariored2
goto fin
:usuariored1
if %remotenet% EQU 192.168.2 goto cerrarsesion
goto fin
:usuariored2
if %remotenet% EQU 192.168.1 goto cerrarsesion
goto fin
:cerrarsesion
shutdown /l
:fin
Rem Fin del Script
El programa de Asistencia Remota que trae Windows 7 tiene una nueva opción de conexión, a la que llama Easy Connect, y que está pensada para simplificar mucho el proceso de solicitud de conexión remota. Sin embargo, al probarlo por primera vez, comprobé que la opción de Easy Connect me aparece deshabilitada.
El problema estaba en que para que pase el router hay que habilitar la redirección del puerto 3540, y a ser posible en modo port range triggering, para que valga para cualquier PC (en cada router se puede llamar de distinta manera, pero básicamente se trata de que el router sea capaz de discriminar el equipo que ha lanzado un datagrama, y la respuesta a través del puerto en cuestión la redirige hacia ese equipo). Una vez hecho, la opción de Easy connect ya no aparece deshabilitada, y la verdad es que ha sido muy sencilla de usar.
Hay que tener cuidado con algunos cortafuegos distintos al de Windows, ya que no se creaba en ellos la regla de permiso correspondiente. Si no conecta mediante este sistema, hay que repasarlo y dar permiso a la asistencia remota y al puerto indicado.
José Antonio
Ahora que ya es pública la beta de Windows 7, creo de lo más interesante divulgar esta entrada del blog de Tim Sneath, en la que expone una serie de secretillos de Windows 7 de lo más interesante. En particular, el que dice como hacer que el icono de Messenger aparezca en el system tray en lugar de anclado a la barra de tareas.
http://blogs.msdn.com/tims/archive/2009/01/12/the-bumper-list-of-windows-7-secrets.aspx
Ayer, al ir a actualizar un Server 2003 a 2008, me encontré con el problema de que al estar instalado Windows Powershell en ese servidor, el programa de instalación de 2008 indicaba que no podía seguir y abortaba la instalación antes de empezar.
Bien, tan sencillo como ir al panel de control y desinstalarlo, ¿no? Mi sorpresa es que, aun activando que se muestren las actualizaciones en la lista de programas instalados, no aparecía la posibilidad de desinstalar ese programa.
Buscando un poco por internet encontré la causa: si después de la instalación de Windows Powershell se instala en el servidor un Service Pack (y en mi caso lo había hecho en su día con el SP2), desaparece de la lista de programas instalados la posibilidad de desinstalar Powershell, y no parece nada recomendable desinstalarlo a mano borrando archivos y entradas en el registro.
La solución pasa por desinstalar el SP2, tras lo cual vuelve a aparecer en el panel de control la posibilidad de desinstalar Powershell y sus MUI (actualizaciones KB926139 para la versión en inglés, KB926140 para las localizadas y KB926141 para el MUI). Una vez hecho, la actualización a 2008 se realizó sin mayor problema.
4.- CREAR EL PRIMER DOMINIO
Ahora que ya hemos visto algunos conceptos, es el momento de crear nuestro primer dominio. Para ello necesitamos una máquina adecuada y el software servidor, sea Server 2000, 2003 ó 2008. De todos los servidores que montemos en un dominio, al menos uno tiene que configurarse como Controlador de Dominio (DC, de Domain Controller), aunque es más seguro disponer de más de uno, más aún si tenemos nuestro dominio repartido en varias redes o Sitios de AD. A los servidores del dominio que no sean DC,s les llamaremos "Servidor Miembro".
Para que un servidor pueda ser promovido a Controlador de Dominio es preciso que tenga instalados los archivos necesarios para ello. En Server 2000 y 2003 lo están por defecto, mientras que en Server 2008 es necesario primero usar el asistente de instalación de roles para añadir los servicios del Directorio Activo. Por otro lado, he comentado antes que el Directorio Activo depende al cien por cien de una estructura DNS, por lo que será preciso crear ésta de forma adecuada. Aunque podemos hacerlo a mano, la verdad es que lo mejor es dejar que el propio asistente instale y configure el servicio "Servidor DNS" en el equipo durante el propio proceso de promoción. De hecho, en Server 2008, si le instalamos el rol de servicios de AD, veremos que ni siquiera nos va a permitir instalar el rol de servidor DNS por nuestra cuenta, sino que lo hará él mismo cuando promocionemos el servidor.
Con el servidor iniciado, y configurada su tarjeta de red con una dirección IP fija y poniéndole como servidor DNS principal a sí mismo, pinchamos en Inicio - Ejecutar y tecleamos el comando "dcpromo".
Tras comprobar que se han instalado previamente los archivos correspondientes al rol de servidor de directorio activo, se inicia el asistente. Para controlar todos los aspectos seleccionaremos la instalación en modo avanzado.
Nos muestra una advertencia de compatibilidad con determinados clientes antiguos, que generalmente podremos ignorar. Si nos afecta, el artículo indicado tiene información más completa.
Lo primero que nos pregunta el asistente es qué es lo que queremos hacer. Desde crear un bosque nuevo, a añadir un nuevo controlador de dominio a uno ya existente, crear un subdominio, o crear un nuevo árbol en un bosque existente.
En nuestro caso, como estamos creando el bosque desde cero, seleccionaremos la opción de crear un dominio nuevo en un bosque nuevo.
El resto de opciones en esta pantalla está muy claro: si queremos añadir más controladores de dominio a un dominio que ya existe para tener redundancia usaremos la opción de la segunda imagen; para crear un árbol de dominios nuevo que pertenezca a un bosque existente, la tercera y para crear un subdominio de otro que ya existe la cuarta.
El siguiente paso es dar un nombre FQDN (Full Quallified Domain Name) al bosque, que coincide con el nombre del dominio raíz. Debemos usar un nombre con puntos intermedios, ya que en caso contrario aparecen algunos problemas secundarios posteriormente, y procuraremos que el nombre sea representativo de nuestra organización.
Una vez hecho esto, tenemos que seleccionar el nombre NETBIOS del dominio. Nos ofrece por defecto la primera parte del nombre FQDN, pero podemos poner cualquier nombre que cumpla las reglas de nombres NETBIOS, y por supuesto, que no esté ya en uso.
Como vemos, y a pesar de que ya cuando se lanzó Windows 2000 con el Directorio Activo se pretendía eliminar progresivamente NETBIOS y basar todo en resolución de nombres DNS, la realidad es que todavía hay muchas aplicaciones que se basan en resolución de nombres NETBIOS. Es posible montar un entorno cien por cien DNS, pero a la hora de la verdad está limitado, ya que no tendremos certeza de que funcionen correctamente aplicaciones que requieran resolución NETBIOS (hay antivirus de red que se basan en esto para gestionar los clientes en que están instalados, por ejemplo), y algunas ni se instalarán (El propio Microsoft System Center Configuration Manager basa gran parte de su código en NETBIOS).
La siguiente decisión que tenemos que tomar es la elegir el nivel funcional, tanto del bosque como del primer dominio. Por explicarlo en pocas palabras, un dominio o un bosque proporciona unas determinadas funcionalidades en función de la versión de sistema operativo servidor en la que se basan. A más moderno el sistema operativo, más funcionalidades aporta su directorio activo. El total de funcionalidades correspondientes a un sistema operativo en un dominio se consigue cuando todos los DCs del dominio tienen al menos ese sistema operativo, y el de un bosque se consigue cuando todos sus dominios tienen el nivel funcional correspondiente o superior.
Si montamos un dominio nuevo con un servidor 2008, lo lógico es seleccionar el nivel funcional de Server 2008 tanto para el dominio como para el bosque, salvo que necesitemos instalar expresamente un DC con un sistema operativo anterior (recalco lo de que sea un DC, ya que los servidores miembro pueden tener cualquier versión anterior).
Si partimos de un bosque con dominios en nivel 2000, éstos sólo podrán tener DCs con Windows 2000 o superior, pero aunque tengamos en el dominio DCs con 2003 ó 2008, las funcionalidades del dominio seguirán siendo las correspondientes a Windows 2000. En el momento en que hayamos migrado o actualizado todos los DCs de un dominio del bosque al menos a Server 2003 podremos modificar el nivel funcional del dominio al de Server 2003, o al de Server 2008 si ya sólo tenemos DCs con este Sistema Operativo. La operación de cambiar el nivel funcional se denomina "elevar" el nivel funcional del dominio, y una vez hecha no tiene vuelta atrás.
Para elevar el nivel funcional del bosque a Server 2003 es preciso que todos los dominios del bosque tengan el nivel funcional 2003 o superior, y para nivel funcional 2008, todos los dominios del bosque tienen que tener nivel funcional 2008. Más tarde veremos cómo se realiza la operación de elevar el nivel de dominios y bosque.
Y para el dominio, seleccionamos el nivel que deseemos
La siguiente decisión es determinar si queremos que el controlador de dominio sea servidor DNS. Para el primer DC es lo más aconsejable, aunque no imprescindible, y para el resto de DCs lo mejor es hacer primero una planificación detallada de cómo queremos nuestra topología de servidores DNS en la red.
El primer DC del bosque tiene obligatoriamente el rol de Catálogo Global del bosque (GC), que es una funcionalidad adicional de los DCs que hacemos que sean GC por la que además de toda la información de todos los objetos correspondientes a su dominio, también albergan un subconjunto de los atributos de todos los objetos de todos los dominios del bosque.
Por fin, y sólo en los servidores 2008, aparece la posibilidad de que el DC sea de tipo RODC (Read Only Domain Controller), muy útil en situaciones como la de enviar un DC a una sede remota con conexión intermitente en la que no queremos que se pueda modificar nada del directorio, sino tan sólo usarlo. Como se ve en la figura, obviamente en primer DC de un dominio tiene que ser obligatoriamente de tipo lectura/escritura, de ahí que la opción esté desactivada.
Al pulsar "siguiente", el equipo ha detectado que tiene direcciones ip dinámicas, y nos avisa que deben ser estáticas. En Server 2000 y 2003 no suele aparecer el mensaje, ya que generalmente habremos puesto previamente una dirección ip fija (aunque si se nos ha olvidado, es el momento de solventarlo). Sin embargo, en Server 2008 nos aparece casi siempre, aunque le hayamos puesto una ipv4 fija, ya que éste también considera las ipv6, y salvo que lo sepamos y le hayamos configurado una ipv6 fija, normalmente no la tendrá configurada así y nos avisará, aunque sin especificar. Si no vamos a usar ipv6 en nuestra red, podemos ignorar el mensaje y decirle que sí, que siga aunque tenga una ip asignada dinámicamente. Eso sí, asegurarse primero de que la ipv4 sí se la hemos configurado fija.
Si detecta que nuestra configuración DNS está integrada en una topología DNS existente, intentará ubicarse en ella. Esto, que cuando creamos el bosque por primera vez no suele tener mayor importancia, es trascendental cuando estamos creando dominios secundarios o nuevos árboles en un bosque existente. Si no es capaz de detectarlo el propio asistente y crear las delegaciones adecuadas, tendremos que crearlas a mano en los servidores DNS que estén por encima en la cadena DNS.
En el caso del primer dominio del bosque, obviamos el mensaje y le decimos que continúe.
Lo siguiente es elegir la ubicación de los archivos del AD. Está recomendado usar discos distintos para cada una de las opciones con el objeto de mejorar el rendimiento (usar distintas particiones del mismo disco no mejora nada), pero la realidad es que salvo en ADs muy grandes y con muchas modificaciones y con gran frecuencia, lo normal es que se puedan poner todos en la misma partición sin que se note en el rendimiento.
La siguiente pregunta es la contraseña para cuando queramos reiniciar el servidor en el modo de restauración de los servicios de directorio. Esta contraseña no tiene nada que ver con la del usuario administrador, y sirve sólo para iniciar en el modo indicado. Este modo de arranque, sólo disponible en los DCs, sirve para realizar tareas de mantenimiento, como, por ejemplo, una restauración del AD en modo autoritativo.
El asistente nos muestra un resumen de lo indicado, tras lo cual comenzarán los trabajos de promoción del servidor a Controlador de Dominio, tal como indican las imágenes a continuación.
Una vez finaliza el proceso nos muestra el mensaje de haberlo hecho, tras lo cual reiniciaremos el servidor.
Tras el reinicio ya podremos iniciar sesión con un usuario administrador del dominio. En el caso del primer DC del bosque, su contraseña coincide con la del usuario "administrador" local que tuviéramos en el equipo antes de promocionarlo.
3.- CONCEPTOS
A esta superestructura que va a albergar todos los recursos de nuestra organización la vamos a llamar bosque (o bosque de dominios). Puede tener un único dominio o varios, según nuestras necesidades. El bosque se caracteriza por tener un esquema (que ahora veremos lo que es) común para todos los dominios del mismo, y gestiona las relaciones entre todos los componentes de cualquier dominio perteneciente al mismo.
El sistema más simple es el de un bosque compuesto por un dominio único. Realmente ésta es la situación más común, ya que gracias a la alta capacidad de organización de un dominio en el Directorio Activo, ha disminuido en gran manera la necesidad en las empresas de mantener dominios independientes para sus componentes.
Este primer dominio del bosque, que se crea al mismo tiempo que este último, es lo que llamaremos "Dominio Raíz del Bosque". Es un dominio más, similar a todos los que posteriormente podamos añadir al bosque, pero tiene dos diferencias fundamentales con el resto: la primera, que una vez creado ya no se puede eliminar mientras queden otros dominios en el bosque, y la segunda, que en éste dominio raíz se gestionan de forma única para todos los dominios del bosque el esquema común y la nomenclatura de todos los dominios del bosque (controla los nombres para evitar que en un momento dado pudiéramos crear un dominio con un nombre ya existente en el bosque).
El bosque está compuesto de objetos. Desde cada dominio definido en el bosque hasta el último usuario o impresora son objetos componentes de esta estructura. Cada uno de estos objetos tiene una serie de atributos, que definen las características de los mismos. Así, por ejemplo para un usuario determinado, le habremos definido un nombre, apellidos, teléfono y un sinfín de atributos más que le identificarán en bosque de forma única.
El esquema es una base de datos del Directorio Activo donde se definen los distintos tipos de objetos que podremos crear en el bosque. A cada uno de estos tipos le llamaremos "Clase", y en ella estarán definidos todos los atributos que luego rellenaremos con los datos propios que identifican al objeto. Por poner un ejemplo, en el esquema tenemos la clase "User", la cual tiene definidos, entre muchos otros, los atributos "Name" y "Phone". Cuando desde la herramienta adecuada decimos al sistema que cree una cuenta de usuario, el sistema crea en AD un objeto usuario basado en la clase "User", con espacio para albergar todos los atributos que lo identifican. En el momento de crear el usuario, rellenamos los datos de aquellos atributos que son obligatorios, y tanto entonces como en cualquier momento podemos ampliar la información rellenando aquellos que no lo son. El hecho de que el esquema sea común a todos los dominios del bosque hace que cuando creamos una cuenta de usuario en un dominio, ésta tiene exactamente los mismos atributos y con las mismas características que las creadas en cualquiera de los otros dominios.
El esquema es algo dinámico. Cuando creamos un bosque, por ejemplo, con un servidor 2003, este Sistema Operativo trae una determinada versión del esquema, por lo que los atributos de los objetos que creemos serán los que estén definidos en esa versión. Posteriormente podemos instalar en el bosque un software, como Exchange, que amplía el esquema para añadir clases completamente nuevas, y añade nuevos atributos a clases ya existentes (por ejemplo, para añadir atributos relacionados con el correo a la clase "User"). Una vez hecha esta modificación del esquema, los objetos nuevos y los creados con anterioridad pasarán a disponer de estos nuevos atributos, con lo que habremos aumentado la funcionalidad de nuestra organización.
Generalmente, cada nueva versión de sistema operativo servidor viene preparada con una versión nueva del esquema de AD, más completa que las anteriores, y siempre conteniendo todo lo anterior más lo nuevo. Cuando creamos un bosque nuevo con la última versión, su Directorio Activo tiene automáticamente el último esquema definido. Sin embargo, si a un bosque definido con el esquema de una versión determinada de Windows, por ejemplo Server 2003, queremos añadirle determinadas funcionalidades correspondientes a versiones más modernas (2003 R2 ó 2008), como que pueda albergar controladores de dominio con Server 2008, nos será preciso en primer lugar ampliar el esquema actual con la versión correspondiente a la última versión que necesitemos tener.
Una vez hemos creado el primer dominio, es posible añadir más dominios al bosque. Sin embargo, lo más importante en esto es realizar a priori una planificación exhaustiva de lo que necesitamos. Tan malo es crear un único dominio mal organizado como empezar a crear subdominios sin ton ni son, que luego complican en exceso la administración centralizada de los mismos.
El concepto que tenemos que tener más en cuenta a la hora de decidir nuestra estructura de dominios es el de la administración única de los objetos de los mismos. Y por única no quiero decir que la haga un solo administrador, pues se pueden delegar permisos de administración a partes del dominio, sino que se tiene una política de administración conjunta para todo el dominio (mismas políticas de contraseñas, administradores centrales del dominio, gestión de las políticas comunes y particulares, etc). Cuando realmente necesitamos tener independencia total, aunque manteniendo la pertenencia al bosque, es cuando crearemos dominios adicionales en el bosque.
Una vez hemos decidido una estructura de dominios en el bosque, vemos que la topología de los mismos es función de la nomenclatura que establezcamos. Partiendo siempre del nombre que hayamos dado al dominio raíz, en el ejemplo "gericom.es", si necesitamos mantener el mismo como sufijo de otros, hablaremos de subdominios (p.e. sevilla.gericom.es), o dominios padres e hijos. Entre todos los que cuelgan de un mismo padre forman lo que en AD se llama un árbol de dominios. En el caso de que queramos crear dominios con una nomenclatura que no esté ligada al dominio raíz, éstos formarán nuevos árboles de dominios (que pueden ser árboles de un único dominio) dentro del bosque.
Un primer detalle a tener en cuenta con esta estructura de dominios es que, dando los permisos adecuados, cualquier usuario de cualquier dominio puede acceder a cualquier recurso ofrecido en cualquiera de los dominios del bosque.
Fijémonos en el gráfico anterior, y en particular en los nombres dados a los dominios. La estructura de nombres coincide con el tipo de nomenclatura de dominios DNS. Aunque son cosas distintas, la estructura de nombres de dominio en el Directorio Activo está totalmente ligada a una estructura de dominios DNS del mismo nombre. De hecho, gran parte de las funcionalidades del Directorio Activo dependen totalmente del servicio DNS y su correcta configuración.
Por fin, en esta estructura podemos definir el dominio como un conjunto de equipos, usuarios y otros recursos que se administran como una entidad única. Debe disponer de al menos un servidor Windows que realice las funciones de Controlador de Dominio, que es un servidor que aloja los servicios correspondientes al Directorio Activo en el dominio.
Hasta ahora hemos hablado de una estructura lógica del bosque, en la que, por ahora, hemos organizado los recursos en una estructura de dominios, pero hay que notar que esta estructura no tiene absolutamente ninguna relación con la estructura física de nuestra red. Del mismo modo podemos tener objetos de un mismo dominio repartidos por múltiples redes, como elementos de distintos dominios dentro de la misma red, con todas las combinaciones que queramos.
Por ello, para reflejar en el AD la estructura física de nuestra red aparece el concepto de Sitio de AD. Un Sitio es un conjunto formado por una o varias subredes que estén unidos entre sí por enlaces de alta capacidad. Nos permitirán por un lado gestionar de forma eficiente las réplicas del AD entre los servidores del propio o distintos Sitios, y también permiten que el inicio de sesión de los usuarios se realice en controladores de dominio del propio Sitio del equipo del usuario de forma preferente.
2.- DE GRUPO DE TRABAJO A DOMINIO
El trabajo en Dominio supone un cambio radical en el concepto de uso de los recursos de la red. En lugar de que cada equipo de la red sea una Unidad de Administración, éstos pasan a ser meros componentes de una única entidad, el dominio, que es en conjunto lo que podríamos llamar una Unidad de Administración Global. De esta forma, en un único punto de administración podemos definir todos los parámetros que necesitemos de comportamiento de todos los recursos que pertenezcan al dominio, y hacer que estos parámetros se distribuyan en la forma que queramos por todos los equipos del mismo.
Tareas tan simples como establecer la longitud de la contraseña de los usuarios, en un grupo de trabajo implica configurarlo en todos y cada uno de los ordenadores, y cada vez que queramos cambiar un parámetro tendremos que volver a pasar por todos los equipos. En un dominio, lo definimos es un único sitio y hacemos que se distribuyan estas modificaciones.
Otra gran ventaja que nos va a proporcionar un dominio es la gestión única de las cuentas de usuario. En un grupo de trabajo, éstas se definen localmente en cada uno de los equipos, en una base de datos de usuarios local. En un dominio, las cuentas se definen en una base de datos centralizada, lo que nos permitirá en todo momento saber el estado de cada una de ellas, y gestionar una política de cuentas común. Una gran dificultad en los grupos de trabajo es compartir recursos en red a usuarios de otros equipos. Para validarse, es preciso hacerlo definiendo en cada equipo el acceso con las credenciales de un usuario y contraseña del equipo que comparte. Si posteriormente en éste se cambia la contraseña, hay que realizar la modificación en todos y cada uno de los equipos que acceden a ese recurso. En un dominio, sin embargo, en el que desde todos los equipos del mismo se puede leer la base de datos de usuarios común, se comparten los recursos con permisos a los usuarios del dominio, y simplemente con estar en la lista de usuarios con permisos ya se puede acceder al recurso compartido, sin tener más que hacer.
Un concepto importante a la hora de trabajar en dominio es el de la pertenencia al mismo. En un grupo de trabajo, tan sólo con conectar un equipo físicamente a la red y ponerle una configuración de red adecuada, ya está en igualdad de oportunidades que los demás para poder acceder a los recursos de la red. En dominio, el primer paso que hay que hacer para poder acceder a todos los recursos del mismo es establecer la pertenencia al dominio del equipo. Es decir, que salvo determinados accesos a recursos compartidos, para aprovechar la inmensa mayoría de lo que nos ofrece un dominio es preciso primero pertenecer al mismo, proceso que podemos hacer que sea totalmente controlado por quién se hace.
El concepto de dominio en las redes Microsoft apareció de la mano de Windows NT, como una base de datos plana en la que definíamos usuarios y equipos, y roles tanto para los usuarios como para los equipos. Este primer concepto de dominio se mantuvo hasta Windows NT 4.0, y con Server 2000 cambió al modelo vigente hasta ahora con Server 2008, el Directorio Activo, en el que nos vamos a centrar.
¿Y por qué este cambio al Directorio Activo? Como he dicho antes, la base de datos de un dominio NT era plana, lo que quiere decir que todos los usuarios y equipos se definen y ven en una única lista, todos juntos. Para dominios pequeños no supone gran problema, pero si empieza a crecer el número de usuarios y equipos, la dificultad de su gestión aumenta de forma considerable. Por otro lado, si queremos relacionar recursos de nuestro dominio con otros dominios de nuestra misma organización, es preciso realizar expresamente una serie de operaciones para poder establecer las relaciones de confianza adecuadas, y en ningún momento vamos a poder gestionar una política común a todos los dominios de nuestra organización.
Con el concepto de Directorio Activo (AD = Active Directory) disminuyen en gran manera esas dificultades; por un lado, en un dominio vamos a poder organizar los recursos en una estructura similar a un árbol de carpetas de archivos, y establecer parámetros comunes a los componentes de cada rama. Por otro lado, la estructura ya no va a estar ligada solamente a un único dominio, sino que comenzaremos definiendo una superestructura común para toda nuestra organización, en la que colgarán todos los dominios que necesitemos para nuestras empresas y departamentos, permitiendo por un lado tener organismos con administración independiente de los demás (cada dominio), pero manteniendo un margen de gestión común a todos los elementos de nuestra organización.
1.- DE DÓNDE VENIMOS
Antes de comenzar a instalar un dominio es preciso saber de qué se trata; para ello, lo mejor es echar un vistazo al pasado y ver cómo se han relacionado los ordenadores con Windows a lo largo del tiempo.
En los tiempos de Windows 3.1 el uso normal de los ordenadores era de forma aislada, basando los intercambios de información en soportes físicos como disquettes de 5"1/4 ó 3 "1/2, y hubo que esperar hasta la versión "Windows 3.1 para trabajo en grupo (1992)" para poder encontrar una versión de Windows enfocada hacia la cooperación en red. Esta versión basaba las comunicaciones en el uso como protocolo principal de Netbeui, un protocolo sencillo que usaba mayoritariamente mensajes de broadcast a la red, no tenía posibilidades de encaminamiento de mensajes a través de routers, pero que en aquel momento era lo más práctico dado que la mayoría de las pequeñas redes que se montaban estaban compuestas por unos pocos ordenadores unidos por cable coaxial.
Con Windows para Trabajo en Grupo se introducía en Windows el concepto de compartición de recursos por la red, de forma muy simple, y con la posibilidad de compartir carpetas mediante contraseñas o, si el equipo se unía a un dominio Windows (que comenzaron a existir casi simultáneamente), estableciendo permisos a usuarios. El protocolo tcpip todavía tardaría unos años en implementarse en Windows.
Evidentemente, había otros sistemas de conexión en red, de los que el más común de encontrar en los 90 era el sistema operativo de red Novell Netware, con el que se extendió en las redes pequeñas y medianas el concepto de Directorio. Microsoft, consciente de la necesidad de organizar las comunicaciones en red, centró sus desarrollos en la familia Windows NT, que apareció en su versión 3.1 allá por el verano de 1993, con una versión Workstation y una Servidor.
Y aquí es donde aparece la gran diferencia entre el Grupo de Trabajo y el Dominio. Un Grupo de Trabajo es un conjunto de ordenadores conectados en red en el que cada equipo, sea cliente o servidor, en una Unidad de Administración en sí mismo. Esto se traduce en que todas las tareas de configuración y administración que queramos hacer en los equipos de nuestro grupo de trabajo tenemos que realizarlas de forma individual en todos y cada uno de los equipos. Para redes pequeñas no supone un gran problema, pero conforme las redes van creciendo los problemas de administración se multiplican.
Además, y hasta la implantación generalizada como sistema operativo cliente de Windows 2000 profesional y posteriormente XP (Windows NT profesional, como cliente, apenas suponía un mínimo porcentaje en comparación con los Windows 9x instalados), el usuario de un ordenador tenía plenos poderes sobre el mismo, salvo que se usaran determinados programas específicos para controlar la configuración, con lo que el laborioso trabajo de configuración realizado por los administradores podía ser fácilmente saltado por los usuarios, más si tenían conocimientos de informática.
Para retomar un poco esto del blog, voy a poner unos artículos dedicados a principiantes en el tema sobre cómo montar un dominio de AD, conceptos básicos y las tareas fundamentales de administración. Procuraré tocar todos los aspectos más usados, para, una vez terminado, acometer algún tema en particular más a fondo, en función del interés que se tenga por los mismos.
Básicamente, las Group Policy Preferences son settings similares a las GPO, pero que se aplican a los equipos cliente sin ser mandatorios, es decir, que
el usuario los puede cambiar después a su gusto. Entre otras cosas, permite establecer mediante GPPs cosas que antes sólo se podían hacer mediante
scripts de inicio de sesión, tales como los mapeos de unidades de red y de impresoras, variables de entorno, recursos compartidos,
creación-modificación-borrado de archivos, accesos directos y carpetas en los ordenadores cliente, modificación de entradas en determinados archivos
.ini, modificaciones en el registro, restricción de uso de dispositivos (por fin), opciones de carpeta y asociaciones de extensiones, preferencias de
internet, gestion de usuarios y grupos locales, configuración de VPNs, opcines de energía, etc., así como la configuración del menú inicio para los
usuarios (las opciones que les aparecerán en el mismo).
Por defecto sólo se aplica a equipos Server 2008 unidos a un dominio en el que al menos haya un DC 2008 desde el que las editaremos. Para los sistemas operativos Vista, XP y 2003 es necesario descargar e instalar un complemento a tal efecto.
Windows XP
http://www.microsoft.com/downloads/details.aspx?familyid=E60B5C8F-D7DC-4B27-A261-247CE3F6C4F8&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=249c1aed-c1f1-4a0b-872e-ef0a32170625&displaylang=en
Windows Server 2003
http://www.microsoft.com/downloads/details.aspx?familyid=BFE775F9-5C34-44D0-8A94-44E47DB35ADD&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=29e83503-7686-49f3-b42d-8e5ed23d5d79&displaylang=en
Windows Vista
http://www.microsoft.com/downloads/details.aspx?familyid=AB60DC87-884C-46D5-82CD-F3C299DAC7CC&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=b10a7af4-8bee-4adc-8bbe-9949df77a3cf&displaylang=en
Ya es público y se puede descargar desde el siguiente enlace
http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=b0c7136d-5ebb-413b-89c9-cb3d06d12674
Recomiendo encarecidamente instalarlo. Llevo ya un tiempo con él en varios equipos y aunque no es un cambio drástico como alguno quisiera hacer ver, se nota mucho el cambio a mejor.
José Antonio Quílez
En un Vista abrimos una mmc y agregamos el complemento Plantillas de Seguridad.
Creamos una nueva plantilla y nos fijamos donde la guarda (por defecto en documentos\security\Templates
Definimos las políticas de cuenta que queremos habilitar y guardamos la plantilla.
Ahora copiamos el .inf al core, por ejemplo a c:\ (lo he renombrado a core.inf)
en la ventana de comando del core tecleamos lo siguiente:
secedit /configure /db secedit.sdb /cfg core.inf
Y pasa a ser el valor de la política local. Este procedimiento nos vale también para cualquier otra política de seguridad que podamos definir en la plantilla.
Como indica el artículo, si durante la actualización de Server 2003 ó R2 a Server 2008 éste detecta un controlador de impresora incompatible y no paramos la actualización, pueden desaparecer todas las colas de impresión, lo cual es bastante engorroso si tenemos muchas en el servidor.
El siguiente artículo explica como hacer un backup de las colas de impresión y restaurarlas tras la actualización a 2008, con lo que se minimiza el problema.
http://support.microsoft.com/default.aspx?scid=kb;en-us;938923&sd=rss&spid=3198
More Posts
Next page »