Windows 7

  • [アーティクル]

Windows 7 の展開ガイド

Chris Adams

会社の規模によって、Windows 7 の展開は "かなり簡単" な場合もあれば、"気がおかしくなるほど複雑" な場合もあります。マイクロソフトにおける Windows 7 の展開は、気がおかしくなるほどとまでは行きませんが、それに近い作業になっています。しかし、System Center、Configuration Manager 2007 のオペレーティング システムの展開 (OSD) 機能、および間もなくリリースされるサービス パック 2 (SP2) を使用することで、展開プロセスを大幅に簡素化できます。どの企業でも Windows 7 を展開する際の複雑さの程度に関係なく、マイクロソフトの基本プロセスを使用することで、Windows 7 にすみやかに移行できます。

この記事では、マイクロソフト社内で Windows 7 を展開する際に使用した方法について説明します。マイクロソフトでは、どのようにして Windows 7 の展開ソリューションを開発したのか、また、同じツールを利用して皆さんの展開プロセスを簡素化する方法についても紹介します。

エンタープライズ デスクトップ展開シナリオについて

まず、新しい OS の大規模な配布を実現するために必要な要件とシナリオを評価する必要があります。デスクトップに配布するアプリケーションと異なり、オペレーティング システムを配布する場合はユーザーの生産性とデータに大きなリスクが生じます。そのため、多くの場合、OS を配布する際には、かなりの時間をかけて、現在の状況を確認し、問題が起きないプロセスを探りながら、リスクを最小限に抑えるようにする必要があります。マイクロソフトでは、280,000 台を超えるデスクトップに OS を配布する必要があったので、まさにこのような作業を行いました。

図 1. エンタープライズ デスクトップのディスク構成シナリオ

エンタープライズ デスクトップ ソリューションの開発で最も重視されるのは、ハード ディスク構成、暗号化テクノロジ、アプリケーション、およびユーザー データです (ハードウェア デバイスのドライバーも展開ではとても重要な要素ですが、この記事では取り上げません。マイクロソフト製ハードウェア デバイスのドライバーの展開を簡素化するために開発されたソリューションの概要については、TechNet のブログ記事 tinyurl.com/kog748 (英語) を参照してください)。

ディスクが単数と複数のどちらでも、Configuration Manager を使用して Windows 7 を展開する場合、デスクトップ構成は重要です。課題は、Windows 7 を新しいコンピューターのみに展開するのか、OS が既にインストールされているコンピューターに移行プロセスを介して展開するのかを把握することです。図 1 からわかるように、マイクロソフトでは、複数のパーティションを持つ単一のディスクまたは複雑なマルチブートやマルチディスク構成に対応するソリューションを開発する必要がありました。

マイクロソフト社内のデスクトップの多くは、Windows Vista を実行しています。また、一部の部門では Vista で導入された BitLocker 暗号化テクノロジの使用が義務付けられています。BitLocker 暗号化テクノロジでは、盗難や紛失に備えて、システム パーティションを暗号化して保護します。暗号化されたドライブで稼働している OS をアップグレードする場合、タスク シーケンスでは、この暗号化を無効または一時的に停止する必要があります。また、ほとんどのモバイル環境では暗号化テクノロジが必要であるため、モバイル環境用に開発するソリューションでは、暗号化のシナリオを考慮する必要があります。

すべての企業で紛れもなく、異論を挟む余地がない事実は、ユーザーが移行中に失われてはならないデータを持っていることです。Windows ユーザーに対しては、マイクロソフトは、ユーザー データの収集と復元を簡素化するためのユーザー状態移行ツールキット (USMT) を提供しています。Windows 7 では次世代の USMT (バージョン 4.0) が導入されています。これはバージョン 3.0 に対して大幅な機能強化が施されています。USMT 3.0 と 4.0 の最大の違いは、ユーザー状態を収集する適切なプロセスを選択することと、その状態を保存する方法にあり、これはまさにマイクロソフトで実施した展開シナリオの最後の部分のテーマです。

