アップグレードのベスト プラクティスを検討する

  • [アーティクル]

アップグレード プロセスを円滑に行うには、以下のベスト プラクティスに従います。

  1. アップグレードの実行前にファームが完全に機能していることを確認します。

    アップグレードしてもファームに存在する問題は解決されません。したがって、アップグレードの実行前にファームが完全に機能していることを確認する必要があります。たとえば、使用しなくなった Web アプリケーションや仮想サーバーがある場合は、アップグレード前にそれらの拡張を元に戻します。また、インターネット インフォメーション サービス (ISS) で Web アプリケーションを削除する場合は、アップグレード前に Web アプリケーションの拡張を元に戻します。元に戻さなかった場合、Web アプリケーションが存在しないのに Web アプリケーションのアップグレードが Office SharePoint Server 2007 によって試みられ、アップグレードに失敗します。事前に問題を特定して解決しておくと、アップグレードの開始後にアップグレード スケジュールを維持するのに役立ちます。

  2. 最初にテスト ファームで試用版のアップグレードを実行します。

    稼働中のファームをバックアップし、テスト サーバーに復元してから、アップグレードを実行します。その結果を調べて、稼働中のアップグレードされたサイトの状態を予想し、アップグレード後にどの程度のカスタマイズを行う必要があるか決定し、アップグレードに要する時間を予測します。全文検索インデックスのクロールを試みます。テスト アップグレードの実行と一般的な問題のリストの詳細については、「試用版のアップグレードを使用して潜在的な問題を発見する (Office SharePoint Server)」を参照してください。

  3. 容量を計画します。

    段階的なアップグレードの要件を満たすのに十分なディスク、プロセッサ、およびメモリの容量があることを確認します。システム要件の詳細については、「アップグレードのシステム要件を確認する (Office SharePoint Server)」を参照してください。アップグレードに必要なディスク容量の計画の詳細については、「アップグレード プロセスに要する時間と必要な容量を予測する (Office SharePoint Server)」を参照してください。

    サーバー ファームの最適なパフォーマンスおよび操作をサポートする目的で、SQL Server の記憶域要件を計画および監視する場合に役立つ主な推奨事項とベスト プラクティスについては、「SharePoint 用 SQL Server 記憶域の計画と監視 : パフォーマンスの推奨事項とベスト プラクティス (ホワイト ペーパー)」を参照してください。容量の計画の詳細については、「パフォーマンスと容量を計画する (Office SharePoint Server)」を参照してください。

  4. サイト コレクションを負荷分散します。

    サイト コレクションを、大きなデータベースから複数の小さなデータベースに負荷分散して、バックアップしやすくします。サイト コレクションのバックアップは、stsadm -o backup 操作を使用して実行します。バックアップ後、新しいコンテンツ データベースを作成して、コンテンツを新しいデータベースに復元します。

    stsadm -o backup 操作の詳細については、「Backup : Stsadm 操作 (Office SharePoint Server)」を参照してください。

    データベースの移動の詳細については、「Mergecontentdbs : Stsadm 操作 (Office SharePoint Server)」を参照してください。

    注意

    領域はバックアップできません。

  5. データをバックアップします。

    アップグレード前に完全バックアップを実行し、アップグレードされた各サイト コレクションの稼働後にもう一度バックアップを実行します。各サイト コレクションのアップグレード後に追加のバックアップを行うには、以下の 2 つの理由があります。

    • サーバーで問題が発生した場合に、古いバージョンで最初から作業を始めて、アップグレードを再実行する必要がありません。

    • 段階的なアップグレードのある時点で、アップグレードされるサイト、古いサイト、およびバックアップそのものによって消費される容量を減らし、古いバージョンを削除する必要が生じます。ただし、古いサイトを削除した後に何らかの理由でそれらが必要となる場合に備えて、アップグレードされたサイトのバックアップを保持しておきます。

    環境が異なる場合は、以下のバックアップ方法を使用することをお勧めします。

  6. アップグレード中またはアップグレード後に、以前のバージョンのサイトまたは構成データを変更しないでください。

    アップグレードの実行中は、アップグレードするサイトをロックすることをお勧めします。アップグレード プロセスそのものでは、サイト コンテンツおよび Microsoft Windows SharePoint Services 2.0 からの構成データをロックできますが、SharePoint Portal Server 2003 に固有の構成データはロックできません。アップグレード中またはアップグレード後には、以前のバージョンのサイトに対して構成の変更 (サイト ディレクトリへのサイトの追加など) を加えないでください。そのような変更内容は新しいバージョンと同期できません。それらの変更内容が失われるか、前のバージョンに戻してアップグレードを再実行する必要が生じることが考えられます。サイトをロックするには、以下の 2 つの方法を使用できます。

    • SharePoint サーバーの全体管理で、[サイト コレクションのクォータとロックの管理] ページの [コンテンツの追加不可] のロックを使用して、サイト コレクションをロックすることができます。クォータを使用したサイトのロックの詳細については、「Configuring Site Collection Quotas and Locks (Windows SharePoint Services 2.0) (英語)」(https://go.microsoft.com/fwlink/?linkid=89388&clcid=0x411) を参照してください。

    • Microsoft SQL Server でコンテンツ データベースを読み取り専用に設定することができます。データベースの読み取り専用への設定の詳細については、SQL Server 2000 の SQL Server Books Online で「データベース オプションの設定」を参照してください。

  7. アップグレード プロセスを開始した後は、サーバー ファームにサーバーを追加しないでください。

    SharePoint 製品とテクノロジ構成ウィザードを実行すると、構成データベースがアップグレードされます。構成データベースにはファーム内のサーバーの一覧が含まれます。構成ウィザードの実行後にファームに追加されたサーバーは、データベースに含まれません。したがって、ウィザードの実行後に追加されたサーバーは、アップグレードされたバージョンのトポロジには表示されません。ファームにサーバーを追加する必要がある場合は、「アップグレードされたファームにサーバーを追加する (Office SharePoint Server)」の手順に従って、アップグレードを開始する前、あるいはアップグレード プロセスを完了した後に追加してください。

  8. 共有サービスがある場合は、まず親ポータル サイトをアップグレードします。

    ただし、最初に親ポータル サイトをアップグレードできない場合は、一時的な共有サービス プロバイダ (SSP) を作成して新しいバージョンのサービスをホストし、最初に子ポータル サイトをアップグレードすることができます。この方法を行う場合は、以下の点を考慮してください。

    • アップグレード後に、一時的な親共有サービス プロバイダ (SSP) を作成し、データ (検索、プロファイルなど) を設定する必要があります。一時的な SSP をアップグレードされた 1 つ以上の子ポータル サイトに関連付けて、新しい機能をテストします。

    • まず、小規模な部署の子ポータル サイトでの試用版の展開を検討します。次に、完全な移行を開始する準備ができたら、まず親ポータル サイトをアップグレードし、アップグレードされた親の SSP でアップグレードされた子ポータル サイトをポイントします。子ポータル サイトのコンテンツは、子ポータル サイトをアップグレードした直後に使用可能になりますが、親ポータル サイトに関連付けられている共有サービスのコンテンツは、親ポータル サイトがアップグレードされるまで使用可能になりません。

    共有サービスを使用したアップグレードの詳細については、「共有サービスを使用して段階的なアップグレードを実行する」を参照してください。

  9. 個人用サイトの含まれるポータル サイトを移行する場合、個人用サイトのホストの場所用の Web アプリケーションを作成します。

    データベースの移行を実行する場合は、データベースに対して一括アップグレードを実行しますが、サーバー ファーム構成データはアップグレードしません。したがって、個人用サイトのホストの URL は、アップグレードされたサーバー ファームでは構成されません。 個人用サイトが含まれるデータベースを移行する前に、新しい Office SharePoint Server 2007 環境で個人用サイト向けにホストの場所を 1 つ作成します。個人用サイトのホストの場所を作成するには、以下の手順を実行します。

    個人用サイト向けにホストの場所を 1 つ作成する

    1. 共有サービス管理ホーム ページの [ユーザー プロファイルと個人用サイト] セクションで、[個人用サイトの設定] をクリックします。

    2. [個人用サイト サービス] セクションで、アップグレードされたサーバー ファームの個人用サイトのホストの場所として使用する Web アプリケーションの URL を入力します。

    3. 個人用サイトが含まれるコンテンツ データベースを、作成した個人用サイトのホストの場所に移行します。

    注意

    ユーザー プロファイル データベースも移行する場合は、ユーザー プロファイル データベースの移行中に個人用サイトの SSP を作成します。

    個人用サイトの設定を構成し、個人用サイト向けにホストの場所を 1 つ作成する方法の詳細については、「個人用サイト ホストの場所を管理する」を参照してください。

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

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

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