Crear un USB de arranque con PowerShell (sin herramientas GUI)

Reglas básicas (qué construimos y por qué)

Un “USB de arranque” no es magia. Es una unidad USB con una tabla de particiones, un sistema de archivos que el firmware puede leer
y archivos de arranque colocados donde el firmware los espera. En hardware moderno eso suele significar que el firmware UEFI
busca \EFI\BOOT\BOOTX64.EFI en un sistema de archivos FAT32.

Cuando usas herramientas GUI, ellas toman decisiones en tu nombre de forma silenciosa: GPT vs MBR, FAT32 vs NTFS,
si crear una o dos particiones, si escribir imágenes en crudo o copiar archivos.
Esas decisiones pueden ser correctas para una máquina y erróneas para la siguiente.
PowerShell te permite decidir deliberadamente y, igual de importante, registrar lo que hiciste.

Nuestro objetivo por defecto en este artículo: una ISO de instalación de Windows (Windows 10/11, Server) escrita en USB
de manera que arranque en sistemas UEFI. También cubriremos BIOS/CSM y la clásica trampa:
las ISOs de Windows suelen contener un archivo mayor de 4 GB, que FAT32 no puede almacenar.

Posición con opinión: para amplia compatibilidad, construye un USB arrancable UEFI con FAT32 y maneja correctamente el problema del archivo de 4 GB.
Evita soluciones ingeniosas hasta que hayas validado el método sencillo.

Datos interesantes y pequeñas lecciones de historia

• El Torito (1990s) es el estándar de arranque de CD-ROM que popularizó los medios de instalación booteables. El arranque por USB luego tomó el modelo de “pretender que es un disco”.
• La ruta de medios extraíbles de UEFI (\EFI\BOOT\BOOTX64.EFI) existe específicamente para que un USB pueda arrancar sin entradas NVRAM.
• FAT32 no es “antiguo”, es “amigable con el firmware”. La especificación UEFI requiere que el firmware pueda leer FAT, por eso FAT32 sigue siendo relevante en 2026.
• El soporte NTFS en firmware no está garantizado. Algunos proveedores lo implementan, muchos no, y algunos lo hacen mal.
• GPT en unidades extraíbles solía ser un campo minado; muchos sistemas de la era BIOS sólo entendían MBR. UEFI normalizó GPT.
• El medio de instalación de Windows evolucionó de install.wim a veces a install.esd para reducir tamaño; las imágenes empresariales todavía suelen incluir WIM grandes.
• Secure Boot endureció las reglas: los cargadores de arranque deben estar firmados (o la plataforma en Modo de Configuración). Tu USB puede ser perfecto y aun así “no arrancar” por política.
• El arranque USB temprano era inestable porque los proveedores de BIOS trataban el almacenamiento masivo USB como un complemento. Algo de ese ADN aún aparece en menús de arranque extraños.

Broma #1: UEFI es como el arte moderno—algunas personas insisten en que es hermoso, y todos los demás sólo quieren que la puerta se abra.

Guía de diagnóstico rápido (encuentra el cuello de botella)

Primero: ¿la máquina realmente intenta arrancar lo correcto?

• Revisa la entrada del menú de arranque: ¿es la entrada “UEFI: USB” o la legacy/CSM?
• Si Secure Boot está habilitado, confirma que la ISO sea una publicación oficial de Microsoft o esté firmada adecuadamente.
• Si es una VM o un KVM remoto, confirma que la “redirección USB” no esté presentando el dispositivo como una unidad de CDROM u otra emulación extraña.

Segundo: ¿el USB está formateado de forma legible por el firmware?

• Para UEFI, la partición que contiene \EFI debe ser FAT32 en el caso general.
• Verifica si accidentalmente creaste exFAT (a Windows le gusta; al firmware a menudo no).
• Confirma que la partición esté presente y tenga una letra de unidad cuando se conecte a Windows.

Tercero: ¿los archivos de arranque necesarios existen en la ruta esperada?

• En el USB, verifica que \EFI\BOOT\BOOTX64.EFI exista para sistemas UEFI x64.
• Para BIOS, verifica que exista un sector de arranque adecuado y los archivos del cargador relevantes (varía según la ISO).
• No adivines. Lista los directorios y valida las rutas.

Cuarto: ¿el tamaño de archivo rompe FAT32?

