デスクトップ ファイルWindows 展開サービスをカスタマイズする

Wes Miller

目次

既存テクノロジの代わりに使用する
WDS を使用した展開プロセス
ネットワーク ブート プログラム
WDS PXE プロバイダ
TFTP デーモン
ブート構成データ ストア
Windows PE
トランスポート サーバー
カスタム マルチキャスト
まとめ

この記事では、3 か月にわたって Windows 展開サービス (WDS) を紹介してきました。初回は WDS の誕生について、2 回目では概要を紹介し、3 回目では WDSUtil やマルチキャストなど、いくつかの高度なトピックについて紹介しました。このシリーズの最終回となる今月の記事では、組織のニーズに合わせて WDS をカスタマイズするポイントとその方法を紹介します。マイクロソフトが提供する多くのツールには、ユーザーが構成できる要素が組み込まれています。ですが、重要なのは、そのツールがニーズを満たすかどうか、そのシナリオでツールを使用するにはツールをカスタマイズする必要があるかどうかを判別することです。

既存テクノロジの代わりに使用する

最近、読者の皆さんから「x (既存の展開テクノロジ) を使用していますが、その代わりに WDS を使用することはできますか。また、WDS には x に対応したパリティ機能はありますか。」という質問がよく寄せられます。Automated Deployment Services (ADS) の廃止により、「大容量サーバーを迅速に展開または再準備するのに WDS を使用できるのか」ということが最大関心事項の 1 つになっています。

WDS は、ADS に完全に対応した後継テクノロジとしてデザインされたものではありません。実際、完全に対応した後継テクノロジとして見なすには、いくつかの主要コンポーネントが不足しています。ですが、少し手を加えれば、WDS を ADS の後継テクノロジとして使用することは可能です。同様に、既定の構成を使用した場合に、WDS の動作がご使用の環境に適していなければ、WDS の多くのコンポーネントは別のテクノロジに置き換えることができます。それに伴う作業の複雑さと作業量は、対象のコンポーネントと代替テクノロジによって異なります。次は、WDS を使用した展開について見てみましょう。カスタマイズできるコンポーネントを紹介し、カスタマイズする方法を説明します。

WDS を使用した展開プロセス

図 1 は、WDS を使用した展開プロセスのコンポーネントの一覧です。このプロセスの各ステップは、カスタマイズすることができます。各ステップには、私の個人的な見解に基づいて色付けをしました。これは各ステップを代替テクノロジに置き換えたり、カスタマイズしたりする作業の複雑さ (通常は、開発スキルの難易度) を示しています。青色が濃いほど、そのステップをカスタマイズする難易度は高くなります。

図 1 WDS のカスタマイズ難易度

各ステップをカスタマイズする際の実際の難易度は、チームのスキル (開発スキルまたはスクリプト作成スキル) と WDS、Windows Imaging Format (WIM)、Active Directory、統合する必要がある他のテクノロジ (SQL、ADSI など) に関する理解度に左右されます。今度は、各ステップをカスタマイズする方法やカスタマイズに使用するテクノロジを詳しく見てみましょう。

ネットワーク ブート プログラム

WDS で提供されているネットワーク ブート プログラム (NBP) の代わりにカスタム NBP を使用しなければならないことはまれですが、カスタム NBP を作成することは可能です。WDS には、ヘッドレス システム (通常、サーバー) や F12 キーの入力を必要としたり必要としなかったりするシステムなどで使用できる NBP が同梱されています。このような NBP は、WDSUtil を使用して Active Directory にプレステージするか、または Startrom.com をプレステージされていない全システムに使用する NBP に置換することができます (たとえば、すべてのシステムがヘッドレスである場合や F12 キーの入力を必要としない場合などです)。

残念ながら、カスタム NBP の作成方法に関する資料はあまり多く提供されていません (参考情報については、msdn.microsoft.com/library/bb870970.aspx を参照してください)。また、NBP は、非常に小規模な 16 ビットの実行可能プログラムですが、厳しい制限があり、開発には特殊なプログラミング スキルが必要です。ですから、非常な特殊な要件を満たす必要があり、かつ開発チームにカスタム NBP の開発に必要なスキルを持ったメンバがいる場合を除き、通常、WDS で提供されている既存の NBP を使用することをお勧めします。

