Japan SharePoint Support Team Blog

2013 年 4 月の CU がリリースされました

2013-04-29T15:11:00Z

2013 年 4 月の CU がリリースされましたのでお知らせします。

以下のリンクよりダウンロードできます。

SPS2013 の 4 月 CU 適用時に一部の環境で構成ウィザード実行中にエラーが発生する問題が確認されています。エラーが発生した場合再度構成ウィザードを実行することで問題を回避できます。この問題は 6 月の CU で修正される予定ですので、特にお急ぎでなければ、6 月の CU をお待ちいただくことをお勧めします。

注意点

SharePoint Server 2013 の CU 適用前には 2013 年 3 月の更新プログラムをインストールする必要があります。
SharePoint Server 2010、SharePoint Foundation 2010 の CU 適用前には SP1 をインストールする必要があります。
MOSS 2007、WSS 3.0 の CU 適用前には SP3 をインストールする必要があります。
SharePoint Server 2013 の CU には SharePoint Foundation 2013 の CU が含まれます。SharePoint Server 2013 with Project Server の CU には SharePoint Server 2013、SharePoint Foundation 2013 の CU が含まれます。いずれか 1 つの製品ファミリに対応した CU を適用すれば問題ありません。
SharePoint Server 2010 の CU には SharePoint Foundation 2010 の CU が含まれます。SharePoint Server 2010 with Project Server の CU には SharePoint Server 2010、SharePoint Foundation 2010 の CU が含まれます。いずれか 1 つの製品ファミリに対応した CU を適用すれば問題ありません。
インストールの完了後 SharePoint 製品構成ウィザードを実行する必要があります。

関連 KB

KB 2799869 - WSS 3.0
KB 2799867 - MOSS 2007
KB 2794728 - SharePoint Foundation 2010
KB 2775353 - SharePoint Server 2010
KB 2775426 - Project Server 2010
KB 2751999 - SharePoint Foundation 2013
KB 2726992 - SharePoint Server 2013
KB 2775426 - Project Server 2013
KB 2799821 - Office Web Apps Server 2013

入手先

Download WSS 3.0 2013-04 CU
Download MOSS 2007 2013-04 CU
Download SharePoint Foundation 2010 2013-04 CU
Download SharePoint Server 2010 2013-04 CU
Download SharePoint Server 2010 with Project Server 2013-04 CU
Download SharePoint Foundation 2013 2013-04 CU
Download SharePoint Server 2013 2013-04 CU
Download Project Server 2013 2013-04 CU
Download Office Web Apps Server 2013 2013-04 CU

関連情報

SPS2013 の CU はファイルを展開すると以下のように .exe ファイルと .cab ファイルが展開されますので、それぞれ同じ場所にコピーして .exe ファイルからインストールを実行してください。

関連サイト

【重要】2013 年 3 月の必須更新プログラムについて (対象：SharePoint 2013)

2013-04-29T14:48:00Z

※重要※SharePoint 2013 4 月以降の CU を適用する前に、必ず以下のパブリック更新プログラム (PU) を適用してください。

注意点

SharePoint Server 2013 の PU には SharePoint Foundation 2013 の PU が含まれます。SharePoint Server 2013 with Project Server の PU には SharePoint Server 2013、SharePoint Foundation 2013 の PU が含まれます。いずれか 1 つの製品ファミリに対応した CU を適用すれば問題ありません。
インストールの完了後 SharePoint 製品構成ウィザードを実行する必要があります。

関連 KB

KB 2768000 - SharePoint Foundation 2013
KB 2767999 - SharePoint Server 2013
KB 2768001 - Project Server 2013

入手先

関連情報

上記の更新プログラムには、通常リリースされるサービスパックと同様に今後リリースされる累積的な更新プログラム (CU) のベースラインとなるパッケージ構成のアップデートが含まれています。
本修正プログラムを適用せずに 2013 年 4 月以降の CU を適用しようとすると以下のように正しいバージョンの製品が見つからないことを示すエラーが表示されます。

関連サイト

SharePoint 2013 検索のためのサーバーオブジェクトモデルについて

2013-04-23T10:00:00Z

こんにちは SharePoint サポートの森　健吾 (kenmori) です。今回の投稿では、SharePoint 2010 からのアップグレードシナリオにおいて、SharePoint 2013 でサーバーオブジェクトモデル (以下 SSOM) を使用して検索する方法をご紹介します。

まず、今回の投稿は、アップグレードシナリオを想定している開発者の方には、問題となる可能性がありますため早めに情報を提供する動きに至りました。

開発者に適切に情報を伝える目的を優先しますので、本投稿の難易度としては SharePoint における検索設定の基礎知識、および検索オブジェクトモデルを使用したソリューションを一通り使用した簡単なシステムを開発できるレベル (初級から中級程度) の開発者を想定した内容となります。

そのため、この内容を最低限理解するために必要とする、検索アーキテクチャ等の基礎知識や、キーワード検索、プロパティ検索、検索範囲、検索インデックス、管理プロパティ等の説明は、このページに書ききれなくなることが想定されますため割愛します。リファレンスは記載しますので、必要な場合はご参照いただくことでご了承ください。

タイトル : エンタープライズ検索の管理 (SharePoint Server 2010)
アドレス : http://technet.microsoft.com/ja-jp/library/ee792877(v=office.14).aspx

タイトル :SharePoint Server 2013 で検索を計画する
アドレス : http://technet.microsoft.com/ja-jp/library/cc263400.aspx

SharePoint 2010 の検索 SSOM について

SharePoint 2010 の検索 SSOM には、以下の 2 つのクラスを使用していました。それぞれ、異なる構文で検索を実行することが特徴です。

・FullTextSqlQuery　・・・ SQL 構文を使用して検索条件を指定
　　SELECT Title, CONTENTCLASS, SITE, Path FROM SCOPE() Where "scope"='All Sites' AND CONTAINS('"test*"') ORDER BY "Title" DESC

・KeywordQuery　　・・・　キーワードクエリ構文を使用して検索条件を指定
　　test author:Shakesp* IsDocument:1

タイトル : 検索クエリを作成する
アドレス : http://msdn.microsoft.com/ja-jp/library/ee556426(v=office.14).aspx

SQL 構文とキーワードクエリ構文の違いについては、本コンテンツでもご紹介いたしますが、あらかじめ上記サイトからもご確認ください。

SharePoint 2013 の検索 SSOM について

SharePoint 2013 では、Fast for SharePoint 2010 を踏襲した大規模な検索アーキテクチャの変更が実施されました。その結果、下位互換性を保てなくなった機能が一部削除されています。

その一つに検索 SSOM として存在していた FullTextSqlQuery クラスが存在します。FullTextSqlQuery クラスを使用した検索ソリューションを SharePoint 2013 上に展開した場合、以下のような例外がスローされます。

System.NotSupportedException: 指定されたメソッドはサポートされていません。
場所 Microsoft.Office.Server.Search.Query.FullTextSqlQuery.PreQueryExecute()
場所 Microsoft.Office.Server.Search.Query.Query.ExecuteQuery()
場所 Microsoft.Office.Server.Search.Query.SearchExecutor.ExecuteQueryInternal(Query
query)
場所 Microsoft.Office.Server.Search.Query.SearchExecutor.ExecuteQuery(Query query)

これは、SharePoint Foundation 検索ライブラリ (Microsoft.SharePoint.Search.Query) を使用しても同様です。つまり、SharePoint 2013 では FullTextSqlQuery の定義は存在するものの、NotSupportedException が生成されるのみの実装です。つまり、今バージョンより KeywordQuery クラスを使用した実装に移行する必要があります。

なお、FullTextSqlQuery クラスの定義は以後のバージョンで削除される予定です。

FullTextSqlQuery クラスから KeywordQuery クラスを使用する際の移行について

SharePoint 2013 で引き続き検索 SSOM を使用する場合は、KeywordQuery クラスを使用したソリューションへの移行を検討する必要があることをご説明させていただきました。今回の投稿は、そのポイントとなる箇所をメインにご説明いたします。

概要

1. 表示列として管理プロパティを指定する方法について
2. 検索範囲 (検索先) の指定について
3. フルテキスト・非フルテキスト述語の指定について
4. 管理プロパティを使用した並べ替えについて

まず、上記 4 つの項目でご説明するにあたり、サンプルコードを以下に記載し、FullTextSqlQuery クラスと KeywordQuery クラスの検索処理を実装するためのコードを比較します。

SharePoint 2010 の FullTextSqlQuery サンプル

移行シナリオを想定してまず SharePoint 2010 における FullTextSqlQuery を使用したコードの例を以下に記載します。

