Створення завантажувального USB за допомогою PowerShell (без GUI)

Основні правила (що ми будуємо і навіщо)

«Завантажувальний USB» — це не магія. Це флешка з таблицею розділів, файловою системою, яку може прочитати прошивка,
і файлами завантаження, розміщеними там, де їх очікує прошивка. На сучасному обладнанні це зазвичай означає, що прошивка UEFI
шукає \EFI\BOOT\BOOTX64.EFI на файловій системі FAT32.

Коли ви користуєтеся GUI-інструментами, вони непомітно приймають рішення за вас: GPT чи MBR, FAT32 чи NTFS,
створити один чи два розділи, записати сирі образи чи скопіювати файли.
Ці рішення можуть бути вірними для однієї машини й хибними для наступної.
PowerShell дозволяє вам приймати рішення свідомо і — що не менш важливо — вести лог дій.

Наш основний сценарій у цій статті: Windows інсталяційний ISO (Windows 10/11, Server), записаний на USB
так, щоб він завантажувався на системах UEFI. Ми також розглянемо BIOS/CSM та класичну підводну камінь:
Windows ISO часто містять файл більше 4 GB, який FAT32 не може зберегти.

Оціночна позиція: для широкої сумісності будуйте USB, що завантажується в UEFI з FAT32 і вирішуйте проблему файлу >4 GB правильно.
Уникайте хитрих обхідних шляхів, поки не підтвердите простий і надійний метод.

Цікаві факти та коротка історія

• El Torito (1990‑ті) — стандарт завантаження з CD-ROM, який зробив завантажувальні інсталяційні носії масовими. Пізніше USB-boot запозичив модель «прикидатися диском».
• Шлях для знімних носіїв у UEFI (\EFI\BOOT\BOOTX64.EFI) існує спеціально для того, щоб USB міг завантажитися без запису у NVRAM.
• FAT32 не «старий», він «дружній до прошивки». Специфікація UEFI вимагає від прошивки підтримки читання FAT, саме тому FAT32 залишається релевантним у 2026 році.
• Підтримка NTFS у прошивці не гарантована. Деякі виробники реалізують її, багато хто — ні, а дехто робить це погано.
• GPT на знімних дисках колись був мінним полем; багато BIOS-епохи систем розуміли лише MBR. UEFI зробив GPT нормою.
• Інсталяційні носії Windows еволюціонували від install.wim до іноді install.esd для зменшення розміру; у корпоративних образах все ще часто використовують великі WIM-файли.
• Secure Boot посилив правила: завантажувачі мають бути підписані (або платформа має бути в режимі Setup). Ваш USB може бути ідеальним і все одно «не завантажуватися» через політику.
• Ранні спроби USB-завантаження були ненадійні, бо постачальники BIOS ставилися до USB-масивного сховища як до додатку. Частина тієї ДНК інколи проявляється в дивних меню завантаження.

Жарт №1: UEFI — як сучасне мистецтво: хтось наполягає, що воно прекрасне, а інші просто хочуть, щоб двері відчинилися.

Швидкий план діагностики (знайдіть вузьке місце швидко)

По-перше: машина взагалі намагається завантажитися з правильного носія?

• Перевірте запис у меню завантаження: це запис «UEFI: USB» чи легасі/CSM?
• Якщо увімкнено Secure Boot, підтвердьте, що ISO — офіційний реліз Microsoft або відповідно підписаний.
• Якщо це VM чи віддалений KVM, підтвердьте, що «USB redirection» не відображається як CD-ROM-пристрій або якась емульована дивина.

По-друге: чи відформатований USB у спосіб, який читає прошивка?

• Для UEFI розділ з \EFI зазвичай має бути FAT32.
• Перевірте, чи випадково ви не зробили exFAT (Windows любить, а прошивка часто — ні).
• Підтвердьте, що розділ існує і має літеру диска при підключенні до Windows.

По-третє: чи потрібні файли завантаження знаходяться в очікуваному шляху?

• На USB перевірте наявність \EFI\BOOT\BOOTX64.EFI для x64 UEFI-систем.
• Для BIOS перевірте наявність правильного завантажувального сектора та відповідних файлів завантажувача (залежить від ISO).
• Не здогадуйтеся. Перелікуйте каталоги й валідовуйте шляхи.

