JP6160688B2 - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Description

本発明は、ソフトウェアのインストールにおける障害発生時の処理に関する。

オペレーティングシステム（以下、ＯＳと記す）がプレインストールされているサーバの初期設定処理は、初回の電源投入時に自動で行われる。図１は、サーバの初期設定処理の動作フローを示す。初期設定処理では、まずアプリケーションに対応するドライバのインストールが行われる（Ｓ１００１）。そして、アプリケーションのインストールが行われ（Ｓ１００２）、ユーザの環境に応じたアプリケーションの固有設定が行われる（Ｓ１００３）。そして、アプリケーションが正しくインストールされたか否かを確認する最終チェックが行われる（Ｓ１００４）。この初期設定処理中にハードウェア故障、ソフトウェアエラー、電源切断等が発生し、処理が予期せず途中で失敗した場合（Ｓ１００５）、どの処理まで正しく行われたかを記録していないため処理を途中から再開することができない。この場合、ユーザはＯＳのインストール（リカバリ）から再度行わなければならず（Ｓ１００６）、そのリカバリには多大な時間がかかる。

一方、複数のソフトウェアのインストールが完了するまでの時間を削減するための第１の技術がある。この第１の技術は、複数のソフトウェアのインストールをコンピュータに連続して実行させることを前提とする。そして、この第１の技術は、ＯＳが再起動した時に自己プログラムが自動的に起動されるように設定する機能をコンピュータに実現させる。さらに、第１の技術は、上記自己プログラムが起動した時に、上記複数のソフトウェアのインストールにおける進捗状況を把握し、上記複数のソフトウェアのインストールを未実行または異常終了の位置から再開する機能をコンピュータに実現させる。

また、ＯＳの再起動を高速に行う第２の技術がある。この技術は、主記憶装置上のＯＳの初期化データを初期化データ退避領域に退避するためのデータ退避手段と、情報処理装置に接続された入出力装置の停止制御を行う入出力装置制御手段と、を備える。さらに、第２の技術は、再起動の可否を指定し、ＯＳプログラムの特定番地に制御を移す再起動制御手段と、データ退避領域から初期化データを回復するためのデータ回復手段と、を備える。

特開２００４−３０２９２９号公報 特開平１１−２４９３６号公報

しかしながら、第１の技術では、停電による予期せぬ電源断が起こった際に、正しいエラー処理が行われないため処理状況が記録できない。そのため再度処理を行う際にはインストール未実施の処理として最初からインストールが再開される。

さらには、第１及び第２の技術では、既に途中までインストール処理が進行した状態で処理が再開されることになる。この場合、処理途中のファイルが残存しているため、インストールを再開できない場合や再会できたとしてもインストールを正しく完了することを保証できない。そのため、問題発生後に初期セットアップを継続する場合、手作業でどの処理まで実施されたかを確認しなければならず、作業が煩雑になり、時間がかかる。

また、第２の技術では、１度目の実行で障害が発生するまでの時間分の処理時間がかかる。
そこで、１つの側面では、本発明は、ソフトウェアのインストール処理において障害が発生した場合に、処理の再開までに要する時間を削減することを目的とする。

一態様の情報処理装置は、記憶部、保存処理部、処理部、検出部、進捗管理部、復元部、及び制御部を含む。記憶部は、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を記憶する。保存処理部は、記憶部に記憶された変更対象ファイルの所在及びファイル名を用いて、変更対象ファイルを取得して保存する。処理部は、インストールを実行する。検出部は、インストールの途中で発生した障害を検出する。進捗管理部は、インストールの進捗状況を示す進捗情報を取得し、障害が検出された場合、進捗情報に基いて、障害が発生した時の所定の処理を障害時処理として特定する。復元部は、障害時処理において変更されたファイルを、該ファイルに対応する保存された変更対象ファイルを用いて復元する。制御部は、障害時処理の開始時点からインストールを再開する。

本実施形態に係る情報処理システムによれば、ソフトウェアのインストール処理において障害が発生した場合に、処理の再開までに要する時間を削減することができる。

サーバの初期設定処理の動作フローを示す。 本実施形態に係る情報処理装置の機能ブロック図の一例を示す。 本実施形態に係る情報処理装置の構成の一例を示す。 本実施形態に係る進捗管理テーブルの一例を示す。 本実施形態に係るアプリ変更情報の一例を示す。 バックアップ処理部によりファイルがバックアップされる様子を説明するための図である。 アプリ変更情報の追加情報一覧に記載されているファイル名のファイルを削除する様子を説明するための図である。 アプリ環境バックアップ情報からインストール対象ファイルを書き戻す様子を説明するための図である。 本実施形態における初期化処理の全体の処理フローを示す。 本実施形態におけるインストール対象決定処理の動作フローを示す。 本実施形態におけるアプリケーションインストール処理の動作フローを示す。 本実施形態におけるドライバのインストール、アプリケーションのインストール、固有設定の動作フローを示す。 本実施形態におけるリトライ処理の動作フローを示す。 本実施形態におけるリカバリ処理の動作フローを示す。 本実施形態に係る情報処理装置のハードウェア構成の一例を示す。

図１は、本実施形態に係る情報処理装置の機能ブロック図の一例である。情報処理装置１は、記憶部２、保存処理部３、処理部４、検出部５、進捗管理部６、復元部７、及び制御部８を含む。