----
SearchServiceApplicationProxy proxy =　(SearchServiceApplicationProxy)SearchServiceApplicationProxy.GetProxy(SPServiceContext.GetContext(site));
FullTextSqlQuery ftsq = new FullTextSqlQuery(proxy);
ftsq.ResultsProvider = SearchProvider.Default;
ftsq.ResultTypes = ResultType.RelevantResults;
ftsq.QueryText = "SELECT Title, CONTENTCLASS, SITE, Path FROM SCOPE() Where "scope"='All Sites' AND CONTAINS('"test*"') ORDER BY "Title" DESC";
ResultTableCollection resultTables = ftsq.Execute();
ResultTable relevantResults = resultTables[ResultType.RelevantResults];
DataTable resultDataTable = new DataTable();
resultDataTable.Load(relevantResults, LoadOption.OverwriteChanges);
dataGridView1.DataSource = resultDataTable;
----

QueryText プロパティに指定する検索文字列には SQL 構文を指定します。

タイトル : SharePoint 検索の SQL 構文のリファレンス
アドレス : http://msdn.microsoft.com/ja-jp/library/ee558869(v=office.14).aspx

上記のサイトに記載されている通り、様々なステートメントをサポートしていますので、柔軟な検索が実施できている状況となります。

・SELECT ・・・　表示列を簡単に選択できます。
・FROM　　・・・　SharePoint 2007 以降は SCOPE() のみです。
・WHERE　・・・　検索範囲、検索キーワード、プロパティ検索で使用します。
・ORDER BY・・・　主に管理プロパティを使用した並べ替えを行います。

また、特に WHERE 句が実現できる範囲については、より詳細に確認が必要となります。

タイトル : SharePoint 検索の SQL 構文の WHERE 句
アドレス : http://msdn.microsoft.com/ja-jp/library/ms544086(v=office.14).aspx

なお、検索において実際に絞り込みを行う際に、重要とされる WHERE 句についてです。上述の通り検索範囲、自由形式のクエリ、プロパティ検索で使用しますが、以下のようにさらに細かく処理が分類できます。

フルテキスト述語　　・・・　CONTAINS 述語(* 接頭辞一致)、FREETEXT 述語
非フルテキスト述語　・・・　LIKE, =, <, >, <=, >=, <> など

(補足)
フルテキスト述語は検索インデックスを使用して高速な検索を実行できます。非フルテキスト述語は、メタデータストアに対して T-SQL を実行することで値を絞り込む処理です。
キーワードクエリ構文の検索では構文が全く異なることから、これらの設定を引き続き使用するための代替案を確認する必要があると認識しています。

SharePoint 2013 の KeywordQuery サンプル

次に SharePoint 2013 における KeywordQuery を使用したコードの例を以下に記載します。

---
SearchServiceApplicationProxy ssap = (SearchServiceApplicationProxy)SearchServiceApplicationProxy.GetProxy(SPServiceContext.GetContext(mySite));
Microsoft.Office.Server.Search.Query.KeywordQuery myQuery = new Microsoft.Office.Server.Search.Query.KeywordQuery(ssap);
myQuery.QueryInfo.AdvancedSearch = true;
myQuery.QueryText = "？？？"; // 後述にていくつか例を記載します。
myQuery.SelectProperties.Add("Title");
myQuery.SelectProperties.Add("Path");
myQuery.SelectProperties.Add("ContentTypeId");
myQuery.SortList.Add("Rank", SortDirection.Descending);
SearchExecutor mySearchEx = new SearchExecutor();
ResultTableCollection myResultCol = mySearchEx.ExecuteQuery(myQuery);
ResultTable myResultTable = myResultCol.Filter("TableType", KnownTableTypes.RelevantResults).Single(relevantTable => relevantTable.QueryRuleId == Guid.Empty);
DataTable myDataTable = new DataTable();
myDataTable.Load(myResultTable, LoadOption.OverwriteChanges);
dataGridView1.DataSource = myDataTable;
---

では、実際にサンプルコードを眺めながら、ソリューションのアップグレード方法について検討していきましょう。

1. 表示列として管理プロパティを指定する方法について

SQL 構文において、SELECT ステートメントに含めていた表示列の指定については、KeywordQuery.SelectProperties に管理プロパティの名前を指定して表示列を追加することで対処が可能です。

--抜粋--
myQuery.SelectProperties.Add("Title");
myQuery.SelectProperties.Add("Path");
myQuery.SelectProperties.Add("ContentTypeId");
--抜粋--

タイトル : KeywordQuery.SelectProperties property
アドレス : http://msdn.microsoft.com/en-us/library/microsoft.office.server.search.query.keywordquery.selectproperties(v=office.15).aspx

ただし、管理プロパティが検索結果として "取得可能" であるかどうかについては、管理プロパティの設定を確認しておく必要があります。
この点につきましては、以下の Technet をご参考にしてください。

タイトル : SharePoint Server 2013 の検索スキーマの概要
アドレス : http://technet.microsoft.com/ja-jp/library/jj219669(office.15).aspx#MP_Overview
参考箇所 : 管理プロパティの設定の概要

2. 検索範囲 (検索先) の指定について

SQL 構文で Where 句で指定していた検索範囲の指定については、QueryText プロパティで scope プロパティの絞り込みを実施することで指定が可能です。

--抜粋--
myQuery.QueryText = "scope:\"All Sites\"";
--抜粋--

補足

SharePoint 2013 からは、検索範囲は下位互換のために残されており、新しいバージョンからは検索先を使用することなります。
検索先を指定する方法は KeywordQuery.SourceId プロパティに GUID 型で値を指定し、絞り込む必要があります。

-- 例 --
SourceRecord source = searchProxy.GetResultSourceByName("カスタム検索先", new SearchObjectOwner(SearchObjectLevel.SPSite, mySite.RootWeb));
myQuery.SourceId = source.Id;
----

タイトル : 検索の新機能 (SharePoint Server 2013)
アドレス : http://technet.microsoft.com/ja-jp/library/ee667266.aspx#itpro_WhatsNewEntSrch_RelevanceNew
参考箇所 : 検索先

3. フルテキスト・非フルテキスト述語の指定について

SQL 構文で Where 句で指定していたフルテキストおよび非フルテキスト述語の指定については、一部の条件を除き移行が可能です。
キーワードクエリ構文は、KQL (Keyword Query Language) と呼ばれるようになりました。

本項目については、以下のリファレンスを参照しながら説明していきます。

タイトル : キーワードクエリ構文のリファレンス
アドレス : http://msdn.microsoft.com/ja-jp/library/ee558911.aspx

なお、後記にて記載する KQL は、QueryText プロパティに指定したものとご認識ください。ソースコードの部分は割愛します。

自由形式のクエリ

QueryText プロパティにスペース区切りで自由形式に文字列を指定した場合は、フルテキストインデックスに格納された用語との完全一致に基づいて、結果が返されます。

federated search

ワイルドカード演算子 (*) を使用して先頭一致を有効にすることにより、CONTAINS 述語で実現できていた接頭辞一致も引き続き可能です。

search fed*

(補足)
接尾辞一致のフルテキスト検索ははじめから存在していません。

プロパティ制限検索

プロパティ検索については、以下の構文で実現が可能です。

<プロパティ名><演算子><プロパティ値>

特によく使用される演算子は : (コロン) であり、以下のような検索キーワードをよく見かけると思います。

author:Shakesp*

これらは、KQL においてプロパティを制限する構文であり、上記の例は Author プロパティが Shakesp で始まる値をフルテキストインデックスに格納されているプロパティから検索する動作です。

なお、演算子を変更することで、非フルテキスト検索も実行可能です。しかし、注意点があります。上述のサイトに記載されている通り、プロパティ制限の有効なプロパティ演算子は以下の通りです。

:, =, <, >, <=, >=, <>, ..

上記でお気づきかもしれませんが、KQL では非フルテキスト述語であるLIKE 演算子に置き換わる手法は存在していません。
KeywordQuery に置き換える際には、この部分が制限事項となりますことをご理解、ご了承ください。

KQL の演算子 (AND NOT OR)

SQL 構文において、検索条件の組み合わせを色々と指定できましたが、これらは KQL においても条件の組み合わせを細かく指定が可能です。

author:"John Smith" AND filetype:docx

4. 管理プロパティを使用した並べ替えについて

SQL 構文で Order By 句で指定していた並べ替えについては、KeywodQuery.SortList プロパティに管理プロパティを指定することで代替処理が実装可能となります。

--
myQuery.SortList.Add("Title", SortDirection.Descending);
--

タイトル : KeywordQuery.SortList property
アドレス : http://msdn.microsoft.com/en-us/library/microsoft.office.server.search.query.keywordquery.sortlist.aspx

