JP2013186755A - 情報処理装置、イメージファイル管理方法およびプログラム - Google Patents

Abstract

【課題】クライアント端末のデスクトップ環境（仮想イメージファイル）を効率的に管理する情報処理装置を提供する。
【解決手段】実施形態によれば、情報処理装置は、複数のクライアント端末のデスクトップ環境を管理するクライアント管理システムに適用される。情報処理装置は、第１の制御手段と、第２の制御手段とを具備する。第１の制御手段は、前記デスクトップ環境用のディスクイメージファイルであって前記複数のクライアント端末それぞれに固有の情報を含まない第１のイメージファイルと、前記第１のイメージファイルを基にして前記複数のクライアント端末それぞれに固有の情報を含む第２のイメージファイルを構築するための差分ファイルとの作成処理を制御する。第２の制御手段は、前記複数のクライアント端末中の対応するクライアント端末による前記第２のイメージファイルの取得が完了した前記差分ファイルの削除処理を制御する。
【選択図】図６

Description

本発明の実施形態は、複数のクライアント端末のデスクトップ環境を管理するための情報処理装置、イメージファイル管理方法およびプログラムに関する。

近年、各種企業においては、オフィス内の多数のクライアント端末をサーバによって管理するためのシステム（クライアント管理システム）の導入が検討されている。

クライアント管理システムでは、多数のクライアント端末のデスクトップ環境（オペレーティングシステム（ＯＳ）、アプリケーションプログラム）を、クライアント管理システム内のサーバによって集中管理することができる。デスクトップ環境は、例えば、仮想ハードディスク（ＶＨＤ）フォーマットのようなディスクイメージファイルであって、ＯＳ、アプリケーションプログラムを含む仮想イメージファイルとして管理される。

特開２０１１−１５０７４１号公報 特開２０１１−１８６９１５号公報 特開２００９−２２３７１３号公報

サーバによって管理すべきクライアント端末の数が増加すると、これに伴い、サーバによって集中管理すべきデスクトップ環境の数も増加する。クライアント端末のデスクトップ環境を格納するディスク等、サーバのリソースは有限であるので、クライアント端末が膨大な数に上ると、クライアント端末のデスクトップ環境を効率的に管理する仕組みが必要となる。

本発明は、クライアント端末のデスクトップ環境（仮想イメージファイル）を効率的に管理する情報処理装置、イメージファイル管理方法およびプログラムを提供することを目的とする。

実施形態によれば、情報処理装置は、複数のクライアント端末を管理するクライアント管理システムに適用される。情報処理装置は、第１の制御手段と、第２の制御手段とを具備する。第１の制御手段は、前記デスクトップ環境用のディスクイメージファイルであって前記複数のクライアント端末それぞれに固有の情報を含まない第１のイメージファイルと、前記第１のイメージファイルを基にして前記複数のクライアント端末それぞれに固有の情報を含む第２のイメージファイルを構築するための差分ファイルとの作成処理を制御する。第２の制御手段は、前記複数のクライアント端末中の対応するクライアント端末による前記第２のイメージファイルの取得が完了した前記差分ファイルの削除処理を制御する。

実施形態の情報処理装置（管理サーバ）を適用するクライアント管理システムの構成を示す図。 図１のクライアント管理システムとリッチクライアント端末（仮想化クライアント端末）との間の通信手順の例を説明するため図。 図１のクライアント管理システムとシンクライアント端末との間の通信手順の例を説明するため図。 図１のクライアント管理システムに適用されるコネクションブローカによって提供されるローミング機能を説明するため図。 図１のクライアント管理システムに適用されるコネクションブローカによって管理されるユーザプロファイルを説明するための図。 図１のクライアント管理システム内における仮想イメージファイルの取扱いのための連携を説明するための図。 図１のクライアント管理システムに適用される仮想イメージ作成＆配信サーバによって作成される仮想イメージファイルの構造を説明するための図。 図１のクライアント管理システム内における仮想イメージファイルの取扱いに関するシーケンス図。 図１のクライアント管理システムに適用される管理サーバによって制御される個別イメージファイル（差分ファイル）を含む仮想イメージファイルの削除処理のシーケンス図。 図１のクライアント管理システムにおいて仮想イメージファイルを２つの仮想イメージ作成＆配信サーバによって分散管理する場合の一態様を示す図。 図１のクライアント管理システムに適用される管理サーバが仮想イメージファイルの振り分け先を決定する第１の原理を説明するための図。 図１のクライアント管理システムに適用される管理サーバが仮想イメージファイルの振り分け先を決定する第２の原理を説明するための図。 図１のクライアント管理システムにおける仮想イメージファイルの更新に関する運用を示す図。

以下、実施の形態について図面を参照して説明する。

図１は、本実施形態の情報処理装置（管理サーバ２１）を適用するクライアント管理システム１の構成を示す。このクライアント管理システム１は、複数のクライアント端末を管理するためのサーバシステムである。クライアント管理システム１は、１つまたは複数のサーバ（物理サーバ）によって実現することができる。ここでは、このクライアント管理システム１が、複数のサーバによって実現されている場合を想定する。

図１に示すように、クライアント管理システム１は、管理サーバ２１、仮想マシン管理サーバ２２、ドメインコントローラ２３、仮想イメージ作成＆配信サーバ２４、シンクライアント実行サーバ２５、コネクションブローカ２６、プロファイルストレージ２７および仮想イメージストレージ２８等を備える。

管理サーバ２１、仮想マシン管理サーバ２２、ドメインコントローラ２３、仮想イメージ作成＆配信サーバ２４、シンクライアント実行サーバ２５、コネクションブローカ２６およびプロファイルストレージ２７は、例えばＬＡＮ（Local area network）等のネットワークに接続されている。第１タイプのクライアント端末１１、第２タイプのクライアント端末１２および管理者端末１３も、このネットワークに接続されている。

クライアント管理システム１は、例えばオフィス環境において構築される。クライアント管理システム１は、オフィス内に配置された複数のクライアント端末を管理サーバ２１によって集中管理する。さらに、このクライアント管理システム１では、複数のクライアント端末に適用される複数のユーザプロファイルが、プロファイルストレージ２７に格納される。各ユーザプロファイルは、このユーザプロファイルが適用されるクライアント端末のユーザ環境を設定するための設定情報、例えば、各アプリケーションプログラムに関する各種設定情報、デスクトップ画面に関する各種設定情報を含む。さらに、各ユーザプロファイルは、ユーザがアプリケーションプログラムを用いて作成したドキュメントファイルのようなユーザデータも含む。