• Si la ISO tiene \sources\install.wim > 4 GB, copiar archivos directamente a FAT32 fallará o omitirá archivos silenciosamente según tu proceso.
• Solución: dividir el WIM o usar un enfoque de dos particiones (FAT32 + NTFS) si es imprescindible.

Quinto: ¿el medio en sí es basura?

• Sí, incluso las unidades USB “nuevas” fallan. Prueba lectura/escritura, reformatea, prueba otro puerto (especialmente los puertos frontales USB 3 en placas antiguas).
• Si no puedes reproducir el problema con otra memoria, deja de discutir con la física y reemplázala.

Requisitos y comprobaciones de seguridad (no borres el disco equivocado)

Estás a punto de ejecutar comandos que pueden borrar discos al instante. La única barrera de seguridad fiable es tu propia disciplina.
Si estás en un portátil con un SSD USB externo conectado y “limpias” el disco equivocado, aprenderás emociones nuevas.

Qué necesitas

• Windows 10/11 o Windows Server con PowerShell y privilegios de administrador.
• Una unidad USB (mínimo 8 GB; 16+ GB es más cómodo).
• Un archivo ISO de Windows accesible localmente.

Tarea 1: Identificar discos y confirmar el USB por tamaño y tipo de bus

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Sort-Object Number | Format-Table Number,FriendlyName,BusType,Size,PartitionStyle -Auto"
Number FriendlyName              BusType    Size PartitionStyle
------ ------------              -------    ---- --------------
0      NVMe Samsung SSD 980      NVMe   1000204886016 GPT
1      SanDisk Ultra USB 3.0     USB       16008609792 RAW

Qué significa: El disco 1 es USB, 16 GB, actualmente RAW (sin tabla de particiones).

Decisión: El disco 1 es el objetivo. Si tu USB aparece como otra cosa (como “SATA”), detente e investiga—algunas bases mienten.

Tarea 2: Comprobación de volumen (evita borrar el equivocado)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size -Auto"
DriveLetter FileSystemLabel FileSystem SizeRemaining        Size
---------- -------------- ---------- -------------        ----
C          Windows        NTFS        215.73 GB       930.89 GB
E          BACKUP         NTFS        120.11 GB       465.76 GB

Qué significa: Tu USB puede ni siquiera tener letra de unidad aún, lo cual está bien.

Decisión: Si el USB ya tiene una letra y contiene algo que te importa, cópialo ahora. Lo borraremos.

Tarea 3: Confirmar que la ISO existe y no es una descarga parcial

cr0x@server:~$ powershell -NoProfile -Command "$iso='C:\ISO\Win11_23H2_English_x64.iso'; Get-Item $iso | Format-List Name,Length,LastWriteTime"
Name          : Win11_23H2_English_x64.iso
Length        : 6640211968
LastWriteTime : 01/10/2026 14:21:53

Qué significa: La ISO existe y pesa ~6.6 GB.

Decisión: Si el tamaño es sospechosamente pequeño (como unos MB), detente—tu ISO no es real.

Método: ISO de Windows → USB booteable (compatible UEFI)

Hay dos maneras básicas de crear un USB de arranque:

1. Método de copia de archivos: particionar + formatear el USB, montar la ISO, copiar archivos. Esto es lo que haremos.
2. Escritura de imagen en crudo: escribir una imagen de disco bit a bit. Las ISOs de Windows típicamente no están pensadas para escribirse en crudo al USB como muchas ISOs de Linux.

Para medios de instalación de Windows, el método de copia de archivos es predecible y mantenible. También facilita manejar el límite de 4 GB.

Tarea 4: Limpiar e inicializar el USB como GPT (UEFI-primero)

cr0x@server:~$ powershell -NoProfile -Command "$disk=1; Clear-Disk -Number $disk -RemoveData -Confirm:\$false; Initialize-Disk -Number $disk -PartitionStyle GPT; Get-Disk -Number $disk | Format-Table Number,PartitionStyle,Size -Auto"
Number PartitionStyle   Size
------ --------------   ----
1      GPT           14.91 GB

Qué significa: El disco 1 ahora es GPT.

Decisión: Si necesitas que este USB arranque en máquinas antiguas sólo BIOS, considera MBR en su lugar. Para la mayoría de flotas modernas, GPT es la opción por defecto.

Tarea 5: Crear una sola partición FAT32 y asignar letra

