SharePoint 製品とテクノロジの展開によるエンタープライズ コラボレーションの実現

ダウンロード SharePoint 製品とテクノロジの展開によるエンタープライズ コラボレーションの実現 912 KB Microsoft Word ファイル Office ビューアのダウンロード

従来の状況

ソリューション

OTG では、Microsoft のテクノロジを使用してグローバルなコラボレーション プラットフォームを構築しました。このプラットフォームは、3 つの地域データセンターのサーバーファーム上で、パーソナルストレージ、チーム Web サイト、グループポータル、部門ポータル、およびエンタープライズサービスをサポートします。

利点

製品とテクノロジ

トピック

	概要
	はじめに
	ビジネスに関する利点
	サービスのアーキテクチャと設計
	サーバー アーキテクチャ
	アップグレード
	得られた教訓
	ベスト プラクティス
	まとめ
	詳細情報

概要

Microsoft では、他の多くの大企業と同様、社内全体に存在する大量の動的コラボレーションコンテンツを管理することに苦労していました。社内にはいくつものプラットフォームがあり、バックアップサービスは統一されておらず、統合が不完全で、コンテンツの適時性、価値、状態などを示すメタデータもありませんでした。Microsoft の IT 部門である OTG (Operations and Technology Group) は、こうした問題を解決するために、Microsoft SharePoint・製品とテクノロジへの移行を決定しました。

SharePoint 製品とテクノロジによって、柔軟性に富んだ開発や管理ツールを備えたスケーラビリティの高いコラボレーションソリューションを構築できます。 Microsoft では、次の 4 つのビジネスニーズに対応するコラボレーションソリューションを構築しました。

このホワイトペーパーでは、集中的にホストされたコラボレーションソリューションについて説明しますが、このソリューションを導入する以前、OTG は世界各地に存在する多数のサーバー上の 26,000 を超える SharePoint Team Services サイトを管理していました。

OTG が目指したのは、コラボレーションと情報交換を妨げる障壁を取り除き、業務の効率化と従業員の生産性向上を実現することでした。新たに導入した SharePoint インフラストラクチャは集中化されているため、ストレージエリアネットワークの個々の SharePoint Team Services サーバーでコンテンツストレージコストが 4 分の 1 に減少し、管理が容易になり、Microsoft Office Professional Edition 2003 との設定なしの統合も可能になると予想しました。

このホワイトペーパーは、エンタープライズ環境に SharePoint 製品とテクノロジを展開する業務上の意思決定者、技術的な意思決定者、IT 設計者、および開発管理者を対象としています。このホワイトペーパーに記載された推奨事項は、いち早く SharePoint インフラストラクチャを導入した OTG の経験に基づいていますが、作業手順の説明を目的としたものではありません。エンタープライズ環境はそれぞれに状況が異なります。したがって、ここで説明する計画や得られた教訓を各企業の要件に合わせて調整する必要があります。

ページのトップへ

はじめに

OTG (Microsoft Operations Technology Group) が新たなコラボレーション プラットフォームを展開することは、ハードウェアとサービスの集中化を目指す Microsoft の最近の方針に合致したソリューションを実装するチャンスでした。その目標は、各地域のデータセンターのサービスを統合することによって、所有およびサポートのコストを削減し、同時にインフォメーション ワーカーが要求する機能、記憶容量、パフォーマンスを提供することでした。

OTG が実施した調査により、Microsoft で行われているコラボレーションの内容はその参加者の種類によって異なることが明らかになりました (図 1 参照)。多くの場合、コラボレーションは 1 人の作業から始まります。ある従業員がアイデアを思いつくと、それを同僚に話します。そしてアイデアやプロジェクトを巡ってチームが形成されると、チームでは情報を共有し、メンバへ情報を速やかに伝達する必要が生じます。関連のあるプロジェクトに携わる複数のチームが 1 つのグループまたは部門を形成することもあります。部門レベルでは、チームから大量の情報が生み出されるため、コンテンツの有効な整理および分類が重要となります。企業レベルでは、リーダーが生成された情報の概要と主要なドキュメントを評価すると共に、企業全体に情報を配布します。

図 1: Microsoft ではさまざまなレベルでコラボレーションが行われている

Microsoft では、情報が階層の上下いずれの方向にも流れます。管理者からの連絡事項、管理情報、最善の方法などは、チームおよび各従業員へ向かって流れます。このようなコンテンツは通常、中央ポータルから提供されます。新しいアイデアやプロジェクト情報は、従業員やチームから部門や管理者へと流れます。多くの場合、このような情報は特定の個人に宛てたものであり、多くの人が共有しようとすると、企業に過剰な連絡事項や情報があふれることになります。

インフォメーションワーカーの困惑

IT チームはユーザーに対してあらゆる種類の機能を提供していましたが、ユーザーとしては個々の状況においてどの機能が最適であるか常に判断できるわけではありません。ユーザーはテクノロジをどのように利用したらよいかを判断しなければならず、本来の業務に集中することができませんでした。 OTG においては、ユーザーが本来の業務以外のことに煩わされなくて済むように、情報を有効に管理できるようシステムとテクノロジを設定し直した方がよいことは明らかに思われました。図 2 は、インフォメーション ワーカーが使用できる機能のうち選択に迷うことが多いものを示したものです。 IT スタッフにとっては、何種類ものプラットフォームを管理することも大きな負担でした。

図 2:これまでインフォメーションワーカーが使用していたコンテンツ保存方法

Microsoft の従業員は、多くの場合、世界各地にいるさまざまな分野のインフォメーション ワーカーで構成される仮想チームで仕事をします。この場合、従業員はドキュメントや情報をすばやく簡単に検索、検証し、コメントを付けたり変更を加えたりして、保存する必要があります。プロジェクトチームのメンバは、だれもが最新の情報やドキュメントの最新バージョンにアクセスできることが必要となります。そうでなければ、各メンバが同じドキュメントの異なるバージョンを更新することになり、ドキュメントの整合性を維持する必要が生じるため、生産性の低下につながります。

2001 年に SharePoint 製品とテクノロジがリリースされて以来、Microsoft のインフォメーション ワーカーは予想を上回る早さでサイトを作成してきました。 OTG のプロジェクトチームは、コラボレーション機能が必要とされており、チーム間の連携が重要となっていることを踏まえ、新たなソリューションで対応する必要のある問題として以下の点を挙げました。

インフォメーションワーカーが選択できるコンテンツ保存方法が多すぎます。 Microsoft のインフォメーション ワーカーがドキュメントを保存するときには、コンテンツの種類、対象ユーザー、目的、完成度、アクセス可能性などに基づいて、保存場所を多くの候補の中から選択する必要がありました。さらに、多くの場合、コンテンツには作成課程でさまざまな段階があるため、インフォメーション ワーカーは保存場所を数回にわたって決定することも必要でした。コンテンツの保存場所を決定した後には、それを参照、修正、または削除するときに見つけられるように、どこに保存したかを覚えておく必要もありました。

チームは他のチームと共同で作業する方法を習得する必要があります。 Microsoft で行われるコラボレーションの大部分は小規模な作業チーム内で進められます。チームを結成したり再編したりする際には、共通のプロセスをサポートする構造を簡単に作成できること、情報の利用とバックアップが容易にできるような保存方法を確立することが必要となります。コラボレーションでは電子メールの受信トレイをよく使用しますが、バージョン履歴が重要な役割をする場合や、情報を多方面の利用者に対して頻繁に公開する必要がある場合などには、受信トレイの機能は不十分です。さらに、電子メールには複数のメールボックスを対象とした検索や閲覧の機能がなく、最新のドキュメントを取得する機能や発行モデルにも対応していません。電子メールを使用した場合、プロジェクトや計画の現状を確認するためには、メッセージスレッドをつなぎ合わせる必要があります。そのため、新たに加わったチームメンバなどがプロジェクトの過去の経過や現在の状況を、保存されている電子メールから把握するのは簡単ではありません。