本実施形態のクライアント管理システム１は、第１タイプおよび第２タイプの２種類のクライアント端末を管理することができる。図１に示されるクライアント端末１１は、第１タイプのクライアント端末である。第１タイプのクライアント端末は、いわゆる仮想化クライアント端末である。第１タイプのクライアント端末が備えるローカルストレージには、仮想マシンモニタ（ハイパーバイザ）が仮想化ソフトウェアとしてインストールされている。第１タイプのクライアント端末は、この仮想化ソフトウェアと、クライアント管理システム１から配信される仮想イメージファイル内のＯＳおよびアプリケーションプログラムとを実行する。

即ち、第１タイプのクライアント端末（以下、リッチクライアント端末１１と称する）においては、ＣＰＵ、メモリ、ストレージ、各種Ｉ／Ｏデバイスといった物理ハードウェア１０１上で仮想マシンモニタ１０２が実行される。仮想マシンモニタ１０２は、ハイパーバイザのような仮想化ソフトウェアであり、物理ハードウェア１０１のリソースをエミュレートすることによって、物理ハードウェア１０１上の仮想化層として機能する。仮想化層である仮想マシンモニタ１０２上では、いくつかの仮想マシンが実行される。図１では、２つの仮想マシン１０３，１０４が仮想マシンモニタ１０２上で実行される場合が想定されている。仮想マシン１０３は、管理ＯＳ（ホストＯＳ）２０１を実行するための仮想マシンである。一方、仮想マシン１０４は、クライアント管理システム１から配信される仮想イメージファイル内の仮想ＯＳ（ゲストＯＳ）３０１およびアプリケーションプログラム３０２を実行する。仮想マシン１０４、つまり、仮想ＯＳ（ゲストＯＳ）３０１およびアプリケーションプログラム３０２は、リッチクライアント端末１１のデスクトップ環境として動作する。

管理ＯＳ（ホストＯＳ）２０１は、仮想マシンモニタ１０２と協働して、仮想マシン１０４を制御することができる。管理ＯＳ（ホストＯＳ）２０１は、管理モジュール２０１Ａを備える。管理モジュール２０１Ａは、クライアント管理システム１の仮想イメージ作成＆配信サーバ２４から仮想イメージファイルをダウンロードすることができる。仮想ＯＳ（ゲストＯＳ）３０１は、エージェント３０１Ａを備える。エージェント３０１Ａは、クライアント管理システム１とリッチクライアント端末１１とを連携させる処理を実行するプログラムである。

第２タイプのクライアント端末は、シンクライアント端末である。これらシンクライアント端末１２は、画面転送プロトコルを使用して、クライアント管理システム１のシンクライアント実行サーバ２５上で実行される仮想マシン５０４それぞれと通信する。換言すれば、複数のシンクライアント端末１２は、仮想デスクトップインフラストラクチャ（ＶＤＩ）を使用してデスクトップ仮想化を実現するための端末（ベース端末）である。これらシンクライアント端末１２それぞれのデスクトップ環境（ＯＳ、アプリケーションプログラム）は、仮想化サーバであるシンクライアント実行サーバ２５によって一元管理される。各シンクライアント端末１２には、シンクライアント実行サーバ２５上の仮想マシン５０４の１つが割り当てられる。ＯＳ、アプリケーションプログラムは、シンクライアント端末１２上ではなく、シンクライアント実行サーバ２５上の仮想マシン５０４によって実行される。

各シンクライアント端末１２は、ユーザによる入力デバイス（例えばキーボード、マウス等）の操作に応じた入力情報をシンクライアント実行サーバ２５内の対応する仮想マシン５０４に送信する。また、各シンクライアント端末１２は、シンクライアント実行サーバ２５内の対応する仮想マシン５０４から、入力情報を反映した画面情報を受信する。

即ち、シンクライアント端末１２においては、画面転送ソフトウェア４０３が実行される。画面転送ソフトウェア４０３は、画面転送プロトコルを使用して、シンクライアント実行サーバ２５内の仮想マシン５０４と通信するプログラムである。画面転送ソフトウェア４０３は、ＯＳ上で動作するアプリケーションプログラムであってもよい。この場合、シンクライアント端末１２においては、ＣＰＵ、メモリ、各種Ｉ／Ｏデバイスといった物理ハードウェア４０１上でＯＳ４０２が実行され、このＯＳ４０２上で画面転送ソフトウェア４０３が実行される。

次に、クライアント管理システム１の各コンポーネントについて説明する。

管理サーバ２１は、本実施形態の情報処理装置であり、クライアント管理システム１の動作を管理するためのサーバである。管理サーバ２１は、ネットワーク、例えばＬＡＮに接続された管理者端末１３の操作に応じて、クライアント管理システム１を使用可能な各ユーザの管理および各リッチクライアント端末１１に対応する仮想イメージファイルの管理等を実行することができる。本実施形態の情報処理装置、即ち、管理サーバ２１は、この仮想イメージファイルを効率的に管理する仕組みを備えたものであり、以下、この点について詳述する。

仮想マシン管理サーバ２２は、シンクライアント実行サーバ２５を管理するためのサーバである。ドメインコントローラ２３は、各ユーザおよび各クライアント端末を認証するためのサーバである。仮想イメージ作成＆配信サーバ２４は、ＯＳおよびアプリケーションプログラムを各々が含む仮想イメージファイルを、複数のリッチクライアント端末１１に配信する配信サーバとして機能する。仮想イメージ作成＆配信サーバ２４は、リッチクライアント端末１１用の仮想イメージファイルのみならず、シンクライアント端末１２用の仮想イメージファイルを作成することもできる。リッチクライアント端末１１用の仮想イメージファイルは、各リッチクライアント端末１１に配信される。一方、シンクライアント端末１２用の仮想イメージファイルは、シンクライアント実行サーバ２５に配信される。各仮想イメージファイルは、例えば仮想ハードディスク（ＶＨＤ）フォーマットのようなディスクイメージファイルであり、後述する、マスタファイル８０１と、差分ファイルである初期化マスタファイル８０２および個別イメージファイル８０３とからなる。

シンクライアント実行サーバ２５は、複数のシンクライアント端末１２と画面転送プロトコルを使用して通信するための複数の仮想マシンを実行するサーバである。シンクライアント実行サーバ２５は、例えば、サーバ仮想化技術によって仮想化された１つの物理サーバによって実現してもよい。