cr0x@server:~$ powershell -NoProfile -Command "$disk=1; $p=New-Partition -DiskNumber $disk -UseMaximumSize -AssignDriveLetter; Format-Volume -Partition $p -FileSystem FAT32 -NewFileSystemLabel 'WINSTALL' -Confirm:\$false; Get-Volume -FileSystemLabel WINSTALL | Format-Table DriveLetter,FileSystem,Size,SizeRemaining -Auto"
DriveLetter FileSystem   Size SizeRemaining
---------- ----------   ---- -------------
F          FAT32     14.90 GB     14.85 GB

Qué significa: El USB ahora es la unidad F: formateada en FAT32.

Decisión: Anota la letra de unidad. Copiaremos el contenido de la ISO allí.

Tarea 6: Montar la ISO y encontrar su letra de unidad

cr0x@server:~$ powershell -NoProfile -Command "$iso='C:\ISO\Win11_23H2_English_x64.iso'; $img=Mount-DiskImage -ImagePath $iso -PassThru; ($img | Get-Volume) | Format-Table DriveLetter,FileSystemLabel,FileSystem -Auto"
DriveLetter FileSystemLabel FileSystem
---------- -------------- ----------
D          CCCOMA_X64FRE   UDF

Qué significa: La ISO se montó como D: (sistema de archivos UDF, como es esperable en imágenes ópticas).

Decisión: Copiaremos desde D:\ a F:\.

Tarea 7: Inspeccionar la ISO por archivos de arranque UEFI antes de copiar

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path 'D:\EFI\BOOT' | Select-Object Name,Length | Format-Table -Auto"
Name         Length
----         ------
BOOTX64.EFI  1528832

Qué significa: La ISO contiene el cargador de arranque UEFI para medios extraíbles.

Decisión: Buen indicio. Si D:\EFI\BOOT\BOOTX64.EFI falta, la ISO podría no ser arrancable por UEFI tal cual.

Tarea 8: Verificar la “bomba de tiempo” FAT32 (tamaño de install.wim)

cr0x@server:~$ powershell -NoProfile -Command "Get-Item 'D:\sources\install.wim' -ErrorAction SilentlyContinue | Format-List Name,Length"
Name   : install.wim
Length : 4875429312

Qué significa: install.wim pesa ~4.8 GB. FAT32 no puede almacenar un solo archivo mayor de 4 GB.

Decisión: No copies la ISO a ciegas. Usa el método de división de WIM abajo.

Tarea 9: Copiar todo excepto install.wim, luego dividir el WIM en partes SWM

El enfoque limpio: copia todos los archivos, omitiendo el WIM grande, y después usa DISM para dividirlo en varios archivos .swm
que quepan cada uno por debajo de 4 GB. El instalador de Windows reconoce install.swm automáticamente.

cr0x@server:~$ powershell -NoProfile -Command "robocopy D:\ F:\ /E /R:2 /W:1 /XF install.wim /XD 'System Volume Information' /NFL /NDL"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Started : Thursday, February 5, 2026 9:12:51 AM
   Source : D:\
     Dest : F:\

    Files : *.*

  Options : *.* /NFL /NDL /S /E /DCOPY:DA /COPY:DAT /R:2 /W:1

------------------------------------------------------------------------------

  Total    Copied   Skipped  Mismatch    FAILED    Extras
   Dirs :       62        62        0        0        0        0
  Files :      987       986        1        0        0        0
  Bytes :  5.92 g   1.36 g   4.56 g        0        0        0
  Times :   0:02:31   0:02:31                       0:00:00   0:00:00

  Ended : Thursday, February 5, 2026 9:15:22 AM

Qué significa: Se omitió un archivo: install.wim. Eso es intencional.

Decisión: Ahora genera las partes install.swm en el USB.

cr0x@server:~$ powershell -NoProfile -Command "dism /Split-Image /ImageFile:D:\sources\install.wim /SWMFile:F:\sources\install.swm /FileSize:3800"
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Splitting image: D:\sources\install.wim
[==========================100.0%==========================]
The operation completed successfully.

Qué significa: DISM dividió el WIM en partes: install.swm, install2.swm, etc.

Decisión: Confirma que los archivos existen y que cada uno está por debajo de 4 GB.

Tarea 10: Validar los archivos SWM y eliminar cualquier copia accidental del WIM

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'F:\sources' -Filter 'install*.s*' | Select-Object Name,Length | Format-Table -Auto"
Name           Length
----           ------
install.swm    3984568320
install2.swm   3961206784

