ありがちミスの傾向と対策

SharePointの導入プロセスで避けるべき初歩的ミス

SharePointは、インストールと構成が簡単過ぎるほど簡単なだけに、導入過程で「初歩的ミス」を犯してしまいがちだ。最もありがちなミスとそれらを回避する方法を紹介する。

公開 2008年12月16日 08時00分

更新 2012年09月04日 18時26分

著者

Shawn Shell

[TechTarget]

印刷する

　SharePointの企業への導入が急激に進んでいるようだ。2001年から提供されているが、最近のバージョンでアーキテクチャにさまざまな変更が加えられたおかげで、人気に火が付いている。だが、SharePointを適切に導入するのは意外と難しい。

　SharePointは、インストールと構成が簡単過ぎるほど簡単で、非常に楽に使える。しかし、かえってそのために、多くの企業が導入過程で「初歩的ミス」を犯してしまう。以下では、最もありがちなミスとそれらを回避する方法を紹介しよう。

基本インストール vs. 詳細インストール

　SharePointをインストールする際、多くの企業は誤って基本インストールオプションを選択する。無難な選択肢に思えるからだ。この場合、作業は至って簡単で、マウスを数回クリックすればインストールできる。

　しかし、多くの企業にとっては詳細インストールオプションの方が適している。

　次の場合には、必ず詳細インストールオプションを選択すべきだ。

すべての関連要素を同じサーバにインストールしたくない

　大抵の場合、企業は少なくともMicrosoft SQL Server（以下、SQL Server）を別のサーバで運用すべきだが、基本インストールではこのデータベースサーバを指定できない。また、Webフロントエンド（WFE）サーバ群の負荷分散を行いたい場合も、詳細インストールオプションを選択する必要がある。

新規または既存のSQL Serverのフルバージョンを使いたい

　SharePointは、コンテンツと構成の保存をSQL Serverに大きく依存している。基本インストールではSQL Expressがインストールされるが、このデータベースは開発用やワークグループなど、非常に小規模な環境用には役立つが、部門レベルや全社レベルでの運用には適していない。

フォールトトレランスが必要

　負荷分散環境や高可用性環境の目的は、パフォーマンスの維持・向上だと誤解している企業が多い。実は、負荷分散やRAID、そのほかの高可用性ソリューションを利用する場合、効果として重要なのは、本当はフォールトトレランス（耐障害性）であることがほとんどだ。基本インストールでは、高可用性環境は構成できない。

サービスアカウントとパーミッションの不適切な利用

　SharePointは多くのサーバベースツールと同様に、自身のインストール先サーバおよび関連サービスとやりとりを行わなければならない。そのため、「サービスアカウント」が必要になる。サービスアカウントは、SharePointがSQL Serverとの通信や、コンテンツのクロール、ファイルシステムへのインデックス情報の追加、ワーカープロセスの作成といった機能を果たすために使う特殊なIDだ。

　SharePointをインストールする際、多くの企業が誤ってNETWORK SERVICEやSYSTEMといったシステムアカウントを使用する。また、管理者アカウントやそれと同等のものが使われる場合もある。どちらのアプローチも禁物だ。主要なSharePointサービスごとに別々のドメインアカウントを使わなければならない。各アカウントは最小限の権限で構成する必要がある。

　作成すべき最低限のアカウントを以下に示す。

プライマリSharePointサービスアカウント

　全体管理に加えてSQL Serverとの通信に使われる。

検索アカウント

　検索するのにサービスアカウントが必要な場所が幾つかある。1つのアカウントですべてまかなうことも許容範囲だが、検索アカウントは、インデックスサーバとWFEサーバに対する管理権限が必要なため、異なる検索サービスごとに別のアカウントを使う方がよいだろう。コンテンツに加えてメンバーシップディレクトリにアクセスするためにクロールアカウントも使われることに注意する必要がある。このアカウントには、そのディレクトリの内容にアクセスする権限を与えなければならない。

アプリケーションアカウント

　環境内のWebアプリケーション（Webサイト）ごとに個別にIDを作成しなければならない。これは、アプリケーション間にセキュリティ境界を設けるのに役立つほか、所定のアプリケーションにどのワーカープロセスがサービスを提供しているかを特定する助けにもなる。例えば、タスクマネージャでは、プロセスのIDがプロセスのイメージ名の隣に表示される。

共有サービスアカウント

　Microsoft Office SharePoint Server（MOSS）をインストールすると、共有サービスがエンタープライズ検索、個人用サイト、BDC（ビジネスデータカタログ）をコントロールする。共有サービスは、SharePointサイトのような独立したアプリケーションだ。

ドライブ容量の不適切な割り当て

　SharePointのインストールプロセスでは、ソフトウェアやインデックス、カスタムソリューションの場所、ログといったすべてがプライマリシステムドライブに配置される。プライマリシステムドライブは大抵Cドライブだ。だが、多くの企業ではCドライブは、OSファイルだけを格納するという前提で、パーティションが小さく設定されている。このため、SharePointのインストールによってすぐに容量が足りなくなる恐れがある。

　SharePointサーバは、WFE、検索、インデックス、データベースのどのサービスを提供するかによって容量の要件が異なる。SharePointサーバが検索サーバかインデックスサーバである場合、インデックスのためにコンテンツの全容量の少なくとも25％を用意しなければならない。大量のコンテンツをクロールすると、小さなCドライブのパーティションではあっという間に容量を使い果たしてしまう。また、SQL Serverを使用する場合、SharePointで使われるすべての情報がこのデータベースに格納されることに留意する必要がある。コンテンツはすべてバイナリとして保存され、データベースファイルとトランザクションログは急速に大きくなる。バージョニングを有効にすると、そのペースはさらに速くなる。要するに、SharePointサイトに関連するデータファイル、インデックス、そのほかの資産は必ず、容量に余裕があるドライブに配置しなければならない。

ディザスタリカバリ対策がなおざり

　多くの企業は事業継続計画の一環としてディザスタリカバリ対策を策定する際、SharePointの特性を軽視したり無視したりする。SharePointは、平均的なデータベース主導型ポータルよりも複雑だ。このため、そのアーキテクチャを理解した上で環境の復旧計画を作成する必要がある。

　初歩的ミスはもっとたくさんあるかもしれないが、以上の4つは特にありがちなものだ。これを参考にすれば、Windows管理者はSharePointの導入において犯しやすいミスを回避し、時間を節約するとともにトラブルを未然に防ぐことができる。ただし、企業や部署によって環境やニーズは異なる。自分のケースに即した導入計画を立て、実行しよう。

本稿筆者のショーン・シェル氏は、Webベースアプリケーション、社員およびパートナー向けポータル、エンタープライズコンテンツ管理を専門とするコンサルティング会社Consejoの創業者。IT業界で19年以上の経験を持ち、この10年はコンテンツ技術に力を入れて取り組んでいる。「Microsoft Content Management Server 2002: A Complete Guide」の共著者であり、CMS Watchの「The SharePoint Report 2008」の作成過程で主席アナリストを務め、同リポートを執筆した。

印刷する