仮想化

Microsoft Application Virtualization の概要

Anthony Kinney

この記事は、App-V のプレリリース版に基づいています。ここに記載されているすべての情報は、変更される場合があります。

概要 :

• App-V のアーキテクチャ
• 仮想アプリケーションを管理する
• App-V のシーケンサを使用する
• App-V と Configuration Manager を統合する

目次

App-V のアーキテクチャ
App-V のフル インフラストラクチャのしくみ
仮想アプリケーションを更新する
シーケンス処理
Version 4.5

Microsoft Application Virtualization 4.5 (別名 App-V) は、私にとって本当に身内のような存在です。以前 SoftGrid と呼ばれていた App-V は私と共に、その SoftGrid を開発した会社である Softricity の買収に伴い、マイクロソフトにやってきました。買収以降、多くの変更が加えられたため、TechNet Magazine でこの記事を執筆する機会が与えられたことを非常に嬉しく思っています。

App-V を理解する最も良い方法は、まずエンタープライズ管理という点で IT プロフェッショナルが直面している課題について話し合うことです。現在のビジネス デスクトップは、アプリケーションで溢れています。アプリケーションをインストールする前に、時間をかけて回帰テストを行い、そのアプリケーションとシステムにインストールされている他のアプリケーションが共存できるかどうか、およびそのアプリケーションが他のアプリケーションの動作に影響を与えないかどうかを確認する必要があります。また、アプリケーションを運用する前に、一連の展開プロセスを行う必要があります。アプリケーションを利用できるのは、基本的にそれがインストールされている場所に限られるため、ユーザーは特定のコンピュータに縛られることになります。これにより、OS やアプリケーションの移行、セキュリティの更新、障害回復計画など、複雑で重要性の高いプロジェクトの複雑さがさらに増します。

App-V によって、そのような状況が一変します。App-V を使用したデスクトップ管理は、複雑で時間がかかり、リソースを消費する一連の手順ではなく、より簡単で自動化されたプロセスです。このため、より簡単にアプリケーションの展開、修正プログラムの適用、更新、および運用停止を行い、より良い結果を得ることができます。

App-V を使用すると、ユーザーはどのデスクトップからでもアプリケーションにアクセスできます。アプリケーションは必要に応じて配信され、実際にローカルにインストールされているかのように動作します。したがって、アプリケーションのコンポーネントをインストールしたり、ホスト デバイスを変更したりする必要はありません。

このような仮想化の使用によって、IT プロフェッショナルのデスクトップ管理が大幅に変わります。ホスト デバイスを変更せずに、仮想化アプリケーションを実行することで、次のようなさまざまなメリットを得ることができます。

• アプリケーションの競合が減少します。
• アプリケーションをより短時間で簡単に更新できます。
• 同じアプリケーションの複数のバージョンを同時に実行できます。
• ユーザーがオンラインでもオフラインでも柔軟にアプリケーションを使用できます。
• アプリケーション間の回帰テストが減少します。

App-V のアーキテクチャ

ここでは、App-V プラットフォームで実際にどのような処理が実行されるかについて説明します。このプラットフォームは、いくつかの主要なコンポーネントから構成されます。これらは、シーケンサ、データベース、クライアント、管理サーバー、ストリーミング サーバー、および管理コンソールです (図 1 参照)。

図 1 App-V 環境のレイアウト (画像をクリックすると拡大表示されます)

App-V システムの中心となるのは、App-V クライアントです。ターミナル サーバー クライアントとデスクトップ クライアントの 2 種類を使用できます。どちらの場合でも、すべてのデスクトップと、仮想アプリケーションを展開するターミナル サーバーにクライアントをインストールする必要があります。クライアントに必要なディスク領域は比較的少量です。クライアントによってドライバがインストールされます。また、クライアントには、タスク トレイのインジケータとして表示されるユーザー ランタイム コンポーネントが用意されています。

