プロバイダー ホスト型アドインを 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 2013 の検索スキーマについて

こんにちは。SharePoint サポートの銭 国康 (セン クニヤス) です。 今回は SharePoint 2013 の検索スキーマについて紹介します。   目次 1 SharePoint のプロパティ検索について 2 検索スキーマとは 3 検索スキーマの処理の流れについて 4 検索スキーマの設定レベルについて 5 検索スキーマの管理について 6 検索スキーマの使用例     1 SharePoint のプロパティ検索について SharePoint 2013 では、ドキュメントやリスト アイテムの名前や、作者などのプロパティに対し、プロパティ検索ができます。 図 1-1 アイテム名のプロパティ検索の図   図 1-2  作者のプロパティ検索の図   このようにプロパティ検索を利用することで、ほしい結果を素早く検索することができ、SharePoint の大変便利な機能の一つだと言えます。さて、ドキュメント ライブラリやリストの自作した列 (固有列) に対し、どのように検索すれば良いのか、思われたことはありませんか?例えば、以下のように [部署名] という固有列があった場合、部署名でプロパティ検索を実施するには、どうすればよいでしょう。   図 1-3  ドキュメント ライブラリの固有列の図  …

0

2016 年 8 月の CU がリリースされました

2016 年 8 月の CU がリリースされました。 今月は SharePoint2010 向けの修正はリリースされておりません。なお、SharePoint 2016 向けの修正は 2 つリリースされており、それぞれ異なる修正のため、最新にするには両方インストールする必要があります。   SharePoint 2013 KB: August 9, 2016, cumulative update for SharePoint Server 2013 (KB3115450) ダウンロード: Microsoft SharePoint Enterprise Server 2013 (KB3115450) の更新プログラム SharePoint 2016 KB: August 9, 2016, update for SharePoint Server 2016 (KB3115437) ダウンロード:Microsoft SharePoint Enterprise Server 2016 (KB3115437) の更新プログラム KB: August…

0

PSCONFIGUI.EXE と PSCONFIG.EXE はどちらを使うべきか

こんにちは、SharePoint サポートの川添です。 今回の投稿では、Senior Escalation Engineer Stefan Gossner さんが投稿している以下の記事をベースに、PSCONFIGUI.EXE と PSCONFIG.EXE の相違について説明したいと思います。なお、本投稿は、作者の許可を得て投稿、一部追記しています。 Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE PSCONFIG.EXE と PSCONFIGUI.EXE は、いずれも構成ウィザードとして知られる、コマンドベースラインのツール、GUI ベースのツールという相違があります。 PSCONFIGUI.EXE は、SharePoint で更新プログラムの適用後に実施するいくつかのタスクを実施する UI ベースの構成ウィザードです。 PSCONFIG.EXE は、より詳細なオプションを指定することのできるコマンドラインツールであり、そのオプションの指定次第では UI ベースの構成ウィザードよりも短時間で完了することもあります。 一方、コマンドラインツールである PSCONFIG.EXE は、その性質上どの操作を実施するかは、実施するユーザーが指定するオプションに依ります。多くの場合、PSCONFIG.EXE を実施する場合に、以下のオプションを指定して実施することがあります。 PSCONFIG -cmd upgrade -inplace b2b -wait しかしながら、このコマンドは、PSCONFIGUI.EXE で実行される操作のサブセットを実行するのみです。例えば、このオプションでは、Web Application の _app_bin にあるファイルは更新されません。PSCONFIG.EXE で実行できるオプションには、以下のようなものがあります。オレンジでマークされた操作は、更新プログラムを適用した後に、PSCONFIGUI.EXE を実施した場合に自動的に実施される操作です。 Usage: psconfig.exe -cmd [Parameters] psconfig.exe -help…


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

Office 製品の Office 365 モダン認証フローと認証キャッシュについて

こんにちは。 SharePoint サポートの森 健吾 (kenmori) です。   Office 2016 になり、Office 製品の Office 365 に対する認証形式が標準でOffice 2013 の既定の認証形式であるレガシー認証 (Microsoft Online サインイン アシスタント) から、モダン認証 (ADAL : Active Directory Authentication Library) に変更されました。 Office の認証に関して問題が発生した際に、一般的な認証フローや各種用語および対処策 (キャッシュの削除) などを把握しておくことは、早期問題解決において重要です。   本投稿では、最初に Office 製品の Office 365 に対するモダン認証のフローを説明した上で、各種キャッシュを説明していきます。   なお、細かい説明をを飛ばしてキャッシュの削除方法を確認したいという方は、3. 認証キャッシュ 以降の内容から読み始めてください。 問題が発生した際に切り分けのためすべてのキャッシュを削除することが有効なトラブル シューティング ステップとなります。     1. モダン認証を使用するメリット   モダン認証では、認証プロセスの中に ADAL 認証を組み込んだ認証となっています。 その背景に、近年、クラウドでリリースされる新機能は ADAL…

0

