はじめまして！

私たちは日本マイクロソフト SharePoint サポートチームです。

 

このたび、SharePoint サポートチームにてブログをはじめることになりました。

SharePoint 製品をご使用いただいているお客様に、技術的な内容を中心にお役に立てる情報を配信する予定です。

また、これから SharePoint 製品のご使用を検討いただいているお客様にも、SharePoint に関するニュースなど参考になる情報を配信する予定です。

 

2009 年 7 月 1 日より配信スタート予定です。

ぜひご期待ください！

 

Japan SharePoint Support Team 一同

 

 

なお、コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

 

こんにちは。

SharePoint サーポートチームのたらかわです。

 

最近日を追うごとに暑くなってますね。雨なんか降ろうものなら湿度が上昇し、自慢の天然パーマがくりんくりんになってしまい困ります。特にもみあげあたりが大変なことになります。

湿度といえば、先日、庭になめ茸っぽい感じの、得体の知れないキノコが生えていることに気づいたのですが、梅雨も終われば消え去るだろうと放置していたところ、庭一面のキノコ畑が出来上がってしまいました。(1 up し放題です。) 幸い、翌日には家族により撤去されていましたが、その日の夕食に出されたなめ茸のお味噌汁は、いつもより豊潤で新鮮な香りがした気がします。

 

さて、たらかわの残機が増えたお話はこの辺にして、本題に入りましょう。

 

既に多くの方がご存知かもしれませんが、Microsoft Office SharePoint Server 2007 および Windows SharePoint Services の最新の Service Pack である、Service Pack 2 が公開されています。

 

本サービスパックには、2009 年 2 月までにリリースされたすべての更新プログラム、セキュリティ更新プログラム、累積的な更新プログラム、および修正プログラムに加え、安定性、パフォーマンス、およびセキュリティの機能強化が含まれています。特に、初期リリース版で目立った、検索、クロール関連の様々なトラブルが解消されていますので、まだ適用されていない場合は是非、この機会に適用をご検討ください。

 

Windows SharePoint Services 3.0 SP2 および Windows SharePoint Services 3.0 Language Pack SP2 について

http://support.microsoft.com/kb/953338

 

2007 Microsoft Office Servers Service Pack 2 (SP2) および 2007 Microsoft Office Servers Language Pack Service Pack 2 (SP2) について

http://support.microsoft.com/kb/953334

 

基本的な適用手順は SP1 のときと同様ですが、以下のサイトでは、具体的な適用手順や注事項について詳しく解説されているので、参考になります。

 

Office SharePoint Server 2007 のソフトウェア更新プログラムを展開する

http://technet.microsoft.com/ja-jp/library/cc263467.aspx

 

Windows SharePoint Services 3.0 用のソフトウェア更新プログラムを展開する

http://technet.microsoft.com/ja-jp/library/cc288269.aspx

 

なお、MOSS 2007 SP2 には、適用時に注意しなければならないことがあります。

MOSS 2007 SP2 をインストールすると、製品の有効期限が試用版と同様に 180 日間に設定されてしまうのです。（な、何ぃ～！？）

 

 

<2009/8/19 追記>

2009 年 7 月 29 日以降にマイクロソフトのダウンロード サイトから 2007 Microsoft Office Servers Service Pack 2 をダウンロードされている場合は、以下に記載する製品の有効期限がリセットされてしまう問題は発生しませんのでご安心ください。お手元に既にダウンロード済みのパッケージがいつダウンロードされたかわからない場合は、以下のサイトから最新のパッケージをダウンロードしていただくことをお勧めします。

また、最新のパッケージが問題なく適用できているか不安な場合、SP2 のインストール後にライセンスの種類をご確認ください。

 

2007 Microsoft Office Servers Service Pack 2 (SP2)

http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=b7816d90-5fc6-4347-89b0-a80deb27a082

 

 

 

 

<図1:製品版にもかかわらず有効期限が設定されてしまってもうどうしていいかわからない。>

 

しかし、慌てる必要はありません。有効期限内であれば、実質的にユーザーへの影響はありませんので、期限が切れる前に、手動でインストール時に使用したプロダクトキーを再設定すれば、製品を再度アクティブ化できます。若干面倒ですが、そのまま放置すると、そのうちライセンスの有効期限が切れて、検索などの一部の機能が使用できなくなるので注意が必要です。

 

<図2:あせらずに、プロダクトキーを再設定しましょう。>
 

 

<図3:放置するとこんなことになっちゃいます。>

 

また、この問題に対する修正プログラムもリリースされています。

 

Update for 2007 Microsoft Office Servers (KB971620), 32-Bit EditionCollapse this imageExpand this imageDownload the Download the Update for 2007 Microsoft Office Servers (KB971620), 32-Bit Edition package now.

http://download.microsoft.com/download/2/f/5/2f51ab71-1325-49d2-9cb9-18dec4780e99/office2007-kb971620-fullfile-x86-glb.exe

 

Update for 2007 Microsoft Office Servers (KB971620), 64-Bit EditionCollapse this imageExpand this imageDownload the Download the Update for 2007 Microsoft Office Servers (KB971620), 64-Bit Edition package now.

http://download.microsoft.com/download/5/b/b/5bbd34a9-c528-42b0-8a5f-9a8997b25c32/office2007-kb971620-fullfile-x64-glb.exe

 

上記修正プログラムは、Service Pack 2 適用前後のどちらのタイミングで適用しても構いません。

Service Pack 2 適用前にインストールした場合、Service Pack 2 適用時に製品の有効期限が誤ってアクティブ化される問題を未然に防止でき、Service Pack 2 適用後にインストールした場合は、誤ってアクティブ化された製品の有効期限の情報を修正することが可能です。これから Service Pack 2 を適用される予定がある方は、Service Pack 2 のインストール前に上述の修正プログラムの適用をプランに組み込むことをお勧めします。

 

注意点として、Service Pack 2 適用後に上述の修正プログラムをインストールした場合、修正プログラムのインストール時にサーバーの再起動を求められます。既に手動で有効期限を変更されている場合には、本修正プログラムの適用は必須ではありませんので、サーバーの再起動を避けたい場合は、手動でプロダクトキーを再設定する対処方法でもよいでしょう。

 

<図4：サーバーの再起動を求められちゃう感じ。>

 

また、修正プログラムをインストールした直後は、有効期限の情報が更新されないことにも注意が必要です。

修正プログラムにより更新された有効期限の情報は、既定で 1 時間に 1 回実行される、"ライセンス同期プログラムジョブ" タイマジョブが実行されたタイミングで、全体管理サイトに反映されます。ですので、修正プログラムを適用した場合は最低でも 1 時間待ってから、ライセンスの情報が更新されることを確認してみましょう。

 

SharePoint タイマ ジョブ リファレンス (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc678870.aspx

 

ライセンス同期プログラム ジョブ

試用版の有効期限ライセンス情報を構成データベースに同期します。

毎時

 

<図5：この子ですね。今まで存在感が無かった彼ですが 1 日 24 回も健気に頑張ってたんだなぁ。>

 

ちなみに、Windows SharePoint Services 3.0 については、この問題の影響は受けません。

※Search Server 2008、Search Server 2008 Express、SharePoint Server 2007 for Search、Microsoft Office Project Server 2007 については MOSS 2007 と同様にこの影響を受けてしまうため注意が必要です。

 

詳しくは以下のリンク先に記載されているので、これから MOSS 2007 に SP2 を適用する場合は是非ご一読ください。

 

2007 Microsoft Office Servers Service Pack 2 (SP2) をインストールすると、製品の有効期限が誤ってアクティブ化される

http://support.microsoft.com/kb/971620

 

今回はタイムリーなネタということで、Service Pack 2 に関するお話をさせていただきましたが、次回からも、SharePoint 製品とテクノロジに関する有益な情報を提供していきますので、ご期待ください！！

 

by たらかわ x 99

こんにちは。

SharePoint サポートチームの森下です。

 

ブログも 2 回目の更新となりますが、実はアクセス カウンターを仕掛けていないという凡ミスにより、どれだけの方にご覧いただけているのかがよく分からない状況になっちゃっているのですが、、

きっとたくさんの方が見てくれていると信じてこれかも定期的に更新していきますので、みなさまどんどんアクセスよろしくお願いします。

 

さて、今回はサポートによくお問い合わせいただくものの中から、ソリューション パッケージ ファイル (*.wsp ファイル) の展開方法 についてご紹介します。

なぜ 2 回目がこのネタ !? とお思いの方もいるかもしれませんが、VSeWSS (以下参照) で作成されたバッチ ファイルをファームの検証環境にそのまま持っていって展開しようとしたけど失敗。。というパターンがけっこう多いようです。

 

http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=a8a4e775-074d-4451-be39-459921f79787

http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=7bf65b28-06e2-4e87-9bad-086e32185e68

 

ここでまずお伝えしないといけ��いのは、VSeWSS は 1 台構成の開発環境を想定しており、ファーム環境に対する考慮はされていません。

したがって、このツールで作成される展開用のバッチなどを、そのままファーム環境で使用することはできないのです。。

そして、もう 1 点、この VSeWSS、ダウンロード サイトの必要システムの欄に記載がありますとおり、マイクロソフトはテクニカル サポートを提供していませんので、この点はあしからずご了承ください。。

 

と、前置きはここまでにして、では実際に開発した wsp ファイルを MOSS のファーム環境に展開するためにはどうしたら良いのか。

そこで今回は一般的なソリューションパッケージの展開方法をここでご紹介できればと思います。

 

ソリューションを展開する方法

****************************

以下の手順は、"サーバーの全体管理" の管理者権限を保持しているユーザーで実行してください。

 

手順概要

========

1. ソリューションを追加する

2. ソリューションを展開する

3. IIS (Internet Information Services) を再起動する

4. フィーチャーをアクティブ化する

 

それぞれの手順の詳細です。

 

1. ソリューションを追加する

----------

1-1 コマンド プロンプトを起動し、以下のコマンドを実行します。

 

pushd "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"

 

1-2. コマンド プロンプトより、以下のコマンドを実行します。

 

stsadm.exe -o addsolution -filename <solution filename>

stsadm.exe -o execadmsvcjobs

 

- 補足

<solution filename> にはソリューション パッケージファイル (*.wsp ファイル) の名前を指定してください。

.wsp ファイルはサーバー上のどこに配置していても問題ありません。例えば C ドライブ直下に配置している場合は以下のコマンドになります。

 

例 :

stsadm.exe -o addsolution -filename C:\WebPart1.wsp

stsadm.exe -o execadmsvcjobs

 

2. ソリューションを展開する

----------

2-1. コマンド プロンプトより、以下のコマンドを実行します。

 

stsadm.exe -o deploysolution -name <solution filename> -url <url> -immediate -allowgacdeployment -force

stsadm.exe -o execadmsvcjobs

 

- 補足

<solution filename> には作成したソリューションパッケージ ファイル (*.wsp ファイル) の名前を、<url> にはソリューションを展開したい仮想サーバーの URL を、それぞれ指定してください。

 

例 :

stsadm.exe -o deploysolution -name WebPart1.wsp -url http://MyServer/Sites/MySite -immediate -allowgacdeployment -force

stsadm.exe -o execadmsvcjobs

 

この手順は stsadm ではなく UI 上からも実施することができます。(手順１. のソリューションの追加だけは stsadm から実施する必要があります。)

サーバーの全体管理から、[サーバー構成の管理] タブ - [ソリューション管理] をクリック、該当の wsp ファイルをクリックして、[ソリューションの展開] をクリックします。

stsadm で指定しているコマンドと同じようなパラメータが表示されていますね。

 

 

 

 

3. IIS (Internet Information Services) を再起動する

----------

3-1. コマンド プロンプトより、以下のコマンドを実行します。

 

iisreset

 

なお、Web フロントエンド サーバーが複数ある場合は、それぞれのサーバーで実行してください。

 

4. フィーチャーをアクティブ化する

----------

4-1. コマンド プロンプトより、以下のコマンドを実行します。

 

stsadm.exe -o activatefeature -name <feature folder> -url <url>

 

- 補足

<feature folder> にはアクティブ化したいフィーチャーの名前を、<url> にはフィーチャーをアクティブ化したいサイトの URL を、それぞれ指定してください。

 

例 :

stsadm.exe -o activatefeature -name WebPart1 -url http://MyServer/Sites/MySite

 

もちろんこの手順も、UI 上から実施することが可能です。

展開先に指定したサイトへアクセスし、[サイトの操作] – [サイトの設定] – [すべてのサイト設定の変更] から、[サイト コレクションの機能] をクリックします。

該当のフィーチャーの [アクティブ化] ボタンをクリックし、手動でアクティブ化することができます。

(ご紹介した手順は、グループ作業ポータルのトップサイトに展開した場合を想定してますので、フィーチャーの内容やサイトの種類などにより若干操作の名称や内容が異なる場合があります。)

 

 

 

 

以上で展開手順は終了です。

次に、インストールしたものを削除する方法もご紹介しておきます。

 

ソリューションを削除する方法

****************************

手順はだいたい展開方法の逆になります。

展開時に UI で実施できた部分は削除時も UI から実施することができます。(手順は省略します。)

 

手順概要

========

1. フィーチャーを非アクティブ化する

2. ソリューションの展開を取り消す

3. IIS (Internet Information Services) を再起動する

4. ソリューションをファームから削除する

 

それぞれの手順の詳細です。

 

1. フィーチャーを非アクティブ化する

----------

1-1. コマンド プロンプトを起動し、以下のコマンドを実行します。

 

pushd "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"

 

1-2. コマンド プロンプトより、以下のコマンドを実行します。

 

stsadm.exe -o deactivatefeature -name <feature folder> -url <url>

 

- 補足

<feature folder> には非アクティブにしたいフィーチャーの名前を、<url> にはフィーチャーを非アクティブにしたいサイトの URL を、それぞれ指定してください。

また、この非アクティブ化は必ずアクティブ化を実施した全てのサイトで実施してください。この作業を実施せずにソリューションを取り消してしまうと、サイト内にゴミが残り予期せぬ現象を招く場合があります。

 

例 :

stsadm.exe -o activatefeature -name WebPart1 -url http://MyServer/Sites/MySite

 

2. ソリューションの展開を取り消す

----------

2-1. コマンド プロンプトより、以下のコマンドを実行します。

 

stsadm.exe -o retractsolution -name <solution filename> -url <url> -immediate

stsadm.exe -o execadmsvcjobs

 

- 補足

<solution filename> には展開を取り消したいソリューションパッケージ ファイル (*.wsp ファイル) の名前を、<url> にはソリューションの展開を取り消したい仮想サーバーの URL を、それぞれ指定してください。

 

例 :

stsadm.exe -o retractsolution -name WebPart1.wsp -url http://MyServer/Sites/MySite -immediate

stsadm.exe -o execadmsvcjobs

 

3. IIS (Internet Information Services) を再起動する

----------

3-1. コマンド プロンプトより、以下のコマンドを実行します。

 

iisreset

 

なお、Web フロントエンド サーバーが複数ある場合は、それぞれのサーバーでコマンドを実行してください。

 

4. ソリューションを削除する

----------

4-1. コマンド プロンプトより、以下のコマンドを実行します。

 

stsadm.exe -o deletesolution -name <solution filename>

stsadm.exe -o execadmsvcjobs

 

- 補足

<solution filename> には削除したいソリューションパッケージ ファイル (*.wsp ファイル) の名前をご指定ください。

 

例 :

stsadm.exe -o deletesolution -name WebPart1.wsp

stsadm.exe -o execadmsvcjobs

 

 

なお、ご紹介した stsadm 操作の詳細は、下記サイトに公開情報がありますので、こちらも合わせてご確認ください。

 

Activatefeature : Stsadm 操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc262692.aspx

 

Addsolution : Stsadm 操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc263162.aspx

 

Deactivatefeature : Stsadm の操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc262680.aspx

 

Deletesolution : Stsadm 操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc261929.aspx

 

Deploysolution : Stsadm 操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc262459.aspx

 

Execadmsvcjobs : Stsadm 操作 (Windows SharePoint Services)

http://technet.microsoft.com/ja-jp/library/cc288149.aspx

 

Retractsolution : Stsadm 操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc261799.aspx

 

次回も SharePoint 製品に関する有益な情報をご紹介していきますので、ご期待ください！

こんにちは。

SharePoint サポートチームのたらかわです。

 

実は、先月半ば頃から風邪を変な風にこじらせたらしく、咳が止まらなくて大変でした。ようやく咳が治まってきたと思ったら、今度は肋骨の左のほうがズキズキと痛むですよ。。病院に行ってみたら、何と肋骨が折れてました。(正確には疲労骨折といって軽くヒビが入っただけなのですが。) 自然治癒にまかせるしかないので、湿布を貼ってしのいでいるのですが、毎回くしゃみをするたびに悶絶している今日この頃です。

 

さて、先週は社内行事などで色々忙しかったので、あまり凝ったネタを提供できず申し訳ないのですが、今回はちょっとした小ネタをご紹介しましょう。

 

問題：増分クロールのスケジュールを 5 分おきに設定したときに、1 回のクロールに 5 分以上かかる環境だと次にスケジュールされたクロールはいったいどうなるのか？

 

A) クロールがもう一つ別スレッドで走る

