次の方法で共有

試用版のアップグレードを使用して潜在的な問題を発見する (SharePoint Foundation 2010)

  • [アーティクル]

 

適用先: SharePoint Foundation 2010

Windows SharePoint Services 3.0 から Microsoft SharePoint Foundation 2010 へのアップグレードを開始する前に、正常なアップグレードに必要となる操作を正確に把握するために、アップグレード プロセスのテストを実行してください。トライアル アップグレードを利用してプロセスをテストすると、以下のことがわかります。

  • 環境に適用されているカスタマイズ。それらのカスタマイズをアップグレード中にどのように行うかの計画を立てることができます。

  • ハードウェアをアップグレードして、アップグレードをより効率的にすばやく実行する必要があるかどうか。

  • アップグレードのタイミング、または環境に応じてアップグレードにかかる時間。

  • 計画に必要な運用上の考慮点。使用可能とするリソースなど。

また、トライアル アップグレードを使用することで、アップグレード ツールとアップグレード プロセスそのものに習熟できるので、実際のプロセスを進めるうえでどうすればよいかがわかります。テストを通じて、次のことを把握できます。

  • 環境に適用される特殊なケース、および最も効果的なアップグレード方法。

  • アップグレードのユーザー インターフェイスの外観。各フェーズの完了と切り替えを把握できます。

  • ログ ファイルの場所と閲覧方法。また、ログ ファイルで提供される情報。

  • ダウンタイムの短縮に使用できる技術。

ここでは、アップグレードをテストするための基本的な手順について説明し、結果の確認方法とテスト時に把握された内容に基づくアップグレード計画の調整方法に関する推奨事項を示します。

この記事の内容

  • テスト環境をセットアップする

  • カスタマイズを識別し、インストールする

  • 実データをテスト環境にコピーし、アップグレードを試行する

  • 結果を確認する

  • 計画を調整し、テストを再実行する

また、アップグレード プロセスをテストする際に次の情報源が役に立ちます。

テスト環境をセットアップする

アップグレード プロセスのテストには、仮想ハードウェアと物理ハードウェアのどちらでも使用できます。環境は 1 つ 1 つ異なるので、アップグレードに要する時間や、特定のカスタマイズをアップグレードする難易度についての一般的なガイドラインはありません。アップグレード プロセスの内容を予測するには、一連のトライアル アップグレードを実行することが最善の方法です。

テスト環境の作成時には、次のことを行います。

  • ハードウェア、ソフトウェア、空き容量など、できる限り実際のファームと同じテスト ファームを構築します。

  • 実際のファームと同じ URL をテスト ファームで使用します。そうしないと、実際のアップグレードでは使用しない URL に関する問題を診断するために、無駄な時間を費やすことになります。

  • すべての設定とカスタマイズがテスト環境に移されたことを確認します。これらの情報を収集する方法については、「カスタマイズを識別し、インストールする」を参照してください。

仮想テスト環境を使用する

仮想化された環境を使用してテストを実行するときには、多くのハードウェアを必要としません。Hyper-V を実行している 2 つのサーバーを使用するだけで、環境を複製できます。1 つのサーバーにはフロントエンドの Web サーバーとアプリケーション サーバーのイメージが適用され、もう 1 つのサーバーにはデータベース サーバーのイメージが適用されます。

試用版アップグレードの仮想テスト環境

物理テスト環境を使用する

物理環境を使用してテストを実行するときには、できる限り正確にサーバー ファーム環境全体を複製する必要があります。フロントエンドの Web サーバー、アプリケーション サーバー、またはデータベース サーバーの数を省略しすぎると、アップグレード プロセスに要する時間を正確に見積もることができなくなり、同じ役割のサーバー間で行われるやり取り (SQL Server トランザクションなど) によって生じる問題の原因が特定できないことがあります。このような問題をテストする場合、元のファームで 1 つの役割を複数のサーバーに割り当てているときには、テスト ファームではその役割に対して少なくとも 2 つのサーバーを使用してください。

試用版のアップグレードのための物理テスト ファーム