これまでのバージョンと異なり、USMT 4.0 はフル オペレーティング システム外で機能します。アップグレード後に復元するユーザー状態を収集する場合、フル OS を対象にすると、ファイルが使用中かロックされていることが多いので、いくつかハードルがあります。また、ウイルス対策ソリューションなどの他のアプリケーションも、データのバックアップ時にエラーの原因となる可能性があります。新しいバージョンのデータ収集プロセスは、Windows Pre-Execution (PE) などの環境においてフル OS 外で機能するため、実行中のサービス数、使用中のアプリケーション数、および開かれているユーザー データがあってデータを収集できないシナリオの数を大幅に削減できます。ユーザー状態を Windows PE から (オフライン バックアップを利用して) 読み込む機能は、Windows PE で実行される Configuration Manager OSD タスク シーケンスとスムーズに連動するので、ユーザー データのバックアップ プロセスを合理化します。

必要なユーザー データを収集したら、USMT では、移行中にこのデータを格納する場所が必要です。マイクロソフトでは、このユーザー データを格納する場所として多数の選択肢ありました。ただし、他の多くの企業の IT 予算では、同じようにさまざまな選択肢があるとは限りません。たとえば、一般的なマイクロソフト社内のユーザー状態のデータが約 1 GB だとします。このデータを後で取得できるように格納する場所としては、外付けハード ディスク、ファイル サーバー、および DVD などの光学式ドライブを利用できます。Configuration Manager 2007 を導入している企業では、状態移行ポイントの役割を使用して、移行処理中にリモート サーバーにデータを格納できますが、制限事項があります。

外部デバイスのコスト効率がよくない最大の理由は、ユーザー状態のデータと同じサイズの物理記憶域が必要になることです。つまり、マイクロソフトで外部デバイスを使用した場合、ユーザー ベースをサポートするために、280 TB の空き容量を用意する必要がありました。この方法は、ユーザー データの量を正確に測定できる場合にのみ適切です。そうでない場合は、科学的なプロセスではなくなり、結果は予想不可能で満足できないものとなるでしょう。

最も適切ではない選択肢は、移行対象のコンピューターを使用することです。これは最も論理的でコスト効率のよい方法に見えますが、技術的に難しい場合が多いです。というのも、この方法を使用するには、ユーザーのコンピューター上に、データをバックアップするために使用できる大量の空き領域が必要だからです。また、ユーザー データをディスク上のある場所から別の場所にコピーする必要もあります。ほとんどのベテラン IT ユーザーは知っていることですが、ハード ディスク上でのファイルの移動やコピーには時間がかかるので、結局、展開にかかる時間が長くなります。ユーザーの生産性を 1 日 (または数日) 奪うような展開は現実的ではなく、冒したくないリスクです。

USMT 4.0 では、以前のバージョンでは提供されていなかったハード リンクという機能のサポートが導入されています。ハード リンクによる移行では、ユーザー データを同じローカル コンピューター上に効率的に格納できるので、時間とディスク領域のどちらもわずかしか必要としません。

ハード リンクを使用するための唯一の要件は、ユーザーのコンピューターに 250 MB の利用可能な空き領域があることです。ハード リンクのサポートにより、ディスク上の物理ファイルを移動せずに、バックアップと復元を行えるようになります。USMT では、物理ファイルへのポインターのみを格納し、これらのポインターを復元時に使用するため、Windows 7 の移行にかかる時間を大幅に短縮しています (ハード リンクの詳細については、TechNet の記事 tinyurl.com/m76dxv (英語) を参照してください)。

このようにさまざまなシナリオを理解すると、Windows 7 への移行時に、さまざまなシナリオに取り組むためのアクション プランを立てやすくなります。

Windows 7 のための OS タスク シーケンスを構築する

