SharePoint Online と連携するカスタム アプリケーションでエラー ログに残すべき必須情報

こんにちは SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、SharePoint Online および OneDrive for Business と連携するカスタム アプリケーションで、エラーが発生した際にログに含めるべき情報についてご紹介します。   関連付け ID について SharePoint Online や OneDrive for Business に対して CSOM や REST API を呼び出すアプリケーションにおいては、問題が発生した際のトラブルシューティングのために、エラー発生時の関連付け ID が必要になります。このため、カスタム アプリケーション側でもこの関連付け ID をログに残す必要があります。 ブラウザからアクセスする通常の利用シナリオにおいても、Fiddler や IE 開発者ツールなどで HTTP トレースを採取し、応答ヘッダーから SPRequestGUID 値を確認することがありますが、API を使用した場合においても有効な方法となります。 弊社サポートで調査を行う際には、この関連付け ID から現象発生時のサーバー側のログを確認します。なお、ログの保持期間はとても短いため (通常は約1日程度)、現象発生後なるべくお早めにお問い合わせください。   概要 上記ご説明をふまえ、一般的に調査を実施する上で必要な情報は以下になります。 詳細な説明は後記いたします。 1. 現象が発生した日付と時刻 2. エラー…

0

PowerShell サンプル : SharePoint Online HTTP 調整 (応答コード : 429) 対策の増分バックオフ リトライ

こんにちは SharePoint サポートの森 健吾 (kenmori) です。 SharePoint Online に対して CSOM などのクライアント サイド API を大量に呼び出した際、一定期間内における HTTP の要求数やデータ センター側の CPU リソース使用量によっては、一時的なブロックが発生します。 詳細については、以下のページに記載されています。 タイトル : SharePoint Online で調整またはブロックを回避する方法 アドレス : https://msdn.microsoft.com/ja-jp/library/office/dn889829.aspx この問題が発生することを前提とした有効な対処策として、上記ページではC# を使用した調整を回避するための期間をあけて再実行するための増分バックオフ リトライ コードが紹介されております。 この投稿では、運用シナリオにおいても頻繁に使用される PowerShell 版のサンプルを紹介しますので、ご参考にしてください。 以下のコードでは、$script:context.ExecuteQuery() を自作関数 ExecuteQueryWithIncrementalRetry に置き換えます。   $siteUrl = “https://tenant.sharepoint.com” # 必要なアセンブリをロードします [void][System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint.Client”) [void][System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint.Client.Runtime”) # SPO に接続します $script:context = New-Object Microsoft.SharePoint.Client.ClientContext($siteUrl) #ユーザー名入力を促します。 Write-Host…

0

サンドボックス ソリューションのイベント レシーバーを、リモート イベント レシーバーに置き換える方法

こんにちは。SharePoint サポートの森 健吾 (kenmori) です。 導入 コード付きサンドボックス ソリューションを代替のソリューションに置き換える開発を実施されている方が多いと考えております。サンドボックス ソリューションの変換先としては、以下のようなガイダンスが記載されています。 タイトル : サンドボックス ソリューションの変換ガイダンス アドレス : https://msdn.microsoft.com/ja-jp/pnp_articles/sandbox-solution-transformation-guidance 上記ガイダンスにからリンクしていくと、以下のページにイベント レシーバーの代替としてリモート イベント レシーバーの使用が紹介されています。 タイトル : SharePoint でリモート イベント レシーバーを使用する アドレス : https://msdn.microsoft.com/ja-jp/pnp_articles/use-remote-event-receivers-in-sharepoint 今回の投稿では、上記内容を少しわかりやすく説明することと、既存のサンドボックス ソリューション、カスタムリスト定義に近い形で置き換えやすいサンプルに仕上げましたので、その内容をご提案します。 なお、リモート イベント レシーバーという仕組みを使う上で運用的に重要な点が 1 点あります。リモート イベント レシーバーは SharePoint Online から直接ネットワーク接続できる場所にイベント処理用の外部 Web サイトを用意する必要があります。この時点で、Azure Web App などのクラウド ベースの Web サイトや、インターネット公開したオンプレミスの Web サイトが必要になり、構成変更追加コストが生じる点についてはあらかじめご了承ください。   リモート イベント レシーバーへの置き換えを理解するポイント サンドボックスのイベント レシーバーをプロバイダーホスト型アドインのリモート イベント…

