Archivos del escritorioPersonalización de Servicios de implementación de Windows

Wes Miller

Contenido

Reemplazo de lo que se tiene
Examen de la pila
Programa de arranque de red
Proveedor PXE de WDS
Demonio de TFTP
Almacén de datos de configuración de arranque
Windows PE
Servidor de transporte
Multidifusión personalizada
Conclusión

Durante tres meses he profundizado en Servicios de implementación de Windows (WDS): sus orígenes, información general y, finalmente, información más exhaustiva sobre algunos temas avanzados, como WDSutil y la multidifusión. En esta entrega final de la serie vamos a examinar dónde y cómo se puede personalizar y configurar WDS para satisfacer las necesidades de su organización. La mayoría de las herramientas de Microsoft están diseñadas con algo de capacidad de configuración. Pero es cuando se aplican en la práctica cuando realmente se sabe si las herramientas satisfacen sus necesidades o, con más frecuencia, si requieren algún ajuste para que funcionen en sus escenarios.

Reemplazo de lo que se tiene

Una pregunta que últimamente me plantean con frecuencia los lectores es "Tengo x (una tecnología de implementación existente), ¿me servirá WDS y tiene equivalencia de características con x?" Con el abandono de los servicios de implementación automatizados (ADS), un área de interés es: "¿Cómo puedo realizar una implementación rápida de alto volumen o el reaprovisionamiento de servidores? ¿Qué puede hacer WDS por mí?"

Aunque WDS no se ha diseñado para ser un reemplazo total de ADS, y de hecho le faltan algunos componentes clave para ser un verdadero sustituto, con un poco de trabajo se puede hacer que WDS sea como ADS. Del mismo modo, si algún aspecto de WDS no le sirve tal como está, averiguará que muchos de sus componentes se pueden reemplazar, con distintos grados de complejidad y diseño. Veamos la implementación mediante WDS y examinemos los elementos que puede personalizar y cómo puede hacerlo.

Examen de la pila

En la figura 1 se muestran los componentes del proceso de implementación de WDS. Cada uno de estos pasos se puede personalizar en cierta medida. He aplicado códigos de color a cada paso para reflejar la complejidad (por lo general, los conocimientos de desarrollo) que creo que supone reemplazarlo o personalizarlo. Cuanto más oscuro sea el color azul, habrá más probabilidad de que resulte difícil personalizar dicho paso.

Figura 1 Complejidad de la personalización de WDS

En realidad, la dificultad de implementación de cada paso, como es evidente, depende tanto de las capacidades de su equipo (desarrollo o scripting) y del conocimiento de WDS, el formato de imagen de Windows (WIM), Active Directory o cualquier tecnología que desee integrar, como SQL o ADSI. Examinemos cada uno de estos pasos. Piense en los modos en que desea personalizarlos y los métodos que usaría.

Programa de arranque de red

Es poco probable que deba crear un programa de arranque de red (NBP) personalizado para reemplazar los que proporciona WDS, pero es posible. WDS incluye programas de arranque de red para usarlos en sistemas sin periféricos (por lo general, servidores) o sistemas en los que puede pedir que se presione F12, etc. Estos programas de arranque de red se pueden almacenar previamente en Active Directory con WDSUtil, o se puede reemplazar Startrom.com por el programa de arranque de red que desee para todos los sistemas que no estén almacenados previamente (por ejemplo, si todos los sistemas son equipos sin periféricos o nunca desea que se pida presionar F12).

Lamentablemente, no hay disponible mucha información acerca de cómo crear un programa de arranque de red propio (consulte msdn.microsoft.com/library/bb870970.aspx para obtener algo de información). Un programa de arranque de red es un archivo ejecutable de 16 bits muy pequeño con grandes limitaciones y requiere conocimientos de programación específicos. Por lo general recomiendo el uso de los programas de arranque de red existentes que se proporcionan con WDS a menos que intente satisfacer un requisito muy específico y tenga un equipo de desarrollo con los conocimientos adecuados.

Proveedor PXE de WDS

Con Servicios de instalación remota (RIS), los comentarios habituales que recibimos de los clientes es el deseo de usar un almacén distinto de Active Directory para la información del sistema cliente, con mucha frecuencia, SQL Server. Con WDS, el diseño incluye una infraestructura acoplable para proveedores de entorno de ejecución previo al arranque (PXE). Esto significa que con el trabajo de desarrollo se puede usar otro almacén de refuerzo además de Active Directory para la información de PXE.

WDS incluye su propio proveedor que usa Active Directory; System Center Configuration Manager (SCCM) ahora también se integra en WDS e implementa un proveedor propio. La documentación acerca de cómo escribir un proveedor propio es muy escasa y no hay disponible demasiado código de muestra (aunque el SDK de Windows proporciona documentación y un par de muestras), por lo que es una tarea ardua. A menos que tenga unos requisitos muy específicos para este aspecto del proceso de arranque, de nuevo recomiendo que no se intente crear un proveedor PXE personalizado.

Demonio de TFTP

