デスクトップ ファイル仮想世界で Windows を展開する

Wes Miller

仮想コンピューティングは至るところで利用されています。まだ利用していないとしたら、利用すべきです。仮想化を使用すると、実質的には専用のハードウェア アブストラクション レイヤが作成され、1 つ以上のゲスト システム (Windows Server オペレーティング システムや Windows クライアント オペレーティング システムなど) をホスト システム間で移動できるようになるため、ハードウェアへの依存が軽減されます。

もちろん、仮想化はゲストのプロセッサを模倣しないため、エミュレーションとは異なります。仮想化では、単に、ゲスト システムからホスト システムのリソースにアクセスできるようになるだけです。このため、ホスト システムはゲストに対して汎用的になります。一般に、ある OEM によって構築されたシステムから別の OEM によって構築されたシステムに仮想ゲストを移動できます。通常、ホストのハードウェアは問題になりません。ただし、注意しなければならないことがあります。たとえば、ある CPU ベンダ (AMD など) のプロセッサが搭載されたハードウェアから別の CPU ベンダ (Intel など) のプロセッサが搭載されたハードウェアにゲストを移動する場合、(使用している仮想化テクノロジによっては) 問題が発生することがあります。これは、仮想コンピューティング テクノロジではホストとゲストが情報のみを受け渡しするためです。(たとえば、古いバージョンの PowerPC ベースの Macintosh 上で実行されている Microsoft® Virtual PC で行っていたように) ゲストの特定の CPU のエミュレーションが行われることはありません。

ただし、仮想化では、ゲストに対して主要なハードウェア コンポーネントのエミュレーションが行われます。ほとんどの場合、このようにエミュレーションが行われるハードウェア コンポーネントは、ネットワーク、ビデオ (通常、高度な GPU はエミュレーションが行われないため、デバイスの機能は大きく制限されます)、および大容量記憶装置に限定されます。これらのコンポーネントはすべて、ソフトウェアによってエミュレーションが行われる 1 種類以上のデバイスをゲストに提供することによって動作します。私のコラムを何回かお読みになっていれば、今挙げたデバイスは Windows® PE でサポートされているデバイスと同じであることにお気付きになるでしょう。仮想化された Windows を実際に動作させる場合も、これらの種類のデバイスが必要です。さらに、あらゆる仮想化テクノロジでは BIOS のエミュレーションを行う必要があります。仮想化テクノロジでは、拡張ファームウェア インターフェイス (EFI) のエミュレーションを行うこともできますが、現在、EFI ベースのオペレーティング システムは限られているため、EFI のエミュレーションを行うという方法はあまり使用されません。こうしたエミュレーションをすべて行うことにより、仮想ゲストを起動することができるようになります。BIOS と各デバイスはソフトウェアで実際のデバイスのエミュレーションを行うことで、そのデバイスをゲストに提供します。したがって、実際のデバイスに必要なドライバ (Windows によって提供されるドライバとは限りません) と同じドライバが必要になります。これは重要な考え方であるため、覚えておいてください。

一部の仮想化テクノロジでは USB (USB 2.0) デバイスとインターフェイスを取ることができるものもありますが、ここでそれらのテクノロジを詳しく説明するつもりはありません。ドライバ (プリンタ、USB ワイヤレス NIC など) や特定の DirectX® のサポート (ほとんどの仮想化テクノロジでは提供されません) を必要とするものを除けば、USB デバイスを動作させるために必要な作業は、あまり多くありません。当然ながら、USB デバイスやエミュレーションが行われない他のデバイスがサポートされているかどうかは、使用している仮想化テクノロジによって異なることに注意してください。新しいデバイスを仮想化製品で使用する際は、その仮想化製品の制限事項 ("鋭い刃"、とでも呼ぶことにします) を知っておくようにしてください。

現在、Windows で使用できる仮想化テクノロジの主要なベンダとしては、マイクロソフトと VMware (vmware.com) の 2 社があります。この他にも、Parallels (parallels.com) など、成長が期待できるベンダがあります。

ここまでの説明で、仮想化の概要をご理解いただけたと思います。このコラムの残りの部分では、仮想システムの設定方法、よく発生する問題の回避方法、および使用中の環境で複数のコンピュータに仮想システムを展開する方法について説明します。

仮想システムの展開

仮想システムの展開と物理システムの展開に違いがあるべきではありません。しかし、後で説明しますが、異なる展開になる十分な理由があるのです。

Windows NT® の発売当初は、セットアップを使用して展開を行う必要がありました。この操作はスクリプトを使用して行うこともできましたが、すべてのプロセスを実行する必要がありました。セットアップが完了しても、そのイメージを複数のシステムにコピーすることは (便利な考え方ですが) できませんでした。