要件とシナリオを理解すると、ソリューションの実装は、複雑な作業ではなくなります。ソリューションを構築する手順は、主に次の 3 つのカテゴリに分けられます。

  1. ユーザー エクスペリエンスの開発
  2. Windows 7 タスク シーケンスの構築
  3. ユーザー状態の移行

Microsoft IT では Modena というコード名のソリューションを開発しました。このソリューションでは、強力な OSD ウィザードを使用して 1 つ目のカテゴリをサポートし、エクスポートしたタスク シーケンスを使用して 2 つ目のカテゴリをサポートし、状態を移行するスクリプトを使用して 3 つ目のカテゴリをサポートする機能を実現しています。この次のセクションでは、Modena OSD ツールの使い方を簡単に説明します。このツールには、OSD ウィザード、エクスポートされたタスク シーケンス、およびスクリプトが含まれます。

OSD ウィザードを使用する

Configuration Manager の OSD は IT 管理者向けのツールです。そのため、OSD には組み込みのウィザードがなく、ほとんどの企業では独自のウィザードを開発する必要があります。つまり、Configuration Manager には、エンド ユーザーの入力を収集するためにすぐに使用できる機能がありません。これはマイクロソフト自体でも直面した課題でした。

マイクロソフトはユーザー主導の企業であるため、すべてのユーザーが管理者としてコンピューターを操作しています。

OS の一部の機能を使用できなくなるような Microsoft IT の決定には、多くのユーザーが難色を示しました。そのため、ユーザーにとって過度の負担や仕事の邪魔にならずに、ユーザーからできるだけ多くのデータを取得できる、非常に堅牢なユーザー エクスペリエンスを開発する必要がありました。

マイクロソフトでは、Modena OSD ウィザードで、この課題に対応しました。このウィザードは、マイクロソフト以外の企業でもお使いいただけます (OSD ツールの入手方法の詳細については、blogs.technet.com/osd (英語) を参照してください)。

Modena OSD ウィザードは、実行可能ファイルと構成ファイルの 2 つで構成されています。実行可能ファイル (OSDSetupWizard.exe) は、マイクロソフトが開発した自己完結型のユーザー エクスペリエンスです。このファイルは、コンピューターが Windows 7 に移行する準備ができているかどうかを検証し、エンド ユーザーの入力を収集することを目的としています。ウィザードの最終的な役割は、ユーザーの入力を受け取って、OSD タスク シーケンスの変数を設定することです。

このウィザードの特徴の 1 つは、プラグ アンド プレイのように動作することで、できる限り多くのシナリオで利用できるようにしていることです。この目標を達成するために、構成ファイルを利用しています。実際に、マイクロソフトのような複雑な環境では、/xml:{osdconffilename.xml} スイッチを使用することで、同じ実行可能ファイルをさまざまな構成ファイルと組み合わせて使用しています。

たとえば、マイクロソフトの展開では SCCM プログラム ウィザードの実行 (RAP) と Preboot Execution Environment (PXE) の両方のサポートが必要です。タスク シーケンスは同じですが、実行する環境 (RAP または PXE) に応じて 2 種類の構成ファイルを使用して、ウィザードの動作を変えています。構成ファイルにより、汎用的な展開パッケージを作成して、さまざまな構成に対応できます。

OSD ウィザードを紹介するために、まず、ウィザードのエンド ユーザー画面 (通称、ページ) について説明します。OSD ウィザードでは 8 ページが提供されます。ただし、各ページの状態は有効、無効、またはサイレントの 3 種類のいずれかになるため、この "提供される" という表現は広い意味で使用しています。有効な場合、ページはエンド ユーザーに表示され、無効な場合は表示されません。

サイレントは特殊で、OSD タスク シーケンスの変数が null でない限り、ページは表示されません。null の場合、そのページでは、ウィザードの処理を続行するためにユーザーに入力を求めます (OSD ウィザードの有効、無効、およびサイレントの機能の詳細については、TechNet のブログ記事 blogs.technet.com/osd (英語) を参照してください)。状況によっては、ある特定のページではエンド ユーザーの入力が必要ですが、その他のデータは不要な場合があります。

