SharePoint 2010 の展開: SharePoint 2010 へのアップグレードの準備をする
SharePoint 2010 へのアップグレードは、すぐにでも取り掛かりたくなる魅力的な作業ですが、そのためにはかなり多くの計画を立てる必要があります。このコラムでは、アップグレードの計画プロセスについて説明します。
Brien Posey
SharePoint 2010 へのアップグレードは、これまでに行ったことがあるどのアップグレードとも異なります。アップグレードの計画プロセスを開始する前に、SharePoint 2010 のシステム要件を確認する必要があります。と言うのも、以前のバージョンの SharePoint とは異なり、SharePoint 2010 は 64 ビット版のみの提供となるからです。このため、SharePoint 2010 は、64 ビット版の Windows Server 2008 か Windows Server 2008 R2 にインストールする必要があります。
SharePoint には SQL Server データベースが必要ですが、SQL Server データベースを SharePoint と同じサーバーに配置する必要はありません。SQL Server が必要なのは SharePoint 2010 でも変わりませんが、重要な変更がいくつか行われたので、SharePoint 2010 では、64 ビット版の SQL Server 2005 か SQL Server 2008 のデータベースが必要です。これは、データベースが SharePoint サーバーのローカルにインストールされているかどうかにかかわらず必要な条件になります。
技術的なシステム要件ではありませんが、使用する Web ブラウザーについても考慮することをお勧めします。SharePoint 2010 は、Web 標準をより有効に活用するように設計されています。つまり、ユーザーは Internet Explorer と Firefox (3.x 以上) のどちらを使用している場合でも、一貫した方法で作業できます。注意する必要があるのは、SharePoint 2010 では Internet Explorer 6 のサポートが限られている点です。IE 6 ユーザーは、SharePoint のコンテンツを表示することはできますが、コンテンツの作成には IE 7 以上 (または、Firefox 3.x 以上) が必要です。
インプレース アップグレード
既にご存じかもしれませんが、SharePoint 2010 は、Microsoft Office SharePoint Server (MOSS) 2007 からのインプレース アップグレードが可能です。ですが、SharePoint 2010 は 64 ビット版しか提供されないため、お使いの MOSS 2007 が 64 ビット版の Windows Server 2008 で実行されている場合のみ、インプレース アップグレードを実行できます。お使いの SharePoint サーバーが必要なシステム要件を満たしている場合、SharePoint ファームにあるすべてのサーバーでインプレース アップグレードを実行できます。
SharePoint ではインプレース アップグレードが全面的にサポートされていますが、個人的には、SharePoint を単純に展開していてまったくカスタマイズをしていない場合のみ、インプレース アップグレードを推奨します。もっと複雑な環境でアップグレードを行う場合は、アップグレード プロセスをより細かく制御できる完全移行をお勧めします。カスタマイズした環境でも同様で、完全に移行することによって、カスタマイズを誤って上書きせずに済みます。
通常、移行を行う場合は、SharePoint 2010 を実行するまったく新しい SharePoint ファームを構築します。構築後は、既存の SharePoint データベースを新しいファームにアタッチできます。また、インプレース アップグレードと新しい SharePoint 2010 サーバーを組み合わせた、ハイブリッドな移行戦略を使用することもできます。
アップグレード前のチェック
インプレース アップグレードと移行のどちらの場合も、実際にプロセスを開始する前には、計画と準備が必要です。アップグレード前チェック ツールの実行は、SharePoint 2010 へのアップグレードの準備において最も重要なプロセスの 1 つです。MOSS 2007 のリリース前に、マイクロソフトは Prescan.exe というユーティリティを公開しました。これは、MOSS 2007 にアップグレードする前に、お使いの SharePoint の展開が正常な状態かどうかを確認できるユーティリティでした。
Prescan.exe は MOSS 2007 では便利なツールでしたが、SharePoint 2010 の展開前の分析にはあまり適していません。このため、マイクロソフトは、アップグレード前チェック ツールという新しいツールを提供しました。アップグレード前チェック ツールは、Prescan.exe から大幅に改善されています。まず第一に、アップグレード前チェック ツールは読み取り専用なので、SharePoint サーバーが変更されることを懸念する必要はありません。
アップグレード前チェック ツールが非常に便利な点は、その前身である Prescan.exe よりも徹底的に問題の検出が行われるところです。また、拡張も可能です。アップグレード前チェック ツールには、SharePoint サーバーの分析に使用する一連のルールが用意されています。これらのルールは XML 形式なので、ニーズに合わせて独自のルールを作成できます。また、XML ベースのルールを使用することで、推奨するベスト プラクティスを変更した場合に、マイクロソフトがアップグレード前チェック ツールを簡単に更新できます。
ですが、おそらく最もすばらしい点は、アップグレード前チェック ツールによって収集される情報です。アップグレード前チェック ツールは、SharePoint 2010 へのアップグレードの準備ツールとして設計されましたが、別の目的で使用している組織もあります。実際、ある組織では、アップグレード前チェック ツールを障害時復旧計画の一環として使用しています。障害が発生したサーバーの復旧に役立つわけではありませんが、SharePoint の展開を再構築する必要が生じた場合に、ユーティリティで収集された情報が大いに役立ちます (ただし、障害が発生する前にツールを実行しておく必要があります)。
同様に、複数の SharePoint サーバーを一貫した方法で構成するために、このツールを使用している組織もあります。アップグレード前チェック ツールを、各 SharePoint サーバーで実行することにより、各サーバーのレポートを比較して、企業ポリシーに従っていない個々の構成要素を特定することができます。
アップグレード前チェック ツールはどこで手に入るのか疑問に思われているかもしれませんが、おそらく、皆さんは既にツールをお持ちだと思います。アップグレード前チェック ツールは MOSS 2007 SP2 に同梱されています。ご想像とは異なるかもしれませんが、アップグレード前チェック ツールはスタンドアロン ツールではなく、STSADM.EXE ユーティリティに組み込まれています。ちなみに、私が MOSS 2007 SP2 を適用した後は、新しい STSADM.EXE の機能にアクセスできるまでにテスト サーバーを 2 回再起動する必要がありました。
そういうわけで、アップグレード前チェック ツールがどのように機能するかご説明しようと思います。既に説明したとおり、アップグレード前チェック ツールでは、XML ベースのルール ファイルを解析して、そのルールを SharePoint の展開を分析する基礎として使用します。アップグレード前チェック ツールには、一連のルールが組み込まれています。これらのルールは、ベスト プラクティス アナライザーに基づいて作成されており、OssPreUpgradeCheck.xml というファイルにあります。図 1 をご覧になると、これがどんなファイルなのかおわかりになると思います。
図 1 アップグレード前チェック ツールで使用する XML ベースのルール ファイル
アップグレード前チェック ツールを実行する際には、このルール ファイルを明示的に呼び出す必要はなく、既定で自動的に呼び出されます。また、カスタムのルール ファイルを使用することもできます。アップグレード前チェック ツールの完全な構文は次のとおりです。
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]
上記の構文からわかるように、必要なパラメーターは –O と PreUpgradeCheck という単語のみです。–RuleFiles パラメーターは省略可能で、使用するルール ファイルを手動で指定する場合にのみ使用します。また、–ListRuleFiles パラメーターを使用すると、使用可能なルール ファイルを表示できます。–LocalOnly パラメーターを使用すると、ローカルの SharePoint サーバーのみに対してルールを実行できます。
図 2 を参照すると、アップグレード前チェック ツールがどのように機能するかをより詳細に理解できます。図をご覧いただくとわかるように、まず、コマンド プロンプト ウィンドウを開いて、ディレクトリ構造を移動し、C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN に移動しました。そこで、次のコマンドを実行しました。
STSADMIN.EXE –O PreUpgradeCheck]
.jpg)
図 2 SharePoint の展開をテストするアップグレード前チェック ツール
図 2 からわかるように、アップグレード前チェック ツールでは、SharePoint の展開に対して数多くの異なるテストが実行されます。各テスト結果には色が付けられていて、赤はサーバーがテストに失敗したことを、緑は合格したことを指します。情報を提供する項目は黄色で示されます。
どこからどう見ても、アップグレード前チェック ツールの出力は冗長ではありません。図 2 の画面キャプチャには、テストが合格したか失敗したかどうかだけが表示されていて、詳細な情報は表示されていません。ですが、画面キャプチャの下の方を見ると、C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs フォルダーにある HTML ファイルを参照すると結果を確認できるというメッセージが表示されているのがわかります。
アップグレード前チェック ツールを実行するたびに、3 つのログ ファイルが作成されます。アップグレード チェックの最後で言及されている HTML ファイルがその 1 つですが、他にも LOG ファイルと XML ファイルがあります。どのログ ファイルも使用できますが、最も読みやすいのは HTML ファイルです。
既に説明したように、アップグレード前チェック ツールでは、多くの情報が収集されます。したがって、結果のログは、すべての情報を網羅するために、すごく長いものになっても不思議ではありません。図 3 をご覧いただくと、HTML ログがどのようなものかだいたいおわかりになると思います。
.jpg)
図 3 Web ブラウザーで参照できるアップグレード前チェックの結果
行ったカスタマイズを特定する
お使いの SharePoint サーバーに行ったカスタマイズを特定することも、アップグレード計画のプロセスにおける重要な手順です。インプレース アップグレードと移行のどちらを行っている場合でも、カスタマイズを誤って上書きしてしまうことはよくあります。したがって、アップグレード後、必要に応じてカスタマイズを簡単に適用し直せるように、カスタマイズを文書化して、関連するファイルのみのバックアップを作成する必要があります。
SharePoint 環境が進化するたびに、あらゆるカスタマイズが十分に文書化されていれば良いのですが、現実的に、すべての変更を記録するのは、たいへんな作業です。したがって、すべてのカスタマイズをきちんと文書化していると思っていても、カスタマイズのログを確認してください。残念ながら、SharePoint にはカスタマイズを特定するツールが組み込まれていません。ですが、だからと言って、SharePoint サーバーのすべてのファイルを手動で確認する必要があるというわけではありません。
カスタマイズについての情報を取得するには、diffing (差分の取得) という手法を使用できます。この手法の背景にある考え方は、お使いの MOSS 2007 サーバーをセットアップし (運用サーバーと同じ修正プログラムが適用されていることを確認してください)、それから差分プログラムを使用して、運用サーバーのどのファイルが SharePoint サーバーの初期設定と異なっているか確認するというものです。
マイクロソフトでは WinDiff の使用を推奨していますが、他にも多数の差分ユーティリティがあり、その大半が WinDiff よりも多くの機能を備えています。
アップグレード プロセスをテストする
SharePoint 2010 への移行を準備していくと、最終的に、アップグレードを実行する方法を計画するという局面に辿り着きます。アップグレード前チェック ツールで検出された問題にすべて対処したなら、アップグレード プロセスは比較的スムーズに進められるでしょう。ですが、絶対に成り行きに任せてはいけません。
MOSS 2007 を独立したラボ環境に展開して、運用サーバーのアップグレードを試みる前にラボでアップグレード計画を実行してみてください。ラボを使用すると、アップグレード プロセスがよくわかるだけでなく、実際にアップグレードを行う場合に発生する可能性がある問題を特定できます。
中小企業 (SMB) で採用する最も適切なアプローチは、いくつかの仮想サーバーをセットアップして、それから実際に運用サーバーのバックアップをラボ サーバーに復元することです。これにより、運用サーバーとほぼ同じ環境でアップグレード計画を試すことができます。
より大きな組織では、SharePoint の運用展開を完全に複製するのはおそらく非現実的でしょう。このような状況では、運用展開と同じように構成された、小規模な環境をセットアップすることをお勧めします。また、全部ではなく、いくつかの SharePoint サーバーのバックアップをラボ環境に復元することもお勧めします。このアプローチでは、多くのものがなおざりにされているように見えます。ですが、皆さんは、おそらく一気に展開全体を SharePoint 2010 にアップグレードまたは移行するのではなく、一度に 1 つの領域への展開に対応するつもりであることを思い出してください。
バックアップを検証する
SharePoint 2010 にアップグレードする前の最後の手順は、バックアップが適切に機能しているかどうか検証することです。私は、今週、サーバーのバックアップを念入りに行っていたと信じていたのに、残念ながらバックアップが不十分だったことが判明した人物をサポートしたばかりです。こんなことが起こらないように、バックアップをテストして、復元できることを確認してください。
.jpg)
Brien Posey は、MVP であり、数千件の記事と数十冊の書籍を執筆した実績のあるフリーランスのテクニカル ライターです。彼の Web サイトのアドレスは brienposey.com (英語) です。