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

  • [アーティクル]

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

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

  • 実際の環境内に存在するカスタマイズの内容。アップグレード中にカスタマイズの内容をどのように処理するか、計画を立てることができます。

  • アップグレードがより効率的で迅速に実行されるように、ハードウェアをアップグレードする必要があるかどうか。

  • アップグレードのタイミングまたは実際の環境でのアップグレードの所要時間。

  • 運用面で計画する必要のある事柄 (利用できるようにするリソースなど)。

また、試験アップグレードを使用して、アップグレード ツールとプロセス自体に精通しておくと、本番のプロセスを実施するときの状況を把握できます。テストを通じて、以下のことがわかります。

  • 使用中の環境に当てはまる特別な問題と、最も効率的なアップグレード方法。

  • アップグレードのユーザー インターフェイスの外観。1 つの段階が終了し、次の段階に進むことがどのようにわかるか。

  • ログ ファイルとは何か。ログ ファイルを読む方法。ログ ファイルに記載されている情報。

  • ダウンタイムを短縮するために利用できる方法。

ここでは、試験アップグレードの基本的な手順について説明します。また、結果を見直して、テスト中に判明したことに基づいてアップグレード計画を調整する場合の推奨事項を示します。

この記事の内容

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

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

  • 実際のデータをテスト環境にコピーしてアップグレードを試みる

  • 結果を確認する

  • 計画を調整して再テストする

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

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

仮想ハードウェアまたは物理ハードウェアのどちらかを使用して、アップグレード プロセスをテストできます。どの環境にも固有の特徴があるため、アップグレードの所要時間や、カスタマイズのアップグレードの難易度に関する一般的なガイドラインはありません。アップグレードがどのように進むかを判断するのに最適な方法は、一連の試験アップグレードを実行することです。

テスト環境を作成するときには以下のことに注意します。

  • テスト用のファームは、ハードウェア、ソフトウェア、使用できる領域などの点で、実際のファームとできるだけ類似したものにします。

  • テスト用ファームでは、実際のファームと同じ URL を使用します (同じ URL を使用しないと、実際のアップグレードでは発生しない、URL 関連の問題の診断に時間を浪費することになります)。

  • テスト環境に、すべての設定とカスタマイズを確実に転送します。「カスタマイズを識別してインストールする」では、これらの情報を収集する方法について説明しています。

仮想テスト環境の使用

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

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

物理テスト環境の使用

物理環境を使用してテストを行う場合は、サーバー ファーム全体をできるだけ詳細に再現する必要があります。フロントエンド Web サーバー、アプリケーション サーバー、またはデータベース サーバーの数をあまり少なくすると、アップグレード処理の所要時間が正確に推定されなくなり、同じ役割のサーバー間のやり取りから発生する複雑さ (SQL Server のトランザクションなど) が考慮されなくなる可能性があります。元のファーム内に、1 つの役割のサーバーが複数存在する場合、テスト用ファームでは、その役割のサーバーを少なくとも 2 つ使用して、そうした問題に関するテストを行います。

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

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

データベース接続アップグレードの方法を使用する場合は、追加のテスト環境として、Office SharePoint Server 2007 を実行する単一サーバー ファームを 1 つ作成する必要が生じることがあります。この環境は、データのアップグレードを試みる前に、アップグレード前チェッカーを実行するために使用できます。

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

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

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

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

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

  • Office SharePoint Server 2007 環境内にあるすべてのコンテンツ データベースで、Stsadm ?o enumallwebs 操作を使用し、サブサイト内にある特定のカスタマイズを識別します。この操作によって、環境内にあるサイト コレクションとサブサイトごとの ID と、サイトが依存しているテンプレートのリストが作成されます。この操作は、Office SharePoint Server 2007 Service Pack 2 (SP2) で初めて導入されました。詳細については、「Enumallwebs: Stsadm 操作 (Office SharePoint Server)」を参照してください。

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

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

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

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

ヒント

社内で作成したのではないカスタマイズについての問い合わせ先

  • マイクロソフトの Web サイトからダウンロードしたテンプレート (Windows SharePoint Services 3.0 アプリケーション テンプレートなど) で問題が発生している場合は、マイクロソフトに連絡してください。

  • 以前のバージョンのためにサード パーティ ソリューション ベンダーから供給されたテンプレートまたはコンポーネントで問題が発生している場合は、該当するベンダーに連絡してください。アップグレードされたバージョンを入手できる可能性があります。

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

実際のデータをテスト環境にコピーしてアップグレードを試みる

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

アップグレード中に発生する可能性がある事柄を判断する場合、すべてのデータのコピーに対してテストを実行すること以上に優れた方法はありません。しかし、この方法が、初回のテストとしては現実的ではない場合もあります。データベースのサイズが大きい場合は、一度に 1 つのデータベースをテストし、テストを段階的に実施できます。このようにすると、各データ セットに固有の事柄を確実にテストしたり、環境内の代表的なサイトのデータ サブセットを集めることができます。最初にデータ サブセットを使用してテストを行う場合は、以下の特性を備えたサブセットを使用する必要があります。

  • データのサブセットには、実際の環境でサポートするサイトの特徴を示しているサイトが含まれる。

  • データ サブセットのサイズと複雑さが、環境の実際のサイズと複雑さに非常によく似ている。

重要

データのサブセットをテストしても、環境のデータのボリューム全体を処理するためにかかる時間について、有効な基準は得られません。

データのコピー後、初回のアップグレード プロセス全体を実行し、その結果を確認します。これは予備的な手順にすぎません。

一括アップグレードを試みる

一括アップグレードの方法を試みる場合は、以下の手順に従ってアップグレード プロセスを試してみます。

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

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

    詳細については、「ファーム全体のバックアップおよび復元 (SharePoint Server 2007)」を参照してください。

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

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

  5. 結果を確認します。

データベース接続アップグレードを試みる

  1. コンテンツ データベースと共有サービス プロバイダー (SSP) データベースの SQL Server バックアップを作成します。

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

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

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

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

  5. 「データベースを接続して SharePoint Server 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 を検索します。

アップグレードの問題を見つける場合は、ログ パーサーを使用してログ ファイルに対するクエリを実行すると便利なことがあります。

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

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

アップグレード中に、見つからないサイトやスキップされたサイトがあったかどうかを確認するには、SharePoint Server 2010 サーバー ファーム内にあるすべてのフロントエンド Web サーバーで、Stsadm 操作の stsadm -o localupgradestatus を実行します。この操作の詳細については、「Localupgradestatus: Stsadm 操作 (Office SharePoint Server)」を参照してください。

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

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

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

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

計画を調整して再テストする

発生する可能性のある問題をすべて見つけ、それらの対処方法を十分に理解できるまで、テストの手順を繰り返します。月曜の朝にはオンラインに戻っている必要があるのに、日曜午後 4 時に作業が順調に進んでいない場合でも、対処方法がわかっているようにすることが目標です。アップグレード プロセスを元に戻せない時点がある場合は、実際のアップグレードを開始する前にロールバック計画をテストし、計画が正しく機能することを確認しておきます。