vSphere環境におけるSysprepについて
仮想マシンの利点としては、迅速なデプロイが挙げられますが、Windowsに関して言えば”クローン”や”テンプレートからの新規マシンの展開”時には、Security IDの重複をなくす必要があります。
Security ID(SID)とは？
Security IDとは、Windows OS毎に一意の値であり、この識別子を元にユーザーアカウントや特定のWindows機能を利用する際にシステムを識別しています。
SIDの重複リスクについて
Security IDの重複リスクについては以下のリンクを参照下さい。
クローン作成またはデプロイ時の Windows のカスタマイズ（VMware)
上記で挙げたように、Windows仮想マシンを複製する際には、セキュリティや特定の機能の正常に利用するために複製元と複製後のWindowsとでは異なるSecurity IDを利用する必要があります。
※敢えて同じSIDを継続するポジティブな理由はありません。
SIDの再生成について
これを実現するには”Sysprep”と呼ばれるMicrosoftのツールを使う必要があります。このツールの歴史は長くWindows NT4.0にまで遡ります。Sysprep – Wikipedia
このツールはWindow 10やWindows 8.1などでは、Cドライブ内にデフォルトで格納されている。基本的にはこのツールをWindows上から実行すればOKです。
これはsysprep.exeを実行した際のイメージ図です。
基本的には、上記のプルダウン選択肢に加え、”Generalize(一般化する)”にチェックを入れてOKボタンをクリックします。
この操作を行う上で、”この処理をいつ、どのマシンで行うのか？”は、１つのポイントだと言える。(仮想マシンのテンプレートに対して行うのか？またはテンプレートから生成した新規の仮想マシン展開後に行うのか？)
個人的には後者の”テンプレートから生成した新規の仮想マシン展開後に行う”が良いと考えます。
この理由は、Sysprep実施後のWindowsは起動後にSID生成を始めとした初期動作が発生します。このこと自体は問題ではありません。仮想マシンテンプレートは、例えばWindowsアップデートや設定変更を行いたい場合は、一旦仮想マシン化してから起動して、起動後のOSにこれらの変更適用を行います。
つまり、テンプレート自身にSysprepをかけてしまうと、毎回更新作業に際して初期化動作が発生してしまい時間が掛かります。また、Sysprepは制限回数があります。(Windows 7は3回まで、Windows 8/10は1,001回まで)
上限確認方法はslmgrコマンドで確認が可能です。
コマンド実行後、表示されたプロンプト内の”リセット可能回数”から確認が可能です。
Windows 8.1ですと、制限回数を気にする必要ないくらいの制限数ですが、これらの事も考えればやはり何度も同じ仮想マシンイメージに対してSysprepを実行するのは避けたい所です。
新規展開されたWindows仮想マシンへのSysprepの自動化について
vCenter Serverがある環境であれば、”仮想マシンカスタマイズ仕様”という機能により、Sysprepの実行を自動化できます。これは仮想マシンを展開した後に、通常であれば次のような初期設定を行うと思いますが、これらを全て仕様書を事前に構成しておき、仕様書を仮想マシン展開時に指定することで、それに則った設定値適用を自動的に行なってくれるというものになります。
- 仮想マシン名のホスト名（特定の文字列を含める、仮想マシンの表示名を使うなど）
- ゲストOS内のタイムゾーン
- ボリュームライセンスキー入力
- 管理者パスワードの設定
- Windowsドメインまたはワークグループの参加
- ネットワーク設定（Static IPまたはDHCP）
- Sysprepの実行有無
Sysprep実行の落とし穴 – Microsoft ストア(Windows 8.x/10)
vSphereとしては大変シンプルな方法でSysprepが実行出来たのですが、Windows側の制限などによりSysprep実行時に問題が出るケースが存在します。
Windows 8.1や10に代表される”Microsoft ストア”を持つWindowsは、Sysprepが失敗するという問題があります。以下のリンク内には具体的な症状や回避作が紹介されています。
Windows 10 (バージョン 1511) における Sysprep 実行時の注意点
Windows10のOSイメージ展開の新常識（その2）――Sysprepを成功させるポイント
組み込みの Windows イメージを含む Microsoft Store アプリを削除または更新した後で sysprep が失敗する
どうやら、Microsoft ストアを持つWindows OSがインターネットに接続をされると、そのタイミングで自動的にMicrosoft ストアからゲームやアプリケーションがプッシュインストールされてしまい、それらがインストールされたWindows OSはSysprepによる一般化に失敗します。（詳細原因などは外部リンクを参照ください）
対処作についてもVMwareサイドで行うものではありませんので、こちらもお手数ですが上記紹介URL内で対応作についてはご確認いただけると幸いです。
おまけ：OEM版Windows OSのSysprepについて
こちらは以前に友人から質問された質問だったのですが、この場を借りて回答致します。
まず、OEM版Windowsは基本的には物理コンピューターに対して紐付いているため、そもそも複数の同一イメージ展開を想定されてません。(例：Dell製のノートパソコンにインストールされたOEM版Windows 10は、そのノートパソコン上での動作のみを許可するようライセンスが提供されています）
以下で紹介する2つのソースでも同様のことが記載されています。
OS プレインストール PC (OEM PC) の再イメージング (コピーによる社内展開) について
これらを受けて、OEM版Windowsをイメージ化したい場合は、”再イメージング”という手法を取る必要があるようです。
コマーシャル ライセンス メディアを使用したライセンス 取得済みのマイクロソフト ソフトウェア製品の再イメージング
上記リンクで紹介されている資料内の以下の記述より、OEM版Windowsライセンスで提供されたWindowsには、OEM版ではなくボリュームライセンスキー及びそれに対応するメディアでのWindowsイメージが必要なようです。
おまけ：QuickPrepとSysprep
Sysprepと似た名称の機能として”QuickPrep”という機能があります。これはVMware HorizonによるVDI環境におけるVDI仮想マシンの複製時に実行される仮想マシンカスタマイズ機能です。Sysprepとの比較が下記URL内にて掲示されていますので、ご興味がある方はご覧ください。
コメント