SCCM在任务序列开始时重新启动

对于遗留的目的，我们不直接从sccm启动，而是有一个独立的wds服务器，我们可以从这个服务器启动，然后上传sccm的启动wim（以及其他用于传统目的）。

回到SCCM，然而， 真正的怪癖在哪里。所以，对于任何给定的任务序列，都有一个启动映像分配给它。所以对于我的任务序列Beta我有相同的启动wim分配给它上传到wds服务器，没有什么大不了的。我启动到pxe，从可用的任务序列列表中selectBeta ，并在我的路上。

在此之后，sccm将确保任务序列引用的任何软件包在某个分发点上可用，这包括引导wims。

我的问题直接在那之后。如果任务序列中引用的引导wim的PackageID与此时正在运行的引导wim的PackageID 不匹配 （或者如果任务序列是从完整的Windows操作系统内运行的），则sccm将stage （读取下载并存储到某个地方）任务序列中引用的启动文件，提示用户“删除CD”并重新启动计算机，然后启动到该启动文件夹。

现在，我知道你在想什么： “Mike，只需使用wds服务器上的任务序列中引用的启动wim，就可以了。”

我不会因为不这样做而浪费你的时间。问题是wds boot wim上的PackageID没有显示正确的PackageID。

 Correct PackageID: SMS000D8 Perceived PackageID: SMS0009E

以下是视觉学习者的日志：

sccm日志文件

现在，我认识到了packageID：这是在升级到SP1后创build的原始sccm boot wim。当然，如果我将启动wim分配给我的任务序列，一切都会继续，并且不会重新启动。

但是，为什么boot wim没有分配给Beta ？每次我们尝试和更新启动wim，它都会失败。如果它是驱动程序，额外的function，或者什么也没有，只是一个DP更新，它注入OSD二进制文件时失败，显然这也会不时发生。导入新的启动wims并更新它们似乎工作正常，所以我们试着走这条路线，这就是我们现在的位置。

Beta需要在任务序列中间重新启动，如果我们重新启动到原始启动wim，我们最新的计算机模型的networking和/或存储驱动程序不在其中，坏的事情发生。

所以我做了更多的search，因为我不是唯一有这个问题的人，事实certificate我不是。

现在，是的：可以将BootMediaPackageID任务序列variables的值更改为我在任务序列中需要的任何值（甚至在任务序列以预执行介质挂钩开始之前）并且快乐。但是，任务序列variablesBootMediaPackageID是_SMSTSBootMediaPackageID并且该variables以及其他类似variables是只读的。

好消息是，所有的任务序列variables都存储在一个叫做variables.dat的文件中，从我在网上读到的文件中。坏消息是这个文件不是明文。

有一个名为tsenv2的工具，应该可以通过内存映射来编辑这个文件，但是网站上说它是用于2007年的，当我尝试使用它的时候，我只是得到了一些Google没有听到的随机错误的。我今天晚些时候和这些人召开电话会议，但是我并没有把所有的鸡蛋放在一个篮子里。

另一个论坛post提到，使用用于访问任务序列的媒体密码（如果有的话）对该文件进行encryption。如果没有，这是简单的XML。我们使用媒体密码，所以看起来很有希望。这张海报还提到它使用AES-256-CBC进行encryption，这也听起来很有希望，所以我下载了openssl for Windows，然后去了镇上，没有任何结果。说到我们的高级安全pipe理员似乎与cbc，如果我没有密钥和iv，但只是密码，可能不是enouh解密文件。我怀疑MS是不是在咳嗽。

所以，那就是我所在的地方。如果有人知道如何解决这个问题，我全都听。