クライアントは App-V Management Server から仮想アプリケーションの一覧を取得し、利用可能な仮想アプリケーションを表示します。また、これらのアプリケーションの起動 (ユーザーによって起動された場合) と、クライアント側キャッシュの管理を行います。さらに、仮想ランタイム環境の作成を管理し、各環境が専用の仮想バブル内で実行されるようにします。この仮想環境には、仮想レジストリ、仮想ファイル システム、仮想サービス マネージャなど、いくつかのコンポーネントが含まれます。

App-V 4.5 には、フル インフラストラクチャ、ライトウェイト インフラストラクチャ、スタンドアロン モードという 3 種類のインフラストラクチャ展開オプションが用意されています。フル インストラクチャを展開すると、バックエンドには App-V Management Server と App-V Streaming Server (後ほど説明しますが、これは新しいコンポーネントです) が含まれます。App-V Management Server は、一元管理された仮想アプリケーションをホストおよび配信するほか、修正プログラムや更新プログラムが適用された場合に仮想アプリケーションを更新します。

この管理サーバーは、SQL Server を基盤として使用し、App-V データベースをホストします。このデータベースには、仮想アプリケーションの構成と設定が格納されます。仮想アプリケーションの準備とアクセス許可の管理を行う場合は、一元管理ツールとして Active Directory グループを使用することをお勧めします。

App-V プラットフォームでは、設定と構成を管理する目的で、IIS がインストールされていれば同じサーバー上に読み込むことができる Microsoft .NET Framework Web サービスが提供されます。この Web サービスは、Microsoft 管理コンソール (MMC) スナップインである App-V 管理コンソールと App-V データベースとの間のパイプ役として機能します。このコンソールを使用して、仮想アプリケーションの公開や管理、Active Directory グループの割り当て、サーバー設定の管理、仮想化アプリケーションの使用状況に関するレポートの実行を行うことができます (図 2 参照)。

図 2 管理コンソール (画像をクリックすると拡大表示されます)

ライトウェイト インフラストラクチャには、アクティブ アップグレードやパッケージ アップグレードなどのストリーミング機能を提供する App-V Streaming Server が含まれます。このオプションでは、Active Directory や SQL Server は必要ありません。また、デスクトップ構成サービス、ライセンス機能、およびメータリング機能も提供されません。ただし、ライトウェイト インフラストラクチャでは、ストリーミング機能を System Center Configuration Manager (SCCM) やその他のサードパーティ製のエンタープライズ ソフトウェア開発 (ESD) ソリューションに追加できます。

スタンドアロン モードでは、App-V のシーケンサによって、仮想アプリケーションの追加を自動化する MSI ファイルが作成されます (図 3 参照)。この MSI ファイルにはメタデータが含まれ、このデータを使用すると、どの ESD システムでも MSI ファイルを認識し、仮想化アプリケーションを制御できます。このモードでは、クライアントをスタンドアロン モードにする必要があります。このため、仮想アプリケーションの更新に使用できるのは、MSI ベースの更新のみです。また、スタンドアロン モードではストリーミングを利用できません。このモードを使用すると、App-V の分離機能を使用できます。

図 3 App-V のシーケンサ (画像をクリックすると拡大表示されます)

MSI ファイルは非常に柔軟性が高く、1 台の App-V クライアントで完全に独立して実行できるため、サーバー コンポーネントをまったく必要としません。つまり、手動での展開、ディスクを使用した展開、または従来の展開ツールを使用した展開が可能です。

App-V 4.5 では、ストリーミング プロトコルとして HTTP と HTTPS がサポートされるため、特にセキュリティで保護されたワイド エリア ネットワーク (WAN) 環境とインターネットを介したストリーミングのパフォーマンスが向上します。

App-V のフル インフラストラクチャのしくみ

いずれかのクライアント (App-V ターミナル サービス クライアントまたはデスクトップ クライアント) がインストールされているデバイスにユーザーがログオンすると、現在のユーザーに割り当てられているアプリケーションの一覧がクライアントからサーバーに要求されます。サーバーは、Active Directory と通信してそのユーザーが属しているグループを特定し、アプリケーションの一覧をクライアントに返します。クライアントは、このユーザーに割り当てられている仮想アプリケーションのアドバタイズを作成します。