従業員は仕事の関連情報を簡単に見つけられません。 Microsoft には 26,000 もの SharePoint Team Services チームサイトがありますが、その多くには明確な相互関係がありません。これらのサイトを統合して 1 つの包括的なポータルを作り上げるには、手動での多大な努力が必要でした。ほとんどの場合ユーザーは、数千ものサイト (そして数千のファイル共有およびパブリックフォルダ) から担当プロジェクトとの合致度が高い上位 10 〜 12 のサイトを自力で探さざるをえませんでした。イントラネット Web 検索機能があれば、このようなサイトの多くを見つけることは可能ですが、合致度の低い大量の検索結果の中に該当するサイトが埋もれてしまう可能性もあります。従業員は以下の点を知っている必要がありました。

チームは IT に関する問題ではなく本来の業務に専念する必要があります。 Microsoft では、多くのチームがサイト内およびサイト間での情報検索などの同じような問題にそれぞれ独自に対処し、独自の方法で関連性のあるチームサイトや企業サイトへのリンクを見つけだしていました。このような努力はプロジェクト業務とは直接関係のない不要なものです。事実、こうした余分な作業によって本来のプロジェクト業務が支障をきたすことも少なくありませんでした。

製品およびテクノロジの名称変更

当初 SharePoint Team Services としてリリースしたテクノロジは、現在 Windows SharePoint Services としてリリースしています。

当初 SharePoint Portal Server 2001 としてリリースしたテクノロジは、現在 Office SharePoint Portal Server 2003 としてリリースしています。

従来のプラットフォームにおける複雑なエンタープライズ管理

SharePoint Team Services ソリューションは、チームソリューションのサポートに関しては十分に機能を果たしていましたが、多くのサイトの管理を目的として開発されたものではありませんでした。チームサイトの数が増加するに従い、このソリューションを Microsoft の全社レベルで管理することが課題となりました。また、複数のストレージプラットフォームが使用されており、機能が互いに重複していました。

高いストレージコスト ディスク領域が多くのプラットフォームに分散しているため、あるストレージに空き領域があっても他のプラットフォームからはアクセスできませんでした。その結果、社内には使用されていない大量のディスク領域が残っていました。さらに、コンテンツが大量になると、その何パーセントかは現状にそぐわないものとなります。しかし、OTG には、どのサイトが現状に合致し有効であるかを判断するためのデータはありませんでした。新しいサイト用の空き領域を作るために、任意に選んだ一部のコンテンツを削除したりアーカイブしたりすることはできないため、ストレージを拡張することとなり、ハードウェアの追加とそれに伴うサポートの負担増がコストの増加をもたらしていました。

統合されていないサポートプロセス OTG では、さまざまなチームがストレージプラットフォームを所有していたため、ストレージテクノロジの統一されたサポートプロセスというものはありませんでした。たとえば、メッセージング処理では Exchange Server をサポートしていましたが、別のチームでは SharePoint 製品とテクノロジをサポートしていました。したがって、ユーザーは問題の解決方法を見いだすために、さまざまな分野の技術者を当たる必要がありました。 OTG では、少ないプラットフォームをサポートし、ある 1 つの領域の改善に対して集中的に努力を傾けるのではなく、それぞれが重要な働きをしていながら世界各地で使用されているわけではない多くのシステムを幅広く管理していました。さらに、サポートチームがどのように編成されているかにまで注意が回らないユーザーは、問い合わせへ対応の遅さに不満を感じていました。

断片化されたインフォメーションワーカーの戦略 インフォメーション ワーカープロセスの管理を専門に担当する IT チームは存在しませんでした。複数のチームがそれぞれのユーザーのニーズに合ったテクノロジを展開しているため、さまざまなソリューションが存在していましたが、相互稼働性がなく、統合されていなかったため、共通のデータやプラットフォームがあっても活用することはできませんでした。

同様に、インフォメーション ワーカー戦略を推進する気運がなく、それが相互稼働性のないソリューションが増える傾向を強める結果になっていました。ユーザーは自分のニーズに最も適したソリューションを見つける方法を自力で見つけるしかありませんでした。

集中的にホストされたコラボレーションプラットフォーム

集中的にホストする SharePoint 製品とテクノロジによって、利用率の低いプラットフォームに要する高いコスト、統合されていないサポートプロセス、スケーラビリティの限界、コンテンツ期限の欠如など、OTG において懸案となっていた問題の多くを解決できました。

OTG は、ユーザーエクスペリエンスを強化し、IT ニーズに応えられるよう、SharePoint 製品とテクノロジ、Microsoft Windowsｮ Server・2003、および Microsoft Office 2003 Editions を開発している Microsoft の製品グループに対し、製品の相互稼働性を高めるよう働きかけました。 OTG にはインフォメーション ワーカー戦略の主導権があったため、個々の従業員から会社全体までの幅広い要求に対応するソリューションを設計できました。 OTG ではシナリオベースのトレーニング資料を作成し、ユーザーがコラボレーションソリューションを既存のプロジェクトやプロセスに効果的に適用できるようにしました。

サポートの対象となるプラットフォームの減少

OTG では、以下の方法でユーザーコンテンツの管理およびサポートのコスト削減と効率化を実現しました。

エンドツーエンドインフラストラクチャとユーザーサポート

OTG では、ハードウェアを 3 つの地域データセンターに統合しました。これらのデータセンターには、OTG の設計が必要とする SAN と最大規模の国際的な施設との良好なネットワーク接続をサポートするインフラストラクチャがあったからです。このハードウェアの統合によって、サポート、バックアップ、運用管理、修正プログラムの管理などが容易になりました。

OTG では、サイト、リスト、およびドキュメントの各レベルでデータを復元する機能を備えたバックアップサービスも実装しました。特定のコンテンツを復元できることで、IT 復元タスクとユーザーによる復元したコンテンツをサイトに取り込む作業の両方において、時間の節約になります。

OTG ではコラボレーションインフラストラクチャを 1 つのエンタープライズソリューションとして設計したため、通常はサポート上の問題を 1 つの仮想チームで解決することになり、サポートの質的な低下と問題解決に要する時間およびコストの増加につながる引き継ぎ作業と連絡の遅れを減少することができます。

可用性の向上

SharePoint Portal Server 2003 でサポートされている Windows 負荷分散を使用することにより、稼働を停止することなくメンテナンスのためにハードウェアをオフラインにすることが可能になりました。このアーキテクチャは、最低 99.5% の高い可用性を実現する冗長性と、ストレージニーズの増大とユーザーベースの拡大に対応できるスケーラビリティをもたらします。

スケーラビリティのあるサービス

OTG が設計した Windows SharePoint Services および SharePoint Portal Server 2003 のアーキテクチャはスケーラビリティを備えていました。トラフィックが増加した場合には、フロントエンドサーバーを追加することで対応できます。 SAN を実装することによって、コンテンツをスケーラブルなストレージにまとめて配置することが可能となり、それがストレージの分散によって発生していた未使用の空き領域の減少につながりました。

ライフサイクル管理

Windows SharePoint Services にはライフサイクル管理機能があります。 OTG では、この機能を使用して既定のコンテンツの期限ポリシーを設定し、アーカイブまたは削除が可能な古いコンテンツを見つけだして現状に合ったコンテンツ用にディスク領域を解放できるようにしました。

ページのトップへ

ビジネスに関する利点

Windows SharePoint Services は、情報の共有とドキュメントのコラボレーション用の Web サイトを作成するためのエンジンで、個人やチームの生産性を向上します。チームサイトでは、リスト管理、お知らせ、予定表、サイト検索、およびサイトメンバシップの役割を使用できます。 Windows SharePoint Services には、バージョン履歴、ドキュメントアクセス権、チェックイン、チェックアウトなど、これまで SharePoint Portal Server 2001 にあったドキュメントコラボレーション機能の多くが組み込まれています。 Windows SharePoint Services は、Windows Server 2003 がもたらすインフォメーション ワーカー向けコラボレーションインフラストラクチャの中核をなす製品です。

SharePoint Portal Server 2003 は、さまざまなビジネスプロセスにかかわる人、チーム、そして情報を結び付ける、スケーラブルなポータルサーバーです。集約と整理によってエンドツーエンドのコラボレーションを促進し、人、チーム、情報の検索を可能にします。この新しいプラットフォームは、クラスタサーバー、強化されたバックアップおよび復元機能、およびライフサイクル管理によって、スケーラビリティとコンテンツの統合を実現します。

