• [アーティクル]

SharePoint の内部SharePoint インフラストラクチャを構築する

Pav Cherny

この記事で使用しているコードのダウンロード: SharePoint2008_05.exe (412KB)

電子メール メッセージングによってビジネス コミュニケーションが変わったのと同様に、Web ベースのコラボレーションによって、共同作業や情報共有の方法も変化しています。その一例として、SharePoint テクノロジで提供されるものを見てみましょう。Microsoft Windows SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server

(MOSS) 2007 を使用すると、チーム サイト、ポータル、Web コンテンツ管理ソリューション、ドキュメント ライブラリ、および検索センターを作成することができます。また、2007 Microsoft® Office system との統合、XML ベースのフォーム、ワークフロー、モビリティなどがサポートされているのは言うまでもありません。

しかし、SharePoint® の導入は必ずしも簡単とは限りません。用語がわかりにくかったり、システム アーキテクチャが複雑だったりすることがあります。また、SharePoint を使用する場合、IIS、Microsoft .NET Framework、SQL Server®、そして場合によっては他のテクノロジ (たとえば、ビジネス インテリジェンス、InfoPath® Forms Services、Rights Management Services (RMS)、Exchange Server、ForefrontTM Security) などの複数のコンポーネントを扱う必要があります。

SharePoint ソリューションを作成する方法は (組み込みのユーザー インターフェイスを使用して作成するにしろ、プログラムで作成するにしろ) たくさんあるので、統合やカスタマイズを行う際には、すぐに、どうすればよいかがわからなくなってしまう可能性があります。また、SharePoint アプリケーションが機能しない場合、トラブルシューティングは複雑なことがあります。多くの場合、構成要素を理解し、それらの要素がどのように連携するかを理解するには、アプリケーション開発者と同じような思考回路が必要です。このような課題がある中で、堅牢でスケーラブルで管理しやすい SharePoint インフラストラクチャを構築するには、どのような作業から着手すればよいのでしょうか。

このコラムでは、まずアーキテクチャの概要を説明して土台を築き、次に WSS の展開 (ブランド設定に関する非常に基本的なカスタマイズを含む) について説明して、どのように作業を開始すればよいかを示します。WSS 3.0 が提供する、Self-Service Site の管理機能を使用すると、SharePoint インフラストラクチャに対する管理者レベルの集中型制御を維持しながら、SharePoint サイトの作成と管理を行う権限を個々のユーザーに委任する方法がわかります。

最初に SharePoint アーキテクチャを説明することにより、柔軟でスケーラブルなインフラストラクチャを実装するのに必要な展開手順と構成手順が理解しやすくなります。では、まず依存関係を見てから、WSS 3.0 の展開について説明しましょう。展開に関する詳細な指示については、付属リソースを参照してください。このリソースは、TechNet Magazine Web サイト (technetmagazine.com) のダウンロード セクションで提供しています。

SharePoint アーキテクチャ

SharePoint テクノロジに関しては、システム アーキテクトの視点から考えるのが有効です。具体的な全詳細を知る必要はありませんが、SharePoint アーキテクチャに起因する全般的な依存関係を理解しておくと、何を構成する必要があり、その理由は何であるかをより早く予測することができるので、より早く解決策を導き出すことができます。

SharePoint は、Web アプリケーションと Web サイトを提供するテクノロジです。SharePoint は IIS ベースの Web サイト ソリューションで、ASP.NET を使用して IIS と統合され、バックエンドでは構成データとコンテンツの格納に SQL Server データベースが使用されます。つまり、SharePoint の中核は、3 つの異なるアーキテクチャ (IIS、.NET、および SQL Server) を組み合わせたものです (図 1 参照)。

Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0

Figure 1** WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0 **(画像を拡大するには、ここをクリックします)

この図を見て及び腰にならないでください。構成要素の数だけを考えると、アーキテクチャは手に負えないものに見えるかもしれません。しかし、これらの構成要素はすべて、論理的なフレームワークに収まっているので、このフレームワークを体系的に観察すると、構成要素の依存関係を理解することができます。

この図が示しているように、SharePoint では、IIS と ASP.NET を使用して HTTP 要求と HTTP 応答を処理します。つまり、要求が ASP.NET ISAPI フィルタ (aspnet_isapi.dll) に着信するまでは、HTTP カーネル モード ドライバ (http.sys) やワーカー プロセス (w3wp.exe) などの標準的な IIS コンポーネントによって、要求のキューへの格納や要求の転送が行われます。.NET Framework をインストールすると、セットアップ処理の一環として、次のように aspnet_isapi.dll が IIS メタベース (C:\Windows\System32\Inetsrv\metabase.xml) に登録されます。

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

