デスクトップ ファイルWindows のネットワーク ブートを実行する

Wes Miller

目次

PXE のしくみ
RIS について
WDS の始まり
その他の機能
まとめ

これから数か月にわたり、Windows 展開サービス (WDS) について取り上げます。WDS は、Windows Server 2003 用に別途提供されており、Windows Server 2008 には組み込まれています。WDS は展開インフラストラクチャにおける非常に重要なコンポーネントになる可能性があるので、このシリーズで、WDS の基礎を皆さんに理解していただきたいと思っています。この

第 1 回目のコラムでは、Preboot eXecution Environment (PXE、ピクシーと発音します) のアーキテクチャ、リモート インストール サービス (RIS) の歴史、およびマイクロソフトで使用されているその他の PXE 関連テクノロジについて説明します。

RIS は、2001 年に私が Windows コア OS グループに移ったときに引き継いだテクノロジの 1 つです (RIS は複雑で、BIOS の実装やハードウェアに依存するので、少しびくびくしながらこのテクノロジを引き継ぎました)。ですが、RIS は、私がプログラム マネージャを務めていたときに、Windows® PE と共に最も楽しんだテクノロジの 1 つでもありました。

一連の 3.5 インチのディスクを使用して、Windows 3.0 を初めてインストールしたときのことを思い出します。やがて、起動可能な CD (Windows 98 の一部のバージョンに含まれていました) によって、インストール作業はより簡単になりました。ただし問題もあり、インストールを実行するには、ローカル ハード ディスクだけでなく、必ず特定の種類のローカル メディアが必要でした。

長年の間、Windows のネットワーク ブートを実行する機能 (つまり、ハード ディスクを使用せずに、ネットワーク経由で Windows を完全にブートする機能) を求める意見がユーザーから頻繁に寄せられていました。初期の Windows では、この機能が備わったバージョンも提供されていましたが、Windows NT® ではこの機能が提供されませんでした。Windows Server® 2003 と Windows Server 2008 の最新バージョンは、iSCSI イニシエータを使用して起動できますが、完全にローカルで処理が実行されるわけではない (つまり、常にリモート ドライブをブート ドライブとして使用する) ので、初期の Windows で提供されていたネットワーク ブートとはまったく異なります。

クライアントの事前準備を行う

• RIS クライアントの事前準備プロセスを評価する
• 事前準備が完了したクライアントを使用してネットワーク セキュリティを強化するための計画
• クライアント コンピュータの事前準備を行う
• オペレーティング システムのリモート インストール

Windows 2000 から、マイクロソフトは、ネットワーク ベースのインストールを可能にする、後に RIS と呼ばれるテクノロジの開発を始めました。RIS の目的は、PXE を使用してオペレーティング システム イメージをインストール先のコンピュータのローカル ディスクに配置するという、比較的わかりやすいものでした。

PXE のしくみ

図 1 は、PXE のブート シーケンスを示しています。PXE は Wired for Management イニシアチブの一部として Intel とその他のベンダによって開発された、比較的単純なプロトコルです。このプロトコルは、BOOTP から派生した動的ホスト構成プロトコル (DHCP) に基づいており、通常はネットワーク インターフェイス カード (NIC) に実装されています。簡単に言うと、次のような動作が行われます。

図 1 PXE のブート シーケンス (画像をクリックすると拡大表示されます)

手順 1 システム BIOS が起動し、起動順序が決定されます。

手順 2 PXE からの起動が、ハード ディスク、フラッシュ ドライブ、および CD-ROM よりも優先されている場合、またはこれらのデバイスがいずれも存在しない場合は、NIC から Universal Network Driver Interface (UNDI) が読み込まれます。NIC の特徴は、非常に小さなネットワーク デバイス ドライバと簡易ファイル転送プロトコル (TFTP) が実装されていることです (BIOS の実装にもよりますが、エンド ユーザーは、PXE ブートを行うために F12 キーを押すことを要求される場合があります。PXE ブートは標準的な動作ではないので、この動作を無効にする機能が提供されていると役立ちます)。