OTG の新しいコラボレーション プラットフォームは、一貫性のあるサービスとユーザーエクスペリエンスをもたらし、集中化によって費用効率も向上しました。たとえば、Web パーツページの基本的な要素である Web パーツは、リストやドキュメントライブラリなどの機能を提供します。 Web パーツは SharePoint 製品とテクノロジ全体で使用されているため、使い慣れたユーザーインターフェイスを使用できます。ユーザーは既存の Web パーツをカスタマイズして表示形式を変更したり、複数のページに挿入したりできます。

インフォメーション ワーカーが決定する必要のある選択肢の数を減らすことは、新しいコラボレーションソリューションを従来のコラボレーション方式より使いやすくするうえで重要なことです。図 3 に、新しいプラットフォームでインフォメーション ワーカーが選択できるコンテンツの保存方法を示します。

図 3: 新しいプラットフォームのコンテンツ保存方法

OTG のコラボレーションソリューションを導入すると、以下のようなビジネス上の利点がもたらされます。

パーソナルストレージ SharePoint Portal Server 2003 のユーザーインターフェイスには [個人用サイト] と呼ばれるパーソナルサイトがあり、これによってユーザーはコンテンツを決まった場所に保存でき、コンテンツのアクセス権を設定することもできます。この個人用サイトには、個人用コンテンツと作業中のコンテンツを保存するプライベート記憶領域と、プロジェクトやドキュメントの共有が容易になるパブリック記憶領域があります。個人用サイトには Active Directoryｮ から取得されたプロファイル情報の一部も含まれているため、ユーザーがチームまたは企業内で果たす役割の情報を他のユーザーに知らせることもできます。

チームコラボレーション SharePoint Product and Technologies と Microsoft Office 2003 Editions の統合は、OTG のユーザーにコンテンツの作成とコラボレーションを行うための統一されたプラットフォームをもたらしました。 Microsoft Word、Microsoft Excel、および Microsoft PowerPointｮ から個人用サイトまたはチームサイトに保存することによって、保存場所のパスを覚えたり検索したりする必要がなくなります。Microsoft Office 2003 Editions では、[個人用サイト] を保存場所の 1 つとして [ファイル名を付けて保存] ダイアログボックスに表示します。

この統合によって、1 つの共有ドキュメントで作業しているチームメンバがドキュメントワークスペースサイトと会議ワークスペースサイトを使用できるようになり、チームコラボレーションが合理化されました。 Microsoft Outlookｮ 2003 では、電子メールの添付ファイルと会議出席依頼を基にドキュメントワークスペースサイトと会議ワークスペースサイトが作成されます。これらのサイトは、ドキュメントおよび会議でのコラボレーション専用に設計されています。

ワークスペースではドキュメントの現在のバージョンとドキュメント履歴にアクセスできるため、ドキュメントワークスペースサイトと会議ワークスペースサイトを使用することによって、ファイルの改訂番号を電子メールで送る必要が少なくなり、時間と労力を節約できます。会議の参加者は、ブラウザやクライアントの作業ウィンドウからワークスペースにアクセスし、情報を表示、編集して、サイトに追加することができます。最新の議題、議事録、タスクは 1 つのイントラネットサイトに集められます。

異なる場所で作業をしているチームメンバがインスタントメッセージを使って意見を交換することはよくありました。新製品の Microsoft Office Live Communications Server では、ほとんどのリストで "プレゼンス情報" が作成されます。この製品はサイト上のメンバシップ Web パーツで使用できます。プレゼンス情報を使用すると、他のメンバがオンラインであるか、ビジー状態であるか、不在であるかを確認したうえで、ワークスペースのユーザーインターフェイスからインスタントメッセージまたは電子メールセッションを開始できます。

グループポータルと部門ポータル 展開後すぐに使用できるポータルによって、ブラウザを使用して 1 つの場所からリンク先のチームサイトにアクセスでき、社内全体の情報を対象とせずにポータル上のリンクされたサイトを検索できるようになりました。さらに、リンクされているチームサイトからポータルへ情報を送信することも可能になりました。したがって、ポータルではチームサイトから集められた特に重要な情報の一覧を表示できます。

エンタープライズサービス 統一されたエンタープライズコラボレーション プラットフォームの利点には以下のものがあります。

"共有サービス" は、会社全体で情報や人を検索するための直感的で有効な方法をもたらしました。共有サービスは以前から設定されていた SharePoint Portal Server 2003 機能であり、コラボレーション プラットフォーム全体で使用されていたため、各チームはサービスの管理に関与する必要はありませんでした。 OTG は、共有サービスインフラストラクチャを展開し、検索、通知、対象ユーザー、およびプロファイリングの機能を実装しました。

ページのトップへ

サービスのアーキテクチャと設計

Microsoft の IT 部門は、幅広い責務を負っている点で、他社にはない、まれな存在です。その主要な役割は、大規模な組織の一般的な IT グループと同様、世界的な IT 設備を運用することです。 OTG は、エンドユーザーサポートや通信管理からサーバーおよびネットワークの運用までを網羅した包括的なサービスを提供しています。この役割には、世界各地の 150,000 を超えるコンピュータの接続管理も含まれます。世界全体で 400 か所を超える Microsoft 関連のオフィスでは、50,000 人を超える従業員、5,000 人を上回る請負業者、17,000 社余りのベンダが業務を行っており、企業ネットワークのサービスおよびリソースに 1 日 24 時間、年中無休でアクセスできます。

Microsoft の中心的な業務はソフトウェア設計です。したがって、OTG には他の世界的な IT 企業では見られない、もう 1 つの任務があります。 OTG では、IT 設備を運用するだけでなく、Microsoft テクノロジをいち早く導入し、SharePoint 製品とテクノロジ、Windows Server 2003、Exchange Server 2003 などの Microsoft 製品をユーザーに提供する前にテストし、展開しています。このプロセスを Microsoft では "自分のドッグフードを食べる" と表現しています。

OTG が新しいコラボレーション プラットフォームを展開したことによって、ハードウェアとサービスの集中化という Microsoft の計画を実行に移すことができました。その目標は、各地域のデータセンターのサービスを統合することによって、所有およびサポートのコストを削減すると共に、機能、記憶容量、および総合的なコラボレーションエクスペリエンスをエンドユーザーにもたらすことでした。このソリューションは、今後 3 年間にわたって Microsoft のコラボレーションに対する要求に応えることを目的としたものでした。

OTG のプロジェクトチームは、展開、アーキテクチャ、トレーニング、サポート、通信の計画から実装までを統括するプログラム管理者が率いていました。他のメンバには、データベース設計者やサービス管理者などがいました。 OTG では、レドモンドおよび各地域のデータセンターに新しいハードウェアを展開する計画を担当するチームとプロセスが既に決定されていたため、本稼働サーバーを展開するためにメンバを追加する必要はありませんでした。

コラボレーション プラットフォームの展開は、社内でのMicrosoft Office Professional Edition 2003 および Microsoft Office Live Communications Server の展開と同時に行われました。これらの製品は、SharePoint サイトにおけるサイトの作成とブレゼンス情報を統合するため、SharePoint 製品とテクノロジの価値を高めます。

論理的な構成

Microsoft のビジネス上の要求に対応するために、OTG では、チームサイトファーム、ポータルファーム、共有サービスファームという 3 種類のサーバーファームで構成されるコラボレーション プラットフォームを作成しました。チームサイトファームは、チームサイトをホストするインフラストラクチャとなるもので、このプラットフォームにあるデータの約 90% が保存されます。ポータルファームは SharePoint Portal Server のフロントエンドサーバーであり、共有サービスファームの SAN をポータルデータストレージとして使用します。共有サービスファームは、検索、通知、対象ユーザー、ユーザープロファイルを一貫性のある形でソリューション全体に提供します。対象ユーザーでは、ユーザープロファイルのプロパティ値、組織の報告構造、またはユーザーが属する Active Directory グループに基づいて、コンテンツのターゲットとするユーザーを決定できます。ユーザープロファイルには、Active Directory からインポートされたプロパティ、そのユーザーが作成したドキュメントへのリンク、そのユーザーが属するチームサイトへのリンク、そのユーザーが共有しているリンクなどが表示されます。レドモンドの共有サービスファームは、MSWeb という中央ポータルもホストしていました。このポータルは、HRWeb、OTGWeb、部門ポータルなどの企業情報およびサービスへのイントラネットアクセスを提供します。

