kunitaka's SharePoint Factory

　ということで、早速ダウンロードして試しにセットアップしてみました。

ライセンス条項を確認して、しばらくするとコマンドプロンプトが何度も勝手に起動されます。
良く見るとタイトルに stsadm.exe が見えるので、テンプレートの追加などがコマンドラインベースで行われているようです。
最後に、セットアップ完了には IIS のリセットが必要ですというダイアログが表示され、「はい」を選択すると、またもやコマンドプロンプトが起動されます。
ここでは、iisreset が実行されているようです。

・GroupBoard Workspace 2007 サイト


セットアップが完了すると、勝手にサイトを作ってしまうようです。
実際には、既存のサイト コレクションの中に、GroupBoard Workspace という名前のサブサイトを作成されていました。
勝手に作ってしまうのはどうかと思うが、前のバージョンのように変な構成で勝手に作られるよりかは「まし」ですかね。

・追加された「GroupBoard Workspace」サイト テンプレート


・タイムカード


・組織図


設定のユーザーインタフェースは少々判り辛いですが、従来のフラットなユーザー一覧よりは判りやすくなるかな。
但し、ユーザー数が物凄い多いサイトには向いていません。　もちろん、通常はそういうサイトでは GroupBoard Workspace を使わないと思いますが・・・

　早速、セットアップしてみたものの・・・

が〜ん、既存の Beta2 をアップグレードしてみたら失敗した。
どうやら、テスト・検証目的で、変な Web アプリケーション (IIS Web サイト) を作りっ放しだったのがいけなかったようです。
泣く泣く、OS から再セットアップしました。　クリーンインストールなら、全く問題無しでした。
その後、Virtual Server 上の仮想 PC で動かしていた、スタンドアロン環境については、Beta2 からのアップグレードでも問題無く Beta2 TR になりました。

ちょっとイレギュラーなものがあると、アップグレードに失敗する可能性があるようです。
予め削除すると良さそうです。

最初に接する管理画面などでは、若干のレイアウトが変わったり、メニュー項目がちゃんと日本語になっていたりしました。
サイト テンプレートでも、Web コンテンツ管理機能を活かしたものが加わっていました。

それ以外の機能は、これからボチボチ触ってみる予定です。

　さてさて、β2のセットアップを終えて、いろいろ触り始めたので画面イメージと共に、気がついた点をレポートしたいと思います。

・ポータルサイトの「ホーム」ページ

これが、新しい SharePoint Server 2007 のポータルサイトの「ホーム」ページです。　SPS 2003 から雰囲気が結構変わっています。

・「サイトの操作」メニュー

右上の「サイトの操作」メニューを表示させたところです。　SPS 2003 では、左側のサイドバー上に表示されていた「操作メニュー」に変わって、このようなメニュー形式に変わりました。
ちなみに、アクセスしているユーザーの権限によって、メニューの表示項目もちゃんと変わります。

・「サイトの設定」ページ

「サイトの設定」ページは、SPS 2003 に比べると随分すっきり見通しが良くなっています。　機能が増えた分、メニュー項目も随分増えているように思われます。

・新しいサイトの作成

「サイト」ページから、新しいチームサイトを作ってみます。


「新しい SharePoint サイト」ページの下半分です。　SPS 2003 と違って、1枚のページで全ての設定を行った上で、サイトの作成が出来るようになっています。
「ブログ」とか「WiKi」などのテンプレートの種類が増えていることが判ります。

・チームサイトの「ホーム」ページ

