我尝试通过MDT部署图像，这些图像已通过MDT＆＃34;标准客户端升级＆＃34;升级。任务序列。我的图像以Win10 v1607图像开始，并更新为v1703然后被捕获。
当我去部署捕获的图像时，我会在首次登录时弹出一个c：\ LTIBootstrap.vbs无法找到的弹出窗口。挖掘，我发现在安装操作系统并重新启动PC后，MDT任务序列继续以 SYSTEM帐户运行。这很奇怪，因为它通常作为内置管理员帐户运行。
出于某种原因，即使unattend.xml文件包含常用的AutoAdminLogon条目，
上的注册表项也是如此HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SystemAutoLogon
并在部署期间将其设置为1。 （我通过比较部署结束时的注册表来发现这一点。）捕获的图像中不存在此密钥。 如果我将手动更新的映像部署到v1703（通过Windows Update而不是MDT），则无法创建此密钥。
有关为何可以忽略unattend.xml或者导致SystemAutoLogon被创建和设置的原因的任何想法？
答案 0 :(得分：0)
我弄明白发生了什么。
MDT升级任务序列使用指向setupcomplete.cmd的命令行/ postoobe选项调用升级。这会导致文件复制到c：\ windows \ setup \ scripts \ setupcomplete.cmd。当Windows安装完成后，如果该位置存在文件，则它将在SYSTEM帐户下运行。
问题是，在升级任务序列完全完成后，此文件仍然存在。因此，如果您随后捕获映像并将其部署到真实计算机，它将看到setupcomplete.cmd并在部署后运行它，而不是使用通常的默认管理员帐户。
我想在c：\ windows ...中存在此文件是导致上述注册表更改的原因。 setupcomplete.cmd仅用于将升级引导回MDT任务序列，并且需要在任务序列完成运行时从c：\ windows ...中删除。
了解升级任务序列的升级后部分通过与标准部署完全不同的机制以SYSTEM而不是管理员身份运行非常重要，因为您可以执行的操作有限制。默认情况下，序列允许您安装应用程序..它们需要是可以由SYSTEM安装的应用程序。
现在我已经在我的脚本目录中更新了我的本地SetupComplete.cmd，以便在完成后通过将最后一个for循环更改为此来删除自身（在阻止退出回声之前，for循环中也存在拼写错误）：
for %%d in (c d e f g h i j k l m n o p q r s t u v w x y z) do if exist %%d:\Windows\Setup\Scripts\setupcomplete.cmd (
del /q /f %%d:\Windows\Setup\Scripts\setupcomplete.cmd
echo %DATE%-%TIME% Exiting SetupComplete.cmd >> %WINDIR%\Temp\setupcomplete.log)
答案 1 :(得分：0)
在考虑了因为运行SYSTEM帐户而导致的更多问题后，我开始玩避免作为SYSTEM帐户运行。 （一个很大的问题是，如果要在重新启动后立即在任务序列结束时关闭，SYSTEM开始运行得太快，并且MDT中的关闭调用失败。）
我们的想法是使用以SYSTEM身份运行的SetupComplete.cmd来简单地引导回运行任务序列作为默认管理员。
实现这一点有一些皱纹。也就是说，在正常安装期间从unattend.xml运行的同步命令不会运行，因此启用admin，禁用uac for admin，禁用用户帐户页面，禁用异步运行等一切都必须手动调用。除此之外，只需通过在操作系统升级完成后通过任务序列中的步骤调用PopulateAutoAdminLogon和SetStartMDT来设置正确的注册表项，然后执行重新启动。这看起来效果很好。执行此操作的理想方法是使用调用PopulateAutoAdminLogon / SetStartMDT的相同脚本也解析unattend.xml并运行这些命令。
由于某种原因，即使为其设置了所有内容，shell隐藏也不起作用。我最好的猜测是，任务序列运行器正在执行此操作，因为IsOSUpgrade已设置，但我不确定。
使用这种方法，SetupComplete.cmd只负责将单个引导程序返回到任务序列中，并且任务序列可以在它调用脚本的同时删除它以执行PopulateAutoAdminLogon / SetStartMDT
有足够的工作要完全改进这种方法，我现在只解决一个自动登录问题，但它确实感觉是MDT在升级时更好的工作方式。希望他们将来能够充实它。