グループ作業サイトの論理アーキテクチャを設計する

この記事の内容 :

• イントラネット環境内のチーム サイトについて

• チーム サイト設計における推奨事項

• 専用 Web アプリケーションでチーム サイトをホストする

• Web アプリケーションの全般設定を計画する

• サイト作成方法を計画する

• チーム サイトのコンテンツ データベース設定を設計する

• 使用されていないサイトを自動的に削除する

• パスまたはホスト名を使用してチーム サイト URL を整理する

• カスタム要素のための計画を行う

• チーム サイトに適用する権限を計画する

Microsoft Office SharePoint Portal Server 2003 の場合、チーム サイトの機能はポータル サイトに比べると制限されていました。しかし Microsoft Office SharePoint Server 2007 の場合、そのような限界はありません。Office SharePoint Server 2007 では、公開されたイントラネット ポータル サイトの機能がイントラネット環境で利用できるようになっていれば、イントラネット環境内のグループ作業サイトもそれらの機能を活用できます。この記事では、このようなサイトのことを、「チーム サイト」という以前の用語で呼ぶことにします。ただし、旧バージョンのような機能上の制限がこれらのサイトにあるわけではありません。「チーム サイト」という用語には、公開され管理されたイントラネット ポータル サイトとは異なる、小規模のグループや特別なグループ作業で使用されるサイトであるという意味があります。

チーム サイトは大半の Office SharePoint Server 2007 の展開における重要な要素であり、イントラネットの展開では特に重要です。チーム サイトが可能とするグループ作業とチーム サイトが提供する記憶域は、長期と短期の両方のプロジェクト、通信、およびグループ間グループ作業に役立ちます。展開の一部としてチーム サイトを提供する予定である場合には、チーム サイトのホスティングと管理を計画できるよう、アーキテクチャ設計時に組み込んでください。たとえば、チーム サイト コンテンツのホスティングに必要なコンテンツ データベースについて計画し、より多くのプロジェクトを扱えるよう短期プロジェクト チーム サイトのアーカイブや削除を計画し、チーム通信サイトがバックアップと復旧を行いやすいサイズであるよう監視します。

この記事は、サーバー ファーム内にチームサイトを展開する際の論理アーキテクチャ設計に関する推奨事項を記載しています。チーム サイトの情報アーキテクチャ、つまり内部構造、については触れません。情報アーキテクチャの設計の詳細については、「Web サイトの構造および公開を計画する (Office SharePoint Server)」を参照してください。チーム サイトの詳細については、「グループ作業サイトを計画する」を参照してください。

イントラネット環境内のチーム サイトについて

Office SharePoint Server 2007 イントラネット環境では、サイト ディレクトリにリストすることによって、チーム サイトを公開イントラネット ポータル サイトに接続できます。公開サイトのサイト ディレクトリを通じてチーム サイトを作成すればすべてのチーム サイトに同じホスト名を共有させることができ、既存サイトをサイト ディレクトリに追加すれば関連するチーム サイトすべてを一カ所にまとめることができます。こうすることにより、URL に関係なく、チーム サイトは公開イントラネット ポータルの一部のように見えます。

チーム サイトは環境内のあらゆる公開サイトと同じ機能を持つ SharePoint サイトであるので、環境で利用できるビジネス インテリジェンス、フォームなどの機能も使用することができます。これらの機能は、チーム サイトのアーキテクチャに影響を及ぼします。たとえばチーム サイトのビジネス データ カタログに入っているデータを表示するには、そのチーム サイトのメンバがデータにアクセスし表示できることを確保する必要があります。ビジネス インテリジェンス機能とセキュリティは Shared Services Provider (SSP) レベルで構成されるので、同一のビジネス データに接続するチーム サイトはすべて同一の SSP を使用する必要があると共に、その SSP に関連付けられている Web アプリケーションに存在している必要があります。

環境におけるビジネス インテリジェンスとフォームの計画の詳細については、下記を参照してください。

• ビジネス インテリジェンスを計画する

• InfoPath Forms Services を計画する

チーム サイト設計における推奨事項

ほとんどの組織ではチーム サイトの数もサイズも増加の一途をたどり、ときにはかなり早い速度で増えることもあります。チームの再編成やプロジェクトの完成や新しいプロジェクトの開始が行われるたびに、古いチーム サイトが放置されたまま新しいチーム サイトが作られたり、データをどんどん詰め込んでチーム サイトが膨張していきます。こういった増大を管理し制御するには、チーム サイトのサポートを慎重に計画する必要があります。

チーム サイトの設計目標には、以下があります。

• サーバー ファーム全体のパフォーマンスを最適化します。