WDS PXE プロバイダ

リモート インストール サービス (RIS) に関しては、ユーザーから、クライアント システム情報の管理に Active Directory 以外のデータ ソースを使用することを希望するフィードバックが多く寄せられており、その多くは SQL Server を使用したいというものでした。WDS には、Pre-Boot eXecution Environment (PXE) プロバイダに対応したプラグ可能なインフラストラクチャが備わっています。つまり、WDS では、(開発作業は必要になりますが) PXE 情報を格納するデータ ソースとして、Active Directory 以外のテクノロジを使用できるということです。

WDS には、Active Directory を使用するプロバイダが用意されていますが、System Center Configuration Manager (SCCM) が WDS に統合されるようになり、SCCM では独自のプロバイダが実装されています。カスタム プロバイダを記述する方法に関する資料は非常に少なく、サンプル コードもあまり提供されていません (ただし、Windows SDK では、いくつかの資料とサンプルを提供しています)。そのため、カスタム プロバイダを記述するのは、控え目な方には向かない作業です。繰り返しになりますが、このブート プロセスに関して非常に特殊な要件がない限り、カスタム PXE プロバイダを作成することはお勧めしません。

TFTP デーモン

WDS が登場するまで、独自の簡易ファイル転送プロトコル デーモン (TFTPD) を使用しているユーザーは多数存在していました。ですが、PXE サーバーは適切に連動しないため、1 台の PXE サーバーを使用せざるを得ないというのが現状でした。

私の経験上、これは、既存の TFTPD (通常、Linux ベースの TFTPD) を使用して、他の OS を起動するように誘導するということでした。RIS で採用されていた初期のインフラストラクチャでは、これを行うことはできませんでした。ですが、RAMDisk によるブートが一般的に使用されるようになると、これが可能になりました。また、WDS ベースのブート イメージを使用して、このような処理を行うことも依然として可能です。

ここで注意点が 1 つあります。それは、TFTPD を使用するということは、マイクロソフトが技術的なサポートを提供していない分野に足を踏み入れていて、診断が困難な問題がほぼ確実に発生するということです。また、WDS で提供されている強化された TFTPD を使用すると、パフォーマンスが低下する可能性があります。理想的には、既存のサーバーを現状に合わせて調整するのではなく、WDS に用意されている TFTPD を使用し、PXE タイムアウト、プレステージ、ネットワーク エッジを使用して、どのクライアントがどの PXE サーバーからブートするのかを定義することをお勧めします。

ブート構成データ ストア

RIS では、ブート レベルでブートするものを指定することはできず、OSChooser を使用して、オプション (セットアップ、Windows PE (Windows プレインストール環境)、その他) を選択する必要がありました。WDS では、ネットワーク ブートで完全な OS ローダーを使用しているので、クライアントに提供しているブート構成データ (BCD) ストアのカスタマイズがサポートされます。各アーキテクチャの既定の BCD は、RemoteInstall\Boot\<arch>\Default.bcd に格納されています。<arch> の部分は、ブートするシステムのアーキテクチャ名になります。

この BCD はクライアントごとにカスタマイズすることが可能で、クライアントはカスタマイズした BCD を使用してブートできます。たとえば、セットアップを開始する BCD エントリ、Windows 回復環境 (RinRE) を実行する BCD エントリ、およびメモリ テストを実行する BCD エントリを作成することが可能です。また、完全に自動化されたセットアップ用の BCD エントリを既定のエントリとして指定し、手動セットアップ用の (セットアップ動作をカスタマイズする) BCD エントリをユーザーが選択できるオプションとして提供することもできます (詳細については、「Bcdedit を使用して BCD ストアを変更する方法」(go.microsoft.com/fwlink/?LinkId=115267) を参照してください)。