ただし、管理プロパティが検索結果として "並べ替え可能" であるかどうかについては、管理プロパティの設定を確認しておく必要があります。
この点につきましては、上述の Technet ページである "SharePoint Server 2013 の検索スキーマの概要" をご確認ください。

次回予告

SQL 構文が使用できなくなり、取り急ぎキーワード構文に移行する方法については本投稿でご紹介しました。
ここで、Fast Query Language (FQL) はどうなのか？FQL だと制限になっている機能を実現できるのでは？と思われる方もいらっしゃると思います。FQL の使用につきましては、次回ご紹介させていただければと思います。

今回の投稿は以上になります。

webanalyzer が正常に起動しない問題

2013-04-19T04:07:00Z

こんにちは SharePoint サポートの副島智範 (tomonos) です。

今回は SharePoint 2010 の検索エンジンとして使われる fast for SharePoint についての情報を共有します。

FAST Search Server 2010 for SharePoint において、webanalyzer が複数構成された環境から、任意の webanalyzer を削除して、構成変更を実施した後に、webanalyzer が正常に起動しないという症状が報告されています。

webanalyzer は "nctrl status" コマンドでステータスを確認すると、"Running" となっているため、正常に動作しているように見えてしまいます。しかし初期化の処理に失敗しているため、稼働できておりません。

[問題点]

構成変更前の設定ファイルが残っていることで、すでに webanalyzer が削除済みとなったサーバーと通信を行います。しかし webanalyzer はすでにそのサーバーには存在しないため、通信に失敗してしまいます。

症状が出ている時は、以下のようなログが出力されます。 (出力先 : %FASTSEARCH%\var\log\webanalyzer\webanalyzer.log)

ログの抜粋

[2013-04-09 09:20:00.163] VERBOSE systemmsg Couldn't connect to walsr: contoso.com:13290

[2013-04-09 09:25:00.977] VERBOSE systemmsg Couldn't connect to walsr: contoso.com:13290

[2013-04-09 09:57:21.503] VERBOSE systemmsg Setting up XML-RPC

[2013-04-09 09:57:21.706] VERBOSE systemmsg Connecting to ConfigServer at contoso.com:13250..

[2013-04-09 09:57:21.847] INFO systemmsg 'Middleware
configuration:' \\ {'authidentity': '', \\ 'authpassword': '', \\ 'authproxypassword':
'', \\ 'authproxyusername': '', \\ 'authusedefault': False,
\\ 'clienttimeout': 0, \\ 'configfile': '', \\ 'debug': 0,
\\ 'host': 'contoso.com', \\ 'maxmsgsize': 1000000, \\
'maxserverthreads': 512, \\ 'minserverthreads': 1, \\ 'nameserver':
['contoso.com:13390',
\\
'contoso.com:13390'], \\ 'port': 13390, \\ 'proxybypass': '',
\\ 'servertimeout': 0, \\ 'sslcert': '', \\ 'staticmapping':
['nameservice::nameserver:0'], \\ 'useautoproxy': False, \\
'usessl': 0} \\

[2013-04-09 09:57:21.862] VERBOSE systemmsg Missing nctrls on these hosts: contoso.com

[2013-04-09 09:57:31.877] VERBOSE systemmsg Missing walsrs on these hosts: contoso.com

[2013-04-09 10:03:37.064] WARNING systemmsg Couldn't connect to the ConfigServer. Message was timed out

[2013-04-09 10:04:46.241] WARNING systemmsg Connection restored

[2013-04-09 10:07:13.261] VERBOSE systemmsg Setting up XML-RPC

[2013-04-09 10:07:13.277] VERBOSE systemmsg Connecting to ConfigServer at contoso.com:13250..

[2013-04-09 10:07:13.620] INFO systemmsg 'Middleware
configuration:' \\ {'authidentity': '', \\ 'authpassword': '', \\
'authproxypassword': '', \\ 'authproxyusername': '', \\
'authusedefault': False, \\ 'clienttimeout': 0, \\ 'configfile':
'', \\ 'debug': 0, \\ 'host': 'contoso.com', \\ 'maxmsgsize':
1000000, \\ 'maxserverthreads': 512, \\ 'minserverthreads': 1,
\\ 'nameserver': ['contoso.com:13390',
\\
'contoso.com:13390'], \\ 'port': 13390, \\ 'proxybypass': '',
\\ 'servertimeout': 0, \\ 'sslcert': '', \\ 'staticmapping':
['nameservice::nameserver:0'], \\ 'useautoproxy': False, \\
'usessl': 0} \\

[対応策]

設定ファイルのキャッシュを削除することで、回避出来ます。

1. webanalyzer を停止します。

nctrl stop webanalyzer

2. %FASTSEARCH%\data\webanalyzer\config\ から *.xml.swp のファイルを削除します。

3. webanalyzer を開始します。

nctrl start webanalyzer

4. webanalyzer が存在するサーバー全てに対して、1 から 3 の作業を繰り返します。

SharePoint Server 2013 の個人用サイトを管理者が作成する方法

2013-03-13T17:35:00Z

こんにちは。
SharePoint サポートチームの成田です。

SharePoint Server 2013 ではソーシャル機能が大幅に強化されていますが、本ブログではソーシャル機能を利用する上で前提となる個人用サイトの作成について触れたいと思います。
個人用サイトが作成されるタイミングは、ユーザーがサイトページ上の [ニュースフィード] やユーザー名のドロップダウンの [プロファイル] をクリックした場合など、初めて個人用サイトのホストサイトコレクションにアクセスしたときです。

個人用サイトの作成がリクエストされると、毎分実行されるタイマージョブ [個人用サイトインスタンス化のインタラクティブな要求のキュー] によってリクエストされたユーザーの個人用サイトが作成され始めます。
この時、ユーザーは個人用サイトの作成が完了するまで下記のような画面が表示されます。

数分待ち、個人用サイトの作成が完了すると、下記のようにニュースフィードなどの機能が使用可能になります。

個人用サイトは、上記のように、ユーザーが個人用サイトのホストサイトコレクションに最初にアクセスしたタイミングで作成されることが基本となりますが、本ブログでは管理者があらかじめ個人用サイトを作成する方法を紹介します。あらかじめ個人用サイトを作成しておくことで、ユーザーが初めて個人用サイトのホストサイトコレクションにアクセスした瞬間からニュースフィードなどの機能を利用できるようになります。

管理者が個人用サイトを作成する方法
============================
管理者が個人用サイトを作成するには以下のメソッドを利用します。

UserProfile.CreatePersonalSite メソッド (Microsoft.Office.Server.UserProfiles)
http://msdn.microsoft.com/ja-jp/library/microsoft.office.server.userprofiles.userprofile.createpersonalsite.aspx

上記のメソッドを、Visual Studio や PowerShell から実行できます。
※個人用サイトを作成する前に、ユーザーのプロファイルが事前に作成されている必要がありますので、手動でプロファイルを追加するか、プロファイル同期によってあらかじめプロファイルが存在することを確認してください。
※以下に紹介するコードやスクリプトはサンプルですので、実行環境に合わせて作成し、実行前に十分検証してください。

1. Visual Studio を使用してプログラムを記述する場合は、以下のようなコードを記述します。
-----
SPSite site = new SPSite(http://sharepoint/mysitehost);
SPServiceContext serviceContext = SPServiceContext.GetContext(site);
UserProfileManager profileManager = new UserProfileManager(serviceContext);
UserProfile profile = profileManager.GetUserProfile("domain\\username");
profile.CreatePersonalSite();
-----
※http://sharepoint/mysitehost は個人用サイトのホストサイトコレクションを指定します
※domain\\username は個人用サイトを作成するユーザー名を指定します

2. PowerShell から UserProfile.CreatePersonalSite メソッドを利用するには以下の手順を実施します。

1) 任意の SharePoint サーバーに管理者アカウントでログオンします。
2) [スタート] メニューから [SharePoint 2013 管理シェル] を管理者モードで起動します。
3) 以下のようにコマンドを実行します。
-----
$mysite = Get-SPSite http://sharepoint/mysitehost
$user = "domain\username"
$context = [Microsoft.Office.Server.ServerContext]::GetContext($mysite)
$upm = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$prof = $upm.GetUserProfile($user)
$prof.CreatePersonalSite()
-----
※http://sharepoint/mysitehost は個人用サイトのホストサイトコレクションを指定します
※domain\username は個人用サイトを作成するユーザー名を指定します

上記の例では個人用サイトを 1 ユーザーずつ作成していますが、必要に応じてユーザープロファイルを列挙して複数のプロファイルを作成することも可能です。
例えば以下のブログでは複数の個人用サイトを一気に作成する方法が紹介されています。
http://msftplayground.com/2010/09/provisioning-my-sites-sharepoint-2010/