記憶部２は、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を記憶する。また、記憶部２は、所定の処理において追加される追加対象ファイルの所在及びファイル名を記憶する。また、記憶部２は、所定の処理が正常に終了した場合の正常状態情報を記憶する。

保存処理部３は、記憶部に記憶された変更対象ファイルの所在及びファイル名を用いて、変更対象ファイルを取得して保存する。
処理部４は、インストールを実行する。

検出部５は、インストールの途中で発生した障害を検出する。また、検出部５は、障害を検出するとともに障害の内容を示す障害情報を収集する。

進捗管理部６は、インストールの進捗状況を示す進捗情報を取得し、障害が検出された場合、進捗情報に基いて、障害が発生した時の所定の処理を障害時処理として特定する。また、進捗管理部６は、所定の処理の前後に、進捗情報を取得する。また、進捗管理部６は、正常状態情報に基いて所定の処理が正常に終了したか否かを判定し、所定の処理が正常に終了していないと判定した場合、所定の処理を障害時処理として特定する。また、進捗管理部６は、障害情報、進捗情報、または上記判定の結果に基いて、障害時処理が再開可能か否かを判定する。

復元部７は、障害時処理において変更されたファイルを、該ファイルに対応する保存された変更対象ファイルを用いて復元する。また、復元部７は、障害時処理において追加されたファイルを、記憶部に記憶された追加対象ファイルの所在及びファイル名に基いて削除する。また、復元部７は、進捗管理部により障害時処理が再開可能でないと判定された場合、障害時処理において変更されたファイルを、保存された変更対象ファイルを用いて復元する。

制御部８は、障害時処理の開始時点からインストールを再開する。
図３は、本実施形態に係る情報処理装置の構成の一例を示す。本実施形態に係る情報処理装置１は、例えばサーバであり、インストール処理部１１、記憶部１２、制御部１３、バックアップ処理部１４、リカバリ処理部１５、及びチェック処理部１６を含む。

インストール処理部１１は、処理部４、検出部５の一例である。記憶部１２は、記憶部２の一例である。制御部１３は、進捗管理部６、制御部８の一例である。バックアップ処理部１４は、保存処理部３の一例である。リカバリ処理部１５は、復元部７の一例である。チェック処理部１６は、進捗管理部６の一例である。

インストール処理部１１は、アプリケーションのインストール、そのアプリケーションのインストールに必要なドライバのインストール、及びユーザ環境に応じたアプリケーションの固有設定を行う。

また、インストール処理部１１は、インストール処理中に発生した障害を検出し、障害が発生したことを制御部１３に通知する。またその際、インストール処理部１１は、障害の内容及び障害発生時のシステムの状態を示す情報である障害情報を記憶部１２に格納し、障害情報の格納が終了したら、チェック処理部１６に障害情報の格納が終了したことを通知する。

さらに、インストール処理部１１は、インストール処理のログ等の動作情報を記憶部１２に格納する。

記憶部１２は、インストール処理の進捗状況を把握するための情報である進捗管理テーブル、各アプリケーションが追加・変更する情報の一覧の情報であるアプリ変更情報、及び、インストールが正常に行われたか否かを判定するための設定チェック情報を記憶する。また、記憶部１２には、障害発生時に障害情報が保存される領域、バックアップ処理部１４によりバックアップ対象のファイルが保存される領域、及び、インストール処理の動作情報が格納される領域が確保される。尚、記憶部１２には、インストールされるドライバ及びアプリケーションに関するファイルも格納される。

先ず、進捗管理テーブルについて説明する。進捗管理テーブルは、アプリケーション毎のインストール処理の進行状況を把握するために用いられる情報である。進捗管理テーブルは、インストール対象のアプリケーション毎に、各々のアプリケーションに対応付けて作成される。図４は、本実施形態に係る進捗管理テーブルの一例を示す。進捗管理テーブル２０は、ステージ２１、開始フラグ２２、完了フラグ２３、成功フラグ２４、失敗フラグ２５、及び識別情報２９のデータ項目を有する。

ステージ２１は、１つのアプリケーションのインストールにおける処理の段階を示している。本実施形態においては、アプリケーションのインストールは、処理の内容に基づいて３つの段階に分けられる。３つの段階とはすなわち、ドライバインストール、アプリケーションインストール、固有設定である。ドライバインストールは、アプリケーションをインストールするためのシステム要件であるようなドライバのインストールが行われる段階である。アプリケーションインストールは、アプリケーションそのもののインストールが行われる段階である。固有設定は、アプリケーションのインストール後にユーザの環境に応じて設定項目が設定される段階である。尚、ステージ２１で示す段階は３つに限定されず、例えば、ドライバインストール前の設定段階等を設けてもよい。

開始フラグ２２は、ステージ２１の処理が開始されたことを示すフラグである。開始フラグ２２は、ステージ２１の処理の開始直前に制御部１３により設定される。

完了フラグ２３は、ステージ２１の処理が完了したことを示すフラグである。完了フラグ２３は、ステージ２１の処理の完了直後に制御部１３により設定される。

