SharePoint Server 用のソフトウェア更新プログラムをインストールする
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
開始する前に
ソフトウェア更新プロセスを開始する前に、必要な権限、ハードウェア要件、ソフトウェア要件、および更新プロセスに関する以下の情報を確認してください。
SharePoint Server 2016、2019、およびサブスクリプション エディションのソフトウェア更新プログラムの概要
SharePoint Server 2016、2019、およびサブスクリプション エディションのソフトウェア更新プログラムを展開するための準備
注:
この記事の手順は SharePoint Server 2016 を参照していますが、特に記載がない限り、SharePoint Foundation 2013、SharePoint Server 2013、SharePoint Server 2019、および SharePoint Server サブスクリプション エディションに適用されます。
この記事の手順を実行するには、以下のメンバーシップとロールが必要です。
SQL Server インスタンスの securityadmin 固定サーバー ロール
更新するすべてのデータベースの db_owner 固定データベース ロール
Microsoft PowerShell コマンドレットを実行するサーバーのローカル管理者
更新プログラムをインストールする前に、次の条件を満たしていることを確認します。
すべてのフロントエンド Web サーバーがロード バランサーで負荷分散され、ローテーションで運用されている。
すべてのファーム サーバーが適切に動作している。 [検索] では、Microsoft PowerShell コマンドレット Get-SPEnterpriseSearchStatus を使用するか、[サーバーの全体管理] > [サービス アプリケーションの管理] >Search_service_application_nameに移動して、サーバーの状態を表示できます。
すべてのデータベースがアクティブで、適切に動作している。
上記のいずれかの条件が満たされない場合は、更新を開始しないでください。 すべての問題を解決してから続行します。
SharePoint Server 2016、2019、および Subscription Edition では、パッチ適用フェーズの完了後に特定のアップグレード エラーを処理できます。 しかし、ビルドからビルドへのアップグレードが失敗した場合は、バックアップからの復元を行わなければならない可能性があります。 したがって、更新プロセスを開始する前に完全バックアップを必ず実行してください。 復元が完了したら、更新を再開できます。 完了したタスクは再実行されません。 詳細については、次のリソースを参照してください。
更新方法を決定する
ソフトウェア更新プログラムの展開を開始する前に、使用する予定の更新戦略が SharePoint Server 2016、2019、またはサブスクリプション エディション環境に最適であることを確認します。 ダウンタイムの短縮、コスト、複雑さなどいくつかの判断材料を基に、ソフトウェア更新プログラムの展開方法を決定します。
データベース接続プロセスのしくみの詳細については、「 SharePoint 2013 から SharePoint Server 2016 へのアップグレード プロセスの概要」、「SharePoint Server 2019へのアップグレード プロセスの概要」、および 「SharePoint Server サブスクリプション エディションへのアップグレード プロセスの概要」の図を参照してください。
注:
この記事のリンクの中には、ビルドからビルドへのアップグレードではなく、バージョンからバージョンへのアップグレードについて扱ったコンテンツに移動するものがあります。 しかし、これらの 2 種類のアップグレードの一般的なプロセスは類似しています。 たとえば、データベースのアップグレードのフェーズは、ビルドからビルドへのアップグレードでもバージョンからバージョンへのアップグレードでも基本的に同じです。
インストールの進行状況を監視する
更新プログラムの展開処理を監視して、更新が予定どおりに進んでいることを確認します。 更新をブロックする問題や、期待どおりに動作しない要素を持つ更新されたファームが発生する可能性があります。 データベースの同期とカスタマイズには特に注意が必要です。
サーバーの全体管理 の [ アップグレードと移行] ページを使用して、製品および更新プログラムのインストールの状態、データの状態、およびアップグレードの状態をリアルタイムで確認することをお勧めします。
セットアップの実行後、ログ ファイルを表示し、Microsoft PowerShell を使用してインストールの進行状況を確認することもできます。
初期状態
次の図に、この記事の更新プログラムの適用シナリオの例で使用するファーム トポロジを示します。
続行する準備ができたら、この記事の次のいずれかの手順のみを実行して更新プログラムをインストールします。
下位互換性のないインプレース方式を使用する
下位互換性のあるインプレース方式を使用する
データベース アタッチ方式を使用して既存コンテンツの高可用性を維持する
下位互換性のないインプレース方式を使用する
このシナリオでは、フロントエンド Web サーバーへの着信要求を無効にしてファーム全体を効率的にシャットダウンします。 次いで、すべてのファーム サーバーに更新プログラムをインストールします。 この戦略では、「 SharePoint 2013 から SharePoint Server 2016 へのアップグレード プロセスの概要」の「SharePoint Server 2016 のソフトウェア更新プログラムの概要 」セクションで説明されている 更新プログラムとビルドからビルドへのアップグレード フェーズを組み合わせています。
次の図に、ファームに更新プログラムをインストールするのに必要な手順を示します。 この図は、続きの操作 (「下位互換性のない更新プログラムをインストールするには 」) の各手順を実行する際に参考にできます。
下位互換性のない更新プログラムをインストールするには
更新プログラムのインストール中にファームを使用できないことをユーザーに通知します。
すべての Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。
更新プログラムの実行ファイルを実行して、サーバーの全体管理 をホストするアプリケーション サーバー (APP-1) に更新プログラムをインストールします。
更新プログラムの実行ファイルを実行して、検索コンポーネントをホストする他のすべてのアプリケーション サーバー (APP-2) に更新プログラムをインストールします。 これを行うには、この記事の後半に示す ホスト検索コンポーネント の手順を実行し、この手順の次の手順に戻ります。 現時点では、これらのサーバーで SharePoint 製品構成ウィザードを実行しないでください。
アップグレード ログ ファイルを調べて、アプリケーション サーバーがすべて正常に更新されたことを確認します。
アップグレード ログ ファイルとアップグレード エラー ログ ファイルは、%COMMONPROGRAMFILES%\Microsoft Shared\Web サーバー拡張機能\16\LOGS にあります。 アップグレード ログ ファイル名の形式は次のとおりです。Upgrade-YYYMMDD-HHMMSS-SSS.log。 ここで、YYYYMMDD は日付、 HHMMSS-SSS は 時間 (24 時間のクロック形式、分、秒、ミリ秒)。 アップグレード エラー ログ ファイルは、Upgrade-YYYYMMDD-HHMMSS-SSS-error.log という名前の短いファイル内のすべてのエラーと警告を結合します。
1 番目の Web サーバー (WEB-1) にログオンします。
実行ファイルを実行して、この Web サーバーに更新プログラムをインストールします。
実行ファイルを実行して、残りの Web サーバー (WEB-2、WEB-3、および WEB-4) に更新プログラムをインストールします。
アップグレード ログ ファイルを調べて、Web サーバーがすべて正常に更新されたことを確認します。
サーバーの全体管理 (APP-1) で SharePoint 製品構成ウィザードを実行します。 これにより、構成データベースがアップグレードされ、各コンテンツ データベースがアップグレードされます。
ウィザードを実行する方法については、「SharePoint Server 2016、2019、またはサブスクリプション エディションの 複数のサーバーに SharePoint Server をインストールする」を参照してください。 「SharePoint 2013 用の 3 層ファームの複数のサーバーに SharePoint 2013 をインストールする」を参照してください。
他のアプリケーション サーバーで SharePoint 製品構成ウィザード を実行します。
1 番目の Web サーバーで SharePoint 製品構成ウィザード を実行します。
注:
特定のサーバーで更新プログラムが失敗した場合に、そのエラーが他の Web サーバーに伝播していないことを、構成ウィザードを実行して確認します。 たとえば、1 台のサーバーで更新が失敗すると、1 つ以上のサイト コレクションで更新が失敗することがあります。
上記の手順を残りの各 Web サーバーに対して繰り返します。
更新が正常に完了したことを確認します。 詳細については、「 SharePoint Server 2016 でデータベースのアップグレードを確認する」を参照してください。
Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションに戻すか、ロード バランサーを再開してサーバーへの着信要求を有効にします。
ファームが使用可能であることをユーザーに通知します。 更新プログラムのインストールとこの記事の使用が完了しました。
下位互換性のあるインプレース方式を使用する
このシナリオでは、SharePoint の下位互換性と遅延アップグレード機能を利用して、ソフトウェア更新プログラムの展開に必要なファームのダウンタイムを短縮します。 ただし、ダウンタイムは排除されません。 データベース コンテンツのアップグレード中は、サイトとサービスを使用できません。
この更新シナリオでは、2 つのフェーズを使用して、ファーム サーバーに更新プログラムをインストールします。 これらのフェーズは次のとおりです。
ファーム サーバーに更新プログラムをインストールします。
ビルドからビルドへのアップグレードを実行し、更新プログラムの適用処理を完了します。
重要
更新フェーズ中、ファームは、最小限のダウンタイムで運用を続行できます。 ただし、ビルドからビルドへのアップグレード フェーズ中は使用できません。 ファームのアップグレード中に、ユーザーがコンテンツにアクセスを試みると、リソースの競合とロックが原因で、アップグレードが失敗したり、アップグレード処理が極端に低速になったりする可能性があります。 このようなアクセス試行のテストは現段階では未実施で、サポートしていません。
詳細については、次のトピックを参照してください。
- SharePoint Server 2016、2019、およびサブスクリプション エディションのソフトウェア更新プログラムの概要
- SharePoint 2013 から SharePoint Server 2016 へのアップグレード プロセスの概要
- SharePoint Server 2019 でデータベースのアップグレードを確認する
- SharePoint Server サブスクリプション エディションのデータベースのアップグレードを検証する
更新フェーズ
次の図に、ファームに更新プログラムをインストールするのに必要な手順を示します。 この図は、次の操作 (「更新プログラムをインストールするには」) の各手順を実行する際に参照できます。
更新プログラムをインストールするには
半分の Web サーバー (WEB-1 と WEB-2) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。
負荷分散のローテーションから外した各 Web サーバー (WEB-1 と WEB-2) で実行ファイルを実行して、更新プログラムをインストールします。 これらのサーバーで SharePoint 製品構成ウィザードを実行しないでください。 更新ログ ファイルを調べて、これらの Web サーバーが正常に更新されたことを確認します。
アップグレード ログ ファイルとアップグレード エラー ログ ファイルは、%COMMONPROGRAMFILES%\Microsoft Shared\Web サーバー拡張機能\16\LOGS にあります。 アップグレード ログ ファイル名の形式は次のとおりです。Upgrade-YYYMMDD-HHMMSS-SSS.log。 ここで、YYYYMMDD は日付、 HHMMSS-SSS は 時間 (24 時間のクロック形式、分、秒、ミリ秒)。 アップグレード エラー ログ ファイルは、Upgrade- YYYMMDD-HHMMSS-SSS-error.log という名前の短いファイル内のすべてのエラーと警告を結合します。
残りの Web サーバー (WEB-3 と WEB-4) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。
更新済みの Web サーバー (WEB-1 と WEB-2) を負荷分散のローテーションに戻します。
負荷分散のローテーションから外した各 Web サーバーで実行ファイルを実行して、更新プログラムをインストールします。 現時点では、これらのサーバーで SharePoint 製品構成ウィザードを実行しないでください。 更新ログ ファイルを調べて、Web サーバーが両方とも正常に更新されたことを確認します。
更新済みの Web サーバー (WEB-3 と WEB-4) を負荷分散のローテーションに戻します。
検索コンポーネントをホストするすべてのアプリケーション サーバー (APP-1 と APP-2) で更新プログラムをインストールします。 これを行うには、この記事の後半に示す 「SharePoint Server 2016 のソフトウェア更新プログラムをインストール する」の手順を実行し、この手順の次の手順に戻ります。 現時点では、SharePoint 製品構成ウィザードを実行しないでください。
ファームに Search コンポーネントをホストしていない追加のアプリケーション サーバーがある場合は、更新実行可能ファイルを実行して、これらのサーバーに更新プログラムをインストールします。 現時点では、これらのサーバーで SharePoint 製品構成ウィザードを実行しないでください。
更新ログ ファイルを調べて、これらのアプリケーション サーバーが正常に更新されたことを確認します。
このプロセスのこの時点で、SharePoint 製品構成ウィザードがどのファーム サーバーでも実行されていなかったため、データベースやその他のコンポーネント (設定、機能、サイト レベルのデータなど) は引き続きアップグレードする必要があります。 ただし、ファームは、下位互換性モードで実行できる必要があります。
アップグレード フェーズ
次の図に、ファーム サーバーをアップグレードすることにより、更新プログラムの適用処理を終了するのに必要な一連の手順を示します。 このプロセスでは、アップグレード中のサイトをユーザーが使用できなくなります。
次の操作の手順を使用するときは、上記の図を参考にしてください。
重要
各サーバーのアップグレードの状態を監視してから、次のサーバーのアップグレードに進みます。 アップグレードを開始する前に、ファームをバックアップすることを強くお勧めします。
次の手順は、ファームをアップグレードするすべてのステップを示しています。 機能が停止している間にすべてのコンポーネントをアップグレードすることも、停止時間を分割して各時間内にファームのパーツを個別にアップグレードすることもできます。 アップグレードを段階的に行う場合は、次のコンポーネントを停止時間を分けてアップグレードできます。
サービス
ソフトウェア更新プログラムに適用する必要があるサービスの更新プログラムが含まれている場合は、サービスをアップグレードしてから、ファームの運用を再開できます (次の手順の手順 8)。
コンテンツ データベース
ファームの停止が短い場合、毎回少数のコンテンツ データベース (次の手順の手順 3 と 4) のみをアップグレードし、ファーム操作を再開できます (次の手順の手順 8)。 すべてのコンテンツをアップグレードし、ファーム サーバーをアップグレードする準備ができるまで、連続した停止期間にわたってプロセスを繰り返すことができます。
また、ごく少数のコンテンツ データベースに対して個別のコンテンツ データベースを同時にアップグレードすることもできます。 ただし、アップグレード プロセス全体が遅くなり、停止時間が長くなるため、多すぎるコンテンツ データベースを並列にアップグレードしないでください。 同じ SQL Server ボリューム上の 2 つ以上のコンテンツ データベースを一度にアップグレードしないことをお勧めします。 アップグレード プロセスの開始時にロックの競合を防ぐために、数分間隔で並列に実行される各コンテンツ データベースのアップグレードを開始します。 さらに、1 つの Web サーバーまたはアプリケーション サーバーでアップグレードするコンテンツ データベースの数を制限します。 追加のアップグレード プロセスごとに、比較的多くのリソースが消費されます。 Web サーバーまたはアプリケーション サーバーごとにアップグレードできるコンテンツ データベースの一般的な数は、4 つのデータベースです。 ただし、アップグレードを開始する Web サーバーまたはアプリケーション サーバーに関係なく、SQL Server ボリュームごとにアップグレードされるデータベースの数を超えないようにしてください。
ファームをアップグレードするには
Web サーバー (WEB-1 ～ WEB-4) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。
重要
サイトとサービスは、アップグレードが完了し、サーバーがアクティブな負荷分散状態に戻るまで使用できません。
必要に応じて、特定のサービスをアップグレードします。
一部の更新では、追加の PowerShell コマンドレットを実行し、特定のサービス アプリケーションもアップグレードしなければならない場合があります。 ソフトウェア更新のメモには、更新プログラムの適用後も特定のサービスが動作するためには、そのサービスのアップグレードが必要であることが記されている場合があります。 これは、たとえば、下位互換性モードで動作できないサービスに適用されます。
このような場合は、ファームを短時間だけオフラインにして、ファーム全体ではなく、そのサービスのみをアップグレードできます。 特定のサービス アプリケーションをアップグレードするための追加の PowerShell コマンドレットが必要な場合には、そのことがメモに明記されます。
(省略可能)PowerShell Upgrade-SPContentDatabase コマンドレットを使用して、各コンテンツ データベースをアップグレードします。 詳しくは、「 Upgrade-SPContentDatabase」を参照してください。
これは省略可能な手順ですが、すべてのコンテンツ データベースが最初にアップグレードされるようにするのに役立ちます。 いくつかの並行処理を有効にして停止時間を短縮できるという利点があります。 実行されていない場合、SharePoint 製品構成ウィザードを実行してファーム サーバーをアップグレードすると、アップグレードされていないコンテンツ データベースがすべてシリアルにアップグレードされます。
重要
Upgrade-SPContentDatabase コマンドレットは、データベースごとに実行します。 このコマンドレットは、アップグレード後の任意の Web サーバーまたはアプリケーション サーバーから実行できます。 この処理がデータベースで実行されている間は、データベースのコンテンツを使用できません。
サーバーの全体管理 サーバー (APP-1) で以下のいずれかを行います。
SharePoint 製品構成ウィザードを実行する
PowerShell コマンド プロンプトで次のコマンドを実行します。
cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources重要
SharePoint 製品構成ウィザードでは、構成データベースと、まだアップグレードされていない他のすべてのデータベースの即時アップグレードも開始されます。 前の手順で説明したように、コンテンツ データベースは既にアップグレードされている唯一のデータベースである可能性があるため、この手順では、すべてのサービス アプリケーション データベースもアップグレードされます。 このプロセスの実行中は、サイトを使用できません。
残りのアプリケーション サーバー (APP-2) で SharePoint 製品構成ウィザード または PSConfig (この操作の手順 4 と同様) を実行します。
Web サーバー (WEB-1 ～ WEB-4) で SharePoint 製品構成ウィザード または PSConfig (この操作の手順 4 と同様) を実行します。
更新が正常に完了したことを確認します。
詳細については、「 SharePoint 2013 でのデータベースのアップグレードの確認」、「 SharePoint Server 2016 でのデータベースアップグレードの確認」、「SharePoint Server2019 でのデータベースアップグレードの検証」、および「 SharePoint Server サブスクリプション エディションでのデータベースのアップグレードの確認 」を参照してください。
更新済みの Web サーバー (WEB-1 ～ WEB-4) を負荷分散のローテーションに戻します。
更新プログラムのインストールとこの記事の使用が完了しました。
データベース アタッチ方式を使用して既存コンテンツの高可用性を維持する
このシナリオでは、既存のコンテンツの高可用性を維持するために、既存のファームで読み取り専用データベースを使用します。 更新プログラムは新しいファームにインストールされ、ユーザー トラフィックはアップグレード完了後にその新しいファームにルーティングされます。
次の図に、データベース アタッチ方式を使用して、更新プログラムを新しいファームにインストールする一連の手順を示します。
詳細については、「 SharePoint 2013 から SharePoint Server 2016 へのコンテンツ データベースのアップグレード」、「 SharePoint 2016 から SharePoint Server 2019 へのデータベースのアップグレード」、および「 SharePoint Server 2019 および SharePoint Server 2016 から SharePoint Server サブスクリプション エディションへのデータベースのアップグレード」を参照してください。
次の操作の推奨手順を使用するときは、上記の図を参考にしてください。
データベース アタッチ方式を使用して、更新プログラムをインストールするには
ソフトウェア更新プログラムをインストールする新しいファームを作成します。 このファームでは、フロントエンド Web サーバーは必要ありません。
詳細については、「データベース接続アップグレード用の SharePoint 2016 ファームの作成」、データベース接続アップグレード用の SharePoint Server 2019 ファームの作成、およびデータベース接続アップグレード用の SharePoint Server サブスクリプション エディション ファームの作成に関するページを参照してください。
注:
元のファームでデータベースをミラーリングしている場合は、新しいファームへのソフトウェア更新プログラムを展開した後、ミラーリングを構成します。
既存のファームのデータベースを読み取り専用に構成します。
注:
既存のファームをミラーリングしている場合は、データベースを読み取り専用に設定する前に、ミラーリングを一時停止してください。
読み取り専用データベースを構成する方法の詳細については、「 SharePoint 2013 から SharePoint Server 2016 にコンテンツ データベースをアップグレードし、SharePoint Server 2016 で 読み取り専用データベースを使用するファームを実行する」の「以前のバージョンのデータベースを Read-Only に設定する (Read-Only データベースを使用してデータベースをアタッチする)」セクションを参照してください。
既存のファームにあるサービス アプリケーションのデータベースを読み取り専用に構成します。 こうすることで、予期しない変更がサービス アプリケーションに行われるのを防止します。
注:
手順 4 から 13 は、SharePoint Foundation 2013、SharePoint Server 2016、SharePoint Server 2019、および SharePoint Server サブスクリプション エディションには適用されません。
User Profile Service サービス アプリケーション データベースに修正プログラムを適用する場合は、ユーザー プロファイル同期サービスの暗号化キーを古いデータベースからエクスポートし、そのキーを新しいデータベースにインポートする必要があります。 このキーは Microsoft Identity Integration Server (MIIS) キー、Synchronization Service 暗号化キー、Forefront Identity Manager 2010 (FIM 2010) キーとも呼ばれます。 キーをエクスポートしてから正しくインポートしないと、同期サービスは開始されません。 暗号化キーをエクスポートするには、以下の手順を実行します。
ファーム管理者の資格情報を使用して、古いユーザー プロファイル サービス サービス アプリケーション データベースを含むコンピューターにサインインします。
コマンド プロンプト ウィンドウを開き、次のフォルダーに移動します。
%Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\
次のコマンドを入力し、Enter キーを押します。
/e<Path をmiiskmu.exe します>
ここで、<Path> は、キーをエクスポートするファイルの完全パスです。
既存のファームのコンテンツ データベースをバックアップします。 詳細については、「SharePoint Server でのバックアップと回復を計画する」をご覧ください。
暗号化キーをインポートするには、次の手順を実行します。
ファーム管理者の資格情報を使用して、新しい User Profile Service サービス アプリケーション データベースを含むコンピューターにサインインします。
User Profile Synchronization Service の開始を試みます。 暗号化キーをまだインポートしていないため、サービスは開始されません。 ULS ログを使用するか、サービスの状態が [停止] になっていることを確認して、サービスが開始されなかったことを確認します。
コマンド プロンプト ウィンドウを開き、次のフォルダーに移動します。
%Program Files%\Microsoft Office Servers\15.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 2013 から SharePoint Server 2016 へのデータベースのアップグレード」および「SharePoint Serverで読み取り専用コンテンツ データベースをアタッチおよび復元する」を参照してください。
新しいファームに問題がないことを確認します。
DNS が新しいファームを指すように構成するか、新しいファームが負荷分散されるようにすることで、新しいファームを運用ファームとして有効にします。 ユーザーが新しいファームにアクセスできることを確認します。
ユーザーがキャッシュされた DNS から切り替える時間を取り、その後で古いファームを使用不可にします。
更新が正常に完了したことを確認します。 詳細については、「 SharePoint 2016 でデータベースのアップグレードを確認する」を参照してください。
更新プログラムのインストールとこの記事の使用が完了しました。
検索コンポーネントをホストするサーバーにソフトウェアの更新プログラムをインストールする
このセクションの手順は、この記事の他の手順から参照されている場合にのみ実行します。 これには、このセクションに含まれる次の手順が含まれます。
検索コンポーネントをホストするサーバーをファームのダウンタイムに更新する
検索コンポーネントをホストするサーバーを最小のダウンタイムで更新する
最小のダウンタイムで更新するためのサーバー可用性グループを判別する
検索コンポーネントをホストするサーバーをファームのダウンタイムに更新する
PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを一時停止します。
$ssa=Get-SPEnterpriseSearchServiceApplication Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa1 つまたは複数の検索コンポーネントをホストする各サーバーで、検索関連の Windows サービスを次の順序で停止します。
SPTimerV4
OSearch16
SPSearchHostController
重要
各サービスが停止したことを確認してから、次のサービスを停止するようにしてください。
1 つまたは複数の検索コンポーネントをホストする各サーバーで、更新プログラムの実行ファイルを実行して、更新プログラムをインストールします。
1 つまたは複数の検索コンポーネントをホストする各サーバーで、検索関連の Windows サービスを次の順序で開始します。
SPSearchHostController
OSearch16
SPTimerV4
PowerShell コマンド プロンプトで次のコマンドを入力し、更新後、すべての検索コンポーネントがアクティブになったことを確認します。
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -ne "Active"} | fl出力に検索コンポーネントがまったく表示されなくなるまで、コマンドを再実行します。
PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを再開します。
Resume-SPEnterpriseSearchServiceApplication -Identity $ssa更新されたコンテンツをファームがクロールしており、新規または変更された文書のインデックスを作成できることを確認します。 これを行うため、サイト コレクション内の項目を追加または変更し、ローカルの SharePoint サイトのコンテンツ ソースのクロールを実行してからその項目の検索を実行し、これが検索結果に現れることを確認します。
検索コンポーネントをホストするサーバーを最小のダウンタイムで更新する
検索コンポーネントをホストするサーバーを 2 つの可用性グループに分け、その更新とビルドからビルドへのアップグレードの実行中に発生するダウンタイムを最小化します。 (いずれかのグループがアクティブで正常である限り、ファームはクエリを処理し、クロールとインデックスのコンテンツを提供できます)。サーバーを 2 つの可用性グループに分割する方法については、この記事の後半の「 最小限のダウンタイムで更新するサーバー可用性グループを決定する 」の手順を参照してください。
PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを一時停止します。
Suspend-SPEnterpriseSearchServiceApplication -Identity $ssaサーバー可用性グループ 1 の各サーバーで、Search 関連の Windows サービスを以下の順序で停止します。
SPTimerV4
OSearch16
SPSearchHostController
重要
各サービスが停止したことを確認してから、次のサービスを停止するようにしてください。
可用性グループ 1 の各サーバーで更新プログラムの実行ファイルを実行し、更新プログラムをインストールします。
可用性グループ 2 の各サーバーで、Search 関連の Windows サービスを可用性グループ 1 で指定されたのと同じ順序で停止します。 ここでも、次のサービスを停止する前に、各サービスが停止されていることを確認することが重要です。
可用性グループ 1 の各サーバーで、Search 関連の Windows サービスを以下の順序で開始します。
SPSearchHostController
OSearch16
SPTimerV4
可用性グループ 1 に関連するすべての検索コンポーネントがアクティブになるまで待ちます。 アクティブなコンポーネントを調べるには、PowerShell コマンド プロンプトで次のコマンドを入力します。
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl可用性グループ 1 に関連するすべての検索コンポーネントが出力に表示されるようになるまで、コマンドを再実行します。
可用性グループ 2 の各サーバーで更新プログラムの実行ファイルを実行し、更新プログラムをインストールします。
可用性グループ 2 の各サーバーで、Search 関連の Windows サービスを可用性グループ 1 で指定されたのと同じ順序で開始します。
可用性グループ 2 に関連するすべての検索コンポーネントがアクティブになるまで待ちます。 アクティブなコンポーネントを調べるには、PowerShell コマンド プロンプトで次のコマンドを入力します。
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl可用性グループ 2 に関連するすべての検索コンポーネントが出力に表示されるようになるまで、コマンドを再実行します。
PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを再開します。
Resume-SPEnterpriseSearchServiceApplication -Identity $ssa更新されたコンテンツをファームがクロールしており、新規または変更された文書のインデックスを作成できることを確認します。 これを行うため、サイト コレクション内の項目を追加または変更し、ローカルの SharePoint サイトのコンテンツ ソースのクロールを実行してからその項目の検索を実行し、これが検索結果に現れることを確認します。
最小のダウンタイムで更新するためのサーバー可用性グループを判別する
ファーム内の任意のサーバーで SharePoint 管理シェルを起動します。
PowerShell コマンド プロンプトで以下のコマンドを入力し、プライマリ検索管理コンポーネントと、そのコンポーネントをホストするサーバーを判別します。
$ssa=Get-SPEnterpriseSearchServiceApplication Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where { (($_.State -ne "Unknown") -and ($_.Name -match "Admin")) } | ForEach {if (Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Component $_.Name -Primary) { Get-SPEnterpriseSearchTopology -SearchApplication $ssa -active | Get-SPEnterpriseSearchComponent -identity $($_.Name) } }可用性グループ 1 に含めるサーバーのセットを決定します。 これらのサーバーは以下の 3 つの要件を満たす必要があります。
セットには、以下の種類の検索コンポーネントを 1 つ以上含める必要があります。ただし、全部含めてはなりません。
コンテンツ処理コンポーネント
クエリ処理コンポーネント
分析処理コンポーネント
クロール コンポーネント
インデックス コンポーネント
セットには、インデックス パーティションにつき 1 つ以上のインデックス コンポーネントを含める必要があります。ただし、全部含めてはなりません。
このセットには、この手順の手順 2 で識別された主要なコンポーネントではない Search 管理コンポーネントが含まれている必要があります。
可用性グループ 2 内のサーバーのセットを決定します。 このセットには、この手順の手順 2 で識別されたプライマリ Search 管理コンポーネントをホストするサーバーを含め、Search コンポーネントをホストする残りのサーバーがすべて含まれている必要があります。
分散キャッシュをホストするサーバーにソフトウェア更新プログラムをインストールする
サーバーを再起動してソフトウェア更新プログラムまたは構成ウィザードを実行する前に、分散キャッシュを停止して、未割り当てキャッシュの割合を防ぐ必要があります。 ここに記載されているプロセスに従って、分散キャッシュを正常にシャットダウンします。
重要
SharePoint Server 2013、SharePoint Server 2016、および SharePoint Server 2019 では、キャッシュがファーム内の別のサーバーに転送される前に分散キャッシュが終了するため、 Stop-SPDistributedCacheServiceInstance -Graceful は使用しないでください。 ただし、 Stop-SPDistributedCacheServiceInstance -Graceful は SharePoint Server サブスクリプション エディションに使用できます。
Search コンポーネントをホストするサーバー上のソフトウェア更新プログラムのトラブルシューティング
発行： 更新後、適切なレジストリ キーまたはファイル システムのアクセス許可がなくなった可能性があります。
解決策: 次のコマンドを実行します。
Initialize-SPResourceSecurity