全プロファイルの個人用サイトを作成するということは、プロファイル数分のサイトコレクションを作成するということになるので、作成時には WFE や DB サーバーにある程度の負荷をかけることにご注意ください。(実際の負荷についてはいくつかの個人用サイトを作成してご確認ください)
大量のプロファイルが存在する場合には複数回に分けて計画的に作成する工夫も必要になるかもしれません。

いかがでしたでしょうか。
ソーシャル機能が大幅に向上した SharePoint 2013 をぜひお試しください！

SharePoint の Web パーツページが表示できない場合のトラブルシューティング

2013-03-12T13:32:00Z

こんにちは SharePoint サポートの森　健吾 (kenmori) です。

今回の投稿では、すでに Web キャスト等でも公開しております Web パーツを含むページが予期せぬエラー等で表示できなくなった際のトラブルシューティング方法について SharePoint 2013 をベースとしてご説明します。

この投稿には SharePoint 2013 での最新情報は少ないものの、バージョンを問わずトラブルシューティングの基礎となりますため、情報を更新する目的で投稿します。

SharePoint では、製品に用意された様々な Web パーツや、それらをカスタマイズした Web パーツ、または Visual Studio によってカスタマイズしたオリジナルの Web パーツを追加して独自のページを作成することができます。
しかし、様々なページを実現できるがゆえに、エラーが発生した場合は、どう対処すべきかわからないという状況が想定されます。

この投稿では、Web パーツページが表示できなくなった場合のトラブルシューティングについて説明していきます。
また、この投稿で使用している画面ショットは、SharePoint 2013 のものを使用していますが、それ以前のバージョンにおいても有効な方法をご紹介します。

エラー画面

SharePoint では、Web パーツを含むページの表示処理などにおいてエラーが発生し、例外がハンドルされない場合、このように "申し訳ございません。何らかの問題が発生しました。" などのエラー画面が表示されます。

このような問題が発生した場合は、次のような手順を行ってください。

トラブル シューティング手順

Web パーツページが表示できない場合のトラブルシューティングを実施するにあたって、最も簡単な方法は Web パーツの管理の画面を使用します。
最初にこの問題がそのページ特有の現象かどうかを確認するために、URL を直接指定して影響範囲を確認します。
影響範囲がページ固有である場合は、以下にその手順についてトラブルシューティングの流れをご説明いたします。

手順概要

Web パーツの管理のページにアクセスします。
管理画面から 1 つ 1 つ Web パーツを閉じ、元のページにアクセスします。
手順 2. を正常に表示されるまで繰り返します。
現象が回避できた時点で、最後に閉じた Web パーツが問題の Web パーツとして断定できます。
この問題となる Web パーツを閉じたまま、その他の Web パーツを元に戻していきます。

さらに、現象発生の原因を追究する場合は、現象発生時のバックアップデータなどをテスト環境に復元し、テスト環境にて継続して調査を実施することをお勧めします。

手順詳細

1. Web パーツの管理のページにアクセスします。

エラー発生画面に [Web パーツの管理のページ] といったリンクが表示されている場合は、このリンクをクリックすることで、Web パーツページの管理画面に遷移し、トラブルシューティングを行うことが可能です。

しかしながら、エラーの種類や深刻さなどによっては、このエラー画面が表示されないことも考えられます。その場合は、ブラウザのアドレスバーにて URL の末尾に ?contents=1 を入力して該当するページの Web パーツページの管理画面に遷移することができます。

また ?contents=1 を追加する方法は、SharePoint Server 2010, 2007 等の以前のバージョンの SharePoint においても使用できます。

2. 管理画面から 1 つ 1 つ Web パーツを閉じ、元のページにアクセスします。

3. 手順 2. を正常に表示されるまで繰り返します。

4. 現象が回避できた時点で、最後に閉じた Web パーツが問題の Web パーツとして断定できます。

Web パーツページの管理画面に遷移したら、Web パーツにチェックを入れ [閉じる] をクリックして、Web パーツを閉じていきます。

問題の Web パーツを特定するため、1 つ閉じるごとにページが正常に表示されるかを確認していきます。
正常に表示できた時点で、最後に閉じた Web パーツが問題を引き起こしていることが確認できます。

5. この問題となる Web パーツを閉じたまま、その他の Web パーツを元に戻していきます。

問題の Web パーツが特定できた後は、その特定の Web パーツを除く全ての Web パーツをあらためて追加します。

Web パーツページの管理画面にて、[閉じる] をクリックして閉じられた Web パーツは、Web パーツを追加する際のカテゴリにて "閉じられた Web パーツ" というカテゴリの中に全て登録されています。

この Web パーツを選択し、[追加] ボタンをクリックすることで、閉じるまでの設定情報を引き継いた Web パーツを再度ページに復元することができます。
この手順を、問題の Web パーツ以外にて適用し、閲覧できないコンテンツの影響を最小限にとどめます。

原因追求

原因追求については、ダウンタイムを最小限にするためだけでなく、根本原因について十分に調査を実施するためにも、テスト環境で実施することをお勧めします。

Web.config の編集

調査方法の 1 つとしては、web.config を以下のように設定し、スタックを含めたより詳細なエラー内容を画面上に表示させることが効果的です。
Internet Information Services (IIS) 管理ツールにて、Web サイトを右クリックしてエクスプローラ表示します。

該当フォルダ内の web.config を開き、以下の 3 つの設定を変更します。

1) SafeMode 要素
要素 : configuration/SharePoint/SafeMode
属性 : CallStack
値 : true

2) CustomErrors 要素
要素 : configuration/system.web/customErrors
属性 : mode
値 : Off または RemoteOnly (サーバー端末のみ Off / リモートは On)

3) Compilation 要素
要素 : configuration/system.web/compilation
属性 : debug
値 : true

上記の設定後には、予期せぬエラー画面が、以下のようなエラーの詳細表示画面に切り替わります。

Visual Studio を使用したデバッグ

現象発生した Web パーツのソースコードをお持ちの場合は、Visual Studio を使用して Web パーツを表示している IIS のワーカープロセスにアタッチ ([デバッグ] – [プロセスにアタッチ]) し、デバッグを行うことで原因追求が可能です。

なお、このような状況に備えるため、SharePoint アプリケーション開発者は、カスタムソリューションをリリースするにあたり、納品したバージョンに相当するソースファイルと、コンパイル時に生成されたシンボルファイル (*.pdb) を必ずご管理いただくことを推奨します。

診断ログ

多くの場合、ハンドルされていない例外は、診断ログに記録されますので、現象発生時の状況を確認する上で診断ログは非常に重要となります。

最初の注意事項として、このファイルは保存期間が決められていますので、削除される前に現象発生時のものを即座に控えておく必要があります。
SharePoint 2013 の Web フロントエンドサーバーにおいて、インストールフォルダ下の LOGS フォルダ (既定では "C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\LOGS") にあるすべてのログファイルをコピーしてください。

補足 : お客様にて診断ログの保存先を変更されている場合には、変更後の保存先を参照してください。診断ログの保存先フォルダは、サーバーの全体管理サイトより [監視] – [診断ログの構成] にアクセスしていただき、[トレースログ] セクションの [パス] よりトレースログのパスを参照することで確認することができます。

今回の例では、以下のようなログが確認できます。

03/09/2013 17:02:21.37 w3wp.exe (0x1A78) 0x1BAC SharePoint Foundation General 8nca Medium Application error when access /SitePages/Home.aspx, Error=エラー at UnhandledExceptionWebPart.UnhandledExceptionWebPart.UnhandledExceptionWebPart.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 7e05069c-8134-708a-27e3-156c2f362b2e

開発者ダッシュボードについて

SharePoint 2010 以降では、トラブルを防止するための機能として、開発者ダッシュボードがあります。

この機能を使用することで、ページが表示されるまでの処理において、どの処理に時間がかかったかを確認することができます。この機能を使用するには、2 つの手順が必要となります。

使用までの手順

1. 管理シェルを起動し、以下のコマンドレットを実行して、開発者ダッシュボードを呼び出せるよう設定しておきます。

$DevDashboardSettings = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings
$DevDashboardSettings.DisplayLevel = 'OnDemand'
$DevDashboardSettings.TraceEnabled = $true
$DevDashboardsettings.Update()

タイトル : SPDeveloperDashboardSettings class
アドレス : http://msdn.microsoft.com/en-us/library/ee557630.aspx

SharePoint 2010 の開発者ダッシュボードの有効化手順は、上記と異なります。詳細については以下をご確認ください。

タイトル : 開発者ダッシュボードの使用
アドレス : http://msdn.microsoft.com/ja-jp/library/ff512745(v=office.14).aspx