データベース接続アップグレードのための追加のテスト環境

データベース接続アップグレードを行う場合は、追加のテスト環境を 1 つ作成する必要が生じることもあります。これは単一のサーバー ファームであり、Windows SharePoint Services 3.0 を実行して、データのアップグレード前にアップグレード前チェッカーを実行できるようにするためのものです。

既存の運用ファームでアップグレード前チェッカーを実行する場合は、この手順を省略できます。

カスタマイズを識別し、インストールする

正確なテスト プロセスを用意するには、現在の環境に適用されているすべてのカスタマイズを探し出し、それらをテスト環境にコピーする必要があります。識別する必要があるカスタマイズの種類については、「カスタマイズの処理方法を決定する (SharePoint Foundation 2010)」を参照してください。

  • アップグレード前チェッカーを使用して、環境内のサイト定義、サイト テンプレート、機能を識別します。

    アップグレード前チェック ツールは、各サイト コレクションに対して実行され、各サイトの状態に関するレポートを生成します。また、各リストのリスト定義情報も保存します。ユーザーはレポートを確認して問題を見つけ、アップグレード プロセスを開始する前に問題に対処できます。Windows SharePoint Services 3.0 のアップグレード前のスキャン ツールとは異なり、アップグレード前チェック ツールは読み取り専用ツールであり、サイトに変更を加えません。このツールの詳細と実行手順については、「将来のリリースに備えたアップグレード前スキャンとレポート (Windows SharePoint Services)」および「アップグレード前チェック ツールを実行する (SharePoint Foundation 2010)」を参照してください。

  • Stsadm –o enumallwebs 操作を Windows SharePoint Services 3.0 環境にあるすべてのコンテンツ データベース上で実行して、サブサイト内の特定のカスタマイズを識別します。この操作により、環境にある各サイト コレクションとサブサイトの ID およびサイトが利用しているテンプレートが一覧表示されます。この操作が最初に導入されたのは、Windows SharePoint Services 3.0 の Service Pack 2 (SP2) です。詳細については、「Enumallwebs : Stsadm 操作 (Windows SharePoint Services)」を参照してください。

  • WinDiff (Microsoft のほとんどのオペレーティング システムに付属) などのツールを使用して、運用環境のサーバーとテスト ファームのサーバーを比較します。このツールを使用すると、サーバー上に存在するファイルを検出し、それらのサーバー間での違いを確認できます。

  • web.config ファイルに変更がないかチェックし、SafeControls 要素を調べてカスタム コントロールを見つけます。

  • SharePoint 診断ツール (SPDiag) を使って、展開されたソリューションを見つけます。詳細については、「SharePoint Diagnostics Tool (SPDiag)」を参照してください。

  • 検出されたすべてのカスタマイズの一覧を作成します。可能な場合、カスタマイズのソースを識別します。たとえば、サード パーティ製のアドインやテンプレートが社内でカスタマイズされているかどうかなどです。ソースの識別後は、更新されたカスタマイズ、またはアップグレードされたカスタマイズがないかを確認できます。アップグレード前チェック ツールの結果とカスタマイズに関する調査で得られたデータに基づいて、環境に関する情報を書き込むことができるワークシートを用意しました。このワークシートは、https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x411 (英語) からダウンロードし、必要に応じてカスタマイズできます。

ヒント

マイクロソフトで作成していないカスタマイズに関する問い合わせ先

  • Microsoft Web サイトからダウンロードしたテンプレート (Windows SharePoint Services 3.0 のアプリケーション テンプレートなど) に関する問題はマイクロソフトに問い合わせてください。

  • 以前のバージョンでサード パーティのソリューション ベンダーから提供されたテンプレートやコンポーネントに問題がある場合は、各ベンダーに問い合わせてください。アップグレードされたバージョンが提供されている場合があります。