この公開プロセスでは、以下に示すいくつかの操作が実行されます。

• 構成ファイルがコピーされます。
• デスクトップ アイコンが作成されます。
• [送る] リンクが作成されます。
• [スタート] メニューのフォルダが作成されます。
• ファイルの種類が構成されます。

このプロセスは非常に短時間で完了するだけでなく、視覚的な変更を発生させることなく、ユーザーが予期したとおりの外観を維持します。これは最も重要なことです。仮想アプリケーションはローカルにインストールされているかのように動作しますが、もちろんホスト コンピュータが変更されることはありません。アイコンは、プログラム ファイルのディレクトリにある実行可能ファイルを参照するのではなく、App-V クライアントを参照します。App-V クライアントは、ランチャー ファイル (OSD ファイル) を利用して構成を再現します。

このプロセスは、従来のソフトウェア展開と異なり、何もインストールされないため、ネットワークへの影響がほとんど発生しないことに注意してください。これは、特に移動ユーザーが存在する環境で非常に役立ちます。その理由は、ユーザーがアプリケーションを使用できても、そのアプリケーションが起動されるまで実際には何も配信されないためです。また、この提供方法によって、App-V のオンデマンド機能と移動アプリケーション機能が実現されます。

ユーザーが仮想アプリケーションを起動すると、クライアントが、ローカル コンピュータに保存されている OSD 構成ファイルを読み取ります。このファイルには、アプリケーションが格納されている App-V 管理サーバーとの通信時にクライアントが使用するプロトコルが指定されます。

適切なサーバーが、初期起動しきい値 (通常はアプリケーション全体の 20 ～ 40% です) に該当するデータをストリーミング配信してクライアントに応答します。この起動しきい値 (もう一度言いますが、アプリケーション全体の 20 ～ 40% のみです) に該当するデータがすべて配信されると、仮想アプリケーションを実行できるようになります。

ストリーミングはまさに、App-V によって導入されたパラダイム シフトを構成する重要な要素の 1 つです。必要な分のみを配信することで、貴重なネットワーク帯域幅を無駄にすることなくアプリケーションを実行できます。クライアントに配信されるすべてのデータは、デバイス上のローカル キャッシュ ファイルに格納され、2 回目以降の起動時には、そのローカル キャッシュからアプリケーションが起動されるため、余分なネットワーク トラフィックが発生しません。

仮想アプリケーションのストリーミングが完了すると、クライアントはアプリケーションがローカル コンピュータを変更しないように、分離された環境を構築します (つまり、そのアプリケーションを実行した痕跡がクライアント側に残りません)。ただし、クライアントは、ファイルの保存および編集時には、仮想アプリケーションによるローカル ファイル システムへのアクセスを許可します。また、ユーザーがローカル システムに対する適切な特権を与えられていれば、仮想アプリケーションとローカル サービス (印刷など) の対話も許可します。仮想アプリケーションがローカル システムのファイルとレジストリに変更を加えた場合、その変更は仮想化環境にリダイレクトされるため、ホスト デバイスが変更されることはありません。

まだ使用されていない機能は、アプリケーションの実行中に必要に応じて配信され、それ以降の使用に備えてキャッシュに格納されます。この動作のメリットは、ユーザーが必要とするコンポーネントのみが初期起動時に読み込まれるため、不要な機能によってネットワーク リソースが消費されないことです (新しいバージョンでは、クライアント側のキャッシュ機能が強化され、キャッシュの使用率と、バックグラウンドで実行されるストリーミングの効率が向上します)。

Microsoft Office Word を例に考えてみましょう。スペル チェックはほぼすべてのユーザーが使用するため (悔しいですが、私はこの機能がなければこの記事を書くことができません)、初期起動時に配信される機能に含まれます。ですが、Word のヘルプ機能についてはどうでしょうか。この機能を使用するユーザーはそれほど多くないので、初期起動時に配信する必要はありません。この機能は、ユーザーがアクセスした時点で初めて配信されます。