B) そのスケジュールは無視される

C) そのスケジュールは待機キューに入れられ、直前のクロールが終わった後すぐに実行される

 

…答えは、「B) そのスケジュールは無視される」です。

無視されたスケジュールには申しわけないですが、同時に 2 つのクロールを実行してインデックスサーバーに負担をかけるよりも、現在クロール中の処理を早く終わらせることがのほうが重要です。

心配しなくても、現在進行中のクロールが完了すれば、次のスケジュールではちゃんとクロールが実行されます。

 

もう少しわかりやすく解説すると、次のような動作になります。

 

(5 分おきにクロールする設定の場合)

0:05 増分クロール A 開始

0:10 増分クロール B 開始…しようとしたけど、まだ前回のクロールが終わってないので今回はスキップ。

0:12 増分クロール A 完了

0:15 増分クロール C 開始

 

いかがでしょうか。

ちなみに、WSS 3.0 で使用される Windows SharePoint Server Search サービスでは、スキップされたクロールの心の叫びが診断ログに残ります。(補足：Office SharePoint Server Search では残らないようです。)

例えば、上記の状況では、以下のようなメッセージが診断ログに残ります。

 

------------------------------------------

07/15/2009 00:10:00.00   OWSTIMER.EXE (0x0758)   0x07BC  Search Server Common   MS Search Administration   8ijm  Verbose   WSS Search: Skipping start address cleanup phase because the default content source is not idle (status = CRAWLING_INCREMENTALLY).

------------------------------------------

 

「既定のコンテンツ ソースがアイドルではないため、開始アドレスのクリーン アップ処理 (クロール開始時の処理) がスキップされました。(ステータス = 増分クロール中)」と書いてありますね。

 

つまり要約すると、「あ、私、お邪魔みたいだから帰るね。ごめんね、なんか、余計なお世話だったよね。あとは 2 人で楽しんで！ (その帰り道) …あはは、私一人で空回りしちゃって、馬鹿みたい。…さようなら。」的なドラマが繰り広げられているというわけですな。

 

…切ない。

 

男として、ここで甲斐性を見せて 2 つのクロールを同時進行させたいところですが、現実はそう甘くは無く、現在進行中のクロールを維持するだけでインデックス サーバーのキャパは一杯なわけです。下手に小細工しようものなら、その場は修羅場と化し、何とか器用にその場を取り繕ったとしても、クロールって意外とリソース要求されるわけで、色々やっているうちにいずれはボロがでて、後々大変なことになるわけですよ。…あ、あくまでクロールの話ですよ、もちろん！

 

…あ、あれ？何の話してましたっけ？

ま…まぁ、そういうわけですので、ことクロールにおいて、MOSS 2007/WSS 3.0 は「誠実な動作をする」ということを覚えておきましょう。

 

- 補足

上述の診断ログは既定の設定では記録されません。

WSS 3.0 の Windows SharePoint Server Search サービスでクロールがスキップされたことを確認するには、以下の手順にて、診断ログの設定を変更する必要があります。

診断ログの設定を変えると、ログのサイズが予想以上に大きくなったりしますので、トラブルシュートなどの特別な目的がなければ、既定の設定でお使いいただくことをお勧めします。

 

<診断ログの設定変更手順>

1) サーバーの全体管理サイトにアクセスします。

2) [サーバー構成の管理] をクリックします。

3) [ログおよびレポートの作成] セクションの [診断ログ] をクリックします。

4) [記録されるイベントの設定] セクションで以下のように設定します。

   カテゴリの選択：MS 検索管理

   トレース ログの記録対象となる重要度の最も低いイベント：詳細 (既定では「中」になっています。)

 

 

5) [OK] をクリックして変更を保存します。

 

 

by たらかわ＠経験者は語る

こんにちは。

SharePoint サポートチームの多田です。

 

今回は、Microsoft Office SharePoint Server 2007 の Standard Edition のみで発生する現象についてご案内したいと思います。

MOSS 2007 では Active Directory からユーザーのプロファイルやグループのメンバシップ情報をインポートできる機能があります。MOSS 2007 Standard Edition では、このプロファイルのインポート実行時にインデックスサーバー上にイベントエラー 7888 が記録されることが報告されております。

MOSS 2007 Standard Edition では、プロファイルのインポート時に、このイベント エラー 7888 が記録されても動作上問題なく、実障害も報告されておりません。

エラーが表示されること自体、製品の問題として認識していますが、ひとまずご安心ください。

同じイベント エラー 7888 でも内容によっては、まったく異なる原因で発生している場合もありますので、念のため、後述のイベント エラー 7888 の出力例を見てくださいね。

 

イベント エラー 7888 の出力例

MOSS 2007 Standard Edition ではプロファイルのインポート時に、以下のようなイベントエラー 7888 が出力されます。2 パターンあるので、見比べてください。

 

--- イベントエラー 7888 (パターン 1) ---

イベントの種類: エラー

イベント ソース: Office SharePoint Server

イベント カテゴリ: (1516)

イベント ID: 7888

説明:

ランタイム例外が検出されました。詳細は次のとおりです。

メッセージ: ストアド プロシージャ 'proc_ar_BumpCacheInvalidationCounter' が見つかりませんでした。

 

詳細:

System.Data.SqlClient.SqlException: ストアド プロシージャ 'proc_ar_BumpCacheInvalidationCounter' が見つかりませんでした。

場所 System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)

場所 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)

場所 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)

場所 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)

場所 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)

場所 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)

場所 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)

場所 System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)

場所 System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

場所 Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)

場所 Microsoft.Office.Server.ApplicationRegistry.MetadataModel.DataAccess.AbstractMaterializer.DistributedCacheInvalidate(Type metadataObjectType, Boolean objectCache)

場所 Microsoft.Office.Server.ApplicationRegistry.MetadataModel.DataAccess.AbstractMaterializer.DistributedCacheInvalidate()

場所 Microsoft.Office.Server.ApplicationRegistry.Infrastructure.SqlSessionProvider.SetSharedResourceProviderToUse(String sharedResourceProviderName)

場所 Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)

--- ここまで ---

 

--- イベントエラー 7888 (パターン 2) ---

イベントの種類: エラー

イベント ソース: Office SharePoint Server

イベント カテゴリ: Office Server 全般

イベント ID: 7888

説明:

ランタイム例外が検出されました。詳細は次のとおりです。

メッセージ: オブジェクト名 'AR_CacheCounters' が無効です。

EXECUTE 後のトランザクション数は、COMMIT TRANSACTION または ROLLBACK TRANSACTION ステートメントがないことを示しています。以前の数 = 0、現在の数 = 1。

 

詳細:

System.Data.SqlClient.SqlException: オブジェクト名 'AR_CacheCounters' が無効です。

EXECUTE 後のトランザクション数は、COMMIT TRANSACTION または ROLLBACK TRANSACTION ステートメントがないことを示しています。以前の数 = 0、現在の数 = 1。

場所 System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)

場所 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)

場所 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)

場所 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)

場所 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)

場所 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)

場所 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)

場所 System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)

場所 System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

場所 Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)

場所 Microsoft.Office.Server.ApplicationRegistry.MetadataModel.DataAccess.AbstractMaterializer.DistributedCacheInvalidate(Type metadataObjectType, Boolean objectCache)

場所 Microsoft.Office.Server.ApplicationRegistry.MetadataModel.DataAccess.AbstractMaterializer.DistributedCacheInvalidate()

場所 Microsoft.Office.Server.ApplicationRegistry.Infrastructure.SqlSessionProvider.SetSharedResourceProviderToUse(String sharedResourceProviderName)

場所 Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)

--- ここまで ---

 

イベント エラー 7888 が出力される理由

MOSS 2007 Standard Edition にてプロファイルのインポート時に出力されるイベントエラー 7888 について大体理解していただけましたでしょうか？

「イベント エラー 7888 についてもう少し詳しく知りたい！」という方は以下をご覧ください。

 

パターン 1 のイベント エラー 7888 のエラー内容を見ると、"ストアド プロシージャ 'proc_ar_BumpCacheInvalidationCounter' が見つかりませんでした。" というメッセージが表示されていることがわかりますね。これは、メッセージの通り、MOSS 2007 Standard Edition にはストアド プロシージャ 'proc_ar_BumpCacheInvalidationCounter' がインストールされていないために、このメッセージが表示されています。MOSS 2007 Enterprise Edition ではストアド プロシージャ 'proc_ar_BumpCacheInvalidationCounter' がインストールされているため、このイベント エラー 7888 は発生しません。