このシンクライアント実行サーバ２５においては、ＣＰＵ、メモリ、ストレージ、各種Ｉ／Ｏデバイスといった物理ハードウェア５０１上で仮想マシンモニタ５０２が実行される。仮想マシンモニタ５０２は、ハイパーバイザのような仮想化ソフトウェアであり、物理ハードウェア５０１のリソースをエミュレートすることによって、物理ハードウェア５０１上の仮想化層として機能する。仮想マシンモニタ５０２上では、管理用の１つの仮想マシン５０３と、仮想デスクトップ環境を実行するための複数の仮想マシン５０４とが実行される。仮想マシン５０３は、管理ＯＳ（ホストＯＳ）５０３Ａを実行する。一方、各仮想マシン５０４は、仮想イメージ作成＆配信サーバ２４から配信される仮想イメージファイル内の仮想ＯＳ（ゲストＯＳ）６０１およびアプリケーションプログラム６０２を実行する。

管理ＯＳ（ホストＯＳ）５０３は、仮想マシンモニタ５０２と協働して、各仮想マシン５０４を制御することができる。仮想ＯＳ（ゲストＯＳ）６０１は、エージェント６０１Ａを備える。エージェント６０１Ａは、リッチクライアント端末１１の仮想マシン１０４内のエージェント３０１Ａと同様に、クライアント管理システム１と各シンクライアント端末１２とを連携させる処理を実行するプログラムである。

コネクションブローカ２６は、ユーザプロファイルの管理等のためにクライアント管理システム１に適用されるサーバである。コネクションブローカ２６は、１つの物理サーバによって実現することができる。

コネクションブローカ２６は、複数のユーザそれぞれに対応する複数のユーザプロファイルを格納するプロファイルストレージ２７を使用して、複数のユーザプロファイルを管理する。また、コネクションブローカ２６は、シンクライアント端末１２上でログオン操作を実行したユーザに対して、シンクライアント実行サーバ２５上の使用可能な仮想マシンを割り当てるための機能も有している。さらに、コネクションブローカ２６は、たとえ各ユーザがどのクライアント端末上でログオン操作を行っても、各ユーザが同じユーザ環境を利用できるようにするための機能（ローミング機能）を有している。

プロファイルストレージ２７は、クライアント管理システム１を使用可能な多数のユーザの識別子（ユーザＩＤ）にそれぞれ関連付けられた多数のユーザプロファイルを格納する。即ち、プロファイルストレージ２７は、多数のユーザにそれぞれ対応するユーザプロファイルを格納するための多数の格納場所を備える。あるユーザがあるクライアント端末をクライアント管理システム１に接続（ログオン）するためのログオン操作を行った場合には、そのクライアント端末に対応する仮想マシンのファイルシステムには、そのユーザのユーザＩＤに関連付けられたユーザプロファイルが自動的にマウントされる。例えば、リッチクライアント端末１１のログオン処理においては、ログオン操作を行ったユーザに対応するユーザプロファイルは、そのリッチクライアント端末１１内の仮想マシン１０４のファイルシステム上にマウントされる。リッチクライアント端末１１内のローカルストレージには、ユーザプロファイル（設定情報、ユーザデータ）の実体は存在せず、ユーザプロファイルの実体はクライアント管理システム１内で管理される。従って、リッチクライアント端末１１のセキュリティ強化を図ることができる。

一方、シンライアント端末１２のログオン処理においては、ログオン操作を行ったユーザのユーザＩＤに関連づけられたユーザプロファイルが、そのシンクライアント端末１２に対応するシンクライアント実行サーバ２５内の仮想マシン５０４のファイルシステム上に自動的にマウントされる。

これにより、各ユーザは、リッチクライアント端末１１およびシンクライアント端末１２のどちらを操作してクライアント管理システム１にログオンした場合でも、同じユーザ環境（同じユーザプロファイル）を使用することができる。

仮想イメージストレージ２８は、仮想イメージ作成＆配信サーバ２４によって作成された仮想イメージファイル、即ち、マスタファイル８０１、初期化マスタファイル８０２および個別イメージファイル８０３を格納するためのストレージである。

ここで、図２を参照して、リッチクライアント端末１１の動作シーケンスについて説明する。

（１）リッチクライアント端末１１内の管理モジュール２０１Ａまたはエージェント３０１Ａは、リッチクライアント端末１１に適用すべき配信イメージ（仮想イメージファイル）が存在するか否かを管理サーバ２１に問い合わせる。例えば、リッチクライアント端末１１のローカルストレージに仮想イメージファイルが存在しない場合、または、リッチクライアント端末１１に既に配信された仮想イメージファイルに対応する更新された仮想イメージファイルがクライアント管理システム１内に存在する場合、管理サーバ２１は、ダウンロードすべき仮想イメージファイルの識別子を管理モジュール２０１Ａまたはエージェント３０１Ａに通知する。

（２）管理モジュール２０１Ａまたはエージェント３０１Ａは、通知された識別子を有する仮想イメージファイルを仮想イメージ作成＆配信サーバ２４に要求し、その仮想イメージファイルを仮想イメージ作成＆配信サーバ２４からダウンロードする。仮想マシン１０４を起動または再起動することにより、ダウンロードされた仮想イメージファイル内のＯＳ（仮想ＯＳ）３０１がスタートされる。

（３）仮想ＯＳ３０１によってログオン画面が表示される。ユーザは、ログオン画面上でログオン操作を行う。仮想ＯＳ３０１は、ドメインコントローラ２３と協働してユーザ認証を行う。ユーザ認証が成功すると、仮想マシン１０４（エージェント３０１Ａ）は、接続要求をコネクションブローカ２６に送信して、ログオン操作を行ったユーザに対応するユーザプロファイルの格納場所をコネクションブローカ２６に問い合わせる。接続要求は、リッチクライアント端末１１をクライアント管理システム１に接続（ログオン）するためのリクエストであり、ログオン操作を行ったユーザのユーザカウント（ユーザＩＤ）を含む。ユーザＩＤは、ユーザを一意に識別するための識別子である。コネクションブローカ２６は、このユーザのユーザＩＤに関連づけられたユーザプロファイルを格納するプロファイルストレージ２７内の格納場所へのパスを示す情報、即ち、ストレージパスを仮想マシン１０４（エージェント３０１Ａ）に送信する。

（４）仮想マシン１０４（エージェント３０１Ａ）は、プロファイルストレージ２７内のユーザプロファイルの格納場所を、仮想マシン１０４（仮想ＯＳ３０１）のファイルシステム上にマウントする。以降、仮想マシン１０４は、ユーザプロファイルをリードまたはライトするために、リッチクライアント端末１１のローカルストレージではなく、プロファイルストレージ２７内のユーザプロファイルの格納場所をアクセスする。

続いて、図３を参照して、シンクライアント端末１２の動作シーケンスについて説明する。