成功フラグ２４は、ステージ２１の処理が正常に完了したことを示すフラグである。成功フラグ２４は、ステージ２１の処理が正常に完了したと判定された場合に制御部１３により設定される。ここで、ステージ２１の処理の終了後に行われる、ステージ２１の処理が正常に完了したか否かの判定処理を設定チェックと記す。設定チェックの詳細は後ほど説明する。

失敗フラグ２５は、ステージ２１の処理が正常に完了していないことを示すフラグである。失敗フラグ２５は、ステージ２１の処理が正常に行われていないと判定された場合に制御部１３により設定される。

識別情報２９は、進捗管理テーブル２０がどのインストール対象アプリケーションと対応付けられているかを示す情報である。

次に、アプリ変更情報について説明する。アプリ変更情報は、各アプリケーションのインストールの処理段階ごとに作成され、各々の処理において追加・変更される情報の一覧である。すなわち、アプリ変更情報は、インストール対象のアプリケーション毎に管理され、さらに、ステージ２１の段階毎に管理される。

図５は、本実施形態に係るアプリ変更情報の一例を示す。アプリ変更情報３０は、対応処理情報３１、追加情報一覧３２、及び変更情報一覧３３を含む。

対応処理情報３１は、アプリ変更情報３０がどのアプリケーションのインストールにおけるどのステージ２１の処理に対応するかを示す情報である。以下の説明では、対応処理情報３１が指し示すステージ２１の処理を対象処理と記す。

追加情報一覧３２は、対象処理が実行されることによって追加される情報の一覧である。追加情報一覧３２は、追加ファイル一覧３４と追加レジストリキー一覧３５を含む。追加ファイル一覧３４は、対象処理において追加されるファイル（フォルダまたはディレクトリを含む）の名称の一覧である。この名称は、ファイルの所在情報を含むフルパスで表される。追加レジストリキー一覧３５は、対象処理において追加されるレジストリキーの名称の一覧である。尚、レジストリの存在しないＵｎｉｘ（登録商標）等のＯＳにおいては、追加レジストリキー一覧３５は省略できる。

変更情報一覧３３は、対象処理が実行されることによって変更される情報の一覧である。変更情報一覧３３は、変更ファイル一覧３６と変更レジストリキー一覧３７を含む。変更ファイル一覧３６は、対象処理において変更されるファイル（フォルダまたはディレクトリを含む）の名称の一覧である。この名称は、ファイルの所在情報を含むフルパスで表される。変更レジストリキー一覧３７は、対象処理において変更されるレジストリキーの名称の一覧である。尚、レジストリの存在しないＵｎｉｘ（登録商標）等のＯＳにおいては、変更レジストリキー一覧３７は省略できる。

次に、設定チェック情報について説明する。設定チェック情報は、インストール対象アプリケーション毎のステージ２１のそれぞれにおいて、処理が正常に行われたか否かを判定するために用いられる情報である。設定チェック情報には、例えば、処理が正常に終了した場合に設定されているべき設定項目とその値が記載されている。

尚、アプリ変更情報３０、設定チェック情報は、予めサーバに格納されているものとする。

制御部１３は、インストール処理の進捗状況を管理する。そのために、制御部１３は、インストール処理における各処理の定められた時点において進捗状況のステータスを保存する処理を行う。さらに、制御部１３は、インストール処理の途中で障害が発生した場合に、障害が発生した時点においてどのステージ２１まで処理が完了していたかを特定する処理を行う。

先ず、インストール処理における各処理の定められた時点において、制御部１３が進捗状況のステータスを保存する処理の例を説明する。制御部１３は、各ステージ２１の処理の開始時点において開始フラグ２２を設定する。また、制御部１３は、各ステージ２１の処理の完了時点において完了フラグ２３を設定する。完了フラグ２３の設定後、制御部１３は、チェック処理部１６に対して設定チェックの実行指示を行う。さらに、制御部１３は、ステージ２１の設定チェックの結果、ステージ２１の処理が正常に行われたと判定された場合に成功フラグ２４を設定する。そして、制御部１３は、設定チェックの結果、ステージ２１の処理が正常に行われていないと判定された場合に失敗フラグ２５を設定する。

次に、インストール処理の途中で障害が発生した場合に、障害が発生した時点においてどのステージ２１まで処理が完了していたかを制御部１３が特定する例を説明する。障害が発生すると制御部１３は、インストール処理部１１から障害が発生したことを通知される。すると、制御部１３は、進捗管理テーブル２０を参照することにより障害発生時までに完了していた処理を特定する。

例えば、障害発生時の進捗管理テーブル２０の状態が図４に示すものであった場合を考える。制御部１３は、進捗管理テーブル２０の識別情報２９の値を参照することにより、どのアプリケーションのインストール処理中に障害が発生したかを特定することができる。図４の例の場合、識別情報２９には「アプリケーションＡ」が設定されているので、制御部１３は、障害が発生したときにはアプリケーションＡのインストール処理が行われていたと判定する。そして、ステージ２１の値が「ドライバインストール」であるレコード（行）の成功フラグ２４の値が「ｔｒｕｅ」に設定されていることを確認することにより、制御部１３はドライバのインストールは正常に完了した状態であることを判別できる。そして、制御部１３はステージ２１の値が「アプリケーションインストール」であるレコードの開始フラグ２２の値が「ｔｒｕｅ」に設定されていることを確認することにより、障害が発生したのはアプリケーションインストールの処理開始後であると判別できる。さらに、制御部１３は「アプリケーションインストール」であるレコードの完了フラグ２３の値が設定されていないことを確認することにより、障害が発生したのはアプリケーションのインストールの完了前であることを判別できる。

