2015年5月

2015年5月31日 (日)

SharePoint API を使って次のように、ProfilePropertyManager オフジェクトを取得しようとする際に、例外が発生することがあります。下記例は C# で記述していますが、そのほかに Windows PowerShell を使用する場合にも該当します。


...
  using (SPSite site = new SPSite(url)) {
                //ランタイムサービスのコンテキストの取得
                SPServiceContext context = SPServiceContext.GetContext(site);

                try
                {
                    ProfilePropertyManager profilePropManager =
                        new UserProfileConfigManager(context).ProfilePropertyManager;
...

エラーの内容は次の通りです。

2015-05-29 2-42-05

"UserProfileApplicationNotAvailableException_Logging::
UserProfileApplicationProxy.ApplicationProperits ProfilePropertyCache
does not have {GUID}

これは、ユーザー プロファイル サービス アプリケーション上でコードを実行するアカウントに適切な権限が付与されていないことが原因であるようです。たとえば、私の環境では次のようになっています。

[確認手順]

  1. サーバー全体管理サイトにアクセスする。
  2. サービス アプリケーションの管理ページにアクセスする。
  3. ユーザー プロファイル サービス アプリケーションを選択し、[権限]をクリックする。
    2015-05-31 17-18-49

 コード実行アカウントは contoso\administrator なのですが、ファームアカウントとサービスアプリケーション用のアカウントの2につのみフル コントロール権限が付与されている状態です。

2015-05-31 17-20-34

ここに contoso\administrator アカウントを追加し、フル コントロール権限を付与します。

2015-05-31 17-21-37

以上で問題が解決するはずです。

2015年5月29日 (金)

ライブラリやリストに管理されたメタデータ列を追加すると、自動的に owsTaxId<列名> という名前の管理プロパティが作成されます。このプロパティを使って絞り込み検索できます。

たとえば、SharePointCategory という名前の管理されたメタデータ列があるとします。

2015-05-29 14-36-31

次のように "サイト管理" となっているアイテムに絞り込み検索できます。

owsTaxIdSharePointCategory:サイト管理

 

2015-05-29 14-38-19

管理プロパティでの絞り込みでは ":" または "=" が使用できます。":" は Contains を表し、"プロパティに~の値を含む" という意味になります。一方の "=" は、プロパティ値が指定した値と厳密に値が一致することを表します。

さて、管理メタデータに対する絞り込み検索ですが、基本的に"=" は使用しないでください。管理メタデータは、内部的には次のような値を持っています (REST API でアクセスしたところ)。

2015-05-29 21-36-59

[owsTaxIDSharePointCategory の値]

GP0|#5e85831a-4ebf-4381-9cde-bc1acc2849e4;L0|#05e85831a-4ebf-4381-9cde-bc1acc2849e4|サイト管理;GTSet|#a1fd6dba-538b-45f7-a997-d1caeec3c63c

管理メタデータは、用語と用語ごとの ID を持っているため、これらの値が格納されているわけです。となると、'owsTaxIDSharePointCategory="サイト管理"' などと指定すると、厳密に値が一致しないため、検索結果がないと言われてしまいます。ですから、"指定した値を含む" という意味の ":" を指定して、検索結果を絞り込む必要があります。

 

Course-Banner-SearchShort
 

2015年5月27日 (水)

2015年4月19日より、Office 365 から Yammer にアクセスするためのアプリランチャーが利用できるようになっていますが、これは Yammer Enterprise をアクティブ化していないと表示されません。

Yammer Enterprise のアクティブ化手順は次のURlを参照してください。

 

Microsoft Ignite 2015 でもアナウンスがあったようですが、Office 365 の先行リリースの設定が更新されています。先行リリースの設定は、いち早く Office 365 に導入される新機能を使えるようにする設定のことです。新機能が公式にアナウンスされてから1週間以内に先行してロールアウトされます。

私のテナントでは 2015/5/6 付でメッセージが次の届いています。

Updated Feature: Evolving First Release

Today we are beginning to roll-out a new Select people option for First Release. This new option lets you pick people to preview updates so that you can prepare your organization. We recommend that you turn on First Release Select people for your Office 365 administrators and power users in your organization.

ということで、これまで先行リリースの設定は組織全体での適用のみでしたが、更新された機能では、テナント内の特定のユーザーのみ選択して、先行リリースを試せるようになります。

2015-05-27 23-22-58

Office 365 の管理者やパワーユーザーの方には先行して新機能を試してどう運用するのか準備することが推奨されています。

 

 

※2015/5/27 記事をよりわかり易いようにブラッシュアップしました。

現在 日本マイクロソフト社が de:code 2015 を開催中ですが、イベントの規模からみても、Office 365 関連の情報は Microsoft Ignite 2015 と比較すると少ない印象ですね。

さて、2015年末までに、Office 365 ではエンタープライズ検索用の新たなハイブリット検索シナリオが利用できるようになります。

そもそも現在はどうなっているかといえば、Office 365 とオンプレミスの SharePoint Server との検索連携はそれぞれの検索インデックスに結果が格納され、Office 365 または オンプレミスの SharePoint Server 2013 いずれからかの検索結果にそれぞれの検索結果を取得できるようになっています。検索結果が格納されている検索インデックスが異なるため、結果は個別の結果セットとして扱われます。

新しいサービス アプリケーションによりオンプレミスの検索結果が統合される

簡単に言うと、今後はバラバラになっている検索インデックスが Office 365 に統合できるようになります。2015年度末までにオンプレミスのSharePoint Serverに対して Cloud Search Service Application が提供される予定になっています(SharePoint Server 2013 だけでなく、SharePoint Server 2016 も同様になるようです)。このサービス アプリケーションが提供されることで、Office 365 上からオンプレミスにある次のコンテンツが検索できるようになります。

  • 既存の SharePoint Server 2007, 2010, 2013
  • ファイル共有
  • BCS コネクター

理屈は次の通りです。オンプレミスの新しいサービス アプリケーションを導入することで、オンプレミス側はコンテンツクロールとコンテンツ解析のみを受け持ち、この情報をセキュアな状態で Office 365 側に渡します。Office 365 側では、受け取ったデータを処理し、SharePoint Online の検索インデックスに格納します。このようにして、今までバラバラになっていた検索インデックスが統合できるようになるわけです。

HybridSearch

[Microsoft Ignite 2015 より]

そのため、SharePoint Online 上からの検索結果は、SharePoint Online もオンプレミスも同一の検索結果ページに表示されるようになります。とはいえ、たとえば、オンプレミスからの結果なのか、それとも SharePoint Online 上からの結果なのか、区別して検索結果ページをカスタマイズしたいというニーズもあるでしょうから、isExternal というメタデータが設定されるようになるようです。

Office 365 導入ユーザーの方からは、オンプレミスと Office 365 の検索の違いを研修などでご案内すると、「ファイルサーバー検索ってオンプレミスだけなんですか、残念」といわれてきましたので、これは朗報といえると思います。

ただ、これで万々歳とはいきません。当然、Office 365 に一本化と思っていたところに再びオンプレミス環境が必要ということになりますし、基盤の準備が必要です。具体的には、この仕組みを使うには、サービス アプリケーション以外に次の条件を満たす必要があります。

  • SharePoint を含むOffice 365 サブスクリプション (アクティブ化されたユーザー)
  • Active Directory ユーザーとグループのディレクトリ同期
  • オンプレミスの Office Web Apps サーバーへの戻るためのリバースプロキシ (検索結果プレビューに必要)

ということで、弊社の「Microsoft SharePoint 2013 エンタープライズ検索の構成とカスタマイズ基礎」コースでは、アップデート情報なども適宜ご紹介していく予定です。

現在オンプレミス環境を使っている方は今後 Office 365 に移行するという選択肢もあると思いますし、Office 365 導入済みまたは導入予定の組織の方にとっても既存資産を生かすために有用だと思います。今現在は未提供のサービスですが、今後の導入を見据えての予備知識としてオンプレミスでのエンタープライズ検索の構成や仕組みを一通り学習しておくと安心です。ご受講も併せてご検討ください。