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

適用対象: yes-img-13  2013 no-img-16 2016  no-img-19 2019  no-img-se Subscription Edition  no-img-sop SharePoint in Microsoft 365

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

  • アップグレード計画が機能しているかどうか、調整の必要があるかどうか。

  • 実際の環境内に存在するカスタマイズの内容。アップグレード中にカスタマイズの処理を計画できます。

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

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

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

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

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

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

  • 特に SharePoint 2010 製品へのアップグレード時に使用されたスクリプトを利用する場合は、アップグレード プロセス中に使用されるスクリプトまたはコマンドを調整する必要があるかどうか。

  • 切断に対処するための適切な計画があるかどうか。

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

さらに、アップグレード プロセスのテストに関しては以下の参考資料が役に立ちます。

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

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

テスト環境を作成する際の考慮事項がいくつかあります。

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

  • テスト用のファームでは、実際のファームと同じ URL を使用します。そうしないと、実際のアップグレードでは発生しない URL に関する問題を診断するために、無駄な時間を費やすことになります。これを行うには、同じ URL を使用し、ホスト ファイルが変更されるコンピューターからのみテストを実行します。

  • Web とアプリケーション サーバーに異なるコンピューター名を使用します。

    これにより Active Directory ドメイン サービス (AD DS) の競合が回避されます。

  • テスト用のファームには、SQL Server を実行する個別のサーバーを使用します。

    テスト用のファームと運用ファームに、SQL Server を実行する同一サーバーを使用している場合は、テストの実行中に、運用サーバーのパフォーマンスが影響を受ける可能性があります。運用ファームとテスト用のファームでは (インスタンスだけでなく) SQL Server コンピューターも異なるものを使用することをお勧めします。

  • テスト環境では同じデータベース名を使用します。

    これにより、環境の管理に使用するスクリプトを検証できます。また、SQL Server を実行している個別のサーバーを使用するようにしてください。使用しなければ、運用環境に影響を及ぼす可能性があります。

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

テスト環境で行う操作が運用環境に影響を及ぼさないようにしてください。次の点に注意してください。

  • 外部データ接続

    環境のコピーで作業していても、データ ソースのリンクは実際のものです。テスト環境のデータへの変更は運用環境に影響します。

  • 稼働中のライブ データベースに対してコマンドを実行する

    テストには、運用環境のライブ データベースではなく必ずコピーを使用するようにしてください。たとえば、コピーではなくライブ データベースに対して Test-SPContentDatabase を実行すると、運用環境のパフォーマンスに影響を及ぼす可能性があります。

仮想テスト環境の使用

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

ただし、仮想環境には物理環境と同じパフォーマンス指標がない場合があります。運用環境が物理環境の場合は、運用環境のアップグレードに必要な時間を計算する際にこの違いを考慮する必要があります。一般的に、SQL Server 用に物理サーバーを使用している場合は、より優れたパフォーマンス評価を得ることができます。パフォーマンス仕様が、運用環境で SQL Server を実行するサーバーと同様であることを確認します。

仮想環境でのサーバーの分散

アップグレード用の仮想テスト ファーム

物理テスト環境の使用

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

物理テスト環境でのサーバーの分散

アップグレードをテストするための物理ファーム

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

正確なテスト プロセスを用意するには、現在の環境に適用されているすべてのカスタマイズを探し出し、それらをテスト環境にコピーする必要があります。識別する必要があるカスタマイズの種類については、「SharePoint 2013 にアップグレードする場合の現在のカスタマイズの計画を作成する」を参照してください。

  • SharePoint 2010 製品環境内にあるすべてのコンテンツ データベースに対して Stsadm -o enumallwebs 操作を使用して、サブサイト内のカスタマイズの詳細を調べます。この操作によって、環境内のすべてのサイト コレクションとサブサイトの ID、およびサイトが依存しているテンプレートの一覧が表示されます。詳細については、「Enumallwebs: Stsadm 操作」を参照してください。

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

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

  • 検出されたすべてのカスタマイズの一覧を作成します。可能な場合、カスタマイズのソースを識別します。たとえば、サード パーティ製のアドインまたはテンプレートが社内でカスタマイズされているかどうかなどです。ソースの識別後は、更新されたカスタマイズ、またはアップグレードされたカスタマイズがないかを確認できます。