制御部１３は、障害が発生した時点においてどのステージ２１まで処理が完了していたかを特定したら、その特定した時点の直後の処理の開始時点からインストールを再開するように、インストール処理部１１に指示する。

バックアップ処理部１４は、ステージ２１の各段階の処理の開始前に、その段階の処理により変更されるファイルをバックアップする。バックアップ対象となるファイルは、バックアップ処理部１４が、次に実行される段階の処理に対応処理情報３１の値が一致するアプリ変更情報３０を検索し、そのアプリ変更情報３０の変更情報一覧３３を参照することによって特定する。

図６は、バックアップ処理部１４によりファイルがバックアップされる様子を説明するための図である。先ず、バックアップ処理部１４は、変更情報一覧３３の変更ファイル一覧３６を参照して、バックアップ対象ファイルを認識する。また、バックアップ処理部１４は、変更情報一覧３３の変更レジストリキー一覧３７を参照して、バックアップ対象のレジストリキーを認識する（Ｓ６１）。次に、バックアップ処理部１４は、認識したバックアップ対象ファイルを所定の退避領域にコピーする。また、バックアップ処理部１４は、認識したバックアップ対象のレジストリキーの値を、レジストリキーの名称と対応付けて、所定の退避領域に格納する。ここでバックアップしたファイル情報とレジストリキー情報をアプリ環境バックアップ情報４２と記す。

リカバリ処理部１５は、インストールの途中で障害が発生した場合、インストール対象のアプリケーションの再インストールを行う前に、サーバを各ステージ２１の開始前の環境に復旧させる。これにより、前回インストールした際に残っているファイルやレジストリ情報などの影響により、再インストールが失敗することを防ぐ。

具体的には、リカバリ処理部１５は、障害が発生した際に、最後にバックアップ処理部１４がバックアップを行った時点にサーバの環境を戻す。バックアップ処理部１４はステージ２１の処理ごとにバックアップを取得することから、最後にバックアップを行った時点とはすなわち、障害が発生した際のステージ２１の処理開始直前の時点である。

障害が発生すると、リカバリ処理部１５は、チェック処理部１６からリカバリの実行命令を受け取る。すると、リカバリ処理部１５は、障害がどのアプリケーションのどの段階の処理の実行中に発生したかの情報を制御部１３から取得する。以下の説明では、障害が発生したときのアプリケーションの処理段階を障害発生時処理と記す。尚、障害が発生してもチェック処理部１６からリカバリの実行命令を受けない場合は、リカバリ処理部１５は、リカバリ処理は行わない。これは、詳しくは後ほど説明するが、発生した障害が、リカバリを行わなくてもいいと判断されるような内容の障害である場合には、リカバリを実行せずにインストール処理を再開できるようにするためである。

リカバリ処理部１５は、対応処理情報３１の値が障害発生時処理を示すアプリ変更情報３０を特定する。そして、リカバリ処理部１５は、特定したアプリ変更情報３０の追加情報一覧３２を参照し、障害発生時処理において追加された可能性のあるファイルを削除する。

図７は、アプリ変更情報３０の追加情報一覧３２に記載されているファイル名のファイルを削除する様子を説明するための図である。リカバリ処理部１５は、追加情報一覧３２の追加ファイル一覧３４を参照し、削除対象ファイルを認識する。また、リカバリ処理部１５は、追加情報一覧３２の追加レジストリキー一覧３５を参照し、削除対象のレジストリキーを認識する（Ｓ７１）。リカバリ処理部１５は、Ｓ７１で認識した削除対象ファイルを、インストール対象ディスク領域４１から全て削除する。また、リカバリ処理部１５は、Ｓ７１で認識した削除対象のレジストリキーの値をすべて削除する（Ｓ７２）。

次にリカバリ処理部１５は、特定したアプリ変更情報３０の変更情報一覧３３に記載されている対象ファイルまたはレジストリキーをアプリ環境バックアップ情報４２から書き戻す。

図８は、アプリ環境バックアップ情報４２からインストール対象ファイルを書き戻す様子を説明するための図である。リカバリ処理部１５は、変更情報一覧３３の変更ファイル一覧３６を参照し、書き戻し対象ファイルを認識する。また、リカバリ処理部１５は、変更情報一覧３３の変更レジストリキー一覧３７を参照し、書き戻し対象のレジストリキーを認識する（Ｓ８１）。リカバリ処理部１５は、Ｓ８１で認識した書き戻し対象ファイルをアプリ環境バックアップ情報４２からインストール対象ディスク領域４１にコピーする。また、リカバリ処理部１５は、Ｓ８１で認識した書き戻し対象のレジストリキーとその値を、アプリ環境バックアップ情報４２を参照して、レジストリに登録する（Ｓ８２）。