2. ページの右上にあるアイコンをクリックし、実際にページ上に開発者ダッシュボードを呼び出します。

以下のように開発者ダッシュボードが起動します。新しい開発者ダッシュボードでは、ページ表示までに関連する様々な内部動作の要因 (例. SQL, SPRequest, サービス呼び出し, ULS) を分析する機能です。

画面に表示されているように、各 Web パーツの表示においてどれだけの時間がかかったか、データベース、Web サービスなどのバックエンドのデータソースにアクセスした時間なども詳細タブに記載されることから、どの処理において時間がかかるか、データが増えるに応じてどのように推移するかなどをページの公開前にあらかじめ把握しておくことができます。

平常時において、潜在的なリスクを事前に把握しておくことが可能になりますので、是非とも、この新機能を活用いただければと思います。

SharePoint Server 2013 の検索アーキテクチャ

2013-03-01T03:07:00Z

みなさんこんにちは。
SharePoint サポートチームの荒川です。

今日は新しくなった SharePoint Server 2013 の検索アーキテクチャについてご紹介します。

SharePoint Server 2013 で大幅に変更された検索アーキテクチャ
SharePoint Server 2013 の大きな変更点の一つとして、サーチエンジンの刷新が挙げられます。アーキテクチャとしてこれまでの機能を一部残していますが、殆ど別物といっても過言ではありません。トポロジの変更も従来のように管理 UI から気軽に行えなくなっていますし、運用中に気軽にトポロジ変更したりもできなくなっていますので、検索アーキテクチャをしっかりと理解して、十分な計画のもとに実装する必要があります。

SharePoint 検索エンジンの歴史
従来の SharePoint 検索エンジンは、元々がシングルサーバーのシステムである MS Search 2.0、Microsoft Desktop Search から発展したシステムでした。このため、どちらかというと箱庭的な環境で使う分には管理性もよく使いやすいという反面、大規模なシステムになると耐障害性やパフォーマンスという観点ではさらなる機能の向上が求められる場面がありました。

図：SharePoint Portal Server 2003 の検索アーキテクチャ

そうした背景を受け、FAST Search Server 2010 for SharePoint では、SharePoint Server 2010 の検索機能と統合能力に加えて、プラットフォームとしての柔軟性とスケーラビリティをいっそう高めると共に、高度なコンテンツ処理機能が提供されました。
SharePoint Server 2010 の検索機能とより密接な統合が可能になったことに加え、プラットフォームとしての柔軟性とス��ーラビリティが大幅に向上し、コンテンツ処理コンポーネントやクエリ処理コンポーネント、ホストコントローラによるノード単位でのコンポーネントの実行など、SharePoint Server 2013 の検索アーキテクチャの基盤となる仕組みが導入されています。

図：FAST Search Server 2010 for SharePoint の検索アーキテクチャ

FAST の長所は非常に大規模なシステムを構築できる点にありますが、構築の難易度が高いという反面もありました。現在リリースされている SharePoint Server 2013 の検索アーキテクチャでは FAST Search Server の仕組みと、これまでの SharePoint Search の仕組みが融合された新しい検索エンジンが採用されています。

SharePoint Server 2013 の検索コンポーネントモデル
下の図は、SharePoint Server 2013 の検索コンポーネントモデルを表したものです。

以下に、各プロセスごとに関連する検索コンポーネントの役割について解説します。
※上の図の各コンポーネントに付けられている数字、アルファベットは、後述の説明にあるものと対応しています。

クロールおよびコンテンツプロセス
クロールおよびコンテンツ処理アーキテクチャには、クロールコンポーネント、クロールデータベース、およびコンテンツ処理コンポーネントが含まれます。これらのコンポーネントは、両方とも、クロールの量とパフォーマンスの要件に基づいてスケールアウトできます。

1. クロールコンポーネント
・クロールコンポーネントは、クロールデータベースで指定された情報に基づいてコンテンツソースのクロールを行います。クロールコンポーネントは、コンテンツ処理コンポーネントに、クロールされたアイテム (実際のコンテンツと、関連付けられたメタデータの両方) を送ります。
・クロールコンポーネントは、コンテンツソースを操作してデータを取得するコネクタ、またはプロトコルハンドラーを呼び出します。複数のクロールコンポーネントを、同時にクロールするよう展開できます。
・クロールコンポーネントは、1 つまたは複数のクロールデータベースを使用し、クロールされたアイテムについての情報を一時的に保存して、クロール履歴を追跡管理します。
・容量とクロールパフォーマンスを上げるには、クロールコンポーネントを追加します。

A. クロールデータベース
・クロールデータベースには、クロールされたアイテムの詳細な追跡および履歴情報が含まれます。
・このデータベースには、最後にクロールした時間、最後にクロールした ID、最後のクロール中に行われた更新の種類のような情報が含まれます。
・各クロールデータベースには 1 つまたは複数のクローラーが関連付けられています。

2. コンテンツ処理コンポーネント
・コンテンツ処理コンポーネントは、クロールコンポーネントとインデックスコンポーネントの間に位置します。クロールされたアイテムを処理して、これらのアイテムをインデックスコンポーネントに渡します。
・コンテンツ処理コンポーネントは、ドキュメント解析とプロパティマッピングのような処理を実行して、クロールしたアイテムを、検索インデックスに含めることができる成果物に変換します。
・コンテンツ処理コンポーネントとクエリ処理コンポーネントの両方が、言語学的処理を実行します。コンテンツ処理中の言語学的処理の例は、言語検出とエンティティ抽出です。
・コンテンツ処理コンポーネントは、リンクと URL の情報をリンクデータベースに書き込みます。その一方で、分析処理コンポーネントは、コンテ
ンツ処理コンポーネント経由で、これらのリンクと URL の関連性についての情報を検索インデックスに書き込みます。

インデックスおよびクエリプロセス
インデックスおよびクエリアーキテクチャには、インデックスコンポーネント、インデックスパーティション、およびクエリ処理コンポーネントが含まれます。これらすべては、コンテンツボリューム、クエリボリューム、およびパフォーマンス要件に基づいて、スケールアウトできます。

4. インデックスコンポーネント
・インデックスコンポーネントは、インデックスレプリカの論理表現です。検索アーキテクチャでは、各インデックスレプリカについて 1 つのインデックスコンポーネントを準備する必要があります。
・インデックスコンポーネントはコンテンツ処理コンポーネントから処理されたアイテムを受け取って、それらのアイテムをインデックスファイルに書き込みます。
・インデックスコンポーネントはクエリ処理コンポーネントからクエリを受け取り、その代わりに結果セットを渡します。
・クエリは、クエリ処理コンポーネント経由でインデックスレプリカに送られます。システムは、インデックスレプリカに着信したクエリを送り、負荷分散します。
・インデックスは、インデックスパーティションと呼ばれる別々の部分に分割できます。各インデックスパーティションには、インデックスの異なる部分が含まれます。検索インデックスは、すべてのインデックスパーティションの集合体です。インデックスパーティションは、ディスク上の一連のファイルに保存されます。
・検索インデックスは、以下の 2 つの方向に規模調整できます。

　インデックスレプリカ
　・インデックスレプリカは、クエリ負荷またはフォールトトレランスの需要に従ってインデックスパーティションに追加できます。各インデックスパーティションは、1 つまたは複数のインデックスレプリカを持っています。インデックスパーティション内の、各インデックスレプリカは同じ情報を持っています。たとえば、ファームに 1 つのインデックスパーティションがあるとします。このインデックスパーティションには、3 つのインデックスレプリカが含まれ、各インデックスレプリカはクエリ全体の 3 分の 1 に対して機能します。
　・各インデックスレプリカについて 1 つのインデックスコンポーネントを準備する必要があります。
　・フォールトトレランスと冗長性を実現するには、各インデックスパーティション用に追加のインデックスレプリカを作成し、複数のアプリケーションサーバー上でインデックスレプリカを配布します。

　インデックスパーティション
　・コンテンツボリュームが増大した場合は、それを処理できるようにインデックスパーティションを追加できます。たとえば、3 つのインデックスパーティションがあるファームでは、各インデックスパーティションにインデックスの 1/3 が含まれます。通常は検索インデックスで 1 千万のアイテムごとに 1 つのインデックスパーティションを追加することを推奨しています。
　・各インデックスパーティションには、同じ情報を含む 1 つまたは複数のインデックスレプリカが含まれます。