たとえば、多くの企業では、エンド ユーザーが各自のコンピューターに独自の名前を付けることはできますが、Active Directory (AD) ドメインまたは組織単位を選択することはできません。OSD ウィザードでは、このような状況に簡単に適応できます。管理者は、ウィザード ページを表示できても、ユーザーがドメインや組織単位などの特定の入力の内容を変更できないようにすることが可能です。この便利なロック機能は、構成ファイルで指定することで、ほとんどのページで利用できます。

一部のページには、無効化やロックだけでなく、ウィザード内部の動作を変更する属性もあります。ウィザードの機能により、自動的に AD を調べて、コンピューター名が使用済みでないかどうかや、ユーザーの資格情報が有効かどうかを確認できます。その他の属性が存在するページでは、値を指定することで、ウィザードを再コンパイルすることなく、このような機能を有効または無効にできます。

OSD ウィザードで提供される 8 つの各ページには、そのページで提供する機能を表す名前が付けられています。具体的には、Welcome (ようこそ)、Pre-Flight (プレフライト)、Computer (コンピューター)、Network (ネットワーク)、Language (言語)、Volume (ボリューム)、Application (アプリケーション)、および Summary (まとめ) です。このウィザードのいくつかのページで提供される主な機能を確認し、その機能の使用方法を考えてみましょう。

独自のブランドでウィザードをカスタマイズして、自社標準の IT ブランドに合わせることができます。また、ブランド化は、構成ファイルで header 属性にビットマップ名を指定することで簡単に実現できます。環境に合うようにウィザードのブランドを変更するのに必要な作業は、630x100 のサイズのビットマップ イメージを作成して、このイメージを OSD パッケージに追加し、構成ファイルを編集するだけです (ブランド化の詳細については、TechNet ブログの記事 tinyurl.com/r7jdve (英語) を参照してください)。

OSD ウィザードの最も強力な機能の 1 つは、Windows 7 への移行を開始する前に実行される独自のプレフライト チェックを組み込めることです。たとえば、会社で Windows 7 と互換性のない人事アプリケーションがあるとします。ユーザーの生産性への影響を最小限に抑えるため、スクリプトを作成して、このアプリケーションがインストールされているかどうかを確認する OSD ウィザードのプレフライト チェックを追加します。このチェックの結果を基に、当該ユーザーの移行処理の続行を許可するか、互換性のない人事アプリケーションについての警告をユーザーに表示できます。

OSD ウィザードには、現在、構成ファイルで有効または無効にできる 2 種類の組み込みのプレフライトがあります。この 2 つのプレフライトは、ほとんどの企業で適用できるので組み込まれています。1 つ目のプレフライトは、フル OS で実行される電源のチェック (たとえば、ユーザーが RAP またはプログラムの追加と削除を使用して移行する場合) で、ユーザーが AC 電源を使用していない場合に、エラー通知を返します。このプレフライトで AC 電源が使用されていないことが検出されると、ユーザーには AC アダプターを接続するように求めるエラー通知が返されます。AC 電源に接続したら、ユーザーは [Retry Pre-Flight Checks] (プレフライト チェックの再試行) をクリックして、他に問題がない場合は、次のページに進めます。

2 つ目の組み込みのプレフライトは、ワイヤレス チェックです。OSD は多くの帯域幅を必要とするプロセスなので、イーサネット アダプター (802.3 ワイヤード接続など) で接続している場合に最も効率よく動作します。このワイヤレス プレフライトでイーサネットが使用されていないことが検出されると、ユーザーがネットワークへのワイヤード (有線) 接続を確立するまでエラー通知が返されます。