このストアド プロシージャ 'proc_ar_BumpCacheInvalidationCounter' がどのような動作をしているかについては、以下の資料 (32 ページ) に記載されています。英語の資料ですが、MOSS 2007 の内部動作について詳しく説明がされているのでご興味がある方はぜひ目を通してください。

 

タイトル : Business Data Catalog Database Protocol Specification

アドレス : http://download.microsoft.com/download/8/5/8/858f2155-d48d-4c68-9205-29460fd7698f/[MS-BDCSP].pdf

 

パターン 2 のイベント エラー 7888 のエラー内容を見ると、"オブジェクト名 'AR_CacheCounters' が無効です。" というメッセージが表示されています。こちらも MOSS 2007 Standard Edition にオブジェクト 'AR_CacheCounters' がインストールされていないため、に、このメッセージが表示されています。同じくMOSS 2007 Enterprise Edition ではオブジェクト 'AR_CacheCounters' がインストールされているため、イベント エラー 7888 は発生しません。MOSS 2007 は、データベースと通信する際、キャッシュ処理を行っており、一部のキャッシュ処理に対し、オブジェクト カウンタを AR_CacheCounters に記録する処理を行っております。この機能は、MOSS 2007 Standard Edition には、搭載されていません。

 

 

この情報はお役に立てましたでしょうか？

ご意見、ご感想等がございましたら本ブログのメニューバーの "EMAIL" フォームにてご連絡をお待ちしております。

MOSS 2007 では先日 SP2 がリリースされたこともあり、お客様の声を取り入れ、ますます使いやすい製品になってきています。今後とも SharePoint 製品をよろしくお願いします。

どうもこんにちは。
SharePoint サポートチームの伊沼です。

人生初のブログ公開になります。
芸能人のブログなどを参考にしつつこそこそ書いてます。どうぞお付き合いくださいませ。

今回のネタについてですが、前回多田さんがユーザープロファイルに関する記事を書いていたので、私も便乗してユーザー プロファイル関連のネタを考えてみました。今回はイベントエラーについてではなく、MOSS のユーザー プロファイルとは・・？というところから、ちょっとした注意点まで、思いつくままに書いてみようと思います。技術レベル的にあまり高度なことはご紹介しませんので、モスラーのかたにはあまり面白い記事ではないかもしれませんが、モスナー (MOSS ビギナー) のかたにとっては有効な情報になるかと思いますので、ご参照いただければ幸いです。

MOSS のユーザー プロファイルとは・・・

まず、MOSS のユーザー プロファイルとは、一言で言うと、よくある 「プロフ」 みたいなものと考えていただければわかりやすいかと思います。ユーザー プロファイルでは、同じ SharePoint サイトを使っているメンバーのさまざまなユーザー情報 (どこの部署の人なのか、どんなスキルを持っているのか、どんな顔をしているのか、えらい人なのか、同じチームにはどんな人がいるのか、自分との共通点は何か、、、などなど)　を管理でき、SharePoint にアクセスできるユーザーは、他のユーザーのプロファイルを参照したり、プロファイルの情報をもとに他のユーザーを検索したりすることができます。ユーザー プロファイルも MOSS で管理される情報の一部なので、データはもちろん SQL Server 上で管理されます。

では、このユーザー プロファイルを MOSS でどのように作成するかというと、これには 2 つの方法があります。1 つは、各ユーザーのユーザー プロファイルを1 件 1 件手動で登録していく方法です。これは単純ですが、規模が大きい MOSS 環境では非常に地味で膨大な作業になります。でもう 1 つは、AD からユーザーを一括でインポートする方法です。この方法は管理者にとって非常に簡単で単純な作業でできます。たとえば、MOSS が所属するドメインの全ユーザーをインポートしたいのであれば、共有サービス プロバイダの [ユーザー プロファイルとプロパティ] ページから [フルインポートの開始] をクリックするだけで、最大 500 万のドメイン ユーザーを MOSS にインポートすることができます。インポートのスケジューリングを設定しておくこともできるので、AD 上にユーザーが追加された場合にも、スケジュールされたインポートジョブによって、何も考えずとも自動でプロファイルが作成されていくわけです。とても便利ですよね～。

インポートされたプロファイルは、AD の属性にはない、MOSS だけのプロパティを登録して、個人でカスタマイズすることができます。

たとえば、自分の顔写真を登録することができます。自分の顔写真を普段大事に持っている人は、その写真を自分のプロパティとして登録することで、自分の姿を社内の SharePoint ユーザーにアピールすることもできます。

 

 

それでは、上の画面に表示されている [犬] クンをサンプル ユーザーとして、以降ではユーザー プロファイルの用途についてご紹介します。

 

1.    個人用サイト

個人用サイトで表示されるユーザーの情報は、ユーザープロファイルの情報をもとに表示が行われます。以下はまだ詳細なプロファイル情報が登録されていない状態ですが、個人用サイトはこのようなページです。

 

 

個人用サイトでは、自分のプロファイル情報を編集できます。個人用サイトは [自分用ホーム] と [自分用プロファイル] のページがあり、編集したプロファイル情報は、[自分用プロファイル] タブをクリックすることで表示されます。 [自分用ホーム] のページでは、個人用のドキュメントなどを保管したり、新たな個人用のサブサイトを作成したりすることができます。プロファイルの編集は、[自分用ホーム]、[自分用プロファイル] のどちらからでも [詳細] をクリックすることで編集できます。
別のユーザーが自分の個人用サイトにアクセスした場合にも [自分用プロファイル] のページが表示されるため、自分のプロファイル情報がこのページで別のユーザーに公開されることになります。

 個人用サイトは各ユーザーが個々に作成することができ、作成された個人用サイトは、SharePoint としてはひとつのサイト コレクションと同じ扱いになります。個人用サイトは通常サイトでページ右上に表示される [個人用サイト] を初めてクリックしたときに、自動的に作成されます。なお、通常の (チームサイトなどの) サイト コレクションを作成する際、サイト コレクションの管理者を指定する必要がありますが、個人用サイトの場合、個人用サイトを作成した各ユーザー自身がサイト コレクションの管理者になります。

 (余談ここから) 各ユーザーはサイト コレクションの管理者になるため、自分の個人用サイトに対して、あんなことやこんなことなど、、、とにかくいろいろできてしまうわけです。ここで考慮しないといけないのが、個人用サイトで使用する領域の増加です。個人用サイトといえど、SharePoint からすれば一つのサイト コレクションと同じ扱いになるため、個人用サイトに登録したドキュメントなどのデータは、SQL Server に登録されます。たとえば SharePoint を使うユーザーが 1 万ユーザーいて、各ユーザーが個人用サイトに 1 GB のデータを登録すると仮定すると、トータルで 10 TB もの容量が必要になります。こうなると重要なチームサイトなどのデータを保管するための領域がなくなってしまう可能性も出てきますね。そんな時は、個人用サイトをホストする Web アプリケーションでクォータを設定すると効果的です。ユーザー プロファイルから話がだいぶそれてきてしまっているので、クォータについては技術情報の紹介にとどめておきます。

クォータ テンプレートを作成する (Office SharePoint Server)
http://technet.microsoft.com/ja-jp/library/cc263223.aspx

クォータを管理する (Office SharePoint Server)
http://technet.microsoft.com/ja-jp/library/cc891489.aspx

Windows SharePoint Services 内のテンプレートのクォータ値を変更した後、既存のサイトのクォータ値は変更されません。
http://support.microsoft.com/kb/905230/ja
(余談ここまで)