5. クエリ処理コンポーネント
・クエリ処理コンポーネントは、検索フロントエンドコンポーネントとインデックスコンポーネントの間に位置します。
・クエリ処理コンポーネントは、検索クエリおよび結果を分析、処理します。
・クエリ処理コンポーネントとコンテンツ処理コンポーネントの両方が、言語学的処理を実行します。クエリ処理中の言語学的処理の例は、単語区切り処理とステミングです。
・クエリ処理コンポーネントは、検索フロントエンドからクエリを受け取ったとき、正確さ、再現率、および関連性を最適化する目的で、クエリを分析して、処理します。次に、処理されたクエリは、インデックスコンポーネントに送信されます。
・インデックスコンポーネントは、処理されたクエリに基づく結果セットを、クエリ処理コンポーネントに戻します。一方で、クエリ処理コンポーネントは、その結果セットを処理してから、検索フロントエンドにそれを戻します。

分析プロセス
分析アーキテクチャは、分析処理コンポーネント、分析レポートデータベース、およびリンクデータベースから構成されます。

3. 分析処理コンポーネント
・分析処理コンポーネントは、クロールされたアイテムの分析 (検索分析) と、ユーザーが検索結果をどう操作するかの分析 (利用状況分析) を行います。その情報を使用して、検索関連性を向上し、検索レポート、おすすめ候補、およびディープリンクを作成します。
・このコンポーネントは以下を抽出します。

　検索分析情報
　リンク、アンカーテキスト、人に関連する情報、メタデータなどで、これらは、分析処理コンポーネントが、コンテンツ処理コンポーネント経由で受信したアイテムから抽出します。情報は、未処理のままリンクデータベースに保存されます。

　利用状況分析情報
　フロントエンドからイベントストア経由で取得されたアイテムの表示回数などです。

・分析処理コンポーネントは、上記の両方の種類の情報を分析します。次に、分析結果は、検索インデックスに含まれるように (部分的な更新を使用して) コンテンツ処理コンポーネントに戻されます。さらに、利用状況分析からの結果は、分析レポートデータベースに保存されます。

B. リンクデータベース
リンクデータベースは、コンテンツ処理コンポーネントによって抽出された情報を保存します。さらに、検索クリックについての情報を保存します。これは、ユーザーが検索結果ページから検索結果をクリックした回数です。この情報は未処理のまま保存されます。分析処理コンポーネントは分析を行います。

C. 分析レポートデータベース
・分析レポートデータベースは利用状況分析の結果を保存します。
・さらに、分析レポートデータベースは、さまざまな分析からの統計情報を保存します。SharePoint は、この情報を使用して、さまざまな統計を示す Excel レポートを作成します。

検索管理
検索管理は、検索管理コンポーネントとそれに対応するデータベースから構成されます。

検索管理コンポーネント
・検索管理コンポーネントは、検索で重要なさまざまなシステムプロセスを実行します。
・このコンポーネント��、準備を行います。準備とは、その他の検索コンポーネントから追加のインスタンスを追加して、初期化することです。
・Search Service アプリケーションごとに、1 つの検索管理コンポーネントをアクティブにできます。

検索管理データベース
・検索管理データベースは、トポロジ、クロールルール、クエリルール、およびクロールされたプロパティと管理プロパティ間のマッピングのような、検索構成データを保存します。
・検索管理データベースは、各 Search Service アプリケーションに 1 つのみ存在します。

SharePoint Server 2013 の検索トポロジモデル
SharePoint Server 2013 ではシステムの要求に応じて柔軟に検索トポロジを構成できます。
下の図は、アイテムが 1,000 万個以下の小規模ファームに対応した検索トポロジの例です。

上記の例では、クエリの役割と検索管理、クロールの役割でサーバーを分けて、すべての検索コンポーネントで冗長性を持たせています。
また、以下は、最大 4 千万アイテムの検索に対応したエンタープライズ検索用の多目的フォールトトレラントファームの例です。

検索トポロジの構成方法についてここでは詳しく述べませんが、要点のみ以下にまとめておきます。

　・SharePoint Server 2013 をインストールして Search Service アプリケーションを作成した直後は、Search Service アプリケーションが既定の検索トポロジで作成されています。既定の検索トポロジでは、すべての検索コンポーネントは、サーバーの全体管理をホストするサーバー上にあります。
　・SharePoint Server 2013 では検索トポロジを変更するためのユーザーインターフェイスが提供されておらず、すべての操作は PowerShell から行う必要があります。

具体的な手順等については、後述の参考資料「SharePoint Serever 2013 で検索トポロジを管理する」に記載されていますので、そちらをご参照ください。

参考資料
以下の Technet カテゴリには、検索機能を計画する際に役に立つ情報が集約されていますのでご参考ください。

　タイトル：検索の新機能 (SharePoint Server 2013)
　URL ：http://technet.microsoft.com/ja-jp/library/ee667266.aspx

　タイトル：SharePoint Server 2013 で検索を計画する
　URL ：http://technet.microsoft.com/ja-jp/library/cc263400.aspx

以下の Technet カテゴリには、実際に Search Service アプリケーションを作成および構成する際に役に立つ情報が集約されていますのでご参考ください。

　タイトル：SharePoint Server 2013 で Search Service アプリケーションを作成および構成する
　URL ：http://technet.microsoft.com/ja-jp/library/gg502597.aspx

　タイトル：SharePoint Serever 2013 で検索トポロジを管理する
　URL ：http://technet.microsoft.com/ja-jp/library/jj219705.aspx

　タイトル：SharePoint 2013 のアーキテクチャの設計 (IT 担当者)
　URL ：http://technet.microsoft.com/ja-jp/sharepoint/fp123594.aspx

　タイトル：Enterprise search architectures for SharePoint Server 2013
　URL ：http://www.microsoft.com/en-us/download/details.aspx?id=30383

　タイトル：Internet sites search architectures for SharePoint Server 2013
　URL ：http://www.microsoft.com/en-us/download/details.aspx?id=30464

　タイトル：SharePoint Server 2013 の検索アーキテクチャ
　URL ：http://www.microsoft.com/ja-jp/download/details.aspx?id=30374

以下の資料では、SharePoint Server 2013 の既知の問題について報告されていますが、本稿と関連する情報として、検索トポロジの構成時に New-SPEnterpriseSearchIndexComponent が、誤ったサーバーで RootDirectory の存在を確認する問題が取り上げられています。対処方法についても記載がありますのでこちらも併せてご参考ください。

　タイトル：SharePoint Server 2013 の既知の問題
　URL ：http://office.microsoft.com/ja-jp/help/HA102919021.aspx

SharePoint 2013 概要および変更点

2013-02-19T15:49:00Z

こんにちは。SharePoint サポート川添です。

先日 SharePoint Server 2013 がリリースになり、様々な動作検証を実施したり、パイロットで使用されている方もいらっしゃるかと思います。

今回は、SharePoint 2013 での大きな変更点や様々な SharePoint 2013
の有用な技術情報が掲載されているWeb サイトを紹介したいと思います。

SharePoint 2013 での大きな変更点

全ての変更点はカバーできませんが、SharePoint 2013 でのはじめの一歩として、特に大きな点について IT Pro の観点から幾つかピックアップしたいと思います(Developer の観点では、また違った変更点があります) 。詳細な技術的な説明は、別の投稿でカバーしていきます。

1. 認証/認可

・SharePoint 2010 で導入されたクレーム認証が既定となり、今まであったクラシック認証が今後廃止予定とされ、今バージョンから非推奨となります。クラシック認証を使用することも可能ですが、GUI からはクラシック認証を持つ Web アプリケーションを作成することはできません。

・新しい認証プロトコルとして、OAuth 2.0 が導入されました。この認証プロトコルは SharePoint Apps
(これも新たなアプリケーションの概念ですが) で利用されたり、S2S (Server To Server : サーバー間の認証で利用されます) で使用されるもので、ユーザー認証ではななく、アプリケーションに対する認証に使用されます。

2. インストール/アップグレード

・SharePoint 2013 の前提として、Windows Server 2008
R2 SP1 や Windows Server 2012 が利用可能です。また、.NET Framework も 4.5 が必要になります。

・既存の環境に、新規バージョンを上書きインストールするインプレースアップグレードが廃止されました。SharePoint 2010 からのアップグレードでは、データベースアタッチアップグレードのみが使用可能です。

・Office Web Apps が SharePoint とは独立した別製品として提供されます。SharePoint 2010 では、既存の SharePoint Server 上にインストール、構成を行いましたが、Office Web Apps 2013 では SharePoint を必要としません。

3. インフラストラクチャ

・新規サービス
アプリケーションの追加、サービスアプリケーションの廃止が行われます。基本的なサービスアプリケーションの概念は変わりませんが、SharePoint 2013 ではサービスアプリケーションに大幅な変更が加わっています。以下に一部の例を示します。