（１）シンクライアント１２のＯＳ４０２または画面転送ソフトウェア４０３は、使用可能な仮想マシンをコネクションブローカ２６に問い合わせる。コネクションブローカ２６は、シンクライアント端末１２が使用可能なシンクライアント実行サーバ２５上の仮想マシン５０４を指定する情報を、シンクライアント端末１２に送る。この場合、コネクションブローカ２６は、シンクライアント端末１２が使用可能なシンクライアント実行サーバ２５上の仮想マシン５０４のリストを、シンクライアント端末１２に送ってもよい。例えば、コネクションブローカ２６は、問い合わせに含まれるユーザＩＤに基づいて、このユーザに対応するデスクトップ環境を実行可能で、かつ、現在使用されていない仮想マシン５０４のリストを表示するための画面を、シンクライアント端末１２に送ることができる。ユーザは、表示された仮想マシン５０４のリスト内から、１つの仮想マシン５０４を選択する。

（２）ＯＳ４０２または画面転送ソフトウェア４０３は、コネクションブローカ２６によって指定された仮想マシン５０４、または、仮想マシン５０４のリスト内から選択された仮想マシン５０４に接続し、接続した仮想マシン５０４を起動する。これにより、仮想マシン５０４内の仮想ＯＳ６０１がスタートされる。

（３）仮想ＯＳ６０１によってログオン画面が表示される。ユーザは、ログオン画面上でログオン操作を行う。仮想ＯＳ６０１は、ドメインコントローラ２３と協働してユーザ認証を行う。ユーザ認証が成功すると、仮想マシン５０４（エージェント６０１Ａ）は、接続要求をコネクションブローカ２６に送信して、ログオン操作を行ったユーザに対応するユーザプロファイルの格納場所をコネクションブローカ２６に問い合わせる。接続要求は、シンクライアント端末１２をクライアント管理システム１に接続（ログオン）するためのリクエストであり、ログオン操作を行ったユーザのユーザカウント（ユーザＩＤ）を含む。コネクションブローカ２６は、このユーザのユーザＩＤに関連づけられたユーザプロファイルを格納するプロファイルストレージ２７内の格納場所へのパスを示す情報、即ち、ストレージパスを仮想マシン５０４（エージェント６０１Ａ）に通知する。

（４）仮想マシン５０４（エージェント６０１Ａ）は、プロファイルストレージ２７内のユーザプロファイルの格納場所を仮想マシン５０４（仮想ＯＳ６０１）のファイルシステム上に自動的にマウントする。以降、仮想マシン５０４は、ユーザプロファイルをリードまたはライトするために、シンクライアント実行サーバ２５のローカルストレージではなく、プロファイルストレージ２内のユーザプロファイルの格納場所をアクセスする。

次に、図４を参照して、コネクションブローカ２６によって実行されるローミング機能について説明する。

このローミング機能は、各ユーザがどのリッチクライアント端末１１を使用しても、または、どのシンクライアント端末１２を使用しても、そのユーザに対応する同一のユーザプロファイルを利用できるようにする機能である。

ここで、各ユーザの席上には、リッチクライアント端末１１が配置され、会議室やパブリックスペースには、シンクライアント端末１２が配置されている場合を想定する。各ユーザは、自分の席上のリッチクライアント端末１１を操作してクライアント管理システム１にログオンすることができる。ユーザが会議室またはパブリックスペースに移動した場合には、ユーザは、シンクライアント端末１２を操作してクライアント管理システム１にログオンすることができる。この場合、ユーザがどのクライアント端末を使用する場合でも、ローミング機能は、それらクライアント端末に対応する仮想マシンに、同じユーザプロファイルを提供する。

まず、リッチクライアント端末１１上でログオン操作が行われた際にコネクションブローカ２６によって実行される処理について説明する。

（１）ユーザ（User1）は、自分の席上のリッチクライアント端末１１をクライアント管理システム１に接続するためのログオン操作を行う。リッチクライアント端末１１の仮想マシン１０４、例えばエージェント３０１Ａは、コネクションブローカ２６に接続要求を送信して、ログオン操作を行ったユーザ（User1）に対応するユーザプロファイルの格納場所をコネクションブローカ２６に問い合わせる。

（２）コネクションブローカ２６は、ユーザ（User1）のユーザプロファイルのストレージパスをリッチクライアント端末１１の仮想マシン１０４に送信する。仮想マシン１０４は、ユーザ（User1）のユーザプロファイルを仮想マシン１０４のファイルシステム上にマウントする。仮想マシン１０４のファイルシステムは、仮想マシン１０４内の仮想ＯＳ３０１によって管理されるファイルシステムである。

プロファイルストレージ２７内の各ユーザプロファイルは、仮想ハードディスク（ＶＨＤ）フォーマットのような仮想イメージファイルであってよい。この場合、ユーザプロファイルの仮想イメージファイルは、仮想マシン１０４のファイルシステム上の所定のマウントポイントにマウントされる。例えば、ユーザプロファイルを格納するための、ファイルシステム内の所定のディレクトリ（ユーザプロファイルディレクトリ）が、前述のマウントポイントとして使用される。この様子を図５に示す。図５に示すように、プロファイルストレージ２７においては、複数のユーザＩＤ（ユーザＩＤ１，ユーザＩＤ２，…）に対応するフォルダ（ユーザＩＤ１￥，ユーザＩＤ２￥、…）が存在する。これらフォルダ（ユーザＩＤ１￥，ユーザＩＤ２￥，…）には、複数のユーザＩＤ（ユーザＩＤ１，ユーザＩＤ２，…）にそれぞれ関連づけられたユーザプロファイル（UserProfile1.vhd、UserProfile2.vhd、…）が格納されている。仮想マシン１０４のファイルシステム上のユーザプロファイルディレクトリ（ユーザＩＤ１）には、UserProfile1.vhdがマウントされる。

仮想ＯＳ３０１は、ファイルシステム上にマウントされたユーザプロファイルをプロファイルストレージ２７からリードし、そのユーザプロファイル内の設定情報に基づいて、アプリケーションプログラムの設定およびデスクトップ環境の設定等を行うことができる。また、各種ドキュメントのようなユーザデータも、ユーザプロファイル内に存在する。仮想ＯＳ３０１は、ファイルシステム上にマウントされたユーザプロファイル内のユーザデータをプロファイルストレージ２７からリードし、そのユーザデータをリッチクライアント端末１１のディスプレイ上に表示することができる。さらに、更新されたユーザデータまたは設定情報等は、リッチクライアント端末１１のローカルストレージではなく、プロファイルストレージ２７に格納される。

