Archivos del escritorioDentro del formato de imágenes de Windows

Wes Miller

Esta columna se basa en versiones preliminares de las herramientas de implementación de Windows. Toda la información que aquí se menciona está sujeta a cambios.

La versión de Windows Vista supone un cambio significativo en el modo de instalación e implementación de Windows. El motor de configuración y todo el conjunto de herramientas de implementación para Windows Vista (así como la próxima versión de Windows Server, denominada "Longhorn") se han escrito de nuevo. Comenté estos cambios y el trabajo que

el equipo de implementación de Windows® destinó a la aplicación de estos cambios en recientes artículos de la revista TechNet Magazine. Pero queda mucho por decir sobre este tema, por lo que en esta nueva columna periódica hablaré sobre Windows PE, la instalación e implementación de Windows y otros temas de seguridad y administración de Windows.

En esta primera entrega, hablaré sobre el nuevo formato de imágenes de Windows (WIM). Si todavía no está familiarizado con los detalles de la creación de imágenes, consulte la barra lateral "Proceso típico de implementación de imágenes" para obtener una descripción general. En la columna siguiente, comentaré el kit de instalación automatizada de Windows, un nuevo conjunto de herramientas que incluye ImageX (la herramienta de línea de comandos que se usa para crear y manipular imágenes WIM) y los servicios de implementación de Windows (WDS), que sustituyen a los servicios de instalación remota (RIS), y explicaré cómo estas herramientas facilitan la implementación de sistemas operativos.

Punto de inflexión

Año tras año, el equipo de implementación de Windows escucha los mismos comentarios de los clientes de empresa y de OEM. Desean un soporte mejor para la implementación de imágenes y que Microsoft proporcione herramientas de imágenes unificadas. Estos usuarios no están dispuestos a seleccionar otro proveedor y aprender las características de su producto. Además, los clientes de empresa y de OEM se quejan con frecuencia de que no tendrían que pagar las herramientas de imágenes que se usan para implementar Windows, sino que Microsoft debería proporcionar estas herramientas.

Al empezar a desarrollar Windows Vista™, el equipo de implementación de Windows se la jugó. Decidimos descartar completamente el motor de configuración en su totalidad (muchos de sus componentes existen desde hace casi una década). La configuración siempre había sido frágil y tenía demasiados pasos. Queríamos acelerar el proceso, eliminar los pasos innecesarios y mejorar la confiabilidad de la configuración general de Windows. Para ello, cambiamos todo el proceso de configuración del motor hecho a mano que usamos durante un tiempo y los sustituimos por un proceso de configuración basado íntegramente en imágenes.

Diseño de un nuevo formato de imágenes

Al principio del proceso del nuevo diseño, nos pusimos de acuerdo para definir el tipo de imagen que debíamos usar. El argumento clásico era sector frente a archivo. Es decir, ¿debemos usar un formato de imagen que almacene una copia de un volumen como un duplicado sector por sector o una que almacene todos los archivos individualmente? La mayoría de la gente prefiere la velocidad (enfoque de sector) a la compresión (enfoque basado en archivos). Finalmente, nos decidimos por un formato que supone, desde mi punto de vista, un gran compromiso entre las dos propuestas. Su rendimiento es excelente, y también permite una buena compresión.

Para empezar, definimos varios objetivos clave necesarios para crear un formato de imagen que satisficiese las exigencias de los usuarios de la empresa y de OEM. Nuestra lista se inclinaba marcadamente hacia una arquitectura basada en archivos. Todos advertimos las ventajas de este enfoque y, por lo tanto, empezamos a trabajar en esa dirección. Los archivos WIM no tardaron en aparecer. (Y, por si se lo están preguntando, la "M" de WIM no es la inicial de ninguna palabra. Le pusimos WIM por los eventos del equipo de Windows que se repiten cerca de los objetivos de envío; y *.WI parecía una abreviatura extraña.) Veamos el conjunto de objetivos que nos propusimos para el nuevo formato de imagen.

