Archivos del escritorioWindows con arranque en red

Wes Miller

Contenido

Funcionamiento de PXE
Análisis de RIS
WDS, el comienzo
Otros reproductores
Conclusión

Durante los próximos meses, tengo intención de analizar los Servicios de implementación de Windows (WDS), disponibles para Windows Server 2003 e integrados en Windows Server 2008. WDS puede ser un componente muy importante en su infraestructura de implementación, por lo que me gustaría asegurarme de que dispone de una buena base para la discusión. En este

primer artículo, exploraremos la arquitectura del entorno de ejecución previo al arranque (PXE), la historia de los Servicios de instalación remota (RIS), además de otras tecnologías relacionadas con PXE que se usan en Microsoft.

Cuando me trasladé al grupo de sistema operativo principal de Windows en 2001, RIS fue una de las tecnologías que heredé (me daba algo de miedo que fuese así, debido a su complejidad y a la dependencia de las implementaciones de BIOS y del hardware). Sin embargo, fue, junto con Windows® PE, una de las tecnologías con las que más disfruté mientras desempeñaba mi función como administrador de programas.

Recuerdo la primera vez que instalé Windows 3.0 (mediante un conjunto de disquetes de 3,5 pulgadas). Con el paso del tiempo, la instalación se hizo cada vez más fácil gracias a los CD de arranque (incluidos en algunas versiones de Windows 98). La cuestión era que la instalación siempre necesitaba medios locales de algún tipo, además de un disco duro local.

Con el paso de los años, la capacidad de arrancar Windows en red (es decir, realizar el arranque completamente desde la red sin necesidad de disco duro) ha sido una solicitud muy frecuente por parte de los clientes. Aunque algunas de las primeras versiones de Windows disponían de esta capacidad, no era el caso de Windows NT®. Además, aunque las versiones actuales de Windows Server® 2003 y Windows Server 2008 se pueden arrancar a través de un iniciador iSCSI, el proceso es muy distinto, en el sentido de que no es realmente local (implica una dependencia continua de una unidad remota como unidad de arranque).

Preorganización de clientes

Desde Windows 2000, Microsoft empezó a desarrollar la tecnología que, finalmente, se llamaría RIS y que permitiría la instalación basada en red. La finalidad de RIS era relativamente sencilla: colocar una imagen de sistema operativo en el disco local del equipo de destino mediante PXE.

Funcionamiento de PXE

La Figura 1 muestra la secuencia de arranque de PXE. PXE es un protocolo relativamente sencillo que desarrollaron Intel y otros proveedores como parte de la iniciativa Wired for Management. PXE se deriva del Protocolo de configuración dinámica de host (DHCP), que, a su vez, se deriva de BootP y se suele implementar en la tarjeta de la interfaz de red (NIC). En resumen, esto es lo que ocurre:

fig01.gif

Figura 1 Secuencia de arranque de PXE (haga clic en la imagen para ampliarla)

Paso 1 Se inicia el BIOS del sistema, que determina el orden de arranque.

Paso 2 Si el orden de arranque establece PXE por delante de los discos duros, unidades flash o CD-ROM, o si no están presentes ninguno de estos dispositivos, se carga la interfaz del controlador de red universal (UNDI) de la NIC. La NIC ofrece un controlador de dispositivos de red muy pequeño y una implementación del Protocolo trivial de transferencia de archivos (TFTP). Algunas implementaciones de BIOS requieren que los usuarios presionen la tecla F12 para arrancar PXE. Esto no es obligatorio y se puede desactivar.

Paso 3 El sistema comienza a realizar una difusión simple del Protocolo de datagramas de usuario (UDP), en busca de un servidor DHCP. Este es realmente el primer paso de la secuencia de arranque de PXE: la detección. Observe que el protocolo es UDP (lo que significa que, si aún no lo ha hecho, deberá emplear bastante tiempo con los enrutadores y conmutadores para asegurarse de que se pueden realizar las comunicaciones de PXE).

Paso 4 Si un servidor DHCP recibe la difusión, responde en consonancia con una dirección IP. Se trata del paso de ofrecimiento. Hay que tener en cuenta que PXE no tiene estado y que la cantidad de información de estado específica del sistema que puede ofrecer el cliente en este punto es muy limitada (la dirección MAC y, si está disponible, el GUID del BIOS de Administración del sistema, también conocido como GUID de SMBIOS).

Paso 5 El cliente, tras recibir el paquete con la dirección IP, establece que necesita más información (en particular, la dirección del servidor PXE). Se produce otra difusión, que contiene la información procedente del servidor DHCP que respondió originalmente. El cliente indica al servidor DHCP: "Necesito más información; en concreto, necesito la ubicación de un programa de arranque en red". Este es el paso de solicitud.