手順 3 システムによって単純なユーザー データグラム プロトコル (UDP) のブロードキャストが行われ、DHCP サーバーの検索が実行されます。実際にはこれが PXE のブート シーケンスの最初の手順であり、"Discover" と呼ばれます。プロトコルが UDP であることに注意してください。つまり、PXE の通信がルーターやスイッチを通過できるように、少し時間を割いて構成を変更する必要が生じる場合があります。

手順 4 DHCP サーバーがブロードキャストを受信した場合、それに応じてこの DHCP サーバーから IP アドレスが返されます。この手順は "Offer" と呼ばれます。ここで覚えておいていただきたいのは、PXE がステートレスであることによって、この時点でクライアントから提供される、システムに関する一意の状態情報の量がかなり限定されることです (MAC アドレスと、場合によっては System Management BIOS GUID (SMBIOS GUID) が提供されます)。

手順 5 クライアントが IP アドレスを含むパケットを受け取った後、追加情報 (つまり、PXE サーバーのアドレス) が必要であることを通知します。ここで、最初に応答した DHCP サーバーからの情報を含む、別のブロードキャストが行われます。このブロードキャストによって、追加情報 (具体的には、ネットワーク ブート プログラム (NBP) の場所) が必要であることが、クライアントから DHCP サーバーに通知されます。この手順は "Request" と呼ばれます。

手順 6 PXE サーバーから、PXE サーバーのアドレスと NBP の場所が返されます。NBP は、非常に小さいブート実行可能ファイルで、32 KB 未満である必要があります。この手順は "Acknowledge" と呼ばれます。楽しみながら手順を追っているうちに、DORA (Discover、Offer、Request、Acknowledge) という頭字語に気付いたと思います。これで、シーケンスの手順を簡単に覚えることができますね。

Microsoft DHCP および WDS をインストールしている場合 (またはその他のベンダによって提供されたテクノロジを使用している場合)、Request の手順は発生しません。実は、DHCP サーバーから最初に提供される Offer パケットには、PXE サーバーと NBP プログラムの場所が既に含まれています (このため、手順が 2 つ省略され、時間を節約できます)。

手順 7 先ほど説明した小さな TFTP プロトコル スタックを保持しているクライアントが、PXE サーバーによって指定されたネットワーク上の場所から NBP をダウンロードします。TFTP は、古くに策定された、非常に小さなステートレスのプロトコルです。TFTP は、セキュリティやパフォーマンスのために選ばれたのではなかったため、多くのルーター管理者は、セキュリティやパフォーマンスを考慮して、このプロトコルを既定で無効にします。しかし、PXE を動作させるには、TFTP を有効にする必要があります。

多くの PXE の実装 (RIS を含む) では、作業を継続するために、この時点でユーザーに F12 キーを押すよう求める機能が提供されますが、通常、PXE サーバーの管理者は、この機能を無効にすることができます。来月 WDS についてさらに詳しく説明するときに、マイクロソフトがパフォーマンスの向上を目的として Windows Server 2008 用 WDS の TFTP デーモン (TFTPD) に実装したいくつかの機能強化について説明します。

手順 8 NBP が初期化されます。RIS の場合は、Windows ブート ローダーが起動し、展開処理が開始されます。この処理では、PXE (少なくとも実際のブート レベルのプロトコル) はもう使用されません。

ここで覚えておく必要があるのは、PXE (RIS、WDS、またはその他のインフラストラクチャ) は、低速リンクや、衛星通信などの待ち時間の長いリンクでは、うまく機能しないことです。低速リンクでは、大量のデータが転送される可能性があり、待ち時間の長いリンクでは、単純に通信速度が遅く、通信を維持することもできない場合があります。

