Полезные ссылки на тему сборки образа wim

Сборка и установка собственного образа завершилась безусловной победой ;)

Задача оказалась существенно более трудоёмкой чем казалась изначально из-за ряда причин, довольно объективного характера:

(1) особенностей загрузки драйверов в WinPE (сама по себе технология довольно простая, пока всё идёт гладко. Как только что-то идёт плохо - то стразу ступенька в сложности)

(2) неочевидного взаимодействия между компонентами и устаревания части информации (соответственно в сети куча статей и мануалов, но часть из которых устарела, часть из которых не описывает серьёзные грабли встречающиеся на пути)

(3) сложностью отладки (разные журналы). Да и пожалуй сложностью и непривычностью самих технологий.

Подробнее постараюсь написать на неделе.

Пока оставлю несколько полезных ссылок, которые сильно помогли разобраться в ворохе проблем

DISM Overview

Windows PE (WinPE) 

    WinPE Optional Components (OC) Reference 

Загрузка сетевого драйвера и инициализация сети в среде WinPE

Download and install the Windows ADK 

Windows PE startup sequence explained

Для получения старых версий ADK: https://github.com/p0w3rsh3ll/ADK/tree/master

Не помогли статьи вроде: Настройка PXE-сервера для загрузки Windows PE  

 

Ещё одна ссылка, которую нашёл, но не хватило времени посмотреть, но которая, вероятно, позволила бы сэкономить какое-то количество времени HydrationKitWS2025 .

Увеличение диска qemu/kvm

В virt-manager пока функционала нет.

Решается командой: 

qemu-img resize vmdisk.img +10G

src 

Нормально работает в том числе с qcow2.

How to run Windows Installer in Safe Mode in Windows 10 and 11

Любопытный трюк от Касперского, позволяющий запускать Windows Installer в безопасном режиме.

• If Windows runs in Safe Mode with Networking:
• REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer" /VE /T REG_SZ /F /D "Service"
• If Windows runs in Safe Mode without Networking:
• REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /VE /T REG_SZ /F /D "Service"

Run Windows Installer in one of the following ways:

• Run the command below and press Enter:
• net start msiserver

https://support.kaspersky.com/common/windows/15941 

libvirt + WinServer 2025 = black screen при загрузке

Наткнулся на добротные грабли. Возможно, эта заметка позволит кому-то сэкономить время, возможно много ;)

Развёрнуто небольшое тестовое окружение. 

• Есть физический ПК под управлением debian 12. 
• Установлены libvirt (qemu/kvm) + virt-manager. 
• Создано несколько виртуальных машин (ВМ) под управлением windows server 2025 (dc, rdc). 
• В ВМ установлены необходимые пакеты для работы с libvirt.

 Далее. Добавляется новая машина windows server 2025. 

Машина присоединяется в домен, для работы с хостовыми шарами на неё накатываются WinFsp и добавляется файловая система firtiofs, пример: Shared-file-system.

Всё работает ок.

После ребута получаем чёрный экран при попытке загрузки windows. Система грузится, но в момент переключения видеорежима получаем чёрный экран.

До перезагрузки всё работает ок. 

• После перезагрузки - чёрный экран и потребление на 100% одного ядра. Система не загружается. 
• В режим восстановления зайти можно. 
• При этом последняя удачная конфигурация не загружается 
• Ручная остановка службы virtio-fs service к успеху не привела 
• Попытка переименовать папки WinFsp и Virtio-Win (чтобы не загружались расположенные там драйвера) тоже оказалась безуспешной.

 Не буду подробно описывать все свои злоключения. 

• ОС на ВМ была переустановлена несколько раз. При этом сама ВМ, конечно создавалась заново.
• Вдумчивое чтение журналов системы не позволило приблизиться к решению ни на йоту.
  
• На каком-то этапе перестал устанавливать WinFsp - не помогло. Проблема оказалась не в WinFsp.
• Были проведены эксперименты с использованием разных типов дисков.
• Много проверок и попыток поиграть с видеокартами.
• Чтобы локализовать ошибку собиралась минимальная живая конфигурация - всё потенциально "лишнее" и не обязательное оборудование удалялось.
• На каком-то этапе играл с процессором системы. Моментально получил полностью нерабочую систему.
  
• Что интересно, в режиме восстановления всё работало ок.
• Разные режимы аварийной загрузки, попытки сбора логов - всё впустую.  
  

Признаться, здравые идеи закончились, нейронки пасовали или давали "странные" рекомендации, всё что можно было выгрести свежее и не очень свежее из гугла было испробовано.

Времени было потрачено - страшно сказать вслух.

 

Очередные два часа гуглежа помогли вытащить золотую рыбку.

https://hartiga.de/windows-server/windows-server-2025-on-ugreen-nas/ 

Replace that block with the following “Stable” configuration:XML<cpu mode='custom' match='exact' check='none'> <model fallback='allow'>Skylake-Client-IBRS</model> <topology sockets='1' dies='1' cores='6' threads='1'/> </cpu> (Note: Ensure cores='6' matches your actual assigned core count!)

Skylake-Client-IBRS is a “safe harbor” CPU model in the virtualization world. It includes modern instruction sets required by Windows Server 2025 but abstracts away the specific quirks of the physical NAS processor. It also includes IBRS (Indirect Branch Restricted Speculation), which is critical for security mitigations (Spectre/Meltdown) that Windows expects to see present.

Бинго!

• Почему и откуда прилетели такие грабли - совершенно непонятно. Но выглядят они так.
• Почему баг прилетал после нескольких успешных загрузок - непонятно.
• Почему при этом работают другие WinServer (dc, rdc) - тоже непонятно.

