カテゴリ「SharePoint 2013」の117件の投稿 Feed

2015年6月23日 (火)

検証環境として利用しているオンプレミス環境の SharePoint Server 2013 で、いつの間にか Managed Metadata Services にアクセスできなくなる事象がありましたので、対処法を備忘録としてメモしておきます。

症状

サーバーの全体管理サイトから Managed Metadata Services の管理画面にアクセスすると下図のようにエラーとなり、何も操作できません。

2015-06-23 14-30-19

ULSログを見ると次のようなエラーが確認できます。

2015-06-23 14-42-59

 "Failed to get term store for proxy 'Managed Metadata Service'. Exception: System.Collections.Generic.KeyNotFoundException: 指定されたキーはディレクトリ内に存在しませんでした。     場所 Microsoft.SharePoint.Taxonomy.Internal.XmlDataReader.GetDateTime(String name)     場所 Microsoft.SharePoint.Taxonomy.Internal.SharedTermStore.Initialize(IDataReader dataReader, Guid termStoreIdValue, Boolean fromPersistedData)     場所 Microsoft.SharePoint.Taxonomy.Internal.SharedTermStore..ctor(IDataReader dataReader, Guid termStoreId, Boolean fromPersistedData)     場所 Microsoft.SharePoint.Taxonomy.Internal.DataAccessManager.
GetTermStoreData(MetadataWebServiceApplicationProxy sharedServiceProxy, Boolean& partitionCreated)"

対処方法

色々と調べたところ、似たような事象に多くの方が遭遇していることがわかりました。しかし、残念なことに、サービス アプリケーションをデータベースごと再作成するのが唯一の方法のようです。

  1. Managed Metadata Services の現在の設定を確認しておく。これには、[サーバー全体管理]>[サービス アプリケーションの管理]にアクセスし、Managed Metadata Services のプロパティや管理者情報をメモしておきます。また、Managed Metadata Services Proxy のプロパティもメモしておきます。
    2015-06-23 15-01-49
    2015-06-23 15-02-21

  2. Windows PowerShell を使ってManaged Metadata Service アプリケーションとプロキシの2つのみをバックアップします。サンプル スクリプトは次の通りです。
    
    Add-PSSnapin Microsoft.SharePoint.PowerShell
    
    #バックアップ対象のitem パスの確認
    Backup-SPFarm -ShowTree
    
    #サービスアプリケーションのバックアップ
    backup-spfarm -BackupMethod full -Directory \\sp2013-a\backups\ServiceApp -item “ファーム\共有サービス\共有サービス アプリケーション\Managed Metadata Service” -verbose
    
    #サービスアプリケーションProxyのバックアップ
    backup-spfarm -BackupMethod full -Directory \\sp2013-a\backups\ServiceAppProxy -item “ファーム\共有サービス\共有サービス プロキシ\Managed Metadata Service” -verbose
    

    2015-06-23 15-17-27

  3. バックアップが終わったら、バックアップログを確認し、エラーが出力されていないことを確認します。問題なければ、下記の通り、データベースごとサービスアプリケーションを削除します。
    2015-06-23 15-18-55

    2015-06-23 15-20-00
  4. Windows PowerShell を使ってバックアップから復元します。

    
    #復元
    Restore-SPFarm -Directory \\sp2013-a\backups\ServiceApp -RestoreMethod New  -Verbose
    Restore-SPFarm -Directory \\sp2013-a\backups\ServiceAppProxy -RestoreMethod New  -Verbose
    

    復元時には、サービス アプリケーション用のアカウントのパスワード入力が必要です。また、サービス アプリケーションに新しい名前を指定したり、サービス アプリケーションのDBの格納場所や、データベース名、サーバー名などを変更することも可能です(既定値から変更がなければそのまま Enter キーを押下します)。

  5. 復元したサービス アプリケーションを、目的のWebアプリケーションのプロキシグループに追加しておきます。
  6. 最後に、1で確認した設定通りに設定しなおします。

以上で作業は完了です。実作業を行う場合は、テスト環境で十分に手順を確認してから行うようにしてください。

[参考]

2015年6月11日 (木)
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/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 導入済みまたは導入予定の組織の方にとっても既存資産を生かすために有用だと思います。今現在は未提供のサービスですが、今後の導入を見据えての予備知識としてオンプレミスでのエンタープライズ検索の構成や仕組みを一通り学習しておくと安心です。ご受講も併せてご検討ください。