A veces los clientes han invertido en su propio demonio de protocolo trivial de transferencia de archivos (TFTPD) antes de que apareciera WDS. Debido a que los servidores PXE no se entienden bien entre sí, esto suele significar que se debe activar sólo uno.

Según mi experiencia, por lo general significa tomar un TFTPD existente, normalmente basado en Linux, y obtener acceso a él para arrancar otros sistemas operativos. Con el RIS de infraestructura original utilizado no se podía hacer esto. Pero cuando arrancar desde un disco RAM se convirtió en la norma, se podía, y todavía se puede, hacerlo con imágenes de arranque basadas en WDS.

Lo que se debe tener presente es que se adentra en un área sin soporte técnico en lo que respecta a Microsoft y que se pueden producir problemas que son difíciles de diagnosticar. Además, con un TFTPD mejorado en WDS, es muy probable que no alcance un mejor rendimiento. Idealmente, recomiendo el uso de TFTPD de WDS existente e intentar usar los tiempos de espera de PXE, el almacenamiento previo y los perímetros de red para definir los clientes que arrancan desde cada servidor PXE en vez de intentar adaptar un servidor existente.

Almacén de datos de configuración de arranque

Con RIS nunca se pudo especificar, en el nivel de arranque, lo que debía arrancar; siempre se tenía que ir al selector de sistema operativo y elegir una opción (configuración, Windows PE [entorno de preinstalación de Windows] o algo completamente distinto). WDS, debido a que usa un cargador completo para el arranque de red, también admite la personalización del almacén de datos de configuración de arranque (BCD) que se sirve a los clientes. Los BCD predeterminados de cada arquitectura se encuentran en RemoteInstall\Boot\<arq>\Default.bcd, donde <arq> es la arquitectura específica del sistema que va a arrancar.

Puede personalizar estos BCD para cada cliente y el cliente los usará para arrancar. Por ejemplo, puede establecer una entrada de BCD para iniciar la configuración, otra para ejecutar Entorno de recuperación de Windows (WinRE) e incluso otra para ejecutar una prueba de memoria; o puede tener una entrada de configuración totalmente automatizada que sea la predeterminada y otra manual (o experiencia de instalación personalizada) que sea una opción que pueda seleccionar el usuario. (Para obtener más información, vaya a "Cómo modificar el almacén de BCD con Bcdedit" en go.microsoft.com/fwlink/?LinkId=115267.)

Evidentemente, la mayoría del trabajo pesado de WDS se produce en Windows PE, por lo que ajustar Windows PE según sus necesidades puede ser un área crítica de interés para una experiencia personalizada. De forma predeterminada, WDS ofrece una plantilla muy estándar para la instalación, que incluye la experiencia de instalación completa. En ocasiones, las necesidades de implementación pueden implicar que esto no le funcione. En este caso, puede crear su propia imagen de arranque de Windows PE. Empecemos por el principio.

Además de usar los BCD para indicar la imagen que se utilizará, también puede especificar la imagen si personaliza el objeto de cuenta de máquina (MAO) de un equipo en Active Directory. En RIS, se almacena un atributo MAO específico por cada elemento (que indica el archivo Startrom y Unattend, SIF, que se utilizará). Con WDS, se almacenan como pares de nombre y valor en la entrada netBootMirrorDataFile. Por ejemplo, en esta entrada se almacenan la imagen de arranque y el archivo Unattend que utilizará un determinado equipo. El formato de las entradas es una lista delimitada por puntos y comas de pares de nombre y valor. Las entradas para modificar la imagen de arranque y el archivo Unattend son BootImage y UnattendFilePath, respectivamente.

Evidentemente, puede suceder que desee descartar la experiencia de instalación existente por completo y crear una propia. Tal vez necesite más capacidad de configuración, más automatización o una generación automatizada mediante SQL Server. Tal vez desee hacer como hacían algunos clientes con RIS y Windows PE anteriormente y crear su propio front-end para la instalación. Las tareas clave que necesite llevar a cabo independientemente de la experiencia de instalación que escriba son:

• Averiguar la información por equipo o por usuario. Esta información se puede obtener de los datos del usuario, de SQL Server o de un archivo de texto, por ejemplo.
• Copiar y aplicar una imagen de instalación al sistema cliente. Esta tarea se puede llevar a cabo con la instalación directamente, con ImageX para aplicar una imagen desde un recurso compartido de red o mediante multidifusión (simplemente copiar la imagen y aplicarla a través de ImageX).
• Proporcionar un archivo Unattend (como Unattend.xml o sysprep.inf, según la versión de Windows que se vaya a implementar) para terminar la instalación.
• Automatizar los pasos de migración posteriores a la instalación que desee llevar a cabo (o cualquier paso que aplique funciones en el caso de Windows Server 2008).

Con ADS se inició el concepto de las secuencias de tareas que permite asignar pasos repetibles a uno o varios equipos. Debido a que ADS no se diseñó para Windows XP ni es compatible con él, no se puede utilizar para implementar el sistema operativo. Pero las secuencias de tareas de ADS realmente son scripts estructurados y puede llevar a cabo los mismos pasos con un proceso de instalación personalizado.