Хостовый CPU: Intel(R) Core(TM) i7-14700KF

В качестве очевидного после этой ошибки вывода: вслепую использовать host-passthrough не очень хорошая идея.

Внятных  рекомендаций на тему у самого разработчика для себя найти не смог https://www.qemu.org/docs/master/system/i386/cpu.html Единственное полезное, что смог извлечь - конфигурацию Skylake-Server-IBRS с ней сервер тоже вполне себе заработал.

Удачи в правильном выборе железа для ВМ ;)

PS В боевом окружении, конечно лучше десять раз подумать о выборе типа процессора, т.к. например поломанная живая миграция - это больно.

[problem][solved][printer]Установка HP LaserJet Pro P1102w

Недавно имел интереснейшее приключение с установкой принтера HP LaserJet Pro P1102w (http://www8.hp.com/ru/ru/products/printers/product-detail.html?oid=5149432) на ПК с Win 7. На какие-то машины принтер вставал без проблем, но на одну отказывался устанавливаться наотрез. Драйвера до определённого момента корректно ставились, но на этапе определения принтера, ОС (Windows 7) увидеть подключенное устройство не могла.

Изначально предполагался конфликт ПО, но удаление различного ранее установленного софта и драйверов МФУ и принтеров от HP и отключение антивируса к успеху не привело. Альтернативная версия - не очень понятная, скорее всего аппаратная, проблема с USB.

Разобраться в проблеме помогло воспроизведение ошибки на другой машине с Windows 7.
Установка завершалась диалоговым окном:


В логе системы появилась ошибка:
"Служба "HP SI Service" помечена как интерактивная.  Однако в конфигурации системы интерактивные службы не допускаются.  Возможна неправильная работа службы."
Код события: 7030.

Виновником оказалась "служба" "HP Smart Install". Варианта видится два: либо "служба" некорректно работает на некоторых ПК с Windows 7, либо конфликтовала с KAV (даже отключенным).
Для обхода проблемы надо распаковать exe с драйвером и запустить UTIL\SIUtility.exe (SIUtility64.exe). Этот инструмент позволяет включать и отключать HP Smart Install для ПК или принтера.



После отключения HP Smart Instal для ПК, принтер моментально определился и драйвера автоматически встали.

[problem][solved][mfp] Kyocera + Сетевое сканирование = "Не удалось выполнить подключение"

История. Есть несколько пользователей разных МФУ Kyocera. В течении длительного времени МФУ-хи работали без малейших замечаний. В какой-то определённый момент у пользователей поломалась сканирование. Проблема возникала на разных МФУ, у разных пользователей, в разное время.

Симптомы. При запуске сканирования из приложения через стандартный диалог сканирования Kyocera, МФУ начинало сканировать листы и после запоздания в 3-5 секунд, появлялось диалоговое окошко с текстом: "Не удалось выполнить подключение". При повторном запуске сканирования окошко менялось на: "Сканер уже используется".

В поисках решения.
Коллега перерыл тьму типовых решений: перезапуск служб (WIA, сервер и т.д.), добавлял-удалял сканер, переустанавливал драйвера, весь комплект ПО Kyocera, ПО сканирования, запускал приложения с правами админа и т.д. - результат нулевой.
Поиск в интернете показал, что проблема встречается регулярно, но ответа или предположений о причинах не было (имхо, приз за самый бестолковый ответ получает это сообщение http://kyocera-products.ru/casetracker/ne-udalos-vypolnit-podklyuchenie-so-skanerom-fs-1135-mfp).

Диагностика и решение.
Проверка показала, что:
* ошибка воспроизводится при сканировании любым клиентским приложением (стандартное windows -Факсы и сканирование, FineReader, встроенный тул от Kyocera).
* ошибка воспроизводится под любым пользователем ПК.
При этом повторюсь, в это же время с других компов сканирование происходит без намёков на проблемы.
Очевидно, что проблема была на конкретном компьютере.

В поисках решения позапускал netstat перед сканированием, в начале сканирования и в процессе сканирования (тут подошёл бы любой другой инструмент для отслеживания сетевых соединений).
Собственно, в начале сканирования появлялось соединение, которое практически сразу разрывалось.

  TCP    <client ip>:51089   <mfp ip>:9090     ESTABLISHED

Оставалось обнаружить причину такого поведения. 

После ещё нескольких экспериментов удалось локализовать виновника - им оказался антивирь.

Пакостными здесь являются несколько моментов:

* Поведение антивируса непредсказуемо. Другие машины в аналогичной конфигурации продолжают спокойно работать. Причины заставившие антивирь блокировать соединения остались неизвестными.

* У антивируса есть возможность временно отключить работу, но даже в этом случае, соединение продолжает блокироваться (что сильно не соответствует ожидаемому поведению).

* Ошибка исчезла только после удаления антивиря. После его обратной установки сканер работал в штатном режиме.

Проверенным решением является переустановка антивируса. 

Не проверено. Возможным (но потенциально опасным) решением является добавлением софта для сканирования и киосеровского софта (как минимум Program Files\Kyocera\WIA Scanner\Boxless) в пути исключения антивируса.

Firefox. Manually uninstalling a plugin

Официальные рекомендации по ручному удалению плагинов в фаерфоксе (на случай если отсутствует штатная процедура удаления):
http://support.mozilla.org/en-US/kb/troubleshoot-issues-with-plugins-fix-problems#w_manually-uninstalling-a-plugin