Paso 6 El servidor PXE responde con la dirección del servidor PXE y la ubicación del programa de arranque en red (NBP), un ejecutable de arranque extremadamente pequeño que debe ocupar menos de 32 KB. Este es el paso de reconocimiento.

Observe que, si ha instalado Microsoft DHCP y WDS (o ha usado las tecnologías de otro proveedor), se omite el paso de solicitud y, de hecho, el paquete de ofrecimiento original del servidor DHCP contiene ya la ubicación del servidor PXE y del programa NBP (por lo que se eliminan dos pasos, y se ahorra tiempo).

Paso 7 El cliente, que tiene la pequeña pila del protocolo TFTP que mencionamos anteriormente, descarga el NBP de la ubicación de la red que indique el servidor PXE. TFTP es un protocolo antiguo, muy pequeño y sin estado. No ofrecía buenos niveles de seguridad ni rendimiento (y, por ello, muchos administradores de enrutadores lo desactivan de forma predeterminada). Debe estar habilitado para que PXE funcione.

Muchas implementaciones de PXE (incluido RIS) incluyen la capacidad de solicitar al usuario que presione F12 para continuar al llegar a este punto, pero el administrador del servidor PXE suele poder desactivarla. El próximo mes, cuando seguiremos hablando de WDS, echaremos un vistazo a algunas de las mejoras que Microsoft ha incluido en el TFTPD (demonio TFTP) de WDS para Windows Server 2008 con el fin de mejorar el rendimiento.

Paso 8 Se inicializa NBP. En el caso de RIS, esto inicia un cargador de arranque de Windows que inicia el proceso de avanzar la implementación. PXE (al menos el protocolo de nivel de arranque) ya no es un componente del proceso.

Es importante recordar que PXE (RIS, WDS o cualquier otra infraestructura) no funciona correctamente con vínculos lentos (puede enviar cantidades considerables de datos) o vínculos de alta latencia, como satélites (la comunicación no se realiza correctamente y puede que ni siquiera sobreviva).

Tal vez observe en el proceso de arranque de PXE que, cuando el cliente envía la solicitud, no hay nada que pregunte específicamente: "¿Eres mi madre?" No hay mucha información de estado que permita al servidor PXE averiguar la respuesta. Generalmente, se produce una condición de carrera (en la que el primer servidor que responda a la solicitud del cliente es el ganador). Hay un par de formas de mitigar este problema:

  • Ajuste la velocidad de respuesta de uno de los servidores PXE. La latencia de la red y la eficacia del servidor afectarán a la velocidad de respuesta de los servidores. De hecho, en Microsoft, los servidores que usaba Microsoft IT solían ser tan buenos que, incluso aunque el servidor PXE estuviese en la oficina, los servidores de la empresa ganaban en algunas ocasiones. En este caso, sólo tiene que configurar su servidor PXE local para que no tenga límite de tiempo de espera (con respecto a los clientes preorganizados).
  • Preorganice los clientes. Esto es algo muy importante al manipular el servidor PXE para que responda antes que otros servidores de TI de la empresa. Al preorganizar los clientes, permite que Active Directory® comunique a WDS o a RIS que sí, "Yo soy tu madre". Observe que se prefiere el uso del GUID de SMBIOS como identificador exclusivo para los sistemas en Active Directory, pero si un GUID de SMBIOS no está implementado en los sistemas (especialmente en hardware relativamente antiguo), puede (y tendrá que) usar un GUID basado en la dirección MAC. Para obtener más información, consulte la barra lateral "Preorganización de clientes".
  • No deje que las comunicaciones de PXE atraviesen conmutadores o enrutadores; coloque un servidor PXE a cada lado. El inconveniente es que resulta muy caro de implementar y de mantener (hay que mantener las imágenes de todos los servidores).

Los servidores RIS (y ahora WDS), al igual que los servidores DHCP de Microsoft, se deben autenticar con la implementación de Active Directory a la que están asociados. El objetivo es reducir los problemas que pueden provocar los servidores PXE no autorizados (como tormentas de difusión de PXE) mediante la información a Active Directory acerca de estos servidores.

Observe que esto sólo ofrece protección frente a los servidores que conozca Active Directory. Al establecer su propio dominio, o un servidor PXE ajeno a Microsoft, este no será el caso.