• メンテナンス (バックアップ、復旧、アップグレード) を目的としてチーム サイトのデータベースを論理的に分割します。

• イントラネット内にある他のタイプのサイトに影響を及ぼさずにチーム サイトのポリシーと設定を適用できるようにします。

チーム サイトの設計指針としては、以降のセクションでそれぞれ詳述する次の推奨事項があります。

• 専用 Web アプリケーションでチーム サイトをホストします。

• チーム サイトの増大を管理しコンテンツを最新内容に維持するため、クォータまたはライフ サイクルの管理設定など、Web アプリケーション全般設定を Web アプリケーション レベルで適用します。

• 適切な記憶域と規模を確保すること、および設定したサイズのデータベースのバックアップと復元が確実に行えること、を目的として、コンテンツ データベース設定を設計します。

• 使用されていないサイトを自動的に削除します。

• パスを使用してチーム サイト URL を整理します。

• 適切なポリシーと権限を計画します。

専用 Web アプリケーションでチーム サイトをホストする

チーム サイトのホスティングは、専用 Web アプリケーションにおいて行うか、個人用サイトと共有する Web アプリケーションにおいて行います。公開イントラネット ポータル サイトと同じ Web アプリケーションではチーム サイトのホスティングを行わないことをお勧めします。イントラネット ポータル サイトとチーム サイトを分離した方が、データの復旧とメンテナンスが容易です (コンテンツ データベースのサイズを管理している場合には、この点はそれほどの問題ではありません)。下図は、イントラネット ソリューションのチーム サイトを含んでいる Web アプリケーションを示しています。

複数の専用 Web アプリケーションをチーム サイトのホスティングに使用したい状況が発生する可能性があります。次の例について考えてみます。

• ある米国の投資銀行株式調査企業では、証券取引委員会の規定に準拠するため、投資銀行部門のサイトと株式調査部門のサイトを完全に分離させている必要があります。この企業の場合、2 部門用として 2 つのチームサイト コレクションを備えた 2 つの Web アプリケーションを使用する必要があります。また、一方の部門が作成したコンテンツを他方の部門のユーザーが見ることがないよう、Web アプリケーション ポリシーと別々の SSP を使用する必要もあります。

• ある調査製造企業では、その知的財産と調査結果を厳しく管理する必要があります。この企業の場合には、別の Web アプリケーションで調査チーム サイトをホストすると共に、Web アプリケーション ポリシーを使用して各種権限を適用し、調査チーム サイトのコンテンツを調査部員以外が見ることがないようにします。

• ある組織では、内部 (イントラネット) と外部 (エクストラネット) の両方のチーム サイトをホストしていますが、両者の実装と管理を別々に行いたいと考えています。この組織の場合、2 組のチームサイトをホストするため 2 つの Web アプリケーションの計画と実装を行い、問題発生時に備えて、環境別の認証方法、データベース、IIS ログを持つようにします。エクストラネットの計画の詳細については、「エクストラネット ファーム トポロジを設計する (Office SharePoint Server)」を参照してください。

一般的に、専用の Web アプリケーションは以下の目的で使用します。

• 匿名コンテンツと認証コンテンツを区別します。

• ユーザーを隔離します。

• 権限を適用します。

• パフォーマンスを最適化します。

• 管理性を最適化します。

共有 Web アプリケーションと専用 Web アプリケーションのどちらを使用するかの決定の詳細については、「論理アーキテクチャ モデル : 企業展開」を参照してください。

パフォーマンスについて考慮する

専用 Web アプリケーションでチーム サイトをホストしている場合には、チーム サイト コレクションだけで構成されるコンテンツ データベースがいくつか存在することになります。Microsoft SQL Server はデータベースの特性に基づいてクエリ プランを選択するので、類似のデータ特性を持つサイトをコンテンツ データベースがホストしている場合には SQL Server データベース ソフトウェアの動作効率が向上します。一方、大きく異なるデータ特性を持つサイトをデータベースがホストしている場合に SQL Server が使用するクエリ プランは、データベース内のあらゆるコンテンツに対して最も効率のよい方法であるとは限りません。たとえば、データベースがチーム サイト (大量の中型サイト) とポータル サイト (多数の要求を持つ非常に大型のサイト少数) をホストしている状況でのクエリ プランは、いずれかのタイプのサイトにとって効率の悪いものとなります。したがって、チーム サイトのコンテンツを専用データベースに置けば SQL Server のパフォーマンスが最適化され、その結果、サーバー ファーム全体のパフォーマンスが向上します。

管理性を考慮する

専用 Web アプリケーションでチーム サイトをホストすれば、次の点で管理性が改善されます。