ただし、組み込みのチェック以外のプレフライトも実行できます。プレフライトでは、実行可能ファイルまたは Visual Basic スクリプトなどの Windows Scripting Host スクリプトをサポートしています。プレフライト チェックは、ファイルやスクリプトが実行でき、5 分未満で完了する限り、その数に制限はありません (5 分以上かかると、OSD ウィザードによりスクリプトの実行が停止されます)。

図 2. OSD ウィザード

スクリプトまたは実行可能ファイルが実行されるたびに、コードが OSD ウィザードのプロセスに返されます。ウィザードの構成に応じて、Success (成功)、Warning (警告)、または Error (エラー) 状態通知が返されます (図 2 参照)。Success または Warning の通知が返された場合、ユーザーはウィザードの残りの処理を続行できます。ただし、Error の通知が返された場合、ユーザーは処理を続行できません。独自のプレフライト スクリプトまたは組み込みのスクリプトから返される有効なコードは、osdconf.xml で構成することが可能で、ウィザードの実行可能ファイルを変更する必要はありません。また、エラーの説明文も構成可能です。
Windows 7 展開の一環としてアプリケーションを配布する方法は 2 とおりあります。1 つは Windows 7 の基本 Windows インストール イメージ (WIM) に含める方法で、もう 1 つは個別のタスク シーケンスのステップとする方法です。Windows 7 の WIM イメージに含める方法は、ほとんどのエンド ユーザーに必要で、更新される頻度が高くないアプリケーションに使用します。ただし、この方法には、2 つの主な欠点があります。1 つ目は、イメージのサイズが増大することです。これは、クライアントへのダウンロードにかかる時間に影響します。2 つ目は、イメージの管理が必要なことです。アプリケーションが更新されるたびに、WIM イメージでは、新しいインストール イメージを作成して、基本イメージと関連付けられている Configuration Manager パッケージを更新する必要があります。

図 3. OSD ウィザードのアプリケーションの選択ページ

このような理由から、Modena ツールでは、Configuration Manager 2007 のソフトウェア アプリケーションのインストール機能とスムーズに統合し、OSD プロセスの一環としてインストールするアプリケーションを選択できる機能をエンド ユーザーに提供しています (詳細については、TechNet の記事 tinyurl.com/pdfp5s (英語) を参照してください)。図 3 からわかるように、アプリケーションは、OSD ウィザードの構成ファイルの指定に基づいて、ツリー形式で表示されます。たとえば、部署、場所、またはアプリケーションの種類ごとにアプリケーション グループを定義して、各グループに含まれるアプリケーションと既定の選択内容を定義します。この定義により、アプリケーションを簡単に変更したり、追加したりすることができます。このときの唯一の要件は、アプリケーションが Configuration Manager 2007 データベースでパッケージ化され、利用可能であることです。

繰り返しになりますが、このウィザードの主な目的は、Windows 7 イメージの最終的な結果を調整できる機能をユーザーに提供することです。ユーザーが多くの入力を行うことを予期していない環境では、最小限の情報の入力だけを求めるようにウィザードを構成して、他の情報は管理者がタスク シーケンスにハード コーディングするようにできます。

許されないデータの喪失

USMT 4.0 には、多くの企業のユーザー状態をキャプチャできる構成ファイルの基本セットが含まれています。構成ファイル MigApp.xml と MigDocs.xml は、ユーザー データをキャプチャする大半のシナリオに対応しています (構成ファイルの詳細については、TechNet の記事 technet.microsoft.com/ja-jp/library/dd560786.aspx を参照してください)。
OSD では、Windows 7 をインストールするボリュームをクリーンアップします。そのため、OSD を使用するたびに、ユーザー状態を適切かつ正確にキャプチャすることが非常に重要です。つまり、データの喪失は許されません。

マイクロソフトでも使用したベスト プラクティスは、タスク シーケンスの 1 ステップとして、ユーザー状態のターゲット フォルダーとなる安全な場所を設けることです。次に、OSDStateStorePath という名前の OSD の組み込みのタスク シーケンス変数を使用して、タスク シーケンスの Apply OS (OS 適用) のステップで実行するボリュームのクリーンアップから、このディレクトリを除外します (この機能を実現して十分に活用する方法の詳細については、TechNet ブログ記事 blogs.technet.com/osd (英語) を参照してください)。

