こんにちは。SharePoint サポート チームの成田です。SharePoint Server 2013 ではソーシャル機能が大幅に強化されていますが、本ブログではソーシャル機能を利用する上で前提となる個人用サイトの作成について触れたいと思います。個人用サイトが作成されるタイミングは、ユーザーがサイトページ上の [ニュース フィード] やユーザー名のドロップダウンの [プロファイル] をクリックした場合など、初めて個人用サイトのホスト サイトコレクションにアクセスしたときです。個人用サイトの作成がリクエストされると、毎分実行されるタイマージョブ [個人用サイト インスタンス化のインタラクティブな要求のキュー] によってリクエストされたユーザーの個人用サイトが作成され始めます。この時、ユーザーは個人用サイトの作成が完了するまで下記のような画面が表示されます。数分待ち、個人用サイトの作成が完了すると、下記のようにニュースフィードなどの機能が使用可能になります。個人用サイトは、上記のように、ユーザーが個人用サイトのホストサイトコレクションに最初にアクセスしたタイミングで作成されることが基本となりますが、本ブログでは管理者があらかじめ個人用サイトを作成する方法を紹介します。あらかじめ個人用サイトを作成しておくことで、ユーザーが初めて個人用サイトのホストサイト コレクションにアクセスした瞬間からニュース フィードなどの機能を利用できるようになります。管理者が個人用サイトを作成する方法============================管理者が個人用サイトを作成するには以下のメソッドを利用します。UserProfile.CreatePersonalSite メソッド (Microsoft.Office.Server.UserProfiles)http://msdn.microsoft.com/ja-jp/library/microsoft.office.server.userprofiles.userprofile.createpersonalsite.aspx上記のメソッドを、Visual Studio や PowerShell から実行できます。※個人用サイトを作成する前に、ユーザーのプロファイルが事前に作成されている必要がありますので、手動でプロファイルを追加するか、プロファイル同期によってあらかじめプロファイルが存在することを確認してください。※以下に紹介するコードやスクリプトはサンプルですので、実行環境に合わせて作成し、実行前に十分検証してください。1. Visual Studio を使用してプログラムを記述する場合は、以下のようなコードを記述します。-----SPSite site = new SPSite(http://sharepoint/mysitehost);SPServiceContext serviceContext = SPServiceContext.GetContext(site);UserProfileManager profileManager = new UserProfileManager(serviceContext);UserProfile profile = profileManager.GetUserProfile("domain\\username");profile.CreatePersonalSite();-----※http://sharepoint/mysitehost は個人用サイトのホスト サイト コレクションを指定します※domain\\username は個人用サイトを作成するユーザー名を指定します2. PowerShell から UserProfile.CreatePersonalSite メソッドを利用するには以下の手順を実施します。1) 任意の SharePoint サーバーに管理者アカウントでログオンします。2) [スタート] メニューから [SharePoint 2013 管理シェル] を管理者モードで起動します。3) 以下のようにコマンドを実行します。-----$mysite = Get-SPSite http://sharepoint/mysitehost$user = "domain\username"$context = [Microsoft.Office.Server.ServerContext]::GetContext($mysite)$upm = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)$prof = $upm.GetUserProfile($user)$prof.CreatePersonalSite()-----※http://sharepoint/mysitehost は個人用サイトのホスト サイト コレクションを指定します※domain\username は個人用サイトを作成するユーザー名を指定します上記の例では個人用サイトを 1 ユー��ーずつ作成していますが、必要に応じてユーザー プロファイルを列挙して複数のプロファイルを作成することも可能です。例えば以下のブログでは複数の個人用サイトを一気に作成する方法が紹介されています。http://msftplayground.com/2010/09/provisioning-my-sites-sharepoint-2010/全プロファイルの個人用サイトを作成するということは、プロファイル数分のサイトコレクションを作成するということになるので、作成時には WFE や DB サーバーにある程度の負荷をかけることにご注意ください。(実際の負荷についてはいくつかの個人用サイトを作成してご確認ください)大量のプロファイルが存在する場合には複数回に分けて計画的に作成する工夫も必要になるかもしれません。いかがでしたでしょうか。ソーシャル機能が大幅に向上した SharePoint 2013 をぜひお試しください！
こんにちは SharePoint サポートの森 健吾 (kenmori) です。
今回の投稿では、すでに Web キャスト等でも公開しております Web パーツを含むページが予期せぬエラー等で表示できなくなった際のトラブル シューティング方法について SharePoint 2013 をベースとしてご説明します。
この投稿には SharePoint 2013 での最新情報は少ないものの、バージョンを問わずトラブルシューティングの基礎となりますため、情報を更新する目的で投稿します。
SharePoint では、製品に用意された様々な Web パーツや、それらをカスタマイズした Web パーツ、または Visual Studio によってカスタマイズしたオリジナルの Web パーツを追加して独自のページを作成することができます。しかし、様々なページを実現できるがゆえに、エラーが発生した場合は、どう対処すべきかわからないという状況が想定されます。
この投稿では、Web パーツ ページが表示できなくなった場合のトラブル シューティングについて説明していきます。また、この投稿で使用している画面ショットは、SharePoint 2013 のものを使用していますが、それ以前のバージョンにおいても有効な方法をご紹介します。
エラー画面
SharePoint では、Web パーツを含むページの表示処理などにおいてエラーが発生し、例外がハンドルされない場合、このように "申し訳ございません。何らかの問題が発生しました。" などのエラー画面が表示されます。
このような問題が発生した場合は、次のような手順を行ってください。
トラブル シューティング手順
Web パーツ ページが表示できない場合のトラブル シューティングを実施するにあたって、最も簡単な方法は Web パーツの管理の画面を使用します。最初にこの問題がそのページ特有の現象かどうかを確認するために、URL を直接指定して影響範囲を確認します。影響範囲がページ固有である場合は、以下にその手順についてトラブルシューティングの流れをご説明いたします。
手順概要
さらに、現象発生の原因を追究する場合は、現象発生時のバックアップ データなどをテスト環境に復元し、テスト環境にて継続して調査を実施することをお勧めします。
手順詳細
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アドレス : http://msdn.microsoft.com/en-us/library/ee557630.aspx
SharePoint 2010 の開発者ダッシュボードの有効化手順は、上記と異なります。詳細については以下をご確認ください。
タイトル : 開発者ダッシュボードの使用アドレス : http://msdn.microsoft.com/ja-jp/library/ff512745(v=office.14).aspx
2. ページの右上にあるアイコンをクリックし、実際にページ上に開発者ダッシュボードを呼び出します。
以下のように開発者ダッシュボードが起動します。新しい開発者ダッシュボードでは、ページ表示までに関連する様々な内部動作の要因 (例. SQL, SPRequest, サービス呼び出し, ULS) を分析する機能です。
画面に表示されているように、各 Web パーツの表示においてどれだけの時間がかかったか、データベース、Web サービスなどのバックエンドのデータ ソースにアクセスした時間なども詳細タブに記載されることから、どの処理において時間がかかるか、データが増えるに応じてどのように推移するかなどをページの公開前にあらかじめ把握しておくことができます。
平常時において、潜在的なリスクを事前に把握しておくことが可能になりますので、是非とも、この新機能を活用いただければと思います。