• 次の項目を別々に管理できます。

  • データベース設定

  • クォータ テンプレート

  • ごみ箱設定

  • 使用されていないサイトに対する自動アクション

  • 認証

  • ポリシー

• チーム サイトを他のタイプのサイトとは別に管理することにより、チーム サイトの増大を効果的に管理できます。

• 特定のサービスレベル アグリーメントを取り決める機会ができます。たとえば、コンテンツ データベースの毎週の完全バックアップと毎日の差分バックアップを行うというサービスレベル アグリーメントと共に、第 2 段階ごみ箱を使用した個々のコンテンツ項目の復旧時間の短縮を提供できます。

アプリケーション プールを選択する

企業環境の場合、グループ作業と分離に関する要件が似ている Web アプリケーションとチーム サイトに、アプリケーション プールを共有させることができます。たとえばチーム サイトと個人用サイトはどちらもグループ作業での情報とドキュメントの保存に使用されると共に、分離基準がほぼ同じなので (両者とも組織全体で利用可能)、チーム サイトと個人用サイトでアプリケーション プールを共有させることができます。

一般的に、専用アプリケーション プールが必要となるのは、次のいずれかを行う必要がある場合です。

• 匿名コンテンツと認証コンテンツを区別します。

• 外部ビジネス アプリケーションのパスワードを保存し、外部ビジネス アプリケーションと通信するアプリケーションを分離します (たとえば、ビジネス データ カタログとの接続)。

• サイトの作成、管理、およびコンテンツに関するグループ作業をユーザーが自由に行えるアプリケーションを分離します。

専用アプリケーション プールを使用すべき状況の詳細については、「論理アーキテクチャ モデル : 企業展開」を参照してください。

複数の組織のためのコンテンツが 1 つのサーバー ファームにホストされているホスト環境では、1 つの組織のためのコンテンツはすべて同じアプリケーション プールでホストすることをお勧めします。こうすることにより、より高い拡張性 (アプリケーション プールが少なくなれば実行中プロセスも少なくなります) のみならず、アプリケーション プール間のプロセス分離も向上します (したがって、顧客 A のアプリケーション プールが停止しても顧客 B のサイトに影響を及ぼしません)。これは当然ながら、組織数、パフォーマンス計画における推奨事項、および分離要件に依存します。

Web アプリケーションの全般設定を計画する

データの増大と環境内チーム サイトにおける現在のコンテンツの状態とを管理する際に役立つ設定が、[Web アプリケーションの全般設定] ページにあります。これらの設定は、Web アプリケーション内のすべてのサイトに適用されます。少なくとも次の設定の実装を計画してください。各設定について、以下に説明します。

• チーム サイトの最大サイズを制限するクォータ テンプレートを定義し、適用します。

• 最大アップロード サイズを指定します。ユーザーがグループ作業をしやすいよう、ビジネス要件に基づいて余裕のあるサイズを選択してください。

• サイトのごみ箱を起動し、第 2 段階ごみ箱を使用します。

上記の設定のほか、[Web アプリケーションの全般設定] ページのすべての機能設定を吟味し、組織内チーム サイトに適した機能となっていることを確認してください。既定では、次の機能が有効です。

• 個人情報スマート タグとオンライン状態 (オンライン プレゼンス情報が表示されます)

• 警告 (ユーザーはデフォルトで最大 500 の警告を作成できます)

• Really Simple Syndication (RSS) フィード

• ブログのアプリケーション プログラミング インターフェイス (API) (ブログを作成するリンク)

クォータ テンプレート設定を指定する

Office SharePoint Server 2007 環境内のチーム サイトを対象とした既定のクォータ テンプレートはありません。ただし、基本的には以下の設定をお勧めします。

• サイトのサイズが 450 メガバイト (MB) に達すると、自動電子メールがサイト所有者に送信される。

• サイトのサイズが 500 MB に達すると、ドキュメントのアップロードがユーザーに対して禁じられる。

これらの設定が適切である場合もありますが、チーム サイトにユーザーが保存すると思われる項目のサイズと数を把握し、それに基づいてこれらの設定を調整し、チーム サイトが本来の目的に沿って使用されることを保証してください。

たとえば、複数の調査チームや設計チームが共同でグループ作業し、保存とアーカイブが必要なコンテンツを大量に出力する組織の場合には、サイトのクォータ制限を 5 ～ 10 ギガバイト (GB) に増やすことをお勧めします。このような場合、チーム サイトのコンテンツをホストすれば、コンテンツが確実にバックアップされると共に、コンテンツに投稿する必要があるあらゆる個人がそれを行えます。5 ～ 10 GB サイズのサイト コレクションをそのサイト コレクションのコンテンツ データベースに入れるという方法もあります。サイト コレクションが急激に増大すると思われる場合には、特に良い方法です。