次に、シンクライアント端末１２上でログオン操作が行われた際にコネクションブローカ２６によって実行される処理について説明する。

（１）ユーザ（User1）は、例えばパブリックスペース等に設置されているシンクライアント端末１２をクライアント管理システム１に接続するためのログオン操作を行う。シンクライアント端末１２に対応する、シンクライアント実行サーバ４５上の仮想マシン５０４、例えばエージェント６０１Ａは、コネクションブローカ２６に接続要求を送信して、ログオン操作を行ったユーザ（ｕｓｅｒ１）に対応するユーザプロファイルの格納場所をコネクションブローカ２６に問い合わせる。

（２）コネクションブローカ２６は、ユーザ（User1）のユーザプロファイルのストレージパスを、シンクライアント端末１２に対応する、シンクライアント実行サーバ２５上の仮想マシン５０４に送信する。仮想マシン５０４は、ユーザ（User1）のユーザプロファイルを仮想マシン５０４のファイルシステム上にマウントする。仮想マシン５０４のファイルシステムは、仮想マシン５０４内の仮想ＯＳ６０１によって管理されるファイルシステムである。仮想ＯＳ６０１は、ファイルシステム上にマウントされたユーザプロファイルをプロファイルストレージ２７からリードし、そのユーザプロファイル内の設定情報に基づいて、アプリケーションプログラムの設定およびデスクトップ環境の設定等を行うことができる。

このように、各ユーザは、どのクライアント端末上でログオン操作を行っても、同じユーザ環境を利用することができる。

ところで、クライアント端末が膨大な数に上ると、仮想イメージファイルを格納する仮想イメージストレージ２８を大量に消費することになる。そこで、管理サーバ２１は、クライアント管理システム１として管理すべき仮想イメージファイルの数が激増したとしても、必要とする仮想イメージストレージ２８の容量を極力抑えるための仮想イメージファイルの管理処理を実行する。

図６および図７を参照して、管理サーバ２１によって実行される仮想イメージファイルの管理処理を説明する。図６は、クライアント管理システム１内における仮想イメージファイルの取扱いのための連携を説明するための図である。

リッチクライアント端末１１用またはシンクライアント端末１２用の仮想イメージファイルを作成する場合、管理者端末１３から管理サーバ２１に対して、仮想イメージファイルの作成要求が通知される（図６の（１））。この通知を受けた管理サーバ２１は、仮想イメージ作成＆配信サーバ２４に対して、要求された仮想イメージファイルの作成指示を通知する（図６の（２））。管理サーバ２１は、仮想イメージファイルの管理処理を司る仮想イメージ管理処理部２１１を備えている。また、管理サーバ２１は、後述する更新パッチ情報２１１Ａを管理する。

図６に示すように、仮想イメージ作成＆配信サーバ２４においては、ＣＰＵ、メモリ、ストレージ、各種Ｉ／Ｏデバイスといった物理ハードウェア７０１上で仮想マシンモニタ７０２が実行される。仮想マシンモニタ７０２は、ハイパーバイザのような仮想化ソフトウェアであり、物理ハードウェア７０１のリソースをエミュレートすることによって、物理ハードウェア７０１上の仮想化層として機能する。仮想マシンモニタ７０２上では、管理用の１つの仮想マシン７０３と、仮想イメージファイルを作成するための複数の仮想マシン７０４，７０５とが実行される。仮想マシン７０３は、管理ＯＳ（ホストＯＳ）７０３Ａを実行する。一方、仮想マシン７０４，７０５は、管理サーバ２１から指示された仮想イメージファイルの作成処理を実行する。

仮想イメージ作成＆配信サーバ２４は、仮想イメージファイルの作成指示を管理サーバ２１から受け取ると、この仮想イメージファイルの作成に使用すべき仮想マシン７０４，７０５を示す情報を管理サーバ２１に返信する。管理サーバ２１は、（仮想イメージファイルの作成要求に対する応答として）仮想イメージ作成＆配信サーバ２４上の仮想マシン７０４，７０５を指定する情報を、管理者端末１３に転送する。管理者端末１３は、管理者サーバ２１によって指定された仮想マシン７０４，７０５に接続し、接続した仮想マシン７０４，７０５を起動する（図６の（３））。これにより、ユーザ（管理者）が、管理者端末１３を操作して、仮想イメージファイルの作成を仮想イメージ作成＆配信サーバ２４に実行させることが可能となる。仮想イメージ作成＆配信サーバ２４によって作成された仮想イメージファイルは、仮想イメージストレージ２８に格納される。

図７は、仮想イメージ作成＆配信サーバ２４によって作成される仮想イメージファイルの構造を説明するための図である。

前述したように、仮想イメージファイルは、マスタファイル８０１と、差分ファイルである初期化マスタファイル８０２および個別イメージファイル８０３とからなる。図６に示される仮想イメージ作成＆配信サーバ２４上の仮想マシン７０４は、マスタファイル８０１と初期化マスタファイル８０２とを作成するための仮想マシンである。また、仮想マシン７０５は、個別イメージファイル８０３を作成するための仮想マシンである。

リッチクライアント端末１１用の仮想イメージファイルを作成する場合、まず、仮想マシン７０４上において仮想ＯＳ３０１およびアプリケーションプログラム３０２のインストールが実行され、これら仮想ＯＳ３０１およびアプリケーションプログラム３０２がインストールされたディスクのイメージファイル（ディスクイメージファイル）が作成される。一方、シンクライアント端末１２用の仮想イメージファイルを作成する場合には、仮想マシン７０４上において仮想ＯＳ６０１およびアプリケーションプログラム６０２のインストールが実行され、これら仮想ＯＳ６０１およびアプリケーションプログラム６０２がインストールされたディスクのイメージファイル（ディスクイメージファイル）が作成される。このインストール時、機器固有情報（ＩＤ：０）が暫定的に入力され、作成されるディスクイメージファイルに内包される。マスタファイル８０１は、この暫定的に入力された機器固有情報（ＩＤ：０）を含んだ状態のディスクイメージファイルである。

マスタファイル８０１が作成されると、続いて、仮想マシン７０４上において、マスタファイル８０１に含まれる機器固有情報（ＩＤ：０）をリセットする処理が行われる。初期化マスタファイル８０２は、機器固有情報がリセットされた状態（ＩＤ：リセット）のディスクイメージファイルである。初期化マスタファイル８０２の実体は、マスタファイル８０１に差分ファイル８０２Ａを追加したものである。従って、マスタファイル８０１に含まれる機器固有情報（ＩＤ：０）をリセットする処理とは、即ち、差分ファイル８０２Ａを作成する処理である。