お気付きかもしれませんが、PXE のブート プロセスでは、クライアントが要求を送信するときに、「あなたは私の母親ですか」と具体的にサーバーにたずねることはありません。これは、単純に、ある PXE サーバーを特定できるほど多くの状態情報が提供されないからです。このため、通常は競合状態が発生します。この場合、最初にクライアントの要求に応答したサーバーが優先されます。いくつかの方法を使用すると、この問題の発生率を下げることができます。

• どれか 1 台の PXE サーバーの応答速度を調整します。サーバーの応答速度に影響を及ぼすのは、ネットワークの待ち時間とサーバーの処理能力です。実際に、以前マイクロソフトでは、Microsoft IT によって使用されていたサーバーの性能が非常に高く、たとえオフィス内に PXE サーバーが配置されていても、社内サーバーの方が先に応答することがありました。この場合は、事前準備が完了したクライアントへの応答でタイムアウトが一切発生しないように、ローカルの PXE サーバーを設定します。
• クライアントの事前準備を行います。この作業は、PXE サーバーを社内の他の IT サーバーよりも先に応答させる場合、非常に重要です。クライアントの事前準備を完了することによって、Active Directory® は実際に「私はあなたの母親です」と WDS や RIS に返答できるようになります。SMBIOS GUID は、Active Directory に登録されるシステムの一意識別子として非常によく使用されます。ただし、システムに SMBIOS GUID が実装されていない場合 (比較的古いハードウェアは、高い確率でこれに該当します) は、MAC アドレスに基づいた GUID を使用できます (また、そうする必要があります)。詳細については、補足記事「クライアントの事前準備を行う」を参照してください。
• PXE の通信がスイッチまたはルーターを越えないようにします。つまり、PXE サーバーを各セグメントに配置します。この方法の欠点は、実装と管理の両方に高い費用がかかることです (各サーバーに独自のイメージを配置する必要があります)。

RIS (および現在の WDS) サーバーは、Microsoft DHCP サーバーのように、関連付けられている Active Directory の実装に対して認証を受ける必要があります。この目的は、Active Directory にすべての PXE サーバーを認識させることによって、悪意のある PXE サーバーが原因で発生する問題 (PXE のブロードキャスト ストームなど) の数を減らすことです。

この方法で保護できるのは、Active Directory によって認識されるサーバーのみであることに注意してください。独自のドメインを設定しているか、Microsoft PXE 以外のサーバーを使用している場合、この方法を使用してサーバーを保護することはできません。

マイクロソフトでは、以前、非常に熱心な従業員が、RIS を使用しない "ゼロタッチ" 展開用の PXE サーバーを構成しました。この実装の動作では、ハード ディスクに格納されているデータが完全に消去され、新しいイメージが配置されます。隔離された (ネットワークに接続されていない) 環境で展開作業が行われていれば、問題は発生しなかったと思いますが、残念なことに、この展開作業はネットワークに接続された環境で行われました。このため、ハード ディスクよりも先に PXE が起動するように構成されていた、マイクロソフト幹部のコンピュータのディスクに格納されていたデータが消去されました。

これまで Microsoft IT では、F12 キーを押さなければ PXE ブートを実行できないようにサーバーを構成していたので、このような問題が発生したことはありませんでしたが、この PXE サーバーでは、待ち時間が発生せず、F12 キーを押す必要があることを示すメッセージや、なんらかの通知も提供されませんでした。つまり、この幹部社員のコンピュータと、移動ユーザー プロファイルによって保護されなかったすべてのデータは、事実上失われたことになります。

この話から、"ゼロタッチ" 展開を行う場合に、PXE サーバーを隔離するか、少なくとも F12 キーを押す必要があることを示すメッセージを表示することの重要性がおわかりいただけたと思います。

RIS について

