SharePoint Server 2013 ではクレームベース認証モードが必須になっています。これにより顕在化した問題があります。多くの場合、Active Directory のセキュリティグループに対してアクセス許可レベルの割り当てを行うという運用をしますが、グループのメンバー変更を行った際に権限がすぐに反映されないという問題が新たに起きるようになりました。

Active Directory を使っていて SharePoint Server 2013 をオンプレミスで導入している企業にとっては、必ず直面する問題であり、海外のブログなどでもかなり取り上げられています。そして、マイクロソフト社がようやくサポート技術文書を正式に公開してくれました。

• SharePoint Server 2013 にActive Directory セキュリティ グループを使用して権限を付与している場合、権限の変更反映に時間がかかる

このことは、Japan SharePoint Support Team のブログにも記載されています。

• SharePoint 2013 Active Directory セキュリティ グループを使用した権限設定時の留意点

SharePoint Server 2013 では新たに分散キャッシュの仕組みを持っているため、対応が複雑になりがちですので、上記文書をよく確認した上、構成方針を決定されるとよいと思います。

※SharePoint Server 2013 の認証に関して基本的な内容については、
弊社の下記のコースで取り扱っております。よろしければ、ご利用くださいませ。

SharePoint Server 2013 は SSL を構成することが推奨されています。

このバージョンの SharePoint は OAuth　2.0 をサポートしており、Exchange Server (タスク同期など)や Office Web Apps Server, Lync Server, クラウド上の自動翻訳サービス (SharePoint の Machine Translation Services)　などと連携する際にこれを使用しますが、そもそも OAuth 2.0 を使う HTTP 通信では SSL を使う必要があります。とはいえ、Exchange Server や Office Web Apps Server と連携させる場合は、SSL をバイパスできるため、SharePoin Server 2013 では必須とまではなっていません。

SSL での通信を行うよう構成した場合、SharePoint 2013 から新たに導入されたSharePoint アプリを利用する際に基盤管理者が悩むのが　IIS　の証明書の構成です。SharePoint アプリはセキュリティ リスクを考慮し、SharePoint アプリが動作するためのドメインを SharePoint の URL ドメインとは異なるものにするよう構成する必要があります。たとえば、contoso.com というドメイン名を使用している場合は、apps-contoso.com というように、全く異なるドメイン名にします。となると、SharePoint 上でホストされるアプリの場合は、実質的にはアプリを起動したサイトのサブサイトとなり、SSL を通常通り構成していると、証明書エラーの問題が発生します。

日本マイクロソフト社が公開している、Japan SharePoint Support Team Blog では、SharePoint アプリ 用の証明書の作成方法について次の記事で説明しています。

• SharePoint ホスト アプリ環境の証明書を作成する

この記事で紹介されているのは、Webサーバーに適用するデジタル証明書にサブジェクト代替名を指定したワイルドカード証明書を使用するというアプローチです。

これ以外のアプローチでは、SharePoint アプリ用に SharePoint Webアプリケーションを新規に作成する必要があり、ホストヘッダー名を付けて構成します。この場合、証明書の構成には、2つ方法があります。

• SharePoint Web アプリケーションをホストする IIS サイトの IPアドレスを、既存のIISサイトのIPアドレスとは異なるものにする
• SharePoint Web アプリケーションをホストする IIS サイトは単一のIPアドレスにし、Server Name Indication を使用する

IIS は複数サイト作成する必要がある場合は、単一のIPアドレス、ポート番号で構成したいしようと思うとホストヘッダーを指定すれば済みます。ところが、SSL の証明書は FQDN ごとに IP アドレスを個別に設定しなければ、サイトごとに異なる証明書を指定することができません。そのため、IPアドレスを IISサイトごとに個別指定する必要があるわけです。しかし、これは IIS 7.5 までの話です。IIS 8.0 以降では、Server Name Indication (SNI) を利用できるようになっているため、単一のIPアドレスであっても対応できるようになっています。

SNI を使う場合は、たとえば、次のような構成が可能です(※私の検証環境がベースです)。

SNI を使用する場合は、上図の通り、IISサイトのバインド編集画面でホスト名を指定した上で、「サーバー名表示を要求する」チェックボックスをオンにします。

この構成例では、それぞれのデジタル証明書のサブジェクトは次のように構成しています。

[SharePoint -80]

[SharePoint - Apps]

ちなみに、Access Services 2013 も SharePoint アプリです。SharePoint アプリをユーザーに利用される必要がある基盤を担当する方々は、こうしたアプローチがあることを念頭に構成していただくとよいと思います。