すべてのカスタマイズを識別した後には、それらをテスト ファーム内の適切なサーバーにコピーします。Windows PowerShell コマンドレットの test-spcontentdatabase を使用して、データベースを SharePoint Foundation 2010 に接続する前に、環境でコピーし忘れたカスタマイズがないか確認します。データベースをデータベース サーバーに復元した後で、アップグレードを実行する前に、このコマンドを各データベースに対して実行します。このコマンドレットは、ダイアログの表示なしで実行されることに注意してください。エラーが発生しない限り、結果は表示されません。

実データをテスト環境にコピーし、アップグレードを試行する

実際のデータを使用しないと、テストの目標を達成できません。データのコピーを作成するには、次の方法を使用できます。

アップグレード中に何が発生するかを知るには、すべてのデータのコピーに対してテストを実行することが最善の方法ですが、この方法が最初のテストとして必ずしも現実的ではない場合があります。データベースが大きい場合は、一度に 1 つのデータベースをテストすることでテストを段階的に実行して、データ セットに固有のすべての特性を確実にテストできます。または、環境内の代表的なサイトからデータのサブセットを集めることもできます。データのサブセットを使用して最初のテストを実行する場合、サブセットには次の特性があることに留意してください。

  • データのサブセットには、環境でサポートされる代表的なサイトが含まれます。

  • データのサブセットのサイズと複雑さは、実際の環境のサイズと複雑さに極めて似ています。

重要

データのサブセットのテストでは、環境内のデータ全体の処理に要する時間に関して、正しいベンチマークが生成されません。

データのコピー後、最初にアップグレード プロセスをひととおり実行して、何が起こるかを確認します。これは、まだ準備段階です。

一括アップグレードを実行する

一括アップグレードの場合は、次の手順を使用してアップグレード プロセスを実行します。

  1. ファームのバックアップを作成します。

  2. テスト ファームのバックアップを復元します。

    詳細については、「Windows SharePoint Services 3.0 テクノロジのバックアップと復旧を管理する」を参照してください。

  3. アップグレード前チェッカーを実行します。見つかった問題はすべてメモに残します。これらの問題については、運用ファームで実際のアップグレードを実行する前に、元の環境で対策を取るようにします。詳細については、「アップグレード前チェック ツールを実行する (SharePoint Foundation 2010)」を参照してください。

  4. 「一括アップグレードを実行する (SharePoint Foundation 2010)」に記載されている手順に従って、一括アップグレードを実行します。

  5. 結果を確認します。

データベース接続アップグレードを実行する

  1. コンテンツ データベースの SQL Server バックアップを作成します。

  2. SQL Server を使用して単一サーバーのテスト ファームにバックアップを復元し、その環境にコンテンツ データベースを接続します。

    詳細については、「コンテンツ データベースをバックアップおよび復元する (Windows SharePoint Services 3.0)」を参照してください。

  3. アップグレード前チェッカーを実行します。見つかった問題と、加えられた変更点はすべてメモに残します。これらの問題の対処および変更の適用については、運用ファームで実際のアップグレードを実行する前に、元の環境で行うようにします。詳細については、「アップグレード前チェック ツールを実行する (SharePoint Foundation 2010)」を参照してください。

  4. 「新しい SharePoint Foundation 2010 環境を準備する」に記載されている手順に従って、テスト環境をデータベース接続アップグレード用に構成します。

  5. 「データベースを接続して SharePoint Foundation 2010 へアップグレードする」に記載されている手順に従って、データベース接続アップグレードのプロセスを実行します。

結果を確認する

テスト アップグレードの終了後は、結果を確認し、計画に立ち戻ることができます。ログ ファイルの内容とアップグレードされたサイトを参照し、カスタマイズを調査します。環境におけるアップグレードの実行内容、検出された課題、および見直しの必要なアップグレード計画について確認してください。

ログ ファイルを確認する