IIS で ASP.NET ISAPI フィルタが読み込まれると、Web サイトに着信する要求はすべて ASP.NET に渡すことができます。SharePoint では、どこかの時点で ASP.NET を使用してこのような要求を受信する必要があるので、これは重要です。これを実現するために、SharePoint は、ワイルドカード アプリケーション マップを追加して、特定の Web サイトの構成を拡張します。ワイルドカード アプリケーション マップを使用すると、ファイル名拡張子にかかわらず、すべての着信要求が ASP.NET ISAPI フィルタに転送されます。

ワイルドカード アプリケーション マップは、基本インストール オプションを使用して WSS 3.0 をインストールすると IIS マネージャで確認できます。WSS のセットアップ処理の一環として、サーバー上に既に存在する既定の IIS Web サイトが非アクティブになり、ASP.NET ワイルドカード アプリケーション マップが定義されている (図 2 参照) 新しい既定の Web サイトがポート 80 に作成されます。

Figure 2 Wildcard application map for ASP.NET ISAPI filter

Figure 2** Wildcard application map for ASP.NET ISAPI filter **(画像を拡大するには、ここをクリックします)

ASP.NET から SharePoint に要求を渡すには、SharePoint はカスタムの HttpApplication オブジェクトによって HTTP 要求パイプラインも拡張する必要があります。このオブジェクトは、Microsoft.SharePoint アセンブリの SPHttpApplication というクラスによって実装されます。このカスタム アプリケーション オブジェクトは、ASP.NET アプリケーション ファイル (global.asax) に定義されます。このファイルは、SharePoint で拡張された Web サイトのルート フォルダのファイル システム内にあります。次のコードは、このような global.asax ファイルの内容を示したものです。

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

このファイルは ASP.NET によって動的に解析およびコンパイルされ、SharePoint アプリケーション オブジェクトのインスタンスが作成されます。

受信した要求ごとに、BeginRequest、AuthenticateRequest、ProcessRequest、EndRequest など、Web アプリケーションが処理できる一連のイベントがトリガされます。イベント処理の詳細は SharePoint の展開と管理という範囲を超えていますが、global.asax で SPHttpApplication クラスが指定されるだけでなく、SharePoint ではサイトの web.config ファイルで定義されたカスタムの HTTP ハンドラと HTTP モジュールを実装する、ということを知っておくことは重要です。たとえば、SharePoint では、SPRequestModule クラスに基づいた HTTP モジュールを使用します。このモジュールは、標準的な ASP.NET モジュールよりも前に最初の HTTP モジュールとして登録されます。SPRequestModule クラスでは、ASP.NET で SPVirtualPathProvider コンポーネントを登録することなどによって、SharePoint のランタイム環境を初期化します。SPRequestModule は SharePoint 内部で使用するクラスですが、SharePoint ソリューション開発者は、web.config ファイルを変更して、カスタムの HTTP ハンドラと HTTP モジュールなどの追加コンポーネントを登録することができます。SharePoint では、カスタムの HTTP モジュールと標準的な HTTP モジュールの両方を使用して、SharePoint アプリケーションへのすべての要求に対する厳格な制御を維持しながら ASP.NET を利用します。

SharePoint 3.0 サーバーの全体管理サイトを使用して Web アプリケーションを作成すると、特定の IIS Web サイトに ASP.NET ワイルドカード アプリケーション マップが追加され、global.asax ファイルと web.config ファイルが Web サイトのルート フォルダに作成されます。各 Web アプリケーションには、そのアプリケーションのルート フォルダにある専用の global.asax ファイルと web.config ファイルを使用します。