一方、短期プロジェクトやチーム通信サイトとして使用されることがほとんどであるチーム サイトの場合には、クォータ制限を下げるとよいでしょう。この結果、短期プロジェクトの進行に必要な情報だけを保存する方向にチームを誘導できます (ただし、クォータ制限を下げすぎるとクォータ引き上げのヘルプ デスク要求に伴うコストが増大する恐れがあるので、下げすぎないことが肝要です)。この場合、一般的なチーム コンテンツや新規プロジェクトのコンテンツを別々のチーム サイトに保存するよう、チームにアドバイスしてください。

業務上、特定のチームやグループが通常より大量のコンテンツをチーム サイトに保存しなければならない場合には、特定のサイト コレクションのクォータ制限を調整できます。クォータ制限を調整するには、チームやグループに対応するサイト コレクションを [サイト コレクションのクォータとロック] ページで選択します。現在のクォータ テンプレートを [個々のクォータ] に変更し、適切な制限を指定します。

クォータ テンプレートの計画では、組織内の大半のチーム サイトに適した制限値を選択します。管理性を向上させるため、特定のビジネス ニーズを満たす必要がある場合には、ユーザー単位でクォータを調整してください。

最大アップロード サイズを指定する

既定のアップロードの最大サイズは 50 MB です。50 MB は、多くの種類とサイズのドキュメントをパフォーマンスを劣化させることなくアップロードできる柔軟性を備えた、余裕のある制限値であると見なされています。ユーザーが大型のファイルをチーム サイトに保存する必要がある場合には、この設定を調整するとよいでしょう。その際、低速接続を使用しているユーザーがある場合には、IIS タイムアウト設定を監視する必要があります。

ごみ箱設定を指定する

ごみ箱の使用は、チーム サイトの管理性を向上できる簡単な方法です。ごみ箱を使用できれば、全体管理者による処理 (つまりバックアップ テープからの復元) を行わなくとも、サイト所有者は削除した項目を自分で取り出せます。

次のリストは、ほとんどの組織に適している、ごみ箱の既定設定を示しています。

• ごみ箱状態 : オン

• ごみ箱内の項目を削除するまでの日数 : 30 日

• 第 2 段階ごみ箱 : 第 2 段階削除項目用に稼働サイト クォータの 50% を追加する

削除済みデータ バックアップでは、ユーザーがごみ箱から削除したアイテムが保存されています。第 2 段階ごみ箱から項目を復元できるのは、サイト コレクション管理者だけです。第 2 段階ごみ箱に指定されるサイズの分だけ、チーム サイトの総サイズが増大します。たとえば、チーム サイトの制限値が 500 MB であるときに第 2 段階ごみ箱のサイズとして 50% を設定すると、サイトが使用できる総容量は 750 MB となります。これに基づき、データベース容量を計画してください。

第 2 段階ごみ箱の中の項目は、保存期間 (既定では 30 日) が終了するとごみ箱の場合とまったく同じように自動的に削除されます。ただし、第 2 段階ごみ箱のサイズ制限に達した場合には、最も古い項目から自動的に削除されます。サイト コレクション管理者は、第 2 段階ごみ箱を手動で空にすることもできます。

ごみ箱機能を使用する際の重要な考慮点は、第 2 段階ごみ箱を使用するかどうか、使用する場合にはどれだけの容量を割り当てるか、です。重要なドキュメント、ドキュメント ライブラリ内のフォルダ、またはリスト内の列をユーザーが誤って削除した場合に備えるため、少なくとも少量 (10% など) のスペースを第 2 段階ごみ箱に割り当てるとよいでしょう。

サイト作成方法を計画する

チーム サイトのサイト コレクションを一元的に作成するか、[Self-Service Site の管理] を使用してユーザー自身にサイト コレクションを作成させるかを選択することができます。いずれの方法も、条件を伴います。

Self-Service Site の管理を使用したサイト コレクションをチームに許可すると、管理者からの手助けなしでチームが必要に応じて簡単にサイトを作成できます。ただし、この方法には以下に示す多くの短所があります。

• 高度な分類法を実装する機会が失われます。

• アプリケーションの管理が複雑になる可能性があります。

• サイトが放置されやすくなります。

• 1 つのサイト コレクションを共有できるはずの複数のプロジェクトやチームによるテンプレートやナビゲーションの共有が行えなくなります。