По-четверте: чи не ламає FAT32 розмір файлу?

• Якщо в ISO є \sources\install.wim > 4 GB, звичайне копіювання на FAT32 не пройде або файл буде пропущено в залежності від процесу.
• Виправте шляхом розбиття WIM або використання двопартійного підходу (FAT32 + NTFS), якщо потрібно.

По-п’яте: чи сам носій не сміттєвий?

• Так, навіть «нові» USB-флешки виходять з ладу. Тестуйте запис/читання, переформатуйте, спробуйте інший порт (особливо USB 3 на передній панелі старих плат).
• Якщо проблему не вдається відтворити на іншій флешці — замініть її і не сперечайтеся з фізикою.

Передумови та перевірки безпеки (не затирайте не той диск)

Ви збираєтеся виконати команди, які можуть миттєво стерти диски. Єдина надійна страховка — ваша власна дисципліна.
Якщо ви на ноутбуці з підключеним зовнішнім USB SSD і «очищаєте» не той диск, ви дізнаєтесь нові емоції.

Що потрібно

• Windows 10/11 або Windows Server з PowerShell та правами адміністратора.
• USB-носій (мінімум 8 GB; 16+ GB комфортніше).
• Windows ISO-файл, доступний локально.

Завдання 1: Ідентифікувати диски і підтвердити USB за розміром та шиною

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

Що це означає: Диск 1 — USB, 16 GB, зараз RAW (немає таблиці розділів).

Рішення: Диск 1 — цільовий. Якщо ваш USB відображається інакше (наприклад «SATA»), зупиніться і розберіться — деякі док-станції брешуть.

Завдання 2: Перевірка томів (щоб уникнути стирання неправильного)

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

Що це означає: У вашого USB може навіть не бути літери диска, і це нормально.

Рішення: Якщо USB вже має літеру та містить щось важливе — скопіюйте це зараз. Ми його видалимо.

Завдання 3: Підтвердити наявність ISO і що це не часткове завантаження

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

Що це означає: ISO існує і має ~6.6 GB.

Рішення: Якщо розмір підозріло малий (наприклад кілька MB), зупиніться — ваш ISO не справжній.

Метод: Windows ISO → завантажувальний USB (дружній до UEFI)

Є два базових способи зробити завантажувальний USB:

1. Метод копіювання файлів: розбити на розділи + відформатувати USB, змонтувати ISO, скопіювати файли. Саме це ми робитимемо.
2. Запис сирого образу: записати образ біт у біт. Windows ISO зазвичай не призначені для сирого запису на USB так, як часто роблять з Linux ISO.

Для інсталяційних носіїв Windows метод копіювання файлів передбачуваний і керований. Він також полегшує роботу з лімітом 4 GB.

Завдання 4: Очистити й ініціалізувати USB як GPT (UEFI‑перший)

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

Що це означає: Диск 1 тепер GPT.

Рішення: Якщо USB має завантажуватися на старих BIOS‑тільки машинах, розгляньте MBR замість GPT. Для більшості сучасних парків GPT — правильний вибір за замовчуванням.

Завдання 5: Створити один FAT32-розділ і призначити літеру диска

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

Що це означає: USB тепер диск F: відформатований FAT32.

Рішення: Запам’ятайте літеру диска. Ми скопіюємо вміст ISO туди.

Завдання 6: Змонтувати ISO і знайти його літеру диска

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

Що це означає: ISO змонтовано як D: (UDF-файлова система, як і очікується для оптичних образів).

Рішення: Копіюємо з D:\ до F:\.

Завдання 7: Перевірити ISO на наявність UEFI-файлів перед копіюванням

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

Що це означає: ISO містить завантажувач UEFI для знімних носіїв.

Рішення: Добрий знак. Якщо D:\EFI\BOOT\BOOTX64.EFI відсутній, ISO може не бути UEFI‑завантажувальним у поточному вигляді.

Завдання 8: Перевірити «часову бомбу» FAT32 (розмір install.wim)

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

Що це означає: install.wim ≈ 4.8 GB. FAT32 не може зберігати файл більший за 4 GB.