しかし、マイクロソフトは最終的に、ディスク複製される ("クローン化される") Windows NT システムをサポートすることが理にかなっていると判断しました。そのため現在では、物理システムを展開する場合に使用できる方法はすべて、仮想システムの展開でも使用できます。Winnt32 (Windows Vista® や Windows Server® 2008 の場合は setup.exe) や Windows PE (以前のコラムで説明したように、展開するクライアントに応じて 1.x または 2.x のいずれかを使用します) を使用できます。また、リモート インストール サービス (RIS)、Windows 展開サービス (WDS)、または Sysprep (Windows NT 4.0 で導入された、展開用のシステム準備ツール) も使用できます。さらに、お好みのディスク複製テクノロジ (ImageX など) を使用することもできます。

当然ながら、これを行う必要があるのは、特定の OS を最初に展開するときだけです。その後は、単に作成したイメージをコピーするだけで済みます。しかし、今説明したようなディスク ベースの複製方法には問題があります。

Sysprep を使用する

最初にマイクロソフトがディスク ベースの複製をサポートしないことを決めた主な理由は、Windows NT のセキュリティ識別子 (SID) でした。さいわい、Sysprep を使用すれば、この問題を解決することができます。しかし、まずはこれがどのような問題であるかを見ておきましょう。support.microsoft.com/kb/314828 で説明されているように、SID の構成要素の 1 つは、Windows ベースの個々のコンピュータを識別する、SID 構造体のリビジョン番号 (通常はグローバル一意識別子 (GUID) と呼ばれます) です。このリビジョン番号を基に、すべてのローカル アカウントの識別子が生成されます。各ローカル アカウントは、相対識別子 (RID) と呼ばれる一意の識別子を持っています。RID は、SID の末尾に付加されるアカウント ID です。したがって、2 つを組み合わせるとローカル アカウントの識別子になります。

では、Administrator の SID である S-1-5-21-191058668-193157475-1542849698-500 を使用して、なぜこれが問題なのかを考えてみましょう。この例の S-1-5 は、これが SID であることを示す記述子 (S はすべての SID のテキスト表現に使用されます) で、1 と 5 はそれぞれ、Windows NT SID のリビジョン番号と権限識別子の値 (この例では Windows セキュリティ) を表します。残りの部分 (500 を含む) は実際の SID であり、この部分から、これが既知の SID (Windows Administrator アカウント) であることが特定できます。すべての Windows インストールで既定で作成される Administrator アカウント (削除することはできません) の SID は、末尾が 500 です。インストール後に Windows に追加されたローカル ユーザー アカウントは、末尾が 1000 以上になります。

Windows Sysinternals (私が以前書いた、PSTools についてのコラム technetmagazine.com/issues/2007/03/DesktopFiles で言及しました) から入手できる PsGetSid を使用すると、システムに登録されている特定のユーザーの SID や、システムの SID を一覧に表示することができます。図 1 は PsGetSid の出力を示しており、私の仮想システムの SID、および私のユーザー アカウント 1003 の SID が表示されています。

図 1** PsGetSid の出力 (仮想システムの SID とユーザー アカウント 1003 の SID) **(画像を拡大するには、ここをクリックします)

ローカル アカウントの RID はこの SID に基づいているので、システムのディスク複製や単なるバーチャル マシン イメージのコピーを実行したときに発生する問題は、比較的わかりやすいと思います。SID を変更しないと、各 Windows システムの一意性を維持する主要なコンポーネントのコピーをそのまま使用することになります (Sysprep のタスクは他にもありますが、SID の変更は Sysprep の主要なタスクです)。システム A とシステム B の Administrator の SID が同じである場合、まったく同じユーザーが各システムに正当に存在することになります。システム B のローカル アカウントがシステム A に対して認証を行う場合、およびその逆の場合も、同じことが当てはまります。さらに悪いことに、これらのシステムの SID は、まったく同じものとして Active Directory® で認識されます。そのため、システム A にドメイン リソースへのアクセスを許可し、システム B には許可しなかった場合、矛盾が生じます。B を拒否するように設定すると、実際は A も拒否されます。

したがって、特に仮想システムのシナリオでは、あまりにも簡単にシステム イメージを展開できてしまうため、必ず Sysprep を使用してシステム上の SID を再生成する必要があります。また、サードパーティ製の SID 変更ツールは使用せず、Sysprep を使用するようにしてください。Sysprep は、マイクロソフトが設計、テスト、およびサポートを行っている、システム (仮想システムを含む) を複製用に準備するためのツールです。図 2 は、システム上の SID を変更する前の Sysprep の画面の例を示しています。次の手順としてシステムの複製の準備を行う場合、必ず [セキュリティ識別子を再作成しない] チェック ボックスをオフにしてください。

