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