先週リリースされた新着情報をお知らせします。SharePoint と地図の統合については非常に興味深いですね。。
SharePoint 2013 (Technical Preview) MySite Upgrade and Profile PhotosSharePoint and Windows Azure Virtual MachinesIntegrating location and map functionality in SharePoint 2013Create a map view for the Geolocation field in SharePoint 2013Get Checkout Files List in Microsoft SharePoint Server 2010
MOSS 2007 や SharePoint 2010 では、サイトのユーザー情報におけるユーザーの表示名やメールアドレスなどの情報は、プロファイルをインポートすることにより AD と同期させることが可能です。
WSS 3.0 や SharePoint Foundation 2010 では基本的にはユーザーが手動でサイトのユーザー情報を更新して情報を同期する必要があります。
MOSS 2007 や SharePoint 2010 におけるプロファイルの同期の仕組みは次のとおりです。
1. プロファイルのインポート (同期) により AD から SharePoint のユーザープロファイルに情報が取り込まれる。
2. 既定では 1 時間に 1 回実行されているプロファイルの同期タイマージョブによりサ���トのユーザー情報に同期される。
この 2 段階のプロセスを経て、最終的にサイトのユーザー情報に情報が反映されます。
なお、上記 2 のプロファイルの同期ジョブでは、既定では「アクティブユーザー」に対してのみ同期処理が実行されます。
SharePoint ではユーザーが「アクティブ ユーザー」かどうか、コンテンツ データベースの UserInfo テーブルで管理しており、「アクティブユーザー」に対しては tp_IsActive フラグが 1 に設定されます。
ユーザーは以下のいずれかの条件を満たすことで、アクティブとみなされます。
・サイトの権限に直接ユーザー登録されている
・過去に何らかのアイテムの更新処理を行ったことがある
したがって、サイトに AD グループ経由で権限登録されており、かつ、「閲覧のみ」の権限しか持たずアイテムを更新したことが無いユーザーについては非アクティブと認識され、結果として AD の情報が更新されてもサイトのユーザー情報が更新されないという状況が発生します。
既定でアクティブユーザーに対してのみプロファイルの同期処理が実行される動作は、製品の想定された動作ですが、「stsadm –o sync –ignoreisactive 1」コマンドを実行することでこの動作を変更でき、非アクティブユーザーに対してもプロファイル同期が行われるよう、動作を変更することが可能です。このあたりの詳しい解説については以下の資料をご参照ください。
How to Update Inactive User Profile Information in SharePoint
http://blogs.msdn.com/b/rcormier/archive/2012/09/08/how-to-update-inactive-user-profile-information-in-sharepoint.aspx
ここまでの話は、比較的 MOSS の頃からメジャーな話なので、既にご存知の方もおられるかと思います。
有志の方々が PowerShell スクリプトなどで強制的に SPUser オブジェクトのプロパティを書き換える方法など紹介されておりますので、既にこのようなソリューションで対応されている方もおられるかと思います。
Update Inactive User Information Using PowerShell
http://gallery.technet.microsoft.com/scriptcenter/Update-Inactive-User-736dec27
MOSS running stsadm –o migrategroup command keeps the old group name and does not replace with the new name
http://blogs.msdn.com/b/joerg_sinemus/archive/2010/09/28/moss-running-stsadm-o-migrategroup-command-keeps-the-old-group-name-and-does-not-replace-with-the-new-name.aspx
SPS2010 running stsadm –o migrategroup command keeps the old group name and does not replace with the new name
http://blogs.msdn.com/b/joerg_sinemus/archive/2010/12/16/sps2010-running-stsadm-o-migrategroup-command-keeps-the-old-group-name-and-does-not-replace-with-the-new-name.aspx
で、ここからが本題です。
SharePoint 2010 および SharePoint Foundation 2010 以降に限られますが、実は、以下の PowerShell コマンドにより強制的にサイトのユーザー情報を AD の情報と同期させることが可能です。
Get-SPUser -Web <サイトの URL> -Identity <ユーザーログオン名> | Set-SPUser -SyncFromAD
例) Get-SPUser -Web http://sp2010 -Identity contoso\user1 | Set-SPUser -SyncFromAD
注意点として、このコマンドはプロファイルを更新するものでは無く、あくまでサイトのユーザー情報を更新するものなので、ユーザープロファイルは更新されません。また、サイト コレクション単位で実行する必要があります。
この方法を応用すれば、SharePoint Foundation においてもユーザー情報の同期が実装できるかもしれません、、、が、ユーザー数が多い環境では AD に対して負担をかけるかもしれませんので、実施にあたっては十分に検証していただくことをお勧めします。
Get-SPUser
http://technet.microsoft.com/ja-jp/library/ff607580.aspx
Set-SPUser
http://technet.microsoft.com/ja-jp/library/ff607827.aspx
SharePoint 2010 で何故か検索思ったようにヒットしない、MOSS 2007 の時と微妙に違う結果になる、、という現象に悩まされたときは、以下の KB で紹介されてる対処方法で改善されるかもしれません。
SharePoint 2010: People search does not return expected results in Japanese versionhttp://support.microsoft.com/kb/2723923SharePoint 2010 ではコンテンツの内容から自動的にインデックス処理時のワードブレーカーを選択する追加機能が実装されたのですが、コンテンツの内容によってはこれが期待どおりの動作をせず、日本語のコンテンツが誤って中国語などのワードブレーカーで処理されてしまうことがあります。この場合、ブラウザの言語設定が日本語の環境だとクエリのワードブレーク結果とインデックスのワードブレーク結果が一致せず、コンテンツがヒットしない現象が発生します。クロールコンポーネントのレジストリ変更後、インデックスのフルクロールが必要となるので大規模な環境で気軽に試せない場合、検証環境があれば、その環境に同じコンテンツを移行して対応策が有効なものか、動作確認することが可能です。
特定の条件において、MOSS 2007 SP3 適用時に構成ウィザードの実行に非常に長い時間を要するとともに、検索データベースのトランザクションログが肥大化する症状が報告されています。
[背景]
MOSS 2007 では大量のコンテンツをクロールする際に、クロールキューに溜まったデータを一括ですべて処理できないため、バッチ処理としてある程度のまとまりごとに処理を行います。この時、内部でバッチ ID を割り振って検索データベースの MSSBatchHistory テーブルにデータを格納して管理するのですが、既知の制限として、MSSBatchHistory テーブルの情報がリセットされず、BatchID が int 型の制限を超えてしまいクロールに失敗するという問題がありました。このため、2011 年 4 月の CU でこの問題が修正されています。
この修正では以下の修正が施されています。
・MSSBatchHistory テーブルの BatchID カラムのデータ型を Int 型から BigInt 型に変更します。
・クロール毎に MSSBatchHistory テーブルをリセットするようになりました。
[問題点]
この修正の影響により、SP3 を含む、2011 年 4 月の CU 以降の修正を適用した場合、構成ウィザード実行時に BatchID カラムのデータ型が Int 型から BigInt 型に変更されるため、MSSBatchHistory テーブルが肥大化している環境では構成ウィザードの実行に非常に長い時間を要するとともに、検索データベースのトランザクションログが肥大化する問題に遭遇する可能性があります。
[対応策]
以下の SharePoint Escalation Services チームのブログにこの問題に対する対応策が紹介されています。
SharePoint 2007: SSP upgrade issue with SP3
http://blogs.msdn.com/b/spses/archive/2012/10/01/sharepoint-2007-ssp-upgrade-issue-with-sp3.aspx
基本的には、可能な限り時間を短縮するための対応策を施すとともに、実施にあたって十分な時間的余裕と、ディスクの空き容量を確保いただくことをお奨めしています。
(概要)
1. 予め MSSBatchHistory テーブルの大きさを確認する
2. upgrade ログのチェックポイントを確認する
3. MSSBatchHistory テーブルのサイズによっては十分なメンテナンスプランの時間を設ける
4. SSP 検索 DB の SQL 復旧モードを「シンプル」に変更する
5. SSP 検索データベース用のトランザクションログの配置先ディスクに十分な空き容量を確保しておく
6. SQL Server の設定で MAXDOP =1 に設定しておく
SharePoint の長期運用において、SP 適用は避けて通れませんので、是非とも頭の片隅に置いておいていただけると幸いです。。
SharePoint 2013 テクニカルプレビューの新しいコンテンツが公開されました。
Windows PowerShell for SharePoint 2013 IT pros SharePoint Server 2013 および SharePoint Foundation 2013 の Windows PowerShell コマンドを紹介しています。 What's new for mobile devices in SharePoint 2013SharePoint Server 2013 のモバイル プラットフォームに最適化された新しいユーザーエクスペリエンスを紹介しています。What's new in search in SharePoint Server 2013SharePoint Server 2013 の新しい検索機能について解説していますMicroblog features, feeds, and the Distributed Cache service overview in SharePoint Server 2013SharePoint Server 2013 Preview のマイクロブログ、ニュースフィード、および分散キャッシュ サービスについて解説していますManage the Distributed Cache service in SharePoint Server 2013SharePoint 2013 Preview の分散キャッシュ サービスを構成して管理する方法について解説していますTest Lab Guide: Demonstrate forms-based claims authentication for SharePoint Server 2013SharePoint Server 2013 Preview を Microsoft SQL Server 2012 とともに複数のサーバーに構成する方法について解説しています。このテストラボでは以下の内容について解説します。 - SharePoint Server 2013 を 3 層ファーム用の複数サーバーに展開します。 - フォームベース認証を構成します。 - フォームベース認証をデモンストレーションします。