Qué significa: Las partes SWM existen y caben dentro del límite de FAT32.

Decisión: Asegúrate de que F:\sources\install.wim no exista. El instalador debe ver sólo las partes SWM en este caso.

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'F:\sources\install.wim'"
False

Tarea 11: Desmontar la ISO limpiamente

cr0x@server:~$ powershell -NoProfile -Command "$iso='C:\ISO\Win11_23H2_English_x64.iso'; Dismount-DiskImage -ImagePath $iso"

Qué significa: La ISO ya no está montada.

Decisión: Expulsa el USB de forma segura cuando estés listo, pero primero verifica archivos de arranque y estructura.

Broma #2: Un USB booteable es solo un disco pequeño con grandes expectativas—como mi primer turno de guardia.

Gestión de install.wim mayor de 4 GB (realidad FAT32)

El tamaño máximo de un solo archivo en FAT32 es 4 GiB menos 1 byte. Esto no es negociable. No puedes “forzarlo.”
Si lo intentas, obtendrás un error de copia, o peor: una herramienta que afirma éxito pero omite el archivo silenciosamente.
Cualquiera de los resultados conduce a un USB que arranca bien y falla después, justo cuando Setup necesita la imagen.

Opción A (recomendada): dividir el WIM en SWM

Esto es lo que hicimos arriba. Preserva la compatibilidad UEFI y mantiene el USB simple: una partición, un sistema de archivos, un conjunto de expectativas.
También hace tu proceso auditable—DISM muestra lo que hizo.

Opción B: Dos particiones (FAT32 para arranque + NTFS para payload)

A veces distribuyes una imagen personalizada y dividir no es deseable. Un patrón común es:
partición FAT32 que contiene \EFI y archivos de arranque, más una partición NTFS que contiene el WIM grande.
Esto puede funcionar, pero incrementa la variabilidad del firmware y el error humano. Algunos sistemas solo enumeran la primera partición en medios extraíbles.
Algunos menús de arranque se confunden. Algunas personas copian cosas al lugar equivocado.

Si lo haces de todos modos, mantén la partición FAT32 primero, pequeña (por ejemplo 1–2 GB), y verifica que tu hardware objetivo pueda ver ambas particiones.
Para el instalador de Windows específicamente, debes asegurarte de que Setup pueda acceder a la partición NTFS durante el WinPE arrancado.
La mayoría de las compilaciones modernas de WinPE pueden, pero “la mayoría” no es una categoría de control de cambios.

Opción C: Convertir WIM a ESD (a veces)

Convertir WIM a ESD puede reducir el tamaño, pero no siempre es apropiado para flujos de trabajo de imagen empresarial.
También puede afectar escenarios de mantenimiento. Si no sabes ya por qué quieres ESD, probablemente no lo necesites.

Notas sobre BIOS heredado (cuando estás atrapado en 2009)

El arranque por USB en BIOS heredado es otro mundo: espera sectores de arranque y a menudo prefiere MBR.
Algunas ISOs de Windows incluyen soporte de arranque BIOS; algunas plataformas requieren un diseño estilo “USB-HDD”.

Si debes soportar hardware sólo BIOS, considera inicializar el USB como MBR en lugar de GPT. Dicho esto, muchos entornos “soportan BIOS”
en política mientras que el hardware real ha sido UEFI la última década. Verifica antes de diseñar para fantasmas.

Tarea 12: Inicializar el USB como MBR (alternativa amigable para BIOS)

cr0x@server:~$ powershell -NoProfile -Command "$disk=1; Clear-Disk -Number $disk -RemoveData -Confirm:\$false; Initialize-Disk -Number $disk -PartitionStyle MBR; Get-Disk -Number $disk | Format-Table Number,PartitionStyle -Auto"
Number PartitionStyle
------ --------------
1      MBR

Qué significa: El USB ahora usa MBR.

Decisión: Haz esto solo si realmente necesitas arranque BIOS. De lo contrario, mantén GPT para flotas UEFI-primero.

Para arranque BIOS, las particiones “activas” siguen importando en algunos casos. Los cmdlets de almacenamiento de PowerShell no exponen todas las banderas de la era BIOS con limpieza.
Cuando estás en compatibilidad heredada profunda, diskpart a veces es la herramienta menos mala. Si tu requisito es realmente “solo PowerShell,”
aún puedes invocar diskpart desde PowerShell. Eso no es una herramienta GUI; es solo un cuchillo afilado.