Рішення: Не копіюйте ISO бездумно. Використайте метод розбиття WIM, описаний нижче.

Завдання 9: Скопіювати все, окрім install.wim, а потім розбити WIM на SWM частини

Чистий підхід: скопіюйте всі файли, пропустивши великий WIM, а потім використайте DISM, щоб розбити його на кілька .swm файлів,
які кожен вміщуються в межах 4 GB. Windows Setup автоматично розпізнає install.swm.

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 PM

Що це означає: Один файл пропущено: install.wim. Це зроблено навмисно.

Рішення: Тепер згенеруйте частини install.swm на 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.

Що це означає: DISM розбив WIM на частини: install.swm, install2.swm тощо.

Рішення: Підтвердіть, що файли існують і кожен менший за 4 GB.

Завдання 10: Перевірити SWM-файли і видалити випадкову копію 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

Що це означає: SWM-частини існують і вкладаються в ліміт FAT32.

Рішення: Переконайтеся, що F:\sources\install.wim не існує. Setup має бачити лише SWM‑частини.

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

Завдання 11: Акуратно відмонтувати ISO

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

Що це означає: ISO більше не змонтовано.

Рішення: Безпечно вийміть USB, коли будете готові, але спочатку перевірте файли завантаження та структуру.

Жарт №2: Завантажувальний USB — це просто маленький диск з великими очікуваннями, трохи як моя перша ніч на чергуванні.

Обробка install.wim більше 4 GB (реальність FAT32)

Максимальний розмір одного файлу в FAT32 — 4 GiB мінус 1 байт. Це не обговорюється. Ви не можете «примусити» це працювати.
Якщо спробуєте, отримаєте помилку копіювання або, гірше, інструмент скаже, що все пройшло успішно, але файл було пропущено.
Обидва варіанти призведуть до USB, який завантажується, але падає пізніше, коли Setup потребуватиме образу.

Опція A (рекомендовано): Розбити WIM на SWM

Саме те, що ми зробили вище. Це зберігає сумісність з UEFI і робить USB простим: один розділ, одна файлова система, один набір очікувань.
Це також робить процес аудитуємим — DISM показує, що він зробив.

Опція B: Два розділи (FAT32 для завантаження + NTFS для payload)

Іноді ви розповсюджуєте кастомізований образ і розбиття неприйнятне. Поширена схема:
FAT32-розділ із \EFI і файлами завантаження, плюс NTFS-розділ із великим WIM.
Це може працювати, але підвищує варіативність прошивок і людські помилки. Декілька систем бачать тільки перший розділ на знімних носіях.
Деякі меню завантаження плутаються. Дехто копіює не туди.

Якщо все ж робите так, тримайте FAT32-розділ першим і маленьким (наприклад 1–2 GB) та перевіряйте, чи цільове обладнання бачить обидва розділи.
Для Windows Setup потрібно, щоб під час роботи WinPE було доступно NTFS. Більшість сучасних WinPE builds це підтримують, але «більшість» — не те саме, що процедура зміни контролю.

Опція C: Конвертувати WIM у ESD (іноді)

Конвертація WIM у ESD може зменшити розмір, але це не завжди підходить для корпоративного іміджінгу.
Це також може вплинути на сценарії сервісінгу. Якщо ви не знаєте, навіщо вам ESD — навряд чи варто його використовувати.

Нотатки для Legacy BIOS (коли ви застрягли в 2009)

Завантаження з USB у Legacy BIOS — інша історія: воно очікує завантажувальні сектори і часто віддає перевагу MBR.
Деякі Windows ISO включають підтримку BIOS-завантаження; деяким платформам потрібен макет типу «USB‑HDD».

Якщо потрібно підтримувати лише BIOS-обладнання, розгляньте ініціалізацію USB як MBR замість GPT. Проте багато середовищ «підтримують BIOS»
у політиці, тоді як реальне обладнання вже UEFI останнє десятиліття. Перевірте перед тим, як проектувати для тіней.