2.    人の検索
プロファイルをインポートしたり、作成したりしておくと、検索センターで人の検索が実行できます (実際に検索にヒットさせるためには、sps3://・・・ の開始アドレスに対する事前のクロールが必要になります) 。検索結果に表示された人のリンクをクリックすると、個人用サイトにジャンプします。プロファイルが作成されていないユーザーは、この検索結果に表示されません。 

ちなみに、人の検索を行う際、以下のように詳細な条件を設定して検索することもできます。検索センターの [人] タブをクリックすると、条件設定ができるページが表示されます。これらの条件として指定できるプロパティは、ユーザー プロファイルのプロパティと紐づいていますので、プロパティをプロファイルにちゃんと登録しておけば、いろいろな検索条件で人を検索することができるようになるわけです。

その他の注意点について

ユーザー プロファイルの使い方について簡単にご紹介しましたが、ここで一点注意しなければならない点をご紹介します。
ユーザー プロファイルはあくまでも「プロフ」 のような扱いでなので、SharePoint サイトにアクセスする際の認証情報として利用されるものではありません。モスナー (MOSS ビギナー (しつこいですね)) のかたは、ユーザー プロファイルを認証に必要なアカウント情報と勘違いされる傾向がありますが、そうではありません。「ユーザー プロファイルが MOSS にインポートされているから MOSS サイトにアクセスできる」 ということはありませんし、逆に「ユーザー プロファイルが MOSS にインポートされていないアカウントは MOSS にアクセスできない」 ということもありません。
ここで認証に関する詳しい動作についてはお伝えしませんが、ドメイン環境で稼動している MOSS サーバーに対してWindows 認証が必要なサイトにクライアントからアクセスする場合、AD のアカウント情報により認証が行われます。
また、アクセスしようとしているユーザーが、サイト自体にアクセス権を持っていなければアクセスできないので、アクセスしようとしているサイトに対する権限も事前に設定しておく必要があります。たとえば以下のように設定すれば、[犬] クンはサイトに対してアクセスすることができます。

今回はユーザー プロファイルに関する使い方を簡単にご紹介しましたが、ユーザープロファイルはもっと奥深い部分もたくさんありますので、(機会があれば) より突っ込んだ話をこのブログでご紹介していこうと思います。

大雨の日が多いので、皆様、お体には十分お気をつけください。それではまた。

こんにちは。

SharePoint サポートチームのたらかわです。

 

最近、ユーザー プロファイル関連のネタが続いているようなので、たまには違うネタでもやろうかと思ったのですが、残念ながら仕事の合間に粛々と書き溜めておいたネタが前回、前々回に引き続きユーザー プロファイルと微妙に関連するサイトのユーザー情報に関するネタでございました。

お蔵入りにするのももったいないので、このまま公開することにしました。次回は他のネタを用意していますので、勘弁してください。

 

問題：

MOSS 2007 ユーザーの毛須花子さんは、このたび晴れて舞黒太郎さんと結婚することになりました。これに伴い、花子さんの AD ユーザー名が組織の命名規則に従い mosuh から maikuroh に変更になります。組織では、ユーザー名が変更される場合、新しいユーザー ID を発行する決まりとなっています。このため、花子さんのために新しい AD ユーザー maikuroh が作成されました。

花子さんは、社内の MOSS 2007 サイトにおいて、以前と同じ個人用設定や、サイトやリストのアクセス権を使い続けたいと考えています。

最小限の管理タスクで花子さんの希望を満たすソリューションを選択してください。

 

と、いきなり MCP チックな問題文を書いてしまいましたが、要は、「サイトのユーザー情報は残したまま、ユーザーの個人用設定やコンテンツのアクセス権を引き継いで、サイトのユーザーに紐づいた AD ユーザーだけ変えたい」ということです。

 

一般的にユーザー ID が変わるシナリオとして、以下のことが考えられます。

 

・結婚や部署移動によりユーザー名が変わった

・ドメイン移行によりユーザーが所属するドメインが変わった

・新しい自分に生まれ変わりたくなった

 

…最後のは一般的ではないかもしれませんが、自分はよくこのような衝動に駆られるので、一般的ということにしておきましょう。

 

余談ですが、たらかわは子供の頃、当時人気があった某 RPG ゲームの主人公に自分の名前を、ヒロインの名前に何を思ったか好きな女子の名前を付けてしまったことがあります。その後、我に返り、このままだと家に友達を呼べないことに気付き、必死に名前を変えようとしたのですが、残念ながらそのゲームのシステムには、キャラクターのリネームという機能は実装されておらず、泣く泣くそのセーブデータを消去したという甘酸っぱくも切ない思い出があります。そんな話はどうでもいいですか。そうですか。

 

さすがに、AD のユーザー名に好きな女子の名前を入れて感情移入しようなどという極めて斬新な使い方をするユーザーはごく少数だと思いますが、処々の事情により AD のユーザー名を変更する必要が出てくることもあるでしょう。

 

ご安心ください。

 

MOSS 2007/WSS 3.0 には、サイトのユーザー情報は残したまま、ユーザーの個人用設定やコンテンツのアクセス権を引き継いで、サイトのユーザーに紐づいた AD ユーザーだけ変える夢のような機能が実装されています！！

MOSS 2007/WSS 3.0 でサイトのユーザー情報に関連づいた AD ユーザーを変更するには "Migrateuser" Stsadm 操作を使用します。

 

Migrateuser : Stsadm 操作 (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc262141.aspx

 

Migrateuser : Stsadm 操作 (Windows SharePoint Services)

http://technet.microsoft.com/ja-jp/library/cc288467.aspx

 

"Migrateuser" Stsadm 操作は、ドメインの移行に伴いユーザー情報を移行する時や、検証環境から運用環境への移行時に任意のユーザーに一括でサイトのユーザー情報を移行する場合など、環境の移行シナリオでよく使用されます。"Migrateuser" Stsadm 操作では、ユーザーのログイン ID をもとに、コンテンツ データベースの UserInfo テーブル (※1 おまけ参照) の情報を書き換えるので、すべてのサイトコレクションに関連づいたユーザー情報を一括で変更できるのです。

 

では、実際に使ってみましょう。

 

1. CONTOSO ドメインに "tarakawa" というユーザーを作りました。

 

 

 

 

2. 適当なサイトに contoso\tarakawa のアクセス権を付けて、contoso\tarakawa でサイトにログインしましょう。問題なくログインできますね。

 

 

 

 

3. 個人用サイトを作っちゃいましょう。秘蔵のコレクションをこっそり個人用ライブラリにアップロードします。

 

 

 

4. あ、あ、いつもの衝動が！！う、生まれ変わりたい！！！

 

5. システム管理者にお願いして別の新しい AD のユーザーを作ってもらいました。映画俳優のジョニー・デップさんみたいにカッコよくなりたいので、これからは contoso\JohnnyD でいきます。これでハリウッド進出間違いなしです。

 

 

 

6. もう一度、contoso\JohnnyD でサイトにログインしましょう。残念ながら生まれ変わってません。「お前なんか知らねー」って言われてしまいました。。。頑張っておめかししたつもりでしたが、どうやら「似ても似つかない」とジャッジされてしまったようです。切ないですね。

 

 

 

7. いくら望んでも、遺伝子レベルで差がありすぎるものはどうしようもありません。仕方がないので黒魔術に頼るとしましょう。今までの非道な行いを悔い改めて、コマンド プロンプトを起動して以下のコマンドを実行します。

   cd %commonprogramfiles%\Microsoft Shared\Web server extensions\12\Bin

 

8. 次に、以下のコマンドを実行します。今回は、移行先のユーザー アカウントに Sid 履歴が含まれていないので migrateuser 操作に ignoresidhistory パラメータを付けます。(※2 おまけ参照)

   stsadm -o migrateuser -oldlogin contoso\tarakawa -newlogin contoso\JohnnyD –ignoresidhistory

 

9. これで転生の儀式は完了です。

 

 

 

10. 再び、contoso\JohnnyDでサイトにログインしましょう。アクセスできました。個人用サイトの秘蔵のコレクションも無事ですね。表示名が昔のままなのは後でどうにかするとして (※3 おまけ参照)、とりあえずは無事に転生できたようです。悪魔に魂を売った甲斐がありました。

 

 

 

11. 以後、上記コマンドを実行することで、「GeorgeC」「BradP」「TomC」など、状況に応じて適宜生まれ変わることが可能です。

 

いかがでしょうか。

上記コマンドを利用すれば、WSS 3.0 でもユーザーの表示名を変更することができます。

皆さんも生まれ変わりたくなったら、サーバーのローカル管理者権限とファームの管理者権限を取得して、気軽に "Migrateuser" Stsadm 操作を実行してみてくださいね♪

 

- おまけ

(※1) UserInfo テーブルって何？

サイトのユーザー情報は、各コンテンツデータベースの UserInfo テーブルに格納されています。ユーザー情報はサイト コレクションごとに持っているのですが、実際には、サイトコレクションの ID 情報とともに、コンテンツ データベース内の 1 つのテーブルに格納されて管理されているんですね。興味があれば、検証環境でコンテンツデータベースの中を覗いてみてください。UserInfo テーブルにはユーザーの ID、表示名の他にも、色んな情報が確認できます。UserInfo テーブルの各カラムの用途については、以下の公開仕様書が参考になるかと思います。

 

2.2.7.10 UserInfo Table

http://msdn.microsoft.com/en-us/library/dd303914(PROT.13).aspx

 

注：SharePoint 関連データベースを興味で覗くのは自由ですが、直接変更することはマイクロソフトでサポートされていないのでご注意ください。マイクロソフトでは、SharePoint 製品とテクノロジで使用されるデータベースを直接変更したことで生じる問題をサポートしていません。

 

(※2) ignoresidhistory パラメータはどんな時に付けるの？

"Migrateuser" Stsadm 操作の ignoresidhistory パラメータは、新しいユーザーの SID 履歴のメタ データが古いユーザーの名前と一致するかどうかチェックしたくない時に使います。

ignoresidhistory パラメータを付けない場合、移行元のユーザーの SID が移行先ユーザーの SID 履歴に含まれるかチェックされ、含まれない場合はエラーを返します。これにより、Active Directory 移行ツール (ADMT) を使い、ドメイン間でユーザーを移行した場合などに、SharePoint サイトのユーザー情報が誤ったユーザーに移行されることを防ぐことができます。(contoso\tarakawa を fabrikam\tarakawa に移行すべきところを、fabrikam\tatakawa に移行してしまう等。tatakawa さんにとってはいい迷惑。。)

 

逆に、フォレスト間でユーザーを移行して Sid 履歴を保持していない状況や、今回のように Sid 履歴を含まないユーザー ID に移行することが目的の場合には、ignoresidhistory パラメータを付けないと「新しいユーザーアカウントには、有効な SID 履歴データがありません。」というエラーで失敗してしまうので、このような場合は敢えて付けるのです。

 

このあたりの情報は、以下の資料に記載されているので、興味があればご参照ください。

 

5.2.4 Updating the Site Collection local user record (aka Account Migration)

http://msdn.microsoft.com/en-us/library/dd341297(PROT.13).aspx

 

(※3) ユーザーの表示名はどうしたらいいの？

"Migrateuser" Stsadm 操作で SharePoint ユーザーを移行した場合、ユーザー プロファイルの情報やサイトのユーザー情報は以前のユーザーの情報を引き継ぎますので、必要に応じて変更します。MOSS 2007 の場合は、プロファイルのインポートをして 1 時間程度待てば、「プロファイルの同期」タイマジョブによりすべてのコンテンツ データベースのユーザー情報が自動的に更新されます。

 

SharePoint タイマ ジョブ リファレンス (Office SharePoint Server)

http://technet.microsoft.com/ja-jp/library/cc678870.aspx

--- 参考箇所の抜粋 ---

プロファイルの同期

コンテンツ データベースのユーザー情報を、ユーザー プロファイル データから同期します。

毎時

------

 

WSS 3.0 の場合は、ちょいと面倒ですが、以下の手順により手動でユーザー情報を更新します。

 

<手順>

1) 表示名を変更したいユーザーでサイトにアクセスして、右上の「ようこそ○○さん」プルダウン メニューから [個人用設定] を選択します。

2) [ユーザー情報：<ユーザー名>] ページで [アイテムの編集] メニューをクリックします。

3) ユーザーの [名前] プロパティの値を手動で変更して [OK] をクリックします。

 

 

by たらかわ＠死んだら地獄行き

こんにちは。

SharePoint サポートチームの伊沼です。

 

タイトルにある「診断ログ (別名: ULS (Unified Logging Service) ログ) 」ですが、おもに SharePoint 上で何らかのトラブルが起きた際、現象の解析を行うために使われるテキスト ベースのログ ファイルです。

既定では SharePoint サーバー上の以下の場所に保存されています。

 

 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS

 

今回はこの診断ログにまつわる現象の一つとして、診断ログが記録されなくなる現象についてご紹介します。診断ログは、SharePoint で障害が発生したとき、トラブルシュートを行うために非常に有効な情報であり、サポートにお問い合わせいただく際には、現象の解析のために必ずと言っていいほど必要になる代物ですので、タイトルを見て「ログについての記事か、、、つまらなそうだから読み飛ばそ。」なんて思う気持ちを是非押さえていただいて、最後までお付き合いいただければ幸いです。

 

具体的な現象について

診断ログが出力されない現象は、細かく分類すると 2 つの現象があります。2 つの現象では、実際の影響度が大きく異なりますが、どちらにも共通して言えるのは、診断ログに以下のようなログが記録されることです。

 

Tracing Service lost trace events. Current value 3.

 

この記録は、本来診断ログに記録されるべき何らかの情報が記録できなかったことを示しています。

この記録がされる現象の 2 つのうち 1 つめは、サーバーの負荷状況などにより、上記のログがまれに記録されるが、その後また正常に記録が開始される場合です。この記録は MOSS, WSS の通常運用中でもよく見られるログですが、一時的なものですので、これによる影響はさほど大きくありません。

 

2 つめは、上記の Lost Tarce Events のログが記録された以降、本来出力されるべきログが一切記録されなくなる現象が発生する場合があります。具体的には、以下のような記録が延々と記録されます。

 

XX/XX/XXXX XX:XX:XX.XX wsstracing.exe (0x0560) 0x0160 ULS Logging Unified Logging Service uls1 Monitorable Tracing Service lost trace events. Current value 3.

XX/XX/XXXX XX:XX:XX.XX wsstracing.exe (0x0560) 0x0160 ULS Logging Unified Logging Service uls1 Monitorable Tracing Service lost trace events. Current value 6.

XX/XX/XXXX XX:XX:XX.XX wsstracing.exe (0x0560) 0x0160 ULS Logging Unified Logging Service uls1 Monitorable Tracing Service lost trace events. Current value 2.

・・・・

 

この状態になると、上記の Tracing Service lost trace events が記録されるだけで、どれだけ待ってもまともなログが記録されない状況になります。こんな状態では何か問題があった時にログから原因調査ができなくなってしまいますね。以降ではこの 2 つ目の現象について詳細をご紹介したいとおもいます。

 

現象が発生する条件について

まず初めにお断りしておかなければならないのは、診断ログが記録されなくなる現象が発生する明確な条件はありません。つまり、ある対策を事前に実施しておけばこの現象を防げる、、というような明確な対処方法はありません。しかし、以下にあげる項目に多く該当する場合には、この現象が発生する可能性が高くなることが確認されています。

 

・クロールなどの大量のログが出力されるような処理が行われている

・診断ログが大量に出力されるように設定が変更されている

・サーバーのスペックが弱い

 

未然の抑制方法について

上述から、この現象をできるだけ未然に抑制するためには、以下の対処方法が有効です。

 

・クロールやプロファイルのインポートなどのスケジュールを見直す (処理が重複しないようにうまい具合にスケジューリングする)

・診断ログの出力レベルを適切に設定する (具体的な方法は http://technet.microsoft.com/ja-jp/library/cc288649.aspx 参照)

・サーバー スペックをパワーアップする

 

ただし、これらを実施した場合にも、状況によっては現象が起きる可能性はあります。診断ログが記録されなくなった現象が起こったことはイベントログにも記録されないため、何か他のトラブルが起きたタイミングで診断ログを見たときに、「あり？何も記録されてない！！」という事態にならないように、診断ログがちゃんと出力されているかどうかを定期的にチェックすることをお勧めします。この現象が起きたときには診断ログのファイル サイズが極端に小さくなるので、診断ログのファイルの中身をいちいち確認するのが面倒な方は、ファイルサイズからでもある程度の判断はできます。

 

現象発生後の対処方法について

じゃあ実際に診断ログが出力されなくなってしまったらどうしたらいいの？と思われたかた、ご安心ください。診断ログは、Windows SharePoint Services Tracing (SPTrace) サービスという独立したサービスで出力処理が行われており、このサービスを再起動することで対処することができます。

 

<手順>

1.     MOSS サーバー上でコマンド プロンプトを起動します。

2.     net stop SPTrace と入力して Enter キーを押します。

3.     net start SPTrace と入力して Enter キーを押します。

 

これで SPTrace が再起動されます (※補足) ので、正常にログが記録され始めるはずです。

 

補足

診断ログの出力処理が行われている最中に SPTrace サービスを停止すると、停止のタイミングにより、サービスが停止が正常にできずにハングしてしまう現象が報告されています。この現象が発生した場合には、サーバーの再起動を行っていただくことで対処することができますが、SPTrace サービス停止前に SharePoint 関連のサービスを以下の手順で停止することで診断ログの書き込み処理が行われなくなるため、SPTrace 停止時にハングは起きません。ただし、この手順では W3SVC (World Wide Web Publishing Service) サービスを停止するため、SharePoint サイトへのアクセスができなくなるので注意が必要です。

 

net stop DCLoadBalancer /y

net stop DCLauncher /y

net stop SPTimerV3 /y

net stop OSearch /y

net stop SPSearch /y

net stop W3SVC /y

net stop IISAdmin /y

net stop SPWriter /y

net stop SPTrace /y

net stop SPAdmin /y

 

詳細については以下のサポート技術情報をご覧ください。

 

Windows Server 2003 stops responding (hangs) during a shutdown if SharePoint Services Tracing is enabled

http://support.microsoft.com/kb/971067

 

<関連記事>

第 1 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 1) 第 2 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 2) 第 3 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 3)

 