Desde hace tiempo soy admirador de Microsoft SQL Server (desde la versión 6.5 de SQL Server), por lo que mi instinto me dicta crear dicha estructura con SQL. Evidentemente, se necesita agregar la funcionalidad de SQL a la compilación de Windows PE para hacerlo. Además, puede escribir su propia GUI, una aplicación HTML (HTA) o un archivo ejecutable compilado, o usar Windows Script Host (WSH) para realizar una experiencia de instalación minimalista sólo a través de la línea de comandos. Para usarlos, HTA o WSH también se deben agregar a Windows PE.

La complejidad del diseño de una experiencia de instalación propia depende por completo de sus conocimientos e imaginación. He visto sistemas bastante elegantes que se han definido únicamente con SQL y WSH o HTA, que son capacidades relativamente sencillas que puede elegir cualquiera. No obstante, es muy importante tener presentes las restricciones que he mencionado en columnas anteriores.

• Windows PE no dispone del subsistema Windows sobre Windows (WOW), por lo que tendrá que realizar la compilación una vez para cada arquitectura que desee admitir.
• No puede usar Visual Basic 6.0 si necesita implementar mediante Windows PE x64 o IA64.
• Puede usar Visual Studio 2005 o 2008 para crear aplicaciones, pero debe crear una aplicación Visual C++ no administrada, ya que no hay ninguna versión de Microsoft .NET Framework que se admita en Windows PE.
• Sin .NET Framework, tampoco podrá usar Windows PowerShell para la automatización.

Evidentemente, también puede usar una utilidad de imagen de terceros mediante WDS si desea escribir su propia experiencia de instalación. Aunque creo que el formato WIM e ImageX pueden cubrir la mayoría de los escenarios de implementación, puede haber determinados requisitos que necesita que cumpla la herramienta de imagen existente.

De forma similar, determinados escenarios pueden requerir particiones personalizadas: tal vez vaya a implementar Windows Vista con BitLocket o crear sistemas Windows XP y almacenar los datos de perfil en otro volumen, o tal vez vaya a implementar un sistema Windows Server y desea crear un volumen independiente en el mismo disco para realizar el registro. Cualquiera de estos escenarios requiere la automatización de DiskPart que, como en versiones anteriores, se puede realizar con un script (cualquier formato de archivo) para DiskPart que contenga los comandos que desea ejecutar y termine con exit, para finalizar DiskPart.

La creación de una experiencia de instalación es para valientes, ya que básicamente se está reconstruyendo el archivo ejecutable de instalación (o al menos replicando su funcionalidad) y puede haber bastante que diseñar y generar. Pero se trata de cuánta funcionalidad desea incorporar de forma predeterminada y de lo que se desea incorporar (HTA o WSH, o bien un lenguaje de programación compilado).

Servidor de transporte

Si no va a usar la mayor parte de la funcionalidad integrada de WDS (como Active Directory) o va a diseñar su propia solución completa y personalizada, el servidor Transporte puede cubrir sus necesidades y no incorporar requisitos que no desee. La tabla de la figura 2 (reproducida de "Uso del servidor Transporte" en go.microsoft.com/fwlink/?LinkID=115298) describe lo que se incluye como parte de la función de servidor de transporte de WDS.

Figura 2 Servidor de implementación frente a servidor de transporte

Cuando me refiero a que el servidor de transporte es un elemento complicado de implementar, no es que la función sea difícil, ya que, evidentemente, se implementa de modo sencillo (consulte la figura 3). Es la implementación de instalación personalizada de alrededor del servidor de transporte la que requiere trabajo. El uso de la función de servidor de transporte anula la mayor parte de la facilidad de uso integrada en WDS como función.

Figura 3 El servidor de transporte puede resultar útil para los escenarios de implementación personalizada (haga clic en la imagen para ampliarla)

Multidifusión personalizada

Independientemente de si usa la función de servidor de transporte, pero especialmente si la usa, es una buena ocasión para usar la multidifusión si va a realizar una implementación de multidifusión. ADS dispone de una característica de multidifusión muy eficaz, que puede duplicar mediante WDS con multidifusión. WDS dispone de multidifusión, pero si va a crear su propia solución personalizada, puede aprovechar la multidifusión con WDSMCast, tal y como mencioné el mes pasado (consulte la figura 4). Recuerde que debe transferir los archivos de imagen que se implementan y, a continuación, se deben aplicar. Por lo general esto significa que necesita suficiente espacio en el disco local para que la imagen se almacene y, a continuación, se aplique.

Figura 4 Ejecución de WDSMCast (haga clic en la imagen para ampliarla)

Conclusión

WDS proporciona bastante eficacia por sí mismo, probablemente la suficiente para satisfacer las necesidades de muchas organizaciones. Pero si busca crear su propia solución que traspase los límites de WDS, puede hacerlo, y sólo estará limitado por su imaginación, su programación y sus conocimientos.

Wes Miller es jefe de productos técnicos senior en CoreTrace (CoreTrace.com), con sede 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.