ヒント

社内で作成したのではないカスタマイズについての問い合わせ先 > Microsoft の Web サイトからダウンロードしたテンプレートで問題が発生している場合は、Microsoft に連絡してください。> 以前のバージョンのためにサード パーティ ソリューション ベンダーから供給されたテンプレートまたはコンポーネントで問題が発生している場合は、該当するベンダーに連絡してください。アップグレードされたバージョンを入手できる可能性があります。

すべてのカスタマイズを識別したら、そのカスタマイズをテスト用ファームの適切なサーバーにコピーします。以下のカスタマイズが展開されていることを確認します。

  • ソリューション - 既定では、レガシー ソリューションが /14 ディレクトリに展開されます。ソリューションをインストールして /15 ディレクトリに展開する場合は、CompatibilityLevel パラメーターを使用します。詳細については、「Install-SPSolution」を参照してください。

  • カスタム マスター ページ

  • カスタム JavaScript

  • カスタム CSS ファイル (テーマに関するファイルを含む)

  • カスタム ワークフロー アクション (アクション ファイルに含まれている必要があります)

  • 大きなリストが予想どおりに表示されるように、大きなリストのクエリ調整を確認します。

カスタマイズをテストするときは、以下のガイダンスを実行します。

  • 視覚的な変化を確認します。

  • 動作の変化を確認します。

  • 2010 モードと 2013 モード両方のサイト コレクションでテストします。

  • 言語またはリソースの読み込みに関する問題を見つけます。

    この問題は、カスタマイズが 2010 モードで存在し、そのカスタマイズが 2013 モードで新しいカスタマイズに置き換わったときに発生する可能性があります。言語リソース用のグローバル ディレクトリは 1 つしか存在しないため、適切なファイルの読み込みで問題が発生する可能性があります。置換用の 2013 カスタマイズには 2010 リソースが含まれているため、カスタマイズは両方のモードで引き続き機能します。

  • アップグレードがカスタマイズに影響しなかったことを検証します。カスタマイズによってサイト コレクションのアップグレードがブロックされなかったことを確認します。

Microsoft PowerShell の Test-SPContentDatabase コマンドレットを使用して、データベースを SharePoint 2013 に接続する前に、環境で不足しているカスタマイズがないか確認します。データベースをデータベース サーバーに復元した後で、アップグレードを実行する前に、このコマンドを各データベースに対して実行します。このコマンドレットは、ダイアログの表示なしで実行されることに注意してください。エラーが発生しない限り、結果は表示されません。

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

実際のデータを使用しないと、テストの目的は達成できません。Microsoft SQL Server のバックアップと復元ツールを使用して、コンテンツとサービス データベースのコピーを作成します。

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

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

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

重要

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

データのコピー後、初回のアップグレード プロセス全体を実行し、その結果を確認します。これは予備的な手順にすぎません。「SharePoint 2010 から SharePoint 2013 にコンテンツ データベースをアップグレードする」に記載されている手順に従って、データベース接続アップグレードのプロセスを実行します。

アップグレード プロセスをテストする場合は、ファーム間で共有されているサービスを必ずテストします。次のような、あらゆる状態を考慮します。

  • SharePoint 2013 サービス ファームに接続された SharePoint Server 2010 ファーム。

  • SharePoint 2013 サービス ファームに接続された SharePoint 2013 ファーム。

  • さまざまなサービスに対応するさまざまなバージョンのファーム。

テスト環境を使用して、サービス アプリケーションのセキュリティ、構成、互換性、およびパフォーマンスの問題を見つけます。

データベースのアップグレード後の結果を確認する

テストのアップグレードが完了したら、結果を確認して計画を再検討できます。ログ ファイルを参照し、アップグレードされたサイトを確認して、カスタマイズを調査します。テスト環境でのアップグレードはどのように行われましたか。何が判明しましたか。アップグレード計画について、何を再検討する必要がありますか。