私は、Windows 2000 がリリースされた後に、RIS を引き継ぎました。RIS に関して言えば、時代は Windows 2000 にやさしくはありませんでした。また、Windows Server 2000 の RIS は、テスト、パフォーマンス、およびその他の制約を理由に、Windows 2000 Professional の展開にのみ使用されました。残念なことに、サーバー製品は RIS を使用して展開できませんでした。Windows 2000 は x86 コンピュータでのみ使用できたので、1 つのアーキテクチャ上の 1 つの製品を前提とする RIS の実験台として適していました。RIS は、Active Directory と完全に統合されました (また、その必要がありました)。また、Microsoft DHCP サーバーにも RIS が適切に統合され、このサービスに固有の TFTPD も提供されました。

RIS は、Windows カーネルがセットアップ プロセスを開始できる状態になるまで、NBP を使用して TFTP ダウンロードを続行します (ある時点で、Windows からサーバーへの接続に使用されるプロトコルが TFTPD からサーバー メッセージ ブロック (SMB) に切り替わってからは、フロッピー ディスクを使用して開始される従来の Windows 2000 または Windows XP のインストールと同じリテラル コード パスが使用されます)。ネイティブ モードの Windows が初期化されると、Windows セットアップによって RIS の OSChooser (OSC) ウィザードが起動されます。

OSC の画面は、構成可能な HTML 2.0 のようなページです。これらのページは制約が厳しく、画像などを含めることはできません。また、ANSI 以外の文字を含めることもできません (そのため、一部のロケールでの Windows の展開が複雑になりました)。

最終的に、RIS によって RIS サーバー上に txtsetup.sif ファイルが作成されます。OSChooser ウィザードが完了すると、クライアントは "ソフト リブート" されますが、RIS サーバーと txtsetup.sif ファイルの場所は保持され、ソフト リブートの完了後に再度読み込まれます。この txtsetup.sif ファイルの内容は、基本的に unattend.txt ファイルと同じですが、RIS がセットアップ プロセスを完了するのに役立つ、その他のいくつかのフィールドが含まれています。

RIS では、従来の無人セットアップ (RISetup) と非常によく似たセットアップを実行することもできます。RIS では、Sysprep (RIPrep) と同様の複製ベースのインフラストラクチャが使用され、実際に Sysprep と同じコードが使用されます。ただし、RIPrep イメージを RIS サーバーにアップロードすることもできます。

その後、RIS にはいくつかの基本的な制限があることが明らかになりました。1 つ目は、サーバーを展開するためのサポートが提供されなかったことです。Code Red や Sasser などの特定の攻撃が発生したこと、および 2001 年 9 月 11 日の惨劇からの迅速な回復を目指す主要な顧客が IT に関する複雑な問題を経験したことから、マイクロソフトでは、既存の Windows 2000 RIS サーバーを使用して Windows Server を展開するソリューションの開発に急ピッチで取り組みました。このソリューションは Windows Server 2003 で提供するために開発されましたが、正式にはリリースされませんでした。

PXE に関連するテクノロジの詳細情報

• PXE クライアント、DHCP、および RIS サーバーの間で行われる、PXE に関する対話
• PXE を使用したオペレーティング システム展開の計画
• PXE のアーキテクチャ
• リモート インストール サービス
• オペレーティング システムのリモート インストール
• オペレーティング システムのリモート インストールに関するステップ バイ ステップ ガイド
• WDS PXE プロバイダ
• リモート インストール サービスとは
• Windows Server 2003 Automated Deployment Services

2 つ目は、RIS で OSChooser ウィザードを完全に自動化する機能が提供されなかったことです。この機能は、後に Windows Server 2003 の <META ACTION="AUTOENTER"> 要素によって提供されました。最後は、ANSI 以外の文字が使用された場合に OSChooser が正しく機能しなかったことです。これは、米国外のいくつかの顧客から指摘された重要な欠点です。