図 4 に、OTG のコラボレーション プラットフォームサービスの論理図を示します。完全なアーキテクチャには複数の部門ポータルがあり、図に示したグループポータルの下にはさらに別のグループポータルが存在します。

図 4: コラボレーションプラットフォームサービスのトポロジ

このサービスの要素が相互に作用しあい、Microsoft におけるコラボレーションへの要求に対応します。

一般に、会社全体で同じサービスを提供することにより、トレーニング コストとヘルプデスクへの問い合わせ件数が減少します。さらに、ポータルごとに共有サービスインフラストラクチャを実装する必要もなくなります。インデックス作成サービスを集中化することによって、そのサービスから生成されるネットワークトラフィックは、多くの SharePoint Portal Server が個々にコンテンツをクロールする場合より少なくなります。

共有サービスによってビジネス問題を解決した例として、コラボレーション プラットフォームにおける検索範囲の定義があります。たとえば、あるグループが調布データセンターにあるコンテンツをその地域でホストされるポータルに置き、それと同時にレドモンドデータセンターでホストされている部門ポータルの検索範囲にも含める場合は、ポータルをその親部門ポータルに関連付け、さらに調布データセンターのコンテンツおよびポータルに対応する検索範囲に含めることができます。

セキュリティ

OTG が展開したコラボレーション プラットフォームは、Microsoft の企業ネットワークで認証されたユーザーが使用できます。コンテンツデータベースは共有 SAN でホストされているため、Windows 認証が特定のサイトにあるコンテンツの主要なアクセス制御メカニズムとなります。財務サイトは独立したフロントエンドサーバーでホストされているため、ビジネスルールまたはデータアクセスを使用したカスタム Web パーツを使用しても、ホスト先のインフラストラクチャの共有サーバーにコードを追加するという危険を犯さずに済みます。

OTG では、以下の対策によってインフラストラクチャのセキュリティを確保しました。

コラボレーション プラットフォームでは本来的にデータの保存および共有が容易であるため、OTG では、ユーザーが新しいサイトを作成する際にエンドユーザー契約への同意を求めることにより、会社の機密保持、プライバシー、およびセキュリティに関する方針に従う責任があることを知らせました。

チームサイトファームとポータルファーム

OTG では、ストレージエリアネットワーク (SAN) ハードウェア上に構築された集中コンテンツリポジトリにチームサイトとポータルをそれぞれホストするチームサイトファームとポータルファームを作成しました。SAN ハードウェアでは、各ファームについて最大 3.6 テラバイトのデータベース容量を確保できます。各地域のポータルファームは独立した SharePoint Portal Server インストールシステムです。

共有サービスファーム

共有サービスは、以下のようにコンテンツの種類どうしの関係に基づいて地域内に提供されました。

SharePoint Portal Server の展開に際し、OTG は以下の共有サービスを展開しました。

検索サービス

共有サービスインフラストラクチャには強力な検索機能があり、特定のチームサイト、個人用サイト、またはポータルに範囲を絞った検索に加え、会社全体を対象とした広い範囲の検索もできます。 OTG のユーザーが使用できた既定の検索機能には以下のようなものがあります。

既定では、チームサイトと個人用サイトが検索インデックスおよびサイトディレクトリに含められます。チームサイトの所有者がサイトを検索インデックスの対象とならないように設定しても、サイト名はサイトディレクトリに登録されます。ユーザーがコンテンツを参照するためには読み取りアクセス許可が必要です。

通知サービス

コンテンツの変更を知らせる通知をサイトに要求できます。この通知によって、更新されたコンテンツを検索しなくても更新が行われたことをすぐに知ることができます。共有サービスアーキテクチャにより、ユーザーは個人用サイトで自分の地域内にあるサイトの通知を管理できます。また、通知を電子メールで受け取るか、Outlook の [仕訳ルールと通知] ダイアログボックスで確認できるようにするかを選択することもできます。

対象ユーザーサービス

ルールベースの対象ユーザー定義では、ユーザープロファイルのプロパティ値、組織の報告構造、またはユーザーが属する Active Directory グループに基づいて、コンテンツのターゲットとするユーザーを決定できます。管理者は特定の対象ユーザーに Web パーツとニュースを発行できます。

対象ユーザー サービスによって、OTG では Active Directory への投資を生かし、既存の配布リストおよびセキュリティグループを基に対象ユーザーを簡単に作成できました。各地域では、共有サービスがグループポータルおよび部門ポータルに対象ユーザー機能を提供しています。

プロファイリングサービス

ユーザーが自分の所属する組織の従業員を検索した場合、OTG のプロファイリングサービスは、各ユーザーの名前、電話番号、オフィスの所在地、ドキュメントの記録、そのユーザーが作業しているサイト、個人用サイトへのリンクを検索結果として返します。各ユーザーには本人のプロパティと関連項目が表示される個人用ビューがあります。このビューはそのユーザーだけが表示できます。パブリックビューには、他のユーザーのユーザープロファイルが表示されます。プロファイルのデータは、Active Directory からの差分インポートに基づいて週に 1 回の頻度で更新されます。

エンタープライズ運用の計画

OTG では、このソリューションの展開中から現在まで、サポート、ライフサイクル管理、バックアップと復元などのエンタープライズ運用業務を行っています。運用計画の内容は以下のとおりです。

サイトおよびポータルの作成

OTG のコラボレーション プラットフォームが広く導入された大きな要因として、ユーザーがサイトを作成し、プラットフォームを使用し始めることが容易であったことが挙げられます。 OTG では、各ユーザーがポータル以外の自分のサイトを作成できます。

個人用サイトの作成 個人用サイトは、レドモンドの共有サービスファームまたは地域のサービスファームにある中央ポータルにリンクされます。ユーザーが自分の個人用サイトを作成するまで、プロファイル情報は既定の Web パーツにパブリックビューとして表示されます。ユーザーが自分のサイトを作成すると、設定とコンテンツが保存されるデータベースが生成されます。したがって、個人用サイトのディスク領域はユーザーが自分のサイトをカスタマイズして初めてコミットされます。

アクセス権を設定し、ユーザーが自分の所属する地域の共有サービスファームにのみ個人用サイトを作成できるようにすることで、OTG は個人用サイトが各ユーザーにつき 1 つだけ存在するようにしました。会社全体を対象として個人情報を検索しやすくするために、Active Directory において各ユーザーのサイトの URL が更新されます。従業員データを信頼性の高い高速ネットワーク接続で使用できるように、個人用サイトは従業員のいる場所から最も近い地域でホストしました。

チームサイトの作成 ユーザーは、コラボレーションサービス Web サイト、またはポータルとリンクされたサイトを作成するためのハイパーリンクを公開している別の部門ポータルまたはグループポータルから、チームサイトを作成できます。ポータルから作成したサイトは既定ではそのポータルにリンクされますが、チームが属する組織または関係に変更 (会社の再構築やサイト所有権の移転など) があった場合には、サイトを別のポータルにリンクすることもできます。この機能によって、意味のあるサイト階層を IT の介入なしで簡単に維持することができます。

サイトを作成するときには、所有者および代理の所有者、サイトの目的、テンプレート言語 (英語、日本語、ドイツ語) などのサイトに関するメタデータを指定します。このホワイトペーパーを作成している時点では、適切なリンク先のポータルが存在しない場合もあるため、特定のポータルに自動的にリンクされないサイトを作成できます。ただし、ポータルの数が増えたときには、OTG が方針を変更し、サイトは特定のポータル上のハイパーリンクからのみ作成でき、既定でそのポータルにリンクされるようになる可能性があります。これにより、サイトは必ずそのポータルから検索可能となり、会社全体のサイトおよびポータルの階層に組み込まれます。

