次の方法で共有

SharePoint の内部

  • [アーティクル]

この記事の情報はベータ版を基にしています。ここに記載されている情報は変更される可能性があります。

SharePoint 2010 の使用に備える

Pav Cherny

SharePoint 2010 のリリースを間近に控えた今、アップグレードと移行のオプションについて検討して、環境の準備を整えるための対策を立てる好機です。
多くのアップグレード シナリオや移行シナリオでは、ネットワーク接続からサードパーティ製アプリケーションやビジネスの継続性に至るまで、数千とまで行かなくても数百もの細目を検討する必要があることで、作業の複雑さが増しています。新しいバージョンに移行したり、インプレース アップグレードと移行のどちらを行うのかを判断したりする際に使用できるフレームワークやシナリオには、さまざまなものがあります (たとえば、新しいバージョンへの移行には、準備、テスト、実装、評価という段階を踏むことができます)。

ですが、今なら、移行戦略を計画して、SharePoint 2010 への移行時に発生する問題を軽減するための準備をする時間があります。

この記事では、現時点で、SharePoint 2010 の使用に備えて実施できる大きな影響を持つ対策の一部をご紹介します。さらに詳しい情報が必要な場合は、既存のドキュメントを参照して、追加の情報を入手したり、包括的な計画を立てたりすることができます。

参考資料としては、Joel Oleson が自身のブログ (sharepointjoel.com、英語) で公開しているアップグレードへの対応状況に関するプレゼンテーションとホワイト ペーパーがあります。また、マイクロソフトでは、準備用のガイド (英語) を提供しています。

ハードウェアとソフトウェアの依存関係を解決する

環境の準備を整える際には、まず、既存のソフトウェアとハードウェアの構成を調査して、その構成が SharePoint 2010 のシステム要件を満たしているかどうかを確認し、要件を満たしていない場合は更新します。全体に関する最も重要な要件は、64 ビット対応のハードウェアと SharePoint 2007 SP2 です。

もちろん、他にも事前にできることはあります。次のベスト プラクティスに従って、フロントエンド サーバー、アプリケーション サーバー、バックエンド サーバー、およびクライアントの環境の更新を検討してください。

フロントエンド サーバーでは、Windows 7 ベースのユーザー インターフェイスを採用している 64 ビット版の Windows Server 2008 または Windows Server 2008 R2 が必要です。この記事の執筆時点では、SharePoint は、Windows Server 2003 でも特に大きな問題が発生することなく実行されていますが、SharePoint 2010 への移行準備の大部分は、OS のアップグレード作業になります。

既に 64 ビット対応のハードウェアで Windows Server 2003 を実行している場合は、サーバーを再利用して、フロントエンド サーバー、アプリケーション サーバー、およびバックエンド サーバーについてはインプレース アップグレードを実行できます。新しいサーバーをファームに追加して、サーバー管理 Web サイト、フロントエンド サーバーの役割、およびアプリケーション サーバーの役割を移行できます。Windows Server 2008 へのアップグレードを検討している場合は、次のベスト プラクティスを考慮する必要があります。

  • Windows SharePoint Services Timer (SPTimerV3) にアクセス許可を付与する。ファームの管理者アカウントがローカルの Administrators グループに追加されていないか、スタンドアロン インストールを使用している場合は、stsadm -o grantiis7permission というコマンドを実行して、IIS 7.0 から情報を読み取る許可を SPTimerV3 に与えます。
  • Windows SharePoint Services Search (Spsearch) サービスを停止する。Windows Server 2008 をインストールして、Spsearch サービスが実行されているときに SharePoint Products and Technologies Configuration Wizard (SharePoint 製品とテクノロジ構成ウィザード) を実行すると、検索インデックスが破損することがあります。壊れたインデックスを再作成するには、stsadm -o spsearch -action stop というコマンドを実行してから、SharePoint サーバー管理 Web サイトの Windows SharePoint Services Search サービスの設定ページでデータベースの名前を変更する必要があります。詳細については、tinyurl.com/l6fmkr を参照してください。
  • IIS 7 の設定を確認する。IIS 6.0 で Front Page Server Extensions などの上位互換性のない機能を使用していた場合、Windows Server 2008 と IIS 7 にアップグレードすると、W3SVC サービスが無効になることがあります。もう 1 つの問題は、IIS 7 で既定の認証として使用されるカーネル モードの認証です。401.1 エラーが発生する場合、その原因は、カーネル モードの認証にある可能性があります。これは、IIS の Windows 認証の詳細設定で無効にできます。詳細については、technet.microsoft.com/ja-jp/library/cc288081.aspx を参照してください。