仮想マシン７０５上においては、リッチクライアント端末１１またはシンクライアント端末１２の機器固有情報（ＩＤ：ａ，ｂ，ｃ，…）を初期化マスタファイル８０２にセットする処理が行われる。この処理によって作成されるディスクイメージファイルが個別イメージファイル８０３である。個別イメージファイル８０２の実体は、初期化マスタファイル８０２に差分ファイル８０３Ａを追加したもの、即ち、マスタファイル８０１に差分ファイル８０２Ａと差分ファイル８０３Ａとを追加したものである。従って、リッチクライアント端末１１またはシンクライアント端末１２の機器固有情報（ＩＤ：ａ，ｂ，ｃ，…）を初期化マスタファイル８０２にセットする処理とは、即ち、差分ファイル８０３Ａを作成する処理である。この差分ファイル８０３Ａは、仮想イメージファイルの数だけ存在する。よって、例えばリッチクライアント端末１１の数が増加すると、これに伴い、差分ファイル８０３Ａの数も増加する。

ここまでの説明から明らかなように、仮想イメージストレージ２８には、マスタファイル８０１、（マスタファイル８０１を基にして初期化マスタファイル８０２を構築するための）差分ファイル８０２Ａおよび（初期化マスタファイル８０２を基にして個別イメージファイル８０３を構築するための）差分ファイル８０３Ａが格納される。そして、これらマスタファイル８０１、差分ファイル８０２Ａおよび差分ファイル８０３Ａが、仮想イメージファイルとして、仮想イメージ作成＆配信サーバ２４からリッチクライアント端末１１やシンクライアント実行サーバ２５に配信される。

再び図６を参照する。

リッチクライアント端末１１やシンクライアント実行サーバ２５は、仮想イメージ作成＆配信サーバからダウンロードすべき仮想イメージファイルが存在するか否かを管理サーバ２１に問い合わせる（図６の（４））。ダウンロードすべき仮想イメージファイルが存在し、その識別子が管理サーバ２１から通知された場合、リッチクライアント端末１１やシンクライアント実行サーバ２５は、通知された識別子を有する仮想イメージファイルを仮想イメージ作成＆配信サーバ２４に要求し、その仮想イメージファイルを仮想イメージ作成＆配信サーバ２４からダウンロードする（図６の（５））。

リッチクライアント端末１１やシンクライアント実行サーバ２５は、仮想イメージ作成＆配信サーバ２４からの仮想イメージファイルのダウンロードが完了したら、その旨を管理サーバ２１に通知する（図６の（６））。この通知を受けると、管理サーバ２１は、仮想イメージ作成＆配信サーバ２４に対し、ダウンロードが完了した仮想イメージファイル用の差分ファイル８０３Ａの削除指示を通知する（図６の（７））。仮想イメージ作成＆配信サーバ２４は、管理サーバ２１から削除指示を受けた差分ファイル８０３Ａを仮想イメージストレージ２８から削除する。

このように、本実施形態のクライアント管理システム１では、管理サーバ２１が、仮想イメージ作成＆配信サーバ２４からリッチクライアント端末１１またはシンクライアント実行サーバ２５による取得が完了した仮想イメージファイル用の差分ファイル８０３Ａを仮想イメージストレージ２８から削除するように制御する。これにより、クライアント端末の増加に伴って、仮想イメージストレージ２８の消費容量がリニアに増加することを防止する。なお、仮想イメージファイルを再供給しなければならない事象が発生しても、マスタファイル８０１と差分ファイル８０２Ａとからなる初期化マスタファイル８０２が仮想イメージストレージ２８に存在するので、差分ファイル８０３Ａのリカバリは容易に可能である。即ち、管理サーバ２１は、クライアント端末のデスクトップ環境（仮想イメージファイル）を効率的に管理することを実現する。

図８は、仮想イメージファイルの取扱いに関するシーケンス図を示している。

管理サーバ２１は、仮想イメージ作成＆配信サーバ２４に対して、仮想イメージファイルの作成指示を通知する（ステップＡ１）。この通知を受けた仮想イメージ作成＆配信サーバ２４は、仮想イメージファイルの作成処理を実行する（ステップＡ１．１）。作成された仮想イメージファイルは、仮想イメージストレージ２８に格納される。

リッチクライアント端末１１は、管理サーバ２１に対して、新たな仮想イメージファイルが存在するか否かを問い合わせる（ステップＡ２）。リッチクライアント端末１１は、管理サーバ２１からの回答に基づき、新たな仮想イメージファイルを仮想イメージ作成＆配信サーバ２４からダウンロードする（ステップＡ３）。そして、リッチクライアント端末１１は、仮想イメージファイルの更新処理を実行し（ステップＡ４）、更新成功を管理サーバ２１に通知する（ステップＡ５）。

管理サーバ２１は、リッチクライアント端末１１から仮想イメージファイルの更新成功を通知されると、仮想イメージ作成＆配信サーバ２４に対して、そのリッチクライアント端末１１用の個別イメージファイル（差分ファイル）の削除指示を通知する（ステップＡ６）。この通知を受けた仮想イメージ作成＆配信サーバ２４は、（仮想イメージストレージ２８に格納された）指示されたリッチクライアント端末１１用の個別イメージファイル（差分ファイル）の削除処理を実行する（ステップＡ６．１）。

図９は、個別イメージファイル８０３（差分ファイル８０３Ａ）を含む仮想イメージファイルの削除処理のシーケンスを示す図である。

管理サーバ２１は、仮想イメージ作成＆配信サーバ２４に対して、仮想イメージファイルの削除を指示する（ステップＢ１）。この指示を受けた仮想イメージ作成＆配信サーバ２４は、削除対象の仮想イメージファイルをロックする（ステップＢ１．１）。仮想イメージ作成＆配信サーバ２４は、まず、削除対象の仮想イメージファイルの管理情報ファイルを削除し（ステップＢ１．２）。続いて、削除対象の仮想イメージファイルの削除を実行する（ステップＢ１．３）。

仮想イメージ作成＆配信サーバ２４は、ロックの解除を行い（ステップＢ１．４）、仮想イメージファイルの削除完了を管理サーバ２１に通知する。

なお、例えば、リッチクライアント端末１１の数が増大した場合、仮想イメージ作成＆配信サーバ２４を増設して、仮想イメージファイルを分散管理することも考えられる。このような場合に、管理サーバ２１は、この仮想イメージファイルの分散管理を適切に実行する。