場合によっては、チームサイトの所有者がサイト名として http://ProductSalesCentral のような "ホストヘッダー (修飾名)" を要求することもあります。ホストヘッダーのあるサイトでは、宣伝の面で有利な覚えやすい URL を持つことができます。チームが新しい SharePoint サイトを作成するときに、その URL として、既にある Web サイトの URL を使いたがる場合もあります。 Windows SharePoint Services サイトにアップグレードされた SharePoint Team Services サイトのサイト名を保持するために、OTG では既存のサイト URL にホストヘッダーを割り当てました。このホワイトペーパーを作成している時点では、50 のチームが新しいサイト用に短い URL を要求しています。 OTG としては、この機能が広く使用されることを望んでいません。ヘルプデスクにホストヘッダーを使用したサイトの作成要求が寄せられ、さらなるなコストがかかるからです。代替策として、希望の URL を作成し、そこにアクセスした場合には該当する SharePoint サイトにリダイレクトするという方法があります。 OTG では、チームサイトファーム内にホストヘッダーを持つサイト用のフロントエンドサーバーを配置しました (わかりやすくするために、図中にはそれらのサーバーは示してありません)。

ポータルの作成 コンテンツを整理したり強調したりする必要があるグループは、関連するチームサイトを集めた SharePoint Portal Server 2003 ポータルを作成し、それらのサイトを対象とする検索機能を組み込むことができます。コラボレーションソリューションインフラストラクチャがあるため、OTG ではオンラインフォームで送られてくるポータル作成依頼に承認を与えるだけで済みます。このフォームには、ポータルを作成する理由、所有者および共同所有者、ポータルの目的と他のポータルとの関連付けに関するメタデータが記載されています。 SharePoint Portal Server 2003 はサーバーファームごとに 1 つの言語をサポートするため、すべてのポータルは英語テンプレートを使用していました。

OTG がホストするポータルのほとんどは、設定なしで使用できる標準の SharePoint Portal Server 2003 ポータルであり、標準の Web パーツを使用し、OTG がホストするフロントエンドサーバーを共有していました。設定なしで使用できるポータルと Web パーツだけを使用し、ほとんどのサイトを仮想サーバーでホストすると、カスタム Web パーツを使用した場合に発生する可能性のある可用性やパフォーマンス上のリスクを軽減できます。

OTG では、専門の業務またはグループに対応する各種の独立したカスタムポータルもサポートしています。財務 (Finance) などの一部のグループが OTG に対してカスタムポータルをホストするよう要望していました。標準のポータルの安定性を損なうことなくカスタムポータルを作成できるように、OTG では財務グループ用のフロントエンドサーバーを購入し (1 台約 4,500 米ドル)、財務グループが Web アプリケーションのニーズに対応するカスタム Web パーツを追加し、OTG がホストするバックエンド SQL Server および SAN を使用できるようにしました。各グループはそれぞれのニーズに柔軟性をもって対応できるようになり、しかも OTG による管理およびサポートを利用することが可能となりました。

多層サポート

SharePoint 製品とテクノロジに基づくプラットフォームへの移行において OTG のサポートを必要としていたのは、ポータル管理者、ポータルユーザー、チームサイトの所有者、チームサイトのユーザー、個人用サイトの所有者などでした。

プロジェクトチームは OTG の標準 3 層サポートモデルを採用しました。層 1 はヘルプデスクです。層 2 では、ヘルプデスクが解決できなかった問題に対処します。層 3 は、層 1 および 2 で解決できなかった問題に対応するセーフティネットの役割を果たします。表 1 は、インフォメーション ワーカーが利用できるサポートの種類をまとめたものです。

表 1:サポート体制

Microsoft Operation Manager Management Packs

Microsoft では、Microsoft Operations Manager (MOM) 2000 Management Packs のリリースと SharePoint Portal Server 2003 および Windows SharePoint Services の構成ガイドの発行を計画しています。この Management Packs は、アプリケーションのパフォーマンスおよび状態の監視を目的としたものです。 SharePoint 製品とテクノロジは SQL Server と企業バックアップサービスも利用しますが、これらを集中管理することによって、広範な IT システムをサポートします。 OTG では、MOM を使用し、既存のデータセンター管理インフラストラクチャで、基本的なハードウェア、ネットワークサービス、およびオペレーティングシステム機能を監視しています。

次に、この Management Packs が監視する操作の一例を示します。

現在、OTG は Management Packs のプレリリース版をコラボレーション プラットフォームに統合し、テストを行っています。この Management Packs の詳細については、http://www.microsoft.com/mom/default.asp (英語) にアクセスしてください。

サイトのライフサイクル管理

記憶領域の有効利用と効率の向上を目的としてコンテンツのライフサイクルを積極的に管理するために、OTG の運用担当者は、Windows SharePoint Services のライフサイクル管理機能を使用しました。古いサイトの管理および閉鎖には、組み込みの電子メール通知機能とサイト削除機能が役立ちました。

OTG では、サイトの所有者に期限切れの通知を定期的に送信するサービスを作成しました。古いサイトの所有者は、リンクをクリックし、サイトを削除できるページへと進みます。 Windows SharePoint Services で作成され、所有者と代理の所有者がいるサイトに対して通知を連続 3 回送信したにもかかわらず応答がない場合、そのサイトは自動的に削除されます。

OTG では、サイト所有権の継承については人事部門の方針に従い、サイト期限ポリシーについては Law & Corporate Affairs の要求に従いました。

表 2 は、OTG 管理者が設定した期限処理をまとめたものです。

表 2:サイト期限ポリシー

* OTG では、ユーザーに対し、練習および試用のためにデモサイトを作成するよう奨励していました。

バックアップと復元

OTG では、SharePoint Team Services データベースをバックアップするために、5 つの項目 (インターネットインフォメーションサービスメタベース、システム状態のローカルグループ、サイトのセキュリティに必要な roles ファイル、仮想サーバーごとに 1 つのデータベース、ファイルシステムに保存されたファイル) をバックアップすることが必要でした。

バックアップと復元の機能は製品の強化と OTG によるストレージの統合によって大幅に強化されており、単一サイトの復元が可能になりました。復元したサイトからユーザーが 1 つのドキュメントを取得し、自分のサイトにアップロードする場合、サイトをオフラインにする必要がありません。また、FrontPage には、サイト管理者がサイトをいつでもバックアップまたはアーカイブできる機能があります。

OTG では、展開中に、完全なサイトコレクションを Stsadm.exe ユーティリティでバックアップし、さらにディスクに十分な空き領域がある場合は、Smigrate.exe ユーティリティを使用してデータベースをサイト単位でバックアップすることにしました。サイト単位のバックアップを行うと、50 GB の SQL Server データベース全体を復元せずに個々のサイトまたはドキュメントを復元することができます。表 3 では、OTG のバックアップ方針と復元機能について説明します。

表 3:さまざまなバックアップの種類に対応する復元機能

通常、チームサイトは一時的なサイトに復元されます。ユーザーはこのサイトから必要なファイルを取得できます。ポータルサイトは既存のポータル上に復元されます。ポータルの場合、個々のドキュメントまたはリストを復元することはできません。復元要求は 72 時間以内に開始されます。過去 2 日以内にバックアップされたデータを復元する場合は、バックアップがまだディスク上にあるため、処理速度が速くなります。

ページのトップへ

サーバー アーキテクチャ

OTG プロジェクトチームは、ストレージおよびネットワークに要するコストの削減とバックアップ、ストレージセキュリティ、および共有の機能強化を目的として、すべてのコラボレーションサービスを 3 つのデータセンターに統合することを決めました。

次の表に示す 3 つのデータセンターは、地域内の接続、高域の帯域幅、SAN ハードウェアをサポートする能力を備えていることから、サーバーファームをホストする施設として選定されました。これらの地域は、Microsoft の管理階層ともほぼ一致します。

表 4:各 OTG データセンターのサービス対象地域

ここでは、まずデータ センターのアーキテクチャについて説明した後、このインフラストラクチャで特定の役割を果たすサーバーの要件について説明します。

レドモンドデータセンター

OTG では、コラボレーション プラットフォームのストレージを管理するために次世代の SAN テクノロジを導入しました。この決定は、多くの検討事項に影響を与えました。特に影響を受けたのが、SAN に接続する SQL Server 2000 インストールの設計です。図 5 に、レドモンドデータセンターのアーキテクチャを示します。