こんにちは。

SharePoint サポートチームの荒川です。

 

今回は、「MOSS 2007/WSS 3.0 のソフトウェア更新プログラム」に関して詳しく解説したいと思います。

製品を健全に運用していくなかで、切っても切り離せない関係にある更新プログラムですが、意外とややこしく、毎回苦労している方も多いのではないでしょうか。

たらかわがサポート業務に携わるなかで、よく耳にする疑問や、意外と知られていない情報などを以下にまとめてみましたので、参考になれば幸いです。

 

なお、今回は情報量が多いので、全部で 3 回に分けてシリーズ連載とします。当ブログ初のシリーズ連載ということで、少し気合を入れて記事を書いてますので、どうぞご期待ください。

 

CU って何？

CU (Cumulative Update) とは、約 2 ヶ月に 1 回のタイミングで公開される「累積的な更新プログラム」のことです。

 

現在、Microsoft Office 製品の修正プログラムの配信方法は、従来の優先度による修正プログラム配信モデルから定期配信モデルに移行しています。最初に CU がリリースされたのは、昨年 (2008 年) の 8 月で、現在の定期配信モデルに完全に移行したのは、昨年の 12 月のことですので、一般的には、まだ馴染みが浅いかもしれません。

 

以前は、不定期に Hotfix と呼ばれる修正プログラムがリリースされていたのですが、修正プログラムがいつ公開されるかわからない状況では、ユーザーが適用作業のスケジュールを立てづらく、公開後すぐに適用することが難しいといった問題がありました。そこで、マイクロソフトでは、ソフトウェア更新プログラムの予測可能な配信サイクルをユーザーに提示し、MOSS 2007/WSS 3.0 のソフトウェア更新プログラムのインストールの管理を容易にするために、修正プログラムの配信方法を現在の定期配信モデルに変更しました。

 

COD って何？

上述において、CU の配信サイクルが 2 ヶ月に 1 度であることを述べましたが、もちろん、絶対に 2 ヶ月間修正プログラムをリリースしないかというとそうではなく、製品の問題によってユーザーの通常業務が妨げられている場合や、有効な解決策がない場合などの緊急事態には、CU の配信サイクルに関係なく必要に応じて個別の修正プログラムを提供します。このような修正プログラムは「重要なオンデマンド修正プログラム (COD)」と呼ばれます。

 

CU、COD はとりあえず適用しておけばよいの？

CU、COD は「とりあえず」適用するものではありません。

CU、COD は広範囲にわたってテストされておらず、CU、COD の適用により特定の問題が回避できたとしても、別の問題が発生するリスクが少なからずあります。このため、マイクロソフトでは、CU、COD を適用する前に、その修正が本当に必要か検討し、代替案で対応できるものであれば、次期サービスパックの提供を待つことを推奨しています。

 

補足：CU や COD を入手したことがある方はご存知かもしれませんが、これらの修正プログラムは、マイクロソフトサイト上のリンクから、直接ダウンロードすることはできません。サポート技術情報の上部のリンクより、Hotfix Online Submission を経由して、個別にダウンロード用の URL を自身のメールアドレス宛てに発送する手続きを行い、ダウンロード用のパスワードを使用して入手する必要があります。何故このような面倒な手続きを取らなければならないかというと、CU、COD はマイクロソフトによる完全なテストが行なわれていないため一般的には公開されていない修正プログラムという位置付けにあるためです。

 

詳しくは、以下の以下のサイトで確認できますので、今後 CU、COD の適用を検討される方はご参考ください。

Hotfix Online Submission – 修正プログラムの入手に関するご案内とご注意 http://support.microsoft.com/gp/HotfixNotice

 

セキュリティ関連の修正プログラムと CU の違いって何？

セキュリティ関連の修正プログラムは、マイクロソフトから適用を推奨しているものですので、CU、COD と違い、マイクロソフト サイト上のリンクから、直接ダウンロードできます。これらの修正プログラムは「パブリック更新プログラム」と呼ばれ、CU の配信サイクルに関係なく必要に応じて配信されます。パブリック更新プログラムの別の例として Service Pack があります。

 

いまさらだけど、Service Pack って何？

Service Pack とは、すべての修正プログラム、セキュリティ更新プログラム、重要な更新プログラム、更新プログラム、および製品のリリース後に社内で発見された問題の追加修正を含む、テスト済みの累積的なセットです。また、Service Pack には、一部のユーザーから要望のあった仕様の変更や機能が含まれる場合もあります。

 

Service Pack は適用したほうがよいの？

Service Pack は適用したほうがよいです。Service Pack には、既知の問題に対する修正に加え、セキュリティの向上、パフォーマンスの向上、新機能の追加など、様々な改善が含まれますので、Service Pack を適用することで、製品の能力を最大限に引き出すことができます。また、予め Service Pack を適用しておくことで、Service Pack のリリース前に発見された既知の問題を未然に防止できるため、マイクロソフトでは、製品に最新の Service Pack を適用して利用することを推奨しています。

 

なお、最新の Service Pack の適用はベストプラクティスとして推奨されますが、必須ではありません。最新の Service Pack をインストールできない場合は、サポートライフサイクルに従い、まだライフサイクルが終わっていない古い Service Pack が適用された製品へのサポートが提供されます。

2009 年 7 月現在、MOSS 2007/WSS 3.0 Service Pack 1 および Service Pack 2 がサポート対象製品に含まれていますが、2010 年 7 月 13 日には Service Pack 1 のサポートが終了するので、それまでに MOSS 2007/WSS 3.0 Service Pack 2 を適用する必要があります。

 

サポート ライフサイクルに関する詳細は以下のサイトで確認できますので、不明な点があれば、ここで確認してみてください。

マイクロソフト サポート ライフサイクル http://support.microsoft.com/gp/lifecycle

 

～ 次回予告 ～

MOSS 2007/WSS 3.0 のCU が 2 ヶ月に 1 回リリースされることはわかりましたが、実際にサポート技術情報で「SharePoint Cumulative Update」て検索してみると同じ月に複数の CU が出ていたりします。一体何故こんなにたくさんの CU が出ているのでしょうか。次回はここに焦点をあてて、「今、どの CU を適用すべきか」を判断する方法についてお伝えする予定です。

 

 

<関連記事>

第 1 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 1) 第 2 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 2) 第 3 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 3)

 

こんにちは。

SharePoint サポートチームの荒川です。

 

今回は、前回に引き続き「MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 2)」をお送りします。

前回、MOSS 2007/WSS 3.0 のCU が 2 ヶ月に 1 回リリースされることについてお伝えしたわけですが、実際にサポート技術情報で「SharePoint Cumulative Update」て検索してみると同じ月に複数の CU が出ていたりします。一体何故こんなにたくさんの CU が出ているのでしょうか。

 

 

CU にはどんな種類があるの？

実は CU にはいろんな種類があります。

2009 年 4 月にリリースされた CU を例に見てみましょう。

2009 年 4 月にリリースされた CU の一覧   - MOSS 2007 Description of the SharePoint Server 2007 Cumulative Update Server Hotfix Package (Coreserver.msp): April 30, 2009 http://support.microsoft.com/kb/968859   Description of the SharePoint Server 2007 Cumulative Update Server Hotfix Package (Dlc.msp): April 30, 2009 http://support.microsoft.com/kb/968862   Description of the InfoPath 2007 hotfix package (Ifswfe.msp): April 30, 2009 http://support.microsoft.com/kb/969414   Description of the Excel Services in SharePoint Server 2007 hotfix package (Xlsrvapp.msp): April 30, 2009 http://support.microsoft.com/kb/969954   Description of the SharePoint Server 2007 Cumulative Update Server Hotfix Package (Coreservermui.msp): April 30, 2009 http://support.microsoft.com/kb/969420   Description of the Microsoft Office SharePoint Server 2007 hotfix package (Dlcmui.msp [Greek]): April 30, 2009 http://support.microsoft.com/kb/969959   Description of the SharePoint Server 2007 Cumulative Update Server Hotfix Package (MOSS server-package): April 30, 2009 http://support.microsoft.com/kb/968851   - WSS 3.0 Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): April 28, 2009 http://support.microsoft.com/kb/968857   Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Wssmui.msp): April 28, 2009 http://support.microsoft.com/kb/969421   Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): April 30, 2009 http://support.microsoft.com/kb/968850

 

いかがでしょうか。これだけ沢山あると、一体どの修正を適用すればよいのか、正直混乱してしまいますね。

これらの CU の違いは何なのでしょうか。その答えは、CU に関連づいたサポート技術情報のタイトルにあります。

CU のタイトルに注目してみると、以下のような CU に含まれている「パッチ」の名前が記載されていることが判ります。

Coreserver.msp Coreservermui.msp Dlc.msp Dlcmui.msp Ifswfe.msp Xlsrvapp.msp MOSS server-package Sts.msp Wssmui.msp WSS server-package

 

このパッチの名前は、製品の各コンポーネント単位で付けられています。つまり、CU は MOSS 2007 という一つの製品に対して提供されるのではなく、製品の各コンポーネント単位で提供されることになります。

 

補足：パッチの識別子についてここでは細かく触れませんが、たとえば、"Dlc" はドキュメント ライフサイクルの識別子であり、ワークフローやポリシー関連の機能を含みます。"Ifs" は InfoPath Forms Services の識別子で、"Xls" は Excel Calculation Services の識別子です。検索機能を含む、MOSS 2007/WSS 3.0 の主要な機能は Coreserver/Sts パッチにそれぞれ含まれています。

 

当然、各コンポーネントで修正対象となるモジュールが異なるため、4 月にリリースされた Coreserver.msp を適用している環境に、6 月にリリースされた Dlc.msp のみを適用した環境では、4 月以降に修正された Coreserver.msp 関連の既知の問題が発生することになります。一般的に、CU が何種類もあるということが知られていないことも多く、このような状況はユーザーに思わぬ混乱を招く可能性があります。

 

　　　　　　　

 

また、修正の必要がなければ、当然パッチは更新されないので、月によってはすべてのコンポーネントに対する CU が提供されないこともあります。たとえば、2009 年 6 月にリリースされた個別の CU には、Ifswfe や Xlsrvapp のパッチが含まれませんので、2009 年 4 月にリリースされたこれらのパッチを適用していない場合、6 月に配信されたすべての CU を適用したとしても、Ifswfe、Xlsrvapp に関する既知の問題の影響を受けることになります。

 

マイクロソフトでは、このようなわかりづらい状況を改善するために、2008 年 12 月以降、コンポーネント単位の個別の CU に加え、これまでにリリースされたすべてのパッチを包括した CU を、MOSS server-package、WSS server-package という形で配信するようになりました。

包括的な CU は Service Pack 以降にリリースされたすべての修正を含んでいるため、ダウンロード サイズが大きく、インストールにも時間がかかりますが、後々のメンテナンス性を考慮すると、包括的な CU を適用したほうが良いでしょう。勿論、影響範囲を最小限に抑えたい場合は個別の CU を適用しても構いませんが、その場合は何を適用したのかきちんと管理しておかないと、後々面倒なことになるかもしれません。

 

…文章だけでは判りづらくなってきましたね。。もう少し、視覚的に判り易くしましょう。

CU に関連付いたサポート技術情報の文書番号を、リリース月ごとにまとめたものが以下の表です。

注：公開資料をベースにざっとまとめたものですので、細かいところに不備があるかもしれません。参考程度にご覧ください。情報は 2009 年 7 月時点のものですので、今後変更される可能性があります。

 

MOSS 2007

		Global
Version	Rel	CoreServer	DLC	ifswfe	xlsrvapp	Lpsrvwfe	Msxml5s	pjsrvwfe	pjsrvapp	Name
12.0.6327.5000	Aug-08	956056		956315				956061
12.0.6331.5000	Oct	957693	958569	957694				957696
12.0.6332.5001	Nov (COD)			959382
12.0.6335.5000	Dec	959637		959639
12.0.6335.5000	Dec	960011
12.0.6336.5001	Dec (COD)	961176
12.0.6336.5002	Jan (COD)	963022						963024
12.0.6341.5000	Feb	961749
12.0.6341.5001	Feb (COD)	968269
12.0.6341.5002	Feb	961756
12.0.6420.1000	Apr (SP2)	953334
12.0.6504.5000	Apr	968859	968862	969414	969954			968860
12.0.6504.5002	Apr	968851
12.0.6510.5000	Jun	970948	972569					971502		972346
12.0.6510.5003	Jun	971537

 

