Share via


アップグレード プロセスのしくみ (Windows SharePoint Services)

この記事の内容 :

  • 一括アップグレード

  • 段階的なアップグレード

  • 段階的なアップグレード中の URL リダイレクトの処理方法

アップグレードは、一括アップグレード、段階的なアップグレード、データベース移行の 3 つの方法から選択できます。一括アップグレードは、すべての Microsoft® SharePoint® サイトを一度にアップグレードする場合に使用する方法で、単一サーバーまたは小規模な展開に最も適しています。段階的なアップグレードを使用すると、1 つ以上のサイト コレクションを一度にアップグレードできるようにして、アップグレード プロセスを詳細に制御することができます。一括アップグレードおよび段階的なアップグレードは、以前のバージョンがインストールされているハードウェア上で行われます。データベース移行を使用すると、コンテンツを新しいファームまたは新しいハードウェアに移動することができます。

ヒント

大規模な展開では、アップグレードを実行する管理者が一度にアップグレードするサイト コレクション数を制御できるので、一括アップグレードよりも段階的なアップグレードの方が適しています。この方法を使用すると、以前のバージョンのサイトをホストしながら、大規模な展開を何回かの週末に分けて段階的にアップグレードできます。これが可能なのは、アップグレードされるサイトと同じサーバーにある、まだアップグレードされていないサイトのホストを続行できるからです。

一括アップグレードでは、以下の処理が行われます。

  • 以前のバージョンが新しいバージョンで上書きされ、コンテンツ データベースが変更されます。このため、一括アップグレードは元に戻すことができる処理ではありません。つまり、以前のバージョンにロール バックすることはできません。

  • 元のサイトがそのままアップグレードされ、アップグレード後に以前のバージョンのサイトを表示することはできません。

  • アップグレード中、サイトの訪問者はすべてのサイトを使用できません。サイトを利用できない期間は、サーバーまたはサーバー ファーム全体をアップグレードするまでの全時間です。

  • サイトの閲覧者は、アップグレード後も同じ URL を引き続き使用します。

段階的なアップグレードでは、以下の処理が行われます。

  • サイト コレクションの各グループがアップグレードされる際、それらに含まれるデータは、データがアップグレードされる前に元のデータベースから新しいデータベースにコピーされます。元のデータは、サーバー管理者によって明示的に削除されるまで、元のデータベース内に保持されます。このため、アップグレードされたサイトは、必要に応じて以前のバージョンに簡単にロール バックすることができます。

  • アップグレード中もサイトの閲覧者はほとんどのサイトを利用でき、現在アップグレード中のサイト コレクションのみがオフラインになります (以前のバージョンのサイトは、アップグレードの準備のためにコピーされるまでは、更新としてマークされることはありません)。

  • アップグレードの影響は、アップグレード中の単一または複数のサイトを利用しようとするユーザーのみに限られます。

  • アップグレード後は、元の URL はサイトのアップグレード後のバージョンを参照します。このため、ユーザーはアップグレード前に使用していた URL を引き続き使用できます。

データベース移行は、本質的にはコンテンツのコピーに対して実行される一括アップグレードです。データベース移行では、以下の処理が行われます。

  • 構成データベースを除くすべてのデータベースをコピーしてから、新しいスタンドアロン インストールまたはサーバー ファーム インストールにデータベースを追加します。

  • 新しいサーバー ファームにデータベースを加えると、アップグレード プロセスが実行され、データがそのままアップグレードされます。

    重要

    アップグレードが予想以上に長引いたり、アップグレード後に一部のサイトで作業のやり直しが発生するなど、ダウンタイムやリスクを考慮して、サーバー管理者はプロセス中に発生する可能性のある問題について、サイトの所有者およびユーザーに伝えることが重要です。詳細については、「情報伝達計画を作成する (Windows SharePoint Services)」を参照してください。

一括アップグレード