図 5: レドモンドデータセンターのハードウェアアーキテクチャ

OTG が構築したインフラストラクチャは、大容量とスケーラビリティを備え、クラスタに分割されています。 OTG では、フロントエンドサーバーで Windows 負荷分散を使用して大量のトラフィックを処理し、サーバーの追加を容易にしました。

フロントエンドサーバーには、ASP.NET Web パーツアセンブリ、IIS ログ、Windows SharePoint Services ASP.NET のコードおよびアプリケーションプログラミングインターフェイス (API) が保存されていました。フロントエンドサーバーは、SAN にデータを格納する SQL Server クラスタを介して設定データベースおよびコンテンツデータベースにアクセスします。この構成では、インデックスサーバーとフロントエンド Web サーバーの間に対話はありません。

各地域のデータセンターでは、ミラーされたデータベースドライブと最大 3.6 テラバイトのデータベース容量を備えた EVA (Enterprise Virtual Array) ストレージエリアネットワーク (SAN) にコンテンツデータベースを保存しました。SAN と Web フロントエンドサーバーの接続には冗長性のあるギガビットイーサネットを使用しました。 SAN のハードウェアを除き、すべてのサーバーが Microsoft データセンター用の承認済み設定に基づいています。地域データセンターの IT スタッフがハードウェアのインストールおよび管理を担当しました。レドモンドデータセンターに展開したハードウェアのサーバー仕様を表 5 に示します。

表 5:レドモンドデータセンターの OTG サーバー要件

* OTG では、予算に余裕があったため、記憶容量の長期的な増加予測に基づき、SAN をもう 1 つ導入しました。現在のところ、Microsoft の記憶容量に対する要求を満たすために、2 つ目の SAN は必要となっていません。

地域データセンター

各データセンターでは、その地域内で作成、管理されるすべてのチームサイトを 1 つのチームサイトファームでホストします。チームサイトファームは、Web フロントエンドと SAN で構成されます。このようなチームサイトファームの設計は、可用性と記憶容量の両方に優れたスケーラビリティをもたらします。　

さらに、各データセンターでは、共有サービスファームによって地域内にサービスを提供すると共に、中央共有サービスとの連携によってサービスを全世界に提供しました。ダブリンと調布では、共有サービスに対する要求がレドモンドより小さかったため、SharePoint Portal Server のフロントエンドサーバーを共有サービスファームに組み入れました。図 6 に、調布とダブリンの地域データセンターに展開されたサーバーを示します。

図 6: 地域データセンターのハードウェアアーキテクチャ

レドモンドを除く 2 つの地域がサポートするユーザーの数はそれほど多くないため、プロジェクトチームはダブリンと調布のデータセンターを 2 ノードの SQL アクティブやアクティブパッシブクラスタ構成としました。プライマリノードはすべてのコンテンツデータベースおよび設定データベースをホストします。パッシブノードはセカンダリノードとして設定し、障害が発生したときには負荷を引き継げるようにしました。各ノードには SQL Server 2000 をインストールし、光ファイバケーブルで接続された EVA SAN 筐体のストレージを設置しました。

表 5 にダブリンと調布の OTG サーバー要件を示します。これらの要件は 2 つのデータセンターでほぼ同じです。異なるのは、ダブリンの SAN ストレージが調布より大きい点だけです。

表 6:ダブリンデータセンターおよび調布データセンターの OTG サーバー要件

サーバー要件と留意事項

OTG はフロントエンドサーバーの負荷分散が重要であると判断しました。フロントエンドサーバーは、ユーザーデータの保存には使用せず、バックエンド SQL Server 2000 データベースに保存されているデータのトラフィックおよびインターフェイスレンダリングの処理に特化しました。

レドモンド データセンターには、中央共有サービスファームとチームサイトファームを 3 ノードの SQL Server アクティブやアクティブパッシブクラスタ構成で配置しました。2 つのアクティブノードにはそれぞれのプライマリリソースがあり、コンテンツデータベース負荷の半分を 2 つのノード間でサイズに基づいて分散しました。 3 つ目のノードはパッシブノードであり、他のノードのいずれかで障害が発生した場合に負荷を引き継ぐように設定しました。データの整合性を維持するため、データベースは同じノード上に配置しました。必要な記憶容量の予想がチームサイトファームの記憶容量 3.6 TB を超えていたため、OTG は共有ストレージが 412 GB の EVA SAN を導入しました。この EVA SAN は、必要に応じてディスクを追加し、容量を拡張することができます。

最適なディスク I/O パフォーマンスを実現できるようにハードディスクドライブを 2 つのストレージグループに分け、データベースの半分を一方のドライブに置き、残り半分をもう一方のドライブに配置しました。トラブルシューティングとメンテナンスを簡単に行うことができるように、プロジェクトチームは、リソースグループおよびストレージグループの数を少なくし、複雑さを軽減することにしました。 SAN の初期ディスク容量は、その地域の SharePoint Team Services コンテンツの量を算出し、それに将来の増加分として 25% 上乗せしたサイズを基に決定しました。未使用のディスク領域は、コンテンツが増加したときのために未フォーマットのままとしました。さらに、OTG では、ディスクが低価格化した時期をねらい、必要に応じて追加ディスクを購入することも計画しています。

検索サーバー

チームサイトファーム上のポータルで検索を実行する場合、共有サービスやそのポータルまたは個人用サイトへのページ要求を使用するため、検索サーバーのリソースが必要となります。プロジェクトチームは、検索を高速化するために必要な RAM と CPU の条件について検討しました。

OTG の計算では、2 台のインデックスサーバーがサポートするディスク領域はそれぞれ 100 GB、検索サーバーがサポートするディスク領域は 200 GB となりました (検索サーバーは 2 台のインデックスサーバーが生成した結果を収集します)。ディスク容量は、MSWeb ポータルのインデックスに新しい SharePoint サイトの予想インデックスを加えたサイズを基に決定されました。OTG では、将来の成長に備えると共に、その成長予測にセーフティマージンを加えるために、この合計サイズを 3 倍しました。

検索サーバーは 2 台 1 組で中央サービスファームに展開し、1 台が動作不能になってもコンテンツが使用できるようにしました。 SharePoint Portal Server には使用可能な検索サーバーのテーブルが作成されるため、Windows 負荷分散サービスもハードウェアも必要ありません。

インデックスサーバー

インデックスサーバーは、チームサイトファーム内のすべてのコンテンツとポータルのサイトディレクトリに保存されているファイルをクロールします。一方のインデックスサーバーでは、SharePoint Portal Server Job サービスを実行し、通知とスケジュールされたプロセスを追跡します。もう一方のインデックスサーバーは、ナレッジ管理グループが作成したポータル、サイトディレクトリ、カスタム設定などの各種コンテンツソースをクロールするための追加リソースを提供します。インデックスサーバーは夜間にインデックスを検索サーバーへ転送し、それによって検索に使用される情報を更新します。

バックエンド SQL 2000 Server

SQL Server は主としてデータの保存に使用したため、OTG ではスケーリングに必要となるディスク、CPU、およびメモリの要件について検討しました。 2 つの異なる SQL Server バックエンドストレージ構成でサーバーを展開しました。中央チームサイトファームには 3 台のバックエンド SQL Server コンピュータが必要でした。レドモンド、調布、ダブリンの共有サービスファームには、それぞれ 2 台のバックエンド SQL Server コンピュータが必要でした。

集約とエンタープライズサービス

OTG が展開したソリューションは、SharePoint 製品とテクノロジおよび共有サービスインフラストラクチャを基盤として、標準プラットフォームとツール群を提供しました。

このプラットフォームを拡張し、ユーザーのためにアドオンサービスを構築する必要があるグループは、さまざまな内部グループに対し、アドバイス、カスタム開発、サポートなどを依頼しました。このホワイトペーパーを作成している時点では、セールスおよびサポート (Sales and Support) グループと財務 (Finance) グループがカスタムポータルを作成し、OTG 共有サービスを利用するように設定しました。 OTG のエンタープライズ共有サービスが利用できたことにより、これらのグループはカスタム Web パーツを使用してポータルを作成、運用でき、さらにはバックエンドサーバーでの OTG によるホスティングがもたらす規模の経済も利用できました。