バックエンド サーバーでは、64 ビット版の SQL Server 2005 以降が必要です。SQL Server Express もサポートされていますが、SharePoint 2010 に移行するときには、バックエンド サーバーのインフラストラクチャを再検証して最適化することができるので、上位エディションを使用することをお勧めします。

SQL Server Standard Edition と Enterprise Edition には、管理ツールやクラスタリングなどの高可用性の機能が用意されています。

クライアント ブラウザーのサポートについては、SharePoint 2010 では、Internet Explorer 6 はサポートされておらず、IE 7 以降の標準ベースのブラウザーのみがサポートされます。また、IE 以外には Firefox 3.x と Safari がサポートされます。

アップグレード チェッカー ツールを実行する

フロントエンド サーバーが 64 ビット対応ハードウェアで Windows Server 2008 を実行していること、バックエンド サーバーで SQL Server 2005 以降が実行されていること、クライアントが標準ベースのブラウザーを使用していることを確認したら、stsadm -o preupgradecheck というコマンドを実行します。PreUpgradeCheck は SharePoint 2007 の SP2 に同梱されているツールで、規則ファイルを使用して、構成データを確認し、レポートを作成します。Microsoft Office SharePoint Server (MOSS) 用の規則ファイルは OssPreUpgradeCheck.xml、Windows SharePoint Services (WSS) 用の規則ファイルは WssPreUpgradeCheck.xml です。

PreUpgradeCheck を実行する前には、当然ながら SP2 をインストールする必要があります。インストール ウィザードは、単純明快ですが、3 つの注意事項があります。まず、各サーバーのフロントエンド IIS サービスを停止して、コンテンツ データベースをバックアップしてデタッチする必要があるので、処理を開始する前に、ユーザーに計画済みのダウンタイムがあることを通知する必要があります。特にカスタマイズしている場合は、フロントエンド サーバーとアプリケーション サーバーのファイルをバックアップすることもお勧めします。

次に、WSS SP2 をインストールし、構成ウィザードをキャンセルして、MOSS SP2 をインストールする必要があります。

最後に、更新処理が完了したら、upgrade.log にエラーが記録されていないことを確認します (このファイルは、12 ハイブの logs ディレクトリにあります)。失敗やエラーに関する情報を検索します。インストールが正常に完了すると、upgrade.log には、図 1 のような文字列が含まれます。更新処理の詳細については、technet.microsoft.com/ja-jp/library/cc263467.aspx を参照してください。