図 2** 複製の準備を行う場合は [セキュリティ識別子を再作成しない] チェック ボックスをオフにする **

Sysprep を使用すると、SID が新しい ID に更新されるだけでなく、Sysprep が認識したすべてのプライベート データ ストアに SID とコンピュータ名の変更が反映されます。また、暗号化も新しい SID で機能するように変更されます。たとえば、スケジュールが設定されたタスクのデータ ストア、IIS メタベース内の値 (IIS がインストールされている場合) などが変更されます。

また、Sysprep を実行すると、システム上のすべての NIC とその NIC 用のネットワーク構成データも強制的に削除されます。ネットワーク構成はレジストリ内の NIC に "ぶら下がった" 階層にあり、この NIC の関係 (仮想システム間の移動でなければ壊れることが多い) は NIC のハードウェア ID に基づいているため、Sysprep を実行すると、従来は残ったままになっていたこのデータが削除されます。

また、Sysprep を実行すると、システムから Active Directory のメンバシップに関する情報がすべて削除されます。したがって、Sysprep を実行すると、処理の一環として、システムは強制的にドメインから削除されます。これにより、SID が新しくなったシステムは、安全にドメインに参加できます。一部の SID 変更ユーティリティでは、コンピュータをドメインから削除することなくコンピュータの SID を変更できますが、この方法は信頼性と安全性に欠けています。やむを得ず、ドメインに参加しているコンピュータで Sysprep を実行する必要がある場合は、Sysprep を実行する前にこのコンピュータをドメインから削除するか、Sysprep を実行してこの作業を行います。

これに関連しますが、ドメイン コントローラ (DC) を仮想化する場合は、DC に昇格しておらず、ドメインにも参加していない、スタンドアロンのサーバー システムを複製する必要があります。Windows Server 2003 Small Business Server Edition を除き、DC を安全にディスク複製することはできません。新しい DC を安全に作成するには、ドメインに参加して DC に昇格する準備が整っているサーバーのディスク イメージを作成する必要があります。Sysprep を使用しても、DC 上の SID が安全に変更されない可能性があります (単一フォレストで単一サーバーという非常に特殊な SBS インスタンスの場合を除きます)。

最後に、Sysprep を実行すると、SID が変更され、コンピュータがドメインから削除されるだけでなく、コンピュータの名前も変更されます。

仮想システムのイメージを作成する場合は (または、単に仮想システムをコピーする場合でも) 上記の作業をすべて実行する必要があると言うと、過酷に思われるかもしれません。しかし、特にこれらのシステムをネットワーク上で他の物理システムや仮想システムと共に使用したり、ドメインで使用したり、ネットワーク上でこれらのシステム自体のコピーと共に使用する場合、上記の作業は不可欠です。

仮想システムの複製に Sysprep を使用しなかった場合、ほぼ確実に、言わずと知れたいくつかの問題 (Active Directory ネットワークやその他のネットワークでの競合) や、多くの予期しない問題が発生するでしょう。たとえば、仮想イメージはハッキングの被害を非常に受けやすいという特徴があります。これは、1 つの仮想イメージのハッキングに成功した場合、他の仮想イメージにもアクセスできるようになるためです。

ドライバとハードウェア アブストラクション レイヤ

仮想イメージに含まれる仮想デバイスのドライバが Windows に付属していない場合もあるということは既に説明しました。異なる記憶域バス ドライバを使用するコンピュータに仮想イメージを移動すると、物理ハードウェアを扱うときと同じように、非常に簡単に恐怖の 0x0000007B ドライバ エラーが発生するため、展開を行う (Sysprep を使用してディスク イメージを展開する) 際は、使用しているデバイス用のドライバを用意しておいてください。同じことが NIC にも当てはまります。ほとんどの仮想化製品は、ある程度汎用的な仮想デバイスを提供するように設計されていますが、追加のドライバが必要になる場合もあります。