チェック処理部１６は、設定チェック、システムチェック、最終チェックを行う。
設定チェックでは、チェック処理部１６は、アプリケーションが正常にインストールされたか否かを判定する。設定チェックは、チェック処理部１６がステージ２１の処理終了後に制御部１３から設定チェックの実行指示を受信した場合に開始される。設定チェックの結果は制御部１３に通知される。

具体的には、チェック処理部１６は、各アプリケーションのステージ毎の設定チェック情報を参照し、設定チェック情報に記載された設定項目の値が正常な値か否かを判定することにより、アプリケーションが正常にインストールされたか否かを判定する。例えば、チェック処理部１６は、サーバのハードウェアの情報を取得し、そのハードウェアに合ったアプリケーションの設定になっているか否かを、設定チェック情報を用いてチェックする。

次に、システムチェックについて説明する。システムチェックでは、チェック処理部１６は、インストール処理中に障害が発生した場合に、リカバリ処理部１５によるリカバリを行わずに再度インストール処理を行うことができるか否かを判定する。障害が発生すると、チェック処理部１６は、先ず、インストール処理部１１から障害情報の格納が終了したことを通知される。すると、チェック処理部１６は、システムチェックを開始する。

具体的には、チェック処理部１６は、先ず、障害発生後既にリカバリ済みか否かを判定する。障害発生後既にリカバリ済みと判定した場合は、チェック処理部は、リカバリ不要であると判定する。

障害発生後リカバリ未実施であると判定した場合、チェック処理部１６は、障害発生時にインストール処理部１１により記憶部１２に保存されたステータス情報を参照し、発生した障害の内容を判定して、リカバリが不要か否かを判定する。これは、例えば、障害の内容が所定の時間の経過により解消するようなエラーの場合は、その時間が経過すれば、リカバリを行わずに再度インストール処理を行うことができる場合があるからである。ここで、障害の内容によっては、インストール処理の再開時点は、エラーが発生した時点としてもよい。

障害の内容からリカバリ不要ではないと判定した場合、チェック処理部１６は、進捗管理テーブル２０を参照してリカバリ不要か否かを判定する。進捗管理テーブル２０の所定のレコードにおいて、開始フラグ２２が設定されていて、完了フラグ２３が設定されていない場合は、チェック処理部１６は、処理途中で障害が発生したと判定し、リカバリが必要であると判定する。また、所定のレコードに失敗フラグ２５が設定されている場合は、チェック処理部１６はインストールが正常に行われていないと判定し、リカバリが必要であると判定する。また、所定のレコードにおいて、開始フラグ２２、完了フラグ２３、及び成功フラグ２４が設定されている場合は、チェック処理部１６はリカバリ不要であると判定する。

チェック処理部１６は、システムチェックにおいてリカバリが必要であると判定した場合、リカバリ処理部１５にリカバリ処理の実行を指示する。
次に、最終チェックについて説明する。最終チェックでは、チェック処理部１６は、例えば、ハードウェア情報を取得し、設定チェック情報または動作情報を参照することにより、インストールされるべきドライバ、アプリケーション、固有設定が正しく行われているか否かをチェックする。また、チェック処理部１６は、ステータス保存部に保存している結果の確認とアプリ変更情報３０を確認することによって、インストールされるべきドライバ、アプリケーション、固有設定が正しく行われているかのチェックを行う。最終チェックは、ステージ２１のすべての段階が終了した後に実行される。

次に、本実施形態の動作フローを説明する。ＯＳインストール完了後の初期設定処理では、複数のアプリケーションがインストールされる。図９に本実施形態における初期設定処理の全体の処理フロー図を示す。

初期設定処理では、先ずインストール対象決定処理が行われる（Ｓ１０１）。インストール対象決定処理は、インストール対象のアプリケーションを決定するための処理である。この処理の詳細は後ほど説明する。

次に、Ｓ１０１で決定されたアプリケーションを対象として所定の順番でアプリケーションのインストールが行われる（Ｓ１０２）。そして、制御部１３は、Ｓ１０１で決定されたアプリケーションのうちすべてのアプリケーションのインストールが終了したか否かを判定する（Ｓ１０３）。すべてのインストール対象アプリケーションがインストールされていないと判定された場合は（Ｓ１０３でＮｏ）、Ｓ１０２においてインストール未実施のアプリケーションのインストールが行われる。すべてのインストール対象アプリケーションがインストールされたと判定された場合は（Ｓ１０３でＹｅｓ）、初期設定処理は終了する。

次にインストール対象決定処理の詳細を説明する。図１０は、本実施形態におけるインストール対象決定処理の動作フローを示す。

先ず、制御部１３は、サーバのハードウェアの情報取得を行う（Ｓ２０１）。具体的には、制御部１３は、サーバ本体の情報、すなわち、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、デバイス、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の情報を取得する。

次に、制御部１３は、サーバのソフトウェアの情報取得を行う（Ｓ２０２）。具体的には、制御部１３は、サーバにインストールされているソフトウェアの情報を取得し、その情報とサーバ本体に対応するアプリケーション情報とを比較してインストールを行うアプリケーション情報を取得する。

