次の方法で共有

アップグレードのトラブルシューティングを実行して再開する (Office SharePoint Server)

  • [アーティクル]

この記事の内容 :

  • アップグレードのトラブルシューティングと再開の概要

  • アップグレード前のスキャンの既知の問題

  • 一括アップグレードの既知の問題

  • 段階的なアップグレードの既知の問題

  • データベースの移行の既知の問題

  • カスタマイズしたサイトの既知の問題

アップグレードのトラブルシューティングと再開の概要

アップグレードが停止する場合は、以下の方法で問題を解決できます。

  • アップグレード ログ ファイル内の「エラー」を探します。アップグレード ログ ファイルの場所は、%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS です。アップグレード ログの表示の詳細については、「アップグレードを確認する (Office SharePoint Server)」を参照してください。

    ヒント

    これらのログ ファイルで「エラー」の反復を迅速に見つけるには、Windows のファイルおよびフォルダの検索機能を使用します。

  • イベント ビューアでイベントを確認し、アプリケーション エラーを探します。

  • readme で既知の問題と解決策を確認します。多くの場合、エラーは回避できる問題です。

  • 段階的なアップグレードを実行している場合は、実行しているサイト コレクションが新しいバージョンで表示されているかどうかを確認します。表示されていれば、そこで回避策を実行するか、新しいバージョンのサイトを古いバージョンに戻した後で、再度アップグレードします。サイトを以前のバージョンに戻す方法については、「以前のバージョンのサイトに戻す (Office SharePoint Server)」を参照してください。

  • コマンド "stsadm -o upgrade" を使用すると、一括アップグレードを再開できます。アップグレードでは、既に完了しているタスクは省略され、完了していないタスクから続行されます。アップグレード操作の詳細については、「サイトをアップグレードする (Office SharePoint Server)」を参照してください。

アップグレード前のスキャンの既知の問題

Localhost というサーバー名を使用したためアップグレードが阻止される

サーバー名に "localhost" を使用した場合、環境内で多数の問題が発生する可能性があるため、推奨されません。サーバー名として "localhost" を使用すると、アップグレード前のスキャン ツールを実行したときにこの問題が記録され、アップグレードを続行できなくなります。サーバー コンピュータの名前を変更して、アップグレード前のスキャンを実行すると、アップグレードを続行できるようになります。サーバー名を変更し、アップグレード前のスキャン ツールの問題を解決するには、次に示す手順に従ってください。

  1. 構成データベースをバックアップします。

  2. コマンドラインで、%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin に移動し、次のコマンドを実行して、構成データベース内のサーバー名を変更します。

    Stsadm.exe -o setconfigdb -databaseserver < サーバー名 > -connect

  3. コマンド ラインで、%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin に移動し、次のコマンドを実行して、アップグレード前のスキャン ツールの問題をクリアします。

    Prescan /fixlocalhost

  4. コマンド ラインで次のコマンドを実行し、アップグレード前のスキャン処理を再実行します。

    Prescan /all

    • 問題がなければ、アップグレードを続行します。

    • まだ問題が発生する場合は、サーバー名に localhost を使用しているサービスが依然として存在しています。現時点でアップグレードは阻止されませんが、一部のサービスが正常にアップグレードされない可能性があります。

一括アップグレードの既知の問題

サーバー ファームのアップグレードにはネットワーク サービスではなくドメイン アカウントを使用する必要がある

サーバー ファーム環境では、一括アップグレードでも段階的なアップグレードでも、前のバージョンの環境で使用した資格情報を新しいバージョンの環境でも使用する必要があります。ただし、前のバージョンの環境でネットワーク サービス アカウントを使用していた場合、新しいバージョンの環境ではドメイン アカウントを使用する必要があります。前のバージョンの環境では引き続きネットワーク サービスを使用できますが、新しいバージョンをインストールして新しいファームを作成するときには、代わりにドメイン アカウントを指定する必要があります。使用するドメイン アカウントには、SQL Server のデータベースに対する適切な権限を付与してください (前のバージョンの全データベースに対して、Database Creators グループ、Process Administrators グループ、および Database Owners グループに属している必要があります)。