また、厄介なハードウェア アブストラクション レイヤ (HAL) も無視することはできません。使用している仮想化テクノロジでサポートされている場合は、Advanced Configuration and Power Interface (ACPI) マルチプロセッサ (intel.com/technology/iapc/acpi を参照してください) がサポートされているバーチャル マシンを作成することが理想的です。通常、HAL 間での変換はサポートされていません (詳細については、support.microsoft.com/kb/309283 を参照してください)。しかし、一部の仮想化テクノロジでは (さらに重要なことに、多くの移動テクノロジでは)、ACPI に対応していない Windows インストールを ACPI に対応しているインストールに安全に移動でき、その逆も可能であることを保証しています。これは真実ではありません。さらに、このようにして移動した Windows インストールで問題が発生した場合、マイクロソフトによるサポートを受けることはできません。つい先ほど紹介したサポート Web ページで説明されている制限は、仮想化されたシステムにも当てはまります。図 3 は、私のバーチャル マシン (この例では ACPI ユニプロセッサ HAL を使用して実行されています) のデバイス マネージャで HAL を確認したときの画面を示しています。ここではユニプロセッサ HAL を使用していますが、マルチプロセッサ HAL に変更することもできます。

図 3** バーチャル マシンのデバイス マネージャで確認した HAL **(画像を拡大するには、ここをクリックします)

その他の変更点

変更できるものは変更し、変更できないものは受け入れる

物理システムから仮想システムへの移動、またはその逆の作業を検討する場合、変更できるものとできないものを念頭に置いておく必要があります。Windows インストールの変更できる側面を次に示します。

• HAL (ただし、ユニプロセッサ システムからマルチプロセッサ システム、またはその逆の移動を行う場合のみであり、さらに両者が同じ電源構成に基づいている必要があります)。
• 大容量記憶域コントローラ (これは簡単なことではありませんが、物理システムから仮想システムへの移動を行う多くのソリューションは、既にこの操作の実現を試みています)。ほとんどのベンダは、IDE 記憶域と SCSI 記憶域用のソリューションを提供しています。IDE から SCSI に、または SCSI から IDE に変更する作業はあまり簡単ではないため、展開を行う際にはどちらかを適切に選択してください。通常、SCSI を選択する方が、デバイスの信頼性は高くなります (これは、ほとんどのベンダの SCSI デバイス エミュレーションの実装に当てはまります)。
• ネットワーク コントローラ (ただし通常、仮想システムから仮想システムへの移動を行う場合、特定のベンダが提供するテクノロジ内では同じものが使用されます)。

Windows インストールの変更できない側面を次に示します。

• HAL (同じ電源構成が使用されており、前述の状況に当てはまる場合を除きます)。この HAL を変更する移動ソリューションを使用した場合、Windows インストールの安定性や信頼性は保証されないと考えてください (さらに重要なことには、このような Windows インストールはマイクロソフトによってサポートされません)。

SID とコンピュータ名を変更するだけでなく、使用している仮想コンピューティング テクノロジに固有の値も変更する必要があります。特に、MAC アドレス (ネットワーク デバイスの一意の ID) を変更する必要があります。また、多くの仮想アプリケーションも、それぞれ一意の識別子を持っています。ほとんどの場合、これらの識別子は、それぞれのコンピュータの構成ファイルに格納されているため、これらのエントリを編集する方法 (および有効性を維持する方法) を知っておくとよいでしょう。Pre-Boot Execution Environment (PXE) がサポートされている多くの仮想化製品では、それぞれの一意の ID に基づいて SMBIOS UUID を指定し、ドメインに参加する場合にこの ID を変更する (または、使用している仮想化ソフトウェアで変更できる場合はそのソフトウェアを使用して変更する) ことの必要性が強調されています。変更しなかった場合、(GUID が競合して) WDS クライアント システムまたは RIS クライアント システムを管理できなくなる可能性があります。私が使用したことがあるほとんどの仮想化ソリューションでは、MAC アドレスが重複した場合、深刻なネットワークの問題が発生しました。このため、単にバーチャル マシンを移動するだけでない場合、仮想化ソフトウェアによって MAC アドレスが変更されないときは、自分で変更することが非常に重要です。

仮想システムを展開用に準備する際に注意が必要なその他のコンポーネントは、リンクされているディスクやスナップショットです。使用している仮想化ソリューションによっては、これらが差分ディスクと見なされたり、別の名前が付けられる場合もあります。しかし、Sysprep を実行してシステムを準備し、その仮想システムのスナップショット (または元に戻すことが可能な状態のその他のファイル) を作成した場合、イメージの複製時にイメージの安全性、信頼性、およびセキュリティを維持するには、それらのスナップショットを破棄する必要があります。スナップショットまたはその他の "ディスクの変更を取り消す" 機能を使用するテクノロジでは、あるバーチャル マシンから作成されたシステムを特定のスナップショットが適用される前の状態に戻すと、同じバーチャル マシンから作成された複数のシステムと競合する可能性があります。また、元のバーチャル マシンの状態が戻された場合は、元のバーチャル マシンとも競合する可能性があります。このため、スナップショットや差分ディスクの関係がすべて反映されたシステムに対して Sysprep を実行しておく必要があります。