ユーザーが作業を完了してアプリケーションを終了すると、クライアントは仮想環境を破棄した後、この環境を維持して次回の起動時に再構築できるように、すべてのユーザー設定をユーザー固有の領域に格納します。ストリーミング配信された量にかかわらず、そのアプリケーションの配信済みデータはローカル キャッシュに格納され、次回の起動時に利用されます。また、別のユーザーが同じホスト システムにログオンし、同じ仮想アプリケーションを起動した場合は、既にキャッシュに格納されているアプリケーションが利用されます。

仮想アプリケーションのアドバタイズを削除するには、該当する Active Directory グループからユーザーを削除します。また、デスクトップから完全に仮想アプリケーションをアンインストールするには、キャッシュの内容を消去します。アプリケーションが実際にローカルにインストールされることはないので、"この共有コンポーネントを削除しますか" というわずらわしいメッセージが表示されることはありません。

仮想アプリケーションがキャッシュに格納されていても、すべてのユーザーがこのキャッシュにアクセスできるわけではありません。ローカルにインストールされたアプリケーションの実行可能ファイルは、権限のないユーザーでも検索または参照できますが、仮想アプリケーションの存在を示すデータは、Active Directory グループによって明示的に権限がユーザーに与えられていない限り、仮想的にも物理的にも参照できません。

仮想アプリケーションを更新する

更新はシーケンサを使用して行います。アプリケーションに変更が加えられ、更新プログラムが追加されると、App-V 管理サーバー上で、そのバージョンが前のバージョンのすぐ隣に配置されます。サーバーは、クライアントの次回の起動時に、変更が加えられたことを通知します。前のバージョンが使用中である場合は、その仮想アプリケーションが終了するまで、ユーザーは引き続きそのバージョンを利用できます。次回の起動時に、更新されたデータのみがクライアントにストリーミング配信され、キャッシュに読み込まれます。その結果、更新されたバージョンのアプリケーションが提供されます。

たとえば、1,000 人のユーザーが Word 2000 を実行しているとします。管理者は、Word 2000 (word2K.sft) を Word 2000 SP3 に更新する必要があるため、word2K.sft ファイルをシーケンス ステーションにコピーし、シーケンサで [Open for Package Upgrade] (開いてパッケージをアップグレードする) を選択します。[Open for Package Upgrade] を選択すると、パッケージの最新の状態から処理を開始できます。管理者は、仮想アプリケーション内で DLL のコピー、更新プログラムの実行、または修正プログラムの実行を行い、Word 2000 を SP3 に更新します。処理が完了したら、この更新されたパッケージを保存します。

シーケンサは、自動的に新しいファイル名 word2K_2.sft を割り当てることで、ファイル名の重複を避けると同時に、それがシーケンス処理を実行するバージョンであることを示します。この新しいパッケージは、App-V 管理サーバー上で古いパッケージと同じディレクトリに格納されます。したがって、Word 2000 (word2K.sft) と Word 2000 SP3 (word2K_2.sft) は同じディレクトリに格納されます。その後、管理者は App-V の管理コンソールを使用して、これら 2 つの SFT ファイルを関連付けます。

クライアント側で、SP3 が適用されていない Word 2000 を使用しているユーザーは、問題なく作業を続行できます。管理者がこの関連付けを行った後で Word 2000 を新たに起動したユーザーには、変更が検出されたことを示すメッセージが表示されます。続いて、word2K.sft と word2K_2.sft の差分に該当するデータのみがクライアントにストリーミング配信され、自動的に Word 2000 が SP3 に更新されます。

仮想アプリケーションは動的な性質を持つため、ロールバックも非常に簡単です。必要な操作は、App-V の管理コンソールに戻り、新しく追加したバージョンを削除することだけです。その結果、再起動時にクライアントが以前のバージョンへのロールバックを実行します。クライアントは、パッケージのデータが重複しないように自動的にキャッシュを削除し、適切な SFT ファイルを再度ストリーミングによって受信します。これは、従来のソフトウェア展開ツールを使用して物理的にインストールされたアプリケーションの更新プログラムをロールバックするときに必要な処理を考えると、適正なトレードオフであると言えます。