一括アップグレードは、以前のバージョンがインストールされている同じハードウェア上で行われます。一括アップグレードを実行すると、あらかじめ設定された順序でインストール全体がアップグレードされます。以下の手順は、一括アップグレード プロセスの実行時に行われる処理を示しています。

  1. アップグレード前のすべての手順を実行した後、サーバー管理者は以前のバージョンの Windows SharePoint Services が稼働しているサーバーに Windows SharePoint Services 3.0 をインストールし、[一括アップグレード] を選択します。

  2. アップグレード プロセスが実行され、構成データベースおよびサーバーの全体管理サイトがアップグレードされます。

  3. 各仮想サーバーでアップグレード プロセスが実行され、それぞれの仮想サーバー内の各サイト コレクションがアップグレードされます。

  4. すべてのサイトがアップグレードされると、アップグレード プロセスは終了します。

  5. サーバー ファーム環境の各サーバーに対してアップグレード操作を繰り返します。

  6. 管理者はアップグレードが完了したことを確認してから、以前のバージョンの Windows SharePoint Services をアンインストールします。

段階的なアップグレード

一括アップグレードと同様に、段階的なアップグレードも以前のバージョンのインストールに使用されたハードウェア上で行われます。ただし、段階的なアップグレードでは、サイト コレクションごとに実行するアップグレードのタイミングを制御することができます。また、以前のバージョンと新しいバージョンを同じハードウェア上で並行して引き続き使用できます。段階的なアップグレードを実行すると、開始トポロジと終了トポロジは同じ構成になります。これは、一括アップグレードの場合と似ていますが、次のような違いがあります。

  • アップグレード中およびアップグレード後、フロントエンド Web サーバーは Windows SharePoint Services 2.0 と Windows SharePoint Services 3.0 の両方を実行します。アップグレードしたサイト コレクションは Windows SharePoint Services 3.0 で実行されますが、アップグレードできなかったサイト コレクションやアップグレード対象として選択されなかったサイト コレクションは Windows SharePoint Services 2.0 で実行されます。

    注意

    サイトのアップグレードを保留すべき状況としては、必要な言語パックが Windows SharePoint Services 3.0 で利用可能になるまで一部のサイトを以前のバージョンで維持する必要がある場合や、新しいカスタム サイト定義が作成されるまで待つ必要がある場合が考えられます。

  • アップグレード中およびアップグレード後は、Windows SharePoint Services 2.0 と Windows SharePoint Services 3.0 の両方のデータベースを使用できます。アップグレードされたサイトのコンテンツは Windows SharePoint Services 3.0 データベースに格納され、アップグレードできなかったサイトまたはそのまま維持する必要があるサイトのコンテンツは Windows SharePoint Services 2.0 データベースに引き続き格納されます。構成データベースは Windows SharePoint Services 3.0 と Windows SharePoint Services 2.0 の両方に対して存在します。

以下の図は、段階的なアップグレード プロセスを示しています。

アップグレード時の移行中のトポロジ

以下の手順は、前の図中の番号に対応しており、段階的なアップグレード プロセスの実行時に行われる処理を示しています。

  1. アップグレード前のすべての手順を実行した後、サーバー管理者はファーム内の最初のフロントエンド Web サーバーに Windows SharePoint Services 3.0 をインストールし、[段階的なアップグレード] を選択します。

    注意

    アップグレードを実行する前に、環境をバックアップすることをお勧めします。詳細については、「SQL Server で完全バックアップを実行およびテストする (Windows SharePoint Services)」を参照してください。

  2. アップグレード プロセスによって、SharePoint のサーバーの全体管理をホストする Windows SharePoint Services 3.0 Web アプリケーションが作成され、サーバーの全体管理サイトが作成されます。

  3. アップグレード プロセスによって、Windows SharePoint Services 3.0 の構成データを格納する新しい構成データベースが作成されます。Windows SharePoint Services 2.0 構成データベースの構成データが新しいデータベースにコピーされます。

  4. 管理者がアップグレードする仮想サーバーを選択し、対象となる Web アプリケーションを指定します。アップグレード プロセスによって、対象の Web アプリケーションが作成され、Windows SharePoint Services 2.0 仮想サーバーに展開されていた Web パーツが新しい Web アプリケーションに追加されます。

  5. アップグレード プロセスにより、以前のバージョンに存在するコンテンツ データベースごとに一時コンテンツ データベースが作成されます。アップグレード プロセスによって、Windows SharePoint Services 2.0 のサイト リストが新しい環境にコピーされます。管理者はアップグレードするサイト コレクションを選択します。アップグレード プロセスにより、それらのサイトのデータが一時コンテンツ データベースにコピーされ、その一時コンテンツ データベース内のそれらのサイトがアップグレードされます。各サイトは、一時コンテンツ データベースにコピーされている間、一時的に利用できなくなります。

  6. コンテンツがアップグレードされると、アップグレード プロセスによって Windows SharePoint Services 3.0 コンテンツ データベースにデータが移動され、一時コンテンツ データベースは削除されます。

  7. アップグレード プロセスの終了時には、Windows SharePoint Services 2.0 と Windows SharePoint Services 3.0 の両方が稼働していて利用可能な状態になります。すべてのサイトがアップグレードされたら、管理者はアップグレードが完了したことを確認します。Windows SharePoint Services 2.0 が不要な場合、管理者は Windows SharePoint Services 2.0 をアンインストールします。