‘ワークフローでは、アイテムを更新できませんでした。アイテムの 1 つ以上の列で、異なる種類の情報が必要であった可能性があります。’ エラーについて

こんにちは。江口です。今回は、SharePoint Online で、SharePoint Designer ワークフロー (SPD ワークフロー) 利用時のエラーについて案内します。 はじめに 業務フローに合わせてSPD ワークフローを発行し利用している場合、これまで問題なく使用できていたワークフローで、下記のエラーが記録されることがあります。 エラーが発生したワークフローでは、以下の図1. のようにワークフロー状態列に ‘エラー発生’ が表示されます。 図1: ワークフロー状態列に ‘エラー発生’ が表示 ワークフロー状態列の ‘エラー発生’ をクリックしてワークフローの状態ページにアクセスすると、以下のようなエラーメッセージが記録されていることを確認できます。 図2: ワークフローの状態ページ エラーメッセージ: ワークフローでは、アイテムを更新できませんでした。アイテムの 1 つ以上の列で、異なる種類の情報が必要であった可能性があります。 原因 これまで正常に動作していたワークフローに対して上記エラーが発生するようになった場合、下記の要因に該当する可能性があります。 要因) 表示名が同名のユーザーがテナント内に存在する 上記エラーは、テナント内に表示名が同じユーザー (同姓同名のユーザー) が複数存在している状況で、ワークフロー内で使用している”ユーザーとグループ” 列の値として、”返されるフィールドの名前” 項目に [表示名] を設定している場合に発生することを確認しています。 このエラーは、表示名が同姓同名のユーザーが複数存在している場合、ユーザーとグループ列の値に指定するユーザーを一意に特定できないためことに起因します。 なお、具体的には、以下のような構成および手順で現象を再現することができます。 – 事前準備 予め表示名が重複するユーザーをテナント内に作成します 表示名: UserA ログイン名: userA@tenant.onmicrosoft.com 表示名: UserA ログイン名: userB@tenant.onmicrosoft.com – 現象再現手順 1….

0

見落とされやすいパフォーマンス問題の原因

こんにちは。SharePoint サポートチームの荒川です。 これまでにも何度かブロッキング関連のトラブルについて記事を書いてきましたが、今回は見落とされやすいブロッキング要因について解説します。   この記事の趣旨 一つのコンテンツデータベースにデータ量が多いサイトコレクションとデータ量の少ないサイトコレクションを混在させた場合、パフォーマンスおよびブロッキング問題の原因になることがあるため、データ量が多いサイトコレクションには専用のコンテンツデータベースを設けることを強くお勧めします。   問題シナリオ 以下の問題について考えます。 サイトにアクセスするとしばらく (30秒から1分以上) 待たされ、サイトが開けることもあるがタイムアウトエラーになりアクセスできないこともある。 この問題は時々発生し、すべての Web サーバーを IIS リセットするか、SQL サーバーを再起動またはフェールオーバーすることで改善されるがしばらくすると再発する。   上記のような問題が発生している場合、可能性が高い原因として SQL サーバーのブロッキング問題が挙げられます。 ブロッキング問題が発生しているときの特徴には以下のようなものがあり、これらの状況が複数一致しているようであればブロッキング問題に遭遇している可能性が高くなります。  サイトにアクセスするとすぐにエラーになるのではなく、しばらく砂時計の状態で待たされる 最終的にタイムアウトエラーとなる場合もあれば、一定時間で解消することもある 問題が断続的に発生し、IIS リセットや SQL サーバーの再起動で解消される ブロッキングが発生してクエリのパフォーマンスが低下している状況では、SharePoint の診断ログに以下のような「Slow Query Duration」の警告が複数出力されることがあります。このログはクエリが完了したタイミングで記録されるものになりますので、ブロッキングが長時間におよびクエリが全く成功しない状況ではログが出力されない場合もあり、一様に判断基準にすることはできませんが、パフォーマンス問題の診断の参考として利用できる情報です。 <診断ログの例> 07/01/2016 17:15:05.35 w3wp.exe (0x1234) 0x0123 SharePoint Foundation Database fa43 High Slow Query Duration: 4562406.84626119 c6dd1b44-7004-46ff-xxxx-d2b1b9ca5ec0   上記のログが出力される場合少なくとも SQL Server に対してクエリは実行されており、そのクエリの実行に時間がかかっているということが判断できますので、SQL Server…


SharePoint ブロッキング問題の調査手法 (後編)