Tareas de verificación (prueba que arrancará)

Instinto SRE: no confíes en los mensajes de éxito. Mide. Valida. Recolecta evidencia que puedas adjuntar a un ticket cuando alguien diga
“el USB que hiciste no funciona” mientras arranca por la red por accidente.

Tarea 13: Confirmar sistema de archivos y espacio libre en el USB

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume -DriveLetter F | Format-List DriveLetter,FileSystem,HealthStatus,Size,SizeRemaining"
DriveLetter   : F
FileSystem    : FAT32
HealthStatus  : Healthy
Size          : 16000143360
SizeRemaining : 8429182976

Qué significa: FAT32, saludable, suficiente espacio libre.

Decisión: Si es exFAT o NTFS y esperas arranque UEFI en todas partes, corrígelo ahora en vez de discutir con el firmware más tarde.

Tarea 14: Verificar que exista la ruta de arranque de medios extraíbles en el USB

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'F:\EFI\BOOT\BOOTX64.EFI'"
True

Qué significa: El archivo clave de arranque UEFI existe.

Decisión: Si False, tu copia no incluyó archivos EFI (o montaste la ISO equivocada). Recopia y vuelve a verificar.

Tarea 15: Validar que el directorio \sources tenga lo que Setup necesita

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'F:\sources' | Select-Object -First 10 Name | Format-Table -Auto"
Name
----
acmigration.dll
background.bmp
boot.wim
compatresources.dll
diagerr.xml
diskpart.exe
etwproviders.dll
inf
install.swm
install2.swm

Qué significa: boot.wim existe y hay partes SWM presentes.

Decisión: Si boot.wim falta, el USB puede arrancar en vacío o fallar pronto.

Tarea 16: Confirmar que el USB se lea de extremo a extremo (spot-check de hash rápido)

cr0x@server:~$ powershell -NoProfile -Command "Get-FileHash 'F:\EFI\BOOT\BOOTX64.EFI' -Algorithm SHA256 | Format-List Algorithm,Hash"
Algorithm : SHA256
Hash      : 4C5E9AB2D16B9F5D3B8C0CE4D8B6F26B1D9C3B7D8B7B7C3A9B0D2D4E9A5F0B1C

Qué significa: El archivo es legible y se puede hashear; no estás encontrando errores de E/S inmediatos.

Decisión: Si el hash lanza errores, el USB puede estar fallando. Reemplázalo en vez de depurar fantasmas.

Tarea 17: Confirmar que el diseño de particiones sea lo que crees

cr0x@server:~$ powershell -NoProfile -Command "Get-Partition -DiskNumber 1 | Format-Table DiskNumber,PartitionNumber,DriveLetter,Size,GptType,MbrType -Auto"
DiskNumber PartitionNumber DriveLetter    Size GptType                               MbrType
---------- --------------- -----------    ---- -------                               ------
1          1               F           14.90 GB EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Qué significa: Partición de datos única en GPT (datos básicos).

Decisión: Para arranque UEFI en medios extraíbles, lo crítico es FAT32 + ruta EFI. El tipo de partición importa menos que el contenido,
pero diseños extraños pueden confundir firmware antiguo.

Tarea 18: Comprobación rápida del tamaño de directorio (¿copiaste realmente la mayor parte de la ISO?)

cr0x@server:~$ powershell -NoProfile -Command "(Get-ChildItem F:\ -Recurse -Force | Measure-Object -Property Length -Sum).Sum"
5123456789

Qué significa: Los bytes totales en el USB es un valor multi-gig plausible.

Decisión: Si es pequeño (cientos de MB), no copiaste correctamente o omitiste demasiado.

Una cita de operaciones (idea parafraseada)

idea parafraseada — Gene Kranz: “Lo duro y competente” vence al pánico; en operaciones, la disciplina gana cuando los sistemas se comportan mal.

Tres mini-historias corporativas (cosas que realmente suceden)

Incidente: una suposición errónea sobre NTFS y UEFI

Una empresa mediana tenía un proceso estándar para “USB de recuperación de Windows” a cargo del soporte de escritorio. Funcionaba bien en sus portátiles más nuevos,
así que todos declararon que estaba resuelto. Luego un lote de servidores rack necesitó reinstalación de emergencia después de que una actualización de firmware del controlador de almacenamiento saliera mal.
El equipo remoto llegó con el USB. Los servidores miraron, sin impresiones.