Formato neutral del sistema de archivos de Windows El formato de imagen tenía que funcionar en las dos arquitecturas del sistema de archivos que Windows admite. La mayoría de los sistemas usan NTFS al ejecutarse, pero también hay muchos OEM y empresas que usan sistemas de archivos FAT como recurso provisional para poder usar MS-DOS® para implementar Windows. A continuación, se pasan a NTFS. Nos hemos visto obligados a admitir este formato para Windows Vista.

Geometría de volumen neutral Hemos tenido que superar el problema histórico de capturar grandes volúmenes y aplicarlo a un volumen más pequeño. Aunque la herramienta de imágenes puede superar estos trucos de manipulación a través de una partición, es poco confiable. En una arquitectura basada en archivos, la imagen sólo ocupa el espacio que ocupan los archivos que la conforman. Dado que el sistema de archivos se restaura de forma independiente, no depende del volumen.

Proceso típico de implementación de imágenes

Cuando un OEM duplica grandes cantidades de sistemas o una empresa grande necesita desplegar Windows en muchas máquinas, normalmente, usan la tecnología de implementación de imágenes. La premisa consiste en tomar el sistema host, crearlo tal y como se desee y, a continuación, duplicarlo en los sistemas de destino. Si no está familiarizado con el proceso de implementación de imágenes, a continuación se proporciona una breve descripción general.

1. El administrador instala Windows en un sistema y lo configura como desee. Esto implica la adición y eliminación de componentes, la instalación de aplicaciones usadas con frecuencia y el ajuste de la interfaz de usuario y otros valores. Llamémoslo el sistema host.
2. Entonces, el administrador ejecuta Sysprep (suministrado por Microsoft en forma de herramientas de implementación de Windows), que se encarga de borrar los atributos que hacen una instalación de Windows única (por ejemplo, el nombre del equipo, el SID [identificador de seguridad de Windows] y otros identificadores únicos del sistema). Estos atributos se restablecen cuando se ejecuta la segunda parte de Sysprep.
3. A continuación, el administrador cierra el equipo y lo reinicia en Windows PE, MS-DOS u otro sistema operativo que le permita ejecutar la aplicación de implementación de imágenes.
4. Ahora, el administrador ejecuta la herramienta de implementación de imágenes y crea una imagen para el sistema de referencia. Esta imagen es un archivo (o colección de archivos) que contiene una réplica exacta de la partición o el disco de referencia.
5. El sistema se cierra y el administrador archiva la imagen, que se puede actualizar (agregando aplicaciones, revisiones y service packs) según sea necesario.
6. La imagen se replica en uno o más equipos y Sysprep termina su trabajo con la ejecución de una versión abreviada de instalación (llamada instalación mínima o inicio de Windows, en función de la versión de Windows en la que esté ejecutando Sysprep y cómo esté configurado Sysprep). Esta etapa depende de un pequeño ejecutable en modo nativo denominado setupcl.exe.

Arquitectura neutral del sistema La arquitectura de imagen tenía que ser compatible con todas las arquitecturas que admitiese Windows. En ese momento, esto significaba las dispares arquitecturas x86 e IA64 (Intel Itanium). Hoy en día, también incluye las arquitecturas x64 (AMD64 y EM64T).

Debe ser rápida de capturar y aplicar La imagen tenía que poder capturarse con cierta rapidez, dada la compresión. Pero, todavía más importante, la aplicación de la imagen tenía que ser muy rápida.

Compatible con la aplicación de imágenes no destructiva Dado que íbamos a sustituir la opción de actualización (que sustituye Windows sin dañar los datos ni las aplicaciones del usuario) y a derivar una herramienta que se pudiese usar para la recuperación del sistema, deseábamos que pudiese implantar la imagen de un sistema sin destruir todo lo que ya está en el volumen. Los formatos basados en sectores, sin mucho trabajo, no permiten al usuario hacer esto. Por lo general, o se restaura todo el sistema o no se restaura nada.