Windows 7 を展開するためのタスク シーケンスを構築する

Modena OSD ツールには、マイクロソフトで使用した OSD タスク シーケンスをエクスポートしたものが付属しています。このエクスポートされたタスク シーケンスは、いくつかのグループに分かれていますが、Root の配下には Master Group (マスター グループ) と Failover Group (フェールオーバー グループ) という名前の子グループがあります。Master Group には、Windows 7 の展開で使用する主なステップのそれぞれに関連付けれられている子グループがあります。これらの各子グループ (図 4 参照) には、Master Group にエラーを返すエラー状態が定義されています。Master Group ではエラーを受け取ると、それを Failover Group という特別なステップに転送します。

タスク シーケンスをこのようなステップに分けることで、ログ、レポート、およびエラー処理プロセスを簡素化しています。このような作業には付き物ですが、どれほど準備に時間をかけても、エラーは発生します。それが Failover Group が用意されている理由です。このグループは、失敗したインストールのトラブルシューティングに必要な関連ログ ファイルをすべて収集し、それらを OSD の安全なフォルダーに保存するようにデザインされています。

タスク シーケンスにフォールト トレランスを実装するには、Root の配下に Master Group および Failover Group という 2 つの子グループを作成します。もう 1 つのベスト プラクティスは、展開に必要なすべての作業ステップを Master Group に含め、このグループをエラー時にも処理を続行するように指定したグループとして使用します。各子グループは、タスク シーケンスを続行するために必要で、エラーが発生したら失敗するように設定します。Master Group では、5 つの入れ子になったグループを子グループとして設定しています (図 4 参照)。

図 4. タスク シーケンスのグループ化

もう 1 つのベスト プラクティスは、展開に致命的な影響を与えない子グループは、エラーが発生しても処理を続行するように設定することです。OSD タスク シーケンス エンジンでは、常に親グループを参照して処理を続行すべきかどうかを判断することで、エラーが発生したときに実行する操作を決定しています。このような動作のため、各ステップがエラー発生時に停止または続行するかを定義することをお勧めします。ステップがエラー時に続行するように設定されていないと、タスク シーケンスでは親グループを参照して、次に実行する操作を決定します。図 4 のデザインでは、Master Group がエラー時に処理を続行するように設定されているため、それに対応するピアの Failover Group が実行されます。

たとえば、ユーザー状態をキャプチャするためのグループを作成するとします。このグループに含まれるステップは重要なので、各ステップのデザインでは、エラーが発生した場合、展開がそれ以上続行されないようにして、ボリュームが削除されないようにします (これがタスク シーケンスの次のステップである場合)。このような場合、タスク シーケンス エンジンは、実行中のステップがエラー時に続行するように設定されているかどうかを判断し、エラー発生時の動作が定義されていない場合は、そのステップの親グループを参照して、次に実行する操作を決定します。Backup State (状態のバックアップ) 親グループではエラー時に処理を続行するかどうかが定義されていないため、さらにその親 (ここでは Master Group) を参照します。

Failover Group の目的は、前述のとおり、エラーが発生した場合にトラブルシューティングに必要なすべてのデータを確実にキャプチャすることです。このグループは Master Group のピア グループとして設定し、エラー時に Master Group がこれを参照するようにします (図 4 参照)。Failover Group は、展開中に致命的なエラーが発生しない限り、実行されることはありません。そのため、Failover Group はタスク シーケンスの最後のステップであり、セットアップが正常に完了しない場合は必ず実行されます。

