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

適用対象: yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seサブスクリプション エディション no-img-sopMicrosoft 365 の SharePoint

はじめに

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

注意

この記事の手順は SharePoint Server 2016 を参照していますが、特に明記されていない限り、SharePoint Foundation 2013、SharePoint Server 2013、SharePoint Server 2019 に適用されます。

この記事の手順を実行するには、以下のメンバーシップとロールが必要です。

  • SQL Server インスタンスの securityadmin 固定サーバー ロール

  • 更新するすべてのデータベースの db_owner 固定データベース ロール

  • Microsoft PowerShell コマンドレットを実行するサーバーのローカル管理者

更新プログラムをインストールする前に、次の条件を満たしていることを確認します。

  • すべてのフロントエンド Web サーバーがロード バランサーで負荷分散され、ローテーションで運用されている。

  • すべてのファーム サーバーが適切に動作している。検索に関するサーバーの状態は、Microsoft PowerShell コマンドレット Get-SPEnterpriseSearchStatus を使用するか、サーバーの全体管理 > [サービス アプリケーションの管理] > [ Search_service_application_name] にアクセスすれば表示できます。

  • すべてのデータベースがアクティブで、適切に動作している。

上記の条件を 1 つでも満たしていない場合は、更新プログラムを起動しないでください。すべての問題を解決してから続行します。

SharePoint Server 2016 では、更新プログラムの適用フェーズの終了後に一部のアップグレード エラーを処理できます。しかし、ビルドからビルドへのアップグレードが失敗した場合は、バックアップからの復元を行わなければならない可能性があります。したがって、更新プロセスを開始する前に完全バックアップを必ず実行してください。復元が完了したら、更新を再開できます。その時点で既に完了しているタスクは再度実行されません。詳細については、以下を参照してください。

更新方法を決定する

ソフトウェア更新プログラムの展開を開始する前に、使用予定の更新戦略が SharePoint Server 2016 環境に最適であることを確認します。 ダウンタイムの短縮、コスト、複雑さなどいくつかの判断材料を基に、ソフトウェア更新プログラムの展開方法を決定します。 データベース接続プロセスのしくみの詳細については、「 SharePoint 2013 から SharePoint Server 2016 へのアップグレード プロセスの概要」の図を参照してください。

注意

この記事のリンクの中には、ビルドからビルドへのアップグレードではなく、バージョンからバージョンへのアップグレードについて扱ったコンテンツに移動するものがあります。しかし、これらの 2 種類のアップグレードの一般的なプロセスは類似しています。 たとえば、データベースのアップグレードのフェーズは、ビルドからビルドへのアップグレードでもバージョンからバージョンへのアップグレードでも基本的に同じです。

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

更新プログラムの展開処理を監視して、更新が予定どおりに進んでいることを確認します。問題が発生して処理が中断したり、更新後のファーム内の要素が期待どおりに機能しないことがあります。データベースの同期とカスタマイズには特に注意が必要です。

サーバーの全体管理 の [ アップグレードと移行] ページを使用して、製品および更新プログラムのインストールの状態、データの状態、およびアップグレードの状態をリアルタイムで確認することをお勧めします。

セットアップの実行後、ログ ファイルを表示し、Microsoft PowerShell を使用してインストールの進行状況を確認することもできます。

初期状態

次の図に、この記事の更新プログラムの適用シナリオの例で使用するファーム トポロジを示します。

修正プログラム適用のためのファーム トポロジの例を示しています

続行する準備ができたら、この記事に挙げる以下の手順の中から 1 つだけを実行して、更新プログラムをインストールします。

  • 下位互換性のないインプレース方式を使用する

  • 下位互換性のあるインプレース方式を使用する

  • データベース アタッチ方式を使用して既存コンテンツの高可用性を維持する

下位互換性のないインプレース方式を使用する

このシナリオでは、フロントエンド Web サーバーへの着信要求を無効にしてファーム全体を効率的にシャットダウンします。 次いで、すべてのファーム サーバーに更新プログラムをインストールします。 この戦略は、 SharePoint 2013 から SharePoint Server 2016 へのアップグレード プロセスの概要の「SharePoint Server 2016 のソフトウェア更新プログラムの概要 」セクションで説明されている更新プログラムとビルド間 アップグレード フェーズを組み合わせたものです。

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

