2017-08-17 3 views
0

MDTを介してイメージを展開しようとしましたが、MDTの "Standard Client Upgrade"タスクシーケンスでアップグレードされました。私のイメージはWin10 v1607イメージとして開始され、v1703にアップデートされてキャプチャされました。アップグレードされたOSを展開する際のMicrosoft Deployment Toolkitの設定SystemAutoLogonレジストリキー

キャプチャしたイメージを展開すると、最初のログイン時にc:\ LTIBootstrap.vbsが見つからないというポップアップが表示されます。私は、OSがインストールされ、PCが再起動した後、MDTタスクシーケンスがのSYSTEMアカウントとして実行され続けることを発見しました。これは通常、組み込みAdministratorアカウントとして実行されるため、これは奇妙です。 Unattend.xmlファイルが

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SystemAutoLogon 

のレジストリキーが展開中に作成され、1に設定されている、通常のAutoAdminLogonのエントリが含まれているにもかかわらず、何らかの理由で

、。 (私は展開の終わりにレジストリを比較することによってこれを発見しました。)このキーはキャプチャされたイメージには存在しません。 v1703に手動で更新されたイメージを展開すると、このキーは作成されません(MDTではなくWindows Update経由)。

なぜunattend.xmlを無視できるのか、SystemAutoLogonを作成して設定するのは何ですか?

答えて

0

私は何が起こっていたのか理解しました。

MDTアップグレードタスクシーケンスでは、setupcomplete.cmdを指すコマンドライン/ postoobeオプションを使用してアップグレードを呼び出します。これにより、ファイルがc:\ windows \ setup \ scripts \ setupcomplete.cmdにコピーされます。 Windowsのインストールが完了すると、その場所にファイルが存在する場合、そのファイルはSYSTEMアカウントで実行されます。

問題は、アップグレードタスクシーケンスが完全に完了した後でもこのファイルが残っていることです。したがって、イメージをキャプチャして実際のマシンに展開すると、通常のデフォルトのAdministratorアカウントを使用する代わりに、setupcomplete.cmdが表示され、展開後にイメージが実行されます。

私はこのファイルがc:\ windows ...にあると想像していますが、上記のレジストリの変更が原因です。 setupcomplete.cmdは、アップグレードをMDTタスクシーケンスにブートストラップするためにのみ構築されており、タスクシーケンスの実行が完了するとc:\ windows ...から削除する必要があります。そして、あなたが何ができるかには限界があるとして、アップグレードタスクシーケンスのアップグレード後の部分は、標準的な展開とは非常に異なるメカニズムを介してシステムの代わりに、管理者として実行されることを知っ

は、重要です。デフォルトでは、シーケンスはアプリケーションをインストールできます。システムによってインストールされているアプリケーションである必要があります。

今のところ私はスクリプトディレクトリのローカルSetupComplete.cmdを更新しました。これは最後のforループをこれに変更することで削除されます(exitエコーを防ぐ前に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) 
+0

SetupComplete.cmdへの編集が不十分であることが検出されました。シャットダウンでタスクシーケンスを終了したい場合は、SetupComplete.cmdがまだ存在し、次回マシンをブートするまで削除されません。これは場合によっては軽微かもしれませんが、私には問題を引き起こします。 ここでは、タスクシーケンスの最後にある手動ステップを使用してSetupComplete.cmdを削除し、クリーンアップコードをSetupComplete.cmdからこの新しい手動ステップに移動しました。 – aggieNick02

0

SYSTEMアカウントとして実行されているために、このような問題が発生したと考えて、私はSYSTEMアカウントとして実行しないようにしました。 (大きな問題の1つは、再起動直後にタスクシーケンスの最後でシャットダウンしたい場合は、SYSTEMの起動が速すぎるため、MDTでのシャットダウンの呼び出しに失敗することです)。

代わりに、 SYSTEMとして実行されているSetupComplete.cmdを実行して、デフォルトの管理者としてタスクシーケンスを実行するだけです。

これを実装するにはいくつかのシワがあります。つまり、通常のインストール時にunattend.xmlから実行される同期コマンドは実行されないため、管理者の有効化、adminのuacの無効化、ユーザーアカウントページの無効化、非同期の実行の無効化などの操作はすべて手動で実行する必要があります。さらに、OSアップグレードが完了した後、タスクシーケンスのステップを経てPopulateAutoAdminLogonおよびSetStartMDTを呼び出すことによって正しいレジストリエントリを設定してから、再起動するだけで問題はありません。これはかなりうまくいくようです。これを行う理想的な方法は、PopulateAutoAdminLogon/SetStartMDTを呼び出してunattend.xmlを解析し、それらのコマンドを実行する同じスクリプトを持つことです。

何らかの理由で、すべてが設定されていてもシェル隠蔽が機能しません。私の最高の推測は、IsOSUpgradeが設定されているが、わからないためにタスクシーケンスのランナーがこれを実行していることです。このアプローチで

、SetupComplete.cmdはバックタスクシーケンスへの単一のブートストラップのためだけに責任がある、とタスクシーケンスは、それがありPopulateAutoAdminLogon/SetStartMDT

を行うには、スクリプトを呼び出すのと同時に、それを削除することができますこのアプローチを完全に磨くためには十分な作業が必要ですが、今のところ私が問題になっている問題を回避するだけですが、MDTがアップグレードを行うときにはMDTがうまく機能するように感じています。うまくいけば、彼らは将来肉体を育てるだろう。

関連する問題