Local
CoreServerMUI	DLCMUI	Pjsrvmui	Lpsrvmui
958567
960011
961754
961756
953334
969420	969959	969957
968851
970947			972562
971537

 

WSS 3.0

		Global	Local
Version	Rel	STS	WSSMUI
12.0.6327.5000	Aug-08	956057	957109
12.0.6331.5000	Oct	957691
12.0.6335.5000	Dec	959644	960314
12.0.6335.5000	Dec	960010
12.0.6336.5001	Dec (COD)	961175
12.0.6336.5002	Jan (COD)	963023
12.0.6341.5000	Feb	961750	967703
12.0.6341.5000	Feb	961755
12.0.6421.1000	Apr (SP2)	953338
12.0.6504.5000	Apr	968857	969421
12.0.6504.5000	Apr	968850
12.0.6504.5002	May (COD)	971065
12.0.6510.5001	Jun	970946	971500
12.0.6510.5001	Jun	971538

 

上記の表を見ると、コンポーネントごとに分かれた CUを横断する包括的な CU が、2008年 12月以降の CU 配信時にリリースされていることが判ります。(赤字部分)

CU の一覧はサポート技術情報からチェックできます。

Office 2007 Cumulative Update for April 2009 http://support.microsoft.com/kb/968765   Office 2007 Cumulative Update for June 2009 http://support.microsoft.com/kb/972632

 

CU の一覧が公開された場合は、以下のサポート技術情報からリンクされますので、今後新しい CU がリリースされたら、是非確認してみてください。

Cumulative updates are available from the Microsoft Office team to fix reported problems http://support.microsoft.com/kb/953878

 

 

～ 次回予告 ～

最終回となる次回は、パッチに関する細かい補足事項を取り上げたいと思います。

 

こんにちは。

SharePoint サポートチームのはながたです。チームブログ、初アップデートです。

 

これまで、たらかわくん（チームでは、たらちゃんと呼ばれてます）の暴走ぎみな記事に「MS の SharePoint サポートチームは変なやつばっかりのようだ」と思った人もいるかもしれませんが、その他大勢はごく普通で、たらちゃんはいろんな意味でチームでも特別な存在なのです。

 

さて、今回は TechNet のWeb キャストで SharePoint Server 用の「5 minutes トラブルシューティング」のビデオが公開されたお知らせです。

 

お題は「SharePoint Server において構成ウィザードが失敗する場合のトラブルシューティング」です。

 

SharePoint Server の管理者であれば、誰もが実行したことがある「構成ウィザード」ですが、環境や構築手順によって失敗してしまうことがあります。

このトラブルは、SharePoint サポートでも 1, 2 を争うほど多いお問い合わせ、かつ有名な現象ですので、このブログを読んでいる人であれば、あー、知ってる、という人もいるかもしれません。

そのため今回の Web キャストでは、実際に構成ウィザードが失敗する環境を例に、どんな情報が有効で、どんな対処をするべきか？などなど、私たちサポートエンジニアも実践しているトラブルシューティングを、短い時間ではありますがご紹介していますので、是非ご参照ください！また、フィードバックもお待ちしてます！！

 

(今回はビデオの長さに制限があったので簡潔にまとめてますが、機会があればこのブロ��でも、より詳しい内容をご紹介していきたいと思ってます)

 

このビデオは、チームでも割とひきこもりがちなエスカレーション エンジニアさとうさんがスピーカーをしています（私はコンテンツ作成しました）。【スピーカー紹介】に入社時の写真とかでちゃってるんです。目標は「顔がみえるサポート」？らしいですが、ちょっとはずかしい。。

 

SharePoint Server において構成ウィザードが失敗する場合のトラブルシューティング

http://technet.microsoft.com/ja-jp/ee460822.aspx

 

5 minutes トラブルシューティング

http://technet.microsoft.com/ja-jp/dd251165.aspx

 

今後ともよろしくお願いします！！

 

<関連記事>

第 1 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 1) 第 2 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 2) 第 3 回：MOSS 2007/WSS 3.0 のソフトウェア更新プログラムについて (Part 3)

 

こんにちは。

SharePoint サポートチームのたらかわです。

 

3 部作の最終回となる今回は、パッチに関する細かい補足事項を取り上げたいと思います。運用に役立つ情報が詰まっていますので、是非是非ご一読くださいませ。

 

 

パッケージって何？

「パッケージ」とは、修正プログラム用にダウンロードされる実行可能 (.exe) ファイルのことです。パッケージには、1 つ以上のパッチが格納されています。

実際に、CU をダウンロードして解凍してみると、パッチ (*.msp) ファイルがそのまま展開されるのではなく、"office-kb961756-fullfile-x86-glb.exe" のようなファイル名になっていることが判ります。

 

補足：パッケージファイルを展開する際にコマンドラインから "/extract:<Path>" スイッチを付けて展開すると、パッケージに格納されているパッチファイルが確認できます。

 

パッケージには決められた命名規則があり、以下のパターンになっています。

 

productnamerrr-kby-xnn-fullfile-lang.exe

 

各項目の詳細は次のとおりです。

・productname は、リリースされた製品の名前の短い識別子です。

・rrr は、リリースの説明です。たとえば、Service Pack 1 は sp1 となります。

・y は、ソフトウェア更新プログラムに関するサポート技術情報の記事に対応する番号です。

・nn は、ハードウェア アーキテクチャを示す番号で、x86 か x64 のどちらかです。

・lang は、ソフトウェア更新プログラムの言語です。たとえば、米国英語は en-us です。

 

たとえば、米国英語版 x86 ベースのハードウェア用 Microsoft Office SharePoint Server 2007 Service Pack 1 (SP1) ファイルのファイル名は、officeserver2007sp1-kb936984-x86-fullfile-en-us.exe です。

 

補足：

・パッチは累積的です。したがって、2 つのパッケージに同じパッチが含まれる場合、ビルド番号が大きいパッケージには、ビルド番号が小さいパッケージに含まれるすべてのものが含まれます。

・パッケージのプロパティには、そのパッケージを含むビルドの番号が表示されます。このビルド番号はパッケージ内のファイルに示されたバージョンより高い場合もあり、パッケージの内容をより正確に示しているため、重要な情報です。

・パッケージ名には、office-kb950487-x86-fullfile-glb.exe のように glb という文字列が含まれる場合があります。これはパッケージにグローバル パッチが含まれることを示します。

・パッケージ名には、wss-kb948957-x86-fullfile-en-us.exe のように en-us (英語、アメリカ) や de-de (ドイツ語、ドイツ連邦共和国) などの地域コードが含まれる場合があります。これはパッケージにローカライズされたパッチが含まれることを示します。

 

グローバル パッチとローカル パッチの違いって何？

パッチは、CoreServer と CoreServerMUI、STS と WSSMUI のように、グローバル パッチとローカルパッチに分かれていることがあります。

グローバル パッチは、製品の言語に依存しない部分に適用されます。つまり、言語固有の関係を持たないアイテムのみを変更します。SharePoint 製品の設計では、言語固有の文字列は専用の場所に置かれ、個別に更新できるようになっています。これにより、基本のインストール言語または言語パックのインストールの有無に関係なく、グローバルパッチをすべてのサーバーに適用できます。

ローカライズされたパッチ (ローカル パッチとも呼ばれます) は、言語固有の文字列や関連するコードに対する更新プログラムを含みます。ローカライズされたパッチでのコードの変更は、ユーザーインターフェイスに表示される特定の文字列が対象ではない場合がありますが、ローカライズされたパッチに組み込むのに十分なほどそのような文字列と密接に関係しています。

 

グローバル パッチとローカライズされたパッチは両方適用したほうがよい？

よくある質問は、グローバル パッチとローカライズされたパッチのどちらか一方をインストールするか、または両方をインストールするかという点です。

どのパッチをインストールするかは、そのインストールによって何を実現するかに基づいて決定します。この決定に関するガイダンスを次に示します。

 

  ・製品の更新プログラムの大部分は、グローバルパッチに収められています。製品の設計情報で説明したように、製品コードの言語固有の部分を分離するように配慮されており、コード ベースの中に言語固有の部分は多くありません。

  ・コードの修正プログラムの中には、完全に実装するためにはグローバルパッチとローカル パッチの両方を必要とするものがあります。一方のパッチだけをインストールした場合、特定の機能にパッチ適用前と同じ不具合が残ります。

  ・Service Pack はすべての機能を更新するので、Service Pack が適用された後の任意の時点で最初の依存関係が設定されます。この依存関係は次の Service Pack まで維持されます。グローバル パッチまたはローカライズされたパッチをのいずれか一方だけをインストールしてもサーバーの全体的な動作には影響しない場合がありますが、すべての修正を確実に適用したい場合は、グローバル パッチとローカライズされたパッチの両方をインストールしてください。

  ・Microsoft カスタマ サポートサービスでは、修正から最大限のメリットが得られるように SharePoint 環境全体に両方のパッチをインストールし、プラットフォーム全体のソフトウェア更新を同じレベルに維持することを強く推奨しています。

 

結局、常に最新のパッチを適用して使いたい場合はどうすればよいの？

ユーザーの要件によっては、環境を常に最新にしておきたい場合もあるでしょう。前項で述べたように、CU の基本スタンスとしては、特定の問題に限定して、個別に適用を検討することが推奨されますが、MOSS 2007/WSS 3.0 に対する修正プログラムの適用は運用中のサービス停止など、業務に与える影響も大きく、サーバーの数が増えるとなかなか大変な作業ですので、できることなら作業時に、それまでにリリースされている最新のパッチをすべて適用しておき、潜在的な問題を潰しておきたいと考えるのは自然なことかもしれません。また、特定の環境で何らかのトラブルが発生した際に、検証環境で現象を再現して、とりあえず検証環境に最新のパッチを適用して問題が解決するか確認したいという状況も考えられます。(製品サポートではよくあることです。)

 

このような場合、最も手っ取り早い方法は、その時点でリリースされている最新の Service Pack と、最新の包括的な CU (MOSS server-package、WSS server-package) を適用することです。

たとえば、2009 年 7 月時点において、MOSS 2007 に最新のパッチを適用したい場合は、以下のソフトウェア更新プログラムを適用します。

 

WSS 3.0 Service Pack 2 (KB 953338)

MOSS 2007 Service Pack 2 (KB 953334)

2009 年 6 月の WSS 3.0 の累積的な更新プログラム MOSS server-package (KB 971538)

2009 年 6 月の MOSS 2007 の累進的な更新プログラム WSS server-package (KB 971537)

 

補足：Service Pack はインストール順序が決まっていますが、パッケージと修正プログラムには決められたインストール順序はありません。パッケージまたは修正プログラムは、作業の終了後にファーム内のすべてのサーバーが同じレベルに更新される限り、任意の順序でインストールできます。���らに、サーバーが更新プログラムに関するサポート技術情報に記載されている問題の影響を受けない限り、更新プログラムをインストールするための要件はありません。

更新プログラムのインストール順序は特に決まっていませんが、MOSS 2007 の RTM 後に必要な更新プログラムは、上記の順序でインストールすることをお勧めします。

 

注：2009 年 4 月以降の CU を適用する場合には、事前に MOSS 2007/WSS 3.0 の Service Pack 2 を適用することが強く推奨されています。

MOSS 2007 Service Pack 1 の環境に、いきなり 2009 年 6 月の CU を適用することもできなくはないですが、トラブルを未然に防止するためにも、推奨された方法で更新しましょう。

よく、Service Pack は影響範囲が大きいので個別の修正だけ適用したいといった要望があるのですが、前回ご紹介した CU のリリース表を見てもわかるとおり、コンポーネント単位の CU ツリーは一本化されており修正内容は累積的ですので、影響範囲という観点だけでみると、Service Pack 2 も 4 月以降の CU も実はそれほど変わりません。また、今後 Service Pack 3 がリリースされた場合も、同様の考え方になると思います。

 

関連資料

Deploy software updates for Office SharePoint Server 2007 http://technet.microsoft.com/ja-jp/library/cc263467.aspx   Deploy software updates for Windows SharePoint Services 3.0 http://technet.microsoft.com/ja-jp/library/cc288269.aspx   Microsoft SharePoint Team Blog Announcing December Cumulative Update for Office SharePoint Server 2007 and Windows SharePoint Services 3.0 http://blogs.msdn.com/sharepoint/archive/2008/12/17/announcing-december-cumulative-update-for-office-sharepoint-server-2007-and-windows-sharepoint-services-3-0.aspx

 

 

こんにちは。SharePoint サポートチームのかわぞえです。

 

最近不幸にも家の網戸にとまってしまったカマキリを捕獲して、ペットとして飼っています。

奥さんには嫌がられていますが、子供たちは興味津々で次々とバッタやコオロギをカマキリのいる虫かごに放り込み、弱肉強食の食物連鎖の構図を楽しんでいます。

A: 「でも、カマキリのパパは最後にはママに食べられちゃうんだよ」