各フロントエンド Web サーバーをオフラインにし、修正プログラムを適用し、オンラインに戻すという操作をどのように行うを示しています。各アプリケーション サーバーで SharePoint 製品構成ウィザードを実行し、続いて各フロントエンド Web サーバーで SharePoint 製品構成ウィザードを実行します。

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

  1. 更新プログラムのインストール中はファームが使用できなくなることをユーザーに通知しておきます。

  2. すべての Web サーバー (WEB-1 ~ WEB-4) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。

  3. 更新プログラムの実行ファイルを実行して、サーバーの全体管理 をホストするアプリケーション サーバー (APP-1) に更新プログラムをインストールします。

  4. 更新プログラムの実行ファイルを実行して、検索コンポーネントをホストする他のすべてのアプリケーション サーバー (APP-2) に更新プログラムをインストールします。 これを行うには、この記事の後半に記載されている Host Search コンポーネント の手順を実行し、この手順の次の手順に戻ります。 この時点では、SharePoint 製品の構成ウィザードをこれらのサーバーに対して実行しないでください。

  5. アップグレード ログ ファイルを調べて、アプリケーション サーバーがすべて正常に更新されたことを確認します。

    アップグレード ログ ファイルとアップグレード エラー ログ ファイルは、%COMMONPROGRAMFILES%\Microsoft Shared\Web サーバー拡張機能\16\LOGS にあります。 アップグレード ログ ファイル名の形式は、Upgrade-YYYYMMDD-HHMMSS-SSS.log です。 ここで、YYYYMMDDD は日付であり、 HHMMSS-SSS は時刻 (24 時間のクロック形式の時間、分、秒、ミリ秒) です。 アップグレード エラー ログ ファイルは、Upgrade-YYYYMMDD-HHMMSS-SSS-error.log という名前の短いファイル内のすべてのエラーと警告を結合します。

  6. 1 番目の Web サーバー (WEB-1) にログオンします。

  7. 実行ファイルを実行して、この Web サーバーに更新プログラムをインストールします。

  8. 実行ファイルを実行して、残りの Web サーバー (WEB-2、WEB-3、および WEB-4) に更新プログラムをインストールします。

  9. アップグレード ログ ファイルを調べて、Web サーバーがすべて正常に更新されたことを確認します。

  10. サーバーの全体管理 (APP-1) で SharePoint 製品構成ウィザードを実行します。 これにより、構成データベースがアップグレードされ、各コンテンツ データベースがアップグレードされます。 ウィザードの実行方法については、「3 層ファームの 複数のサーバーに SharePoint 2013 をインストール する」の記事で、 複数のサーバーに SharePoint Server 2016 をインストールする方法に関する記事を参照してください。

  11. 他のアプリケーション サーバーで SharePoint 製品構成ウィザード を実行します。

  12. 1 番目の Web サーバーで SharePoint 製品構成ウィザード を実行します。

    注意

    特定のサーバーで更新プログラムが失敗した場合に、そのエラーが他の Web サーバーに伝播していないことを、構成ウィザードを実行して確認します。たとえば、1 台のサーバーで更新が失敗すると、1 つ以上のサイト コレクションで更新が失敗することがあります。

  13. 上記の手順を残りの各 Web サーバーに対して繰り返します。

  14. 更新が正常に完了したことを確認します。 詳細については、「 SharePoint Server 2016 でデータベースのアップグレードを確認する」を参照してください。

  15. Web サーバー (WEB-1 ~ WEB-4) をロード バランサーのローテーションに戻すか、ロード バランサーを再開してサーバーへの着信要求を有効にします。

  16. ファームが使用可能であることをユーザーに通知します。更新プログラムのインストールは終了しました。記事の内容の実行もこれで終わりです。

下位互換性のあるインプレース方式を使用する

このシナリオでは、SharePoint の下位互換性と遅延アップグレード機能を利用して、ソフトウェア更新プログラムの展開に必要なファームダウンタイムを削減します。 ただし、ダウンタイムは完全にはなくなりません。 データベース コンテンツのアップグレード中は、サイトとサービスを使用できません。