段階的なアップグレード中の URL リダイレクトの処理方法

2 つのサイトで同じ URL を共有することはできません。したがって、段階的なアップグレード中、各サイトの古いバージョンと新しいバージョンが同時に存在するときは、サイトごとに別々のドメイン URL (http://company_name/sites/SiteA と http://company_name_old/sites/SiteA など) が必要になります。アップグレード中は、以前のバージョンの元のサイトをホストする一時ドメイン URL が必要です。新しいバージョンはアップグレード前のコンテンツを指すドメイン URL を継承し、ユーザーの要求はアップグレードされているのかどうかにかかわらず、コンテンツに送られます。このリダイレクトを可能にするために、アップグレード中には以下の処理が実行されます。

  1. アップグレードを開始する前に、以前のバージョンのサイト用に一時 URL ドメインを作成します。

  2. アップグレードを実行すると、アップグレード プロセスによって上記のドメインを指定するように要求されます。アップグレード プロセスによって以前のバージョンのサイトは一時 URL ドメインに移動され、新しいバージョンのサイトは元の URL ドメインを引き継ぎます。

  3. サイトがアップグレードされるまで、元の URL に対する要求が古いサイトに送信されるように、リダイレクトはサイト コレクションごとに自動的に作成されます。

  4. 各サイトがアップグレードされると、そのサイトに対するリダイレクトは削除されます。

  5. すべてのサイトがアップグレードされた後、古いサイトをすべて削除し、アップグレード プロセスを完了すると、ドメイン ネーム システム (DNS) から一時 URL ドメインを手動で削除できます。

この処理の間、元の URL への参照アクセスは常に行えます。ただし、特定のクライアント アプリケーション (Microsoft Office クライアント アプリケーションなど) では、このようなリダイレクトは使用できません。元の URL は、サイトのアップグレード前は以前のバージョンを参照し、サイトのアップグレード後は新しいバージョンを参照します。

以下の表は、段階的なアップグレード中に URL がどのようになるのかを示しています。

段階 元のサイトの URL アップグレード後のサイトの URL メモ

アップグレード前

http://*company_name*

/sites/SiteA

なし

サーバー管理者が、段階的なアップグレード中に使用する http://*company_name*_old を作成します。

アップグレード中

http://*company_name*_old

/sites/SiteA

http://*company_name*

/sites/SiteA

サイトがアップグレードされるまで、http://*company_name*/sites/SiteA に対する要求は http://*company_name*_old/sites/SiteA にリダイレクトされます。

アップグレード後

http://*company_name*_old

/sites/SiteA (削除されるまで)

http://*company_name*

/sites/SiteA

アップグレードが完了して結果が検証されると、リダイレクトは削除されます。

この URL のリダイレクトによって、サイトまたはドキュメント内のハードコードされたリンクが切断される場合があります。たとえば、Microsoft Office InfoPath® フォームには、データの場所 (特定の SharePoint リスト、Web サービス、XML ファイルなど) へのハードコードされたリンクが含まれる場合があります。リンクはハードコードされているため、段階的なアップグレード中にアップグレード前のサイトに使用する一時 URL を参照するような自動更新はできません。実際にアップグレード プロセスを開始する前に、試用版アップグレードを試用して、そのような問題を特定してください。こうすることにより、すばやくアップグレードして元の URL を使用できるようにする必要があるサイトを特定し、ハードコードされたリンクが含まれているフォームやその他のアイテム内の機能が失われたという問い合わせを防ぐことができます。

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

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

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