B: 「そうなんだ、、、切ないねーパパ。僕も食べられちゃうのかな。。」

男に対する食物連鎖の厳しさがあることに気づき、大人の階段を一歩上ったわが子を垣間見ました。。。

 

さて、今回は MOSS 2007 の検索機能の中で、ちょっとした Tips をご案内したいと思います。

内容は、「MOSS 2007 の検索結果に、特定の列の情報を表示させないようにする」、です。

 

以下のような状況を想定したケーススタディを考えてみます。

 

1). Contoso 社のサポート部門では、リストライブラリでお問い合わせいただいた内容やお客様名、企業名、対応者を記録しています。

2). お問い合わせを受けた際には、リストライブラリを検索し、過去に受けた問い合わせ内容やお客様を検索し、迅速かつ適切な対応ができるよう努めています。

3). これらの状況のため、いかに早く情報を抽出できるかが、顧客に対するサービス品質向上の1つとして重要な要素となっています。

 

ところが、サポートの担当者からは、以下の声が上がっており、IT 管理者は頭を悩ませています。

「お客様名を検索しようとすると、同じ名前の対応者もひっかかってきており、検索精度に影響がでるのでなんとかしてほしい」

 

ここは是非 MOSS 2007 の検索機能を使用してこの問題に対処してみたいと思います。

MOSS 2007 では、コンテンツをクロールした際に検索インデックスにインデックス情報が格納されますが、コンテンツの中身だけではなくプロパティ情報もデータとして格納されます。

たとえばドキュメントのプロパティとしては、タイトル、作成日時、作成者などがすぐに思いつきますね。

 

早速 MOSS 2007 の管理画面から、どう設定するのか、確認してみましょう。

 

1. まず現状の動作を確認してみます。今回対象のリストは以下のようになっています。舞黒さんが顧客名列にも対応者列にも存在しています。

 

 

2. このリストを検索すると、舞黒太郎さんを含む列と舞黒次郎さんの名前を含む列がヒットします。1つは [顧客名] 列の舞黒太郎さん、もう1つは [対応者] 列にある舞黒次郎さんを含む例です。この舞黒次郎さんを含む  [対応者] 列を除外することが今回の要件となります。

 

 

3. では、この状況を変更するべく、サーバーの全体管理サイトから、共有サービスプロバイダの管理ページ -> [検索の設定] ページにアクセスします。画面が表示されたら、[メタデータ プロパティのマッピング] のリンクをクリックします。

 

 

4. 何やら見慣れない画面がでてきましたね。説明文に、「クロールされたプロパティは、クロールされたコンテンツから自動的に抽出されます。」とあります。先にご説明したコンテンツの中身だけでなく、プロパティ情報もデータとして格納されている、ということですね。では先ほどの列がどこに格納されているか確認しましょう。[クロールされたプロパティ] をここでクリックします。

 

 

5. 次は [メタデータ プロパティのマッピング] 画面が表示されます。このなかで SharePoint のリスト列の情報なので、SharePoint カテゴリを選択します。

 

6. クロールされたプロパティが表示されました。これらがSharePoint カテゴリに分類されるコンテンツをクロールした際に、抽出されたプロパティになります。早速編集する対象の [対応者] 列を探すべく、検索ボックスで [対応者] と検索しますが、ヒットしません。再度検索してもやはりヒットしません。そこで、よく画面を見てみると、プロパティ名で意味不明な文字列があります。意味不明な文字を解読するため、ここでは当該の文字列に対してデコードを行ってみましょう。まず ”ows_” の部分と、”_x” の部分を除いた文字列を初めに抽出します。そうすると、(5bfe 5fdc 8005) という 3 つの文字列が残りますので、次にこれをデコードします。デコードするには、外部サイトになりますが、以下のサイトが便利です。デコードを行うと、”5bfe 5fdc 8005” に対応した文字列として、日本語の ”対応者” が表示されます。

 

- 参考 URL

Unicode code converter (W3C の Internationalization Activity Lead である Richard Ishidaさんのサイトにある Web 上のツールです)

http://rishida.net/tools/conversion/

 

 

7.  お気づきの通り、日本語などの DBCS (Double Byte Character Set) では、Unicode にエンコードされて表示されます。その他の文字列についても、”ows_” の部分と、”_x” の部分を除いた文字列をデコードすると、対応する日本語文字列が表示されます。(英数字で列を作成している場合にはエンコードされることはありませんので、英数字で記載された列を作成するもの1つの手です。今回の例でいえば、ReqNo は、ows_ReqNo として表示されます。)

 

では早速 [対応者] のプロパティをインデックスから除外してみましょう。クロールされたプロパティ (ows_x5bfe_x5fdc_x8005) をクリックして表示された画面で、[このプロパティの値を検索インデックスに取り込む] のチェックを外して、[OK] します。

 

 

８. [メタデータ プロパティのマッピング] 画面の説明にもあるように、今回実施したプロパティの変更はフルクロールが必要となりますので、フル クロールを実施します。フル クロール後、再度同様の検索を実施すると、[顧客名] 列の舞黒太郎さんは表示されましたが、[対応者] 列の舞黒次郎さんは結果から表示されなくなりました。これで今回の要件を実現することができましたので、IT管理者も一安心です。

 

 

 

今回は、特定の列を検索インデックスから除外するというピンポイントな Tips でしたが、いかがでしたでしょうか。MOSS 2007 検索機能では、その他にもクロールルールを作成して、ルールに基づくコンテンツのみをクロールする (例えば、特定の URL はクロールする対象から除外する)、特定の URL を検索結果から即削除する、検索範囲で指定できるルールから特定のフォルダ、指定したプロパティを含むコンテンツを当該の検索範囲には表示させない、といった様々な機能が用意されています。会社の要件に沿うよう、ご利用になっている MOSS 2007 の検索機能について色々な設定をお試しください。

 

- 参考情報

今回ご紹介した機能に関する TechNet の参考情報です。お時間のあるときにでも、是非ご一読ください。

タイトル : コンテンツをクロールする (Office SharePoint Server 2007)

URL     : http://technet.microsoft.com/ja-jp/library/cc262794.aspx

 

タイトル : メタデータ プロパティのマッピングを管理する (Office SharePoint Server)

URL     : http://technet.microsoft.com/ja-jp/library/cc262933.aspx

 

タイトル : 検索範囲を構成する (Office SharePoint Server)
URL     : http://technet.microsoft.com/ja-jp/library/cc263389.aspx

タイトル : 範囲ルールを管理する (Office SharePoint Server)
URL     : http://technet.microsoft.com/ja-jp/library/cc263348.aspx

こんにちは。

SharePoint サポートチームのくらたです。

今回は「クロール ログの出力方法」についての紹介したいと思います。お客様から「クロール ログは画面で見ることは出来るが、ファイルなどに一覧で出力することが出来ないんですか？」とご質問を頂くことがあります。

クロール ログとは以下のようにクロールの結果を記載したログになりますが、MOSS 2007 では、UI 上からは確認出来るものの、ファイルなどにエクスポートする機能は搭載しておりません。そこで、今回は SQL サーバー データベース内のテーブルから、クロールログと同様の内容を確認するという代替案についてご説明いたします。(SQL サーバーだとテーブルの内容はファイルに出力できますよね。)

では、クロール ログの内容を把握するために、具体的に SQL サーバーのどのテーブルを参照すれば良いのかを見ていきましょう。

クロールの状況は、検索データベース (既定では SharedService1_Search_DB) の以下の 2 つのテーブルを参照することにより、確認できます。

1) MSSCrawlURL テーブル

クロール ログと同等の情報が記録されています。

2) MSSCrawlHistory テーブル

クロール 履歴の情報が記録されています。

テーブルの詳細は以下になります。

1) MSSCrawlURL テーブル

MSSCrawlURL テーブルには、とても多くの列が存在しますが、具体的に参照して頂きたい列は限られてます。くらたの経験上、以下の4 つの列を参照して頂ければ概ねクロール ログと同様の状況を把握することが可能です。

列名	内容
DisplayURL	アイテムの URLを表します。
ErrorID	エラー内容の詳細を表します。エラー メッセージの詳細は、MSSCrawlErrorList テーブルに記載されています。
ErrorLevel	エラーの種類を表します。 ErrorLevel = 0 の場合 : 成功 ErrorLevel = 1 の場合 : 警告 ErrorLevel = 2 の場合 : エラー
LastTouchStart	クロールした時刻を表します。

例えば、クロールが警告になった URL を確認する場合は、以下の SQL 文を実行します。

SELECT [DisplayURL],[ErrorID],[ErrorLevel],[LastTouchStart]   FROM [<検索データベース名>].[dbo].[MSSCrawlURL] where ErrorLevel = 1

くらたの検証環境で確認したところ、以下のような結果が返ってきました。

上記より、http://kokurata165324x/searchcenter が、警告 (ErrorID = 4) により失敗していることが確認出来ます。

エラー内容の詳細は、MSSCrawlErrorList テーブルから確認することが出来、具体的には以下のような SQL 文を実行することで、確認することが可能です。

SELECT *   FROM [<検索データベース名>].[dbo].[MSSCrawlErrorList] where ErrorID = <ErrorID>

では、実際に実行してみましょう。

上記のように、ErrorID = 4 は、“この URL のコンテンツはインデックス付けしない属性を持つため、サーバーによって除外されています。” という警告メッセージであることが確認できます。

実際のクロール ログを見てもやはり警告が出ていました。。。

今回はエラーについての切り分けが目的ではないので、エラー内容についてはふれませんが、このようにしてクロールログの内容を SQL データベースから確認することが可能です。

なお、上記の SQL を別々に実行するのも大変ですので、以下の SQL 文を使用し、INNER JOIN で MSSCrawlErrorList  テーブルと  MSSCrawlURL  テーブルと連結して、表示させるとより便利ですね。

SELECT MSSCrawlURL.DisplayURL, MSSCrawlURL.ErrorID, MSSCrawlURL.ErrorLevel, MSSCrawlURL.LastTouchStart,MSSCrawlErrorList.ErrorMsg FROM [<検索データベース名>].[dbo].[MSSCrawlErrorList]   INNER JOIN [<検索データベース名>].[dbo].[MSSCrawlURL]    ON MSSCrawlErrorList.ErrorID = MSSCrawlURL.ErrorID     Where MSSCrawlErrorList.ErrorLevel = <ErrorLevel>

実際に実行し、警告のクロール (ErrorLevel = 1) を表示させてみると、以下のようになります。

2) MSSCrawlHistory テーブル

MSSCrawlHistory テーブルを参照することにより、クロール履歴を確認することが可能です。詳細なクロール履歴は、UI 上から把握することは出来ないため、SQL データベースを参照することは非常に有効な手段になります。

MSSCrawlHistory テーブルには、以下の列が存在します。

説明	内容
CrawlID	クロールごとに内部的保持する一意の識別子を表します。
ProjectID	プロジェクトの種類を表します。 ProjectID = 1 の場合 : Portal Content (コンテンツのクロール) ProjectID = 2 の場合 : Anchor Project (リンク関連の処理)
CrawlType	クロールの種類を表します。 CrawlType = 1 の場合 : フル クロール CrawlType = 2 の場合 : 増分 クロール CrawlType = 6 の場合 : 削除 クロール ※後述の「削除クロールって何？」をご参照ください。
RequestTime	リクエスト時刻
Status	現在の状態を表します。 Status = 1 の場合 : 初期化 Status = 2 の場合 : 開始アドレスが初期化されています Status = 4 の場合 : 開始 Status = 5 の場合 : エラー Status = 11 の場合 : 完了 Status = 9 の場合 : 一時停止 Status = 12 の場合 : 停止
StartTime	開始時刻
EndTime	終了時刻
SuccessCount	成功したアイテム数
ErrorCount	エラーになったアイテム数
WarningCount	警告になったアイテム数

実際に以下の SQL 文により、MSSCrawlHistory テーブルの中身を参照してみましょう。

上記のように、MSSCrawlHistory テーブルを参照することにより、クロール 履歴を参照できます。

削除クロールって何？

----------------------

削除クロールとは、以下の状況などに実行される処理のことです。

  - コンテンツ ソースを削除した場合

  - コンテンツ ソースの開始アドレスが削除された場合

くらたの検証環境で、具体的に以下のように、開始アドレスを削除してみると・・・。

http://kokurata165324x/ を削除

削除クロールが実行されたことが確認できます。

さらに、クロール ログには以下のように記載されています。

今回は、検索データベースに保存されたクロール結果の情報について解説いたしましたが、いかがでしょうか。SQL サーバーを直接確認する以外にも、Visual Studio 等を使用したプログラムを開発することで、クロールログを取得することが可能です。プログラムの開発については、割愛しますがクロールログが出力可能なツール (Search Crawl Log Viewer) が以下に公開されておりますのでご紹介します。本ツールはサンプルコードも公開されておりますので、プログラムを開発される上でご参照ください。