App-V のメリットを実現するには、仮想アプリケーション パッケージを作成する必要があります。ここで活躍するのが App-V のシーケンサです。従来のソフトウェア展開ツール用のスクリプトまたはパッケージの作成に関する知識や経験があれば、シーケンス処理への移行時に役立ちます (ただし、シーケンス処理は、それ自体で 1 つの記事になるほどのトピックであることをお伝えしておかなければなりません)。

ほとんどのソフトウェア展開ソリューションは、各コンピュータでアプリケーションのインストールや更新を実行しなくても済むように、スクリプトを使用して、そのアプリケーションのインストール処理をキャプチャし、その処理を他のコンピュータ上で再現します。一般的なソフトウェア展開ツールは、アプリケーションがインストールされた後、パッケージに関する処理を何も実行しません。このため、アプリケーションで必要になる可能性がある項目をインストールしたり、他のスクリプトを実行したり、必要なアプリケーションの構成を手動で行ったりする必要があります。

App-V の根本的な変更点は、シーケンス処理によって、既にインストールされているアプリケーションのイメージが生成され、その依存関係に関する処理や構成が行われることです。この処理は、App-V クライアントが、自身を実行しているデバイスに変更を加えることなく実行できます。

シーケンサは、さまざまなファイルを生成します。最も重要なファイルは、アプリケーションのすべての資産、依存関係、および構成情報を含む SFT ファイルです。場合によっては、複数のアプリケーションが含まれることもあり、その場合は当然サイズが非常に大きくなります。圧縮オプションもいくつか用意されていますが、それらを使用するには、ネットワークとデバイスのパフォーマンスに関する詳しい知識が不可欠です。シーケンサが作成するアイコン ファイル (.ico) は、仮想アプリケーションのアドバタイズに使用され、そのアプリケーションがローカルにインストールされているかのような動作を提供する役割を果たします。

OSD ファイルも非常に重要であり、その利用方法は無限です。既定では、これは App-V クライアントに仮想アプリケーションの起動方法を指示する XML ファイルです。OSD ファイルを変更して、仮想アプリケーションの起動方法と実行方法を構成および制御することもできます。シーケンス処理の管理者向けガイドや、シーケンス処理のベスト プラクティスに関するドキュメントを読み、OSD ファイルを通じて利用できるプロパティや値について確認することを強くお勧めします。

新しい manifest.xml ファイルには、パッケージ ベースの構成情報が格納されます。このファイルは、サードパーティ製の ESD ソリューションや MSI 展開との統合に使用できます。シーケンサは、仮想アプリケーション パッケージの MSI ファイルを生成することもできます。このファイルを使用して、仮想アプリケーションをスタンドアロン (サーバーを使用しない) クライアントに読み込んだり、ESD システムから提供したりできます。

シーケンサ自体はウィザード ベースのツールであり、パッケージの作成者は、この手順に従ってアプリケーションをインストールし、それを仮想アプリケーションに変換できます (図 4 参照)。まず、パッケージの既定のプロパティを構成します。OSD ファイルに格納されるこれらのプロパティには、パッケージ名やコメントが含まれます。詳細設定では、ストリーミング配信元のサーバー、コンテンツ ディレクトリ、パッケージでサポートされるオペレーティング システムを指定できます。

図 4 シーケンス処理ウィザード (画像をクリックすると拡大表示されます)

2 番目の手順は、アプリケーションのインストール、構成、およびテストです。インストール中、シーケンサは、ファイル システム、レジストリ、およびシステムも含め、ローカル システムに加えられるすべての変更をキャプチャします。また、このウィザードには、Windows Update との統合を行うためのユーティリティなど、いくつかのユーティリティが用意されています。

次は、ファイルの種類の関連付けを構成し、ショートカットの配置先を指定します。通常は、[スタート] メニュー、デスクトップ、およびクイック起動バーに配置されますが、独自の場所を作成することもできます。