オンプレミス環境の SharePoint Server 2013 の December 2014 CU がリリースされましたので、下記ページを更新しました。

• SharePoint Server 2013 CU, PU, SP (Build Number)

情報が日本語でないため、この CU の内容を要約します(まずはサーバー分のみ※Foundationはまた別途追記します)。

• 次の問題を修正

1. User Profile Service アプリケーション、検索サービス アプリケーション、App Management サービス アプリケーションをセットアップしており、そのサーバーに対して代替アクセスマッピングとフォームベース認証を構成している際に、そのサーバー上でホストされているサイトにアクセスし、ユーザー検索した結果からユーザー名をクリックするとエラーメッセージを受け取る可能性がある
2. SharePoint 2010 ファームから SharePoint 2013 ファームの検索サービス アプリケーションを利用するよう構成している場合は、SharePoint 2010 ファームで代替アクセスマッピングを構成していると、SharePoint 2010 側の検索センター内のコンテンツを検索するときに検索結果に表示される URL が正しくない
3. SharePoint 2013 リストで評価(いいね、星)機能をオンにしており、名前にアポストロフィーを含むユーザーを追加し、そのリストをユーザーが必要時してアイテムを評価すると、評価が表示されなくなり、エラーメッセージが表示される。
4. 複数ノードで構成している SharePoint 2013 検索ファーム上で "Did you mean" (スペル修正候補の表示) が動作しないことがある
5. マルチノードの SharePoint 2013 検索ファームをセットアップする際に、プライマリ インデクサーノードをメンテナンスなどの目的で再起動すると、セカンダリノードの再起動を引き起こす。このため、プライマリ ノードの再起動中はクエリが停止してしまう
6. SAML ベースのクレーム認証を構成しているサイトにサインインすると、コンテンツ検索時に結果が表示されない
7. SharePoint 2013 ベースのエンタープライズ検索を使っていると、おすすめコンテンツを表示する機能(Best Bets) が動作しない可能性がある
8. SharePoint 2013 サイト用の SAML トークン プロバイダーを構成しており、そのサイトの web.config ファイルの CookieHandler.Domain プロパティを追加すると、サイトへのセッションの有効期限が切れた際に、再びサイトにログオンできなくなる可能性がある

• リンク データベース内でデッドロックが発生した場合のクロールのパフォーマンスを向上させる
• ライブラリ内の "人気のあるアイテム" 表示ではより正確にカウントされるよう改善させる
• 個人用サイトで @ を使った特定のユーザーへの発言をする際に、@名前 部分にポインターをかざすと、ログインユーザー名が表示されるよう改善させる (現在は同一表示名のユーザーがいる場合に区別がつかない)

SharePoint 2013 REST API の RowLimit ですが、昨日の記事で紹介したように最大 500 まで指定可能です。

• [SP2013] 検索 REST API の RowLimit と RowsPerPage

REST API を利用する際に RowLimit を明示しなければ既定では RowLimit=10 が設定されます。指定可能なのが、500 までであり、501 など指定すると結果が返らずエラーとなります。これは Office 365 上の SharePoint Online も同様です。

ただし、オンプレミスの場合はこの値を変更できます。動作テストなどで設定変更したい場合に役立つと思います。

Windows PowerShell を使って次の通り指定します。

#SharePointのスナップインは必要に応じて追加します。
Add-PSSnapin Microsoft.SharePoint.PowerShell

#検索サービスアプリケーションオブジェクトを取得し、MaxRowLimitの既定値を確認します。
$ssa=Get-SPEnterpriseSearchServiceApplication
$ssa.maxRowLimit

#値を変更します。
$ssa.maxRowLimit=100
$ssa.Update()

SharePoint 2013 では検索に REST API が使用できます。概要を把握するには次の MSDN のページが参考になるのですが、この資料を参考にする際に、2点ほど気を付けたいところがあります。

• SharePoint 検索 REST API の概要

RowLimit

まず、RowLimit です。これは一度に返される最大件数を指定します。何も指定しない場合は既定では 10 になっています。この値は最大 500 まで指定可能であり、これを越えるとエラーとなってしまうので注意が必要です。 500 を越えてアイテムを取得する場合は StartRow を明示するようにします。

RowsPerPage

上記リンク先の資料に、RowsPerPage の説明があります。このプロパティはサーバーサイドのAPIでは、SharePoint 2013 から廃止されているようです。ということは、クライアントAPIとしても当然使うべきではないということになると思われます。

• Query.RowsPerPage property