SharePoint 2013 への試用版アップグレードを使用して潜在的な問題を発見する
適用対象:
2016 2019 Subscription Edition SharePoint in Microsoft 365
SharePoint 2010 製品から SharePoint 2013へのアップグレードを開始する前に、正常なアップグレードに必要となる操作を正確に把握するために、アップグレード プロセスのテストを実行してください。 試験アップグレードを利用してプロセスをテストすると、以下のことがわかります。
アップグレード計画が機能しているかどうか、調整の必要があるかどうか。
実際の環境内に存在するカスタマイズの内容。アップグレード中にカスタマイズの処理を計画できます。
アップグレードがより効率的で迅速に実行されるように、ハードウェアをアップグレードする必要があるかどうか。
アップグレードのタイミングまたは実際の環境でのアップグレードの所要時間。
運用面で計画する必要のある事柄 (利用できるようにするリソースなど)。
また、試験アップグレードを使用して、アップグレード ツールとプロセス自体に精通しておくと、本番のプロセスを実施するときの状況を把握できます。 テストを通じて、以下のことがわかります。
アップグレードのユーザー インターフェイスの外観。 1 つの段階が終了し、次の段階に進むことがどのようにわかるか。
ログ ファイルの場所と閲覧方法。 また、ログ ファイルで提供される情報。
特に SharePoint 2010 製品へのアップグレード時に使用されたスクリプトを利用する場合は、アップグレード プロセス中に使用されるスクリプトまたはコマンドを調整する必要があるかどうか。
切断に対処するための適切な計画があるかどうか。
ここでは、試験アップグレードの基本的な手順について説明します。また、結果を見直して、テスト中に判明したことに基づいてアップグレード計画を調整する場合の推奨事項を示します。
さらに、アップグレード プロセスのテストに関しては以下の参考資料が役に立ちます。
SharePoint 2013 - アップグレード プロセス モデルのテスト
SharePoint 2013 製品プレビュー - アップグレードのテスト方法モデルのポスターをダウンロードし、アップグレード プロセスのテスト方法に関する視覚化された情報を確認します。
「SharePoint 2010 から SharePoint 2013 へのアップグレードのベスト プラクティス」のアップグレード プロセスのテストに関するベスト プラクティスを参照してください。
テスト環境をセットアップする
アップグレード プロセスのテストには、仮想ハードウェアと物理ハードウェアのどちらでも使用できます。 すべての環境は一意です。 そのため、アップグレードにかかる時間や、特定のカスタマイズがアップグレードの難しさに関する一般的なガイドラインはありません。 アップグレードがどのように行われるかを測定する最善の方法は、一連の試用版アップグレードを実行することです。
テスト環境を作成する際の考慮事項がいくつかあります。
テスト用のファームは、ハードウェア、ソフトウェア、使用できる領域などの点で、実際のファームとできるだけ類似したものにします。
テスト用のファームでは、実際のファームと同じ 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 トランザクションなど) 内のサーバー間の相互作用によって発生する複雑な問題を考慮しない場合があります。 提案された運用ファームのロールに複数のサーバーがある場合は、テスト ファーム内のそのロールに対して少なくとも 2 つのサーバーを使用して、このような問題をテストします。
物理テスト環境でのサーバーの分散
カスタマイズを識別してインストールする
正確なテスト プロセスを用意するには、現在の環境に適用されているすべてのカスタマイズを探し出し、それらをテスト環境にコピーする必要があります。 特定する必要があるカスタマイズの種類の詳細については、「 SharePoint 2013 へのアップグレード中に現在のカスタマイズのプランを作成する」を参照してください。
SharePoint 2010 製品環境内にあるすべてのコンテンツ データベースに対して Stsadm -o enumallwebs 操作を使用して、サブサイト内のカスタマイズの詳細を調べます。 この操作によって、環境内のすべてのサイト コレクションとサブサイトの ID、およびサイトが依存しているテンプレートの一覧が表示されます。 詳細については、「 Enumallwebs : Stsadm 操作 (Office SharePoint Server)」を参照してください。
WinDiff (ほとんどの Microsoft オペレーティング システムで提供されているツール) などのツールを使用して、運用環境のサーバーと、テスト用ファームのサーバーを比較します。 このツールを使用すると、各サーバーに存在するファイルを確認し、サーバー間の違いを確認できます。
web.config ファイルに変更がないかチェックし、SafeControls 要素を調べてカスタム コントロールを見つけます。
検出されたすべてのカスタマイズの一覧を作成します。 可能な場合、カスタマイズのソースを識別します。 たとえば、サード パーティ製のアドインまたはテンプレートが社内でカスタマイズされているかどうかなどです。 ソースの識別後は、更新されたカスタマイズ、またはアップグレードされたカスタマイズがないかを確認できます。
ヒント
社内で作成したのではないカスタマイズについての問い合わせ先 > Microsoft Web サイトからダウンロードしたテンプレートに問題がある場合は、Microsoft にお問い合わせください。 > 以前のバージョンで提供されたテンプレートまたはコンポーネントに問題がある場合は、サード パーティのソリューション ベンダーにお問い合わせください。 アップグレードされたバージョンを入手できる可能性があります。
すべてのカスタマイズを識別したら、そのカスタマイズをテスト用ファームの適切なサーバーにコピーします。 以下のカスタマイズが展開されていることを確認します。
ソリューション - 既定では、レガシー ソリューションが /14 ディレクトリに展開されます。 ソリューションをインストールして /15 ディレクトリに展開する場合は、 CompatibilityLevel パラメーターを使用します。 詳細については、「 Install-SPSolution」を参照してください。
カスタム マスター ページ
カスタム JavaScript
カスタム CSS ファイル (テーマに関するファイルを含む)
カスタム ワークフロー アクション (アクション ファイルに含まれている必要があります)
大きなリストが予想どおりに表示されるように、大きなリストのクエリ調整を確認します。
カスタマイズをテストするときは、以下のガイダンスを実行します。
視覚的な変化を確認します。
動作の変化を確認します。
2010 モードと 2013 モード両方のサイト コレクションでテストします。
言語またはリソースの読み込みに関する問題を見つけます。
この問題は、カスタマイズが 2010 モードで存在し、そのカスタマイズが 2013 モードで新しいカスタマイズに置き換わったときに発生する可能性があります。 言語リソース用のグローバル ディレクトリは 1 つしか存在しないため、適切なファイルの読み込みで問題が発生する可能性があります。 置換用の 2013 カスタマイズには 2010 リソースが含まれているため、カスタマイズは両方のモードで引き続き機能します。
アップグレードがカスタマイズに影響しなかったことを検証します。 カスタマイズによってサイト コレクションのアップグレードがブロックされなかったことを確認します。
SharePoint 2013 にデータベースをアタッチする前に 、Test-SPContentDatabase Microsoft PowerShell コマンドレットを使用して、環境にカスタマイズが含まれていないかどうかを判断できます。 データベースをデータベース サーバーに復元した後、アップグレードを実行する前に、各データベースに対してこのコマンドを実行します。 このコマンドレットはサイレントで実行されることに注意してください。問題が見つからない限り、出力は返されません。
実際のデータをテスト環境にコピーしてデータベースをアップグレードする
実際のデータを使用しないと、テストの目的は達成できません。 Microsoft SQL Server のバックアップと復元ツールを使用して、コンテンツとサービス データベースのコピーを作成します。
アップグレード中に発生する可能性がある事柄を判断する場合、すべてのデータのコピーに対してテストを実行すること以上に優れた方法はありません。 しかし、この方法が、初回のテストとしては現実的ではない場合もあります。 データベースのサイズが大きい場合は、一度に 1 つのデータベースをテストし、テストを段階的に実施できます。 このようにすると、各データ セットに固有の事柄を確実にテストしたり、環境内の代表的なサイトのデータ サブセットを集めることができます。 最初にデータ サブセットを使用してテストを行う場合は、以下の特性を備えたサブセットを使用する必要があります。
データのサブセットには、実際の環境でサポートするサイトの特徴を示しているサイトが含まれる。
データ サブセットのサイズと複雑さが、環境の実際のサイズと複雑さに非常によく似ている。
重要
データのサブセットをテストしても、環境のデータのボリューム全体を処理するためにかかる時間について、有効な基準は得られません。
データのコピー後、初回のアップグレード プロセス全体を実行し、その結果を確認します。 これは予備的な手順にすぎません。 「 SharePoint 2010 から SharePoint 2013 にコンテンツ データベースをアップグレードする 」の手順に従って、データベースアタッチのアップグレード プロセスを試してください。
アップグレード プロセスをテストする場合は、ファーム間で共有されているサービスを必ずテストします。 次のような、あらゆる状態を考慮します。
SharePoint 2013 サービス ファームに接続された SharePoint Server 2010 ファーム。
SharePoint 2013 サービス ファームに接続された SharePoint 2013 ファーム。
さまざまなサービスに対応するさまざまなバージョンのファーム。
テスト環境を使用して、サービス アプリケーションのセキュリティ、構成、互換性、およびパフォーマンスの問題を見つけます。
データベースのアップグレード後の結果を確認する
テストのアップグレードが完了したら、結果を確認して計画を再検討できます。 ログ ファイルを参照し、アップグレードされたサイトを確認して、カスタマイズを調査します。 テスト環境でのアップグレードはどのように行われましたか。 何が判明しましたか。 アップグレード計画について、何を再検討する必要がありますか。
ログ ファイルを確認する
Review the upgrade log file and the upgrade error log file (generated when you run the upgrade). アップグレード ログ ファイル (.log) とアップグレード エラー ログ ファイル (.err) は、%COMMONPROGRAMFILES%\Microsoft Shared\Web サーバー拡張機能\15\LOGS にあります。 ログ ファイルには、Upgrade- YYYMMDD-HHMMSS-SSS.log という形式で名前が付けられます。 ここで、YYYYMMDD は日付、 HHMMSS-SSS は 時間 (24 時間のクロック形式、分、秒、ミリ秒)。
ログ ファイルの形式は、Unified Logging System (ULS) 規則に従っています。 ログ ファイルを確認して問題を見つけ、トラブルシューティングを行うには、ファイルの先頭から開始します。 エラーや警告は、環境内のいくつかのサイト コレクションで発生する場合や、アップグレード プロセスを完全にブロックしている場合には、繰り返し発生することがあります。 たとえば、構成データベースに接続できない場合は、アップグレード プロセスが何度か試みられて (失敗し)、それらの試行がログ ファイルに記載されます。
2010 モードのサイトの確認
アップグレードされなかったサイト コレクションが 2010 モードで予想どおりに機能していることを確認します。 サイトの外観と動作は、SharePoint 2010 製品の場合と同じである必要があります。 いくつかの変化が予想されます。 たとえば、SharePoint 2013 では Office Online と Web 分析機能が変更されており、これらの機能を使用したサイトが影響を受けます。 検索する特定の情報については、「 SharePoint 2010 から SharePoint 2013 へのアップグレード プロセスの概要」を参照してください。
必要に応じたアップグレードの再実行
必要な場合は、 Upgrade-SPContentDatabase Microsoft PowerShell コマンドレットを使用して、データベースのアップグレード プロセスを再開できます。 このコマンドレットの詳細については、「Upgrade-SPContentDatabase」を参照してください。 詳細については、「SharePoint 2013 へのデータベースの接続アップグレードまたはサイト コレクションのアップグレードを再開する」を参照してください。
サイト コレクションと個人用サイトをアップグレードする
コンテンツおよびサービス データベースに対するアップグレードをテストし検証したら、サイト コレクションに対してアップグレード プロセスをテストできます。 「 サイト コレクションを SharePoint 2013 にアップグレードする 」の手順に従って、サイト コレクションのアップグレード プロセスをテストします。 環境内に個人用サイトがある場合は、 アップグレードプロセスの詳細については、「SharePoint 2010 から SharePoint 2013 への アップグレード プロセスの概要」を参照してください。
注:
個人用サイトに関するコンテンツは SharePoint 2013 にのみ適用されます。
サイト コレクションのアップグレード後に結果を確認する
アップグレードされたサイトを確認し、運用環境でアップグレード プロセスを実行する前に対応する必要のある問題をすべて特定します。 特定の検索対象の詳細については、「 SharePoint 2010 から SharePoint 2013 へのアップグレード プロセスの概要」を参照してください。
サイト コレクションのアップグレード ログ ファイルを確認して、上から下から問題がないか確認します。 ログ ファイルの終わり近くの概要セクションを確認して、問題の数と実際のアップグレード状態を確認します (状態がない場合は、アップグレード プロセスが失敗し、サイトのアップグレードを再試行する必要があります)。 サイト コレクションのログ ファイルは、サイト コレクション自体 (_catalogs/アップグレード ドキュメント ライブラリ) とファイル システムの両方に格納されます。 問題の詳細が必要な場合は、ファイル システム ログ ファイルに詳細情報が含まれます。 サイト アップグレード ログ ファイルのファイル システム バージョンは、%COMMONPROGRAMFILES%\Microsoft Shared\Web サーバー拡張機能\15\LOGS にあります。 ログ ファイルの名前は SiteUpgrade- YYYYMMDD-HHMMSS-SSS.log で、 YYYYMMDD は日付、 HHMMSS-SSSS は時刻 (24 時間のクロック形式、分、秒、ミリ秒) の形式で指定されます。
計画を調整して再テストする
発生する可能性のある問題をすべて見つけ出し、それらの対処方法がわかるまで、テスト プロセスを繰り返します。 月曜日の朝にはオンラインに戻す必要がある場合、日曜日の午後 4 時の時点で良好に機能していないときの対処を計画することが目標です。 元に戻すことができない時点 (point of no return) が存在するかどうかを確認します。 フォールバック プランをテストし、実際のアップグレードを開始する前に機能することを確認します。
関連項目
その他のリソース
SharePoint 2010 から SharePoint 2013 へのアップグレードのベスト プラクティス
SharePoint 2013 へのアップグレード中のパフォーマンスを計画する
SharePoint 2010 から SharePoint 2013 にデータベースをアップグレードする