一方、組織の運用形態に基づいて一元的にサイト コレクションを作成すれば、チーム サイトの管理と増大を構造的なものにする綿密な分類方式の実施が可能となります。サイト コレクションを共有するプロジェクトとチームがテンプレートやナビゲーションを共有する可能性も増えます。この方法では、最初のサイト コレクションの作成後、チームがそれぞれのニーズに基づいてそのサイト コレクション内にサイトを作成できます。ただし、ユーザーがサイトを作成するたびに IT リソースが消費されます。

それぞれの方法を使うべき状況の例については、「論理アーキテクチャ モデル : 企業展開」を参照してください。サイト作成の計画の詳細については、「サイト作成のプロセスを計画する (Office SharePoint Server)」を参照してください。

ユーザーにそれぞれのチーム サイト コレクションを作成させるのではなく、組織がチーム サイトのサイト コレクションを作成することにした場合には、サイト パス ワークシート (https://go.microsoft.com/fwlink/?linkid=73149&clcid=0x411) を使用して、どのレベルでチーム サイトを作成するかを決定します。つまり、それぞれのサイト コレクションに含まれるトップレベル サイトを作成するか、複数のサブサイトを持つ 1 つの大規模なサイト コレクションを作成するかを決定します。多数のサイト コレクションを作成するか、多数のサブサイトを持つ少数のサイト コレクションを作成するかを決定する際には、その詳細を Windows SharePoint Services 3.0 テクニカル ライブラリの「Determine sites and subsites needed [Windows SharePoint Services]」の「個々のサイト コレクションを使用するのか、単一のサイト コレクション内でサブサイトを使用するのかを決定する」で確認してください。Office SharePoint Server 2007 で利用できるサイト タイプの詳細については、「サイトおよびサブサイトを決定する」を参照してください。

チーム サイトのコンテンツ データベース設定を設計する

「論理アーキテクチャ モデル : 企業展開」では、チーム サイトは専用データベースに保存されます。各サイト コレクションが 1 つの専用データベースに保存されるのです。この方式では、各サイトコレクション データベースをそれぞれ独立して管理し、バックアップ、復旧、移行を行うことができます。また、プロジェクトの完了時に、プロジェクトに関連するデータベースを簡単にアーカイブできます。この方式では多くのデータベースを作成することになりますが、サイト コレクションごとにデータベースを個別管理することができます。

ただし、SQL Server インスタンスごとのデータベース数が SQL Server のパフォーマンスに影響を及ぼす可能性があります。たとえば 300 個以上のチーム サイト コレクションをそれぞれ専用データベースに保存すると、SQL Server パフォーマンスが劣化するおそれがあります。これは、各データベースがアプリケーション プールと SQL Server との個別の接続を利用しているからです。Web サーバーとデータベースを追加すると、アクティブな接続の数が増えることになります。接続数が多くなりすぎると、SQL Server が応答しなくなる可能性があります。

したがって、300 を超えるチーム サイト コレクションを作成する予定の場合には、専用データベースを使用せず、各データベースに複数のサイト コレクションを保存するようにします。ところで、Microsoft IT 部門で使用しているデータベース数は 300 です。この 300 というデータベース数は障害点ではなく、SharePoint Portal Server 2003 データに基づいた予測値であり、各サーバー上で安全にホストできるサイト コレクション数について Microsoft IT が確信を持てるレベルを示しています。具体的な数値は、データベース数を含むさまざまなパラメータによって異なります。たとえば、専用データベースを使用するかしないかは、次のような要素にも依存します。

• チームによってサービスレベル アグリーメントが異なるか (バックアップ要件が異なるなど)。

• チームに必要な記憶域が 8 GB を超えるか。

• チームによってプロジェクト タイムラインが異なるか。短期プロジェクト チームと長期プロジェクト チームが混在しているときに同一のデータベースを共有させると、サイトのアーカイブや運用環境からの移動が困難になる可能性があります。

• データベース レベルで発生する処理に対して高いレベルの自主性と独立性をチームが期待しているか。

上記のいずれか 1 つにでも該当する場合には、サイト コレクションに専用データベースを使用した方がよいでしょう。

各データベースに複数のサイト コレクションを保存する場合には、任意の 1 つのデータベースの最大サイズと各サイト コレクションの最大サイズ (クォータ テンプレート記憶域制限値にごみ箱割り当て容量値を加算した値に基づく) に基づいて、各データベースに保存すべきサイト コレクション数を求めることができます。各ユーザーに 500 MB のクォータを与えたとしても全員がクォータを使い切るとは限らないので、結果的にコンテンツ データベースが多すぎることがあります。クォータ量はデータベース計画での考慮事項の 1 つではありますが、必ず実際の使用量を追跡し、適宜調整してください。SharePoint Portal Server 2003 や Windows SharePoint Services 2.0 の環境が以前にあった場合には、そのサイト コレクションがどれほどのサイズであったかを調べ、クォータ量ではなく実際のサイト コレクション サイズに基づいてデータベースを作成してください。

管理環境におけるデータベース サイズ制限は、次の 2 つの要素によって確定することが少なくありません。

• データベースのバックアップに要する時間。特定のデータベース サイズを超えると、バックアップ処理の効率が低下し、実用的とはいえない長さの時間を要し、他の問題の影響を受けます。これも、環境にデータベース サーバーを追加するために決定する事項であることがあります。

• サービスレベル アグリーメントで指定されている、コンテンツ復元に使用するサービス時間枠 (時間量)。たとえばコンテンツ復元のサービス時間枠が 4 時間である場合、データベースのサイズは、その時間内に復元できる量に限定されます。

チーム サイト コレクションの管理可能な最大サイズを求めるには、下表の値を調べます。

項目	要素	値
A	コンテンツ復元のためのサービス時間枠	hr
B	選択した復旧方法とツールを使用してサービス時間枠以内で復元できるコンテンツの量	GB
C	データベース バックアップの目標時間枠	hr
D	選択したバックアップ方法とツールを使用して目標時間枠以内でバックアップできるコンテンツの量	GB

管理可能な最大データベース サイズは、2 つのコンテンツ量 (B、D) の低い方の値です。

コンテンツ データベースのターゲット サイズが判明すれば、各データベースでサポートできるサイト コレクションの数を求めることができます。下表は、データベース サイズとサイト コレクション サイズ制限値に基づく、データベース当たりのサイト コレクション数を示しています。サイト コレクション サイズ制限値には、第 2 段階ごみ箱に割り当てるスペースが含まれています。

データベース サイズ	500 MB サイト コレクション サイズ制限値	750 MB サイト コレクション サイズ制限値	1 GB サイト コレクション サイズ制限値	2 GB サイト コレクション サイズ制限値	5 GB サイト コレクション サイズ制限値	10 GB サイト コレクション サイズ制限値
25 GB	50	33	25	12	5	2
50 GB	100	66	50	25	10	5
100 GB	200	133	100	50	20	10
200 GB	400	266	200	100	40	20
500 GB	800	533	500	250	100	50
1 テラバイト	1,600	1,066	1,000	500	200	100

チーム サイトの Web アプリケーションを作成する際には、データベース サイズ ターゲットとサイト コレクション サイズ限界値に対応する最大サイト コレクション数を持つ最初のコンテンツ データベースに対し、[コンテンツ データベースの管理] ページで設定を変更します ([最大サイト数])。また、警告をトリガするサイト数しきい値も指定します ([サイト レベルの警告])。サイト レベルの警告の値に達した場合には、同じ設定のデータベースを新たに作成してください。最大サイト コレクション値に達すると、データベース内にはそれ以上のサイト コレクションが作成されません。別のデータベースが作成されていない場合、サイト作成は失敗します。

使用されていないサイトを自動的に削除する

使用されていないサイトを自動的に削除することにより、チーム サイトのコンテンツの現在性を高めることができます。チーム サイト全体の増大を制御することにもつながります。別の Web アプリケーションでチーム サイトがホストされている場合には、使用されていない Web サイトについての照会を始める前に使用期間を延長するなど、個人サイトとは違ったやり方で未使用チーム サイトを管理できます。

既定では、サイトの自動削除は有効になっていません。サイト削除設定を管理するには、[アプリケーション構成の管理] ページの [SharePoint サイトの管理] セクションで、[サイトの使用確認と削除] をクリックします。

この機能を有効にしたときの既定設定は、次のとおりです。

• サイト コレクションを作成してから 90 日後に、サイト コレクション所有者に電子メール通知が送信されるか、使用が確認されます。つまり、90 日間使用が確認されなかったサイトの所有者は、通知を受信します。

• システムは未確認サイト コレクションの有無をチェックし、毎日真夜中に通知を送信します。

• 未確認サイト コレクションの自動削除オプションは、選択されません。この設定が選択されている場合、通知が 28 回送信された後、サイトが自動的に削除されます。通知回数を指定することもできます。

既定の設定の場合、90 日間使用されていなかったサイト コレクションは、28 回目の通知後に、つまりサイトの最終確認から 118 日後に、削除されます。組織に適した設定を指定できます。この機能はサイトの実際の使用状況を追跡するのではなく確認という手段によって機能するため、サイト所有者が予期せず不在となる可能性を考慮し、短期間のサイトの期限切れ日時や削除日時を設定しないようにする必要があります。また、複数のサイト コレクション管理者を必ず用意し、主管理者が長期に渡って不在となる場合にはバックアップ管理者がサイト確認を行えるようにしてください。

自動サイト削除は環境管理に役立ちますが、ビジネスクリティカルなデータが保存されていたサイトが自動的に削除されてしまうというリスクを伴います。このリスクを削減するには、以下のことをお勧めします。

• すべてのサイトについて、第 2 の連絡先を要求します。こうすることにより、サイト所有者が不在であったり組織を離脱したりした場合でも、サイトが使用中であるかどうかを確認するための連絡先があることになります。第 2 の連絡先がないときに未使用サイトを削除するまでの日数や通知回数を減らした場合には、必要なサイトを間違って削除してしまう恐れがあります。[Self-Service Site の管理] を使用している場合や [サーバーの全体管理] からサイト コレクションを作成するためのビジネス プロセスとして、この推奨事項を実施してください。

• 自動的に削除される前に、サイトをアーカイブします。未使用サイトの自動削除を実施している多くの組織では、自動的に削除する前にすべてのサイトをアーカイブするツールの開発にも投資しています。こうすることにより、ビジネスクリティカルな情報が入っていたサイトを簡単に復元することができます。あるいは、削除されたサイトを復元する必要が生じた場合に備え、コンテンツ データベースの長期保存を計画します。

パスまたはホスト名を使用してチーム サイト URL を整理する

組織の構造とチーム サイトの使用形態によっては、パスを使用してチーム サイトの URL を整理してもよいでしょう。たとえばチーム サイトの URL を部門別にしたい場合には、http://company_name/division_name/sites や http://company_name/research/sites のような URL を使用します。また、http://intranet_name/teamsites を使用すれば、公開イントラネット サイトとの関係を明示できます。[Self-Service Site の管理] を使用している場合のチーム サイトの既定 URL は http://server_name/sites ですが、http://server_name/team のワイルド カードを使用した管理対象パスを作成したり適切な接頭辞をチーム サイトに使用することもできます。

パスの詳細については、下記を参照してください。

• グループ作業サイトを計画する

• サイトおよびサブサイトを決定する

• 「論理アーキテクチャ モデル : 企業展開」の「URL パスにおける明示的インクルードとワイルド カードを使用した管理対象パス」

• ホワイト ペーパー : Windows SharePoint Services で共有ホスト ソリューションを作成する (https://go.microsoft.com/fwlink/?linkid=86128&clcid=0x411)

組織内で比較的大きな役割を担うチーム サイトがある場合には、ホスト名を持つサイトを作成することもできます。たとえば人事 Web サイトがチーム サイトであると共に公開イントラネット サイトの一部ではない場合、http://hrsite or http://humanresources というホスト名を持つチーム サイトにするという方法があります。

カスタム要素のための計画を行う

カスタマイズを行うと、環境がさらに複雑となる可能性があります。カスタム機能を展開する前、更新を適用するとき、環境をアップグレードするときなど、数回に渡ってすべてのソリューション パックをテストする場合には、特にその傾向が高まります。カスタム機能、テンプレート、Web パーツなどの使用に対する組織のポリシーを決定し、環境におけるカスタム機能の管理性、サポート性、操作性を計画する必要があります。

• 管理性   環境全体のバックアップと復元が必要である場合には (障害復旧時やハードウェア移動時)、あらゆるカスタム要素 (その環境用に開発したカスタム Web パーツやカスタム サイト定義) のバックアップを取り、復元時に環境に追加しなおす必要があります。カスタム要素の参照がすべて格納されている構成データベースを復元することはできないので、復元後の環境にこれらを追加しなおさなければなりません。たとえば、カスタム サイト定義を追加しなおし、カスタム Web パーツをインストールする必要があります。新しいサーバーに移動したりサーバーを復元したりしたときにカスタム要素を忘れると、ユーザーのチーム サイトでエラーが発生する恐れがあり、ユーザーを待たせたままコードを追跡しなければならなくなります。

• サポート性   カスタム要素が環境に存在すると、問題発生時のトラブルシューティングに時間がかかる可能性があります。ユーザー設定コードはそれぞれ特有であり、複雑なものもシンプルなものもあると同時に、実行にはメモリ消費が追加される可能性があります。ユーザー設定コードの使用箇所数とシステムへの影響を考慮してください。また、トラブルシューティング時に問題の根本原因としてカスタマイズをどのようにしたら除外できるかについても考慮してください。ユーザー設定コードを自分で作成する場合には、エラーをトラブルシューティングできるよう、イベント ログ (Microsoft Operations Manager (MOM) イベント用) とトラブルシューティングとして組織で使用しているロケーションとの両方にカスタマイズ エラーが記録されるように作成してください。

• 操作性   ソリューション、Web パーツ、テンプレートの操作性を考慮してください。環境内チーム サイトのカスタム テンプレートが多数あり、テンプレートや Web パーツのリストが複数画面に及ぶ場合には (たとえば読み取ったり確認したりするには 50 画面は多すぎる)、すべてのカスタム要素が必要か、何らかの方法でリストを分割できるか、ブラウズや追跡を容易にするため一般機能パックに移動すべきか、について考慮します。

一部の組織では、カスタマイズに関するポリシーが複数存在します。たとえば、プレーン サイトであるレベル 1 (標準テンプレートのみ使用する)、一部のカスタマイズを使用するレベル 2 (別のサービスレベル アグリーメントが適用される)、レベル 3 (組織がハードウェアをホストするがハードウェア上でのカスタマイズ環境の実行と管理はチーム サイトを所有するチームが行う) というように、2 層システムや 3 層システムを使用することができます。これも、複数の Web アプリケーションでチーム サイトをホストし、Web アプリケーションごとに別々のサービスレベル アグリーメントを適用する、という方式が適していると思われる状況です。

チーム サイトに適用する権限を計画する

チーム サイトに適用する権限とポリシーにより、以下が決まります。

• チーム サイトを作成できるユーザー

• チーム サイトの表示とチーム サイトへの投稿を行えるユーザー

• チーム サイト上のコンテンツへのアクセスが禁止されるユーザー

権限の管理には、セキュリティ グループを使用することをお勧めします。下表は、権限の構成指針と構成場所を示しています。

権限	ガイダンス	構成
チーム サイト コレクションを作成する	既定では、チーム サイトのサイト コレクションを作成できるのは、ファームの管理者グループのメンバだけです。 他のユーザーもチーム サイト コレクションを作成できるようにするには、[サーバーの全体管理] の Self-Service Site の管理機能を使用します。詳細については、「サイト作成のプロセスを計画する (Office SharePoint Server)」を参照してください。 Self-Service Site の管理を起動すると同時に、Self-Service Site の作成権限を 1 つ以上のセキュリティ グループに限定するか、または [Self-Service Site の管理 : 新規 SharePoint サイト] ページ (Scsignup.aspx) へのアクセスを特定のセキュリティ グループに限定すれば、組織内の一部の人々に対してのみ Self-Service Site の管理を有効にすることができます。	[サーバーの全体管理] サイトの [アプリケーションの管理] ページの [アプリケーション セキュリティ] セクションで、[Self-Service Site の管理] をクリックします。 Self-Service Site Creation の使用権限を持つユーザーとグループは、[Self-Service Site の管理] が有効であるときにサイト コレクションを作成できます。
サイト コレクション内にサブサイトを作成する	既定では、サブサイトの作成権限 (フル コントロール アクセス許可レベルに含まれる) を持つチーム サイトのメンバは、サイト コレクション内にサブサイトを作成できます。サブサイト作成をユーザーに対してグローバルに禁止するのではなく、サブサイト作成権限の管理をサイト所有者に許可することをお勧めします。	[サイトの設定] ページで、所有者グループに属するメンバの追加や削除を行います。
チーム サイトを表示し、チーム サイトに投稿する	チーム サイトの作成を禁止されている従業員でも、他のチーム サイトにあるドキュメントをそのサイト所有者が指定する権限に従って表示したり投稿したりすることができます。この種のグループ作業への参加をユーザーに対してグローバルに禁止するのではなく、サイト コンテンツに対する権限の管理をサイト所有者に許可することをお勧めします。	[サイトの設定] ページで、閲覧者グループに属するメンバの追加や削除を行います。
チーム サイト コンテンツにアクセスできない	Web アプリケーションのポリシーを作成し、チーム サイト コンテンツへのあらゆるアクセスを組織内ユーザーに対して禁止することができます。禁止されたユーザーはチーム サイトでのグループ作業をまったく行えなくなるので、このオプションは慎重に使用してください。Web アプリケーションのポリシーは、Web アプリケーション内で構成された他の権限より優先されます。	[アプリケーション構成の管理] ページの [アプリケーション セキュリティ] セクションで、[Web アプリケーションのポリシー] をクリックします。禁止したいユーザーを [Web アプリケーションのポリシー] ページで選択し、[選択したユーザーの権限の編集] をクリックし、[ユーザーの編集] ページの [アクセス許可ポリシー レベル] セクションで [すべて拒否] を選択します。

このブックをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

• Office SharePoint Server 2007 の計画とアーキテクチャ、パート 2

入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。