0

プロバイダー ホスト型アドインを Azure Web App として展開する方法

こんにちは。SharePoint サポートの森 健吾 (kenmori) です。 SharePoint Online のサンドボックス ソリューションの廃止の通達に伴い、ソリューションの移行先を検討している方もいらっしゃると想定しております。今回の投稿では、プロバイダー ホスト型アドインの展開方法について紹介します。 開発方法からはじめたい方は、こちらのサイトを使用いただくことをお勧めします。 タイトル : プロバイダー ホスト型 SharePoint アドインの作成を始める アドレス : https://msdn.microsoft.com/ja-jp/library/office/fp142381.aspx ただし、上記の開発手法を SharePoint Online で運用する場合、ネットワークの都合上、インターネット上の外部ホスト先の Web サイトにコードを展開する必要が出てきます。 今回の投稿では、外部ホスト型のアドインを展開する手順の例としてVisual Studio 2015 を使用し、弊社サービスである Azure Web App に展開する方法についてご紹介します。   プロバイダー ホスト型アドインの構成  以下にプロバイダー ホスト型アドインの動作を簡単に紹介します。 プロバイダー ホスト型アドイン プロバイダー ホスト型アドインはブラウザーを一度介して、ユーザー コンテキスト (SPAppContext) を受け渡すシングル サインオンです。ブラウザーから外部ホストに直接アクセスし、外部ホストからは Access Token を使用して SharePoint Online に HTTP メソッド呼び出しする動作になります。 Visual…

0

SharePoint Online サンドボックス ソリューションに関する告知について

こんにちは。SharePoint サポートの森 健吾 (kenmori) です。   先日、SharePoint Online のサンドボックス ソリューションに関する重要なお知らせがありました。 タイトル : Removing Code-Based Sandbox Solutions in SharePoint Online アドレス : http://dev.office.com/blogs/removing-code-based-sandbox-solutions-in-sharepoint-online   本投稿でも2016/08/04 時点の内容を抜粋いたします。 As part of the removal process, activation of new code-based sandbox solutions, as well as updates of existing solutions are no longer available. 機能削除の過程において、コード付きのサンドボックス ソリューションの新規アクティブ化および既存ソリューションの更新はできなくなりました。 In the coming weeks, running code-based…

0

クライアント アプリケーションから SharePoint オンプレミス ADFS 認証環境にアクセスする

こんにちは、SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、SharePoint オンプレミス ADFS 認証環境のサイトに対して、クライアント アプリケーションからユーザー認証し、HTTP を要求する処理を記載します。   利用シナリオの考察 この方法が最も求められるシナリオは、ウォームアップ スクリプトです。 SharePoint サーバーに 1 度アクセスしておくことで、アプリケーションやサイト上必要な初期処理やキャッシュの作成を行わせてしまいます。2 回目以降にアクセスする場合は、別ユーザーも含めて素早くサイトにアクセスすることができます。 Web アプリケーションの拡張を実施することで、SharePoint は同一コンテンツを複数領域にホストさせることができますが、ウォームアップ スクリプトは認証エンドポイントごとにそれぞれ実施したほうが効率的です。 現時点では、便宜上ブラウザーを使用してウォームアップする人も多いと思います。ただし、ブラウザーはユーザーがログオンして使用するクライアント アプリケーションであるため、ブラウザーを使用するウォーム アップ スクリプトはログオフした状態で実行することはサポートされていませんし、正常動作しません。そのため、ウォームアップ スクリプトを実行するサーバーをログオフさせて運用することが必要である場合には、このソリューションが必要となる可能性があるかもしれません。 別の利用シナリオとして、カスタム クライアント アプリケーションを開発し、Web サービスや REST API にアクセスする際に、SharePoint の ADFS 認証を使用した領域を選択する方をいらっしゃるかもしれません。 この場合においても、本投稿に記載された認証 Cookie を使用することで技術的に可能です。特に、実行するユーザーを扱う処理の実装が重要である場合には ADFS 認証させるためにご使用を検討ください。 ただし、SharePoint 製品としては Web アプリケーションを拡張した際にはWindows 認証だけの領域を 1 つは保持することを推奨しており、例として検索インデックスを作成するクロールの際には Windows 認証を使用してアクセスすることになります。 Windows NTLM 認証を使用して、権限の高いユーザーでアクセスする方が認証のオーバーヘッドを抑えられ、ほとんどのソリューションを実現できると考えています。…