そして、これが SharePoint Server 2007 のチームサイトの「ホーム」ページです。　一見すると SPS 2003 とあまり変わらないですね。
でも、良く見ると、ポータルサイトのナビゲーションバーが含まれていますし、パンくずリストが表示されています。　SPS 2003 では、ポータルサイトとチームサイトはそれぞれ別のサイトとして構成することしか出来ませんでしたが、SharePoint Server 2007 では、SPS 2003 のエリアを作成する感覚でチームサイトを作成することが出来ます。　言うなれば、エリアとサイトのテンプレートが統合された感じです。　もちろん、従来通り単独のチームサイトとして作成することも出来るようです。
SPS 2003 の頃も、アーキテクチャとして WSS 2.0 の上に構成されたものでしたが、統合度合いが今1つ中途半端な感じがしましたが、MOSS 2007 における WSS 3.0 との統合度合いはかなり高まっているように見受けられます。

・ドキュメント ライブラリの「すべてのドキュメント」ビュー

今度は、ドキュメント ライブラリの「すべてのドキュメント」ビューにアクセスしてみます。　左側のナビゲーションバーがそのまま表示されていて、ツールバーのスタイルも変わっていますね。
ビューの切り替えはツールバーの右端のメニューで切り替える形になっています。

・ドキュメント ライブラリのツールバーのメニュー

そして、ツールバー上のメニューを表示させたのが、こちらです。　このようなツールバー + メニュー機能のお陰で、機能が増えた割にはすっきりとした構成になっています。
ちなみに、これらもアクセスしているユーザーの権限によって、メニューの表示項目もちゃんと変わります。

・ドキュメント ライブラリの「カスタマイズ」ページ

実際に、「ドキュメント ライブラリの設定」にアクセスしてみました。　「サイトの設定」ページと同様に、カテゴライズされたメニューが横に並んでいる分、メニュー項目が増えていてもすっきりとした感じがします。


「カスタマイズ」ページの下半分です。　下半分は SPS 2003 とそれほど変わりないかな。

今回はここまで。　まだまだ、ほんの一部ですが、雰囲気はお判り頂けたでしょうか。

　暇を見つけては、β2のセットアップにチャレンジ中です。
関係ありませんが、SharePoint Server 2007 は略称は MOSS になるようです。

セットアップを行う際には、setup.exe を起動後、プロダクトキーを入力して、ライセンス条項に同意してから、「インストールの種類」にて「基本」を選ぶのがお薦めです。
「基本」を選ぶと、SQL Server 2005 Express Edition がデータベースエンジンとして組み込まれ、その他の以下の項目が自動的に構成されます。

• 構成ウィザードのパラメータ設定
• サービスの割り当て
• 共有サービス Webアプリケーション作成
• サイトコレクション用のWebアプリケーション作成
• サイトコレクションの作成

SharePoint 2007 では柔軟な構成が組める分、SPS 2003 に比べると構成は少々面倒です。　当面の機能面の評価を行う際には、この「スタンドアロン」構成がお手軽です。

ちなみに、詳細の手順はこちらにあります。

・Deploy Office SharePoint Server 2007 (Beta 2) on a single server
<http://officebeta.iponet.net/en-us/techcenter/HA100337691033.aspx>

　実はまだ続けています。　(→ クロール時間の短縮の考察)
その後、以下のページにある他の IFilter についても調べた結果です。

・Microsoft SharePoint Portal Server - IFilter
<http://www.microsoft.com/japan/sharepoint/server/downloads/IFilter.asp>

以下の IFilter については、シングルスレッド動作と見られるため、レジストリの WSSSingleThreadedFilterExtensions に加える必要があります。

・Visio 2003 IFilter
<http://www.microsoft.com/downloads/details.aspx?FamilyId=DCEE9E09-448B-4386-B901-EFEA29CAC808&displaylang=ja>
ちなみに、Visio 2003 をインストールした場合にも、こちらの IFilter が自動的に入ります。

・DocuWorks 用 IFilter
<http://www.fujixerox.co.jp/soft/docuworks/download202.html>
MSのページではリンク切れとなっています。

なお、OASYS 用 IFilter は見つけられず未調査です。　一太郎用は素晴らしいことにマルチスレッド対応です。　ジャストシステム頑張っています。