Завдання 12: Ініціалізувати USB як MBR (альтернатива для 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

Що це означає: USB тепер використовує MBR.

Рішення: Робіть це тільки якщо дійсно потрібне BIOS-завантаження. Інакше дотримуйтеся GPT для UEFI‑перших парків.

Для BIOS-завантаження прапорець «active» іноді має значення. PowerShell storage cmdlets не завжди відкривають усі BIOS‑ера прапорці чисто.
Для сумісності з лінійкою Legacy іноді diskpart — найменш поганий інструмент. Якщо ваша вимога справді «лише PowerShell»,
ви все одно можете викликати diskpart з PowerShell. Це не GUI-інструмент; це просто гострий ніж.

Завдання перевірки (доведіть, що воно завантажиться)

Інстинкт SRE: не довіряйте повідомленням про успіх. Міряйте. Перевіряйте. Збирайте докази, які можна додати до тикета, коли хтось скаже
«USB, який ви зробили, не працює», а сам запускає завантаження з мережі.

Завдання 13: Підтвердити файлову систему та вільне місце на 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

Що це означає: FAT32, стан Healthy, достатньо вільного місця.

Рішення: Якщо це exFAT або NTFS, а ви очікуєте UEFI‑завантаження всюди — виправте це зараз, замість сперечатися з прошивкою пізніше.

Завдання 14: Перевірити шлях завантаження знімного носія на USB

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

Що це означає: Ключовий UEFI-файл завантаження існує.

Рішення: Якщо False, ваше копіювання не включило EFI-файли (або ви змонтували не той ISO). Перекопіюйте й перевірте знову.

Завдання 15: Перевірити, що каталог \sources має те, що потрібно Setup

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

Що це означає: boot.wim існує і присутні SWM-частини.

Рішення: Якщо boot.wim відсутній, USB може завантажитися в нікуди або впасти рано.

Завдання 16: Підтвердити читабельність USB повністю (швидка перевірка хешем)

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

Що це означає: Файл читається і доступний для хешування; немає негайних помилок вводу/виводу.

Рішення: Якщо хешування видає помилки, USB може виходити з ладу. Замініть носій замість пошуку привидів.

Завдання 17: Підтвердити розклад розділів

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

Що це означає: Один розділ даних на GPT (basic data).

Рішення: Для знімного UEFI-завантаження критично FAT32 + шлях EFI. Тип розділу менш важливий за вміст,
але дивні макети можуть збивати стару прошивку.

Завдання 18: Швидка оцінка розміру директорії (ви справді скопіювали більшість ISO?)

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

Що це означає: Загальна кількість байтів на USB — правдоподібне багатогігабайтне значення.

Рішення: Якщо значення маленьке (кілька сотень MB) — ви некоректно копіювали або занадто багато пропустили.

Одна цитата з операцій (парафраз)

парафразована ідея — Gene Kranz: «Бути жорстким і компетентним» краще за паніку; в операціях дисципліна перемагає, коли системи шалено поводяться.

Три корпоративні міні-історії (реальні випадки)

Інцидент: хибне припущення про NTFS і UEFI

Середнє підприємство мало стандартний процес створення «Windows recovery USB», який підтримувала служба підтримки десктопів. Він працював на їхніх нових ноутбуках,
тож всі вирішили, що проблема вирішена. Потім партія стійків серверів потребувала екстреного перевстановлення ОС після проблем із прошивкою контролера сховища.
Команда віддаленого обслуговування приїхала з USB. Сервери залишилися байдужими.

Припущення було простим: «UEFI може завантажуватися з NTFS, бо на наших ноутбуках це працює».
Це випадково було правдою на тому ноутбуці, бо його виробник додав NTFS-драйвери у прошивку.
Сервери таких драйверів не мали. Немає підтримки NTFS — немає завантаження.

Команда пробувала вимикати/увімкнути Secure Boot, змінювати порти і міняти флешки. Нічого не допомагало. USB з’являвся в меню завантаження, але завантаження падало миттєво.
Хтось запропонував «можливо, ISO пошкоджений», що було комфортною історією, бо не звинувачувало жоден проєктний вибір.

Виправлення було нудно простим: створити USB як FAT32 і розбити WIM. Після цього сервери завантажилися з першої спроби.
Результат: не тільки відновлення систем. Вони оновили внутрішній рукопис до опису FAT32 для UEFI знімних носіїв і кроком валідації наявності \EFI\BOOT\BOOTX64.EFI.

Урок після інциденту: успіх на одному класі апаратури не є доказом. Прошивка — це платформа. Поводьтеся з нею відповідно.

Оптимізація, що дала зворотний ефект: «зробимо швидше» з агресивним копіюванням

Інша команда хотіла пришвидшити створення інсталяційних USB для проєкту міграції. Хтось вирішив використати паралельні копії
і коротку політику повторних спроб, щоб «швидко виходити при помилці». Скрипт використовував фонові завдання для копіювання декількох каталогів одночасно,
і вважав операцію успішною, якщо завдання не кидали фатальних помилок.

Було швидко. І водночас хибно в тонкий спосіб: періодичні транзитні помилки читання на дешевих USB приводили до пропуску кількох файлів,
але завдання завершувалися. Скрипт не перевіряв кількість файлів чи критичні шляхи. USB завантажувався, запускав Windows Setup, а потім падав під час інсталяції
з помилками про відсутні компоненти, що виглядало як випадкова невдача WinPE.

Найгірше: це траплялося рідко. Значить, воно пройшло тестування і з’явилося як «поле невдач».
Нічого так не руйнує графік впровадження, як періодичні дефекти носія, що виглядають як баги ОС.

Виправлення: припинити оптимізувати не ту річ. Повернулися до одного robocopy з явним логуванням,
плюс набір обов’язкових перевірок: наявність файлів завантаження, наявність boot.wim та перевірка успішності розбиття SWM.
Загальний час трохи збільшився. Рівень помилок впав майже до нуля.

Урок: оптимізація продуктивності без перевірок правильності — це просто швидший шлях до помилок.

Нудна, але правильна практика, що врятувала: маркування і детермінований вибір диска

В регульованому середовищі команда інфраструктури підтримувала скриптовий процес створення USB для відновлення bare‑metal.
Скрипт робив одну непоказну річ дуже добре: він ніколи не вибирав цільовий диск як «диск, що виглядає як USB».
Він вимагав від оператора підтвердити номер диска і маркував USB відомою міткою тому.

Одного дня інженер запустив скрипт на робочій станції з підключеним USB‑to‑SATA адаптером.
Windows повідомив про пристрій як знімний-подібний, і його розмір був близьким до розміру цілі.
У поганий день так можна стерти зовнішній бекап і провести вихідні, вибачаючись.

Але скрипт вимагав дві підтвердження: спочатку він виводив список дисків, потім просив набрати точний номер диска,
і нарешті перевіряв, що щойно відформатований том має очікувану мітку перед копіюванням файлів.
Інженер помітив невідповідність мітки на другому кроці і зупинився.

Пізніше, коли та сама команда швидко відбудовувала носії під час аварії, цей детермінований процес дозволив будь‑кому на виклику
зробити роботу без «племінних знань». Також він створював логи, що задовольняли вимоги аудиту без драм.

Урок: нудні запобіжники потрібні о 2‑й ночі. Вони не дають відчуття розумності — і саме в цьому їхня сутність.

Поширені помилки: симптом → причина → виправлення

1) USB видно в меню завантаження, але одразу повертає до BIOS/UEFI