La suposición fue simple: “UEFI puede arrancar desde NTFS, porque arranca desde nuestro USB NTFS en portátiles.”
Eso era accidentalmente cierto en ese modelo de portátil porque el firmware del proveedor incluía controladores NTFS.
El firmware de los servidores no lo tenía. Sin soporte NTFS, no hay arranque.

El equipo intentó alternar Secure Boot, cambiar puertos y cambiar memorias. Nada. El USB aparecía en el menú de arranque, pero el arranque fallaba al instante.
Alguien sugirió “quizá la ISO está corrupta”, que era una historia reconfortante porque no implicaba un error de diseño.

La solución fue dolorosamente aburrida: volver a crear el USB como FAT32 y dividir el WIM. Después de eso, los servidores arrancaron a la primera.
El resultado real no fue sólo “sistemas restaurados”. Actualizaron el runbook interno para especificar FAT32 para medios extraíbles UEFI y un paso de validación
para comprobar que \EFI\BOOT\BOOTX64.EFI existe.

Lección post-incidente: el éxito en una clase de hardware no es prueba. El firmware es una plataforma. Trátala como tal.

Optimización que salió mal: “hagámoslo más rápido” con flags agresivos de copia

Otro equipo quiso acelerar la creación de USB instaladores para un proyecto de migración. Alguien se puso ingenioso con trabajos de copia paralelos
y una política de reintento corta para “fallar rápido”. El script usó jobs en background para copiar múltiples directorios a la vez,
luego declaró éxito si los jobs no lanzaban errores terminantes.

Fue rápido. También estaba equivocado de una manera sutil: errores de lectura transitorios en medios USB baratos hicieron que un puñado de archivos se omitieran,
pero los jobs terminaron. El script no validó conteos de archivos ni rutas críticas. El USB arrancaba, iniciaba Windows Setup y luego fallaba durante la instalación
con errores de componentes faltantes que parecían miseria aleatoria de WinPE.

Lo peor: fallaba raramente. Eso hizo que escapara a las pruebas y apareciera como “fallos en campo”.
Nada destruye un cronograma de despliegue como defectos intermitentes en el medio que parecen errores del SO.

La solución fue dejar de optimizar lo incorrecto. Volvieron a un solo robocopy con registro explícito,
más un pequeño conjunto de validaciones obligatorias: presencia de archivos de arranque, existencia de boot.wim, y una comprobación de que
la división SWM completó con éxito. El tiempo total aumentó ligeramente. La tasa de fallos cayó a prácticamente cero.

Lección: las optimizaciones de rendimiento sin comprobaciones de corrección son solo maneras más rápidas de equivocarse.

Práctica aburrida pero correcta que salvó el día: etiquetado y selección determinista de disco

En un entorno regulado, un equipo de infra mantenía un proceso scriptado para construir USB de recuperación bare-metal.
El script hacía una cosa poco sexy excepcionalmente bien: nunca seleccionaba el disco objetivo por “el disco que parece un USB.”
Requería que el operador confirmara el número de disco y estampaba el USB con una etiqueta de volumen conocida.

Una tarde, un ingeniero ejecutó el script en una estación con un adaptador USB-a-SATA enchufado.
Windows lo reportó como un dispositivo algo extraíble, y tenía un tamaño parecido al del objetivo.
En un mal día, así es como borras una unidad de backup externa y pasas el fin de semana pidiendo disculpas.

Pero el script forzaba dos confirmaciones: primero imprimía la lista de discos, luego demandaba que el operador tecleara el número exacto del disco,
y finalmente comprobaba que la etiqueta del volumen recién formateado coincidiera con un valor esperado antes de copiar archivos.
El ingeniero notó la discrepancia de etiqueta en el segundo aviso y se detuvo.

Más tarde, cuando el mismo equipo tuvo que reconstruir medios rápidamente durante un incidente, ese proceso determinista significó que cualquiera de guardia
podía hacerlo sin “conocimiento tribal”. También produjo logs que satisfacían requisitos de auditoría sin drama.

Lección: las barreras aburridas son lo que quieres a las 2 a.m. No te hacen sentir inteligente, que precisamente es el punto.

Errores comunes: síntoma → causa raíz → solución

1) El USB aparece en el menú de arranque pero vuelve inmediatamente al BIOS/UEFI

Causa raíz: Archivo de arranque UEFI faltante o mal ubicado (\EFI\BOOT\BOOTX64.EFI), o sistema de archivos incorrecto (exFAT/NTFS en firmware que solo lee FAT).