もちろん、WDS による複雑な処理の大半は Windows PE で行われます。ですから、ニーズに合わせて Windows PE をカスタマイズすることは、カスタム設定を実現するうえで重要です。WDS には、セットアップ向けの非常に汎用性の高いテンプレートが用意されています。このテンプレートでは完全なセットアップ エクスペリエンスが提供されます。ただし、展開のニーズによっては、このテンプレートが適さないことがあります。その場合は、独自の Windows PE ブート イメージを作成できます。では、この作業について最初から見ていきましょう。

BCD を使用すると、使用するイメージを指定できるだけでなく、Active Directory でコンピュータのコンピュータ アカウント オブジェクト (MAO) をカスタマイズして、イメージを指定することもできます。RIS では、特定の MAO 属性に各項目 (使用する Startrom と無人セットアップ用の .SIF ファイル) が格納されていました。WDS では、このような情報は、netBootMirrorDataFile という名前のエントリに名前と値の組み合わせとして格納されます。たとえば、特定のコンピュータで使用するブート イメージと無人セットアップ ファイルは、このエントリに格納されます。このエントリは、名前と値の組み合わせがセミコロンで区切られた形式で記載されます。ブート イメージと無人セットアップ ファイルを変更する場合は、それぞれ BootImage および UnattendFilePath というエントリを変更します。

もちろん、既存のセットアップ エクスペリエンスを一切使用せずに、独自のセットアップ エクスペリエンスを提供したい場合もあるでしょう。また、より詳細な構成を行ったり、さらに自動化したり、SQL Server によって自動的に作成されるビルドが必要になったりする場合もあるでしょう。さらには、初期の RIS と Windows PE を使用していたときのユーザーと同様に、セットアップ用に独自のフロント エンドを構築することを必要とする方もいるでしょう。どのようなセットアップ エクスペリエンスを提供する場合でも、以下の作業が必要になります。

• 各コンピュータまたは各ユーザーの情報を取得する。この情報はユーザー入力、SQL Server、テキスト ファイルなどから入手できます。
• セットアップ イメージをクライアント システムにコピーして適用する。この作業は、セットアップを直接使用するか、ImageX を使用してネットワーク共有のイメージを適用するか、またはマルチキャストを使用して (単に ImageX を使用してイメージをコピーして適用) 実行できます。
• セットアップを完了するための無人セットアップ ファイルを提供します (使用するファイルは展開する Windows のバージョンによって異なりますが、Unattend.xml や sysprep.inf です)。
• セットアップ後に行う移行手順を自動化する (Windows Server 2008 の場合は、役割を適用する手順を自動化する必要があります)。

ADS では、繰り返し実行できる手順を複数台のコンピュータに割り当てられるようにするタスク シーケンスという概念が導入されました。ADS は、Windows XP での使用を想定してデザインされておらず、Windows XP はサポートされていないので、Windows XP の展開に ADS を使用することはできませんでした。しかし、ADS のタスク シーケンスは、単なる構造化されたスクリプトなので、カスタム セットアップ プロセスを使用して同じ手順を実行することができます。

私は、長期にわたって Microsoft SQL Server を好んで使用してきたので (SQL Server 6.5 から使用しています)、この構造の実現に SQL Server を使用することにしました。もちろん、これには Windows PE のビルドに SQL Server の機能を追加する必要があります。また、独自の GUI (HTML アプリケーション (HTA) またはコンパイル済みの実行可能ファイル) を記述するか、Windows Script Host (WSH) を使用して、コマンドラインのみの必要最低限のセットアップ エクスペリエンスを実現できます。HTA や WSH を使用する場合にも、これらを Windows PE に追加する必要があります。

独自のセットアップ エクスペリエンスのデザインの難易度は、皆さんがお持ちのスキルと想像力によって大きく異なります。SQL Server と WSH または HTA のどちらかだけを使用して定義した非常にすばらしいシステムは実在します。また、これらのスキルは比較的習得しやすいものです。ただし、このシリーズの記事で説明した次のような制限事項に留意することが非常に重要です。