一括アップグレードを実行した場合、一部の設定が Web アプリケーション上に維持されない

Secure Sockets Layer (SSL) を使用していて一括アップグレードを実行する場合は、一部の設定が Web アプリケーション上で維持されないため、代替アクセス マッピング (AAM) 機能を使用して Microsoft Office SharePoint Server 内の URL を変更する必要があります。

アップグレードする前に、HTTPS を使った次のような AAM エントリがあるかどうかを確認します。

受信 URL : https://<サーバー名>

送信 URL : https://<サーバー名>

これらのエントリは、Office SharePoint Server 2007 の一括アップグレードを実行した後、正しく設定されません。以下のように不適切に設定されます。

受信 URL : https://<サーバー名>

送信 URL : http://<サーバー名>

このような URL を修正するには、SharePoint サーバーの全体管理 Web サイトの [サーバー構成の管理] ページで [代替アクセス マッピング] をクリックし、[パブリック URL の編集] をクリックして、URL を元に戻します。

受信 URL : https://<サーバー名>

送信 URL : https://<サーバー名>

代替アクセス マッピングの詳細については、「代替アクセス マッピングを計画する (Office SharePoint Server)」を参照してください。

1 台目のフロントエンド Web サーバーのアップグレードの終了時にエラーが出力された

複数台のフロントエンド Web サーバーを使用するファーム内で、1 台目のフロントエンド Web サーバーのアップグレードの終了時にエラーが出力された場合、まずそのエラーを解決することをお勧めします。エラーを解決してからアップグレード作業に戻り、2 台目以降のフロントエンド Web サーバーのアップグレードを続行してください。

何らかの理由でエラーを無視する場合は、Psconfig コマンド ライン ツールを使用して、2 台目のフロントエンド Web サーバーのアップグレードを続行できます (たとえば、ほとんど使用されないサイト コレクションに関するエラーなどは無視してもかまいません)。コマンド ラインから次の操作を実行します。

Psconfig -cmd upgrade -inplace b2b -wait -force

注意

Psconfig コマンド ライン ツールを使用する場合、SharePoint 製品とテクノロジ構成ウィザードを使用して追加のフロントエンド Web サーバーをアップグレードすることはできません。

アップグレード ログに SPConfigurationDatabase2 シーケンス エラーが記録される

一括アップグレードの実行に失敗した場合は、アップグレード ログを確認します。このログ ファイルは、COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS フォルダに保存されます。"[SPConfigurationDatabaseSequence2] [ERROR] [date]: ロール 'WSS_Content_Application_Pools' は現在のデータベースに既に存在します。" というメッセージが出力された場合、次のいずれかの解決策を使用して問題を解決できます。

  • 構成データベースで次の SQL クエリを実行します。

    delete from dependencies

    delete from objects

    delete from classes

    delete from sitemap

    exec sp_droprole N'WSS_Content_Application_Pools'

    注意

    アクションに失敗した場合に droprole にメンバが含まれていたときには、sp_droprole 呼び出しによって、それらのメンバの名前が返されます。返されたメンバに対して、次のコマンドを実行する必要があります。

    exec sp_droprolemember N'WSS_Content_Application_Pools',

    N'usernameReturnedFromSP_DropRole'

    その後、以下のクエリを再度実行する必要があります。

    exec sp_droprole N'WSS_Content_Application_Pools'

  • 新しい V3 ファームを作成し、既存のコンテンツ データベースを接続します。このオプションでは、すべてのユーザー データが維持されますが、Web パーツ パッケージ、仮想サーバー設定などの V2 構成データベースに保存されていた構成情報は失われます。

  • 元のエラーが解決された場合 (たとえば、ネットワーク接続の切断または SQL Server コンピュータのディスク容量不足によりエラーが生じていたが、それらの問題が解決された場合)、V2 ファームを復元し、アップグレードを再開することができます。

注意

解決策の実行後は、忘れずにアップグレードを再開してください。