ページのトップへ

アップグレード

このホワイト ペーパーを作成している時点では、OTG は SharePoint Team Services に基づくホストされたサービス上の 26,000 のチームサイトをアップグレードする計画でした。そのコンテンツを Windows SharePoint Services へ移行した後で、サーバーサポートコストを削減するために古いインフラストラクチャを廃棄することにしました。14 台のスタンドアロンサーバーを 3 つのサーバーファームに置き換えたことにより、容量が 10 倍に増加しました。

OTG では、アップグレードプロセスを 2 段階でテストしました。アップグレードテストとして、まず 300 の SharePoint Team Services サイトを Windows SharePoint Services にアップグレードし、その後さらに 800 のサイトをアップグレードしました。

アップグレードプロセス

アップグレードプロセスをテストする第一の目的は、チームサイトの所有者に対する影響を軽減できるかどうかを確認することです。プロジェクトチームでは、2 つのテスト方法の影響について話し合いました。 1 つ目の選択肢は、ユーザーに自分のサイトをアップグレードしてもらうというものです。もう 1 つの選択肢は、OTG が一括して移行するというものです。 OTG は、スムーズに Windows SharePoint Services へ移行できるように、ユーザーのアップグレードエクスペリエンスを管理することにしました。

テスト用に選択した仮想サーバー上のサイトの所有者に対し、週末にコンテンツを Windows SharePoint Services に移行ではなく "アップグレードする" と通知しました。このプロセスをアップグレードと呼ぶことによって、ユーザーはあまり不安を感じず、問題が発生した場合に備えて元のサイトを残しておくにもかかわらず既存のサービスに固執するようなことはありませんでした。名前空間を保持し、アップグレードした Windows SharePoint Services サイトに適用するために、IIS ホストヘッダー名を各サイトに割り当てました。

ユーザーにアンケートを行い、アップグレードが成功したことを確認してから、さらに 800 のサイト (合計 1,100 サイト) をアップグレードしました。元のサイトは、名前を変更し、予想外の問題が発生した場合に備えて、読み取り専用の仮想サーバーに 2 か月間保管しておきました。問題は発生しなかったため、ユーザーが元のサイトにアクセスする必要はありませんでした。

サイトの所有者は、[サイトの設定] 管理ページで SharePoint Portal Server 2003 上のポータルとのリンクを要求することができます。

SMigrate ツール

OTG チームは Windows SharePoint Services の移行コマンドラインユーティリティ (Windows SharePoint Services のインストールメディアに含まれている Smigrate.exe) を使用して SharePoint Team Services サイトのバックアップを作成してからアップグレードを開始しました。 SMigrate はサイトのコンテンツを FrontPage Web Package (.fwp) と呼ばれるハードディスクアーカイブファイル形式でエクスポートします。生成された .fwp ファイルは、SMigrate を使用して新しい Windows SharePoint Services サイトにインポートしました。

SharePoint Portal Server 2001 から Windows SharePoint Services への移行

OTG がホストする 25 の SharePoint Portal Server 2001 サイトのほとんどは、ポータルが必要だったからではなく、ドキュメント管理機能が必要であったために作成されたものです。こうしたサイトの多くには、特定のプロジェクトで使用され、現在は不要となったコンテンツがありました。 Windows SharePoint Services は、これまで SharePoint Portal Server 2001 だけにあったドキュメント管理機能を備えています。そのため、ドキュメント管理に使用されていた SharePoint Portal Server 2001 サイトを検証し、そのコンテンツを削除するか、ドキュメントライブラリへ移しました。これらのサイト内に含まれていたドキュメントは、新しいチームサイトに手動でコピーしました。

グループポータル

SharePoint Portal Server 2003 ではデータを Web Storage System と SQL Server 2000 のどちらにも保存できるため、コンテンツが Web Storage System に残っている場合にポータルをアップグレードするという方法が可能でした。ただし、SQL Server はスケーラビリティとクラスタ機能を備え、ストレージプラットフォームとして SQL Server を広く採用することが Microsoft の方針であったため、OTG は SQL Server 2000 を使用して SharePoint Portal Server 2003 を展開することにしました。

このようなアーキテクチャに決定したことは、一部の機能やカスタマイズしたポータル UI を新しいプラットフォームで使用するためにはコードの開発が必要になることを意味していました。そうした機能には、ダッシュボード Web パーツ、ダッシュボードサイトのカスタマイズ、ルーティングおよびワークフローの承認、1 つのドキュメントライブラリフォルダにつき複数のドキュメントプロファイル、ドキュメントバージョンなどがあります。

OTG が SharePoint Portal Server 2003 を展開したころには、Web Storage System に保存されたコンテンツを SQL Server に移行するツールはまだ提供されていなかったため、最初のポ―タルの移行は手動で行う必要がありました (移行ツールは現在は、提供されております)。

OTG の新しいコラボレーション プラットフォームで SharePoint Portal Server 2003 に移行することには、コンテンツを移行し、新しいポータルをカスタマイズし直すのに手間がかかるとはいえ、それをはるかに上回るメリットがありました。

ページのトップへ

得られた教訓

OTG では、アーキテクチャ、移行、および運用に関して有益な教訓を得ることができました。そうした教訓は他の企業が SharePoint 製品とテクノロジを展開する際にも役立つと考えられます。

アーキテクチャ

SharePoint Portal Server ソリューションの計画においてきわめて重要な作業と言えるのが、必要な記憶容量とハードウェアソリューションを決定することです。 OTG は Microsoft のデータセンターではまだあまり使用されていない新しい SAN テクノロジを実装することにしていたため、プラットフォームに対する現在および将来の要求に応えられるよう、ハードウェアベンダと共同でアーキテクチャ計画を入念に作成しました。

Windows SharePoint Services では基本的な機能群で個々のチームのニーズに対応できるため、展開する際には戦略的な決定がほとんど必要ありません。それに対し、SharePoint Portal Server の場合は、展開の仕方によって、グループおよび部門における情報の表示方法が変わり、管理者向けに情報を要約する方法も影響を受けます。そのため、アーキテクチャに関する決定はビジネス目標に大きく依存することになります。その例を次に示します。

サービスを展開する前に、その環境でポータルがどのような機能を果たすのかを明確にし、それに基づいてサービスの最適な設計およびサポート方法を決定してください。サイトおよびポータルのアーキテクチャは柔軟性とスケーラビリティを備えていますが、サイトまたはポータルと共有サービスの関係を変更するためには、設定データベースのエントリを変更する必要があります。変更の必要があるエントリは、サーバーファーム内の共有サービスの設定に関するものです。

SharePoint はコラボレーションファイル用に設計されている

SharePoint はコラボレーションシナリオ向けに設計されています。アプリケーションファイルストレージに代わるものではなく、トランザクションデータの管理を目的としたものでもありません。 OTG では、アップロードできるファイルの最大サイズを 100 MB に設定しました。これには 2 つの理由があります。まず、100 MB までのファイルであればアップロードにそれほど時間がかからず、ユーザーの不満につながるタイムアウトエラーが発生しないからです。もう 1 つの理由は、100 MB を超えるファイルがコラボレーションで使用される可能性が低いことです。 OTG では現在もアップロードできるファイルの最大サイズについて検討を続けており、コラボレーションコンテンツのプラットフォームの利用を促進するために最大サイズをもっと小さくする可能性もあります。

SharePoint は要求に応じてスケールアップおよびスケールアウトする

OTG が Windows SharePoint Services および SharePoint Portal Server の最初のパイロット展開を行ったときには、SQL Server バックエンドとして 1 台のコンピュータを使用しました。その後はサーバーを追加していき、データセンターのハードウェア基準に記載されている最大サイズのサーバーでも十分でなくなったときに、SAN ソリューションの導入を決定しました。

SAN の導入を検討するときには、ハードウェアベンダと相談しながら必要なハードウェアと構成を決定することが重要です。大規模なエンタープライズ環境では、通常、SAN は SQL Server のストレージとして使用します。 Microsoft の場合、SAN を導入した背景にはギガバイトあたりのコストパフォーマンスが高いことがありました。 400 GB を超えると、Microsoft のプラットフォームでは SAN の費用対効果が高まります。 OTG は、データセンターにおいて SAN が稼働できるだけの十分なスペース、電力、冷却設備、耐震設備を確保できるように、データセンターのスタッフと共同で作業を進めました。