Причина: Відсутній або неправильно розташований UEFI-файл завантаження (\EFI\BOOT\BOOTX64.EFI), або неправильна файлова система (exFAT/NTFS на прошивці, що читає лише FAT).

Виправлення: Відформатуйте FAT32, перекопіюйте вміст ISO, перевірте, що Test-Path F:\EFI\BOOT\BOOTX64.EFI повертає True.

2) Завантаження починається, Windows Setup завантажується, а потім інсталяція падає через відсутні файли

Причина: install.wim не скопійований на FAT32 через ліміт 4 GB або був пропущений під час копіювання.

Виправлення: Розбийте WIM на SWM за допомогою DISM; підтвердьте наявність SWM-файлів і відсутність install.wim на FAT32.

3) Операція копіювання «успішна», але вміст USB надто малий

Причина: Копіювали не з того джерела (не з змонтованого ISO), або robocopy виключив каталоги, або права приховали помилки.

Виправлення: Перезмонтуйте ISO, перевірте літеру джерела, перезапустіть robocopy без надмірних фільтрів і проведіть саніті‑перевірку загальної кількості байтів.

4) USB завантажується на ноутбуках, але не на серверах

Причина: Особливості прошивки конкретного вендора (підтримка NTFS, інша поведінка щодо знімних носіїв, ініціалізація портів USB).