<連載> SharePoint ブロッキング問題の調査手法 (前編) SharePoint ブロッキング問題の調査手法 (後編)   こんにちは。SharePoint サポートチームの荒川です。 前回に引き続き、ブロッキングの要因となった操作を特定する方法について解説します。 前編では、利用状況モニターを使用してリアルタイムにブロッキングを確認する方法について解説しましたが、利用状況モニターを見ただけではブロッキングの発生有無は確認できてもその原因となった操作までは特定できませんでした。ブロッキングの原因となった操作を特定するためには、SQL Server 側の情報と合わせて、SharePoint 側の情報も確認する必要があります。   SQL Server 側での情報採取 SharePoint 側の処理を特定する前に、SQL Server 側で先頭ブロックの SQL クエリの内容と、セッション情報を取得する必要があります。前編でも述べたとおり、ブロッキングは通常 SharePoint 側からは単なる処理の遅延として扱われるため、SharePoint 側のログには一目でそれとわかるようなエラー情報は出力されません。タイムアウトエラーが記録されたときには既に遅く、ブロッキングの原因となっているアクセスに関するログはそれよりずっと前に記録されていることが殆どであり、診断ログの情報量はとても多いため、問題の発生個所の特定は容易ではありません。このため、SQL Server 側からのアプローチが必要になります。 利用状況モニターの情報は、リアルタイムでの調査には向いていますが、データを採取しておき後から調べるのには向いていませんので、利用状況モニターと同様の情報に加えて後の調査に必要となる様々な情報を一括で採取できるスクリプトを使用します。以下のスクリプトの内容をコピーして [新しいクエリ] に貼り付けて実行してみましょう。このスクリプトでは、ブロッキングに関するセッション情報、ブロッキングに関連しているプロセスで実行されているクエリ、ロックされているオブジェクトを特定するためのオブジェクト情報の一覧がまとめて採取できます。 すぐに調査しない場合であっても、[クエリ] メニューの [結果の出力] で「結果をファイルに出力」を選択して結果を保存しておけば、後から調査する際の参考データとしても使用できます。 /*出力1 – セッション一覧*/ SELECT [Session ID] = s.session_id, [Last Request Start Time] = s.last_request_start_time, [Host Name] = ISNULL(s.host_name,…


SharePoint ブロッキング問題の調査手法 (前編)

<連載> SharePoint ブロッキング問題の調査手法 (前編) SharePoint ブロッキング問題の調査手法 (後編)   こんにちは。SharePoint サポートチームの荒川です。 以前に「SharePoint と SQL ブロッキングの話」と題して SharePoint Server におけるブロッキング問題について解説しましたが、今回は SharePoint ブロッキング問題の調査手法について、より実践的な内容に踏み込んで解説したいと思います。   はじめに お客様からお問い合わせいただくパフォーマンス問題の大半を占める問題として SQL Server のブロッキング問題が挙げられます。ブロッキングとデッドロックは異なるもので、デッドロックはエラーとして検出されすぐにクライアント側にエラーが返されますが、ブロッキングは単に処理に時間がかかっている場合に発生する待ち状態になります。従ってプログラム上は正常に動作している範疇にあるものと捉えますので、これを「問題」ととらえるか否かは、ブロッキングの程度とユーザーの許容範囲に依るものとなり、その性質が、トラブルシュートをより難しいものにしています。 私の経験上、ブロッキングが発生する環境では同一コンテンツ データベース内に複数のサイト コレクションが存在し、さらに一部のサイトコレクションのデータ テーブルに数万件単位の大量のレコードが存在することが多いように見受けられます。レコードの内容は単純にリストやライブラリのアイテム数であったり、ユーザー権限や監査ログ等に関するレコードであったり、個人用 Web パーツやリンク情報といったユーザーの運用方法に大きく依存するため、一様にお伝えすることができないのが現状です。特にユーザーのアクセス毎にデータを登録したり、バッチ処理で大量のデータを処理するなどカスタマイズによる自動化が組み込まれた環境において発生しやすい傾向に感じます。 今回は私の検証環境を用いて実際に SharePoint 上でブロッキングが発生する状況を作り出し、その環境下で原因の特定を作業を進めていきますが、大規模なブロッキングを起こすようなデータ状態をすぐに再現することは難しいため、シンプルにブロッキングの調査手法をご理解いただくことを目的として、以下のような検証環境を作成してみました。 SharePoint Server 2013 SP1 オールインワン (SQL を含む) 環境 検証用リストにフォルダーを作成 フォルダー配下にアイテムを10万件登録 この環境で試しにルートフォルダーのリネームを実施したところ、およそ 40 秒程度の時間を要し、その間に別の IE ウインドウから該当フォルダー配下のアイテムのリネームを実施したところ、フォルダーのリネーム処理が完了するまでの間アイテムのリネーム処理が待たされる (ブロッキングされる) 状況を作り出すことができました。あまり頻繁に発生するようなシナリオではないかもしれませんが、ブロッキング調査の方法を理解するためのサンプルシナリオとして採用しています。   問題がブロッキングに依存するものかどうかの判断基準 ブロッキング問題にはサイトのパフォーマンスが若干低下する程度のものから、サイトに全くアクセスできなくなるものまで様々な程度があります。 パフォーマンスが一時的に低下するだけであれば、致命的な問題とはならず、エンドユーザーからの問い合わせも発生しない場合もありますが、重度なものでは長時間にわたりサイトに全くアクセスができなくなるなど致命的な問題に至る可能性もあります。…