Crear imágenes de referencia con Sysprep y Unattend en Windows

Cuando en una empresa tienes que preparar decenas o cientos de equipos con Windows, hacerlo uno por uno es una auténtica pérdida de tiempo. Para evitarlo, lo ideal es crear una imagen de referencia bien pulida, generalizarla con Sysprep y complementarla con un archivo de respuesta automática Unattend.xml que deje todo listo sin ir clicando asistentes.

En las siguientes líneas vas a ver, con bastante detalle, cómo funciona Sysprep, qué hace exactamente la generalización, cómo se combinan los diferentes pasos de configuración con el archivo Unattend.xml y qué límites, trucos y problemas típicos tienes que tener en cuenta para no estrellarte en mitad del despliegue.

Qué es Sysprep y por qué es clave para crear imágenes de referencia

Sysprep (System Preparation Tool) es la utilidad oficial de Microsoft pensada para preparar una instalación de Windows para clonarla y desplegarla en otros equipos. El objetivo principal es eliminar toda la información única ligada a la máquina de origen para que la imagen pueda reutilizarse en muchos dispositivos sin conflictos.

En cada instalación nueva de Windows se generan elementos únicos como el SID (Security Identifier) del equipo, el nombre de host, cierta caché de controladores, información de activación, etc. Si clonas un disco tal cual sin pasarlo por Sysprep, replicas esa información única y puedes tener problemas muy serios en red, especialmente con servicios como WSUS o servicios de dominio que dependen del SID para identificar equipos.

La función de Sysprep es llevar la instalación a un estado “generalizado”: borra o regenera datos específicos del hardware y del sistema, para que al arrancar de nuevo aparezca la fase de configuración rápida (OOBE) o el modo auditoría, donde se generan identificadores nuevos y se ajusta la configuración final.

En versiones modernas como Windows 10, cualquier equipo donde quieras distribuir una misma imagen debe haber sido pasado antes por un proceso de generalización, ya sea con Sysprep en modo gráfico o mediante línea de comandos con los parámetros adecuados.

Diferencia entre imagen generalizada e imagen especializada

Cuando hablamos de despliegue masivo es fundamental tener clara la distinción entre una imagen generalizada y una imagen especializada. Una imagen generalizada es aquella en la que Sysprep ha eliminado los datos dependientes del equipo, mientras que una imagen especializada aún conserva esa información y está pensada para un único ordenador concreto.

Una imagen generalizada, una vez capturada con DISM, se puede restaurar en cualquier equipo compatible con el mismo sistema operativo, siempre que respetes algunos requisitos de hardware básicos. Por el contrario, una imagen especializada conserva SID, nombre de equipo, configuración de red y otros datos que solo tienen sentido en la máquina donde se creó.

En Windows 10 puedes pasar una instalación de estado especializado a generalizado y viceversa, usando Sysprep con las opciones adecuadas. Lo habitual es: instalas el sistema, personalizas, entras en modo auditoría, dejas la instalación fina y, cuando esté lista, ejecutas Sysprep con /generalize y apagado para capturar esa imagen.

Si vas a despliegues muy homogéneos (todos los equipos con el mismo hardware), podrías plantearte una imagen menos “agresivamente” generalizada, pero aun así es recomendable dejar que Sysprep regenere SIDs y limpie datos únicos para que la red y los servicios de directorio funcionen sin sorpresas.

El papel del archivo de respuesta Unattend.xml

Además de generalizar la instalación, Sysprep se vuelve mucho más potente si lo combinas con un archivo de respuesta Unattend.xml. Este archivo es un documento XML con toda una colección de componentes y ajustes que Windows aplica en distintos pasos de la instalación.

El archivo de respuesta permite contestar de forma automática a las preguntas típicas de cualquier instalación de Windows: idioma, distribución de teclado, zona horaria, aceptación del contrato de licencia, nombre de equipo, comportamiento de OOBE, claves de producto, opciones de protección, etc. En lugar de ir pulsando siguiente, Windows lee el Unattend.xml y aplica los valores definidos.

En Windows 7, Windows 8.1, Windows 10 y versiones de servidor, el archivo de respuesta maneja varias fases o “passes” de configuración, como generalize, specialize, auditSystem, auditUser y oobeSystem. No todas se procesan siempre: algunas solo se ejecutan cuando se usa Sysprep en determinados modos.

Un ejemplo sencillo de base para un fichero Unattend.xml incluye ajustes como SkipRearm, SkipAutoActivation, configuración regional (es-ES), comportamiento de OOBE para saltar el asistente de usuario y máquina, y otros detalles que hacen que la primera experiencia sea completamente desatendida.