この更新シナリオでは、2 つのフェーズを使用して、ファーム サーバーに更新プログラムをインストールします。これらのフェーズは次のとおりです。

  1. ファーム サーバーに更新プログラムをインストールします。

  2. ビルドからビルドへのアップグレードを実行し、更新プログラムの適用処理を完了します。

重要

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

詳細については、「 SharePoint 2013 から SharePoint Server 2016 へのアップグレード プロセスの概要」の「SharePoint Server 2016 のソフトウェア更新プログラムの概要」セクションを参照してください。

更新フェーズ

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

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

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

  1. 半分の Web サーバー (WEB-1 と WEB-2) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。

  2. 負荷分散のローテーションから外した各 Web サーバー (WEB-1 と WEB-2) で実行ファイルを実行して、更新プログラムをインストールします。これらのサーバーで SharePoint 製品構成ウィザード を実行しないでください。更新ログ ファイルを調べて、これらの Web サーバーが正常に更新されたことを確認します。

    アップグレード ログ ファイルとアップグレード エラー ログ ファイルは、%COMMONPROGRAMFILES%\Microsoft Shared\Web サーバー拡張機能\16\LOGS にあります。 アップグレード ログ ファイル名の形式は、Upgrade-YYYYMMDD-HHMMSS-SSS.log です。 ここで、YYYYMMDDD は日付であり、 HHMMSS-SSS は時刻 (24 時間のクロック形式の時間、分、秒、ミリ秒) です。 アップグレード エラー ログ ファイルは、Upgrade- YYYYMMDD-HHMMSS-SSS-error.log という名前の短いファイル内のすべてのエラーと警告を結合します。

  3. 残りの Web サーバー (WEB-3 と WEB-4) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。

  4. 更新済みの Web サーバー (WEB-1 と WEB-2) を負荷分散のローテーションに戻します。

  5. 負荷分散のローテーションから外した各 Web サーバーで実行ファイルを実行して、更新プログラムをインストールします。この時点ではこれらのサーバーで SharePoint 製品構成ウィザード を実行しないでください。更新ログ ファイルを調べて、Web サーバーが両方とも正常に更新されたことを確認します。

  6. 更新済みの Web サーバー (WEB-3 と WEB-4) を負荷分散のローテーションに戻します。

  7. 検索コンポーネントをホストするすべてのアプリケーション サーバー (APP-1 と APP-2) で更新プログラムをインストールします。 これを行うには、この記事の後半に記載されている SharePoint Server 2016 のソフトウェア更新プログラムをインストール する手順を実行し、この手順の次の手順に戻ります。 この時点では SharePoint 製品構成ウィザード を実行しないでください。

  8. 検索コンポーネントをホストしない追加のアプリケーション サーバーがファームにある場合、それらのサーバーで更新プログラムの実行ファイルを実行して、更新プログラムをインストールします。この時点ではこれらのサーバーで SharePoint 製品構成ウィザード を実行しないでください。

  9. 更新ログ ファイルを調べて、これらのアプリケーション サーバーが正常に更新されたことを確認します。

この時点では、どのファーム サーバーでも SharePoint 製品構成ウィザード を実行していないため、データベースとその他の構成要素 (設定、機能、サイトレベルのデータなど) をアップグレードする必要が残っています。ただし、ファームは、下位互換性モードで実行できる必要があります。

アップグレード フェーズ

次の図に、ファーム サーバーをアップグレードすることにより、更新プログラムの適用処理を終了するのに必要な一連の手順を示します。この処理の実行中、ユーザーは、アップグレード中のサイトを使用できません。

一括ソフトウェア更新のアップグレード フェーズ中に使用する手順

次の操作の手順を使用するときは、上記の図を参考にしてください。

重要

各サーバーのアップグレードの状態を監視してから、次のサーバーのアップグレードに進みます。アップグレードを開始する前に、ファームをバックアップすることを強くお勧めします。

