SharePoint Server 用のソフトウェア更新プログラムをインストールする

[アーティクル]
04/07/2023

適用対象: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

開始する前に

ソフトウェア更新プロセスを開始する前に、必要な権限、ハードウェア要件、ソフトウェア要件、および更新プロセスに関する以下の情報を確認してください。

注:

この記事の手順は 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 2016 へのアップグレードをテストしてトラブルシューティングする

更新方法を決定する

ソフトウェア更新プログラムの展開を開始する前に、使用する予定の更新戦略が 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 サーバーをオフラインにし、修正プログラムを適用し、オンラインに戻すという操作をどのように行うを示しています。各アプリケーションサーバーで SharePoint 製品構成ウィザードを実行し、続いて各フロントエンド Web サーバーで SharePoint 製品構成ウィザードを実行します。

下位互換性のない更新プログラムをインストールするには

更新プログラムのインストール中にファームを使用できないことをユーザーに通知します。
すべての 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 つのフェーズを使用して、ファームサーバーに更新プログラムをインストールします。これらのフェーズは次のとおりです。

ファームサーバーに更新プログラムをインストールします。
ビルドからビルドへのアップグレードを実行し、更新プログラムの適用処理を完了します。

重要

更新フェーズ中、ファームは、最小限のダウンタイムで運用を続行できます。ただし、ビルドからビルドへのアップグレードフェーズ中は使用できません。ファームのアップグレード中に、ユーザーがコンテンツにアクセスを試みると、リソースの競合とロックが原因で、アップグレードが失敗したり、アップグレード処理が極端に低速になったりする可能性があります。このようなアクセス試行のテストは現段階では未実施で、サポートしていません。

詳細については、次のトピックを参照してください。

更新フェーズ

次の図に、ファームに更新プログラムをインストールするのに必要な手順を示します。この図は、次の操作 (「更新プログラムをインストールするには」) の各手順を実行する際に参照できます。

下位互換性のある一括手法を採用すると、Web サーバーの半分をオフラインにし、それらに修正プログラムを適用し、オンラインに戻し、続いて残りの Web サーバーにも同じ操作を行うという処理がどのように進行するかを示しています。このステップでは SharePoint 製品構成ウィザードは実行されません。

更新プログラムをインストールするには

半分の 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 Server 2019 でのデータベースアップグレードの検証」、および「 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) キーとも呼ばれます。キーをエクスポートしてから正しくインポートしないと、同期サービスは開始されません。暗号化キーをエクスポートするには、以下の手順を実行します。
1. ファーム管理者の資格情報を使用して、古いユーザープロファイルサービスサービスアプリケーションデータベースを含むコンピューターにサインインします。
2. コマンドプロンプトウィンドウを開き、次のフォルダーに移動します。
  
  %Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\
3. 次のコマンドを入力し、Enter キーを押します。
  
  /e<Path をmiiskmu.exe します>
  
  ここで、<Path> は、キーをエクスポートするファイルの完全パスです。
既存のファームのコンテンツデータベースをバックアップします。詳細については、「SharePoint Server でのバックアップと回復を計画する」をご覧ください。
暗号化キーをインポートするには、次の手順を実行します。
1. ファーム管理者の資格情報を使用して、新しい User Profile Service サービスアプリケーションデータベースを含むコンピューターにサインインします。
2. User Profile Synchronization Service の開始を試みます。暗号化キーをまだインポートしていないため、サービスは開始されません。 ULS ログを使用するか、サービスの状態が [停止] になっていることを確認して、サービスが開始されなかったことを確認します。
3. コマンドプロンプトウィンドウを開き、次のフォルダーに移動します。
  
  %Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\
4. 次のコマンドを入力し、Enter キーを押します。
  
  miiskmu.exe /i<Path>{0E19E162-827E-4077-82D4-E6ABD531636E}
  
  ここで、<Path> は、キーをエクスポートしたファイルの完全パスです。
5. (オプション) 暗号化キーが正しくインポートされたことを確認するには、コマンドプロンプトで次のコマンドを入力し、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 $ssa
```
1 つまたは複数の検索コンポーネントをホストする各サーバーで、検索関連の Windows サービスを次の順序で停止します。
1. SPTimerV4
2. OSearch16
3. SPSearchHostController
重要

各サービスが停止したことを確認してから、次のサービスを停止するようにしてください。
1 つまたは複数の検索コンポーネントをホストする各サーバーで、更新プログラムの実行ファイルを実行して、更新プログラムをインストールします。
1 つまたは複数の検索コンポーネントをホストする各サーバーで、検索関連の Windows サービスを次の順序で開始します。
1. SPSearchHostController
2. OSearch16
3. 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 サービスを以下の順序で停止します。
1. SPTimerV4
2. OSearch16
3. SPSearchHostController
重要

各サービスが停止したことを確認してから、次のサービスを停止するようにしてください。
可用性グループ 1 の各サーバーで更新プログラムの実行ファイルを実行し、更新プログラムをインストールします。
可用性グループ 2 の各サーバーで、Search 関連の Windows サービスを可用性グループ 1 で指定されたのと同じ順序で停止します。ここでも、次のサービスを停止する前に、各サービスが停止されていることを確認することが重要です。
可用性グループ 1 の各サーバーで、Search 関連の Windows サービスを以下の順序で開始します。
1. SPSearchHostController
2. OSearch16
3. 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
```

次の方法で共有

SharePoint Server 用のソフトウェア更新プログラムをインストールする

開始する前に

更新方法を決定する

インストールの進行状況を監視する

初期状態