Compatible con una compresión significativa Cuando se empezó a desarrollar Windows Vista, todavía nos centrábamos en la entrega en CD. Teniendo en cuenta que una imagen de Windows XP ocupa casi 1 GB, decidimos que era importante comprimir la imagen lo máximo posible. Existen varios trucos para hacerlo con una imagen basada en sectores, pero las partes móviles de esta implementación nos preocupaban. Muchos formatos basados en sectores omiten los espacios en blanco del disco para ahorrar espacio. (¿Por qué grabar un 0 en una imagen si se trata siempre de un 0?) Sin embargo, mediante un enfoque basado en archivos, pudimos controlarlo de manera inherente, ya que no estábamos tomando los espacios en blanco.

Compatible con la instancia única de archivos Este punto es igual al tema anterior. Se sabe que Windows almacena varias copias del mismo archivo en unas cuantas ubicaciones diferentes. El enfoque basado en archivos facilitó el almacenamiento de una sola instancia de cada archivo y el uso necesario del archivo.

Compatible con la combinación de soportes (disco) Ya desde los primeros días de WIM, cuando podíamos grabar una imagen en un solo CD, supimos que debía ser compatible con varios tipos de soportes. Aunque entregásemos Windows en un CD, una vez que los usuarios agregasen aplicaciones, service packs y demás, sus imágenes superarían el tamaño de un solo CD o DVD. De manera que tuvimos que permitir su almacenamiento en varios soportes para las soluciones de instalación y recuperación.

Compatible con varias imágenes de volumen en un blob de archivos No es frecuente que una imagen funcione para todo. Cuando diseñamos la "instancia única", incluimos la capacidad de seleccionar más de un volumen, de manera que la misma compresión e instancia única funcionen en todos. Así, si selecciona una imagen de Windows XP Professional y, a continuación, agrega una imagen nueva de Windows XP Tablet PC Edition (un superconjunto de Windows XP Professional), sólo se agregarán a la imagen los archivos que son diferentes explícitamente entre las dos versiones.

Como consecuencia, un OEM o un usuario de empresa puede agregar muchas imágenes derivadas sin que suponga un aumento exponencial en su tamaño. Esta capacidad hubiese sido difícil de conseguir con un formato basado en sectores.

Funcionamiento de WIM

El formato WIM se diseñó para que fuese lo más simple posible, cumpliendo siempre nuestros principios fundamentales. El enfoque basado en archivos nos permitió hacer esto. ¿Cómo funciona exactamente?

En pocas palabras, un archivo WIM es como un archivo CAB (un formato similar al ZIP, pero diseñado por Microsoft, propietario del formato CAB). De hecho, una vez oí cómo se hacía referencia a WIM como "hijo de CAB." La diferencia principal entre un archivo WIM y un archivo CAB es que, además de capturar y comprimir el archivo, una imagen WIM almacena metadatos que aplica a los archivos y directorios que componen el volumen capturado en una imagen de volumen dada. Es como un archivo de almacenamiento con toda la metainformación necesaria para restaurar el volumen a su estado cuando se creó la imagen: listas de control de acceso (ACL), nombres de archivo cortos y largos, atributos, etc.

Tenga en cuenta que, en ningún momento durante el proceso de captura se reúne información de la partición (tamaño o tipo). Ni el proceso de aplicación particiona el sistema. A diferencia de la mayoría de las herramientas de implementación de imágenes, ImageX, que es de partición neutra, requiere que la partición se cree y formatee antes de la aplicación. Para automatizar el proceso antes de aplicar la imagen, debe usar las herramientas Diskpart y línea de comandos de formato.