次のログ ファイルを確認します。

  • アップグレード前チェッカーのログ ファイル。

    アップグレード前チェッカー (stsadm -o preupgradecheck) のログ ファイルの場所は、%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS です。ログ ファイルは、PreUpgradeCheck_YYYYMMDD-HHMMSS-SSS-<ランダムな数字>.log という形式で名前が付けられています。YYYYMMDD は日付、HHMMSS-SSS は時刻 (24 時間形式の時、分、秒、ミリ秒) です。また、アップグレード前チェッカーが同時に起動された場合にも区別できるように、ランダムな数字が使用されます。

  • SharePoint 製品構成ウィザード (Psconfig.exe) のログ ファイル (このウィザードをトライアル一括アップグレードの一部として実行するときに生成されます)。

    PSCDiagnostics ログ ファイルの場所は、%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS です。

  • アップグレード ログ ファイルとアップグレード エラー ログ ファイル (アップグレード実行に生成されます)。

    アップグレード ログ ファイル (.log) とアップグレード エラー ログ ファイル (.err) の場所は、%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS です。これらのログ ファイルは、Upgrade-YYYYMMDD-HHMMSS-SSS.log という形式で名前が付けられています。YYYYMMDD は日付、HHMMSS-SSS は時刻 (24 時間形式の時、分、秒、ミリ秒) です。

問題の検出とトラブルシューティングのためにログ ファイルを確認するには、ファイルの先頭から見ていきます。エラーや警告は、環境内の複数のサイト コレクションで発生しているか、アップグレード プロセス全体をブロックしている場合、繰り返し発生している可能性があります。たとえば、構成データベースに接続できない場合は、アップグレード プロセスは何度か試行され、それらの失敗の結果がログ ファイルに記録されます。

次のエントリを検索するか、画面上で探します。

  • Finished upgrading SPFarm Name=<構成データベース名>

  • In-place upgrade session finishes. Root object = SPFarm=<構成データベース名>, recursive = True. 0 errors and 0 warnings encountered.

これらのエントリが見つかった場合は、インストールに成功しています。

前の手順のエントリが見つからない場合は、Upgrade.log ファイルで次の語を検索または画面上で探すことによって、失敗の原因となった問題を特定できます。

  • 障害 (失敗しているコンポーネントや誤りのあるデータベース接続など) を見つけ出すには、ログ ファイルで ERROR を検索します。

  • 見落とされている機能やコンポーネントなどの問題を見つけ出すには、WARNING を検索します。

アップグレードの問題を見つけるには、ログ パーサーを使用してログ ファイルに対してクエリを実行する方法が便利です。

必要に応じてアップグレードを再起動する

データベース接続アップグレードでは、アップグレードできないサイトはスキップされます。一括アップグレードでは、サーバーの再起動またはアップグレードの失敗が発生した場合、アップグレード プロセスを再開して、残りのサイトをアップグレードする必要があります。

アップグレード中に見落とされたりスキップされたりしたサイトを確認するには、Stsadm 操作 stsadm -o localupgradestatus を SharePoint Foundation 2010 サーバー ファーム内のフロントエンド Web サーバーごとに実行します。この操作の詳細については、「Localupgradestatus : Stsadm 操作 (Windows SharePoint Services)」を参照してください。

Windows PowerShell コマンドレット upgrade-spcontentdatabase -id <GUID> を使用することで、該当のサイト コレクションを含むデータベースに対して、アップグレード プロセスを再起動できます。このコマンドレットの詳細については、「Upgrade-SPContentDatabase」を参照してください。

詳細については、「アップグレードを再開する (SharePoint Foundation 2010)」を参照してください。

アップグレードされたサイトを確認する

アップグレードされたサイトを確認し、運用環境でアップグレード プロセスを実行する前に対応する必要のある問題をすべて特定します。具体的な確認点の詳細については、「アップグレードされたサイトを検証および確認する (SharePoint Foundation 2010)」を参照してください。

計画を調整し、テストを再実行する

発生する可能性のある問題をすべて見つけ出し、それらの対処方法がわかるまで、テスト プロセスを繰り返します。月曜日の朝にはオンラインに戻す必要がある場合、日曜日の午後 4 時の時点で良好に機能していないときの対処を計画することが目標です。元に戻すことができない時点 (point of no return) が存在するかどうかを確認します。実際のアップグレードを開始する前に、ロールバック計画をテストし、ロールバックが正しく機能することを確認します。