次に、制御部１３は、インストール対象のアプリケーションを決定する（Ｓ２０３）。具体的には、制御部１３は、Ｓ２０１で取得したハードウェア情報とＳ２０２で取得したソフトウェア情報とからインストール対象のアプリケーションを特定する。制御部１３は、Ｓ２０２で取得したアプリケーション情報のうち、Ｓ２０１で取得したハードウェア情報からインストール可能なアプリケーションを特定し、そのアプリケーションをインストール対象のアプリケーションと決定する。インストール対象のアプリケーションが決定された段階で、制御部１３は、アプリケーション毎の進捗管理テーブル２０を作成する。そのとき、進捗管理テーブル２０の識別情報２９には、対応する対象アプリケーションの識別情報を設定する。尚、進捗管理テーブル２０は、作成時には、ステージ２１及び識別情報２９以外のデータ項目の値は未設定の状態とする。本実施形態では、各々のステージ２１の値が「ドライバインストール」、「アプリケーションインストール」、「固有設定」である３つのレコードが作成される。

尚、制御部１３は、インストール対象のアプリケーションを決定するとともに、決定したアプリケーションのインストールの順序を、各アプリケーション間の依存関係などを考慮して決定してもよい。また、各アプリケーションのそれぞれの処理のステージ２１は、アプリ変更情報３０と対応付けられているので、インストールの順序が決定されるとともに、インストール処理全体で使用されるアプリ変更情報３０も決まることとなる。

次に、Ｓ２０３で決定された個々のアプリケーションのインストール処理（Ｓ１０２）の詳細について説明する。図１１は、本実施形態におけるアプリケーションインストール処理の動作フローを示す。

先ず、アプリケーションのインストール要件となるようなドライバのインストールが行われる（Ｓ３０１）。そして、アプリケーションのインストールが行われ（Ｓ３０２）、ユーザの環境に応じたアプリケーションの固有設定が行われる（Ｓ３０３）。そして、最後にシステム全体のアプリケーションが正しくインストールされたか否かを確認する最終チェックがチェック処理部１６により行われ（Ｓ３０４）、アプリケーションのインストールが終了する。

Ｓ３０１〜Ｓ３０３において、障害が発生した場合、インストール処理部１１は障害を検出し、障害情報を記憶部１２に保存する（Ｓ３０５）。そして、インストールのリトライ処理が開始される（Ｓ３０６）。インストールのリトライ処理については、後ほど詳細に説明する。リトライ処理が終了するとアプリケーションのインストール処理が終了する。

次に、ドライバのインストール（Ｓ３０１）、アプリケーションのインストール（Ｓ３０２）、アプリケーション固有の設定（Ｓ３０３）の処理の詳細を説明する。図１２は、本実施形態におけるドライバのインストール、アプリケーションのインストール、または固有設定の動作フロー図である。

先ず、バックアップ処理部１４は、バックアップ処理を行う。バックアップ処理部１４は、記憶部１２に格納されているアプリ変更情報３０の変更情報一覧３３からバックアップ対象のファイル及びレジストリキーを特定する。そして、バックアップ処理部１４はバックアップ対象のファイル及びレジストリキーの情報をインストール対象ディスク領域４１から所定の退避領域にアプリ環境バックアップ情報４２としてコピーする（Ｓ４０１）。

次に、制御部１３は、進捗管理テーブル２０の開始フラグ２２を設定する処理を行う（Ｓ４０２）。例えば、制御部１３は、ステージ２１の値が現在の処理段階に一致するレコードの開始フラグ２２に、「ｔｒｕｅ」を格納する。

次に、インストール処理部１１は、処理段階がドライバのインストールの場合は、ドライバのインストールを、処理段階がアプリケーションのインストールの場合はアプリケーションのインストールを、処理段階が固有設定の場合は固有設定を行う（Ｓ４０３）。尚、図１１において説明したように、Ｓ４０３の処理中に障害が発生した場合、制御部１３は、ステータス保存を行い（Ｓ３０５）、リトライ処理が開始される（Ｓ３０６）。

次に、制御部１３は、進捗管理テーブル２０の完了フラグ２３を設定する処理を行う（Ｓ４０４）。例えば、制御部１３は、ステージ２１の値が現在の処理段階に一致するレコードの完了フラグ２３に「ｔｒｕｅ」を格納する。

次に、チェック処理部１６は、Ｓ４０３の処理が正常に行われたか否かを判定する設定チェックを行う（Ｓ４０５）。設定チェックにおいて、Ｓ４０３の処理が正常に行われたと判定された場合（Ｓ４０５でＹＥＳ）、制御部１３は、進捗管理テーブル２０の成功フラグ２４を設定する処理を行う（Ｓ４０６）。例えば、制御部１３は、ステージ２１の値が現在の処理段階に一致するレコードの成功フラグ２４に「ｔｒｕｅ」を格納する。

Ｓ４０５の設定チェックにおいてＳ４０３の処理が正常に行われなかったと判定された場合（Ｓ４０５でＮｏ）、制御部１３は、進捗管理テーブル２０の失敗フラグ２５を設定する処理を行う（Ｓ４０７）。例えば、制御部１３は、ステージ２１の値が現在の処理段階に一致するレコードの失敗フラグ２５に「ｔｒｕｅ」を格納する。そして、処理はＳ３０６のリトライ処理に移る。

次に、リトライ処理（Ｓ３０６）について詳細に説明する。図１３は、本実施形態におけるリトライ処理の動作フローを示す。