PreUpgradeCheck を実行すると、環境に関する詳細情報、ファーム トポロジ、サーバー構成、代替アクセス マッピング (AAM)、データベース、機能、サイト定義などに関する詳細情報を含む詳細レポートが生成されます。コマンド プロンプトに出力される情報からは、問題のあるカテゴリを判断できます。このようなカテゴリについては、SharePoint 2010 に移行する前に変更する必要があります。詳細な .HTM ファイルは、問題の原因となっている状況を解決するために必要なことを調査するのに役立ちます。.HTM ファイルでは、次の情報を確認します。

  • Language packs (言語パック)。構成で言語パックが必要な場合は、SharePoint 2010 への移行後に、言語パックを最新のバージョンにアップグレードする計画を立てる必要があります。
  • AAM。SharePoint 2010 に移行して、新しいサーバー (または、新しいサーバー名) を使用する計画を立てている場合は、AAM エントリや DNS エントリの更新など、URL に関連する変更を加えなければならない可能性が高いです。
  • Site definitions (サイト定義)。カスタム サイト定義を使用するサイトのアップグレードには、SharePoint 2010 で使用する定義ファイルが必要です。このファイルは、カスタム定義に合わせて作成する必要があります。詳細については、msdn.microsoft.com/ja-jp/library/ms439232.aspx を参照してください。
  • Features (機能)。レポートで不足している機能がないかどうかを確認し、不足している機能がある場合はインストールします。
  • Lists (リスト)。リストのサイズと数は、移行処理に影響するので、これらを確認します。マイクロソフトでは、パフォーマンスとサイズに関する推奨事項を technet.microsoft.com/ja-jp/library/cc262787.aspx で公開しています。リストに 2,000 ～ 5,000 件以上のアイテムが含まれているか、環境の規模が拡大して他のパフォーマンス ガイドラインを満たさなくなった場合は、ベスト プラクティスに従って調整する必要があります。
  • Configuration DB and Content DB orphans (孤立した構成 DB とコンテンツ DB)。管理作業やユーザー操作の過程では、SharePoint のスキーマやデータベース アイテムに親子関係が存在しないという状況が発生することがあります。このようなアイテムには、親サイトのないリスト、親ドキュメント ライブラリのないドキュメント、親リストのないリスト アイテム、親サイトのない Web ページ、タイマー ジョブなどがあります。PreUpgradeCheck ツールでは、必ずしも孤立したオブジェクトが検出されるとは限らず、SharePoint サーバー管理 Web サイトに孤立したオブジェクトが表示されないことがあります。そのため、孤立したオブジェクトは手動で確認する必要があります。このようなオブジェクトには、構成が孤立しているものとコンテンツが孤立しているものの 2 種類があります。構成が孤立しているオブジェクトとは、構成 DB に含まれるアイテムで、コンテンツ DB に子コンポーネントを持たないものです。コンテンツが孤立しているオブジェクトには、2 つの場合があります。1 つは、構成 DB で空のサイトがマップされ、そのサイトに関連付けられているコンテンツ DB が存在しない場合です。もう 1 つは、適切なコンテンツ DB が構成 DB のサイトと関連付けられているが、他のコンテンツ DB に迷子のアイテムがある場合です。

Finished upgrading SPFarm Name=<ConfigDBName>

In-place upgrade session finishes. Root object = SPFarm=<configDBName> , recursive = True , 0 errors and 0 warnings encountered.

図 1: SP2 が正常にインストールされた場合に upgrade.log に記録される文字列

 

構成が孤立しているオブジェクトは簡単に解決できます。必要なのは、コンテンツ DB をデタッチして、再アタッチするだけです (コマンドは、stsadm -o deletecontentdb and stsadm -o addcontentdb です)。

事前に、MOSS 2007 環境で stsadm -o preparetomove というコマンドを実行することを忘れないでください。

サイトが不適切な空のコンテンツ DB にマップされていることが原因でコンテンツが孤立しているオブジェクトを解決するには、不適切な コンテンツ DB をバックアップしてから削除し、適切なコンテンツ DB をアタッチします。

コンテンツ DB が孤立していることが原因でコンテンツが孤立しているオブジェクトを解決するには、運用サイトをバックアップしてから削除し、孤立しているコンテンツ DB にアクセスできるようにアタッチしてから、コンテンツ DB を削除します。その後、バックアップしたサイトを復元します。

詳細については、サポート技術情報の記事 918742 と 918744、および STSADM のコマンド (-o databaserepair、-o deletecorruption、-o repairorphans、および -deleteconfigurationobject -id <objectId>) を参照してください。

詳細な構成は、フロントエンド サーバーによって異なるので、各サーバーで PreUpgradeCheck を実行し、構成の違いを確認する必要があることに注意してください。

