Ну вот да... я на редите тоже пост делал по поводу IronDeploy и там чувак упомянул, что брал "интерпрайс издание" - однако чуваки с супорта тупо не смогли им помочь завести систему, не знаю насколько факт/вброс
Я пока больше упор в лёгкость и flow делаю, не знаю насколько вообще получится на этом долго гонять
Факт, мой последний тейк это не опровергает, суть остаётся той же. Сам сначала хотел написать что-то в духе «да, можно проверить хэш». Так что я с тобой согласен, более того, ссылки сохранил, полезные, спасибо.
Но это всё ещё не официальный источник, а значит появляется лишний риск и дополнительная морока с проверкой хэша и подписи.
Может, это уже моя личная паранойя вперемешку с перфекционизмом, но мне банально комфортнее доверять одной цепочке: вендор → я, а не вендор → архив → я. Хочется скачать официальный файл и поставить его, а не дополнительно заниматься проверками.
Понятно, что теоретически скомпрометировать могут и самого вендора, и тогда архив внезапно окажется даже полезнее. Но риск официального канала я как администратор в любом случае вынужден принимать. Добавлять к нему ещё одно звено в виде архива, пусть даже с минимальным риском, мне просто не хочется.
И вроде проверить хеш дело 10-15 секунд "открыл powershell - > команда -> сравнил результат -> закрыл" но... наша жизнь буквально состоит из траты секунд если признаться и бесконечного переключения фокуса с дела на дело.
Сначала опешил, а потом вспомнил по какому принципу работает "шоколадка" ибо пытался разобраться в его лицензии - он же вообще чаще всего не хранит у себя ничего, а по сути перенаправляет на ссылку оффицального поставщика софта, но:
Первые две ссылки отдали 404
А попытка скачать ту версию на которую ты дал ссылку выдало следующее:
А точнее отсутсвие файла на сервере.
Да, choco install mdt -y сейчас спокойно ставит 8450, и функционально разница между 8450 и 8456 не какая-то пропасть. Но PSD сам ориентируется и тестируется именно на 8456, а получить именно этот последний релиз из прежнего публичного источника Microsoft уже не получается.
В итоге получается ещё один маленький legacy-нюанс: продукт формально можно достать в старой версии, последнюю приходится искать другими путями, сам MDT retired. Именно такой набор мелочей мне в новой инфраструктуре и не хотелось тащить дальше.
Забавно, что мой прошлый руководитель поручивший мне эти задачи с wds/mdt тоже постоянно шутил про "так я ж не настоящий сварщик" из одного анекдота ;) Улыбнуло если честно
А по сути вопроса, на самом деле интересно 1. как проводились тесты, это был агент на тачке вшитый в образ и отдающий данные в какой-то сервак? ну т.е... как это вообще происходило на каком уровне, от куда куда текли данные 2. сколько вообще обычно занимало времени на раскрутку windows 10/11 к примеру от Начала до того как начнётся подтягивание политик с домена (т.е где по сути своей ни сколько зона деплоя, сколько доменная) ?
3. На самом деле я серьёзно задумался о поддержке двух вариаций в моём проекте... надо потестировать насколько быстрее вообще будут ставятся образы с того же fog и имеет ли это смысл как таковой...
Мне просто нравится, что на любой случай большинство вещей просто подтягиваются на горячую по SMB т.е в любой момент можно загрузить новую винду и не пересобирать, она уже будет работать потому-что install.wim уже ожидаемо примется командами если конечно не поменялась архитектура самого .wim
или софт - он поставится и не обязательно пересобирать образ так-же и драйвера
Но опять же наверное зависит от того насколько fog шустрее это применяет
FriendsOfMDT были одними из первых вариантов, которые я рассматривал, но так же быстро и отсеялись. Причина до смешного простая: им всё ещё нужен сам MDT.
А в статье я как раз и описывал основную причину, почему вообще полез искать альтернативу: нормальной официальной возможности скачать MDT уже по сути нет. Да, можно найти его там, тут, сям, но тащить такое в прод через сторонние источники мне показалось рискованным. Ну и, если честно, уже хотелось чего-то нового.
Это примерно как когда старый телефон начинает глючить: можно взять следующую модель почти такую же, но почему-то специально хочется совсем другую, в надежде, что там-то уж точно всё будет иначе. Классическая «трава у соседей зеленее» ;)
При этом уже после того, как решил писать своё, некоторые идеи и подходы FriendsOfMDT я всё-таки подсматривал и местами использовал как вдохновение.
А вот Glazier. До вашего комментария вообще о нём не слышал. Выглядит интересно, теперь хочется нормально покопаться в нём. Как говорится, очередная причина возгорания токенов Claude и GPT :0 на вечерок по баночку энергосика
И да спасибо вам тоже) для меня каждый коментарий буквально как впрыск азота желания развивать проект сильнее, ибо интрига и интерес прям горят изучать всё это дельце глубже
Не скажу, что знаю SCCM вдоль и поперёк. Впрочем, я и MDT за три года, наверное, не до конца изучил :)
Пока цель у меня гораздо уже: скорость, лёгкость и минимальное количество движущихся частей. Хочется сделать максимально коротким путь от установки IronDeploy до первого деплоя, а сам процесс развёртывания по возможности быстрым и простым.
Поэтому IronDeploy я бы скорее назвал сильно упрощённым самостоятельным аналогом MDT, чем попыткой повторить SCCM. После деплоя компьютер меня уже практически не интересует: максимум SetupComplete / post-install, финальный отчёт, и на этом всё.
Впрочем, будет враньём сказать, что у меня периодически не возникают техно-фантазии разрастить проект настолько, насколько хватит меня самого и интереса пользователей :) Но скорее хочется не напихать туда всё подряд, а дать возможность подстраивать IronDeploy под реальные сценарии тех, кто им пользуется, особенно там, где в MDT чего-то не хватало.
Ну вот да... я на редите тоже пост делал по поводу IronDeploy и там чувак упомянул, что брал "интерпрайс издание" - однако чуваки с супорта тупо не смогли им помочь завести систему, не знаю насколько факт/вброс
Я пока больше упор в лёгкость и flow делаю, не знаю насколько вообще получится на этом долго гонять
Факт, мой последний тейк это не опровергает, суть остаётся той же. Сам сначала хотел написать что-то в духе «да, можно проверить хэш». Так что я с тобой согласен, более того, ссылки сохранил, полезные, спасибо.
Но это всё ещё не официальный источник, а значит появляется лишний риск и дополнительная морока с проверкой хэша и подписи.
Может, это уже моя личная паранойя вперемешку с перфекционизмом, но мне банально комфортнее доверять одной цепочке: вендор → я, а не вендор → архив → я. Хочется скачать официальный файл и поставить его, а не дополнительно заниматься проверками.
Понятно, что теоретически скомпрометировать могут и самого вендора, и тогда архив внезапно окажется даже полезнее. Но риск официального канала я как администратор в любом случае вынужден принимать. Добавлять к нему ещё одно звено в виде архива, пусть даже с минимальным риском, мне просто не хочется.
И вроде проверить хеш дело 10-15 секунд "открыл powershell - > команда -> сравнил результат -> закрыл" но... наша жизнь буквально состоит из траты секунд если признаться и бесконечного переключения фокуса с дела на дело.
Правды ради пожалуй сохраню ссылочки...
Сначала опешил, а потом вспомнил по какому принципу работает "шоколадка" ибо пытался разобраться в его лицензии - он же вообще чаще всего не хранит у себя ничего, а по сути перенаправляет на ссылку оффицального поставщика софта, но:
Первые две ссылки отдали 404
А попытка скачать ту версию на которую ты дал ссылку выдало следующее:
А точнее отсутсвие файла на сервере.
Да, choco install mdt -y сейчас спокойно ставит 8450, и функционально разница между 8450 и 8456 не какая-то пропасть. Но PSD сам ориентируется и тестируется именно на 8456, а получить именно этот последний релиз из прежнего публичного источника Microsoft уже не получается.
В итоге получается ещё один маленький legacy-нюанс: продукт формально можно достать в старой версии, последнюю приходится искать другими путями, сам MDT retired. Именно такой набор мелочей мне в новой инфраструктуре и не хотелось тащить дальше.
Забавно, что мой прошлый руководитель поручивший мне эти задачи с wds/mdt тоже постоянно шутил про "так я ж не настоящий сварщик" из одного анекдота ;) Улыбнуло если честно
А по сути вопроса, на самом деле интересно
1. как проводились тесты, это был агент на тачке вшитый в образ и отдающий данные в какой-то сервак? ну т.е... как это вообще происходило на каком уровне, от куда куда текли данные
2. сколько вообще обычно занимало времени на раскрутку windows 10/11 к примеру от Начала до того как начнётся подтягивание политик с домена (т.е где по сути своей ни сколько зона деплоя, сколько доменная) ?
3. На самом деле я серьёзно задумался о поддержке двух вариаций в моём проекте... надо потестировать насколько быстрее вообще будут ставятся образы с того же fog и имеет ли это смысл как таковой...
Мне просто нравится, что на любой случай большинство вещей просто подтягиваются на горячую по SMB т.е в любой момент можно загрузить новую винду и не пересобирать, она уже будет работать потому-что install.wim уже ожидаемо примется командами если конечно не поменялась архитектура самого .wim
или софт - он поставится и не обязательно пересобирать образ
так-же и драйвера
Но опять же наверное зависит от того насколько fog шустрее это применяет
лок’тар огар!
FriendsOfMDT были одними из первых вариантов, которые я рассматривал, но так же быстро и отсеялись. Причина до смешного простая: им всё ещё нужен сам MDT.
А в статье я как раз и описывал основную причину, почему вообще полез искать альтернативу: нормальной официальной возможности скачать MDT уже по сути нет. Да, можно найти его там, тут, сям, но тащить такое в прод через сторонние источники мне показалось рискованным. Ну и, если честно, уже хотелось чего-то нового.
Это примерно как когда старый телефон начинает глючить: можно взять следующую модель почти такую же, но почему-то специально хочется совсем другую, в надежде, что там-то уж точно всё будет иначе. Классическая «трава у соседей зеленее» ;)
При этом уже после того, как решил писать своё, некоторые идеи и подходы FriendsOfMDT я всё-таки подсматривал и местами использовал как вдохновение.
А вот Glazier. До вашего комментария вообще о нём не слышал. Выглядит интересно, теперь хочется нормально покопаться в нём. Как говорится, очередная причина возгорания токенов Claude и GPT :0 на вечерок по баночку энергосика
И да спасибо вам тоже) для меня каждый коментарий буквально как впрыск азота желания развивать проект сильнее, ибо интрига и интерес прям горят изучать всё это дельце глубже
Не скажу, что знаю SCCM вдоль и поперёк. Впрочем, я и MDT за три года, наверное, не до конца изучил :)
Пока цель у меня гораздо уже: скорость, лёгкость и минимальное количество движущихся частей. Хочется сделать максимально коротким путь от установки IronDeploy до первого деплоя, а сам процесс развёртывания по возможности быстрым и простым.
Поэтому IronDeploy я бы скорее назвал сильно упрощённым самостоятельным аналогом MDT, чем попыткой повторить SCCM. После деплоя компьютер меня уже практически не интересует: максимум SetupComplete / post-install, финальный отчёт, и на этом всё.
Впрочем, будет враньём сказать, что у меня периодически не возникают техно-фантазии разрастить проект настолько, насколько хватит меня самого и интереса пользователей :) Но скорее хочется не напихать туда всё подряд, а дать возможность подстраивать IronDeploy под реальные сценарии тех, кто им пользуется, особенно там, где в MDT чего-то не хватало.