![SCCM 在任务序列开始时重新启动](https://linux22.com/image/623215/SCCM%20%E5%9C%A8%E4%BB%BB%E5%8A%A1%E5%BA%8F%E5%88%97%E5%BC%80%E5%A7%8B%E6%97%B6%E9%87%8D%E6%96%B0%E5%90%AF%E5%8A%A8.png)
出于遗留目的,我们不直接从 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
。坏消息是,这个文件不是明文。
有一个名为tsenv2
from 1e 的工具,据说可以通过内存映射来编辑此文件,但是网站说它是 2007 年的,当我尝试使用它时,我只得到了一些谷歌从未听说过的随机错误。我今天晚些时候要和这些人开电话会议,但我不会孤注一掷。
另一个论坛帖子提到此文件使用用于访问任务序列的媒体密码加密(如果有的话)。如果没有,则为纯 xml。我们使用媒体密码,因此这似乎很有希望。该发帖人还很好心地提到它是使用 AES-256-CBC 加密的,这听起来也很有希望,因此我下载了适用于 Windows 的 openssl 并开始研究该文件,但无济于事。与我们的高级安全管理员交谈后发现,如果我没有密钥和 iv,只有密码,使用 cbc 可能不足以解密文件。我怀疑 MS 是否会提供这些。
这就是我目前的情况。如果有人知道如何解决这个问题,我愿意倾听。
答案1
对于那些仍然对此感到困惑的人(8 年后),您可以使用 SCCM 的“创建任务序列媒体”重新生成您的variables.dat 文件,选择“可启动媒体”ISO 的选项,确保选择您感兴趣的启动映像。生成 ISO 后,挂载它,然后从中提取variables.dat 文件。