先ず、チェック処理部１６はシステムチェックを行い、リカバリ処理が不要か否かを判定する（Ｓ５０１）。

リカバリ不要と判定された場合（Ｓ５０１でＹＥＳ）、制御部１３はドライバチェックを行う（Ｓ５０２）。ドライバチェックにおいては、障害発生時にドライバのインストール処理が既に行われていたか否かがチェックされる。制御部１３は、進捗管理テーブル２０のステージ２１の値が「ドライバインストール」であるレコードの成功フラグ２４（または完了フラグ２３）を確認し、ドライバのインストールが完了していたか否かを判定する。ドライバのインストールが完了していたと判定されると（Ｓ５０２でＹｅｓ）、処理はＳ５０３に遷移する。ドライバのインストールが終了していなかったと判定されると（Ｓ５０２でＮｏ）、処理はＳ５０５に遷移する。

Ｓ５０２においてドライバのインストールが完了していたと判定された場合、制御部１３はアプリチェックを行う（Ｓ５０３）。アプリチェックにおいては、障害発生時にアプリケーションのインストール処理が既に行われていたか否かがチェックされる。制御部１３は、進捗管理テーブル２０のステージ２１の値が「アプリケーションインストール」であるレコードの成功フラグ２４（または完了フラグ２３）を確認し、アプリケーションのインストールが完了していたか否かを判定する。アプリケーションのインストールが完了していたと判定されると（Ｓ５０３でＹｅｓ）、処理はＳ５０４に遷移する。アプリケーションのインストールが終了していなかったと判定されると（Ｓ５０３でＮｏ）、処理はＳ５０６に遷移する。

Ｓ５０３においてアプリケーションのインストールが正常に終了していたと判定された場合、制御部１３は、固有設定チェックを行う（Ｓ５０４）。固有設定チェックにおいては、障害発生時にアプリケーションの固有設定処理が既に行われていたか否かがチェックされる。制御部１３は、進捗管理テーブル２０のステージ２１の値が「固有設定」であるレコードの成功フラグ２４（または完了フラグ２３）を確認し、固有設定が完了していたか否かを判定する。固有設定が完了していたと判定すると（Ｓ５０４でＹｅｓ）、処理はＳ５０８に遷移する。固有設定が終了していなかったと判定すると（Ｓ５０４でＮｏ）、処理はＳ５０７に遷移する。

Ｓ５０５において、インストール処理部１１はドライバインストールを行う。そして、インストール処理部１１は、アプリケーションのインストールを行う（Ｓ５０６）。次に、インストール処理部１１は固有設定を行う（Ｓ５０７）。

そして、チェック処理部１６は最終チェックを行う（Ｓ５０８）。チェック処理部１６は、インストールされるべきドライバ、アプリケーション、固有設定が正しく行われているか否かを確認する。尚、Ｓ５０５、Ｓ５０６、Ｓ５０７、Ｓ５０８のそれぞれの具体的な処理は、Ｓ３０１、Ｓ３０２、Ｓ３０３、Ｓ３０４のそれぞれと同様である。

Ｓ５０１において、リカバリが必要であると判定された場合（Ｓ５０１でＮｏ）、リカバリ処理が開始される（Ｓ５０９）。

次に、リカバリ処理（Ｓ５０９）について詳細に説明する。図１４は、本実施形態におけるリカバリ処理の動作フローを示す。

先ず、制御部１３は、システムの再起動を行う（Ｓ６０１）。再起動が終了したら、制御部１３は、障害が発生した時点においてどのステージ２１まで処理が完了していたかを特定し、リカバリ処理部１５は、リカバリ処理を行う（Ｓ６０２）。そして、制御部１３は、再度システムの再起動を行う（Ｓ６０３）。そして、処理は、リトライ処理（Ｓ３０６）に遷移する。

図１５は、本実施形態に係る情報処理装置１のハードウェア構成の一例を示す。サーバは、図１５に示すように、ＣＰＵ２０１、メモリ２０２、記憶装置２０３、読取部２０４、着脱可能記録媒体２０５、通信インターフェース２０６、入出力部２０７を含む。なお、ＣＰＵ２０１、メモリ２０２、記憶装置２０３、読取部２０４、通信インターフェース２０６、及び入出力部２０７は、例えば、バス２０９を介して互いに接続されている。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、メモリ２０２を利用して上述のフローチャートの手順を記述したプログラムを実行する。ＣＰＵ２０１は、インストール処理部１１、制御部１３、バックアップ処理部１４、リカバリ処理部１５、チェック処理部１６の一部または全部の機能を提供する。

メモリ２０２は、例えば半導体メモリであり、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）領域およびＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）領域を含んで構成される。メモリ２０２は、記憶部１２の一部または全部の機能を提供する。

記憶装置２０３は、例えばハードディスクであり、記憶部１２の機能の一部または全部の機能を提供する。なお、記憶装置２０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置２０３は、外部記録装置であってもよい。

読取部２０４は、ＣＰＵ２０１の指示に従って着脱可能記録媒体２０５にアクセスする。着脱可能記録媒体２０５は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。

通信インターフェース２０６は、ＣＰＵ２０１の指示に従ってネットワークを介してデータを送受信する。
入出力部２０７は、例えば、ユーザからの指示を受け付けるデバイスに相当する。