0

SharePoint オンプレミスの ADFS 認証にてユーザー検索、解決処理を拡張するクレーム プロバイダー サンプル コード

こんにちは SharePoint サポートの森 健吾 (kenmori) です。 SharePoint Server オンプレミス版で ADFS 認証を構築すると、ユーザー検索が実行されず、どのようなユーザーを入力しても解決してしまう状況にとまどったことがある方も多いと思います。 今回の投稿では、その状況を回避するためのユーザー検索や解決処理を実装する最小構成のサンプル コードを記載いたします。この規模のサンプルは実運用で使用するには不十分ですが、カスタム クレーム プロバイダーの実装方法を理解するためには有用だと考えています。   参考情報 はじめに参考資料を記載いたします。クレーム プロバイダーは、今回機能拡張するユーザー検索や解決処理以外にも様々な機能を提供します。全体的なモジュールの役割は下記サイトで抑えていただけますと幸いです。 タイトル : SharePoint 2013 のクレーム プロバイダーアドレス : https://msdn.microsoft.com/ja-jp/library/office/ee535894.aspx 抜粋 信頼された SAML トークン発行者の場合、SharePoint Server は、リストや検索を提供しません。ユーザーが値を入力すると、SharePoint Server はその値を常に解決します。つまり、「adam@contoso.com」と入力すると、ユーザー選択ウィンドウはその値を受け入れます。これは、STS での解決方法、検索の実装方法、またはクレーム値のリスト方法を指定する業界標準が存在しないためです。 ユーザーは組み込みのクレーム プロバイダーをオーバーライドして、カスタム検索、名前の解決、およびリスト機能を実装できます。これは、たとえば信頼された SAML トークン発行者を使用するシナリオでは特に便利です。   タイトル : [方法] SharePoint 2013 でクレーム プロバイダーを作成するアドレス : https://msdn.microsoft.com/ja-jp/library/office/ee537299.aspx タイトル : [方法] SharePoint 2013 でクレーム…

0

SharePoint Server でユーザーが認証された後に発行されたクレームを確認する方法

こんにちは SharePoint サポートの森 健吾 (kenmori) です。今回の投稿では、SharePoint Server でクレームベース認証による認証後に発行されたクレームの値をすべて出力し、確認するためのサンプルをご紹介します。 用途 主に以下のような用途でご使用いただけますと幸いです。 ・クレーム ベース認証の理解・クレームを使用した認証関連のカスタマイズを実施する事前準備・フェデレーション認証 (例. ADFS 認証) でセキュリティ グループに何を入力すれば良いかの確認 特に、ADFS 認証でセキュリティ グループ名として入力する値に関するご質問が多い状況です。ADFS の [要求規則の編集] から、設定値を確認する必要があります。 "Token-Groups (SID)"  (例. S-1-5…)"Token-Groups – ドメイン名を含む" (例. DOMAIN\group_name)"Token-Groups – 完全修飾ドメイン名を含む" (例. DOMAIN.local\group_name)"Token-Groups – 名前の指定なし" (例. group_name) 質問に至る背景として、フェデレーション認証 (例. ADFS 認証) は外部の信頼された ID プロバイダーに認証処理を委任しています。そのため、SharePoint のフェデレーション認証用のクレーム プロバイダーは、メンバーおよびロール情報を保持しておりませんし、それらの情報の入手先も把握していません。その結果、PeoplePicker による人やグループの検索が実施できず、入力された値をそのまま解決することしかできません。 実際に有効な、ADFS 認証でセキュリティ グループ名を確認するには、本サンプルで認証されたユーザーのクレーム タイプとして出力される http://schemas.microsoft.com/ws/2008/06/identity/claims/role の値を確認し、その値をグループ名として PeoplePicker…