次の手順は、ファームをアップグレードするすべてのステップを示しています。機能が停止している間にすべてのコンポーネントをアップグレードすることも、停止時間を分割して各時間内にファームのパーツを個別にアップグレードすることもできます。アップグレードを段階的に行う場合は、次のコンポーネントを停止時間を分けてアップグレードできます。

  • サービス

    ソフトウェア更新プログラムに、適用する必要があるサービスへの更新が含まれている場合は、サービスのアップグレード後に、ファームの稼働を再開できます (次の操作の手順 8)。その後、ファームをさらに長い時間停止できる状況になったら、コンテンツとファームをアップグレードします。

  • コンテンツ データベース

    ファームを短時間停止して、その都度、少数のコンテンツ データベースをアップグレードできます (次の操作の手順 3 および 4)。その後、ファームの稼働を再開できます (次の操作の手順 8)。停止時間を継続的に設定してアップグレードを繰り返すことにより、最終的にすべてのコンテンツをアップグレードして、ファーム サーバーをアップグレードできる状態にします。

    また、コンテンツ データベース数がわずかであれば、各コンテンツ データベースを並行して同時にアップグレードすることもできます。ただし、コンテンツ データベースが大量にある場合は、並行してアップグレードしないでください。アップグレード処理全体が低速になり、それだけ停止時間が長くなります。同じ SQL Server ボリュームにあるコンテンツ データベースを一度に 3 つ以上アップグレードすることはお勧めできません。このような場合は、各コンテンツ データベースのアップグレードの開始時間を数分ずつずらして並行して行うようにして、アップグレード処理の開始時にロックが競合するのを回避します。また、単一の Web サーバーまたはアプリケーション サーバー上のアップグレード対象のコンテンツ データベースの数を制限します。追加のアップグレード処理が発生するたびに比較的多くのリソースが使用されます。一般に、1 台の Web サーバーまたはアプリケーション サーバーでアップグレードできるコンテンツ データベースの数は 4 つです。ただし、アップグレードを Web サーバーまたはアプリケーション サーバーのどちらのサーバーで開始する場合でも、各 SQL Server ボリュームでアップグレードするデータベースの制限数を超えないように注意してください。