続いて、アプリケーションを起動し、初期起動しきい値を構成する必要があります。ここで、アプリケーションを起動するために App-V がクライアントに配信する必要がある、アプリケーションの初期コンポーネントを定義します。

この初期コード (通常は機能ブロック 1 (FB1) と呼ばれます) を構成するには、アプリケーションを起動し、ユーザーが必要とする最も一般的な機能を使用します。たとえば、Word を起動し、スペル チェックを実行します。この作業中にアプリケーションから呼び出された DLL、ファイル、またはレジストリ キーが自動的に FB1 に割り当てられます。この時点で使用されなかったファイル、設定、またはコンポーネントは FB2 に追加されます。その後、アプリケーションが使用されると、クライアントは、FB1 の範囲を示す SFT ファイルのマップを受け取ります。このマップには、アプリケーションで必要になった場合にクライアントがファイルを取得できるように、FB2 に含まれているその他のファイルの場所に関する情報も含まれます。

このシーケンス処理の最後の手順では、すべての設定が適切に構成されているかどうかを確認します。SFT の内容を表すダイアログ ボックス (図 5 参照) が表示され、ここでパッケージの作成者は、パッケージに対する最終的な追加や変更を行うことができます。

図 5 最終的なパッケージの確認と調整 (画像をクリックすると拡大表示されます)

Version 4.5

2 年間の開発期間を経て、App-V 4.5 は今年後半にリリースされる予定です。これはマイクロソフトからリリースされる初めてのバージョンであり、進化したアプリケーションの仮想化が提供されます。このバージョンでは、仮想アプリケーションの動的な対話、スケーラビリティの強化、マイクロソフト製品としての機能要件とセキュリティ要件へのより厳密な準拠など、いくつかの重要な機能強化が施されています。

仮想アプリケーションの動的な対話によって、仮想化されたアプリケーション間の対話が実現されます。この対話は、Dynamic Suite Composition (DSC) と呼ばれます。DSC は、複数のアプリケーションを同じパッケージに追加する機能に代わるものではなく、仮想アプリケーション間で共有される依存関係、ミドルウェア、およびプラグインを統合するための新しい手段を提供します。

管理者は、相互に対話する仮想アプリケーションを指定できます。たとえば、同じバージョンの Java を必要とする 5 種類の Web アプリケーションがあるとします。App-V 4.1 では、この同じバージョンの Java を 5 つの異なるパッケージにそれぞれ追加する必要があります。また、このバージョンの Java に修正プログラムを適用する必要があるとします。管理者は、これら 5 種類のパッケージすべてに修正プログラムを適用する必要があります。DSC を使用すると、一度 Java のパッケージを作成し、これを 5 種類すべての Web アプリケーションが使用するパッケージとして構成できます。したがって、Java に修正プログラムを適用するときも、この Java パッケージに修正プログラムを適用するだけで済みます。

このシナリオは、ミドルウェアやプラグインにも当てはまります。その他のシナリオについては、リリースが近づき、最終的な機能の追加が完了するころに、ブログで紹介する予定です。

スケーラビリティの強化は、ストリーミングとバックエンド インフラストラクチャの両方に関係しています。バックエンド コンポーネントは、クラスタとフェールオーバーに関するシナリオをサポートするように変更されました。また、WAN および LAN 上でストリーミングを使用しやすくなりました。これらの強化は、いくつかの重要な機能が追加されたことによって実現されます。

まず 1 つは、新しい Streaming Server コンポーネントです。このコンポーネントによって、Active Directory と SQL Server というバックエンド インフラストラクチャを必要としないストリーミングが実現されます。バックエンドの複雑な要件を考慮することなく、オンデマンドでの配信や、パッケージの一元的な更新など、優れた機能をすべて利用できます。このコンポーネントは、ブランチ オフィスのシナリオや、サードパーティ製の ESD ソリューションとの統合時に広く使用されることが予想されます。