Solución: Formatea FAT32, recopia el contenido de la ISO, verifica que Test-Path F:\EFI\BOOT\BOOTX64.EFI sea True.

2) El arranque inicia, Windows Setup carga y luego la instalación falla por archivos faltantes

Causa raíz: install.wim no se copió a FAT32 por el límite de 4 GB, o se omitió durante la copia.

Solución: Divide el WIM en SWM con DISM; confirma que existan los archivos SWM y que no quede install.wim en FAT32.

3) La operación de copia “tuvo éxito”, pero el contenido del USB es demasiado pequeño

Causa raíz: Copiaron desde la fuente equivocada (no la ISO montada), o robocopy excluyó directorios, o permisos ocultaron errores.

Solución: Vuelve a montar la ISO, verifica la letra de origen, vuelve a ejecutar robocopy sin filtros excesivos y comprueba el total de bytes copiados.

4) El USB arranca en portátiles pero no en servidores

Causa raíz: Características específicas del firmware del proveedor (soporte NTFS, comportamiento distinto con medios extraíbles, peculiaridades de inicialización de puertos USB).

Solución: Usa la ruta UEFI FAT32, prefiere puertos traseros de la placa base y valida en la clase de hardware objetivo—no en el portátil más cercano.

5) Secure Boot bloquea el arranque con una violación de política

Causa raíz: Cargador de arranque sin firmar o modificado, o medios no Microsoft en un entorno de Secure Boot estricto.

Solución: Usa medios oficiales o registra las claves apropiadas; no “resuelvas” desactivando Secure Boot a menos que la política lo permita.

6) El USB desaparece intermitentemente o causa errores de E/S durante la copia

Causa raíz: Medio USB defectuoso, puerto/hub inestable o problemas de alimentación en puertos frontales.

Solución: Prueba con otro USB y puerto; si el hash de archivos lanza errores, deja de depurar y reemplaza el hardware.

7) UEFI arranca, pero teclado/ratón no funcionan en WinPE

Causa raíz: Dispositivo de entrada USB no inicializado correctamente (algunas configuraciones de firmware, problemas de xHCI), o drivers faltantes en WinPE para cierto hardware.

Solución: Usa otros puertos (USB 2 si está disponible), ajusta la configuración USB del firmware, o usa medios de instalación actualizados con soporte de drivers más amplio.

8) “Acceso denegado” al formatear o asignar letra

Causa raíz: No ejecutar PowerShell elevado, o un proceso mantiene el volumen abierto.

Solución: Ejecuta PowerShell como Administrador; cierra ventanas del Explorador; vuelve a ejecutar comprobaciones con Get-Process si es necesario.

Listas de verificación / plan paso a paso

Lista A: USB instalador Windows UEFI-primero (una partición FAT32)

1. Identifica el disco objetivo: Get-Disk y confirma por BusType=USB y tamaño.
2. Limpia e inicializa como GPT: Clear-Disk, Initialize-Disk -PartitionStyle GPT.
3. Crea partición + formatea FAT32 + etiqueta: New-Partition, Format-Volume -FileSystem FAT32.
4. Monta la ISO: Mount-DiskImage; captura la letra de la ISO.
5. Verifica el tamaño de install.wim; si > 4 GB, planifica dividirlo.
6. Copiar contenido de la ISO omitiendo install.wim con robocopy.
7. Dividir WIM a SWM con DISM en F:\sources.
8. Verificar: que exista \EFI\BOOT\BOOTX64.EFI; que exista boot.wim; que existan archivos SWM; que el volumen sea FAT32.
9. Desmontar ISO; expulsar USB.

Lista B: Verificación mínima antes de entregar el USB a otra persona

1. Ruta de arranque: Test-Path F:\EFI\BOOT\BOOTX64.EFI debe ser True.
2. WinPE: Test-Path F:\sources\boot.wim debe ser True.
3. Payload de instalación: o bien existe install.esd, o existen install.swm (y no faltan piezas).
4. Sistema de archivos: Get-Volume muestra FAT32.
5. Integridad de copia: ejecuta al menos un Get-FileHash en un par de archivos clave para asegurar estabilidad de lectura.

Lista C: Si estás automatizando esto en un script

