SCCM Перезагрузка в начале последовательности задач

В устаревших целях мы не загружаем pxe напрямую из sccm, но имеем отдельный wds-сервер, с которого мы загружаем pxe, и загружаем wim загрузки sccm (среди прочего, опять же для устаревших целей) на этот сервер.

Однако в sccm и заключается настоящая причуда. Таким образом, для любой заданной последовательности задач есть назначенный ей загрузочный образ. Так что для моей последовательности задач Beta Мне назначен тот же загрузочный wim, который был загружен на сервер wds, ничего страшного. Я загружаю в pxe, выбираю Beta из списка доступных последовательностей задач, и я в пути.

После этого sccm убедится, что все пакеты, на которые ссылается последовательность задач, доступны в некоторой точке распространения, включая загрузочные wims.

Моя проблема приходит сразу после этого. Если PackageID загрузочного wim, на который есть ссылка в последовательности задач , не совпадает с PackageID загрузочного wim, который запускается в тот момент (или если последовательность задач запускается из полной ОС Windows), тогда sccm будет работать (прочитайте загрузить и спрятать куда-нибудь) загрузочный wim, указанный в последовательности задач, попросить пользователя "извлечь компакт-диск" и перезагрузить компьютер, а затем загрузить его до этого загрузочного wim.

Теперь я знаю, о чем вы думаете: "Майк, просто используй тот же wim, который указан в последовательности задач на твоем wds-сервере, и все будет хорошо".

Я бы не стал тратить ваше время, не делая этого. Проблема в том, что PackageID в wim загрузки wds не показывает правильный PackageID.

Correct PackageID: SMS000D8
Perceived PackageID: SMS0009E

Вот снимок журнала для визуальных учеников:

Теперь я узнал воспринятый packageID: это был оригинальный загрузочный wcm sccm, который был создан после обновления до SP1. Конечно, если я назначу этот wim загрузки моей последовательности задач, все будет продолжаться и перезагрузки не будет.

Тем не менее, есть веская причина, по которой этот загрузочный wim не назначен Beta, Каждый раз, когда мы пытаемся обновить этот загрузочный wim, он терпит неудачу. Неважно, драйверы ли это, дополнительные функции или вообще ничего, кроме обновления dp, он не работает при внедрении двоичных файлов OSD, по-видимому, это также происходит время от времени. Импортирование новых загрузочных wims и их обновление, кажется, работают нормально, поэтому мы попытались просто пойти по этому пути, и вот где мы сейчас.

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

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

Теперь, да: можно изменить значение BootMediaPackageID Переменная последовательности задач к тому, что мне нужно внутри последовательности задач (даже до того, как последовательность задач начинается с ловушек перед выполнением) и будет веселой. Тем не менее, переменная последовательности задач BootMediaPackageID действительно _SMSTSBootMediaPackageID и эта переменная, и другие подобные ей, доступны только для чтения.

Хорошей новостью является то, что все переменные последовательности задач хранятся в загрузочном wim в файле с именем variables.dat Из того, что я прочитал в сети. Плохая новость заключается в том, что этот файл не является открытым текстом.

Существует инструмент под названием tsenv2 из 1e, который должен иметь возможность редактировать этот файл, через отображение памяти, однако на веб-сайте написано, что это на 2007 год, и когда я пытался его использовать, я просто получаю случайную ошибку, о которой Google не слышал У меня сегодня вечером телефонная конференция с этими людьми, но я не кладу все свои яйца в одну корзину.

В другом сообщении на форуме упоминалось, что этот файл зашифрован с использованием мультимедийного пароля, который используется для доступа к последовательностям задач, если таковой имеется. Если нет, то это обычный xml. Мы используем медиа-пароль, чтобы это казалось многообещающим. Этот плакат также был достаточно любезен, чтобы упомянуть, что он зашифрован с использованием AES-256-CBC, что также звучит многообещающе, поэтому я скачал openssl для Windows и отправился в город, но безрезультатно. Если говорить с нашим администратором безопасности Sr, то с помощью cbc кажется, что у меня нет ключа и iv, а есть только пароль, что может быть недостаточно для расшифровки файла. Я сомневаюсь, что MS кашляет.

Итак, вот где я. Если кто-нибудь знает, как это обойти, у меня все уши.