Для устаревших целей мы не загружаем pxe напрямую из sccm, но имеем отдельный сервер wds, с которого мы загружаемся с помощью pxe, и загружаем загрузочный wim sccm (среди прочего, опять же для старых целей) на этот сервер.
Однако в sccm настоящий причуда ложь. Итак, для любой данной последовательности задач есть назначенный ей загрузочный образ. Итак, для моей последовательности задач Beta
У меня есть тот же загрузочный WIM, который был загружен на сервер wds, ничего страшного. Я загружаюсь в pxe, выбираю Beta
из списка доступных последовательностей задач, и я уже в пути.
После этого sccm будет следить за тем, чтобы все пакеты, на которые ссылается последовательность задач, были доступны в какой-либо точке распространения, включая загрузочные WIM-файлы.
Моя проблема возникает сразу после этого. Если PackageID загрузочного WIM-файла, на который есть ссылка в последовательности задач не совпадает PackageID загрузочного WIM-файла, который запускается в данный момент (или если последовательность задач выполняется изнутри полной ОС Windows), тогда sccm будет этап (прочтите скачать и спрятать где-нибудь) загрузочный wim, указанный в последовательности задач, предложите пользователю «удалить компакт-диск» и перезагрузить машину, затем загрузитесь с этим загрузочным wim-файлом.
Теперь я знаю, о чем вы думаете: «Майк, просто используйте тот же загрузочный wim-файл, который указан в последовательности задач на вашем сервере wds, и все будет в порядке».
Я бы не стал тратить ваше время, не делая этого. Проблема в том, что PackageID в WDS-загрузчике wds не показывает правильный PackageID.
Correct PackageID: SMS000D8
Perceived PackageID: SMS0009E
Вот снимок журнала для наглядных учеников:
Теперь я узнал воспринимаемый packageID: это был оригинальный загрузочный wim sccm, который был создан после обновления до SP1. Конечно, если я назначу который загрузите wim в мою последовательность задач, все идет, и перезагрузки нет.
Однако есть веская причина, по которой этот загрузочный WIM не назначен Beta
. Каждый раз, когда мы пытаемся обновить этот загрузочный wim, он терпит неудачу. Неважно, если это драйверы, дополнительные функции или вообще ничего, кроме обновления dp, он не работает при внедрении двоичных файлов OSD, по-видимому, это также происходит из время от времени. Импорт новых загрузочных WIM-файлов и их обновление, похоже, работают нормально, поэтому мы попробовали просто пойти по этому пути, и вот где мы сейчас находимся.
Beta
требует перезапуска в середине последовательности задач, и если мы перезагружаемся в исходный загрузочный wim, драйверы сети и / или хранилища для наших последних моделей компьютеров в нем отсутствуют, и случаются плохие вещи.
Итак, я больше погуглил, потому что конечно Эта проблема возникает не только у меня, и оказывается, Я не был.
Теперь да: можно изменить значение BootMediaPackageID
переменную последовательности задач на все, что мне нужно внутри последовательности задач (даже перед последовательность задач начинается с перехватов мультимедиа перед выполнением) и будьте веселыми. Однако переменная последовательности задач BootMediaPackageID
действительно _SMSTSBootMediaPackageID
и который переменная и другие подобные доступны только для чтения.
Хорошей новостью является то, что все переменные последовательности задач хранятся в загрузочном WIM в файле с именем variables.dat
из того, что я прочитал в сети. Плохая новость в том, что этот файл не является открытым текстом.
Есть инструмент под названием tsenv2
from 1e, который должен иметь возможность редактировать этот файл с помощью сопоставления памяти, однако на веб-сайте указано, что это для 2007 года, и когда я попытался его использовать, я просто получил случайную ошибку, о которой Google не слышал. У меня сегодня конференц-звонок с этими людьми, но я не кладу все яйца в одну корзину.
Другой пост на форуме упомянул, что этот файл зашифрован с использованием медиа-пароля, который используется для доступа к последовательностям задач, если они есть. Если нет, то это обычный xml. Мы используем медиа-пароль, поэтому это показалось многообещающим. Этот плакат также был достаточно любезен, чтобы упомянуть, что он зашифрован с использованием AES-256-CBC, что тоже звучало многообещающе, поэтому я загрузил openssl для Windows и отправился в город с файлом, но безрезультатно. Говоря с нашим старшим администратором безопасности, кажется, что с cbc, если у меня нет ключа и iv, а есть только пароль, этого может быть недостаточно для расшифровки файла. Я сомневаюсь, что РС их кашляет.
Итак, вот где я нахожусь. Если кто знает, как это обойти, я весь уши.