• Requerir una entrada explícita del número de disco; nunca selecciones automáticamente.
• Escribir logs: selección de disco, estilo de partición, etiqueta del volumen, resumen de robocopy, salida de DISM.
• Fallar de forma estricta si faltan rutas obligatorias después de la copia.
• Mantener el script idempotente cuando sea posible (limpiar disco y luego construir el mismo diseño cada vez).

Preguntas frecuentes

1) ¿Puedo crear un USB booteable de Windows simplemente copiando el archivo ISO al disco?

No. El firmware no arranca un archivo ISO sentado en un sistema de archivos (no en el caso general). Arranca un cargador desde un sistema de archivos o un sector de arranque.
Debes montar la ISO y copiar su contenido (o escribir correctamente una imagen de disco con estructura de arranque).

2) ¿Por qué FAT32? Parece antiguo.

Porque el firmware puede leerlo. Las implementaciones UEFI están obligadas a soportar FAT. El soporte NTFS es opcional e inconsistente.
FAT32 es el formato aburrido que funciona cuando tratas con placas de servidor aleatorias en momentos inconvenientes.

3) ¿Qué pasa si mi ISO tiene install.esd en lugar de install.wim?

Bien. ESD suele ser más pequeño, así que normalmente cabe en FAT32 sin dividir.
Verifica el tamaño de todos modos: Get-Item D:\sources\install.esd.

4) ¿Necesito GPT para el USB?

Para arranque UEFI, GPT es una buena opción por defecto. Algunos firmwares arrancan UEFI desde MBR también.
Si apuntas a BIOS heredado, MBR suele ser más seguro. Si apuntas a servidores modernos, GPT mantiene las cosas consistentes.

5) ¿Por qué no usar diskpart en vez de los cmdlets de PowerShell?

Puedes invocar diskpart desde PowerShell y a veces es la opción pragmática para casos límite.
Pero los cmdlets de PowerShell son más scriptables, más fáciles de inspeccionar y, en general, más sencillos de validar con salida estructurada.

6) El USB es FAT32, los archivos de arranque existen, pero aún así no arranca. ¿Y ahora qué?

Revisa la selección del modo de arranque (UEFI vs legacy), la política de Secure Boot y prueba otro puerto.
Luego sospecha del propio USB. Si sólo falla en un modelo de hardware, sospecha peculiaridades del firmware o falta de soporte para medios multipartición.

7) ¿Puedo crear un USB booteable para distribuciones Linux con el mismo método?

A veces, pero muchas ISOs de Linux están diseñadas como imágenes híbridas que es mejor escribir en crudo.
Este artículo se centra en medios de instalación de Windows. La copia de archivos funciona cuando la estructura de arranque de la ISO lo espera; la escritura en crudo funciona cuando la ISO está construida para ello.

8) ¿Cómo sé si mi fallo es “USB no arrancable” vs “problema del instalador”?

Si nunca llegas a la interfaz del instalador, normalmente es ruta de arranque/sistema de archivos/modo de firmware.
Si llegas a Setup y falla después (copiando archivos, seleccionando edición, aplicando imagen), suele ser archivos de payload faltantes o corruptos (WIM/SWM/ESD).

9) ¿Puedo hacer esto sin permisos de Administrador?

No de manera fiable. Formatear discos y montar imágenes normalmente requiere elevación.
Si estás en un entorno restringido, trabaja con quien controla los privilegios de endpoints—no lo “arregles” con herramientas dudosas.

10) ¿Debería deshabilitar “formato rápido” por seguridad?

El formato rápido está bien en la mayoría de los casos. No prueba toda la superficie.
Si sospechas de medio defectuoso, reemplaza el USB o ejecuta comprobaciones más rigurosas; no pretendas que formatear valide hardware.

Conclusión: siguientes pasos prácticos

Si recuerdas solo tres cosas, recuerda estas: elige el disco correcto a propósito, usa FAT32 para compatibilidad de arranque UEFI y maneja el límite de 4 GB
dividiendo el WIM en lugar de esperar que desaparezca por arte de magia.

Siguientes pasos:

1. Convierte tu secuencia final de comandos en un script con confirmación explícita de disco y validaciones post-copia.
2. Prueba en la misma clase de hardware en la que vas a instalar (el firmware de servidores no es un portátil).
3. Mantén un USB conocido y bueno en una bolsa etiquetada y trátalo como herramienta de incidentes—porque eso es lo que es.

El objetivo no es sentirse ingenioso. El objetivo es arrancar a la primera cuando el sistema ya está en llamas.