Estructura básica de un Unattend.xml para Sysprep

Un archivo Unattend.xml completo se puede diseñar con el Windows System Image Manager (Windows SIM), que forma parte del kit de despliegue (ADK). Crear el fichero desde cero a mano es posible, pero bastante tedioso, porque hay que conocer bien los componentes y su sintaxis XML.

Un fichero base típico puede incluir, por ejemplo, en el pase generalize el componente Microsoft-Windows-Security-SPP con la etiqueta SkipRearm a 1, lo que en versiones antiguas de Windows permitía reiniciar el contador de activación. En versiones recientes, si usas claves de licencia por volumen o claves comerciales, esta configuración es mucho menos necesaria porque Windows se activa automáticamente.

En el pase specialize es frecuente incluir Microsoft-Windows-Security-SPP-UX (con SkipAutoActivation) y Microsoft-Windows-Shell-Setup para cosas como CopyProfile, ComputerName (puede ponerse un comodín), o la zona horaria (por ejemplo, “GMT Standard Time”). Todo esto se aplica cuando el sistema entra en esa fase después de generalizar.

Por último, en la fase oobeSystem se suelen definir parámetros de regionalización, a través de Microsoft-Windows-International-Core (InputLocale, SystemLocale, UILanguage, UserLocale en es-ES), y parámetros de OOBE en Shell-Setup, como HideEULAPage, NetworkLocation, ProtectYourPC, SkipMachineOOBE y SkipUserOOBE, que permiten saltarse gran parte de la configuración inicial.

Una vez tengas el XML preparado, basta con guardarlo como “unattend.xml” en texto plano (cuidado con que el editor no añada la extensión .txt) y colocarlo en la ruta C:\Windows\System32\sysprep, desde donde Sysprep lo detectará o podrás invocarlo manualmente mediante el parámetro /unattend.

Cómo usar Sysprep con un archivo de respuesta Unattend

Sysprep se puede ejecutar tanto con interfaz gráfica (sysprep.exe) como desde una consola de comandos. Cuando lo vas a emplear en un entorno profesional, la ejecución por línea de comandos es la forma más precisa de controlar todos los parámetros.

La orden clásica para preparar una imagen lista para captura suele tener esta forma: sysprep /generalize /oobe /shutdown /unattend:»C:\Windows\System32\sysprep\unattend.xml». Con ella consigues generalizar, indicar que el siguiente arranque vaya a OOBE, apagar el equipo al finalizar y usar el archivo de respuesta concreto que has preparado.

Para lanzar Sysprep con ese comando, lo habitual es abrir una ventana de símbolo del sistema con permisos de administrador, cambiar al directorio C:\Windows\System32\sysprep y escribir la orden completa con sus parámetros. Cualquier error en los conmutadores (o en la ruta del XML) hace que Sysprep no haga exactamente lo que esperas.

Durante la ejecución, Sysprep tardará unos minutos en limpiar el sistema, procesar el archivo Unattend almacenado (o el que especifiques) y dejar la imagen en estado generalizado. Cuando termina, apaga el equipo de forma automática si usaste /shutdown, dejándolo listo para capturar con la herramienta de imagen de tu preferencia.

Es importante que, una vez el equipo de referencia se apague tras Sysprep, no lo vuelvas a arrancar antes de capturar la imagen. Si lo haces, se romperá el estado generalizado y tendrías que repetir todo el proceso de Sysprep nuevamente antes de hacer la captura.

Fases de configuración: generalize, auditSystem, auditUser y oobeSystem

No todas las fases del archivo de respuesta se ejecutan siempre. Algunas, como generalize, auditSystem y auditUser, solo entran en juego cuando interviene Sysprep. Entender cuándo se procesan te ayuda a ubicar correctamente cada configuración en el Unattend.xml.

Las configuraciones de auditSystem y auditUser se aplican cuando el equipo arranca en modo auditoría, algo que puedes forzar con el comando Sysprep /audit. Este modo sirve para que los técnicos añadan drivers, aplicaciones y ajustes adicionales antes de generalizar.

Por su parte, el pase de configuración generalize se procesa al ejecutar el parámetro /generalize de Sysprep. Es aquí donde se eliminan datos de hardware específicos, SIDs y otra información ligada a la máquina, dejando la instalación en un estado que puede clonarse sin conflictos.

La fase oobeSystem se aplica en el primer arranque tras la generalización, cuando el sistema entra en la experiencia de configuración rápida (OOBE). Si has configurado bien el fichero Unattend.xml, este paso puede ser prácticamente automático para el usuario final.