図１０は、仮想イメージファイルを２つの仮想イメージ作成＆配信サーバ２４によって分散管理する場合の一態様を示す図である。

図１０に示すように、ここでは、仮想イメージ作成＆配信サーバ［１］２４と仮想イメージ作成＆配信サーバ［２］２４とで、仮想イメージファイルを分散管理する場合を想定する。また、仮想イメージ作成＆配信サーバ［１］２４がマスタ、仮想イメージ作成＆配信サーバ［２］２４がスレーブの役割をそれぞれ担っているものと想定する。

この場合、仮想イメージファイルを構成するマスタファイル８０１、初期化マスタファイル８０２（差分ファイル８０２Ａ）、個別イメージファイル８０３（差分ファイル８０３Ａ）の３つのファイルのうち、マスタファイル８０１および初期化マスタファイル８０２（差分ファイル８０２Ａ）の２つは、マスタたる仮想イメージ作成＆配信サーバ［１］２４側の仮想イメージストレージ２８に格納される。換言すると、マスタファイル８０１および初期化マスタファイル８０２（差分ファイル８０２Ａ）の作成処理は、仮想イメージ作成＆配信サーバ［１］２４によって実行される。

従って、個別イメージファイル８０３（差分ファイル８０３Ａ）のみが、仮想イメージ作成＆配信サーバ［１］２４または仮想イメージ作成＆配信サーバ［２］２４に振り分けられて、各々の仮想イメージストレージ２８に格納される。マスタファイル８０１と初期化マスタファイル８０２（差分ファイル８０２Ａ）とが格納される仮想イメージ作成＆配信サーバ［１］２４側の仮想イメージストレージ２８のフォルダは、仮想イメージ作成＆配信サーバ［２］２４からアクセス可能な共有フォルダとして設定されている。仮想イメージ作成＆配信サーバ［２］２４は、必要に応じて、この共有フォルダからマスタファイル８０１や初期化マスタファイル８０２（差分ファイル８０２Ａ）を読み出す。

管理サーバ２１は、例えばあるリッチクライアント端末１１用の仮想イメージファイルの作成を管理者端末１３から指示されると（図１０の（１））。この仮想イメージファイルを構築するための個別イメージファイル８０３（差分ファイル８０３Ａ）を、仮想イメージ作成＆配信サーバ［１］２４または仮想イメージ作成＆配信サーバ［２］２４のいずれに振り分けるべきかを決定し、振り分け先として決定した仮想イメージ作成＆配信サーバ２４に対して、当該リッチクライアント端末１１用の仮想イメージファイルの作成を指示する（図１０の（２））。

図１１は、管理サーバ２１が仮想イメージファイルの振り分け先を決定する第１の原理を説明するための図である。

管理サーバ２１は、個別イメージファイルの作成処理を開始すると（ステップＣ１）、まず、各仮想イメージ作成＆配信サーバ２４に対して、空き容量の確認を指示する（ステップＣ１．１，Ｃ１．２）。管理サーバ２１は、各仮想イメージ作成＆配信サーバ２４から返送されてきた空き容量の中で最も大きいものを選び、その空き容量を返送してきた仮想イメージ作成＆配信サーバ２４に対して、個別イメージファイルの作成を指示する（ステップＣ１．３）。即ち、管理サーバ２１は、その時々で最も大きい空き容量をもつ仮想イメージ作成＆配信サーバ２４に仮想イメージファイルを振り分ける。

図１１中、（Ａ）は、仮想イメージ作成＆配信サーバ［１］２４の空き容量の方が大きかった場合のシーケンス、（Ｂ）は、仮想イメージ作成＆配信サーバ［２］２４の空き容量の方が大きかった場合のシーケンス、をそれぞれ示している。

また、仮想イメージファイルは、例えば部や課などのセクション単位に一括して作成されることが考えられる。即ち、複数の仮想イメージファイルが一時に作成されることが考えられる。

図１２は、管理サーバ２１が仮想イメージファイルの振り分け先を決定する第２の原理を説明するための図である。図１２には、仮想イメージ作成＆配信サーバ［３］２４がさらに増設された状態が示されている。また、ここでは、複数のリッチクライアント端末１１（例えば１００台）の個別イメージファイルを作成する場合を想定する。

管理者端末１３によって個別イメージファイルを作成するための操作が行われると（ステップＤ１）、管理サーバ２１は、まず、（ダウンロードされなかった、ダウンロード時の削除に失敗した、等によって）残存する更新前の個別イメージファイルを削除する処理を実行する（ステップＤ２）。より具体的には、対象の個別イメージファイルを仮想イメージストレージ２８に格納する仮想イメージ作成＆配信サーバ２４に対して、その個別イメージファイルの削除を指示する（ステップＤ２．１）。

管理サーバ２１は、個別イメージファイルの作成要求数を確認し（ステップＤ３）、その数を算出したら（ステップＤ４）、各仮想イメージ作成＆配信サーバ２４に対して、個別イメージファイルの作成可能数を問い合わせる（ステップＤ５）。この問い合わせを受けた各仮想イメージ作成＆配信サーバ２４は、その時の仮想イメージストレージ２８の空き容量から個別イメージファイルの作成可能数を算出し（ステップＤ５．１）、その算出結果を管理サーバ２１に返送する（ステップＤ５．２）。

管理サーバ２１は、各仮想イメージ作成＆配信サーバ２４から返送された個別イメージファイルの作成可能数の合計が作成要求数よりも多いことを確認し（ステップＤ６）、作成要求数を仮想イメージ作成＆配信サーバ２４の数で割って得た値（商）を、各仮想イメージ作成＆配信サーバ２４に振り分ける個別イメージファイルの数として暫定的に決定する（ステップＤ７）。この仮決め後、管理サーバ２１は、個別イメージファイルの作成可能数が振り分け数に満たない仮想イメージ作成＆配信サーバ２４の不足分を他の仮想イメージ作成＆配信サーバ２４に振り替える等の調整を行う（ステップＤ８）。そして、管理サーバ２１は、各仮想イメージ作成＆配信サーバ２４に対して、最終決定した分の個別イメージファイルの作成を指示する（ステップＤ９）。各仮想イメージ作成＆配信サーバ２４は、この指示を受信し（ステップＤ９．１）、指定された個別イメージファイルの作成を実行する。

即ち、管理サーバ２１は、その時々の空き容量に応じて、各仮想イメージ作成＆配信サーバ２４に対する仮想イメージファイルの振り分けを実行する。