要求を処理して意味のある情報をブラウザに返すために、WSS 3.0 と MOSS 2007 では、標準的な ASP.NET ページ パーサーを使用します。このパーサーは、要求された ASP.NET ページをコンパイルするか、コンパイルを行わないモードで処理します。しかし、SharePoint から ASP.NET パーサーに渡される ASP.NET ページは、必ずしも想定される場所にあるとは限りません。たとえば、SharePoint で拡張された Web サイト (SharePoint 3.0 サーバーの全体管理サイトなど) のルート フォルダには default.aspx ファイルは存在しませんが、Web サイトのホーム ページを表示する際に開かれるのは default.aspx です。ページのコンテンツをローカル ファイル システムまたは SQL Server コンテンツ データベースから読み込んで仮想ファイルとして ASP.NET ページ パーサーに渡し、環境を仮想化するのは、SPVirtualPathProvider コンポーネントです。サーバーの全体管理サイトを表示する際、SharePoint では C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin フォルダにある default.aspx ファイルを読み込んでいます。

ホーム ページと他のほとんどの SharePoint サイト ページは、メニューとナビゲーション コントロールの共通レイアウトが実装されている ASP.NET マスタ ページ (default.master) にリンクされています。default.master ページは C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global フォルダ内にあります。このページには、ローカル ファイル システムまたは SQL Server コンテンツ データベースにも登録できる追加のコンテンツ ページに使用できる名前の付いたプレースホルダが含まれています。重要なのは、Web ブラウザで SharePoint サイトを開くと、一連のコンテンツ ページから取得した情報が表示され、これらのページは必ずしもローカル Web サーバー上に存在するとは限らず、マスタ ページで定義されたレイアウトに従って並んでいる、ということです。

原則として、変更されていないページ (SharePoint 用語では、カスタマイズされていないページ) はページ テンプレートとしてすべての SharePoint サーバーのローカル ファイル システムに存在しますが、カスタマイズされたページは、Web ファーム内のすべての SharePoint サーバーが同じ一連のページにアクセスできるように、コンテンツ データベースに書き込まれます (図 3 参照)。カスタマイズされていないページは、Web ファーム内のすべてのサーバーとサイトで同じであることが想定されています。しかし、Office SharePoint Designer 2007 などを使用して、SharePoint サイトのコンテンツ ページやマスタ ページをカスタマイズすると、カスタマイズされたページは自動的にコンテンツ データベースに格納されます。

Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application

Figure 3** Uncustomized and customized ASP.NET pages in a SharePoint application **(画像を拡大するには、ここをクリックします)

カスタマイズされたページや他の Web サイト コンテンツだけでなく、構成データも SQL Server データベースに格納されます。構成データは本質的にグローバルで、コンテンツは個々の Web アプリケーションやサイト コレクションに固有のものであるので、構成データはコンテンツとは別個に格納されます。したがって、1 つの Web ファームに用意できる構成データベースは 1 つだけですが、コンテンツ データベースは複数用意することができます。

Web ファーム内のすべての WSS サーバーでは、同じ構成データベースを使用して、メタデータ、構成設定、および Web ファーム内の SharePoint で拡張されたすべての IIS Web サイトに関する情報を共有します。一方、個々の Web アプリケーションは、1 つまたは複数のコンテンツ データベースと関連付けることができます (ただし、各コンテンツ データベースは 1 つの Web アプリケーションとしか関連付けることができません)。

IIS Web サイト、Web アプリケーション、サイト コレクション、サイト、およびコンテンツ データベースの関係は、わかりにくいことがあります。SharePoint 用語では、SharePoint で拡張された IIS Web サイトを Web アプリケーションと呼びます。Web アプリケーションには複数のサイト コレクションを含めることが可能で、各サイト コレクションには同じ構成設定を共有するトップレベル サイトとサブレベル サイトを含めることができます。

特に重要なのは、複数のサイト コレクションを作成すると、サイト コレクションの管理をさまざまなユーザーやグループに委任できるということです。1 つのサイト コレクションで複数のコンテンツ データベースを使用することはできませんが、複数のサイト コレクションがある場合、Web アプリケーションでは複数のコンテンツ データベースを使用することで、スケーラビリティを向上させ、他の SharePoint サイトで大量のデータベース処理を発生させる大規模なサイトが与えるパフォーマンス上の影響を軽減することができます。ただし、すべての SharePoint サイトを独自のサイト コレクションに配置すると、クロスサイト機能が制限されるので、このような展開はお勧めしません。

WSS 3.0 では、複数のサイト コレクションを対象としたコンテンツ検索はサポートされていません。このような検索を行うには、MOSS 2007 または Microsoft Search Server 2008 を使用する必要があります。たとえば、ファーム管理者は http://contoso 用の Web アプリケーションとトップレベル サイトを作成することができます。その後、サイト コレクション管理者は、SharePoint ユーザー インターフェイスを使用して、http://contoso/info、http://contoso/events などのサブレベル サイトを作成することができます。これらのサイトはすべて、同じサイト コレクションに属するので、同じコンテンツ データベースに格納されます。