ファームをアップグレードするには

  1. Web サーバー (WEB-1 ~ WEB-4) をロード バランサーのローテーションから外すか、ロード バランサーを一時停止してサーバーへの着信要求を停止します。

    重要

    サイトとサービスは、アップグレードが完了し、サーバーがアクティブな負荷分散状態に戻るまで使用できません。

  2. 必要に応じて、特定のサービスをアップグレードします。

    一部の更新では、追加の PowerShell コマンドレットを実行し、特定のサービス アプリケーションもアップグレードしなければならない場合があります。 ソフトウェアの更新に関する注意事項として、更新プログラムの適用後も特定のサービスを続行できるように、そのサービスをアップグレードする必要があることが明記されている場合があります。 これには、サービスを下位互換性モードで実行できない場合などが該当します。

    このような場合は、ファームを短時間だけオフラインにして、ファーム全体ではなく、そのサービスのみをアップグレードできます。 特定のサービス アプリケーションをアップグレードするための追加の PowerShell コマンドレットが必要な場合には、そのことがメモに明記されます。

  3. (省略可能)PowerShell Upgrade-SPContentDatabase コマンドレットを使用して、各コンテンツ データベースをアップグレードします。 詳しくは、「 Upgrade-SPContentDatabase」を参照してください。

    これは任意の手順ですが、最初にすべてのコンテンツ データベースをアップグレードできるので便利です。いくつかの並行処理を有効にして停止時間を短縮できるという利点があります。この手順を実行していない場合は、SharePoint 製品構成ウィザード を実行してファーム サーバーをアップグレードするときに、アップグレードされていない残りすべてのコンテンツ データベースが順次アップグレードされます。

    重要

    Upgrade-SPContentDatabase コマンドレットは、データベースごとに実行します。このコマンドレットは、アップグレード後の任意の Web サーバーまたはアプリケーション サーバーから実行できます。この処理がデータベースで実行されている間は、データベースのコンテンツを使用できません。

  4. サーバーの全体管理 サーバー (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 製品構成ウィザード は、構成データベースと、まだアップグレードされていない他のデータベースのアップグレードも即座に開始します。前の手順でも説明しましたが、この時点で既にアップグレードが済んでいるのは、通常はコンテンツ データベースのみです。サービス アプリケーションのデータベースはすべて、この手順でアップグレードされます。この処理の実行中はサイトを使用できません。

  5. 残りのアプリケーション サーバー (APP-2) で SharePoint 製品構成ウィザード または PSConfig (この操作の手順 4 と同様) を実行します。

  6. Web サーバー (WEB-1 ~ WEB-4) で SharePoint 製品構成ウィザード または PSConfig (この操作の手順 4 と同様) を実行します。

  7. 更新が正常に完了したことを確認します。詳細については、「SharePoint 2013 のデータベースのアップグレードを検証する」を参照してください。

  8. 更新済みの Web サーバー (WEB-1 ~ WEB-4) を負荷分散のローテーションに戻します。

    更新プログラムのインストールは終了しました。記事の内容の実行もこれで終わりです。

データベース アタッチ方式を使用して既存コンテンツの高可用性を維持する

このシナリオでは、既存のコンテンツの高可用性を維持するために、既存のファームで読み取り専用データベースを使用します。更新プログラムは新しいファームにインストールされ、ユーザー トラフィックはアップグレード完了後にその新しいファームにルーティングされます。

次の図に、データベース アタッチ方式を使用して、更新プログラムを新しいファームにインストールする一連の手順を示します。 詳細については、「 SharePoint 2013 から SharePoint Server 2016 へのコンテンツ データベースのアップグレード」を参照してください

既存コンテンツの高可用性を考慮し、データベース接続を使用してソフトウェア更新プログラムをインストールする

次の操作の推奨手順を使用するときは、上記の図を参考にしてください。

データベース アタッチ方式を使用して、更新プログラムをインストールするには

  1. ソフトウェア更新プログラムをインストールする新しいファームを作成します。 このファームには、フロントエンド Web サーバーは必要ありません。 詳細については、「 データベース接続のアップグレード用に SharePoint 2016 ファームを作成する」を参照してください。

    注意

    元のファームでデータベースをミラーリングしている場合は、新しいファームへのソフトウェア更新プログラムを展開した後、ミラーリングを構成します。

  2. 既存のファームのデータベースを読み取り専用に構成します。

    注意

    既存のファームをミラーリングしている場合は、データベースを読み取り専用に設定する前に、ミラーリングを一時停止してください。

    読み取り専用データベースを構成する方法の詳細については、「 SharePoint 2013 から SharePoint Server 2016 にコンテンツ データベースをアップグレードし、SharePoint Server読み取り専用データベースを使用するファームを実行する」の「以前のバージョンのデータベースをRead-Onlyに設定する (Read-Only データベースでデータベースをアタッチする)」セクションを参照してください。

  3. 既存のファームにあるサービス アプリケーションのデータベースを読み取り専用に構成します。こうすることで、予期しない変更がサービス アプリケーションに行われるのを防止します。

    注意

    手順 4 ~ 14 は、SharePoint Foundation 2013、SharePoint Server 2016、SharePoint Server 2019 には適用されません。

  4. User Profile Service サービス アプリケーション データベースにパッチを適用する場合は、古いデータベースからユーザー プロファイル同期サービス暗号化キーをエクスポートし、そのキーを新しいデータベースにインポートする必要があります。 このキーは Microsoft Identity Integration Server (MIIS) キー、Synchronization Service 暗号化キー、Forefront Identity Manager 2010 (FIM 2010) キーとも呼ばれます。 キーのエクスポートとインポートが正しく行われないと、Synchronization Service は開始しません。 暗号化キーをエクスポートするには、以下の手順を実行します。

    1. ファーム管理者の資格情報を使用して、古い User Profile Service サービス アプリケーション データベースが格納されているコンピューターにログオンします。

    2. コマンド プロンプト ウィンドウを開き、次のフォルダーに移動します。

      %Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\

    3. 次のコマンドを入力し、Enter キーを押します。

      miiskmu.exe /e <Path>

      キーをエクスポートするファイルの完全なパスはどこにありますか <Path>

  5. 既存のファームのコンテンツ データベースをバックアップします。 詳細については、「SharePoint Server でのバックアップと回復を計画する」をご覧ください。

  6. 暗号化キーをインポートするには、次の手順を実行します。

    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}

  7. コンテンツ データベースを新しいデータベース サーバーに復元します。

  8. 古いファームの既存のサービス アプリケーションごとに、新しいファームにサービス アプリケーションを作成します。

    既存のファームからすべての設定を複製します。

  9. データベース アタッチ方式を使用して、新しいファームにデータベースを作成します。 詳細については、「 SharePoint 2013 から SharePoint Server 2016 へのデータベースのアップグレード 」および「 SharePoint Server での読み取り専用コンテンツ データベースのアタッチと復元」を参照してください

  10. 新しいファームに問題がないことを確認します。

  11. DNS が新しいファームを指すように構成するか、新しいファームが負荷分散されるようにすることで、新しいファームを運用ファームとして有効にします。ユーザーが新しいファームにアクセスできることを確認します。

  12. ユーザーがキャッシュされた DNS から切り替える時間を取り、その後で古いファームを使用不可にします。

  13. 更新が正常に完了したことを確認します。 詳細については、「 SharePoint 2016 でのデータベースのアップグレードの確認」を参照してください。

    更新プログラムのインストールは終了しました。記事の内容の実行もこれで終わりです。