El almacenamiento en una imagen de volumen no tiene límites. Una imagen puede contener dos volúmenes, el mismo volumen capturado un martes y un jueves, una imagen con un service pack y otra con ninguno u otros volúmenes que satisfagan sus necesidades. Lo más importante es comprender que los archivos idénticos sólo se capturarán una vez. Cuanto menos tengan en común dos imágenes de volumen, más espacio ocuparán.

También deseo señalar que nada en el diseño del formato WIM impide su uso con versiones anteriores de Windows. Funcionará tan bien con Windows 2000 como con Windows Vista. Ahora, veamos qué sucede exactamente cuando se capturan y aplican las imágenes.

Captura de una imagen

Cuando se captura la imagen de un volumen, se suceden los pasos siguientes:

Se capturan metadatos de volumen. ImageX recopila datos sobre nombres de archivo, listas de control de acceso de NTFS u otros atributos del sistema de archivos del volumen. (Tiene la opción de excluir determinados archivos con un archivo de secuencia de comandos.)

Se capturan los datos de archivo. ImageX carga el archivo. Los archivos se cargan en el volumen y se preparan para recopilar determinados datos sobre éstos.

Se genera el hash del archivo. Se genera un hash criptográfico del archivo basado en el propio archivo. Este hash se convierte en el identificador único de los archivos de la imagen.

Se buscan y se eliminan los duplicados. Si ya existe otro archivo con el mismo hash en la imagen, se supone que se trata del mismo archivo y se hace referencia al nuevo archivo apuntando al archivo existente.

Se comprimen los datos únicos del archivo. A diferencia del formato CAB u otros formatos de almacenamiento, los archivos de un archivo WIM se comprimen individualmente, en lugar de como una colección de archivos agrupados en un flujo de datos. También puede decidir no realizar la compresión, en cuyo caso este paso se omite.

Se comprimen y almacenan los metadatos de volumen. Una vez que se han almacenado todos los archivos, se crea una entrada de metadatos para el volumen. En esta entrada se enumeran todos los archivos que se agregaron a la imagen para el volumen.

Se generan y almacenan los datos XML de imagen. Esta es una referencia para cada imagen de volumen capturada. Si ejecuta ImageX /info, por ejemplo, obtendrá datos XML.

Se graba el índice de datos WIM en caché. Por último, se graba el índice de datos maestro (junto con los datos en caché). Esta es la tabla de archivos maestro para todo el WIM; incluye una entrada por hash.

Como se puede apreciar, WIM se crea archivo por archivo. Además, tendrá un archivo WIM, independientemente del número de volúmenes que agregue a la imagen.

Sobrecarga de imágenes

Cuando empezamos a trabajar en WIM, existían varios equipos desarrollando soluciones similares. El equipo de los servicios de implementación automatizados estaba desarrollando una solución de imagen para otro segmento de clientes. Su enfoque tenía detalles sobre la implementación de bajo nivel muy interesantes, pero su motor de imágenes se basaba en sectores, como la mayoría en aquel momento. El equipo de Windows XP Embedded también creó un motor de imágenes basado en sectores para permitir a los proveedores de hardware independientes incrustados (IHV) implementar su propias imágenes durante la fabricación del sistema. Y, cuando Microsoft adquirió el equipo de Virtual PC en 2003, incorporó otro formato de archivo para archivos VHD (disco duro virtual).

Todos estos formatos se basaban en sectores. Satisfacían las necesidades de su segmento de clientes, pero no eran acordes a nuestras directrices para WIM. Por lo tanto, seguimos trabajando en la creación del nuevo formato WIM y la herramienta de línea de comandos ImageX para capturar imágenes. Finalmente, varios equipos adoptaron nuestro formato antes de que formase parte, públicamente, de la versión beta de Windows Vista. El equipo de SMS, por ejemplo, suministró una primera implementación de WIM en Operating System Deployment Feature Pack.

Aplicación de una imagen

Ahora, veamos el proceso del contador: aplicar una imagen