ところで、ＯＳやアプリケーションプログラムは、例えば不具合を修正する等のためのプログラム（更新パッチ）が不定期に提供される場合がある。このような更新パッチを適用するために、例えば１か月毎に、仮想イメージファイルの更新を実行している。即ち、１か月間に提供された更新パッチを蓄積しておき、更新時に、それらを仮想イメージファイルに一括して反映させるといった運用を行っているのが一般的である。

このような運用の場合、更新パッチの反映が最長で１か月間遅延することになる。そこで、管理サーバ１は、例えば１日毎の仮想イメージファイルの更新処理において、更新パッチの有無を判定し、更新パッチが存在したならば、（該当する）仮想イメージファイルの更新処理を実行するように制御する。図６に示した更新パッチ情報２１１Ａは、更新パッチの有無を示す情報である。更新パッチ本体は、例えばクライアント管理システム１内の図示しないファイルサーバ内のストレージに格納される。

図１３は、仮想イメージファイルの更新に関する運用を説明するための図である。

図１３中、（Ａ）は、前述した、例えば１か月毎に、その間に蓄積された更新パッチを一括して仮想イメージファイルに反映させる運用を示している。一方、（Ｂ）は、管理サーバ２１によって制御される、更新パッチが存在したならば、仮想イメージファイルの更新処理を実行する運用を示している。

図１３から明らかなように、（Ｂ）に示す運用によれば、更新パッチをタイムリーに仮想イメージファイルに反映させることが可能となる。また、仮想イメージファイルの更新処理を毎日実施しても、更新パッチが無ければ、無駄な更新処理が実行されてしまうことがない。即ち、管理サーバ２１は、仮想イメージファイルの管理を適切に実行する。

なお、各実施形態の動作制御処理は、ソフトウェア（プログラム）によって実現することができるので、このソフトウェアを格納したコンピュータ読み取り可能な記憶媒体を通じてこのソフトウェアを通常のコンピュータにインストールして実行することにより、各実施形態と同様の効果を容易に実現することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１１…リッチクライアント端末、１２…シンクライアント端末、１３…管理者端末、２１…管理サーバ、２４…仮想イメージ作成＆配信サーバ、２５…シンクライアント実行サーバ、２８…仮想イメージストレージ、２１１…仮想イメージ管理処理部、２１１Ａ…更新パッチ情報、８０１…マスタファイル、８０２…初期化マスタファイル、８０３…個別イメージファイル。

Claims (12)

1. 複数のクライアント端末のデスクトップ環境を管理するクライアント管理システムに適用される情報処理装置であって、
   前記デスクトップ環境用のディスクイメージファイルであって前記複数のクライアント端末それぞれに固有の情報を含まない第１のイメージファイルと、前記第１のイメージファイルを基にして前記複数のクライアント端末それぞれに固有の情報を含む第２のイメージファイルを構築するための差分ファイルとの作成処理を制御する第１の制御手段と、
   前記複数のクライアント端末中の対応するクライアント端末による前記第２のイメージファイルの取得が完了した前記差分ファイルの削除処理を制御する第２の制御手段と、
   を具備する情報処理装置。
2. 前記第１の制御手段は、前記差分ファイルが分散管理されている場合、空き容量の最も大きい拠点に前記差分ファイルが格納されるように制御することを含む請求項１に記載の情報処理装置。
3. 前記第１の制御手段は、前記差分ファイルが分散管理されている場合、各拠点の空き容量に応じて前記差分ファイルが振り分けられて格納されるように制御することを含む請求項１に記載の情報処理装置。
4. 前記第１の制御手段は、前記第１のイメージファイルの更新有無を判定し、更新があった場合に、前記第１のイメージファイルの更新が反映された前記第２のイメージファイルを再構築するための前記差分ファイルを再作成するように前記第２のイメージファイルの更新処理を制御することを含む請求項１に記載の情報処理装置。
5. 複数のクライアント端末のデスクトップ環境を管理するクライアント管理システムに適用される情報処理装置のイメージファイル管理方法であって、
   前記デスクトップ環境用のディスクイメージファイルであって前記複数のクライアント端末それぞれに固有の情報を含まない第１のイメージファイルと、前記第１のイメージファイルを基にして前記複数のクライアント端末それぞれに固有の情報を含む第２のイメージファイルを構築するための差分ファイルとの作成処理を制御し、
   前記複数のクライアント端末中の対応するクライアント端末による前記第２のイメージファイルの取得が完了した前記差分ファイルの削除処理を制御する、
   イメージファイル管理方法。
6. 前記差分ファイルの作成処理を制御することは、前記差分ファイルが分散管理されている場合、空き容量の最も大きい拠点に前記差分ファイルが格納されるように制御することを含む請求項５に記載のイメージファイル管理方法。
7. 前記差分ファイルの作成処理を制御することは、前記差分ファイルが分散管理されている場合、各拠点の空き容量に応じて前記差分ファイルが振り分けられて格納されるように制御することを含む請求項５に記載のイメージファイル管理方法。
8. 前記差分ファイルの作成処理を制御することは、前記第１のイメージファイルの更新有無を判定し、更新があった場合に、前記第１のイメージファイルの更新が反映された前記第２のイメージファイルを再構築するための前記差分ファイルを再作成するように前記第２のイメージファイルの更新処理を制御することを含む請求項５に記載のイメージファイル管理方法。
9. 複数のクライアント端末のデスクトップ環境を管理するクライアント管理システムに適用されるコンピュータを、
   前記デスクトップ環境用のディスクイメージファイルであって前記複数のクライアント端末それぞれに固有の情報を含まない第１のイメージファイルと、前記第１のイメージファイルを基にして前記複数のクライアント端末それぞれに固有の情報を含む第２のイメージファイルを構築するための差分ファイルとの作成処理を制御する第１の制御手段、
   前記複数のクライアント端末中の対応するクライアント端末による前記第２のイメージファイルの取得が完了した前記差分ファイルの削除処理を制御する第２の制御手段、
   として機能させるためのプログラム。
10. 前記第１の制御手段は、前記差分ファイルが分散管理されている場合、空き容量の最も大きい拠点に前記差分ファイルが格納されるように制御することを含む請求項９に記載のプログラム。
11. 前記第１の制御手段は、前記差分ファイルが分散管理されている場合、各拠点の空き容量に応じて前記差分ファイルが振り分けられて格納されるように制御することを含む請求項９に記載のプログラム。
12. 前記第１の制御手段は、前記第１のイメージファイルの更新有無を判定し、更新があった場合に、前記第１のイメージファイルの更新が反映された前記第２のイメージファイルを再構築するための前記差分ファイルを再作成するように前記第２のイメージファイルの更新処理を制御することを含む請求項９に記載のプログラム。

Images