• Windows PE では、Windows on Windows (WOW) サブシステムがサポートされていないので、サポートするアーキテクチャごとにコンパイルする必要があります。
• x64 版または IA64 版の Windows PE を使用して展開する必要がある場合、Visual Basic 6.0 は使用できません。
• Visual Studio 2005 または Visual Studio 2008 を使用してアプリケーションを作成することは可能ですが、Windows PE では、どのバージョンの Microsoft .NET Framework もサポートされていないので、Visual C++ アンマネージ アプリケーションを作成する必要があります。
• .NET Framework を使用できなければ、Windows PowerShell を使用して自動化を実現することもできません。

もちろん、独自のセットアップ エクスペリエンスを実現するために、WDS でサードパーティ製のイメージ作成ユーティリティを使用することも可能です。大半の展開シナリオには WIM 形式と ImageX を使用して対応できると思いますが、ある特定の要件を満たすのに既存のイメージ作成ツールが適している場合もあります。

同様に、特定のシナリオでは、特殊なパーティション分割が必要な場合もあります。たとえば、BitLocker を使用して Windows Vista を展開していたり、Windows XP システムを構築していて、別のボリュームにプロファイル データを格納していたり、Windows Server システムを展開していて、同じディスク上にある別のボリュームにログを記録したりする場合などが、これに該当します。このような処理を行うには、DiskPart を自動化する必要があります。これは以前のバージョンと同様に、実行する必要があるコマンドと DiskPart を終了するための exit コマンドが最後に記載された任意のファイル形式のスクリプトを DiskPart に渡すことで行えます。

カスタム セットアップ エクスペリエンスを構築するということは、基本的にセットアップ実行可能ファイルを再構築する (少なくとも、その機能を再現する) ことになり、相当量のデザインと構築作業が伴うため、気が弱い方には向かない作業です。実際の作業の難易度は、どの程度の機能を組み込み、そのセットアップを何で (HTA、WSH、コンパイル済みのプログラミング言語) 構築するかによって異なります。

トランスポート サーバー

Active Directory など、WDS の組み込み機能の大半を使用していなかったり、独自の完全なカスタム ソリューションを構築している場合は、トランスポート サーバーを使用すると、面倒な要件を発生させることなく、ニーズを満たせることがあります。図 2 の表に、WDS のトランスポート サーバーの役割に含まれているものを示します (この表は、「トランスポート サーバーを使用する」(go.microsoft.com/fwlink/?LinkID=115298) からの引用です)。

図 2 展開サーバーとトランスポート サーバー

トランスポート サーバーの実装が困難であると言うのは、このサーバーの役割自体が複雑だからではありません。この役割自体は簡単に展開できます (図 3 参照)。追加の作業が必要で困難なのはトランスポート サーバーに関連するカスタム セットアップの実装です。トランスポート サーバーの役割を適切に使用すると、WDS の役割に組み込まれている使いやすさが失われます。

図 3 トランスポート サーバーはカスタム展開シナリオに適している場合がある (画像をクリックすると拡大表示されます)

カスタム マルチキャスト

トランスポート サーバーの役割を使用しているかどうかに関係なく、複数のシステムを展開している場合には、マルチキャストを使用すると役に立つことがあります (ただし、この役割を使用している場合は特にマルチキャストが役立ちます)。ADS では、強力なマルチキャスト機能がサポートされていました。WDS をマルチキャストと組み合わせて使用すると、この機能を再現できます。WDS 自体でも、マルチキャストをサポートしていますが、独自のカスタム ソリューションを作成している場合は、先月ご紹介したように WDSMCast を使用してマルチキャストを使用できます (図 4 参照)。ただし、展開するイメージ ファイルは、転送して適用する必要があることに注意してください。通常、これは、ローカル ディスクに、イメージを格納して適用するのに十分な領域を確保する必要があるということになります。

図 4 WDSMCast の実行 (画像をクリックすると拡大表示されます)

まとめ

WDS は単独で使用した場合にも、多くの組織のニーズを満たせる優れた機能を提供します。ですが、WDS の境界を越えた独自のソリューションを作成する必要がある場合は、それも可能です。その障害となるのは、あなたの想像力、スケジュール、そしてスキルだけです。

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