- App Management Service Application が追加されています。これは、SharePoint Apps や OAuth
2.0 / S2S を基盤とする機能 (例. Access Service 2013) を利用する上で必須のサービスアプリケーションで、Search
サービスアプリケーションやUser Profile　サービスアプリケーションとともに、SharePoint 2013 では重要なサービス
アプリケーションの 1 つです。

- Microsoft Translation Service
Application では、Microsoft Translation Service に接続して翻訳できる機能を提供します。バリエーションサイトでの翻訳や、Managed Metadata Service Application の用語の翻訳に使用されます。

- Web Analytics サービスアプリケーションは、サービスアプリケーションとしての位置づけではなく、検索コンポーネントの一部として組み込まれています。そのため、Web Analytics サービスアプリケーションのアップグレードはできません。

- SharePoint 2013 では、Fast
Search 2010 for SharePoint との統合が行われ、検索アーキテクチャの刷新が行われました。そのため、SharePoint 2010 とも Fast Search 2010 for
SharePoint とも異なる、より進化したアーキテクチャが採用されています。

・分散キャッシュ機能の追加

Windows AppFabric の機能を利用して、キャッシュを単一サーバーで独立して持つのではなく、複数サーバー (Cache Cluster) で分散して保持する機能です。SharePoint
2013 では主にソーシャル系の機能が多用しています。なお、既存のオブジェクトキャッシュ等とは別の機能です。

・Request Management 機能の追加

クライアントから発行されたリクエストに対して、ルール等を元にして処理要求先のサーバーを分散して処理する機能です。単に既存の負荷分散装置を置きかえるといったものではなく、既存の負荷分散装置とも共存することができる、SharePoint 内部に実装された機能です。

4. User Interface

・サーバーサイドでのレンダリング処理 (例. XSL など) が、クライアントサイトでレンダリング処理 (例. JavaScript) されるようになりました。すべてがクライアントサイドで処理されるわけではありませんが、サーバーでの負荷軽減やよりリッチな User Experience を提供することを目的として提供されます。メニューをクリックしたりすると、ポップアップ (CallOut) が表示されて、処理されているような状況に出くわすことが多いと思いますが、それがこの変更点にあたります。

・MDS (Minimum Download Strategy) ダウンロード最小化戦略機能では、画面全体を描画するのではなく、必要な箇所のみを取得して画面描画するようになっています。ブラウザのアドレスバーに start.aspx という URL に続いて、ページ URL が追加されているような URL では、この MDS 機能が作動しています。

・Mobile デバイスに最適な UI を提供することができるよう Device Channel 機能が提供されます。特定の User Agent に応じて、特定のレイアウトを提供できるようにする機能です。

5. ソーシャル機能

・SharePoint 2013 での大きな変更点の 1 つです。ソーシャル機能の中では、個人用サイトを中心として大幅な刷新が行われています。マイクロブログの機能、フォロー機能が追加され、フィード機能も大きく変更されています。また、マイクロブログの内容な個人用サイトに保管され、削除されることはありません。

6. Exchange Server 2013 との連携

・先に触れた S2S も関連しますが、Exchange Server 2013 と SharePoint 2013 の連携機能が拡充されています。eDiscovery やサイト
メールボックスの機能が Exchange Server 2013 との連携で実現されています。各機能について簡単に触れると、eDiscovery は主に訴訟を念頭に使用される機能で、SharePoint、Exchange やファイルサーバー等のデータを横断的に検索し、必要なデータをホールドできる機能です。サイトメールボックスは、特定のプロジェクト等の単位で、専用のメールアドレスを持つことができる機能です。そのため、サイト
メールボックスの場合、Exchange Server 側にメールボックスを持ちます。なお、これらの機能は2013 での新機能で、クライアントも Outlook 2013 である必要があります。

以上が、SharePoint 2013 での大きな変更点です。ここで触れたのはごく一部の内容なので、これ以外の変更も非常に多数存在しますが、まずは大きくどういった点が変更されたのか、SharePoint 2013 に触る前の取っ掛かりとして参考になればと思います。

SharePoint 2013 の有用な情報を提供するサイト

SharePoint 2013 に関する資料、Web サイトは様々ありますが、その量は現在増加中です。すでに多数の情報が発行されていますが、リリース直後のため、まだ 2010 と比べて不足している箇所もあります。

今後も、新たな資料が次々と発行されていきますので、RSS フィードが提供されている場合には、購読しておくと便利かと思います。

以下は、2013年2月現在で有用な資料を紹介していますが、英語資料がメインになります。日本語資料がすでに提供されている場合には、言語を英語に変更するか、URL の “en-us” の箇所を “ja-jp” に変更してアクセスすれば、翻訳済の資料を確認できます。

技術情報サイト

SharePoint 2013 for IT pros

http://technet.microsoft.com/en-us/sharepoint/fp142366.aspx

SharePoint 2013 をはじめとして、製品の総合情報ポータルサイトです。累積的な修正プログラムの内容も、SharePoint
2010 と同様に一覧で表示される予定です。

SharePoint 2013

http://technet.microsoft.com/en-us/library/cc303422.aspx

SharePoint 2013 の TechNet Library です。IT Pro 向けの技術的な情報は、ここに集約されます。

SharePoint 2013

http://msdn.microsoft.com/en-us/library/jj162979.aspx

SharePoint 2013 の MSDN Library です。Developer
向けの技術的な情報は、ここに集約されます。

SharePoint Server 2013 known issues

http://office.microsoft.com/en-au/help/sharepoint-server-2013-known-issues-HA102919021.aspx

SharePoint Foundation 2013 known issues

http://office.microsoft.com/en-001/help/sharepoint-foundation-2013-known-issues-HA102919008.aspx

SharePoint 2013 に関する現在の既知の問題に対する情報を提供しています。

ブログ、Wiki 等

Microsoft SharePoint Team Blog

http://sharepoint.microsoft.com/blog/Pages/default.aspx

SharePoint 製品部門によるブログです。SharePoint 全般、イベントの情報等をここで提供しています。

TechNet - Wiki Articles

http://social.technet.microsoft.com/wiki/contents/articles/default.aspx

Partner や MVP による Wiki ページです。Know-How 等が書かれていることがあります。

おまけ

SharePoint 2013 の Certification Exam (for IT Pro) がオープンになっています。我こそは
“SharePoint
2013 マスターだ！” と思わる方は是非力試しをしてみては如何でしょうか。

Exam 70-331:Core Solutions of Microsoft SharePoint Server 2013

http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-331

Exam 70-332:Advanced Solutions of
Microsoft SharePoint Server 2013

http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-332

CU のバージョン一覧

2013-02-19T06:06:00Z

こんにちは。
SharePoint サポートチームの荒川です。
私が個人的に作った CU とバージョン番号の対応表をここにアップしておきます。(たまに更新する予定です。)
CU をどこまであてたか確認したい時などにご利用くださいませ。

補足：ファームバージョンというのは、サーバーの全体管理サイトで [このファームのサーバーの管理] (MOSS 2007 の場合 [ファームサーバー]) を開いたときに確認できるバージョン情報です。基本的に Server-package(Uber)、COD ベースです。このあたりの単語がよくわからない方はこちらをご参照ください。

※自分用の備忘メモとして作っていたもので、途中からモジュールバージョンではなくファームバージョンに変えていたりしますので、一部正確ではないかもしれません。。ですので、あくまで参考程度にご利用ください。

(最終更新：2013/02/18)

MOSS 2007

Version	Rel	Type	KB
12.0.4518.1016	2007年1月	RTM
12.0.6036.5000	2007年10月	PU	937832
12.0.6219.1000	2008年1月	SP1	936984
12.0.6300.5000	2008年1月	COD	941274
12.0.6315.5000	2008年5月	COD	952704
12.0.6317.5000	2008年6月	COD	953135
12.0.6318.5000	2008年7月	IU	951297
12.0.6324.5000	2008年7月	COD	955593
12.0.6327.5000	2008年8月	CU	956056
12.0.6331.5000	2008年10月	CU	957693
12.0.6335.5001	2008年12月	Uber	960011
12.0.6341.5001	2009年2月	Uber	961756
12.0.6341.5002	2009年2月	COD	968269
12.0.6420.1000	2009年4月	SP2	953334
12.0.6421.1000	2009年4月	SP2	953334
12.0.6504.5000	2009年4月	Uber	968851
12.0.6510.5003	2009年6月	Uber	971537
12.0.6514.5002	2009年8月	Uber	973399
12.0.6520.5000	2009年10月	Uber	974988
12.0.6524.5001	2009年12月	Uber	977026
12.0.6529.5000	2010年2月	Uber	978395
12.0.6535.5000	2010年4月	Uber	981042
12.0.6535.5003	2010年6月	Sec	979445
12.0.6539.5000	2010年6月	CU	983305
12.0.6539.5000	2010年6月	Uber	983310
12.0.6545.5001	2010年8月	Uber	2276472
12.0.6548.5000	2010年10月	Uber	2412267
12.0.6550.5000	2010年12月	Uber	2458605
12.0.6554.5000	2011年2月	Uber	2475885
12.0.6557.5000	2011年4月	Uber	2512782
12.0.6562.5000	2011年6月	Uber	2544398
12.0.6565.5000	2011年8月	Uber	2553020
12.0.6608.1000	2011年10月	SP3	2526299
12.0.6653.5000	2011年10月	Uber	2596540
12.0.6653.5002	2011年10月	Uber	2596540
12.0.6656.5000	2011年12月	Uber	2596986
12.0.6658.5000	2012年2月	Uber	2597958
12.0.6661.5000	2012年4月	Uber	2598129
12.0.6662.5000	2012年6月	Uber	2687256
12.0.6665.5000	2012年8月	Uber	2687330
12.0.0.6666	2012年10月	Uber	2687533
12.0.0.6670	2012年12月	Uber	2760570
12.0.0.6673	2013年2月	Uber	2760814

