アップグレード方法を決定する (SharePoint Server 2010)

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

Microsoft Office SharePoint Server 2007 から Microsoft SharePoint Server 2010 へアップグレードするプロセスを実行する前に、アップグレード方法を決める必要があります。この記事の内容を参考にそれぞれの方法の利点と欠点を比較し、それぞれの方法に影響を与える可能性のある特殊なケースについての情報を確認してください。また、この記事に加えて、「サポートされるアップグレード パスとサポートされないアップグレード パスを確認する (SharePoint Server 2010)」にも必ず目を通し、アップグレードが適切に実施できる状況を正確に把握してください。

注意

アップグレードを実行するには、Office SharePoint Server 2007 Service Pack 2 (SP2) がインストールされている必要があります。

この記事の内容

  • アップグレード方法を選択する

  • 特殊なケース

アップグレード方法を選択する

基本となるアップグレード方法には、一括アップグレードとデータベース接続アップグレードの 2 つがあります。そのほか、さまざまなテクニックを使用して基本となるアップグレード方法の特長を組み合わせることで、ダウンタイムの短縮やパフォーマンスの改善を図ることができます。

次の表で、一括アップグレードとデータベース接続アップグレードを比較します。

方法 説明 利点 欠点

一括アップグレード

SharePoint Server 2010 は同じハードウェア上にインストールできます。単一のプロセスの一部として、サーバー ファームのコンテンツおよび設定をアップグレードすることもできます。

ファーム全体の設定が保持されてアップグレードされます。アップグレード後の環境でカスタマイズできますが、アップグレードや再稼働のために手動での手順が必要になる場合があります。

アップグレードの進行中は、サーバーおよびファームはオフラインになります。アップグレードは連続して進行します。したがって、すべてのコンテンツが順にアップグレードされるのに十分な時間を割り当てる必要があります。

データベース接続アップグレード

別のファームの環境のコンテンツをアップグレードできます。この場合、サービスやファームの設定はアップグレードしません。データベースを任意の順序でアップグレードでき、同時に複数のデータベースをアップグレードできます。各データベースをアップグレードしている間は、そのデータベース内のコンテンツをユーザーが利用することはできません。

同時に複数のコンテンツ データベースをアップグレードできるので、全体として一括アップグレードよりも短時間で処理できます。データベース接続アップグレードを使用して、複数のファームを 1 つのファームにまとめることができます。

サーバーおよびファームの設定はアップグレードされません。古いファームから新しいファームへ保持する設定は、手動で転送する必要があります。すべてのカスタマイズも手動で新しいファームへ転送する必要があります。転送されないカスタマイズがあると、意図しない機能の損失や、ユーザー エクスペリエンスの問題が発生する場合があります。ネットワーク経由でのデータベースのコピーには時間がかかり、多くの帯域幅が使用されます。十分に検討して計画する必要があります。データベース サーバーへの直接アクセスが必要です。

一括アップグレードとデータベース接続アップグレードの動作の詳細については、「アップグレード プロセスの概要 (SharePoint Server 2010)」を参照してください。

次の表は、ダウンタイムの短縮テクニックをまとめたものです。これにより、アップグレード中にユーザーが自分のコンテンツにアクセスできなくなる時間を減らし、アップグレード パフォーマンスの改善を図ることができます。

テクニック 説明 利点 欠点

並列アップグレード

同時に複数のデータベースに接続してアップグレードを行うことでアップグレード プロセス全体の速度を上げることができます。並列アップグレードの最大数はハードウェアに依存します。このテクニックは、一括アップグレードとデータベース接続アップグレードのどちらでも使用できます。

環境全体のアップグレード時間が短縮されます。

追加的な手順と監視が必要な手動のプロセスです。

ハイブリッド方法 1: 読み取り専用データベースによるデータベース接続アップグレード

アップグレード プロセス中も、コンテンツへの読み取りアクセスを続行できます。この方法では、他のファームでアップグレードが進行している間はデータベースを読み取り専用に設定します。ユーザーが感じるダウンタイムは短縮されます。

コンテンツのアップグレード中も、既存のファームで、アップグレードされていないサイトのホストを (読み取り専用モードで) 続行できます。その結果、ユーザーにとってのダウンタイムが最小限になります。

同時に複数のコンテンツ データベースをアップグレードできるので、全体として一括アップグレードよりも短時間で処理できます。

ソフトウェアに加えてハードウェアもアップグレードできます。

サーバーおよびファームの設定はアップグレードされません。古いファームから新しいファームへ保持する設定は、手動で転送する必要があります。

すべてのカスタマイズも手動で転送およびアップグレードを行う必要があります。転送されないカスタマイズがあると、意図しない機能の損失や、ユーザー エクスペリエンスの問題が発生する場合があります。

ネットワーク経由でのデータベースのコピーには時間がかかり、多くの帯域幅が使用されます。十分に検討して計画する必要があります。

データベース サーバーへの直接アクセスが必要です。

ハイブリッド方法 2: データベースを切断した一括アップグレード

一括アップグレードでコンテンツや設定をアップグレードできる点を利用しながら、データベース接続アップグレードでの速さも得られます。この方法では、一括アップグレードを使用して、ファームと設定をアップグレードし、並行して複数のデータベースの切断とアップグレードを (同じファームまたは別のファームで) 行います。

ファーム全体の設定を保持してアップグレードできます。

アップグレード後の環境でカスタマイズできますが、アップグレードや再稼働のために手動での手順が必要になる場合があります。

同時に複数のコンテンツ データベースをアップグレードできるので、全体として一括アップグレードよりも短時間で処理できます。

ネットワーク経由でのデータベースのコピーには時間がかかり、多くの帯域幅が使用されます。十分に検討して計画する必要があります。