Creating an Enterprise Search Crawl Log Viewer for SharePoint Server 2007
http://msdn.microsoft.com/en-us/library/cc751807.aspx

また、以下のサイトから Search Crawl Log Viewer のサンプル コードをダウンロードできます。
http://code.msdn.microsoft.com/crawllogviewersample

なお、上述に紹介しましたデータベースのテーブルは、以下の技術情報などで公開されておりますので、ぜひご参照ください。

[MS-SRCHTP]: Search Topology Protocol Specification

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

[MS-SQLPADM]: SQL Administration Protocol Specification

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

みなさん。こんにちは kenmori です。

 

本日は、皆様に SharePoint が用意しているイベント ハンドラについて、特に SPItemEventReceiver についてのご紹介とその注意点についてお伝えいたします。

 

イベント ハンドラって何？

 

イベントハンドラとは簡単に申しますと、何かのタイミングに任意の処理を実行させるカスタマイズになります。

発生する前と後に実行でき、発生前の処理では何と抑止することもできてしまいます。

 

イメージとしては例えば・・・、ご飯を食べた後のイベントで、歯を磨く処理をプログラミングしておきます。

こうすることで、虫歯を防ぐことができて、健康的ですね。

 

その他の例

食べる前に飲む (何か聞いたことがある・・・)

食べる前にやめとく (ダイエットのため)

 

本当に食べる動作にイベント ハンドラがつけられるとすれば、それはロボットの開発の話みたいですので、SharePoint のお話をいたします。

 

SharePoint ではアイテムを追加、更新、削除するタイミングでイベント ハンドラがよく使われています。

 

補足

イベント ハンドラを実施するためには、まず Visual Studio が必要です (2005 以降)。

Edition は何でも大丈夫です。VSeWSS は非サポートツールですが便利です。

 

タイトル : Windows SharePoint Services 3.0 ツール: Visual Studio 2008 Extensions Version 1.2

アドレス : http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=7bf65b28-06e2-4e87-9bad-086e32185e68

 

タイトル : Windows SharePoint Services 3.0 ツール: Visual Studio 2005 Extensions Version 1.1

アドレス : http://www.microsoft.com/downloads/details.aspx?familyid=3E1DCCCD-1CCA-433A-BB4D-97B96BF7AB63&displaylang=ja

 

概要手順

 

VSeWSS をインストールした開発環境にて、イベント ハンドラの開発を実施するには以下のような手順で開始します。

 

1. SharePoint の "空のプロジェクト" を作成します。

2. ソリューション エクスプローラより、プロジェクト ファイルを右クリックし [追加] - [新しい項目] をクリックします。

3. テンプレートより "イベント レシーバ" が選べます。

 

 

 

イベント ハンドラを使用するシナリオ

 

今回は前述いたしましたとおり、アイテムに対するイベント (SPItemEventReceiver) についてのご説明になりますが、SharePoint でこういったカスタマイズが使われるシナリオをいくつかご紹介させていただきます。

 

例えば、アイテムを追加、編集、削除した際にイベントが呼べますのでこんなことができます。

 

・ユーザーの入力文字列を検証する

 複数のフィールド間に入力されたデータの組み合わせを検証する場合には良い方法です。

  (例 "2009" 年 "2" 月 "31" 日は不正な日付です！ etc.)

 

 個々のフィールドに対しては、カスタムフィールドの方がベターです。

 しかし、カスタムフィールドの入力検証を実装するのに敷居が高いと感じる方にはオススメです。

 

・列に対して自動的に値を生成してセットする

 参照列でも実装できない複雑な数式も実現できます。

 

・作成したアイテムにデフォルトの権限を指定する

 登録したアイテムが、最初は自分のみ見えるなどの運用が可能です。

 フォルダ権限を編集すると性能問題があるので、SP2 適用後をオススメします。

 

・アイテムの削除を禁止する

 

イベント ハンドラに不向きなシナリオ

 

イベントハンドラに不向きなシナリオもあります。

・何日間 (または何時間) も継続するような処理を実装する場合

 イベントハンドラの実行中は常にメモリを確保した状況になりますので、何件も起動してしまうと大量なメモリが消費されてしまい、メモリが枯渇してしまうことにもなりかねません。即時完了する処理のみ実装し、長期に渡るビジネスロジックなどを実施する場合は、カスタム ワークフローをご検討ください。

 

・何度も実行されると困る処理

 例えば、メールを送信するなどの処理を実装していると、何通も重複したメールを受信してしまう可能性があります。

 詳細は注意点に記載いたします。

 

イベント ハンドラを使う際の注意点

さて、本題に入ります。イベントハンドラを使う際の注意点ですが、影響度の高いものを集めて記載しております。

開発の際にはご参考にしてください。

 

1. 非同期の -ed イベントで更新後のデータを扱う場合は要注意

 

-ing は同期イベントですが、-ed は非同期イベントと MSDN に記載があります。非同期とはどういうことかと申しますと、別のスレッドで動作することとなります。

 

タイトル : SPItemEventReceiver メソッド (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spitemeventreceiver_methods.aspx

 

これの何が要注意かと申しますと、データが更新される前にイベントが呼ばれていることもあるのです。

このイベントが発生するタイミングはデータベースにデータが更新されるタイミングよりも若干早いため、アイテムが存在しない状況で ItemAdded イベントが呼ばれたり、ItemUpdated イベントでSPWeb から新たに SPListItem を取得した値が更新前の値だったりといったことがあります。(かなり稀です。)

 

同期された値はこれらのプロパティで取得するようにしてください。これらの値を使用すれば、更新前の処理を取得するようなことを避けることができます。

・properties.BeforeProperites

・properties.AfterProperties

 

しかしながら、properties.ListItem やそのプロパティ情報を参照したり、SPSite や SPWeb を別途生成して、 SPListItem にアクセスする際は同期がとれていない可能性があることを想定してプログラムを実装ください。特に、マルチ CPU 環境ではお気をつけください。

 

タイトル : SPItemEventProperties.BeforeProperties プロパティ (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spitemeventproperties.beforeproperties.aspx

 

タイトル : SPItemEventProperties.AfterProperties プロパティ (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spitemeventproperties.afterproperties.aspx

 

- 対処策

 どうしても同期されていないプロパティを使用したい場合は、更新されるのを待つ方法があります。

残念ながら、更新が完全が終わっていることを知るためのプロパティ値などはないようですので、Thread.Sleep メソッドを使用してスレッドを待機させながら、処理をリトライするのが唯一の方法と考えられます。

 

2. イベント ハンドラで無限ループに陥る

 

アイテムが更新された後のイベントで、さらにアイテムを更新した場合どうなるか・・・。もちろん、イベントがまた発生します。

これがきっかけとなり ItemUpdated イベントの無限ループとなってしまいます。

 

先ほど申し上げたとおり ItemUpdated イベントは別スレッドで動作するので、無限ループに陥っていても画面上のパフォーマンスに直接影響せず、気付かないことが多いのです。十分に動作をご確認ください。

 

- 対処策

properties.DisableEventFiring メソッドを呼び出して、イベント ハンドラの処理で再帰的にイベントを発生させないようにしましょう。

 

タイトル : SPEventReceiverBase.DisableEventFiring メソッド (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.speventreceiverbase.disableeventfiring.aspx

 

元に戻すには、EnableEventFiring メソッドを呼び出します。

 

タイトル : SPEventReceiverBase.EnableEventFiring メソッド (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.speventreceiverbase.enableeventfiring.aspx

 

3. ホスト プロセスはアイテムを操作したプロセスです。

 

イベントハンドラはアセンブリとして SharePoint サーバーに展開しますが、実行されるホスト プロセスは、ワーカープロセス (w3wp.exe) であるとは限りません。

例えば、お客様が作成したコンソールアプリケーションから SharePoint のアイテムを追加、編集など実施した場合は、コンソール アプリケーションがホストプロセスとなります。

 

特にファイルの相対パスなど、ホストプロセスが何かによって影響する処理を記載する際はご注意ください。

また Visual Studio より [デバッグ] - [プロセスにアタッチ] にてイベント ハンドラをデバッグする際には、アイテム追加、更新、削除を実施するホストプロセスが何であるかを確認の上、実施ください。

 

 

4. エクスプローラ ビューを使用する際は要注意です。

 

ドキュメントライブラリなどにイベント ハンドラを関連づける時は要注意です。

 

 

エクスプローラビューを使ってファイルをアップロードすると、サーバー側で通常にファイルを保存するのと異なる動作になります。

例えば、エクスプローラビューを使用してファイルをアップロードすると、遅延書き込みが発生します。

 

- 遅延書き込みの簡単なご説明

遅延書き込みを簡単にご説明しますと、例えばリムーバブル ディスクやネットワーク プレースへのファイル書き込みなど、処理時間がかかるファイル I/O 処理を非同期的に実行することにより、画面操作やファイル I/O 処理を最適化するための動作となります。

ファイル アップロードの動作においては、まずサーバー側でアップロード対象のファイル (この時点では 0 KB) を作成します。その後、サーバーに転送されてくるファイルのデータを一度メモリにバッファさせ、システム上適切なタイミングにて適時書き込み処理を実施していくことで、書き込み効率を最適化しております。

 

MSDN には、エクスプローラ ビューに関する内容として以下のような記述がございます

新しいアイテムを追加するときは、ItemAdded イベントのみ発生します。ただし、エクスプローラ ビューが使用される場合は、ItemAdded および ItemUpdated イベントが両方とも発生します。その際、ItemUpdated イベントは常に ItemAdded イベントの後で発生します。

 

タイトル : SPItemEventReceiver.ItemUpdated メソッド (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spitemeventreceiver.itemupdated.aspx

 

イベントは書き込まれた回数呼び出されます。

例えば、遅延書き込みによってバックグラウンドのスレッドが 1 つのファイルを保存するにあたり 4 回書き込みを実施した場合、1 回の ItemAdded イベントと 3 回の ItemUpdated イベントが発生する動作となります。

この結果、イベントハンドラにてメールを送信するなどの処理を実施した場合は、不要なメールが飛び交うことが考えられます。

SharePoint 側は���新されたエクスプローラ ビューより更新されてくるイベントを検知して処理を実施するだけですので、残念ながら SharePoint としてこの複数回発生する更新を変更することはできません。

 

- 対処策

 メール送信の処理はできればワークフローで実装してください。

 

 もちろんワークフローも内部的にはイベントで起動されますので、2 回発生することも考えられます。

 その場合は、一番最後に待機処理を入れて、処理が瞬時に終わらないようにしましょう。

 ワークフローは多重起動できませんので処理が複数回実施されるのを避けることができます。

 

(2010 年 1 月 6 日 追記)

イベント ハンドラの注意点のうち、エクスプローラ ビューを使用する際の注意点をピックアップしたブログを作成しております。

より詳細な情報が必要な場合はこちらをご覧ください。

(http://blogs.technet.com/sharepoint_support/archive/2010/01/06/3303951.aspx)

5 アイテムのチェック イン時の動作について

 

チェックインが発生した際は、アイテムの更新イベントも発生します。

つまり、アイテムを更新してチェックインを実施すると、2 回更新イベントが発生することになります。

 

純粋にチェックインだけを取得するのであれば、ItemCheckingIn、ItemCheckedIn イベントというものもございます。

 

タイトル : SPItemEventReceiver.ItemCheckingIn メソッド (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spitemeventreceiver.itemcheckingin.aspx

 

タイトル : SPItemEventReceiver.ItemCheckedIn メソッド (Microsoft.SharePoint)

アドレス : http://msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spitemeventreceiver.itemcheckedin.aspx

 

まとめ

 

イベントハンドラと聞くと、何でも簡単に実装できてしまうような錯覚に陥ります。

しかしながら、上述のような処理のタイミングに依存した現象が発生することも考えられますので、お客様に機能をご提案する方には事前にプロトタイプ版などを作成し、事前に動作を十分に検証いただいた上で実施ください。

もしもトラブルにぶつかった場合・・・、そんな場合には私たちが可能な限り対応させていただきますので、お問い合わせください。

 

参考情報

 

参考情報を記載いたします。

 

タイトル : イベントの基礎

アドレス : http://msdn.microsoft.com/ja-jp/library/ms442323.aspx

 

タイトル : 基本的なイベント ハンドラを作成する

アドレス : http://msdn.microsoft.com/ja-jp/library/ms437502.aspx

 

タイトル : OFFICE SPACE SharePoint 2007 のイベント
アドレス : http://msdn.microsoft.com/ja-jp/magazine/cc163318.aspx

 

肌寒くなってきましたね。

冒頭の話ではないですが、イベント ハンドラではお体は守れませんので、ご自身でお体にお気をつけて食べ過ぎ、飲みすぎにご注意ください。

 

以上、kenmori でした。