展開の状態は _SMSTSLastActionSucceeded 変数に格納されている値に基づいて決まります。これが、最終的な処理が完了するまで、タスク シーケンスの "ツリー" を通過するためにタスク シーケンス エンジンが使用されるしくみです。この例では、最終的な処理は、Failover Group のステップが実行されて、すべてのログと必要なデータを収集したうえで、失敗することです (これをデザインする方法の詳細については、blogs.technet.com/osd (英語) を参照してください)。

ビットマップと BGInfo.exe を使用してユーザー状態を提供する

マイクロソフトでは、OSD の移行プロセスの進行状況をユーザーが確認できることが重要です。既定では、すべてのクライアント ベースの状態は、Configuration Manager OSD によって通知されます。このような状態メッセージで十分な企業もありますが、移行プロセスを構成するより大きな枠組みのステップについてユーザーに通知する創造的な方法があります。

まず、移行プロセスに伴う、より大きな枠組みのステップがどのようなものであるかを理解します。たとえば、このようなステップには、ドライブのパーティシン分割、Windows のインストール、アプリケーションのインストールなどがあります。このような処理を行う最大の理由は、これらのステップにより、全体的に見てどの程度進行しているかをユーザーが把握できるためです。また、このような情報はユーザーに喜ばれます。

マイクロソフトで使用した 5 つの主要ステップは、Backup State (状態のバックアップ)、Install Windows (Windows のインストール)、Set Up Windows (Windows のセットアップ)、Install Applications (アプリケーションのインストール)、および Restore State (状態の復元) です。ユーザーには、BGInfo.exe という TechNet Sysinternals ツールを使用して動的にレンダリングされる静的ビットマップを使用することで、状況を通知します (BGInfo.exe は technet.microsoft.com/ja-jp/sysinternals/bb897557.aspx からダウンロードできますが、Modena OSD ツールにも同梱されています)。このツールは、呼び出して静的ビットマップを読み込めます。また、このツールを使用して、移行の現在の進行状況を示すビットマップを設定することもできます。

Modena には、各ステップに対応する 5 種類のビットマップが用意されています。このような進捗状況を伝える画像は、タスク シーケンスにより設定されます。たとえば、タスク シーケンス グループの Install OS では、BGInfo.exe を呼び出して、このステップを表すビットマップを読み込んでいます (図 5 参照)。

図 5. 進行状況の表示

Modena OSD ツールは、Windows 7 を皆さんの会社で展開するための枠組みを提供しています。必要な作業は、ビットマップを置き換えることだけです。それには、scripts フォルダーを参照して、BG ディレクトリを開き、各ビットマップ イメージをカスタマイズしたビットマップ イメージで置き換えます。これで、Windows 7 の展開で使用する 5 つの主要ステップをエンド ユーザーに通知できます。これは、OSD タスク シーケンス エンジンが提供する詳細なステップをユーザーが参照しなくても、ユーザーに常に情報を伝えられる優れた方法です。

まとめ

Windows 7 はリリースされ、企業に導入できるようになりましたが、導入に伴う複雑さのために、企業の多くはアップグレード プロジェクトに着手していません。マイクロソフトでは、約 1 年前に Windows 7 への移行プロセスを開始しました。ほぼ完璧に対応できるようになりましたが、手直しがまったく不要になることはありません。

Windows 7 は、エンド ユーザーに最大限の生産性とパフォーマンスを提供します。突き詰めて行くと、唯一の障害は、展開の準備をすることです。マイクロソフトでは、展開の準備にかかる時間と複雑さを軽減できるように、System Center Configuration Manager 2007 ユーザーに Modena OSD ツールを提供しています。エンド ユーザーによる操作を多く必要とする場合でも、最低限の操作しか必要としない場合でも、マイクロソフトで使用したものと同じプロセスを使用することで、Windows 7 プロジェクトを合理化できます。

Chris Adams (chrad@microsoft.com) は、マイクロソフトの管理およびサービス部門でシニア リード プログラム マネージャーを務めています。System Center Configuration Manager と System Center Virtual Machine Manager を重点的に担当しています。