2014年12月

2014年12月17日 (水)

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 アプリ 用の証明書の作成方法について次の記事で説明しています。

この記事で紹介されているのは、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 を使う場合は、たとえば、次のような構成が可能です(※私の検証環境がベースです)。

SSL-SNI

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

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

[SharePoint -80]

2014-12-17 16-33-43

[SharePoint - Apps]

2014-12-17 16-34-24

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

2014年12月12日 (金)

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

情報が日本語でないため、この 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 プロパティを追加すると、サイトへのセッションの有効期限が切れた際に、再びサイトにログオンできなくなる可能性がある
  • リンク データベース内でデッドロックが発生した場合のクロールのパフォーマンスを向上させる
  • ライブラリ内の "人気のあるアイテム" 表示ではより正確にカウントされるよう改善させる
  • 個人用サイトで @ を使った特定のユーザーへの発言をする際に、@名前 部分にポインターをかざすと、ログインユーザー名が表示されるよう改善させる (現在は同一表示名のユーザーがいる場合に区別がつかない)
2014年12月 8日 (月)

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

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()

 

2014年12月 5日 (金)

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

RowLimit

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

RowsPerPage

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

Course-Banner-SharePointApps

2014年12月 2日 (火)

Visual Studio 等の開発ツールを使って、Office 365 上で動作する SharePoint アプリとしてリモート イベント イベントレシーバーやアプリ レシーバーを実装する際、デバッグに Microsoft Azure の Service Bus (リレーサービス機能)を使用します。

2014年8月以降では Service Bus の名前空間を作成する際に気を付ける必要があります。現在は SAS (共有アクセス署名) と ACS (Microsoft Active Directory アクセス制御サービス) の 2種類があり、Azure Service Bus を介したリモート イベントのデバッグは現在のところ ACS のみとなっています。しかし、Microsoft Azure ポータルサイト上から新規に作成できるのは、SAS 認証を使った名前空間のみです。

ACS を使用する名前空間を作成するには、Windows PowerShell, Azure CLI, REST API のいずれかを使用します。

今回は PowerShell を使う例をご紹介しておきます(Azure PowerShell の基本的な使い方は「Azure PowerShell のインストールおよび構成方法」を参照してください)。

  1. .NET Framework 4.5 がインストールされている環境に Azure PowerShell モジュール をダウンロードし、実行します。
  2. Web Platform Installer 5.0 のウィンドウが起動するので、[インストール]をクリックします。
    2014-12-01 18-53-24
  3. [同意をする]　をクリックします。
    2014-12-01 18-53-35
  4. インストールが完了したら[完了]をクリックします。
    2014-12-01 19-08-08
  5. [終了]ボタンをクリックします。
    2014-12-01 19-08-18
  6. スタートメニューから Microsoft Azure PowerShell　を起動します。
    2014-12-01 23-02-18
  7. サブスクリプションに接続しますが、認証方法には Azure AD と証明書方式の2つがあります。今回は Azure AD を使います(※Azure AD の場合は、使用するアカウントは Microsoft アカウントではなく、組織アカウントでないといけません。Microsoft アカウントしかない場合は、「Azure PowerShell のインストールおよび構成方法」の記載にしたがって、アカウントを作成しておく必要があります)。
  8. 次のコマンドを実行すると、ログインウィンドウが表示されます。Azureにアクセスするための組織アカウントを入力します。
    $cred=Get-Credential
    2014-12-01 23-14-03
  9. 次に Add-AzureAccount -Credential $cred を実行します。
    2014-12-01 23-37-45
  10. 以上でサブスクリプションへの接続は終わりです。続いて、Service Bus 名前空間を作成するために次のコマンドを実行します。 New-AzureSBNamespace -Name '<任意の名前空間>' -Location 'Japan East'  -NamespaceType Messaging -CreateACSNamespace $true
    ※西日本の場合は Location を Japan West と指定します。サポートされる Location 名は、Get-AzureLocation を実行することで確認できます。
    ※NamespaceType は Messaging を指定します
    ※CreateACSNamespace を $true に指定し、ACS の名前空間を作成するように指定します
    2014-12-02 0-24-37
  11. 以上でService Bus の作成は完了です。Microsoft Azure 管理ポータルにアクセスします。
  12. Service Bus > 作成した名前空間名 > 接続情報 の順にアクセスします。
    2014-12-01 23-59-24
  13. ACS の接続文字列があることを確認します。
    2014-12-02 0-00-11

Visual Studio を使って SharePoint アプリ としてリモート イベントレシーバーやアプリレシーバーを作成している場合は、この ACS の接続文字列をコピーし、プロジェクトのプロパティのうち SharePoint ページの [Microsoft Azure サービス バスによるデバッグを有効にする] をオンにしたうえで、接続文字列を貼り付けます。

2014-12-02 0-03-08

以上でデバッグ実行すると、ローカルに起動する IIS Express 上でホストされるイベントレーシーバーと Office 365 (SharePoint Online) 上のサイトとがやり取りできるようになるため、デバッグ実行が可能になります。なお、SharePoint アプリの開発モデルは、オンプレミス環境での高信頼性アプリ開発の場合とは異なり　「プロバイダーホスト型」 にしておきます。

[参考]

Course-Banner-SharePointApps