WSS 3.0

Version	Rel	Type	KB
12.0.4518.1016	2007年1月	RTM
12.0.6039.5000	2007年10月	PU	934525
12.0.6219.5000	2008年1月	SP1	936988
12.0.6300.5000	2008年1月	COD	941422
12.0.6318.5000	2008年6月	IU	951695
12.0.6324.5000	2008年6月	COD	955594
12.0.6327.5000	2008年8月	CU	956057
12.0.6327.5002	2008年9月	COD	956612
12.0.6331.5000	2008年10月	CU	957691
12.0.6335.5000	2008年12月	Uber	960010
12.0.6341.5000	2009年2月	Uber	961755
12.0.6421.1000	2009年4月	SP2	953338
12.0.6504.5000	2009年4月	Uber	968850
12.0.6510.5001	2009年6月	Uber	971538
12.0.6514.5004	2009年8月	Uber	973400
12.0.6520.5000	2009年10月	Uber	974989
12.0.6524.5000	2009年12月	Uber	977027
12.0.6529.5000	2010年2月	Uber	978396
12.0.6535.5000	2010年4月	Uber	981043
12.0.6535.5003	2010年6月	Sec	983444
12.0.6539.5000	2010年6月	Uber	983311
12.0.6545.5001	2010年8月	Uber	2276474
12.0.6548.5000	2010年10月	Uber	2412268
12.0.6550.5002	2010年12月	Uber	2458606
12.0.6554.5000	2011年2月	Uber	2475886
12.0.6557.5001	2011年4月	Uber	2512783
12.0.6562.5000	2011年6月	Uber	2544399
12.0.6565.5000	2011年8月	Uber	2553022
12.0.6608.1000	2011年10月	SP3	2526305
12.0.6653.5000	2011年10月	Uber	2596541
12.0.6656.5000	2011年12月	Uber	2596987
12.0.6658.5000	2012年2月	Uber	2597959
12.0.6661.5000	2012年4月	Uber	2598130
12.0.6662.5000	2012年6月	Uber	2687257
12.0.6665.5000	2012年8月	Uber	2687331
12.0.0.6666	2012年10月	Uber	2687535
12.0.0.6670	2012年12月	Uber	2760571
12.0.0.6673	2013年2月	Uber	2760816

SPS 2010

Version	Rel	Type	KB
14.0.4763.1000	2010年4月	RTM
14.0.5123.5000	2010年8月	Uber	2352342
14.0.5128.5000	2010年10月	Uber	2394320
14.0.5128.5003	2010年10月	Uber	2394320
14.0.5130.5002	2010年12月	Uber	2459257
14.0.5136.5002	2011年2月	Uber	2475878
14.0.5138.5001	2011年4月	Uber	2512800
14.0.6029.1000	2011年6月	SP1	2460045
14.0.6106.5000	2011年6月	Uber	2536599
14.0.6106.5002	2011年6月	Uber	2536599
14.0.6109.5002	2011年8月	Uber	2553048
14.0.6109.5005	2011年8月	Uber	2553048
14.0.6112.5000	2011年10月	Uber	2596505
14.0.6114.5000	2011年12月	Uber	2597014
14.0.6117.5002	2012年2月	Uber	2597150
14.0.6120.5000	2012年4月	Uber	2598151
14.0.6120.5006	2012年4月	Uber	2598151
14.0.6123.5002	2012年6月	Uber	2598354
14.0.6126.5002	2012年8月	Uber	2687353
14.0.6129.5002	2012年10月	Uber	2687564
14.0.6131.5003	2012年12月	Uber	2596955
14.0.6134.5000	2013年2月	Uber	2767793

SPF 2010

Version	Rel	Type	KB
14.0.4763.1000	2010年4月	RTM
14.0.5123.5000	2010年8月	Uber	2352346
14.0.5128.5000	2010年10月	Uber	2394323
14.0.5130.5002	2010年12月	Uber	2459125
14.0.5136.5002	2011年2月	Uber	2475880
14.0.5138.5001	2011年4月	Uber	2512804
14.0.6029.1000	2011年6月	SP1	2460058
14.0.6106.5000	2011年6月	Uber	2536601
14.0.6106.5002	2011年6月	Uber	2536601
14.0.6109.5002	2011年8月	Uber	2553050
14.0.6112.5000	2011年10月	Uber	2596508
14.0.6114.5000	2011年12月	Uber	2597058
14.0.6117.5002	2012年2月	Uber	2597132
14.0.6120.5000	2012年4月	Uber	2598321
14.0.6120.5006	2012年4月	Uber	2598321
14.0.6123.5002	2012年6月	Uber	2598373
14.0.6126.5002	2012年8月	Uber	2687355
14.0.6129.5002	2012年10月	Uber	2687566
14.0.6131.5003	2012年12月	Uber	2596957
14.0.6134.5000	2013年2月	Uber	2760791

SPS 2013

Version	Rel	Type	KB
15.0.4420.1017	2012年10月	RTM
	2013年2月	Uber	2767923

SPF 2013

Version	Rel	Type	KB
15.0.4420.1017	2012年10月	RTM
	2013年2月	Uber	2767924

リストの添付ファイルの並び順

2013-02-15T07:03:00Z

みなさんこ��にちは。
SharePoint サポートチームの荒川です。

今回はリストの添付ファイルの並び順に関する既知の問題についてお知らせします。

[現象]
MOSS 2007 から SharePoint 2010 にアップグレードしたら、リストの添付ファイルの並び順がランダムに変わってしまった。

[原因]
この問題は SharePoint 2010 の既知の問題です。

[解説]
この問題は、SharePoint 2010 の内部動作において添付ファイルの一覧を取得するための SQL クエリで並び順を明示的に指定していないために発生します。
SharePoint 2010 では、添付ファイルの情報が保存されるコンテンツデータベース内で、添付ファイルごとに内部的な ID を付与して管理しています。この ID はランダムな要素を含んでいて、アイテムの作成順序によりシーケンシャルな値が発行されません。
ユーザーが SharePoint サイトで添付ファイルの一覧を表示する際には、内部的に proc_GetAllAttachmentsInfo ストアドプロシージャが呼び出されますが、このストアドプロシージャ内において、添付ファイルの ID を元にソートを行っているため、結果的に添付ファイルの並び順がランダムに返されます。

[対処方法]
2012 年の 12 月 (SP1 以降) にリリースされた修正プログラム (CU) において、proc_GetAllAttachmentsInfo ストアドプロシージャが改良され、結果セットをファイル名順にソートするようになりました。本動作を修正するには、お使いの環境に 2012 年の 12 月以降の CU を適用してください。

<2012 年 12 月 CU の入手先>
SharePoint Server 2010
タイトル：Description of the SharePoint Server 2010 cumulative update package (SharePoint server-package): December 22, 2012
URL ：http://support.microsoft.com/kb/2596955

SharePoint Foundation 2010
タイトル：Description of the SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): December 11, 2012
URL ：http://support.microsoft.com/kb/2596957

<参考情報>
2012 年 12 月 CU に含まれる個別の修正 (KB2589331) において、該当の修正に関する情報が公開されています。

タイトル：Description of the SharePoint Foundation 2010 hotfix package (Wssmui-nl-nl.msp, Wss-x-none.msp): December 11, 2012
URL ：http://support.microsoft.com/kb/2589331

--- 抜粋 ---
Assume that you add multiple attachments to a list item in SharePoint Foundation 2010. In this situation, the attachments are not displayed in alphabetical order in the list item.
------------