SharePoint の Web パーツ ページが表示できない場合のトラブルシューティング
こんにちは SharePoint サポートの森 健吾 (kenmori) です。
今回の投稿では、すでに Web キャスト等でも公開しております Web パーツを含むページが予期せぬエラー等で表示できなくなった際のトラブル シューティング方法について SharePoint 2013 をベースとしてご説明します。
この投稿には SharePoint 2013 での最新情報は少ないものの、バージョンを問わずトラブルシューティングの基礎となりますため、情報を更新する目的で投稿します。
SharePoint では、製品に用意された様々な Web パーツや、それらをカスタマイズした Web パーツ、または Visual Studio によってカスタマイズしたオリジナルの Web パーツを追加して独自のページを作成することができます。
しかし、様々なページを実現できるがゆえに、エラーが発生した場合は、どう対処すべきかわからないという状況が想定されます。
この投稿では、Web パーツ ページが表示できなくなった場合のトラブル シューティングについて説明していきます。
また、この投稿で使用している画面ショットは、SharePoint 2013 のものを使用していますが、それ以前のバージョンにおいても有効な方法をご紹介します。
エラー画面
SharePoint では、Web パーツを含むページの表示処理などにおいてエラーが発生し、例外がハンドルされない場合、このように "申し訳ございません。何らかの問題が発生しました。" などのエラー画面が表示されます。
このような問題が発生した場合は、次のような手順を行ってください。
トラブルシューティング手順
Web パーツ ページが表示できない場合のトラブル シューティングを実施するにあたって、最も簡単な方法は Web パーツの管理の画面を使用します。
最初にこの問題がそのページ特有の現象かどうかを確認するために、URL を直接指定して影響範囲を確認します。
影響範囲がページ固有である場合は、以下にその手順についてトラブルシューティングの流れをご説明いたします。
手順概要
- Web パーツの管理のページにアクセスします。
- 管理画面から 1 つ 1 つ Web パーツを閉じ、元のページにアクセスします。
- 手順 2. を正常に表示されるまで繰り返します。
- 現象が回避できた時点で、最後に閉じた Web パーツが問題の Web パーツとして断定できます。
- この問題となる Web パーツを閉じたまま、その他の Web パーツを元に戻していきます。
さらに、現象発生の原因を追究する場合は、現象発生時のバックアップ データなどをテスト環境に復元し、テスト環境にて継続して調査を実施することをお勧めします。
手順詳細
1. Web パーツの管理のページにアクセスします。
エラー発生画面に [Web パーツの管理のページ] といったリンクが表示されている場合は、このリンクをクリックすることで、Web パーツ ページの管理画面に遷移し、トラブル シューティングを行うことが可能です。
しかしながら、エラーの種類や深刻さなどによっては、このエラー画面が表示されないことも考えられます。その場合は、ブラウザのアドレス バーにて URL の末尾に ?contents=1 を入力して該当するページの Web パーツ ページの管理画面に遷移することができます。
また ?contents=1 を追加する方法は、SharePoint Server 2010, 2007 等の以前のバージョンの SharePoint においても使用できます。
2. 管理画面から 1 つ 1 つ Web パーツを閉じ、元のページにアクセスします。
3. 手順 2. を正常に表示されるまで繰り返します。
4. 現象が回避できた時点で、最後に閉じた Web パーツが問題の Web パーツとして断定できます。
Web パーツ ページの管理画面に遷移したら、Web パーツにチェックを入れ [閉じる] をクリックして、Web パーツを閉じていきます。
問題の Web パーツを特定するため、1 つ閉じるごとにページが正常に表示されるかを確認していきます。
正常に表示できた時点で、最後に閉じた Web パーツが問題を引き起こしていることが確認できます。
5. この問題となる Web パーツを閉じたまま、その他の Web パーツを元に戻していきます。
問題の Web パーツが特定できた後は、その特定の Web パーツを除く全ての Web パーツをあらためて追加します。
Web パーツ ページの管理画面にて、[閉じる] をクリックして閉じられた Web パーツは、Web パーツを追加する際のカテゴリにて "閉じられた Web パーツ" というカテゴリの中に全て登録されています。
この Web パーツを選択し、[追加] ボタンをクリックすることで、閉じるまでの設定情報を引き継いた Web パーツを再度ページに復元することができます。
この手順を、問題の Web パーツ以外にて適用し、閲覧できないコンテンツの影響を最小限にとどめます。
原因追求
原因追求については、ダウンタイムを最小限にするためだけでなく、根本原因について十分に調査を実施するためにも、テスト環境で実施することをお勧めします。
Web.config の編集
調査方法の 1 つとしては、web.config を以下のように設定し、スタックを含めたより詳細なエラー内容を画面上に表示させることが効果的です。
Internet Information Services (IIS) 管理ツールにて、Web サイトを右クリックしてエクスプローラ表示します。
該当フォルダ内の web.config を開き、以下の 3 つの設定を変更します。
1) SafeMode 要素
要素 : configuration/SharePoint/SafeMode
属性 : CallStack
値 : true
2) CustomErrors 要素
要素 : configuration/system.web/customErrors
属性 : mode
値 : Off または RemoteOnly (サーバー端末のみ Off / リモートは On)
3) Compilation 要素
要素 : configuration/system.web/compilation
属性 : debug
値 : true
上記の設定後には、予期せぬエラー画面が、以下のようなエラーの詳細表示画面に切り替わります。
Visual Studio を使用したデバッグ
現象発生した Web パーツのソース コードをお持ちの場合は、Visual Studio を使用して Web パーツを表示している IIS のワーカー プロセスにアタッチ ([デバッグ] – [プロセスにアタッチ]) し、デバッグを行うことで原因追求が可能です。
なお、このような状況に備えるため、SharePoint アプリケーション開発者は、カスタム ソリューションをリリースするにあたり、納品したバージョンに相当するソース ファイルと、コンパイル時に生成されたシンボル ファイル (*.pdb) を必ずご管理いただくことを推奨します。
診断ログ
多くの場合、ハンドルされていない例外は、診断ログに記録されますので、現象発生時の状況を確認する上で診断ログは非常に重要となります。
最初の注意事項として、このファイルは保存期間が決められていますので、削除される前に現象発生時のものを即座に控えておく必要があります。
SharePoint 2013 の Web フロント エンド サーバーにおいて、インストール フォルダ下の LOGS フォルダ (既定では "C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\LOGS") にあるすべてのログ ファイルをコピーしてください。
補足 : お客様にて診断ログの保存先を変更されている場合には、変更後の保存先を参照してください。診断ログの保存先フォルダは、サーバーの全体管理サイトより [監視] – [診断ログの構成] にアクセスしていただき、[トレース ログ] セクションの [パス] よりトレース ログのパスを参照することで確認することができます。
今回の例では、以下のようなログが確認できます。
03/09/2013 17:02:21.37 w3wp.exe (0x1A78) 0x1BAC SharePoint Foundation General 8nca Medium Application error when access /SitePages/Home.aspx, Error=エラー at UnhandledExceptionWebPart.UnhandledExceptionWebPart.UnhandledExceptionWebPart.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 7e05069c-8134-708a-27e3-156c2f362b2e
開発者ダッシュボードについて
SharePoint 2010 以降では、トラブルを防止するための機能として、開発者ダッシュ ボードがあります。
この機能を使用することで、ページが表示されるまでの処理において、どの処理に時間がかかったかを確認することができます。この機能を使用するには、2 つの手順が必要となります。
使用までの手順
1. 管理シェルを起動し、以下のコマンドレットを実行して、開発者ダッシュボードを呼び出せるよう設定しておきます。
$DevDashboardSettings = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings
$DevDashboardSettings.DisplayLevel = 'OnDemand'
$DevDashboardSettings.TraceEnabled = $true
$DevDashboardsettings.Update()
タイトル : SPDeveloperDashboardSettings class
アドレス : https://msdn.microsoft.com/en-us/library/ee557630.aspx
SharePoint 2010 の開発者ダッシュボードの有効化手順は、上記と異なります。詳細については以下をご確認ください。
タイトル : 開発者ダッシュボードの使用
アドレス : https://msdn.microsoft.com/ja-jp/library/ff512745(v=office.14).aspx
2. ページの右上にあるアイコンをクリックし、実際にページ上に開発者ダッシュボードを呼び出します。
以下のように開発者ダッシュボードが起動します。新しい開発者ダッシュボードでは、ページ表示までに関連する様々な内部動作の要因 (例. SQL, SPRequest, サービス呼び出し, ULS) を分析する機能です。
画面に表示されているように、各 Web パーツの表示においてどれだけの時間がかかったか、データベース、Web サービスなどのバックエンドのデータ ソースにアクセスした時間なども詳細タブに記載されることから、どの処理において時間がかかるか、データが増えるに応じてどのように推移するかなどをページの公開前にあらかじめ把握しておくことができます。
平常時において、潜在的なリスクを事前に把握しておくことが可能になりますので、是非とも、この新機能を活用いただければと思います。