Я фанател от MDT. Потом его не стало — и я написал свой

[exchange12rocks]

Интересно, спасибо.

А https://github.com/google/glazier и https://github.com/FriendsOfMDT/PSD не рассматривали?

[Syrinox]

FriendsOfMDT были одними из первых вариантов, которые я рассматривал, но так же быстро и отсеялись. Причина до смешного простая: им всё ещё нужен сам MDT.

А в статье я как раз и описывал основную причину, почему вообще полез искать альтернативу: нормальной официальной возможности скачать MDT уже по сути нет. Да, можно найти его там, тут, сям, но тащить такое в прод через сторонние источники мне показалось рискованным. Ну и, если честно, уже хотелось чего-то нового.

Это примерно как когда старый телефон начинает глючить: можно взять следующую модель почти такую же, но почему-то специально хочется совсем другую, в надежде, что там-то уж точно всё будет иначе. Классическая «трава у соседей зеленее» ;)

При этом уже после того, как решил писать своё, некоторые идеи и подходы FriendsOfMDT я всё-таки подсматривал и местами использовал как вдохновение.

А вот Glazier. До вашего комментария вообще о нём не слышал. Выглядит интересно, теперь хочется нормально покопаться в нём. Как говорится, очередная причина возгорания токенов Claude и GPT :0 на вечерок по баночку энергосика

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

[321785]

Мне кажется или вы всё таки, пусть и не осознанно, но пытаетесь повторить SCCM?

[Syrinox]

Не скажу, что знаю SCCM вдоль и поперёк. Впрочем, я и MDT за три года, наверное, не до конца изучил :)

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

Поэтому IronDeploy я бы скорее назвал сильно упрощённым самостоятельным аналогом MDT, чем попыткой повторить SCCM. После деплоя компьютер меня уже практически не интересует: максимум SetupComplete / post-install, финальный отчёт, и на этом всё.

Впрочем, будет враньём сказать, что у меня периодически не возникают техно-фантазии разрастить проект настолько, насколько хватит меня самого и интереса пользователей :) Но скорее хочется не напихать туда всё подряд, а дать возможность подстраивать IronDeploy под реальные сценарии тех, кто им пользуется, особенно там, где в MDT чего-то не хватало.

[orki]

образ стареет. Его надо пересобирать при обновлении Windows, при новом поколении железа, при смене набора софта. Sysprep капризничает. Золотой образ превращается в отдельный объект, который сам требует обслуживания.

Я уже не настоящий сварщик, но когда рулил AD с тысячей машинок, нарочно переводил рельсы деплоя на fog, образ собирался через CI/CD и обмазывался тестами.

И образы аккумулировались и переиспользовались - тестировщикам в геймдеве требовались самые разные версии ос.

Скорость деплоя и свободные руки админов были намного важнее удобства mdt.

[Syrinox]

Забавно, что мой прошлый руководитель поручивший мне эти задачи с wds/mdt тоже постоянно шутил про "так я ж не настоящий сварщик" из одного анекдота ;) Улыбнуло если честно

А по сути вопроса, на самом деле интересно
1. как проводились тесты, это был агент на тачке вшитый в образ и отдающий данные в какой-то сервак? ну т.е... как это вообще происходило на каком уровне, от куда куда текли данные
2. сколько вообще обычно занимало времени на раскрутку windows 10/11 к примеру от Начала до того как начнётся подтягивание политик с домена (т.е где по сути своей ни сколько зона деплоя, сколько доменная) ?

3. На самом деле я серьёзно задумался о поддержке двух вариаций в моём проекте... надо потестировать насколько быстрее вообще будут ставятся образы с того же fog и имеет ли это смысл как таковой...

Мне просто нравится, что на любой случай большинство вещей просто подтягиваются на горячую по SMB т.е в любой момент можно загрузить новую винду и не пересобирать, она уже будет работать потому-что install.wim уже ожидаемо примется командами если конечно не поменялась архитектура самого .wim

или софт - он поставится и не обязательно пересобирать образ
так-же и драйвера

Но опять же наверное зависит от того насколько fog шустрее это применяет

лок’тар огар!

[orki]

Пайплайн у меня был на гитлабе, но это не важно, хоть через make собирать,
1. packer поднимал виртуалку на qemu со образом винды с msdn, ставил винду и запускал, грубо, два скрипта - install_soft.ps1 и sysprep.ps1 с последующим выключением виртуалки.
Тут миллион нюансов, вроде установки fog клиента и отключения его сервиса (потом уже, на этапе установки из образа включаем сервис).
2. подготовка образа. у меня гитлаб-раннеры на линуксе, то готовый образ диска в формате qcow2 паковал в win10-version.wim через wimlib-imagex
3. тест образа, через packer поднимаем другую виртуалку со свежеиспеченным образом и гоняем тесты, для начала - машинка должна ответить через winrm, потом установленный софт
4. если тест успешен, заливаем образ на fog