Виправлення: Використовуйте FAT32 шлях UEFI, віддавайте перевагу заднім портам материнської плати і перевіряйте на цільовому класі обладнання — не на найближчому ноутбуці.

5) Secure Boot блокує завантаження політикою

Причина: Непідписаний або змінений завантажувач, або неофіційний носій у суворому Secure Boot середовищі.

Виправлення: Використовуйте офіційні інсталяційні носії або зареєструйте потрібні ключі; не вимикайте Secure Boot, якщо політика це забороняє.

6) USB періодично зникає або виникають помилки I/O під час копіювання

Причина: Несправний USB-носій, ненадійний порт/хаб або проблеми з живленням на фронтальних портах.

Виправлення: Спробуйте іншу флешку і порт; якщо хешування файлів дає помилки — замініть обладнання замість марного дебагу.

7) UEFI завантажується, але клавіатура/мишка не працюють у WinPE

Причина: USB-пристрій вводу не ініціалізований правильно (певні налаштування прошивки, xHCI handoff), або у WinPE відсутні драйвери для певного обладнання.

Виправлення: Використовуйте інші порти (USB 2, якщо є), змініть налаштування прошивки USB або використайте оновлене інсталяційне медіа з ширшою підтримкою драйверів.

8) «Доступ заборонено» при форматуванні або призначенні літери

Причина: PowerShell не запущено з піднятими правами або якийсь процес тримає том відкритим.

Виправлення: Запустіть PowerShell як Адміністратор; закрийте вікна Explorer; при потребі повторіть перевірку Get-Process.

Контрольні списки / покроковий план

Контрольний список A: UEFI‑перший інсталятор Windows на USB (один FAT32-розділ)

1. Ідентифікуйте цільовий диск: Get-Disk і підтвердіть за BusType=USB та розміром.
2. Очистіть і ініціалізуйте як GPT: Clear-Disk, Initialize-Disk -PartitionStyle GPT.
3. Створіть розділ + відформатуйте FAT32 + дайте мітку: New-Partition, Format-Volume -FileSystem FAT32.
4. Змонтируйте ISO: Mount-DiskImage; зафіксуйте літеру ISO.
5. Перевірте розмір install.wim; якщо > 4 GB — плануйте розбиття.
6. Скопіюйте вміст ISO, пропустивши install.wim, за допомогою robocopy.
7. Розбийте WIM на SWM за допомогою DISM у F:\sources.
8. Перевірте: існування \EFI\BOOT\BOOTX64.EFI; наявність boot.wim; присутність SWM-файлів; файлова система FAT32.
9. Відмонтуйте ISO; вийміть USB.

Контрольний список B: Мінімальна перевірка перед передачею USB комусь іншому

1. Шлях завантаження: Test-Path F:\EFI\BOOT\BOOTX64.EFI має повернути True.
2. WinPE: Test-Path F:\sources\boot.wim має повернути True.
3. Інсталяційний payload: або існує install.esd, або існують install.swm (і нічого не відсутнє).
4. Файлова система: Get-Volume показує FAT32.
5. Цілісність копії: проведіть хоча б одне Get-FileHash для кількох ключових файлів, щоб упевнитися в стабільності читання.

Контрольний список C: Якщо ви автоматизуєте це в скрипті

• Вимагайте явний ввід номера диска; ніколи не вибирайте автоматично.
• Пишіть логи: вибір диска, стиль розділів, мітка тому, підсумок robocopy, вивід DISM.
• Жорстко провалюйтеся, якщо після копіювання відсутні обов’язкові шляхи.
• Робіть скрипт ідемпотентним, де можливо (очистіть диск і створіть ту саму структуру щоразу).

Поширені питання

1) Чи можна створити завантажувальний Windows USB, просто скопіювавши файл ISO на диск?