アップグレードと移行

SharePoint Team Services から Windows SharePoint Services へのアップグレードを成功する鍵は、入念に計画を立てることにあります。以下の教訓は移行作業を進める中で得られたものです。

パイロットを実施する

段階的に移行する場合は、正式なパイロットは必要ありません。管理者または展開チームから概念実証を求められた場合や、展開の規模を決定するためのデータが不足している場合に、パイロットの実施を検討してください。 OTG では SharePoint Team Services サービスの普及率を調べ、新たな Windows SharePoint Services ソリューションの要件を導き出しました。普及率が予想より高かったため、インフラストラクチャの容量には将来の成長に備えて余裕を持たせました。

予期しない SharePoint データの移行への備え

Microsoft では多くのチームがファイルを OTG が管理していないファイル共有に置いていました。 OTG は、こうしたチームの多くがコンテンツを OTG のコラボレーション プラットフォームに移行し、コンテンツのインフラストラクチャの管理業務から解放されたいと考えていることを知りました。当初の移行計画に含まれていない大量のコンテンツを管理することになると、展開中だけでなく、その後およそ 6 か月にわたり、きわめて大きな影響をもたらします。

運用

OTG では、早期に計画を開始し、ストレージとパフォーマンスを予想することによって、運用上の問題を最小限にとどめました。次に、OTG 運用チームが得た教訓について説明します。

個人用サイトの URL に Active Directory 属性を割り当てる

wwwHomePage という Active Directory 属性が使用されているかどうかをチェックしてください。既定では、Microsoft のユーザーには自分の wwwHomePage 属性への書き込みアクセス権が与えられます。個人用サイトを作成すると、Active Directory では、IT 管理者が代わりのプロパティを指定しない限り、この属性が上書きされます。

個人用サイト

従業員が組織内で移動する場合に運用担当者がどのように対応するかについて、管理者の観点から検討してください。たとえば、Microsoft の従業員がレドモンドからヨーロッパのオフィスへ異動になった場合は、その従業員の個人用サイトをダブリンの共有サービスファームへ移すことができます。役職によっては、世界各国へ出張する必要があり、個人用サイトの場所を簡単には 1 か所に決めることができない場合もあります。

すべてのユーザーが簡単に MSWeb 中央ポータル (レドモンドでホストされている) にアクセスできるように、ダブリンと調布の個人用サイトをホストするポータルがネームサービスリダイレクトを使用してユーザーを MSWeb にリダイレクトします。これによって、個人用サイトから 1 つ上のレベルへ移動する場合、どのユーザーでも必ず同じポータルが開きます。

発行サイズとクォータ管理には調整が必要

OTG では、当初、Windows SharePoint Services サイトの既定のクォータを 100 MB に設定しました。記憶容量の拡張を求める要望が多数寄せられ、そうした要求を処理するにも費用がかかるため、その後、OTG では、クォータを 100 MB 単位で増やすよりも最初の要求で 500 MB まで引き上げる方が費用対効果に優れた方法であると判断しました。さらに、OTG は 1 サイトあたりのディスク領域サイズに妥当な最大値を設定できるため、突然ストレージ要求が記憶容量を超えるようなことはありません。

OTG では、当初、ファイルの最大アップロード容量を 50 MB に設定しましたが、この最大値に達してしまうユーザーが多かったため、100 MB に引き上げました。こうした初期最大値を決定するときには、Microsoft Exchange や SharePoint Team Services を展開した際の経験を参考にしています。容量の拡張に対する要望が増えたり最大アップロード容量に達することが多くなったときには、最大値を引き上げたときの影響について検討してください。

最大アップロード容量を設定するときに考慮する必要がある点がもう 1 つあります。それは、このプラットフォームの目的がコラボレーションであることです。このプラットフォームでは大きなサイズのファイルをアップロードできますが、コラボレーションでは比較的小さいファイルを扱うことが多いため、OTG では最大アップロード容量を小さくすることを検討しています。最大アップロード容量は、企業ごとにそれぞれの状況に応じてどのような値にも設定できます。このプラットフォームをコラボレーションに適したものにする方法として、OTG ではコラボレーションに使用しないファイルの種類をアップロード不可にしています。 Microsoft にはアプリケーションコンポーネントを保存するためのソリューションが別にあるため、そうしたファイルは SharePoint サイトにはアップロードできません。

ホストヘッダー名は特殊なケースで役に立つ

OTG では、カスタムスクリプト付きのホストヘッダー URL ("修飾名" ともいう) を作成しました。ホストヘッダーを使用することにより、指定された名前空間の長い URL ではなく、覚えやすく宣伝の面でも便利な URL を作成できます。ホストヘッダーを使用するサイトを作成するにはヘルプデスクに依頼する必要があるため、OTG ではホストヘッダーの広告を通常の業務として行わないことにしました。その代わりに、要求された名前をコラボレーション プラットフォームの名前空間に存在する特定のサイトにマップし、URL のリダイレクトを行っています。

大規模サイトには Windows セキュリティグループを使用する

チームサイトの初期メンバシップを設定するために使用する配布グループは拡張され、配布グループの初期メンバシップのみが反映されるため、大規模なサイトの Active Directory のメンバシップを管理するにはセキュリティグループの方が便利です。配布グループは、小規模なサイトや使用期間が短いためにメンバシップが変更される可能性の低いサイトに適しています。セキュリティグループは拡大されないため、アクセス権には Active Directory で行われた最近の変更が反映されます。

サポート上の主要な問題

次に、サポートチームが対処した主要な問題について説明します。

ページのトップへ

ベスト プラクティス

OTG では、コラボレーションソリューションの展開において以下のような最適な方法を見いだしました。

チームコラボレーション

まず、チーム コラボレーションにおける最適な方法について説明します。

エンタープライズサービス

次に、エンタープライズサービスに関する最適な方法について説明します。

当社では、SharePoint 製品とテクノロジを基盤として精巧な情報ネットワークを作り上げました。この SharePoint環境では、個々のインフォメーションワーカーのドキュメントからエンタープライズサービスまで、あらゆるものが緊密に統合されており、必要なものを検索し、発見することができます。

Microsoft Corporation

OTG グループ マネージャ
Joe McGinn

ページのトップへ

まとめ

SharePoint 製品とテクノロジに基づくコラボレーション プラットフォームは、Microsoft の情報管理戦略を支える中核的な要素の 1 つです。 OTG では、集中化、管理性、および長期的なコスト削減に対する IT 側の要求だけでなく、よりシームレスなコラボレーションを求めるインフォメーション ワーカーの要望にも対応しました。

IT 運用の面では、OTG によって次のことが可能になりました。

OTG は次のように作業環境を簡素化することによってインフォメーション ワーカーの生産性を高めました。

ページのトップへ

詳細情報

Microsoft の製品およびサービスの詳細については、Microsoft Sales Information Center (電話 : (800) 426-9400) までお問い合わせください。カナダ国内のお問い合わせ先は Microsoft Canada information Centre (電話 : (800) 563-9048) です。米国 50 州およびカナダ以外の地域の方は、お近くの Microsoft 子会社までお問い合わせください。インターネットでは、次の Web サイトで当社の情報をご覧いただけます。

http://www.microsoft.com/japan/

次の Web サイトでは、関連するドキュメントと導入事例を紹介しています。

http://www.microsoft.com/japan/technet/itsolutions/msit/default.mspx

SharePoint 製品とテクノロジに関する情報については、http://www.microsoft.com/japan/sharepoint をご覧ください。

このドキュメントに関する質問、コメント、またはご意見がある場合、または Microsoft IT 導入事例についての追加情報が必要な場合には、showcase@microsoft.com に電子メールでご連絡ください。(英語のみ)

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。

このホワイトペーパーに記載された内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このホワイトペーパーは、個人的な教育を目的とする場合に限り、全体または一部を複製することができます。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

© 2003 Microsoft Corporation. All rights reserved.

Microsoft、Active　Directory、Outlook、PowerPoint、SharePoint、Windows、Windows　Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

ページのトップへ