На физическую машину заливаем образ через pxe.
Все драйвера ставим только при финальном деплое на физическую машину.
Мажорно обновился софт или винда - образы пересобираются.
fog в данном случае всего лишь удобный гуй для менеджмента хостов.

у меня было желание добавить еще один тест - на физической машине, которую будили через wake on lan, но руки не дошли автоматизировать очистку после тестового деплоя.

Ставить софт пользователю скриптами выходило от 20 минут до часа, образы этот гап убрали. Правда, у некоторого софта невозможно было автоматизировать использование лицензий, а пираток его не существовало...

На первый драфт ушла неделя, еще пару месяцев доводилось до ума в процессе.

[MrBotikkk]

Его нельзя официально скачать. Нет, серьёзно — попробуйте.

chocolatey Microsoft Deployment Toolkit Build 8456 6.3.8456.3

https://download.microsoft.com/download/3/3/9/339BE62D-B4B8-4956-B58D-73C4685FC492/MicrosoftDeploymentToolkit_x86.msi
https://download.microsoft.com/download/3/3/9/339BE62D-B4B8-4956-B58D-73C4685FC492/MicrosoftDeploymentToolkit_x64.msi
KB4564442 Hotfix
https://download.microsoft.com/download/3/0/6/306AC1B2-59BE-43B8-8C65-E141EF287A5E/KB4564442/MDT_KB4564442.exe

[Syrinox]

Сначала опешил, а потом вспомнил по какому принципу работает "шоколадка" ибо пытался разобраться в его лицензии - он же вообще чаще всего не хранит у себя ничего, а по сути перенаправляет на ссылку оффицального поставщика софта, но:

Первые две ссылки отдали 404

А попытка скачать ту версию на которую ты дал ссылку выдало следующее:

А точнее отсутсвие файла на сервере.

Да, choco install mdt -y сейчас спокойно ставит 8450, и функционально разница между 8450 и 8456 не какая-то пропасть. Но PSD сам ориентируется и тестируется именно на 8456, а получить именно этот последний релиз из прежнего публичного источника Microsoft уже не получается.

В итоге получается ещё один маленький legacy-нюанс: продукт формально можно достать в старой версии, последнюю приходится искать другими путями, сам MDT retired. Именно такой набор мелочей мне в новой инфраструктуре и не хотелось тащить дальше.

[MrBotikkk]

Тогда так:

https://web.archive.org/web/20260105014941/https://download.microsoft.com/download/3/3/9/339BE62D-B4B8-4956-B58D-73C4685FC492/MicrosoftDeploymentToolkit_x64.msi
https://web.archive.org/web/20260105014936/https://download.microsoft.com/download/3/3/9/339BE62D-B4B8-4956-B58D-73C4685FC492/MicrosoftDeploymentToolkit_x86.msi

[Syrinox]

Остаются неофициальные сайты и надежда, что в архиве нет ничего лишнего.

Правды ради пожалуй сохраню ссылочки...

[MrBotikkk]

Хэш можно проверить:

checksum = 'C67EED50478CD76AF1647848EF2A7723'
checksum64 = '0292D2C663D3D81416BC4BBB638291A5'
Get-FileHash "MicrosoftDeploymentToolkit_x64.msi" -Algorithm SHA256
certutil -hashfile "MicrosoftDeploymentToolkit_x64.msi" SHA256

[Syrinox]

Факт, мой последний тейк это не опровергает, суть остаётся той же. Сам сначала хотел написать что-то в духе «да, можно проверить хэш». Так что я с тобой согласен, более того, ссылки сохранил, полезные, спасибо.

Но это всё ещё не официальный источник, а значит появляется лишний риск и дополнительная морока с проверкой хэша и подписи.

Может, это уже моя личная паранойя вперемешку с перфекционизмом, но мне банально комфортнее доверять одной цепочке: вендор → я, а не вендор → архив → я. Хочется скачать официальный файл и поставить его, а не дополнительно заниматься проверками.

Понятно, что теоретически скомпрометировать могут и самого вендора, и тогда архив внезапно окажется даже полезнее. Но риск официального канала я как администратор в любом случае вынужден принимать. Добавлять к нему ещё одно звено в виде архива, пусть даже с минимальным риском, мне просто не хочется.

И вроде проверить хеш дело 10-15 секунд "открыл powershell - > команда -> сравнил результат -> закрыл" но... наша жизнь буквально состоит из траты секунд если признаться и бесконечного переключения фокуса с дела на дело.