データベース サーバーへの直接アクセスが必要です。

これらのテクニックを組み合わせることができることにも注意してください。たとえば、オリジナルのファームを読み取り専用モードに設定し、そのファームのコピーを作成してコンテンツ データベースなしでアップグレードを行い、並列アップグレードでユーザー コンテンツ全体を高速にアップグレードし、最後にアップグレードの完了した新しいファームへユーザーを切り替えることができます。これらのダウンタイム短縮テクニックの詳細については、「アップグレード プロセスの概要 (SharePoint Server 2010)」を参照してください。

サービス停止時間帯が過度に長くなる場合に検討すべきオプションとして、代替アクセス マッピング URL リダイレクトとデータベース接続を組み合わせる方法があります。新しいファームでコンテンツをアップグレードしている間、ユーザーを既存の別のファームにリダイレクトするという方法です。これは高度な方法なので、他のダウンタイム短縮テクニックで十分な効果が得られない場合にのみ使用してください。詳細については、「アップグレード プロセスの一部として AAM URL リダイレクトを使用する (SharePoint Server 2010) (ホワイト ペーパー)」を参照してください。

特殊なケース

アップグレードを実行するときに、別の要件や達成するべき他の目標がある場合があります。以下の表に、特殊なケースと、それぞれのケースに適切なアップグレード方法を示します。

ケース アップグレード方法

SQL Server を 32 ビット版から 64 ビット版にアップグレードする場合

32 ビット版の SQL Server を実行している場合は、64 ビット版に移行する必要があります。最大のパフォーマンスを得るには、SharePoint Server 2010 にアップグレードする前に移行することをお勧めします。アップグレードの失敗を避けるため、種類の異なるアップグレードや移行を同時に行わないようにしてください。詳細については、「既存のサーバー ファームを 64 ビット環境に移行する (Office SharePoint Server 2007)」を参照してください。

SQL Server の 32 ビット版から 64 ビット版へのアップグレードには、次の 2 つのオプションがあります。

  • ファームのデータベース セット全体をバックアップしてから、アップグレードを実行し、それからデータベースを復元できます (このオプションはサポート対象であり、完全バックアップが得られること、およびデータベースの復元後に SharePoint Server 2010 内で何も変更を加える必要がないという理由で、このオプションを選択することをお勧めします)。

  • アップグレードする SQL Server データベースを別の 64 ビット版の SQL Server に移動できます。別の 64 ビット版を追加して、新しい 64 ビット版の SQL Server を指定するように SharePoint Server 2010 のコンピューターにコマンドを実行する必要があります (この方法はサポート対象ですが、データベースの場所を変更する場合などに SharePoint Server 2010 で必要な作業が増えるという理由で、お勧めできません)。

注意

SQL Server 2005 SP2 を SQL Server 2008 にアップグレードする場合など、SQL Server のバージョンをアップグレードする場合は、SQL Server のエディションを 32 ビットから 64 ビットにアップグレードする前、アップグレード中、またはアップグレード後に、バージョンのアップグレードを実行できます。

32 ビット オペレーティング システムから 64 ビット オペレーティング システムにアップグレードする場合

32 ビット オペレーティング システムを使用している場合は、アップグレードの前に 64 ビット オペレーティング システムに移行する必要があります。詳細については、「既存のサーバー ファームを 64 ビット環境に移行する (Office SharePoint Server 2007)」を参照してください。

フォームベースの認証を使用している環境をアップグレードする場合

フォームベースの認証を使用しているときは、アップグレードのための追加的な手順が必要です。詳細については、「クレーム ベースの Web アプリケーション用にフォームベースの認証を構成する (SharePoint Server 2010)」を参照してください。

非常に大規模なデータベースをアップグレードする場合

一般的に、非常に大規模なデータベースは、特に多数のドキュメント バージョンやサイズの大きなドキュメント バージョンが含まれている場合、小規模なデータベースよりもアップグレードに時間がかかります。しかし、データが複雑であることはアップグレードにかかる時間には関係しても、データベース自体のサイズとは無関係です。アップグレード プロセスがタイムアウトした場合、通常は、接続に問題があります。Office SharePoint Server 2007 では、プロセスの実行に必要な時間のせいでアップグレード プロセスがよくタイムアウトしましたが、SharePoint Server 2010 では、それが起こることはほとんどありません。実際の環境でのアップグレードにかかる時間の詳細については、「アップグレード プロセスに要する時間と必要な容量を予測する (SharePoint Server 2010)」を参照してください。

SharePoint Portal Server 2003 からアップグレードする場合

データベース接続アップグレードによる方法で、まず Microsoft Office SharePoint Server 2007 にアップグレードし、次に SharePoint Server 2010 にアップグレードします。このアップグレード プロセスの詳細については、「SharePoint Portal Server 2003 から SharePoint Server 2010 へアップグレードする」を参照してください。

Windows SharePoint Services 3.0 からアップグレードする場合

データベース接続アップグレードによる方法で、Windows SharePoint Services 3.0 から SharePoint Server 2010 にコンテンツ データベースをアップグレードします。このプロセスでは、コンテンツ データベースのデータはアップグレードされますが、ファームの設定は転送されません。

国際化ドメイン名を使用する場合

Office SharePoint Server 2007 では国際化ドメイン名 (IDN) がサポートされていましたが、SharePoint Server 2010 ではサポートされません。現在、Office SharePoint Server 2007 で IDN を使用していて、SharePoint Server 2010 にアップグレードまたは移行する場合は、その前に、IDN の使用を停止し、IDN の設定を削除して、非 IDN 環境をセットアップする必要があります。詳細については、「多言語サイトを計画する (SharePoint Server 2010)」を参照してください。