このため、たとえば、フランス語のキーボードを使用して RIS インストールを完了することはできませんでした。世界中のコンピュータの BIOS レベルで ANSI 以外の文字を正しく機能させることは非常に難しかったので、簡単にこの問題を解決することはできませんでした。

Windows Server 2003 のリリース時に、Intel Itanium アーキテクチャ、および Windows 2000 のすべてのサーバー製品と Windows Server 2003 のサポートが正式に追加されました。Windows Server 2003 は、x64 アーキテクチャのサポートによってさらなる発展を遂げました。

RIS の TFTPD も、パフォーマンスを向上させるために大幅に書き換えられました。Windows Server 2003 では、最大 75 台までクライアントを同時に起動できるようになりました。この上限に達するのは、SMB の帯域幅が、クライアントへのネットワーク トラフィックによってすべて使用されたときであることを覚えておいてください。

WDS の始まり

"Longhorn" (Windows Server 2008 のコード ネーム) 用の RIS の開発に取り組み始めたとき、私たちは一歩譲歩する必要があることがわかりました。以前のコラムで説明したように、私たちは既に Windows PE からのイメージ ベースの (WIM) セットアップに賭けていました。その譲歩の結果、PXE を使用して起動した Windows PE インスタンスからのイメージ ベースの展開という重要な理念が、WDS の基盤となりました。

また、Windows Vista® を展開するための共通プラットフォームとして Windows Server 2003 を使用できること、および下位の WDS に対応する "帯域外の" ソリューションが必要になることもわかりました。その結果、WDS を Windows Server 2003 SP1 で実行できるようになり、Windows Server 2003 SP2 に WDS が組み込まれました。

WDS は、RIS サーバー (レガシ モード)、ハイブリッド サーバー (混合モード)、または WDS 専用のサーバー (ネイティブ モード) として動作させることができるので、WDS を使用すると、当然の結果として、正式な WDS 形式の展開に移行できます。顧客から、RIS を Windows Server 2003 SP2 システムにインストールする方法はありますか、という問い合わせを受けたことがあります。そうですね、方法はあります。これを行うには、WDS をインストールし、レガシ モードで実行します。図 2 は、サポートされるオペレーティング システムを示しています。

図 2. 展開がサポートされるプラットフォーム

Windows Server 2003 SP1 および SP2 の WDS は、WDS への移行を開始することを目的としています。以前に説明したように、Windows Server 2008 の WDS で追加された主な機能は、書き換えられた TFTPD、拡張ファームウェア インターフェイス (EFI) ブートのサポート、そして言うまでもありませんが、マルチキャスト ベースの展開です。

その他の機能

マイクロソフトの別のチームによって、Automated Deployment Services (ADS) が構築されました。このサービスの最も重要な目標は、サーバーのプロビジョニングをすばやく実行することでした。ADS の特徴は、正式なセクタ ベースのイメージ作成、独自のブート エージェント (Windows PE よりも小規模ですが、すべての機能は提供されません)、独自の TFTPD、および非常に高度なマルチキャストです。ADS に組み込まれた機能は、ある程度 System Center Configuration Manager (SCCM) で提供されますが、すべての機能が提供されるわけではありません。

Windows XP Embedded では、独自の TFTPD を経由した RAMDisk への完全な PXE ブートが提供されましたが、この方法ではリモート展開は実行できません。このテクノロジは、PXE を使用して同じディスク イメージからさまざまなシステムを同時に起動できるように設計されました。

まとめ

この記事では、RIS の歴史を簡単に紹介しました。詳細については、補足記事「PXE に関連するテクノロジの詳細情報」を参照してください。来月は、WDS の基本的な知識について説明し、それ以降のコラムでは、WDS の高度な機能 (マルチキャストなど) を紹介します。そして最後は、WDS を使用せずに WDS を使用します (つまり既存の WDS とセットアップのエクスペリエンスを越えて、独自の展開手法を開発します)。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (www.CoreTrace.com) のシニア テクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。

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