検索コンポーネントをホストするサーバーにソフトウェアの更新プログラムをインストールする

このセクションの操作は、この記事の他の操作で指示されている場合に限り、実行するようにしてください。これには、このセクションに記載されている以下の操作が含まれます。

  • 検索コンポーネントをホストするサーバーをファームのダウンタイムに更新する

  • 検索コンポーネントをホストするサーバーを最小のダウンタイムで更新する

  • 最小のダウンタイムで更新するためのサーバー可用性グループを判別する

検索コンポーネントをホストするサーバーをファームのダウンタイムに更新する

  1. PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを一時停止します。

    $ssa=Get-SPEnterpriseSearchServiceApplication
    Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  2. 1 つまたは複数の検索コンポーネントをホストする各サーバーで、検索関連の Windows サービスを次の順序で停止します。

    1. SPTimerV4

    2. OSearch16

    3. SPSearchHostController

    重要

    各サービスが停止したことを確認してから、次のサービスを停止するようにしてください。

  3. 1 つまたは複数の検索コンポーネントをホストする各サーバーで、更新プログラムの実行ファイルを実行して、更新プログラムをインストールします。

  4. 1 つまたは複数の検索コンポーネントをホストする各サーバーで、検索関連の Windows サービスを次の順序で開始します。

    1. SPSearchHostController

    2. OSearch16

    3. SPTimerV4

  5. PowerShell コマンド プロンプトで次のコマンドを入力し、更新後、すべての検索コンポーネントがアクティブになったことを確認します。

    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -ne "Active"} | fl
    

    出力に検索コンポーネントがまったく表示されなくなるまで、コマンドを再実行します。

  6. PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを再開します。

    Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  7. 更新されたコンテンツをファームがクロールしており、新規または変更された文書のインデックスを作成できることを確認します。これを行うため、サイト コレクション内の項目を追加または変更し、ローカルの SharePoint サイトのコンテンツ ソースのクロールを実行してからその項目の検索を実行し、これが検索結果に現れることを確認します。

