ソフトウェア更新プログラムのインストール (SharePoint Server 2010)
適用先: SharePoint Foundation 2010, SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事では、Microsoft SharePoint Server 2010 ファーム内のサーバーにソフトウェア更新プログラムをインストールする方法について説明します。また、3 つのシナリオ例について説明し、各シナリオに対応する更新手順を示します。
この記事の内容
更新戦略を確認する
インストールの進行状況を監視する
更新の失敗に対処する
更新シナリオを確認する
下位互換性のない一括方式を使用する
下位互換性のある一括方式を使用する
データベース接続方式を使用して既存のコンテンツの可用性を高める
更新が正常に完了したことを確認する
更新戦略を確認する
ソフトウェア更新プログラムの展開を開始する前に、使用する更新戦略が使用中の Microsoft SharePoint Server 環境に最適であることを確認します。ソフトウェア更新プログラムの展開に使用する戦略は、ダウンタイムの削減、コスト、複雑さなど複数の要因によって決まります。使用する更新戦略 (一括、データベース接続、または複合) を確認するには、「ソフトウェア更新プログラムを展開する準備をする (SharePoint Server 2010)」の「Determine Update Strategy」のフローチャートを使用します。
インストールの進行状況を監視する
更新中に更新プログラムの展開プロセスを監視し、更新が予定どおりに進んでいることを確認します。更新の妨げになる問題や、更新されたファームの要素が期待どおりに機能しないという結果を招く問題が発生する可能性があります。データベースの同期とカスタマイズに特に注意してください。
製品と更新プログラムのインストールの状態、データの状態、およびアップグレードの状態をリアルタイムで表示するには、サーバーの全体管理の [アップグレードと移行] を主なツールとして使用することをお勧めします。
セットアップの実行後は、ログ ファイルを表示したり、Windows PowerShell を使用してインストールの進行状況の現在の結果を取得したりすることもできます。
更新の失敗に対処する
SharePoint Server 2010 では、更新プログラムの適用フェーズが終了した後のアップグレードの失敗に対する対処方法が改善されています。下位互換モードで実行しているときにアップグレードが失敗した場合は、SharePoint Server データベースを復元し、下位互換モードで引き続き動作させることができます。サイトの更新の問題が解決したら、アップグレードを再開できます。完了済みのタスクが再度実行されることはありません。詳細については、「アップグレードのテストとトラブルシューティング (SharePoint Server 2010)」を参照してください。
以前の SharePoint 製品とテクノロジ環境で更新が失敗した場合は、通常、製品をアンインストールし、古いバージョンをインストールして、バックアップから復元する必要がありました。
更新シナリオを確認する
この記事では、以下のソフトウェア更新シナリオについて説明します。
下位互換性のない一括方式を使用する – 更新プログラムをすべてのファーム サーバーに同時にインストールし、下位互換を使用せずにコンテンツをアップグレードします。
下位互換性のある一括方式を使用してダウンタイムを削減する – 更新プログラムを段階的にインストールし、下位互換性のある遅延アップグレードを使用してダウンタイムを削減します。
データベース接続方式を使用してコンテンツの可用性を高める – この更新では、2 つのファームを使用して既存のコンテンツの可用性を高めます。
一括プロセスとデータベース接続プロセスの動作の詳細については、「アップグレード プロセスの概要 (SharePoint Server 2010)」の図を参照してください。この記事は、ソフトウェアをあるバージョンから別のバージョンにアップグレードする方法に関するもので、ソフトウェア更新プログラムをインストールする方法に関するものではありません。ただし、大まかなプロセスは非常に似ています。
次の図は、この記事で説明する更新プログラム適用シナリオで例として使用されるファーム トポロジを示しています。
.gif "ソフトウェア更新プログラムをインストールするファームの例")
初期状態と必要な条件
上の図は、更新プログラムをインストールする前のファームの初期状態を示しています。次の条件が満たされていることを確認します。
すべてのフロントエンド Web サーバーが共に負荷分散されており、ロード バランサーのローテーションに組み込まれている。
すべてのファーム サーバーが正常に動作している。
すべてのデータベースがアクティブになっていて正常に動作している。
上の条件のいずれかが満たされていない場合は、ソフトウェアを起動しないでください。問題をすべて解決してから続行してください。
下位互換性のない一括方式を使用する
このシナリオでは、フロントエンド Web サーバーに要求が着信しないようにしてから、すべてのファーム サーバーに更新プログラムをインストールします。そのため、ファーム全体をシャットダウンすることになります。この戦略は、「ソフトウェア更新プログラムの概要 (SharePoint Server 2010)」の「Software Update Process」に記載されている更新フェーズとアップグレード フェーズを組み合わせたものです。
次の図は、ファームに更新プログラムをインストールする手順を示しています。
.gif "下位互換性のない一括アップグレード")
次の推奨手順に従う際には、上の図をガイドとして使用してください。
下位互換を使用せずに更新プログラムをインストールするには
Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションから除外するか、ロード バランサーを一時停止して、サーバーに要求が着信しないようにします。
サーバーの全体管理をホストしているアプリケーション サーバー (APP-1) で、実行可能ファイルを実行して更新プログラムをインストールします。
検索クエリ コンポーネントをホストしているアプリケーション サーバー (APP-2) で、実行可能ファイルを実行して更新プログラムをインストールします。
すべてのサーバーが正常に更新されたことを確認します。
最初の Web サーバー (WEB-1) にログオンします。
Web サーバーで、実行可能ファイルを実行して更新プログラムをインストールします。
残りの Web サーバー (WEB-2、WEB-3、および WEB-4) で、実行可能ファイルを実行して更新プログラムをインストールします。
すべてのサーバーが正常に更新されたことを確認します。
サーバーの全体管理サーバーで SharePoint 製品構成ウィザードを実行して、構成データベースをアップグレードし、各コンテンツ データベースを 1 つずつアップグレードします。
検索クエリ コンポーネントをホストしているアプリケーション サーバー (APP-2) で SharePoint 製品構成ウィザードを実行します。
最初の Web サーバー (WEB-1) で SharePoint 製品構成ウィザードを実行します。
注意
構成ウィザードを実行し、特定のサーバーで更新エラーが発生した場合にそのエラーが他の Web サーバーに伝播しないようにします。たとえば、あるサーバーでアップグレードが失敗すると、1 つまたは複数のサイト コレクションでアップグレードが失敗することがあります。
残りの各 Web サーバーで上記の手順を繰り返します。
更新が正常に完了したことを確認します。詳細については、「更新が正常に完了したことを確認する」を参照してください。
Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションに追加するか、ロード バランサーを開始して、サーバーに要求が着信するようにします。
下位互換性のある一括方式を使用する
このシナリオでは、SharePoint Server 2010 の下位互換性と遅延アップグレード機能を使用して、ソフトウェア更新プログラムの展開に必要なダウンタイムを削減します。ただし、ダウンタイムは完全になくなるわけではありません。コンテンツのアップグレード中は、サイトおよびサービスは利用できません。
このソフトウェア更新シナリオでは、次の 2 つのフェーズを使用して、ファーム サーバーに更新プログラムをインストールします。
ファーム サーバーに更新プログラムをインストールするための更新
更新プログラムの適用プロセスを完了するためのアップグレード
更新フェーズ中は、ゼロまたは最小限のダウンタイムでファームの運用を続行できます。ただし、アップグレード フェーズ中は、ファームは利用できません。ファームのアップグレード中にコンテンツにアクセスしようとすると、リソースの競合やロックが発生し、アップグレードが失敗したり、アップグレード プロセスの速度が極端に遅くなったりすることがあります。このような操作はサポートされておらず、テストもされていません。
ソフトウェアの更新プロセスの詳細については、「ソフトウェア更新プログラムの概要 (SharePoint Server 2010)」の「Software Update Process」を参照してください。
更新フェーズ
次の図は、ファームに更新プログラムをインストールするのに必要な手順を示しています。
.gif "下位互換性のある一括アップグレード")
次の推奨手順に従う際には、上の図をガイドとして使用してください。
ファーム サーバーに更新プログラムをインストールするには
半数の Web サーバー (WEB-1 および WEB-2) をロード バランサーのローテーションから除外するか、ロード バランサーを一時停止して、サーバーに要求が着信しないようにします。
負荷分散のローテーションから除外されている各 Web サーバー (WEB-1 および WEB-2) で、実行可能ファイルを実行して更新プログラムをインストールします。これらのサーバーで SharePoint 製品構成ウィザードを実行しないでください。両方の Web サーバーが正常に更新されたことを確認します。
残りの Web サーバー (WEB-3 および WEB-4) をロード バランサーのローテーションから除外するか、ロード バランサーを一時停止して、サーバーに要求が着信しないようにします。この時点で、ファームに対する要求を受信しているフロントエンド Web サーバーはなくなります。
更新された Web サーバー (WEB-1 および WEB-2) を負荷分散のローテーションに戻します。
負荷分散のローテーションからまだ除外されている各 Web サーバーで、実行可能ファイルを実行して更新プログラムをインストールします。これらのサーバーで SharePoint 製品構成ウィザードを実行しないでください。両方の Web サーバーが正常に更新されたことを確認します。
更新された Web サーバー (WEB-3 および WEB-4) を負荷分散のローテーションに戻します。
検索クエリ コンポーネントをホストしているアプリケーション サーバー (APP-2) で、実行可能ファイルを実行して更新プログラムをインストールします。このサーバーで SharePoint 製品構成ウィザードを実行しないでください。
サーバーの全体管理サーバー (APP-1) で、実行可能ファイルを実行して更新プログラムをインストールします。このサーバーで SharePoint 製品構成ウィザードを実行しないでください。
両方のアプリケーション サーバー (APP-1 および APP-2) が正常に更新されたことを確認します。
更新が正常に完了したことを確認します。詳細については、「更新が正常に完了したことを確認する」を参照してください。
プロセスのこの時点では、どのファーム サーバーでも SharePoint 製品構成ウィザードを実行していないので、データベースやその他のコンポーネント (設定、機能、サイトレベルのデータなど) をアップグレードする必要がまだ残っています。ただし、ファームを下位互換モードで運用することはできます。
アップグレード フェーズ
次の図は、ファーム サーバーをアップグレードして更新プログラム適用プロセスを完了するのに必要な手順を示しています。このプロセスの実行中は、ユーザーはアップグレード対象のサイトを利用できません。
.gif "ソフトウェア一括更新のアップグレード フェーズ")
次の推奨手順に従う際には、上の図をガイドとして使用してください。
重要
次の順番のサーバーをアップグレードする前に、各サーバーのアップグレードの状態を監視してください。アップグレードを開始する前にファームのバックアップを作成することを強くお勧めします。
次に、ファームをアップグレードするためのすべての手順を示します。すべてのコンポーネントを同じサービス停止期間内にアップグレードすることも、より短いサービス停止期間を設けてファームの各コンポーネントを別々の時間にアップグレードすることもできます。 アップグレードを段階的に行う場合は、次のコンポーネントを別々のサービス停止期間内にアップグレードできます。
サービス
サービスに適用する必要がある更新がソフトウェア更新プログラムに含まれている場合は、サービスをアップグレードし、その後、ファームを長期間停止してコンテンツとファームのアップグレードを完了できるようになるまで、ファームの運用を再開することができます (手順 7 および 8)。
コンテンツ データベース
ファームを短期間停止して、その停止期間中に少数のコンテンツ データベースのみをアップグレードし (手順 1 ～ 3)、その後でファームの運用を再開することができます (手順 7 および 8)。すべてのコンテンツがアップグレードされ、ファーム サーバーをアップグレードする準備ができるまで、続けて停止期間を設けてこのプロセスを繰り返すことができます。
各コンテンツ データベースを並行してアップグレードすることもできます。ただし、同時にアップグレードできるのはごく少数のコンテンツ データベースだけです。多すぎる数のコンテンツ データベースを並行してアップグレードしないでください。これを行うと、アップグレード プロセス全体の速度が低下し、停止期間が長くなります。同じ Microsoft SQL Server ボリュームの 3 つ以上のコンテンツ データベースを一度にアップグレードしないこと、およびアップグレード プロセスの開始時にロック競合が発生するのを防ぐために、並行して行われる各コンテンツ データベースのアップグレードの開始時間を数分ずつずらすことをお勧めします。また、Web サーバーまたはアプリケーション サーバーごとのアップグレード対象コンテンツ データベースの数を制限してください。追加のアップグレード プロセスのたびに、かなりの量のリソースが消費されるからです。一般に、アップグレード可能なコンテンツ データベースの数は、Web サーバーまたはアプリケーション サーバー 1 台につき 4 つです。ただし、どの Web サーバーまたはアプリケーション サーバーからアップグレードを開始するかにかかわらず、SQL Server ボリュームごとのアップグレード対象データベースの数を超えないようにしてください。
ファームをアップグレードするには
Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションから除外するか、ロード バランサーを一時停止して、サーバーに要求が着信しないようにします。
重要
サイトおよびサービスは、アップグレードが完了してサーバーがアクティブな負荷分散状態に戻るまで利用できません。
必要に応じて特定のサービスをアップグレードします。
一部の更新では、追加の Windows PowerShell コマンドレットを実行して特定のサービス アプリケーションをアップグレードすることが必要になる場合もあります。ソフトウェア更新プログラムのリリース ノートに、「ある特定のサービスを修正プログラム適用後に持続的に動作させるには、そのサービスをアップグレードする必要がある」という記載がある場合は (サービスが下位互換モードで動作できない場合など)、ファームを短期間停止して、ファーム全体をアップグレードせずにサービスをアップグレードすることができます。これが必要な場合は、特定のサービス アプリケーションをアップグレードするための追加の Windows PowerShell コマンドレットがリリース ノートに記載されているはずです。
Windows PowerShell Upgrade-SPContentDatabase コマンドレットを使用して各コンテンツ データベースをアップグレードします。
これはオプションの手順です。ただし、この手順を実行すると、最初にすべてのコンテンツ データベースをアップグレードすることができます。これには、処理を並列化することによって停止期間を短縮できるというメリットがあります。この手順を省略した場合、アップグレードされていない残りのコンテンツ データベースは、SharePoint 製品構成ウィザード を実行してファーム サーバーをアップグレードするときに 1 つずつアップグレードされます。
重要
各データベースに対して Upgrade-SPContentDatabase コマンドレットを実行します。このコマンドレットは、アップグレード済みの任意の Web サーバーまたはアプリケーション サーバーから実行できます。各データベースのコンテンツは、該当するデータベースでこのプロセスが実行されている間は利用できません。
サーバーの全体管理サーバー (APP-1) で SharePoint 製品構成ウィザードを実行します。
重要
SharePoint 製品構成ウィザードは、構成データベースとまだアップグレードされていない他のデータベースのアップグレードも直ちに開始します。前の手順で説明したように、コンテンツ データベース以外のデータベースはアップグレードがまだ完了していない可能性が高いため、サービス アプリケーション データベースはすべてこの手順でアップグレードされます。このプロセスの実行中は、サイトは利用できません。
残りのアプリケーション サーバー (APP-2) で SharePoint 製品構成ウィザードを実行します。
Web サーバー (WEB-1 ～ WEB-4) で SharePoint 製品構成ウィザードを実行します。
更新が正常に完了したことを確認します。詳細については、「更新が正常に完了したことを確認する」を参照してください。
アップグレードされた Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションに戻します。
データベース接続方式を使用して既存のコンテンツの可用性を高める
このシナリオでは、既存のコンテンツの可用性を高めるために、既存のファームの読み取り専用データベースを使用します。更新プログラムは新しいファームにインストールされ、ユーザー トラフィックはこのファームに経路変更されます。
次の図は、データベース接続方式を使用して新しいファームに更新プログラムをインストールするのに必要な手順を示しています。詳細については、「データベースを接続して SharePoint Server 2010 へアップグレードする」を参照してください。
.gif "データベース接続を使用したソフトウェア更新プログラムのインストール")
次の推奨手順に従う際には、上の図をガイドとして使用してください。
データベース接続を使用して更新プログラムをインストールするには
ソフトウェア更新プログラムをインストールする新しいファームを作成します。このファームには、フロントエンド Web サーバーは必要ありません。詳細については、「データベース接続アップグレードのために新しい SharePoint Server 2010 環境を準備する」を参照してください。
注意
元のファームでデータベース ミラーを使用している場合は、新しいファームにソフトウェア更新プログラムを展開した後にミラーリングを構成する必要があります。
既存のファームのデータベースを読み取り専用に構成します。
注意
既存のファームがミラー化されている場合、データベースを読み取り専用に設定する前にミラーリングを一時停止する必要があります。
読み取り専用データベースを構成する方法の詳細については、「データベースを接続して SharePoint Server 2010 へアップグレードする」および「読み取り専用データベースを使用するファームを実行する (SharePoint Server 2010)」の「前のバージョンのデータベースを読み取り専用に設定する (読み取り専用データベースでのデータベース接続)」を参照してください。
既存のファームのサービス アプリケーション データベースを読み取り専用に構成します。これにより、サービス アプリケーションに対する予期しない変更が防止されます。
User Profile Service サービス アプリケーション データベースに修正プログラムを適用する場合は、古いデータベースから User Profile Synchronization Service 暗号化キーをエクスポートし、新しいデータベースにインポートする必要があります。このキーは、Microsoft Identity Integration Server (MIIS) キー、Synchronization Service 暗号化キー、および Forefront Identity Manager 2010 (FIM 2010) キーとも呼ばれます。キーを正しくエクスポートしてインポートしないと、Synchronization Service が開始しません。暗号化キーをエクスポートするには、次の手順を実行します。
ファーム管理者の資格情報を使用して、古い User Profile Service サービス アプリケーション データベースが格納されているコンピューターにログオンします。
コマンド プロンプト ウィンドウを開き、次のフォルダーに移動します。
%Program Files%\Microsoft Office Servers\14.0\Synchronization Service\Bin\
次のコマンドを入力し、Enter キーを押します。
miiskmu.exe /e <Path>
<Path> はキーをエクスポートするファイルの完全パスで、ユーザー名とパスワードはファーム管理者の資格情報です。
既存のファームのコンテンツ データベースをバックアップします。詳細については、「バックアップと復旧 (SharePoint Server 2010)」を参照してください。
暗号化キーをインポートするには、次の手順を実行します。
ファーム管理者の資格情報を使用して、新しい User Profile Service サービス アプリケーション データベースが格納されているコンピューターにログオンします。
User Profile Synchronization Service の開始を試みます。暗号化キーをまだインポートしていないため、サービスは開始しません。ULS ログを使用するか、サービスのステータスが [停止中] になっていることを確かめることで、サービスが開始しなかったことを確認します。
コマンド プロンプト ウィンドウを開き、次のフォルダーに移動します。
%Program Files%\Microsoft Office Servers\14.0\Synchronization Service\Bin\
次のコマンドを入力し、Enter キーを押します。
miiskmu.exe /i <Path> {0E19E162-827E-4077-82D4-E6ABD531636E}
ここで、<Path> はキーをエクスポートしたファイルの完全パスです。
(オプション) 暗号化キーが正しくインポートされたことを確認するには、コマンド プロンプトで次のコマンドを入力し、Enter キーを押します。
miiskmu.exe /c {0E19E162-827E-4077-82D4-E6ABD531636E}
コンテンツ データベースを新しいデータベース サーバーに復元します。
古いファームの既存のサービス アプリケーションごとに、新しいファームにサービス アプリケーションを作成します。
既存のファームからすべての設定を複製する必要があります。
データベース接続を使用して、新しいファームにデータベースを作成します。詳細については、「SharePoint Server 2010 へのデータベース接続アップグレードを実行する」および「読み取り専用のコンテンツ データベースを接続および復元する (SharePoint Server 2010)」を参照してください。
新しいファームに問題がないことを確認します。
DNS が新しいファームを指すように構成するか、新しいファームが負荷分散されるようにすることで、新しいファームを運用ファームとして有効にします。ユーザーが新しいファームにアクセスできることを確認します。
ユーザーがキャッシュされた DNS から切り替える時間を取り、その後で古いファームを使用不可にします。
更新が正常に完了したことを確認します。詳細については、「更新が正常に完了したことを確認する」を参照してください。
更新が正常に完了したことを確認する
使用する更新戦略やソフトウェア更新中に行う監視に関係なく、更新が正常に完了したことを確認する必要があります。詳細については、「アップグレードの状態とアップグレードされたサイトを確認する (SharePoint Server 2010)」を参照してください。