Office SharePoint Server 2007 用 Microsoft Office SharePoint Portal Server 2003 Web サイトからサイト定義を使用することはできません。

SharePoint Portal Server 2003 と Office SharePoint Server 2007 の両方に対して同じカスタム サイト定義テンプレートを使用した場合、Web サイトにアクセスすると、ページ エラーが発生します。SharePoint Portal Server 2003 用に作成したカスタム サイト定義テンプレートを使用することはできません。Office SharePoint Server 2007 用に新しいカスタム サイト定義テンプレートを作成する必要があります。 サイト内の各要素 (カスタム ページなど) を適切な新しい要素にアップグレードすることができるように、古いカスタム サイト定義から新しいカスタム サイト定義にカスタム要素をマップするサイト定義アップグレード ファイルも作成する必要があります。Office SharePoint Server 2007 用の新しいサイト定義の作成の詳細については、「新しいカスタム サイト定義を開発し、アップグレード定義ファイルを作成する (Office SharePoint Server)」および「アップグレード定義ファイルおよび新しいサイト定義を展開する (Office SharePoint Server)」を参照してください。カスタム サイト定義の操作に対するサポート対象およびサポート対象外のシナリオについては、マイクロソフト サポート技術情報の記事 898631「カスタム サイト定義と Windows SharePoint Services で、SharePoint Portal Server 2003、および Office SharePoint Server 2007 でのカスタム領域定義を操作するためのサポートされているとサポート対象外のシナリオ」(https://go.microsoft.com/fwlink/?linkid=140380&clcid=0x411) を参照してください。

既存のコンテンツ データベースを新しいファームに接続したときの、リンク切れしたヘルプ ファイルへのリンク

新しいファームを作成して、既存のコンテンツ データベースを接続したとき、元の Web パーツの一覧には、製品の以前のバージョンのヘルプ ファイルへの URL が含まれています。製品の以前のバージョンのヘルプ ファイルはサーバー上で利用できません。その結果、[Microsoft SharePoint 製品とテクノロジのヘルプ リソース] リンク (次の URL を指します) では、ページが見つからない (HTTP エラー 404) ことを示すエラー メッセージが表示されます。
http://< server:port_number>/_vti_bin/help/1033/sps/html/HelpResources.htm
この問題を解決するには、そのリンクを削除します。

IIS で Default Web Site を使用する場合にフロントエンド以外の Web サーバーが含まれる中規模/大規模ファームで一括アップグレードが失敗する

中規模/大規模サーバー ファームにフロントエンド Web サーバー以外のサーバーが 1 台以上含まれている場合、インターネット インフォメーション サービス (IIS) で Default Web Site を使用して SharePoint サイトをホスティングしていると、Default Web Site をアップグレードできないというメッセージが表示されてアップグレードが中止されることがあります。この問題を回避するには、アップグレードを実行する前に、フロントエンド以外のすべての Web サーバー (インデックス サーバーなど) で IIS の Default Web Site の名前を別の名前に変更して、アップグレードを実行した後、名前を Default Web Site に戻します。サーバー ファーム内のフロントエンド Web サーバーについては、Default Web Site の名前を変更する必要はありません。

アップグレードを実行する前に IIS の Default Web Site の名前を変更しなければ、アップグレードが失敗します。この問題が発生した場合は、フロントエンド以外のすべての Web サーバーで Default Web Site の名前を別の名前に変更し、その後でアップグレードを再開します。アップグレードの再開には、次のコマンドライン コマンドを使用できます。

psconfig -cmd upgrade -inplace previous versionv -wait -force

環境内に URL が同じポータル サイトが複数存在すると、一括アップグレードに失敗する

環境内の複数のポータル サイトの URL が重複している場合、SharePoint 製品とテクノロジ構成ウィザードが中止され、「同一のキーを含む項目が既に追加されています。」というエラーがログ ファイルに記録されます。このエラーは、切り離されたポータル サイトが存在している場合に発生します。これは、IIS またはファイル システム上に存在するが、構成データベース上には存在しないポータル サイトです。このような状態は、次の原因で発生することがあります。

  • ポータル サイトをホスティングする IIS Web サイトを誤って削除した後で、再度作成した。

  • 既存の仮想サーバーの拡張を元に戻した後で、新しいポータル サイトをホスティングするために、同じ仮想サーバーを再度拡張した。

  • 同じポート番号に対応する IIS Web サイトが複数存在する。

SharePoint Portal Server 2003 環境で URL が重複するサイトが存在するかどうか確認するには、[SharePoint のサーバー管理] の [ポータル サイトの一覧と管理] ページで、URL が同じポータル サイトを探します。使用されているサイトと切り離されたサイトを区別し、切り離されたサイトを削除した後で、アップグレードを実行します。

フロントエンド以外の Web サーバーにサーバーの全体管理サイトを作成している場合、一括アップグレードを実行すると、サーバー管理でサイトに間違った URL が表示される

大規模ファームで一括アップグレードを実行する場合、インデックス サーバーに対してアップグレードを実行した後でフロントエンド Web サーバーに対してアップグレードを実行していると、フロントエンド Web サーバーではなくインデックス サーバーにサーバーの全体管理サイトが作成されます。これにより、[サーバーの全体管理] の [サイト コンテンツのアップグレード状態] ページでは、アップグレード対象の Web サイトの URL に間違ったホスト名が表示される可能性があります。この問題を解決するには、サーバーの全体管理サイトに代替アクセス マッピングを追加し、フロントエンド Web サーバーの正しい URL を指定します。

  1. フロントエンド Web サーバーのインターネット インフォメーション サービス マネージャで、サーバーの全体管理サイトのホスト名とポート番号を確認します。

  2. インデックス サーバーで [サーバーの全体管理] を開き、[サーバー構成の管理] タブの [グローバル構成] の下にある [代替アクセス マッピング] をクリックします。

  3. [代替アクセス マッピング] ページの [パブリック URL の編集] をクリックします。

  4. [領域のパブリック URL の編集] ページで [代替アクセス マッピング コレクション] の下向きの矢印をクリックし、[代替アクセス マッピング コレクションの変更] を選択します。

  5. [代替アクセス マッピング コレクションの選択] ボックスで、[サーバーの全体管理] をクリックします。

  6. [パブリック URL] セクションの [イントラネット] ボックスで、フロントエンド Web サーバー上のサーバーの全体管理サイトの正しい URL を入力した後、[保存] をクリックします。

  7. フロントエンド Web サーバーで [サーバーの全体管理] を開き、[サーバー構成の管理] タブの [アップグレードと移行] の下にある [サイト コンテンツのアップグレード状態] をクリックします。

    正しい URL が表示されます。

Microsoft Office SharePoint Portal Server 2003 に一般的でない開始アドレスが構成されている場合、検索開始アドレスとファイル タイプのアップグレードに失敗する

インデックス作成の開始アドレスとして、たとえば http://<server_name>/<server_name>.com のような一般的でないアドレスが指定されている場合、検索のアップグレードで開始アドレスとファイル タイプのアップグレードに失敗する可能性があります。その場合、使用中の Office SharePoint Server 2007 環境で、これらの設定を手動で入力する必要があります。

段階的なアップグレードの既知の問題

サーバー ファームのアップグレードにはネットワーク サービスではなくドメイン アカウントを使用する必要がある

サーバー ファーム環境では、一括アップグレードでも段階的なアップグレードでも、前のバージョンの環境で使用した資格情報を新しいバージョンの環境でも使用する必要があります。ただし、前のバージョンの環境でネットワーク サービス アカウントを使用していた場合、新しいバージョンの環境ではドメイン アカウントを使用する必要があります。前のバージョンの環境では引き続きネットワーク サービスを使用できますが、新しいバージョンをインストールして新しいファームを作成するときには、代わりにドメイン アカウントを指定する必要があります。使用するドメイン アカウントには、SQL Server のデータベースに対する適切な権限を付与してください (前のバージョンの全データベースに対して、Database Creators グループ、Process Administrators グループ、および Database Owners グループに属している必要があります)。

SSL 専用サーバーの段階的なアップグレードに必要な追加手順

段階的なアップグレードでは、元の (アップグレードされない) サイトと新しい (アップグレードされる) サイトをそれぞれホスティングする 2 つの IIS Web サイトを使用します。既定では、作成される新しいサイトでは SSL が使用されません。この Web サイトで SSL を使用する必要がある場合には、段階的なアップグレードの際に追加の手順を実行して、IIS を設定し、SSL に使用するポート番号を設定します。

サイトにターゲット Web アプリケーションを作成した後、サイトをアップグレードする前に、次の手順を実行します。

ターゲット Web アプリケーションの作成の詳細については、「サイトをアップグレードする (Office SharePoint Server)」の「アップグレードされたサイトをホストするための新しい Web アプリケーションを作成する」を参照してください。

インターネット インフォメーション サービス (IIS) マネージャでポート番号と SSL 設定を変更する

  1. インターネット インフォメーション サービス (IIS) マネージャで、変更する Web アプリケーションが格納されているサーバー名の横にあるプラス記号 (+) をクリックします。

  2. [Web サイト] の横にあるプラス記号 (+) をクリックします。

  3. [既定の Web サイト] を右クリックして、[プロパティ] をクリックします。

  4. [Web サイト] タブの [SSL ポート] ボックスに、「444」と入力し、[OK] をクリックします。

  5. 既定の対の Web サイトを右クリックして、[プロパティ] をクリックします。

  6. [Web サイト] タブの [SSL ポート] ボックスに、「443」と入力し、[適用] をクリックします。

  7. [ディレクトリ セキュリティ] タブの [セキュリティで保護された通信] セクションで、[サーバー証明書] をクリックします。

    ウィザードの指示に従って、新しい証明書を割り当てます。

  8. [ディレクトリ セキュリティ] タブの [セキュリティで保護された通信] セクションで、[編集] をクリックします。

  9. [セキュリティで保護された通信] ダイアログ ボックスで、[セキュリティで保護されたチャネル (SSL) を要求する] チェック ボックスをオンにして、[OK] をクリックします。

  10. [OK] をクリックし、既定の対の Web サイトのダイアログ ボックスを閉じます。

代替アクセス マッピングの設定を更新して IIS をリセットする

  1. コマンド プロンプト ウィンドウを開き、%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin に移動します。

  2. 次のコマンドを実行して、元の既定の Web サイトの代替アクセス マッピングを変更し、ポート 444 を指定します。

    Stsadm -o addzoneurl -url https://server_name:port -urlzone default -zonemappedurl https://server_name:444

    ここで、server_name:port には既定の Web サイトの場所を指定します。

  3. %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin に移動します。

  4. 次のコマンドを実行して、リダイレクトされる Web サイトの代替アクセス マッピングを変更します。

    Stsadm -o addzoneurl -url http://server_name:port -urlzone default -zonemappedurl https://server_name:443

    ここで、server_name:port には、ターゲット Web アプリケーションを作成したときに作成された新しいサイトの場所を指定します。

  5. 次のコマンドを実行して IIS をリセットします。

    iisreset /noforce

アップグレードが終了しましたが、一部のサイトがアップグレードされていません。どうすればよいですか。

アップグレード プロセスが終了した後で、アップグレードされていないサイトに対して段階的なアップグレードを実行することはできません。ただし、データベースの移行を利用することで、このようなサイトをアップグレードできます。段階的なアップグレードの終了後にデータベースの移行を利用してサイトをアップグレードする方法については、マイクロソフト サポート技術情報 (https://support.microsoft.com/kb/926718/ja) の記事番号 926718 を参照してください。

共有サービスを使用する子ポータルに段階的なアップグレードを実行した後、子ポータルで検索を実行すると、新しいドキュメントが検索されない

親ファームの共有サービスを利用している子ポータルをアップグレードした場合、代替ポータル サイトの URL マッピングをアップグレードして、アップグレード後の URL を指定する必要があります。そうしなければ、子ポータルからユーザーが検索を実行したときに、子ポータルに追加されたコンテンツが表示されない場合があります。

重要

SharePoint Portal Server 2003 環境で、次の手順を実行する必要があります。

代替ポータル サイトの URL マッピングを更新する

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[SharePoint Portal Server] をポイントし、[SharePoint のサーバー全体管理] をクリックします。

  2. [ポータル サイトと仮想サーバーの構成] の下にある [イントラネット、エクストラネット、およびカスタム アクセスの代替ポータル サイト URL の構成] をクリックします。

  3. 子ポータルのアップグレード済みサイトのドロップダウン メニューで、[編集] をクリックします。

  4. [代替アクセス設定の変更] ページの [イントラネット URL] ボックスに、元のサイトの URL を入力し、[OK] をクリックします。

    これで、既定の URL にアップグレード済みサイトが指定され、イントラネット URL に元のサイトが指定されました。

  5. SharePoint Portal Server 2003 環境にクロールを実行します。

    クロールの実行の詳細については、「SharePoint Portal Server 2003 管理者ガイド」の「Managing Updates of Content Indexes (英語)」(https://office.microsoft.com/en-us/sharepointserver/CH011715081033.aspx) を参照してください。

SharePoint Portal Server 2003 に一般的でない開始アドレスが構成されている場合、検索開始アドレスとファイル タイプのアップグレードに失敗する

インデックス作成の開始アドレスとして、たとえば http://<サーバー名>/<サーバー名>.com のような一般的でないアドレスが指定されている場合、検索のアップグレードで開始アドレスとファイル タイプのアップグレードに失敗する可能性があります。その場合、使用中の Office SharePoint Server 2007 環境で、これらの設定を手動で入力する必要があります。

アップグレード後に親ポータル サイトがクロールされていない

次の条件に該当する場合、親ポータル サイトにクロールは実行されません。

  • 共有サービスを利用している。

  • 複数のインデックス サーバーを含む、大規模なサーバー ファームを使用している。

  • そのインデックス サーバーの 1 つに親ポータルに対する除外ルールが設定されている。

  • インデックスを生成するには、そのルールを削除するか、除外ルールを包含に変更した後で、クロールを再度実行します。

アップグレード後に独立したクエリ サーバーを使用して親ポータルにクエリを実行すると失敗する

ファーム間でのクエリ インデックスの伝達を利用している場合、クエリ サーバーが初期化されるまで時間がかかります。クエリ サーバーを確実に初期化するには、各クエリ サーバーでコマンド ラインから次の操作を実行します。

stsadm.exe -o osearch -propagationlocation <applications directory>

ここで、<applications directory> には、すべての SSP のインデックス データの上位の場所を指定します。次に例を示します。

applications
   SSP1 (as a GUID)
   SSP2 (as a GUID)
   SSP3 (as a GUID)

アップグレードされた親ポータルに、SharePoint Portal Server 2003 サイト上にまだ存在するコンテンツの変換済みの開始アドレスがなく、元の開始アドレスしかない

段階的なアップグレードを実行した後で、開始アドレスに対応する正しい一時 URL が親ポータル サイトに存在せず、元の開始アドレスしかない場合があります。この問題を解決するには、次の手順を実行します。

  1. SharePoint Portal Server 2003 で、検索管理のページを開き、Office SharePoint Server 2007 環境に現在保存されているすべてのコンテンツを削除する除外ルールを追加します。

  2. SharePoint Portal Server 2003 環境にまだ存在しているサイトの新しい URL をクロールするための新しいコンテンツ ソースを追加します。

  3. SharePoint Portal Server 2003 環境でクロールを実行します。

Office SharePoint Server Search サービスを開始できない

アップグレード中に Office SharePoint Server Search サービスが自動的に起動しない場合、SharePoint 製品とテクノロジ構成ウィザードで次のメッセージが表示されます。

アップグレードの完了後に、このサーバーのサービス SearchServiceInstance を起動できませんでした。手動で起動してください。

SharePoint 製品とテクノロジ構成ウィザードは正しく終了しますが、Office SharePoint Server Search サービスは停止したままです。Office SharePoint Server Search サービスを開始するには、次の手順を実行します。

  1. コマンド プロンプトを開き、以下のフォルダに移動します。

    %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\BIN

  2. 以下のコマンドを実行します。

    stsadm –o osearch –action start

セットアップ画面のオプションで [アップグレードしない] を選択した場合に、アップグレードするように後から変更する

セットアップで [アップグレードしない] オプションを選択した場合に、SharePoint 製品とテクノロジ構成ウィザードの実行後にオプションを変更するには、SharePoint 製品とテクノロジ構成ウィザードを再度実行し、段階的なアップグレードを行うように変更する必要があります。

SharePoint 製品とテクノロジ構成ウィザードを使用して、[アップグレードしない] オプションを段階的なアップグレードを実行するように変更するには

  1. SharePoint 製品とテクノロジ構成ウィザードを実行し、ファームから切断します。

  2. %COMMOMPROGRAMFILES%\Microsoft shared\Web Server Extensions\12.0\WSS\ に移動し、SetupType と SetupTypeBackup のレジストリ キーを V2V_GRADUAL_UPGRADE に変更します。

  3. SharePoint 製品とテクノロジ構成ウィザードを再実行して、アップグレードを実行します。

SharePoint 製品とテクノロジをアップグレードできない

Web アプリケーションを含まない既存のサーバー ファームに新しい Web サーバーを追加し、Web サーバーを更新して SharePoint 製品とテクノロジ構成ウィザードを実行すると、次のエラー メッセージが表示されることがあります。

種類 Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException の例外がスローされました。例外の追加情報: SharePoint 製品とテクノロジをアップグレードできませんでした。

このエラーは、SharePoint 製品とテクノロジ構成ウィザードが Web.config ファイルを見つけられないか、変更できないときに発生します。この問題を解決するには、Web.config ファイルを %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\Config から %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\Template\Layouts に手動でコピーする必要があります。Web.config ファイルを Layouts フォルダにコピーした後、SharePoint 製品とテクノロジ構成ウィザードを再び実行することができます。

アップグレードが失敗し、アップグレード ログに Web がないことを示すエラー メッセージが表示される

実行した段階的なアップグレードが失敗した場合、%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS フォルダにあるアップグレード ログを確認してください。アップグレード ログ内のエラー メッセージで Web がないことが示されている場合は、Web サイトが削除されています。その結果、所定の場所に Web サイトが見つかりません。この問題を解決するには、Windows SharePoint Services Timer Service をいったん停止して再開した後、アップグレードを再実行します。

データベースの移行の既知の問題

別々の Web アプリケーションであっても、同じコンテンツ データベースを複数回ファームに追加することはできない

コンテンツ データベース内の各サイト コレクション (各ポータル サイトを含む) には、グローバル一意識別子 (GUID) が関連付けられており、それが構成データベースに登録されています。そのため、別々の Web アプリケーションに含まれる場合でも、同じサイト コレクション (またはポータル) を 2 回ファームに追加することはできません。この状況でもデータベースの接続には成功しますが、サイト コレクションを開始できません。1 つのファームでサイト コレクション (またはポータル) の重複コピーが必要な場合は、まずそのサイト コレクションが含まれるデータベースを別のファームに接続してから、Stsadm.exe のバックアップ操作と復元操作を使用して、サイト コレクションをそのファームにコピーします。バックアップと復元プロセスにより、サイト コレクションに対応する新しい GUID が作成されます。

共有サービス環境ではデータベースをデタッチする前に特別なコマンドを実行する必要がある

共有サービス環境でデータベースの移行を実行する際には、データベースをデタッチ (またはバックアップ) する前に、コマンドラインで次のコマンドを実行する必要があります。

Stsadm.exe -o preparetomove -contentDB <database_server:database_name>

これにより、再接続後にコンテンツ データベースがメンバシップとプロファイルの同期の対象となります。このコマンドを実行せずにコンテンツ データベースをデタッチすると、コンテンツ データベース内のメンバシップとプロファイルの情報が静的となり、アップグレード後に同期されなくなります。

データベースをデタッチする前にこのコマンドを実行しなかった場合、同期の問題を解決する代わりに、接続した後で次のコマンドを実行します。

Stsadm.exe -o preparetomove -oldcontentDB <GUID> -newcontentDB <Database_name>

既にデタッチされているデータベースに preparetomove 操作を実行するには、データベースの GUID を確認する必要があることに注意してください。GUID を検索するには、次のコマンドを使用します。

stsadm -o sync -listolddatabases <days>

データベースをデタッチする方法の詳細については、「データベースのデタッチとアタッチ」を参照してください。

データベースを移行する際にコンポーネント設定 (_SERV) データベースまたはユーザー プロファイル (_PROF) データベースを接続しない

データベースの移行を実行する際には、SharePoint Portal Server 2003 コンポーネント設定データベース (通常は "ID_SERV" という名前の検索データベース。ここで ID には、サーバー名などの ID が入ります) またはユーザー プロファイル (_PROF) データベースを移行して接続する必要はありません。データベースの移行を実行する際には、検索データベースを再作成し、検索設定を再構成する必要があります。これは、SharePoint Portal Server 2003 の検索設定がサーバー上のレジストリとデータベースの両方に保存されており、データベースの移行に一部の設定が含まれないためです。

データベースを移行する際にコンポーネント設定 (検索) データベースを接続すると、共有サービスをアップグレードするときにアップグレード プロセスが中止され、"ストアド プロシージャ 'dbo.proc_MSS_PropagationGetQueryServers' が見つかりませんでした" というメッセージが表示される場合があります。

コンポーネント設定 (_SERV) データベースまたはユーザー プロファイル (_PROF) データベースを接続せずに、データベースの移行を再度実行してください。

コンテンツ データベースの接続後に、ユーザーのアップグレードされた Web サイト ページに個人用サイトが見つからない

個人用サイトを含む共有サービス環境で、データベースの移行によるアップグレード後に、アップグレードされた Web サイト ページに [個人用サイト] リンクがありません。データベースの移行を実行する場合は、データベースに対して一括アップグレードを実行しますが、サーバー ファーム構成データはアップグレードしません。したがって、個人用サイトのホストの URL は、アップグレードされたサーバー ファームでは構成されません。

個人用サイトを含むコンテンツ データベースを新しいサーバー ファームに移行した後、個人用サイトのホストの場所として使用する URL を設定してください。[共有サービス管理] ホーム ページの [ユーザー プロファイルと個人用サイト] セクションで、[個人用サイトの設定] をクリックします。[個人用サイト サービス] セクションで、アップグレードされたサーバー ファームの個人用サイトのホストの場所に使用する Web アプリケーションの URL として「/MySite」を入力します。/MySite には、SharePoint サイト用の Web アプリケーション内に既定で作成される個人用サイトのホストの場所へのパスを指定します。詳細については、「個人用サイトの設定を構成する」を参照してください。

カスタマイズしたサイトの既知の問題

Web.config ファイルに許可されていないカスタマイズを加えるとアプリケーション エラーが発生する

Web.config ファイルで、仮想サーバーのサブフォルダに関する特定のカスタマイズを加えることは禁じられています。たとえば、Web.config ファイルのこのレベルでは AUTHENTICATION ノードと SESSIONSTATE ノードが禁止されています。推奨されない方法で Web.config ファイルを変更すると、アップグレードの際に予期しない結果が発生することがあります。Web.config ファイルのカスタマイズに限らず、カスタマイズの推奨事項には必ず従ってください。詳細については、MSDN Web サイトの「Best Practices for Ensuring Application Reusability and Upgrade in Windows SharePoint Services (英語)」(https://msdn.microsoft.com/ja-jp/library/dd583161.aspx) を参照してください。

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

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

ダウンロード可能なブックの完全な一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。