Por lo tanto, si quieres encadenar todo el proceso (personalizar, generalizar, arrancar en auditoría o en OOBE, etc.) de forma totalmente automatizada, tienes que distribuir las opciones entre los passes adecuados y asegurarte de que Sysprep se ejecuta con los parámetros correctos.

Límites, activación y uso del parámetro SkipRearm

Microsoft impone ciertas restricciones al número de veces que puedes ejecutar Sysprep sobre la misma imagen. En Windows 8.1, Windows Server 2012 y versiones posteriores, puedes ejecutarlo hasta 1001 veces; en Windows 7 y Windows Server 2008/2008 R2, el límite es solo 3 usos por imagen.

En versiones antiguas se recurría mucho a la configuración SkipRearm en el archivo de respuesta para reiniciar el contador de activación. En la práctica, esto permitía “alargar” las posibilidades de preparación durante pruebas y despliegues, aunque siempre dentro de los límites de licencia permitidos.

Sin embargo, si empleas claves de producto por volumen o claves comerciales modernas, Windows se activa de forma automática y no sueles necesitar manipular SkipRearm. Aun así, la opción sigue existiendo en los componentes de seguridad (Security-SPP) para entornos donde la activación se gestiona de forma más manual.

Si un proyecto exige múltiples iteraciones de pruebas con Sysprep sobre la misma imagen, conviene planificarse bien y controlar cuántas generalizaciones se ejecutan, para no toparte con el límite y tener que reconstruir la imagen desde cero en el momento menos oportuno.

Controladores Plug and Play y PersistAllDeviceInstalls

Durante la instalación de Windows, el sistema detecta los dispositivos de hardware y configura automáticamente sus controladores. Al generalizar, Sysprep desinstala esos dispositivos configurados, aunque deja los drivers disponibles en el equipo.

Si tu escenario de despliegue es muy homogéneo y todos los equipos destino tienen hardware idéntico al de la máquina de referencia, quizá te interesa conservar esos dispositivos ya instalados. Para eso está la configuración PersistAllDeviceInstalls del componente Microsoft-Windows-PnpSysprep.

En el archivo Unattend.xml, si estableces PersistAllDeviceInstalls en true, Sysprep mantendrá los dispositivos configurados durante la generalización, lo que reduce el tiempo de detección en los equipos finales. Es, básicamente, una optimización para entornos con hardware clónico.

En cambio, si vas a desplegar en modelos distintos con hardware variado, es más prudente dejar que Sysprep desinstale los dispositivos y que en cada equipo se detecten de cero, instalando los controladores adecuados después de restaurar la imagen.

En cualquier caso, recuerda que la referencia para estos componentes está en la documentación oficial de instalación desatendida de Windows, donde se detalla el significado de cada etiqueta del XML que afecta a Sysprep y al subsistema Plug and Play.

Uso de RunSynchronous y ventana AuditUI en modo auditoría

Cuando arrancas Windows en modo auditoría, puedes aprovechar el componente Microsoft-Windows-Deployment para lanzar comandos secuenciales mediante RunSynchronous en los pases auditSystem o auditUser. Esto te permite automatizar scripts, instalaciones o tareas de preparación adicionales.

Durante el paso auditUser, la ventana denominada AuditUI muestra el estado de esos comandos RunSynchronous. Verás una lista con la descripción o la ruta de cada comando, en el orden definido por el valor Order de RunSynchronousCommand.

Sysprep procesa todos los comandos de forma secuencial. Si uno se ejecuta correctamente, aparece con una marca verde en la AuditUI. Si falla, se marca con una X roja, lo que facilita localizar qué parte del proceso de preparación ha dado problemas, incluso cuando el script no genera registros.

La forma en que se gestionan los reinicios automáticos depende de la configuración WillReboot. Si se establece en Always, el equipo se reinicia siempre tras la ejecución del comando, tanto si devuelve 0 (éxito) como un valor distinto de cero. Si se pone en Never, no reinicia nunca, aunque haya errores.

Con WillReboot en OnRequest, los códigos de retorno 0, 1 o 2 tienen significados distintos: 0 indica éxito sin reinicio, 1 provoca reinicio inmediato con éxito, y 2 reinicia pero el comando se considera todavía en curso, volviendo a aparecer en la lista tras el arranque. Cualquier otro código se interpreta como error irrecuperable, lo que puede dar lugar a un cuadro de diálogo de bloqueo, salvo que exista un script Errorhandler.cmd para gestionar el fallo.