ファーム管理者は、/sites などの管理パスを使用して、追加のサイト コレクション (http://contoso/sites/IT、http://contoso/sites/HR など) を SharePoint 3.0 サーバーの全体管理で定義することもできます。この 3 つのサイト コレクション (http://contoso、http://contoso/sites/IT、および http://contoso/sites/HR) には、異なるサイト コレクション管理者、構成設定、およびコンテンツ データベースを採用することができますが、3 つとも同じ IIS Web サイト (http://contoso) を通じてアクセスされ、Web アプリケーションのアプリケーション プール ID も同じものを使用します。

もちろん、詳細は他にもいろいろありますが、SharePoint に慣れるには、この IIS、ASP.NET、および SQL Server の関係を理解することが特に重要です。SharePoint アーキテクチャの詳細については、Ted Pattison が執筆した MSDN® Magazine の記事「SharePoint Services における開発作業の大幅な強化について」(msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview) を参照することをお勧めします。

SharePoint インフラストラクチャの構成要素

では、アーキテクチャについての簡単な説明から、柔軟な SharePoint インフラストラクチャについての説明に移りましょう。既にお気付きのことと思いますが、必要なのは、Windows Server®、IIS、.NET Framework 3.0 (ASP.NET と Windows® Workflow Foundation が必要なため)、WSS 3.0 と MOSS 2007 のどちらか、および SQL Server です。Windows Server 2008 で IIS 7.0 を使用することを期待していらっしゃるかもしれませんが、ここでは、この記事を執筆している時点で最もよく展開されているバージョンである Windows Server 2003 と IIS 6.0 を使用します。また、初めて SharePoint のパイロット展開を行う際には MOSS 2007 固有の機能は必要ないので、引き続き WSS 3.0 を使用します。

必要最低限の機能を実現するには、WSS 3.0 と必要なすべてのコンポーネントを 1 台のコンピュータにインストールします (このコラムの付属リソースに含まれている WSS 3.0 on a single computer.pdf 参照)。ラボ サーバーや小規模なワークグループ環境の場合は、これで十分です。しかし、柔軟な SharePoint インフラストラクチャが必要な場合、運用環境ではスタンドアロンの展開を使用しないことをお勧めします。可用性と将来のスケーラビリティを確保するには、多層インフラストラクチャを導入して、必要に応じてサーバーを追加することをお勧めします。

図 4 は、簡単で柔軟なシステム構成が必要な方にお勧めの SharePoint インフラストラクチャを示しています。このインフラストラクチャには、2 台の SharePoint サーバーで構成される Web ファームと、SQL Server を実行している別の 1 台のコンピュータが含まれています。この構成を使用すると、Web サーバーのデータベース処理オーバーヘッドが解消され、可用性とスケーラビリティが向上し、システムのメンテナンスが容易になります。Active Directory® が必要なことに注意してください。Active Directory は、WSS 3.0 を Web ファームで展開する場合のソフトウェア要件です。展開に関する一連の手順については、付属リソースに含まれている Basic SharePoint Infrastructure.pdf ファイルを参照してください。

Figure 4 Basic SharePoint infrastructure that can accommodate future growth

Figure 4** Basic SharePoint infrastructure that can accommodate future growth **(画像を拡大するには、ここをクリックします)

SharePoint をこのような形で展開するのに使用するドメイン アカウントは、Web サーバーのローカル管理者の権限を持っている必要があります。また、このアカウントを SQL Server ロールの dbcreator と securityadmin に追加し、SQL Server 2005 の master データベースのデータベース ロール db_owner にも追加する必要があります (Basic SharePoint Infrastructure.pdf 参照)。その後、WSS 3.0 のインストール中に SharePoint 製品とテクノロジ構成ウィザードを使用して、Web サーバー ファームに必要な構成データベースと SharePoint 3.0 サーバーの全体管理サイト用のコンテンツ データベースを作成することができます。これらのデータベースをインストール時に作成しなかった場合は、SQL Server 管理者がこれらのデータベースを用意して WSS システム アカウントを db_owner ロールに追加する必要があります。

SharePoint をインストールする際に使用するユーザー アカウントは、SharePoint がサーバーの全体管理サイトの構成データベースやコンテンツ データベースにアクセスする際に使用するアカウントではないということを覚えておいてください。SharePoint がデータベースへのアクセス時に使用するのは、SharePoint 3.0 サーバーの全体管理サイトのアプリケーション プール ID として構成されたシステム アカウントです。

SharePoint 製品とテクノロジ構成ウィザードでは、アカウント情報の入力を求められます。CONTOSO\WssConfigAdmin など、専用のドメイン ユーザー アカウントを使用することをお勧めします。私は通常、後から追加で作成した Web アプリケーションごとに、別個の専用ユーザー アカウントを使用するようにしています。Web アプリケーションごとに別個のアプリケーション プールを使用することはプロセスを確実に分離するのに役立ち、アプリケーション プールごとに異なるユーザー アカウントを使用することはセキュリティの分離を維持するのに役立ちます。ただし、これは 1 つのやり方にすぎず、管理のしやすさと潜在的なパフォーマンス上の影響は、各自の環境要件やビジネス要件に基づいて評価する必要があることに注意してください。

ドメイン管理者が作成する必要があるもう 1 つの重要なシステム アカウントは、Search サービス アカウントです。サーバーの全体管理のアカウントを使用することもできますが、セキュリティを強化するには、管理者権限を持っておらずコンテンツを変更できない専用の Search サービス アカウント (CONTOSO\WssSearch など) を使用することをお勧めします。Search サービスはインデックスを作成するためにコンテンツをクロールしますが、検索データを別のデータベースに保存するので、コンテンツ データベースへの書き込み権限は必要ありません。

サーバー ファームで Web アプリケーションを作成する場合は、このコンテンツ データベースを検索サーバーと関連付けることができます。関連付けを行うと、検索サーバーによって、対応する Search サービス アカウントが Web アプリケーションの "すべて読み取り" ポリシーに暗黙的に追加されます。検索サーバーは、Windows SharePoint Services Search サービスを実行している SharePoint サーバーです。Basic SharePoint Infrastructure.pdf ファイルに記載されている一連の手順を実行すると、両方の Web サーバーが検索サーバーとして構成されるので、複数のコンテンツ データベースのクロールとインデックス作成による負荷を分散させることができます。ただし、クライアント接続がクロール処理の影響を受けないように、ネットワーク負荷分散やクライアント接続に使用しない Web ファームで専用の検索サーバーを構成することも可能です。

Self-Service Site の管理

基本的な SharePoint インフラストラクチャを使用すると、Active Directory、Web サーバー ファーム、または SQL Server データベースに対する管理者レベルの制御を分散させることなく、サイト コレクションやサイトの管理を個々の部門や個々のユーザーに委任できます。ファーム管理者は、Active Directory の管理者と SQL Server の管理者と協力して、Web アプリケーションで使用するアプリケーション プール アカウントやコンテンツ データベースを用意します。その後、このような Web アプリケーション内で、サイト コレクションを作成したり、サブレベル サイトを作成する権限を持ったサイト コレクション管理者を指定したりします。これにより、各部門のサイト コレクション管理者は、IT 部門の関与を最小限にとどめて SharePoint リソースを管理することができます (図 5 参照)。

Figure 5 Decentralized site administration in a centralized SharePoint infrastructure

Figure 5** Decentralized site administration in a centralized SharePoint infrastructure **(画像を拡大するには、ここをクリックします)

また、ユーザーが管理パス (/sites というパスや、SharePoint 3.0 サーバーの全体管理で作成できる、ワイルドカードが含まれた管理パスなど) の下にサイト コレクションを作成できるようにすることもできます。Web アプリケーションで Self-Service Site の管理機能を有効にすると、ユーザーは、独自のサイト コレクションを作成したり、SharePoint ユーザー インターフェイスを使用してサイト グループや権限を管理したりすることができます。サブレベル サイトとは異なり、サイト コレクションは権限を親サイトから継承しません。

Self-Service Site の管理は、すべての SharePoint 環境に適しているわけではないので、既定では無効になっています。この機能を有効にすると、コンテンツ データベース内に、ほとんど使用しないサイト コレクションがたくさん作成されてしまう可能性があります。しかし、この機能を使用すると SharePoint の管理の柔軟性を鮮明に体感できるので、パイロット展開で試してみることをお勧めします (また、SharePoint には、非アクティブなサイトを必要に応じて削除できるように、非アクティブなサイトをユーザーと管理者の両方またはどちらか一方に通知するオプションがあります)。付属リソースに含まれている Enabling Self-Service Site Management.pdf ファイルで説明されているように、Web アプリケーションで Self-Service Site の管理機能を使用するには、明示的に有効にする必要があります。

SharePoint のカスタマイズとブランド設定

SharePoint の関連リソース

この段階に至ると、企業のロゴ、企業名、および企業のイメージ カラーを SharePoint ユーザー インターフェイスに含めたくなるのは自然なことです。しかし、それは ASP.NET 開発者レベルの作業であることに注意してください。運用環境に影響を与えることなくカスタマイズを行い、その結果をテストできるようにするには、少なくとも、Microsoft Office SharePoint Designer 2007 がインストールされたスタンドアロンの WSS 3.0 サーバーなどの開発システムが必要です (付属リソースに含まれている SharePoint Designer Installation.pdf 参照)。また、Windows SharePoint Services デベロッパー センター (msdn2.microsoft.com/sharepoint) にアクセスして、SharePoint に用意されている豊富なカスタマイズ オプションについて学習する必要があります。

SharePoint 開発はこのコラムの対象範囲外ですが、考慮する必要がある点をいくつか挙げておきます。SharePoint では、カスタマイズされたページは対応するサイト コレクションのコンテンツ データベースに格納されます。つまり、SharePoint サイトのサイト ページ、アプリケーション ページ、マスタ ページ、スタイル シートなどに適用したカスタマイズは、サイト コレクション レベルまたはサイト レベルでしか適用されません。これは、SharePoint Designer 2007 を使用してサイトの外観を調整する個々のサイト コレクション管理者にとっては好都合ですが、Web ファーム内のすべての Web アプリケーション、サイト コレクション、およびサイトに企業独自の要素を適用する必要があるファーム管理者にとってはあまり好都合ではありません。

標準的な SharePoint テーマやサイト定義のコピーを基にして、カスタムのサイト テーマやカスタムのサイト定義を作成することができます。カスタムのマスタ ページを作成して、それをマスタ ページ ギャラリーに追加することもできます。ただし、Self-Service Site の管理が有効になっていると、サイト コレクションやサイトを作成する権限を持ったユーザーは、企業独自の要素が含まれていない標準的なサイト テンプレートを選択することができるので、これらの方法を使用しても Web ファーム全体でのブランド設定は実現されません。

Web ファーム全体でのブランド設定を実現するには、既定の SharePoint コンポーネントをカスタム コンポーネントに置き換えて、カスタム コンポーネントが既定のコンポーネントとして使用されるようにする必要があります。元のファイルを変更することなくこれを実現するためなら、開発者はどんな苦労も惜しみません。1 つの方法は、IIS マネージャの仮想ディレクトリの構成を変更して、カスタマイズされたファイルが格納されている新しいフォルダを参照するようにすることです。もう 1 つの方法は、特定の既定ページに対する要求をカスタマイズされたバージョンにリダイレクトするように URL を書き換えるカスタムの HTTP モジュールまたは ISAPI フィルタを実装することです。

まとめ

この記事では、WSS 3.0 を使用して SharePoint インフラストラクチャを構築する方法の要点を説明しました。これに関連しない機能 (ワークフロー、アンケート、メッセージングの統合、ウイルス対策など) や MOSS 2007 固有の機能 (ポータル、サイト ディレクトリ、ビジネス データ カタログなど) は取り上げませんでした。また、サイト管理や企業のブランド設定に関するカスタマイズについて説明しましたが、これは SharePoint が秘めている潜在能力の一端を紹介したにすぎません。Visual Studio® でカスタム アプリケーションを作成すると、WSS 3.0 をさらにカスタマイズすることができます。

SharePoint は堅牢なインフラストラクチャを備えているので、後から Web サーバーやデータベース サーバーを追加して、拡張することができます。また、少しカスタマイズしたパイロット版を展開すると、ユーザーは個々のサイトを作成することができ、一般に SharePoint について理解することができます。このようにして、ハードウェアやソフトウェアだけでなく、この重要なコンポーネントをユーザーに定着させることができます。また、パイロット展開は、変化に適応する柔軟性を備え、運用環境への本格的な展開を行うための基盤としての役割を果たします。

Pav Cherny は、主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイト ペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、Biblioso Corporation の代表取締役です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.