実施形態を実現するための情報処理プログラムは、例えば、下記の形態でサーバに提供される。
（１）記憶装置２０３に予めインストールされている。
（２）着脱可能記録媒体２０５により提供される。
（３）ネットワークを介して提供される。

尚、サーバは、種々のデバイスを含む構成としてもよい。そのようなデバイスには、例えば、Ｌｏｃａｌ Ａｒｅａ ＮｅｔｗｏｒｋコントローラやＶｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙコントローラがある。

尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 情報処理装置
２ 記憶部
３ 保存処理部
４ 処理部
５ 検出部
６ 進捗管理部
７ 復元部
８ 制御部
１１ インストール処理部
１２ 記憶部
１３ 制御部
１４ バックアップ処理部
１５ リカバリ処理部
１６ チェック処理部
２０ 進捗管理テーブル
２１ ステージ
２２ 開始フラグ
２３ 完了フラグ
２４ 成功フラグ
２５ 失敗フラグ
２９ 識別情報
３０ アプリ変更情報
３１ 対応処理情報
３２ 追加情報一覧
３３ 変更情報一覧
３４ 追加ファイル一覧
３５ 追加レジストリキー一覧
３６ 変更ファイル一覧
３７ 変更レジストリキー一覧
４１ インストール対象ディスク領域
４２ アプリ環境バックアップ情報
２０１ ＣＰＵ
２０２ メモリ
２０３ 記憶装置
２０４ 読取部
２０５ 着脱可能記録媒体
２０６ 通信インターフェース
２０７ 入出力部
２０９ バス

Claims (3)

1. ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を記憶する記憶部と、
   前記記憶部に記憶された前記変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存する保存処理部と、
   前記インストールを実行する処理部と、
   前記インストールの途中で発生した障害を検出する検出部と、
   前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定する進捗管理部と、
   前記障害時処理において変更されたファイルを、該ファイルに対応する保存された前記変更対象ファイルを用いて復元する復元部と、
   前記障害時処理の開始時点から前記インストールを再開する制御部と、
   を備え、
   前記記憶部は、前記所定の処理が正常に終了した場合の正常状態情報を記憶し、
   前記進捗管理部は、前記正常状態情報に基いて前記所定の処理が正常に終了したか否かを判定し、前記所定の処理が正常に終了していないと判定した場合、前記所定の処理を障害時処理として特定し、
   前記検出部は、前記障害を検出するとともに該障害の内容を示す障害情報を収集し、
   前記進捗管理部は、前記障害情報及び前記進捗情報に基いて、前記障害時処理が再開可能か否かを判定し、
   前記復元部は、前記進捗管理部により前記障害時処理が再開可能でないと判定された場合、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元する
   情報処理装置。
2. 記憶部に記憶された、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存し、
   前記インストールを実行し、
   前記インストールの途中で発生した障害を検出し、
   前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定し、
   前記障害時処理において変更されたファイルを、該ファイルに対応する保存された前記変更対象ファイルを用いて復元し、
   前記障害時処理の開始時点から前記インストールを再開し、
   前記所定の処理の障害時処理としての特定では、前記記憶部に記憶された、前記所定の処理が正常に終了した場合の正常状態情報に基いて、前記所定の処理が正常に終了したか否かを判定し、前記所定の処理が正常に終了していないと判定した場合、前記所定の処理を障害時処理として特定し、
   前記障害の検出では、前記障害を検出するとともに該障害の内容を示す障害情報を収集し、
   前記所定の処理の障害時処理としての特定では、前記障害情報及び前記進捗情報に基いて、前記障害時処理が再開可能か否かを更に判定し、
   前記障害時処理において変更されたファイルの復元では、前記障害時処理が再開可能でないと判定された場合、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元する
   情報処理方法。
3. プロセッサに、
   記憶部に記憶された、ソフトウェアのインストールが実行される場合の所定の処理において変更される変更対象ファイルの所在及びファイル名を用いて、前記変更対象ファイルを取得して保存し、
   前記インストールを実行し、
   前記インストールの途中で発生した障害を検出し、
   前記インストールの進捗状況を示す進捗情報を取得し、前記障害が検出された場合、前記進捗情報に基いて、前記障害が発生した時の前記所定の処理を障害時処理として特定し、
   前記障害時処理において変更されたファイルを、該ファイルに対応する保存された前記変更対象ファイルを用いて復元し、
   前記障害時処理の開始時点から前記インストールを再開する
   処理を実行させ、
   前記所定の処理の障害時処理としての特定では、前記記憶部に記憶された、前記所定の処理が正常に終了した場合の正常状態情報に基いて、前記所定の処理が正常に終了したか否かを判定し、前記所定の処理が正常に終了していないと判定した場合、前記所定の処理を障害時処理として特定し、
   前記障害の検出では、前記障害を検出するとともに該障害の内容を示す障害情報を収集し、
   前記所定の処理の障害時処理としての特定では、前記障害情報及び前記進捗情報に基いて、前記障害時処理が再開可能か否かを更に判定し、
   前記障害時処理において変更されたファイルの復元では、前記障害時処理が再開可能でないと判定された場合、前記障害時処理において変更されたファイルを、保存された前記変更対象ファイルを用いて復元する
   情報処理プログラム。
   

Images