App-V クライアントにも、いくつかの機能強化が施されています。たとえば、クライアントはすべての使用情報をローカルに格納し、クライアント システムがネットワークに接続しているかどうかに関係なく、この情報を追跡できるようになりました。クライアント キャッシュも拡張および強化され、ディスク容量が制限されたシナリオでのパフォーマンスが向上しました。また、英語以外のアプリケーションのシーケンス処理、英語以外のオペレーティング システムでの App-V の実行、および他言語へのローカライズもサポートされます。

App-V と Configuration Manager を統合する

App-V 4.5 で提供される機能強化と新機能の多くは、App-V と SCCM 2007 R2 の統合を目的としています。前述のとおり、仮想化とストリーミングは、従来のソフトウェア展開ツールで提供されていないアプリケーションの配信機能を提供します。これは、App-V がこれらのツールに置き換わる製品ではなく、これらのツールを補完して拡張できることを意味しています。

この統合によって、SCCM で提供されるスケーラビリティ、レポート作成機能、デバイスの認識機能、WAN 機能、および App-V で提供されるストリーミング機能と分離機能をすべて利用できます。これら 2 種類のテクノロジが統合されることでメリットを得ることができる領域を以下に示します。

アプリケーションの配信 : SCCM R2 と統合された App-V では、オンデマンドでの配信、移動アプリケーション、初期起動しきい値、クライアント PC を変更せずにアプリケーションを展開できる機能など、すべての機能がサポートされます。

更新 : SCCM 配布ポイント (DP) を使用して、パッケージが更新された場合に、仮想アプリケーションの変更分のみを展開できます。このため、1 回のクリックで、複数の仮想アプリケーションを一括で以前のバージョンに戻すことができます。

管理 : Version R2 では、新しい仮想アプリケーションのアドバタイズ ウィザードが導入されます。これにより、仮想アプリケーションだけでなく、従来のソフトウェア パッケージとアドバタイズの展開を 1 つのコンソールから実行できるようになります。

パッケージの作成 : App-V と SCCM を統合するときに、アプリケーションのパッケージを再度作成する必要がなくなります。アプリケーションの初期シーケンス処理は、SCCM の外部で App-V のシーケンスを使用して実行されますが、既存のパッケージは SCCM を使用して更新できます。

ライセンス : SCCM の既存のツールを使用し、仮想アプリケーションをライセンスとメータリングの目的で追跡できます。

BITS : SCCM では、業界標準の BITS プロトコルを使用して App-V に仮想アプリケーションを展開するための新しい手段が提供されます。SCCM DP を使用したストリーミングも可能ですが、ストリーミングが仮想アプリケーションを展開するための理想的な手段ではない場合もあります。SCCM を使用して展開を行う場合、2 種類の方法を選択できます。標準のストリーミングを使用するか、BITS のサービスの品質 (QoS) 機能を使用して、よりきめ細かに制御された形式で展開を行います。これは、ユーザーが仮想アプリケーションを起動する前にキャッシュをあらかじめ読み込む必要がある場合にも役立ちます。

コンピュータの展開 : SCCM では、仮想アプリケーションを特定のコンピュータに展開できるだけでなく、ユーザーに基づいた App-V プラットフォームの対象化も引き続きサポートされます。これは、仮想アプリケーションをラップトップ、キオスク、およびラボのコンピュータに展開するときに役立ちます。また、指定されたユーザーではなくデバイスに基づいてソフトウェアのライセンスが付与されている場合は、この機能をライセンスの管理に役立てることができます。

スケーラビリティ : 多くの機能が重複した 2 種類のツールを展開する必要が生じることはよくあります。SCCM で提供されるスケーラビリティと WAN 機能が、APP-V で提供される分離およびストリーミング機能に統合されることで、複雑さを増すことなく、管理と展開の両方に対応した単一のツールとして既存の SCCM を使用できます。

Anthony Kinney は、Microsoft Desktop Optimization Pack 担当のテクニカル セールス プロフェッショナルです。Anthony は、2006 年の Softricity 社の買収によって、同社からマイクロソフトに移籍しました。Softricity では、SoftGrid (現 App-V) の導入用トレーニング プログラムを執筆および作成していました。連絡先は Anthony.kinney@microsoft.com (英語のみ) です。