検索コンポーネントをホストするサーバーを最小のダウンタイムで更新する

  1. 検索コンポーネントをホストするサーバーを 2 つの可用性グループに分け、その更新とビルドからビルドへのアップグレードの実行中に発生するダウンタイムを最小化します。(一方のグループがアクティブで正常である限り、ファームはクエリへの対応や、コンテンツのクロールとインデックス作成が可能です。) サーバーを 2 つの可用性グループに分ける方法については、この記事で後述する「最小のダウンタイムで更新するためのサーバー可用性グループを判別する」を参照してください。

  2. PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを一時停止します。

    Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  3. サーバー可用性グループ 1 の各サーバーで、Search 関連の Windows サービスを以下の順序で停止します。

    1. SPTimerV4

    2. OSearch16

    3. SPSearchHostController

    重要

    各サービスが停止したことを確認してから、次のサービスを停止するようにしてください。

  4. 可用性グループ 1 の各サーバーで更新プログラムの実行ファイルを実行し、更新プログラムをインストールします。

  5. 可用性グループ 2 の各サーバーで、Search 関連の Windows サービスを可用性グループ 1 で指定されたのと同じ順序で停止します。各サービスが停止したことを確認してから次のサービスを停止することはここでも重要です。

  6. 可用性グループ 1 の各サーバーで、Search 関連の Windows サービスを以下の順序で開始します。

    1. SPSearchHostController

    2. OSearch16

    3. SPTimerV4

  7. 可用性グループ 1 に関連するすべての検索コンポーネントがアクティブになるまで待ちます。アクティブなコンポーネントを調べるには、PowerShell コマンド プロンプトで次のコマンドを入力します。

    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
    

    可用性グループ 1 に関連するすべての検索コンポーネントが出力に表示されるようになるまで、コマンドを再実行します。

  8. 可用性グループ 2 の各サーバーで更新プログラムの実行ファイルを実行し、更新プログラムをインストールします。

  9. 可用性グループ 2 の各サーバーで、Search 関連の Windows サービスを可用性グループ 1 で指定されたのと同じ順序で開始します。

  10. 可用性グループ 2 に関連するすべての検索コンポーネントがアクティブになるまで待ちます。アクティブなコンポーネントを調べるには、PowerShell コマンド プロンプトで次のコマンドを入力します。

    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
    

    可用性グループ 2 に関連するすべての検索コンポーネントが出力に表示されるようになるまで、コマンドを再実行します。

  11. PowerShell コマンド プロンプトで以下のコマンドを入力して、Search Service アプリケーションを再開します。

    Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  12. 更新されたコンテンツをファームがクロールしており、新規または変更された文書のインデックスを作成できることを確認します。これを行うため、サイト コレクション内の項目を追加または変更し、ローカルの SharePoint サイトのコンテンツ ソースのクロールを実行してからその項目の検索を実行し、これが検索結果に現れることを確認します。

最小のダウンタイムで更新するためのサーバー可用性グループを判別する

  1. ファーム内の任意のサーバーで SharePoint 2016 Management Shell を起動します。

  2. 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) } }
    
  3. 可用性グループ 1 に含めるサーバーのセットを決定します。これらのサーバーは以下の 3 つの要件を満たす必要があります。

    • セットには、以下の種類の検索コンポーネントを 1 つ以上含める必要があります。ただし、全部含めてはなりません。

    • コンテンツ処理コンポーネント

    • クエリ処理コンポーネント

    • 分析処理コンポーネント

    • クロール コンポーネント

    • インデックス コンポーネント

    • セットには、インデックス パーティションにつき 1 つ以上のインデックス コンポーネントを含める必要があります。ただし、全部含めてはなりません。

    • セットには、検索管理コンポーネントを 1 つ含める必要があります。ただし、これは、この操作の手順 2 で識別されたプライマリ コンポーネントであってはなりません。

  4. 可用性グループ 2 に含めるサーバーのセットを決定します。このセットには、検索コンポーネントをホストする残りのすべてのサーバーを含める必要があります。これには、この操作の手順 2 で識別された、プライマリ検索管理コンポーネントをホストするサーバーが含まれます。

分散キャッシュをホストするサーバーにソフトウェア更新プログラムをインストールする

サーバーを再起動してソフトウェア更新プログラムまたは構成ウィザードを実行する前に、分散キャッシュを停止して、未割り当てのキャッシュ分数を防ぐ必要があります。 ここに記載されているプロセスに従って、分散キャッシュを正常にシャットダウンします。

重要

これは、キャッシュがファーム内の別のサーバーに転送される前に分散キャッシュを終了するため、使用 Stop-SPDistributedCacheServiceInstance -Graceful しないでください。

検索コンポーネントをホストするサーバー上のソフトウェア更新プログラムのトラブルシューティング

  • 問題: 更新の後に、適切なレジストリ キーまたはファイル システムのアクセス許可を失っていることがあります。

  • 解決策: 次のコマンドを実行します。

    Initialize-SPResourceSecurity
    

関連項目

その他のリソース

SharePoint 更新プログラム