最適化

ほとんどの仮想化テクノロジには、ホストからゲストを操作する際のパフォーマンスとエクスペリエンスが強化される、バーチャル マシン追加機能またはツールが含まれています。多くの場合、マウスとキーボードによる入力の最適化などのパフォーマンスを向上させる機能や、コピーと貼り付け操作 (またはホストからゲストに対して実行するその他の操作) を強化する機能などが提供されます。仮想システムを展開する前に、これらのツールの最新バージョンをインストールするようにしてください。

また、クライアントのメモリはゲスト OS に最も適した構成にする必要がありますが、展開先のホストのことも考慮する必要があります。最も避けた方がよいことは、1 GB の RAM を使用するように設定した Windows XP イメージを、最初から RAM が 1 GB も搭載されていないホスト システムに展開することです。

また、現在のほとんどの仮想テクノロジに適用される制限も覚えておいてください。ユーザーは、仮想システムに接続されている周辺機器の操作方法だけでなく、ゲスト OS 上で動作するアプリケーションと動作しないアプリケーションを認識しておく必要があります (たとえば、ほとんどの仮想テクノロジでは、DirectX 9 や DirectX 10 がサポートされていないか、古いバージョンが制限付きでサポートされています)。ユーザーは、この制限が何を意味するのか、またはどのような状況で発生するのかを知らない場合があります (このような障害に適切に対処できないアプリケーションもあります)。

ホストについての考慮事項

通常、ゲストで実行されているのが完全なオペレーティング システムであるか、ハードウェアのすぐ上のレイヤで実行されるタイプ 1 ハイパーバイザであるかにかかわらず、仮想化テクノロジを実行しているホスト PC について気にする必要はほとんどありません。ほとんどの仮想化テクノロジは、ゲスト OS がホストについてまったく (またはほとんど) 知らなくてもよいように設計されています。ただし、あるホストから別のホストに移動したゲストで問題が発生した場合は、使用しているホストが何であるかを知っておいてください。また、使用している仮想化ベンダの製品に特定のプラットフォームで適用される制限も知っておいてください。あるプラットフォームから別のプラットフォームに移動することはできても、その過程で、ホスト OS のタイプ 2 ハイパーバイザ (仮想化アプリケーション) で提供される特定の機能が失われたり、使用できるようになったりすることがあります。

その他の展開メカニズム

Sysprep の関連リンク

Sysprep の詳細については、次のドキュメントを参照してください。

• Sysprep を使用したイメージ ベースのインストールを設計する
• Sysprep ツールを使用して Windows XP の展開を自動化する方法
• システム準備ツール (Sysprep.exe) を使用してディスクの複製を実行する方法
• 異種コンピュータでシステム準備ツールを使用する

仮想システムの展開方法としてすぐ思い浮かぶ選択肢は Sysprep やディスク複製の使用 (または単に Sysprep を実行し、バーチャル マシンをコピーするという方法) ですが、他にも選択肢はあります。Windows PE を使用する場合、イメージングとセットアップのどちらを使用するにしても、物理コンピュータよりも仮想化を利用した方が作業が簡単になる可能性があります。これは、物理的な CD-ROM ではなく ISO ファイルを使用して作業するためです。一部の仮想化テクノロジでは DVD メディアを適切に処理できないので、サポートされているかどうかを仮想化ベンダに確認してください。winnt32 または setup.exe (Windows Vista または Windows Server 2008 の場合) を使用することもできますが、特にメリットはありません。Automated Deployment Services など、その他のマイクロソフトの展開テクノロジを使用すると、仮想化テクノロジで PXE がサポートされ、RIS や WDS を利用しているかのようにネットワーク ベースの展開を開始することができます。

移行

最後に、実際に PC 全体を移動することに加えて、ユーザー状態移行ツール (USMT) を実行することも忘れないでください。USMT を使用すると、物理クライアントから新しいバーチャル システムに、ユーザーの設定を簡単に移行することができます。このため、ユーザーが古いデータや設定を新しいバーチャル マシンに移行する必要がある場合、管理者は、ファイルや設定を Windows XP から取得し、それを UNC 共有に格納し、新しいバーチャル マシンに格納する、といった手順で簡単に移行することができます。

Wes Miller は、テキサス州オースティンに住んでいます。以前は、オースティンにある Winternals Software に勤務しており、その前はマイクロソフトで Windows のプログラム マネージャとプロダクト マネージャを兼任していました。Wes の連絡先は、technet@getwired.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.