En Microsoft, hubo una vez un empleado entusiasta que configuró un servidor PXE sin RIS con una implementación sin interacción. Esta implementación funcionaba mediante el borrado del disco duro y la implantación de una imagen nueva. Esto habría estado bien si la implementación se hubiera llevado a cabo en un laboratorio aislado (sin red) pero, por desgracia, no fue el caso (y acabó borrando el disco de un ejecutivo de Microsoft que tenía PXE en la orden de arranque antes que el disco duro.

Eso no habría supuesto un problema, ya que Microsoft IT siempre solicitaba el uso de F12 para arrancar PXE, pero este servidor PXE no tenía demora, solicitud de F12 ni ningún otro tipo de notificación. Esto hizo que el ejecutivo realmente perdiese el equipo y todos los datos que no estaban protegidos por su perfil de usuario móvil.

Espero que esta historia le sirva para darse cuenta de la necesidad de aislar los servidores PXE al proceder sin interacción o, por lo menos, solicitar que se presione F12.

Análisis de RIS

Heredé RIS después de que se lanzase Windows 2000. La vida de Windows 2000 no fue fácil en lo que a RIS se refiere. Las pruebas, el rendimiento y otras limitaciones hicieron que RIS sólo se usase con Windows Server 2000 para la implementación de Windows 2000 Professional. Los productos de servidor, por desgracia, no se podían implementar a través de RIS. Windows 2000 sólo estaba disponible para equipos x86, por lo que demostró ser un buen banco de pruebas para RIS, ya que implicaba un producto en una arquitectura. RIS incluía (y necesitaba) integración completa con Active Directory, integrada en el servidor DHCP de Microsoft, e incluía su propio TFTPD.

RIS usa el NBP para continuar la descarga de TFTP y desactivar suficiente kernel de Windows para iniciar el proceso de instalación. En un punto concreto, una vez que Windows ha cambiado de TFTPD a una conexión basada en un bloque de mensajes de servidor, o SMB, al servidor, se comparte la ruta de acceso literal al código con una instalación iniciada desde un disquete tradicional de Windows 2000 o Windows XP. Una vez que se ha inicializado el modo nativo de Windows, el programa de instalación de Windows inicia el asistente del selector de sistema operativo (OSC) de RIS.

Las pantallas de OSC son algo configurables, parecidas a páginas de HTML 2.0. Están muy limitadas y no pueden contener imágenes ni nada parecido y, de hecho, no pueden contener caracteres distintos de ANSI (lo que complicaba la implementación de algunas configuraciones regionales de Windows).

El producto final de RIS es un archivo txtsetup.sif que se implanta en el servidor RIS. Cuando finaliza el asistente del selector de sistema operativo, se reinicia parcialmente el cliente, pero la ubicación del servidor RIS y del archivo txtset­up.sif se retienen y se vuelven a cargar tras el reinicio parcial. El archivo txtsetup.sif es básicamente igual que un archivo unattend.txt, con varios campos adicionales para ayudar a RIS a finalizar el proceso de instalación.

RIS también podría realizar un proceso de instalación parecido a la instalación desatendida tradicional (RISetup), y tenía una infraestructura basada en clonación similar a Sysprep (RIPrep) y, de hecho, compartían código. Sin embargo, RIPrep también podía cargar una imagen suya en un servidor RIS.

No obstante, RIS tenía una serie de limitaciones fundamentales que se hicieron evidentes. La primera era la falta de compatibilidad con la implementación de servidores. Algunos ataques, como Code Red y Sasser, combinados con las complejidades de TI que algunos clientes clave experimentaron tras recuperarse de la tragedia del 11 de septiembre de 2001, nos llevaron a buscar rápidamente una solución para los servidores RIS con Windows 2000 existentes que permitiesen la implementación de Windows Server. Habíamos estado trabajando en esto para Windows Server 2003, pero no se había publicado formalmente.

Más información acerca de las tecnologías relacionadas con PXE

En segundo lugar, RIS no disponía de la capacidad de automatizar el asistente del selector de sistema operativo, función que se habilitó posteriormente con el elemento <META ACTION="AUTOENTER"> en Windows Server 2003. Finalmente, el programa selector de sistema operativo no funcionaba correctamente con caracteres distintos de ANSI (una carencia clave por la que se quejaron muchos clientes fuera de Estados Unidos).

En consecuencia, no se podía completar una instalación RIS con un teclado francés, por ejemplo. Conseguir que los caracteres distintos de ANSI funcionasen correctamente a nivel del BIOS en los equipos de todo el mundo era una tarea extremadamente compleja y nada fácil de conseguir.

Con el lanzamiento de Windows Server 2003, agregamos formalmente compatibilidad con la arquitectura de Intel Itanium y todas las variantes de servidores de Windows 2000 y Windows Server 2003. Windows Server 2003 llegó más allá con la compatibilidad con la arquitectura x64.

También se incluyó en RIS un TFTPD modificado de forma significativa para mejorar el rendimiento. Windows Server 2003 permitía arrancar hasta 75 clientes a la vez. Tenga en cuenta que se alcanza el límite cuando la canalización SMB se llena con el tráfico de red de los clientes.

WDS, el comienzo

Cuando empezamos a trabajar con RIS en "Longhorn" (nombre en código para Windows Server 2008), se hizo evidente que teníamos que retroceder sobre nuestros pasos. Como ya mencioné en mi artículo anterior, ya teníamos muchas expectativas relacionadas con la instalación basada en imágenes (WIM) de Windows PE. Como resultado, el principio básico que hacía de base para WDS era la implementación basada en imágenes de una versión arrancada en PXE de Windows PE.

También sabíamos que Windows Server 2003 sería la plataforma común para la implementación de Windows Vista®, y que necesitaríamos una solución "fuera de banda" para el nivel inferior de WDS. Como resultado, WDS se podía ejecutar en Windows Server 2003 SP1 y se integró en Windows Server 2003 SP2.

Ya que puede actuar como servidor RIS (modo heredado), servidor híbrido (modo mixto) o servidor sólo WDS (modo nativo), WDS permite migrar a implementaciones formales al estilo de WDS cuando se necesita. Muchos clientes han preguntado si hay alguna forma de instalar RIS en un sistema con Windows Server 2003 SP2. Sí, la hay (se instala WDS y se ejecuta en modo heredado). La Figura 2 muestra los sistemas operativos compatibles.

Figura 2 Plataformas compatibles para la implementación

Sistema operativo RIS (Windows 2000) RIS (Windows Server 2003)** WDS (Windows Server 2003)**** WDS (Windows Server 2008)
Windows 2000 Pro X X X X
Windows 2000 Server * X X X
Windows XP Pro   X (x86 e IA64)*** X X
Windows Server 2003   X (x86 e IA64)*** X X
Windows Vista     X X
Windows Server 2008     X X
* support.microsoft.com/kb/308508 y support.microsoft.com/kb/313069 agregaron compatibilidad para Windows 2000 Server a través de RIS.
** Los modos heredado y mixto de WDS admiten esta misma matriz para las instalaciones heredadas.
*** Windows Server 2003 SP1 agregó compatibilidad con los sistemas basados en x64. Los sistemas IA64 sólo admitían la instalación basada en RISetup.
**** Compatibilidad con el modo nativo.

La finalidad de WDS en Windows Server 2003 SP1 y SP2 era iniciar el proceso de migración a WDS. Como ya mencioné, las características clave que WDS agregó en Windows Server 2008 consistían en un TFTPD revisado, compatibilidad de arranque para EFI (Extensible Firmware Interface) y, por supuesto, la implementación basada en multidifusión.

Otros reproductores

El desarrollo de ADS quedó en manos de otro equipo de Microsoft, con el objetivo principal de conseguir el aprovisionamiento acelerado del servidor. ADS ofrecía imágenes formales basadas en sectores, su propio agente de arranque (más pequeño que Windows PE, pero sin una funcionalidad tan completa), su propio TFTPD y capacidad de multidifusión muy avanzada. La funcionalidad integrada en ADS sólo estaba disponible parcialmente en System Center Configuration Manager (SCCM), aunque no hay un 100% de paridad en cuanto a las características.

Windows XP Embedded incluía un arranque con PXE completo a través de su propio TFTPD en un disco RAM, pero no se podía implementar de forma remota de este modo. La tecnología estaba diseñada para permitir el arranque de muchos sistemas desde la misma imagen de disco a la vez a través de PXE.

Conclusión

A grandes rasgos, eso es todo. Para obtener más información, consulte la barra lateral "Más información acerca de las tecnologías relacionadas con PXE". El próximo mes, exploraremos los aspectos básicos de WDS, seguidos de artículos acerca de la funcionalidad avanzada de WDS (multidifusión, por ejemplo). Finalmente, veremos el uso de WDS sin usar WDS, es decir, cómo puede ir más allá de la experiencia de instalación/WDS para llevar a cabo sus propias técnicas de implementación.

Wes Miller es responsable senior de productos técnicos en CoreTrace (www.CoreTrace.com), con base en Austin, Texas. Anteriormente, trabajó en Winternals Software y como administrador de programas en Microsoft. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.

© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.