0

PowerShell で個人用ビューの内容を取得する方法

SharePoint サポートチームの多田 信吾 (タダ シンゴ) です。 SharePoint の発行ページ等で、個人用ビューの設定が許可されている場合、各ユーザーがそれぞれ個別に個人用ビューに Web パーツを貼り付けることができます。 管理者が各ユーザーの個人用ビューを確認したい場合、各個人で作成しているビューであるため、UI からは確認ができません。このため、PowerShell で個人用ビューの設定を抽出する必要がありますが、PowerShell はスクリプトを実行しているユーザのコンテキストで動作するため、そのユーザーの個人用ビューしか取得できません。例えば以下のサンプルスクリプトにおいて、スクリプトを実行しているユーザーが、domain\testuser01 である場合は、domain\testuser01 の個人用ビューのみが取得されます。   $web = Get-SPWeb "http://sp2010/sub01" $file = $web.GetFile("Pages/testpage01.aspx") $webpartMgr = $file.GetLimitedWebPartManager([System.Web.UI.WebControls.WebParts.PersonalizationScope]::User)   このため、以下のサンプルスクリプトのように、各ユーザーのユーザートークンを指定して SPSite のオブジェクトを生成することで、各ユーザーの個人用ビューを取得することが可能です。 以下のサンプルスクリプトでは、サイトに所属するすべてのユーザーの個人用ビューにおいて、貼られている Web パーツの情報を取得してテキストに書き出しています。   $web = Get-SPWeb "http://sp2010/sub01"   foreach($user in $web.AllUsers) {     $site = New-Object Microsoft.SharePoint.SPSite("http://sp2010", $user.UserToken)     $web2 = $site.OpenWeb("sub01/")    …

0

Feature Stapling を使用して、個人用サイトのカスタマイズを実施する

こんにちは SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、SharePoint Server 2013/2010 において、Feature Stapling (ホチキス止め機能) を使用した個人用サイトのカスタマイズの例をご紹介します。(SharePoint Online では、ファームソリューションとして展開する本カスタマイズは実施できませんのでご了承ください。)   個人用サイトは、下記の投稿にもある通り、ホストサイト コレクションとユーザーごとの個別サイト コレクションに分かれます。 タイトル : SharePoint 2013 個人用サイトのアーキテクチャについて アドレス: http://blogs.technet.com/b/sharepoint_support/archive/2014/10/15/sharepoint-2013-my-sites-architecture.aspx 個別のサイト コレクションは、ユーザーごとにサイト コレクションが別々に作成されるので、全ユーザーのサイト コレクションに一律でカスタマイズを適用することは簡単ではありません。   今回紹介するカスタマイズ手法 Feature Stapling は、サイトにカスタマイズに組み込むのではなく、サイト定義 (個人用サイトのベース テンプレート SPSPERS#2) にカスタマイズを組み込む方法となります。個人用サイトの定義にカスタマイズを組み込むことで、個人用サイトが作成されたタイミングで機能が有効化され、自動的にカスタマイズが適用されていく仕組みとなります。 それでは、手順を見てみましょう。 実装手順 1. Visual Studio を起動し、[ファイル] – [新規作成] – [プロジェクト] をクリックします。2. SharePoint 2013 – 空のプロジェクトを選択して、ファーム ソリューションでプロジェクトを作成します。 3….

0