出于遗留目的，我们不直接从 sccm 进行 pxe 启动，而是有一个单独的 wds 服务器，我们从该服务器进行 pxe 启动，并将 sccm 的启动 wim（以及其他内容，同样出于遗留目的）上传到该服务器。
然而，回到 sccm 中，真实的怪癖就在于此。因此，对于任何给定的任务序列，都会为其分配一个启动映像。因此，对于我的任务序列，Beta我为其分配了与上传到 wds 服务器相同的启动 wim，这没什么大不了的。我启动到 pxe，Beta从可用任务序列列表中进行选择，然后就可以开始了。
在此之后，sccm 将确保任务序列引用的任何包在某些分发点上可用，其中包括启动 wims。
我的问题就出在这之后。如果在任务序列中引用的启动 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是那变量以及其他类似的变量都是只读的。
好消息是，根据我在网上读到的信息，所有任务序列变量都存储在启动 wim 中的一个名为 的文件中variables.dat。坏消息是，这个文件不是明文。
有一个名为tsenv2from 1e 的工具，据说可以通过内存映射来编辑此文件，但是网站说它是 2007 年的，当我尝试使用它时，我只得到了一些谷歌从未听说过的随机错误。我今天晚些时候要和这些人开电话会议，但我不会孤注一掷。
另一个论坛帖子提到此文件使用用于访问任务序列的媒体密码加密（如果有的话）。如果没有，则为纯 xml。我们使用媒体密码，因此这似乎很有希望。该发帖人还很好心地提到它是使用 AES-256-CBC 加密的，这听起来也很有希望，因此我下载了适用于 Windows 的 openssl 并开始研究该文件，但无济于事。与我们的高级安全管理员交谈后发现，如果我没有密钥和 iv，只有密码，使用 cbc 可能不足以解密文件。我怀疑 MS 是否会提供这些。
这就是我目前的情况。如果有人知道如何解决这个问题，我愿意倾听。
答案1
对于那些仍然对此感到困惑的人（8 年后），您可以使用 SCCM 的“创建任务序列媒体”重新生成您的variables.dat 文件，选择“可启动媒体”ISO 的选项，确保选择您感兴趣的启动映像。生成 ISO 后，挂载它，然后从中提取variables.dat 文件。