ということで、レジストリには以下のように設定しておくと良いのかも知れません。
pdf;xdw;vsd;vss;vst;vdx;vsx;vtx

実際には、全て組み込むことはあまり無いと思いますけど・・・

　こちらの記事 (→ クロール時間の短縮の検証) で判明した効果に対する考察です。

・SharePoint Portal Server 2003 のサードパーティのシングルスレッド IFilter を使用する場合、クロールは、クロール完了により長い時間かかります。


こちらの技術情報に記載の通り、再試行が発生する点と再試行までの間に待ち時間が発生するようで、これによってクロール時間が長くなるようです。　実際に、タスクマネージャで CPU 利用率を見ていると、マルチスレッドで動作する IFilter が処理している間は、CPU をほぼフルフル使っていますが、シングルスレッドで動作する IFiler が処理し始めると、途端に CPU はほとんど使われない状態が続きます。

つまり、PDF などのシングルスレッド動作の IFilter が対象とする ファイル数×(再試行＋待ち時間) だけ、クロール時間が長くなってしまうということになります。

tags: SharePoint

　早速、こちらの記事の (→ クロールに掛かる時間の短縮) の技術情報で、どの程度の効果が見られるか検証してみました。
結論からすると、PDFファイルがそれなりのファイル数格納されている場合は、かなり「効果あり」と言えると思います。　むしろ、適用は「必須」とも言えるかも知れません。

○検証環境
ノートPC、Pentium M 1.86GHz、2GB RAM
Windows Server 2003 SP1、SQL Server 2000 SP4、SharePoint Portal Server 2003 SP2

○検証条件
チームサイト1、Wordファイル×100、合計約30MB
チームサイト2、PowerPointファイル×100、合計約93MB
チームサイト3、Excelファイル×100、合計約11MB
チームサイト4、PDFファイル×50、合計約33MB

○検証結果
・PDF追加前 (チームサイト1〜3)、フル更新
→ 32秒、30秒、28秒、30秒、平均30秒

・PDF追加後 (チームサイト1〜4)、レジストリ適用前、フル更新
→ 10分19秒、11分32秒、8分41秒、8分38秒、平均9分48秒

・PDF追加後 (チームサイト1〜4)、レジストリ適用後、フル更新
→ 43秒、40秒、40秒、42秒、平均41秒

見ての通り、レジストリを適用しないと、驚異的？に遅くなります。
そして、レジストリを適用することで、妥当な時間に収まるように見受けられます。

結局の所、事実として PDF Ifilter はシングルスレッド対応だったということですね。

　検索 Web サービスのバグに対する修正モジュール (→ <検索 Web サービスのバグ>) を確認してみました。
適用時にはサーバーの再起動が必要になりますが、確かに修正されていました。

元の記事で、UTF-16 と書いていましたが、少し正確じゃありませんでした。
検索 Web サービスのレスポンス結果の XML 内に埋め込まれている、検索結果 XML は確かにヘッダーには以下のように UTF-16 なんですが、

<?xml version="1.0" encoding="utf-16"?>

実際には、UTF-16 にエンコードされている訳ではありませんでした。
例えば、「チームサイト」という2バイト文字は、以下のような文字コードに展開されています。　何じゃこりゃ？？

C3 A3 C2 83 C2 81 C3 A3 C2 83 C2 BC C3 A3 C2 83 C2 A0 C3 A3 C2 82 C2 B5 C3 A3 C2 82 C2 A4 C3 A3 C2 83 C2 88

ちなみに、UTF-8 では、本来は以下のような文字コードで表されます。

E3 83 81 E3 83 BC E3 83 A0 E3 82 B5 E3 82 A4 E3 83 88

今回の修正モジュールを適用して、レジストリの値を 1 にすると、XML のヘッダーは相変わらず UTF-16 のままですが、2バイトコードについては本来の UTF-8 になってくれるので、正しく処理することが可能になりました。