出於遺留目的，我們不會直接從 sccm 進行 pxe 引導，而是使用單獨的 wds 伺服器來進行 pxe 引導，並將 sccm 的引導 wim（以及其他目的，同樣用於遺留目的）上傳到該伺服器。
然而，回到 sccm 中，真實的古怪的謊言。因此，對於任何給定的任務序列，都會為其指派一個啟動映像。因此，對於我的任務序列，Beta我分配給它的啟動 wim 與上傳到 wds 伺服器的啟動 wim 相同，沒什麼大不了的。我啟動到 pxe，Beta從可用任務序列清單中進行選擇，然後就可以上路了。
此後，sccm 將確保任務序列引用的任何套件在某個分發點上可用，其中包括啟動 wim。
我的問題在那之後直接出現。如果任務序列中引用的啟動 wim 的 PackageID不匹配此時正在執行的啟動 wim 的 PackageID（或如果任務序列是從完整的 Windows 作業系統內部執行），則 sccm 將階段（閱讀下載並儲存在某處）任務序列中引用的啟動 wim，提示使用者「取出 CD」並重新啟動計算機，然後啟動到該啟動 wim。
現在，我知道你在想什麼：“Mike，只需使用 wds 伺服器上的任務序列中引用的相同啟動 wim 就可以了。”
我不會因為不這樣做而浪費你的時間。問題是 wds boot wim 上的 PackageID 未顯示正確的 PackageID。
Correct PackageID: SMS000D8
Perceived PackageID: SMS0009E
這是視覺學習者的日誌截圖：
現在，我認出了感知到的packageID：它是升級到SP1後創建的原始sccm boot wim。當然，如果我分配那將 wim 啟動到我的任務序列，一切都會繼續，並且不會重新啟動。
然而，引導 wim 沒有分配給 是有充分理由的Beta。每次我們嘗試更新啟動 wim 時，都會失敗。無論是驅動程式、額外功能還是除了 dp 更新之外什麼都沒有，注入 OSD 二進位時會失敗，顯然這也會發生在時不時地。導入新的啟動 wim 並更新它們似乎工作正常，所以我們嘗試走這條路，這就是我們現在的情況。
Beta需要在任務序列中間重新啟動，如果我們重新啟動到原始啟動 wim，則我們最新電腦型號的網路和/或儲存驅動程式不在其中，並且會發生不好的事情。
所以，我做了更多的谷歌搜索，因為一定我不是唯一一個遇到這個問題的人，事實證明我不是。
現在，是的：可以將任務序列變數的值變更BootMediaPackageID為任務序列中我需要的任何值（甚至前任務序列從預執行媒體掛鉤開始）並且很愉快。然而，任務序列變數BootMediaPackageID確實是_SMSTSBootMediaPackageID且那變數和其他類似變數是唯讀的。
好消息是，variables.dat根據我在網路上讀到的內容，所有任務序列變數都儲存在啟動 wim 上一個名為 的檔案中。壞消息是該文件不是明文。
有一個名為tsenv21e 的工具應該能夠透過記憶體映射編輯這個文件，但是該網站說它是 2007 年的，當我嘗試使用它時，我只是得到一些 google 沒有聽說過的隨機錯誤。今天晚些時候我將與這些人舉行電話會議，但我不會把所有雞蛋都放在一個籃子裡。
另一個論壇貼文提到該文件使用用於存取任務序列的媒體密碼（如果有）進行加密。如果沒有，那就是純 xml。我們使用媒體密碼，所以這看起來很有希望。那張海報還很友善地提到它是使用 AES-256-CBC 加密的，這聽起來也很有希望，所以我下載了 Windows 版的 openssl，然後去城裡查看該文件，但沒有成功。與我們的高級安全管理員交談，如果我沒有金鑰和 iv 而只有密碼，那麼 cbc 似乎不足以解密該檔案。我懷疑 MS 是否會咳嗽。
所以，這就是我現在的處境。如果有人知道如何解決這個問題，我會洗耳恭聽。
答案1
對於那些仍然對此感到困惑的人（8 年後），您可以透過使用 SCCM「建立任務序列媒體」來重新產生變數.dat 文件，選擇「可啟動媒體」ISO 的選項，確保選擇啟動您感興趣的影像。