ログ ファイルを確認する

(アップグレードの実行中に生成された) アップグレード ログ ファイルとアップグレード エラー ログ ファイルを確認します。アップグレード ログ ファイル (.log) とアップグレード エラー ログ ファイル (.err) は、%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS にあります。ログ ファイルの名前は、Upgrade-YYYYMMDD-HHMMSS-SSS.log という形式になっています。ここで YYYYMMDD には日付、HHMMSS-SSS には時刻 (24 時間制での時、分、秒、およびミリ秒) が入ります。

ログ ファイルの形式は、Unified Logging System (ULS) 規則に従っています。ログ ファイルを確認して問題を見つけ、トラブルシューティングを行うには、ファイルの先頭から開始します。エラーや警告は、環境内のいくつかのサイト コレクションで発生する場合や、アップグレード プロセスを完全にブロックしている場合には、繰り返し発生することがあります。たとえば、構成データベースに接続できない場合は、アップグレード プロセスが何度か試みられて (失敗し)、それらの試行がログ ファイルに記載されます。

2010 モードのサイトの確認

アップグレードされなかったサイト コレクションが 2010 モードで予想どおりに機能していることを確認します。サイトの外観と動作は、SharePoint 2010 製品の場合と同じである必要があります。いくつかの変化が予想されます。たとえば Office Online と Web 分析機能が SharePoint 2013 で変更され、その機能を使用するサイトが影響を受けます。具体的な確認点の詳細については、「SharePoint 2010 から SharePoint 2013 へのアップグレード プロセスの概要」を参照してください。

必要に応じたアップグレードの再実行

必要に応じて、Microsoft PowerShell の Upgrade-SPContentDatabase コマンドレットを使用することで、データベースに対してアップグレード プロセスを再起動できます。このコマンドレットの詳細については、「Upgrade-SPContentDatabase」を参照してください。詳細については、「SharePoint 2013 へのデータベースの接続アップグレードまたはサイト コレクションのアップグレードを再開する」を参照してください。

サイト コレクションと個人用サイトをアップグレードする

コンテンツおよびサービス データベースに対するアップグレードをテストし検証したら、サイト コレクションに対してアップグレード プロセスをテストできます。「サイト コレクションを SharePoint 2013 にアップグレードする」に記載されている手順を使用し、サイト コレクションのアップグレード プロセスをテストします。環境に個人用サイトがある場合、アップグレード プロセスに関する詳細については、「SharePoint 2010 から SharePoint 2013 へのアップグレード プロセスの概要」を参照してください。

注意

個人用サイトに関するコンテンツは SharePoint 2013 にのみ適用されます。

サイト コレクションのアップグレード後に結果を確認する

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

サイト コレクションのアップグレード ログ ファイルを確認し、問題がないか上から下までチェックします。ログ ファイルの終わり近くにある概要セクションをチェックし、問題の数と実際のアップグレードの状態を確認します (状態がない場合は、アップグレード プロセスが失敗したため、サイトのアップグレードを再試行する必要があります)。サイト コレクションのログ ファイルは、サイト コレクション自体 (_catalogs/Upgrade ドキュメント ライブラリ内) とファイル システム上に格納されます。問題の詳細を知りたい場合は、多くの情報を格納するファイル システムのログ ファイルを確認します。サイト アップグレード ログ ファイルのファイル システム版は、%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS にあります。ログ ファイルの名前の形式は、SiteUpgrade-YYYYMMDD-HHMMSS-SSS.log です。ここで YYYYMMDD には日付が、HHMMSS-SSS には時刻 (24 時間制での時、分、秒、およびミリ秒) が入ります。

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

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

関連項目

その他のリソース

SharePoint 2010 から SharePoint 2013 へのアップグレードのベスト プラクティス

SharePoint 2013 へのアップグレード中のパフォーマンスを計画する

SharePoint 2010 から SharePoint 2013 にデータベースをアップグレードする

Upgrade a site collection to SharePoint 2013

SharePoint 2013 へのアップグレードのテストおよびトラブルシューティングを行う