Se carga el índice de datos WIM en caché. Esta acción se correlaciona con el último paso del procedimiento anterior. Puesto que se trata del índice maestro, es el primer elemento que se debe cargar del WIM después de especificar la imagen de volumen que se desea aplicar.

Se recuperan y se cargan los metadatos de la imagen. ImageX carga los metadatos específicos de cada imagen de volumen.

Se crea la estructura de directorios. Para garantizar que cada archivo tiene una ubicación de restauración, se crea todo el árbol de directorios del volumen.

Se extraen los datos de archivo. Los archivos se extraen del WIM en el mismo orden secuencial en que se almacenaron.

Se aplican los datos de archivo. En este paso, los archivos se cargan, se descomprimen (si la imagen de volumen estaba comprimida en el WIM) y se copian en todas las ubicaciones a las que se haga referencia. Por último, se aplican todos los metadatos de cada archivo.

Se aplican todos los metadatos de directorio. Es importante que éste sea el último paso, ya que es posible que la ACL de un directorio impida que la imagen se aplique correctamente.

Compresión flexible

Uno de nuestros principales objetivos para el formato de imágenes WIM era proporcionar opciones de compresión flexibles. Por este motivo, incorporamos la capacidad de capturar una imagen de volumen con compresión cuando fuese necesario, además de permitir la captura de una imagen sin compresión. Esta última opción es adecuada para casos en que la imagen no necesita una gran compresión o cuando es necesaria una captura muy rápida.

En cuanto a la compresión, deben tenerse en mente cuatro principios clave. La compresión siempre es más lenta que la descompresión. Cuanto más agresivo sea el algoritmo de compresión, más tardará en comprimir un conjunto de datos determinado. Y, cuantos más datos se proporcionen a un algoritmo de compresión, mejor será la compresión.

Las imágenes WIM se pueden comprimir con compresión XPress o LZX. Por supuesto, también existe la opción de no realizar ninguna compresión. XPress es una buena opción cuando es necesario algún tipo de compresión pero no se desea dedicar demasiado tiempo al proceso de captura. LZX proporciona una tasa de compresión óptima, pero, como se puede imaginar, tarda bastante más en realizarla.

Si no se usa ningún tipo de compresión, la captura de imagen es más rápida, pero también se obtiene una imagen mayor. El tipo de compresión es una opción que se establece por WIM. Una vez que se ha capturado una imagen de volumen en un WIM, todas las imágenes de volumen posteriores deben capturarse con el mismo valor de compresión.

Recuerde que, dado que las imágenes WIM se comprimen archivo por archivo, la compresión no es todo lo completa que podría ser. Lo hicimos a propósito, porque de este modo editar la imagen sería más fácil. La capacidad de editar imágenes tras la captura es una opción importante. Para editar un archivo después de haber capturado la imagen, deben sustituirse los datos de archivo y sus metadatos. Si hubiésemos comprimido todo el WIM a la vez, la compatibilidad para la edición de archivos hubiese sido mucho más difícil de diseñar (en el caso de que fuese posible) y la sustitución de un archivo de la imagen tardaría mucho tiempo. Con este compromiso, conseguimos un formato con una buena compresión y que se puede editar con nuestras herramientas.

Espero haberles ayudado a comprender cómo funcionan las capacidades de implementación de imágenes que diseñamos para Windows Vista. En la siguiente columna, hablaré sobre algunas de las herramientas que se pueden usar para administrar e implementar imágenes WIM y profundizaré en ImageX y los Servicios de implementación de Windows.

Wes Miller es Director de desarrollo de Pluck (www.pluck.com) en Austin, Texas. Anteriormente, Wes trabajó en Winternals Software en Austin y en Microsoft como administrador de programas y administrador de producto para Windows. Puede ponerse en contacto con Wes en la dirección technet@getwired.com. Wes desea agradecer la ayuda que John Macintyre, el actual administrador del programa WIM/ImageX de Microsoft, para elaborar esta columna.

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