stsadm -o preupgradecheck -localonly というコマンドを実行すると、各サーバーの構成を確認して、このコマンドで生成される .HTM レポートを WinDiff などのツールを使用して比較できます。

PreUpgradeCheck の詳細については、technet.microsoft.com/ja-jp/library/dd793605.aspx を参照してください。

整理と標準化

SharePoint 2010 に移行するための作業のうち、対応に最も時間がかかる問題の 1 つがカスタマイズです。サイトを少しカスタマイズしているだけのシンプルなシナリオでも、SharePoint 2010 への移行には、詳細の記録、移行、確認、問題の解決という作業が必要になります。

大規模なカスタマイズを行っているサイトやサードパーティ製のツールを使用しているサイトでは、その複雑さにより、カスタマイズを移行するためのソフトウェア開発プロジェクトが必要になります。

IT プロフェッショナルが、可能な限り標準化し、カスタマイズを文書化し、データと構成の詳細を整理することで、開発者による問題解決が簡略化されます。

カスタマイズの種類 アップグレードと移行のベスト プラクティス
サードパーティ製のアドオン アップグレード パスと推奨事項をベンダーに確認します。
サイト定義 "サイト定義にリセット" 機能を使用します。サイト定義マップを作成し、空のサイトと既存のサイトを使用して移行のテストをします。
SharePoint 2003 の名残 孤立したオブジェクトと古いオブジェクトを削除して、新しいファームと DB アタッチを作成して移行します。
CSS、テーマ、/_Layouts など マスター ページと CSS を整理または作成します。コードをソリューションとしてパッケージ化します。
ワークフロー、Web パーツ 削除して再インストールするのか、作成し直すのかを文書化して判断します。テスト環境に展開して、機能を確認します。

図 2: カスタマイズの移行に関するベスト プラクティス

整理するという選択肢については、既に説明しました。孤立したオブジェクトを確認して、機能や Web パーツの依存関係を解決して、リストを最適化して、データベースの制限を 100 GB に設定して、その他の最適化処理を行うと、移行が簡略化されます。

使用していないサイトを削除して、しきい値を高くして、ユーザーがサイトのクリーンアップを実行するようにすることによっても、移行するデータのサイズを縮小できます。また、ソリューションや機能は可能な限り標準化し、カスタマイズについては、削除、再インストール、または再作成のうち、最適なものを検討する必要があります。カスタマイズに関する一般的なベスト プラクティスとオプションについては、図 2 を参照してください。

SharePoint 2010 は、まだリリースされていないので、カスタマイズについて準備およびテストできることは限られています。

多くの環境における最善の方法は、インプレース アップグレードではなく、新しいファームを作成し、コンテンツ データベースを移行して、カスタマイズを適用する計画を立てることです。

この方法を採用すると、徐々にアップグレードを進めて、サイトを移行しながら、不要になったサーバーの使用を中止できます。

仮想化の可能性を活用する

仮想化テクノロジと関連する管理ツールの利便性により、運用環境をアップグレードする前に、移行計画を評価して確認することが可能になりました。

その最たるものは、仮想マシンを使用して実際よりも小さな規模で運用環境を構築して、運用環境に実装する前に移行戦略やアップグレード戦略を評価できることです。

仮想化テクノロジでは、OS のスナップショットをキャプチャして、オンデマンドでスナップショットを復元する機能が提供されます。この機能により、移行手順を詳しく文書化して、運用環境を更新する場合には、文書化された手順を実行すればよいという状況を作ることができます。

今後の展望

今月号の記事では、実用的な観点から移行の対応状況を取り上げ、SharePoint 2010 の使用に向けて環境の準備を整えるための作業を提案しました。

64 ビット対応ハードウェアへの移行、PreUpgradeCheck ツールの実行、検出された問題の解決、仮想化環境での計画の評価という主な提案作業を実行すれば、SharePoint 2010 への移行に向けた準備は十分です。

 

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