Ні. Прошивка не завантажує ISO-файл, що лежить на файловій системі (не в загальному випадку). Вона завантажує завантажувач з файлової системи або з завантажувального сектора.
Потрібно змонтувати ISO і скопіювати його вміст (або правильно записати диск образом з потрібною структурою завантаження).

2) Чому FAT32? Це здається древнім.

Бо прошивка може його читати. Реалізації UEFI зобов’язані підтримувати FAT. Підтримка NTFS опціональна і непослідовна.
FAT32 — нудний формат, що працює, коли треба мати справу з випадковими серверними платами у невдалий час.

3) Що робити, якщо в моєму ISO є install.esd замість install.wim?

Чудово. ESD часто менший за розміром, тож зазвичай вміщується на FAT32 без розбиття.
Все одно перевіряйте розмір: Get-Item D:\sources\install.esd.

4) Чи потрібен GPT для USB?

Для UEFI завантаження GPT — добрий вибір за замовчуванням. Деякі прошивки можуть завантажувати UEFI і з MBR.
Якщо ви таргетуєте legacy BIOS — MBR часто безпечніший. Якщо орієнтуєтесь на сучасні сервери — GPT забезпечує узгодженість.

5) Чому не просто використовувати diskpart замість PowerShell cmdlet-ів?

Ви можете викликати diskpart з PowerShell і іноді це прагматичне рішення для крайніх випадків.
Але PowerShell cmdlet-и краще скриптуються, простіші для виявлення і загалом легше перевіряти структурованим виводом.

6) USB — FAT32, файли завантаження є, але він все ще не завантажується. Що далі?

Перевірте вибір режиму завантаження (UEFI vs legacy), політику Secure Boot і спробуйте інший порт.
Потім підозрюйте сам носій. Якщо проблема проявляється лише на одній моделі апаратури — дивіться в бік прошивки чи відсутності підтримки багатороздільних носіїв.

7) Чи можу я створити завантажувальний USB для дистрибутивів Linux тим самим методом?

Іноді так, але багато Linux ISO розроблені як hybrid-образи, які краще записувати сирим способом.
Ця стаття зосереджена на Windows інсталяційних носіях. Копіювання файлів працює, коли структура ISO це передбачає; сирий запис працює, коли ISO побудований для цього.

8) Як зрозуміти, чи моя невдача — «USB не завантажувальний» чи «проблема інсталятора»?

Якщо ви ніколи не доходите до інтерфейсу інсталятора — зазвичай це шлях завантаження/файлова система/режим прошивки.
Якщо ви доходите до Setup і програма падає пізніше (копіювання файлів, вибір редакції, застосування образу) — часто це відсутні чи пошкоджені payload-файли (WIM/SWM/ESD).

9) Чи можна зробити це без прав Адміністратора?

Надійно — ні. Форматування дисків і монтування образів зазвичай вимагають підвищених прав.
Якщо ви в закритому середовищі, працюйте з тим, хто контролює привілеї кінцевої точки — не вирішуйте це сумнівними інструментами.

10) Чи варто відключати «quick format» для безпеки?

Quick format підходить у більшості випадків. Він не тестує всю поверхню.
Якщо підозрюєте несправність носія — замініть USB або проведіть ґрунтовніші перевірки; не приймайте формат як інструмент валідації апаратури.

Висновок: наступні кроки, які можна виконати

Якщо запам’ятаєте лише три речі, нехай це будуть: свідомо вибирайте правильний диск, використовуйте FAT32 для сумісності з UEFI і вирішуйте проблему файлу 4 GB
шляхом розбиття WIM, а не надіями.

Наступні кроки:

1. Перетворіть фінальну послідовність команд у скрипт з явним підтвердженням диска і пост‑копійнними перевірками.
2. Тестуйте на тому класі апаратури, на якому будете інсталювати (прошивка серверів — не ноутбук).
3. Майте одну відому‑добру флешку в підписаному пакеті і поводьтеся з нею як з інструментом інцидентів — бо саме так воно і є.

Мета не в тому, щоб почуватися розумним. Мета — завантажитися з першої спроби, коли система вже в вогні.