SharePoint Server 2016、2019、およびサブスクリプション エディションのソフトウェア更新プログラムの概要
適用対象:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
管理者は SharePoint Server 2016、2019、または Subscription Edition を更新して、機能を提供するアセンブリを展開または更新し、データベースをアップグレードします。 正常な更新プロセスは、系統だったアプローチに従うので、サービスの中断を最小限に抑えられます。 更新プロセスを始める前に、プロセスの詳細についてこの記事の情報を確認してください。
注:
この記事は、SharePoint Server 2016、2019、およびサブスクリプション エディションに適用されます。
ソフトウェアの更新を開始する前に
ソフトウェアの更新プロセスを始める前に、必要な権限、ハードウェア要件、およびソフトウェア要件に関する以下の情報を確認してください。
この記事の情報は、SharePoint Server 2016、2019、またはサブスクリプション エディションを管理するすべての IT プロフェッショナル向けです。 ただし、ソフトウェア更新プログラムをインストールするための具体的な手順は、SharePoint Server 2016、2019、またはサブスクリプション エディションをホストするサーバーのファームにソフトウェア更新プログラムを展開する必要がある IT プロフェッショナルを対象としています。
この記事の情報は、次の製品に適用されます。
SharePoint Server 2016
SharePoint Server 2016 言語パック
SharePoint Server 2019
SharePoint Server 2019言語パック
SharePoint Server Subscription Edition
SharePoint Server サブスクリプション エディション言語パック
注:
SharePoint Server 2016、2019、または Subscription Edition のスタンドアロン環境にソフトウェア更新プログラムをインストールするプロセスは、サーバー ファームにソフトウェア更新プログラムをインストールするプロセスよりも簡単なプロセスであり、サーバー ファームに必要なすべての手順は必要ありません。
Microsoft は、毎月パブリック 更新をリリースします。 最初の更新プログラムは、言語に依存しない更新プログラムと呼ばれます。 この更新プログラムには、多くの場合、機能とセキュリティの両方の修正プログラムが含まれます。 "sts-x-none" パッチとも呼ばれます。
2 番目の種類のパッチは、言語に依存するパッチです。 このパッチは、英語のインストールを含むすべての言語パックを対象とします。 このパッチは、ファームを完全に更新するために必要ですが、毎月リリースされるわけではありません。 このパッチは、"wssloc" パッチとも呼ばれます。
注:
2023 年 3 月から、Microsoft は、以前にリリースされていたすべての修正プログラムを含む SharePoint Server サブスクリプション エディション 用の単一の "uber" パッチをリリースします。このパッチは、それらの個別の 'sts-x-none' パッチと 'wssloc' パッチでリリースされました。
重要
言語依存パッチが特定の月に使用できない場合は、以前に利用可能だった最新の言語依存パッチに更新します。 たとえば、2019 年 7 月のパブリック更新プログラム for SharePoint Server 2016 を適用する場合は、2019 年 7 月の言語に依存しない更新プログラムと、2019 年 4 月からの言語依存パッチをインストールします。 言語依存のパッチをインストールしない場合は、機能が見つからないか正しくない可能性があります。
ソフトウェア更新に関する用語
SharePoint Server 2016、2019、Subscription Edition でソフトウェア更新プログラムを実装する方法を理解するには、コア コンポーネントの用語を理解することが重要です。
| 用語 |
定義 |
コメント |
|---|---|---|
| パブリック更新プログラム (PU) |
PU は過去から現在までの重要なオンデマンドのホットフィックスがすべて含まれているロールアップ更新プログラムです。 また PU には、ホットフィックスの承認条件を満たす問題に対する修正プログラムも含まれます。 この条件には、回避策を使用できるかどうか、お客様への影響、問題を再現できるかどうか、変更を加える必要があるコードの複雑さなどの理由があります。 |
|
| パッチ |
1 つ以上の製品に対する更新プログラムが含まれるコンパイル済みの実行可能インストーラー ファイルです。 パッケージの例としては、サービス パック、パブリック更新プログラム (PU)、またはホットフィックスをインストールする目的でダウンロードする実行可能 (.exe) ファイルがあります。 パッケージは、MSI ファイルとも呼ばれます。 |
|
| ソフトウェア更新プログラム |
ソフトウェア更新プログラムとは、Microsoft Corporation がリリースするソフトウェア製品の改善や修正に使用する更新プログラム、ロールアップ更新プログラム、サービス パック、機能パック、重要な更新プログラム、セキュリティ更新プログラム、ホットフィックスのことです。 |
|
| アップグレード |
新しいバージョンのソフトウェアを使用するように環境を変更するプロセスのことです。 更新プログラムやパッチなどのマイナー リリースにも、メジャー リリースにもアップグレードできます。 マイナー リリースへのアップグレードは、ビルドからビルドへのアップグレードと呼ばれます。 メジャー リリースへのアップグレードは、バージョンからバージョンへのアップグレードと呼ばれます。 |
SharePoint Server 2016 では、ビルドからビルドへのアップグレードの場合、一括方式かデータベース接続方式を選択できます。 バージョンからバージョンへのアップグレードの場合、データベース接続のみサポートされます。 バージョンからバージョンへのアップグレードの詳細については、「SharePoint Server 2016 へのアップグレード プロセスの概要」、「SharePoint Server 2019へのアップグレード プロセスの概要」、および「SharePoint Server サブスクリプション エディションへのアップグレード プロセスの概要」を参照してください。 ビルドからビルドへのアップグレードのインプレースアップグレードとデータベースアタッチアップグレードの手順の概要については、「SharePoint Server 2016、2019、Subscription Edition 用のソフトウェア更新プログラムをインストールする」を参照してください。 |
ソフトウェア更新プログラムに関する用語の完全な一覧については、「マイクロソフトのソフトウェアの更新で使用される一般的な用語の説明」を参照してください。
ソフトウェア更新機能
SharePoint Server 2016、2019、Subscription Edition には、エンドツーエンドのソフトウェア更新エクスペリエンスを容易にする機能があります。 これらの機能の一部を次に示します。
更新されたサービス ファームと更新されていないコンテンツ ファームの間に下位互換性があります。
Windows Server Update Services (WSUS)、Windows Update および Microsoft Update を使用する自動更新が完全にサポートされています。
注:
自動更新ではバイナリ ファイルがファーム サーバーにコピーされますが、ソフトウェアの更新を完了するには、サーバーでアップグレードを実行する必要があります。
管理者は SharePoint サーバーの全体管理 Web サイトまたは Microsoft PowerShell を使用して更新の状態を監視できます。
ソフトウェアの更新プロセス
SharePoint Server 2016、2019、Subscription Edition 環境で更新プログラムを展開するプロセスは、パッチ適用とビルドからビルドへのアップグレードという 2 フェーズのプロセスです。
それぞれの段階に特定の手順と結果があります。 ビルドからビルドへのアップグレードの段階は延期できます。
注意
最高レベルの下位互換性が保たれるよう努めていますが、下位互換状態での稼働期間が長いほど、ファームの動作の問題が発生する可能性は高くなります。
パッチの段階
パッチ フェーズでは、ファーム内の各 SharePoint Server で更新プログラムを実行します。 1 つまたは 2 つのパッチ (言語に依存しない更新プログラムと言語依存更新プログラム) を実行する必要がある場合があります。
注:
ファームでのインストールの特定の順序は必要ありません。
パッチの段階には、パッチの展開とバイナリ ファイルの展開という 2 つの手順があります。 パッチの展開手順中に、SharePoint Server 2016、2019、またはサブスクリプション エディションを実行しているサーバーに新しいバイナリ ファイルがコピーされます。 パッチにより置き換えられるファイルを使用しているサービスは、一時的に停止されます。 サービスを停止すると、使用中のファイルを置き換えるためにサーバーを再起動する必要が少なくなります。 しかし、場合によっては、サーバーを再起動する必要があります。
パッチ段階の 2 番目の手順は、バイナリ ファイルを展開する手順です。 この手順では、インストーラーによってサポートされているダイナミック リンク ライブラリ (.dll) ファイルが、SharePoint Server 2016、2019、またはサブスクリプション エディションを実行しているサーバー上の適切なディレクトリにコピーされます。 この手順により、更新プログラムのインストール後にすべての Web アプリケーションが正しいバージョンのバイナリ ファイルを実行し、正しく機能することが保証されます。 バイナリ ファイルを展開する手順が終わると、更新の段階は完了です。
ソフトウェア更新プログラムを展開する次の段階はビルドからビルドへのアップグレードの段階で、これは最後の段階です。 この段階では、データベースのスキーマを変更し、ファーム内のオブジェクトを更新し、サイト コレクションを更新します。
ビルドからビルドへのアップグレードの段階
ビルドからビルドへのアップグレード フェーズでは、管理者が構成ウィザードまたは psconfig SharePoint 管理シェルから実行する必要があります。
注:
ファーム内の構成ウィザードの特定の実行順序は必要ありません。
パッチの段階が終わったら、ビルドからビルドへのアップグレードの段階を開始して更新プログラムのインストールを終わらせる必要があります。 ビルドからビルドへのアップグレードの段階は負荷の高いタスクなので、終わるまで非常に時間がかかります。 最初の操作は、実行中のすべての SharePoint プロセスをアップグレードすることです。 これらのプロセスをアップグレードした後に、データベースがクロールされてアップグレードされます。 1 つのサーバー上でファームのアップグレードを終えた後、他のすべてのサーバー上でこのプロセスをすべて行い、互換性を維持する必要があります。
ソフトウェアの更新戦略
注:
このセクションの情報は、ファームが高可用性 (HA) 環境でない場合に適用されます。 HA 環境がある場合は、「 SharePoint Server のダウンタイムゼロパッチ適用手順」の手順に従ってください。
主に次の要因の 1 つに基づいて、更新戦略を選択します。
更新プログラムのインストール時に許容できるダウンタイムの長さ。
ダウンタイムを減らすために利用できる追加のスタッフ リソースとコンピューティング リソース。
更新戦略を決めるときには、その戦略を使用すると更新がどのように管理され、制御されるのか検討してください。
ダウンタイムを減らすことを検討する際には、次のオプションを使用できます。1 つ目の方が 2 つ目よりダウンタイムが長くなります。
更新プログラムをインストールし、アップグレードの段階を延期しません。
更新プログラムをインストールし、アップグレードの段階を延期します。
ソフトウェア更新プログラムの展開サイクル
SharePoint Server 2016、2019、またはサブスクリプション エディションのファームとサーバーのアップグレードに使用されるサイクルは、アップグレード フェーズのサブセットであるソフトウェア更新プログラムの展開にも適用されます。 ソフトウェア更新プログラムを展開するガイドとして、次の図の更新サイクルを使用することをお勧めします。
手順 1:ソフトウェア更新プログラムの要件について学習する
サイクルのこの段階では、更新プログラムのインストール要件について学習します。 この情報は、更新してファームに追加する新しいサーバーにも関係があります。
要件と前提条件
最初に、システムをファーム サーバーとしてプロビジョニングできることを確認します。 詳細については、「SharePoint Server 2016 のハードウェアとソフトウェアの要件」、SharePoint Server 2019のハードウェアとソフトウェアの要件、およびSharePoint Server サブスクリプション エディションのシステム要件に関するページを参照してください。
アップグレードを計画しているサーバー上のオペレーティング システムのバージョンが、他のファーム サーバーと同じであることを確認します。 この段階には、更新プログラム、サービス パック、セキュリティ ホットフィックスが関係しています。
更新戦略
ファームの更新に使用する戦略を決めます。 要件に応じて、次の戦略のいずれかを使用できます。
一括 (インプレース)
データベース接続
使用する更新戦略の詳細については、「SharePoint Server 2016、2019、およびサブスクリプション エディション用のソフトウェア更新プログラムをインストールする」を参照してください。
ダウンタイムの短縮
ダウンタイムを減らすために使用できるオプションを調査して査定します。 最初に、依存関係がないためにダウンタイムが長くなっている可能性があるか確認します。 更新に関するすべての依存関係を識別し、更新プログラムを展開する前にそれらの依存関係を扱うか、または追加の時間をスケジュールに入れます。 読み取り専用のコンテンツ データベースを使ったり、並列アップグレードを実行したりしてダウンタイムを減らすことを検討します。
一般的な問題
依存関係がない、依存関係が期限切れになっている、更新プログラムをインストールするサーバーでスペースが足りないなどの一般的な問題を識別して対応します。
手順 2:ソフトウェア更新プログラムの準備
ソフトウェア更新プログラムを準備するには、環境を文書化し、更新戦略を計画して、予想したダウンタイムの時間内に計画どおり更新が進むことを確認します。
環境を文書化する
環境を文書化して、ファーム内の一意の内容を判断します。 手動検査、WinDiff を使用した比較、Microsoft PowerShell コマンドなど、ファームに関する情報を収集するには、いくつかの手法を使用できます。
該当する場合は、環境の次の要素を文書化します。
ファーム トポロジとサイトの階層
インストールされている言語パックとフィルター パック
更新プログラムによる影響を受ける可能性があるカスタマイズ
カスタマイズの管理
通常、カスタマイズはファームのアップグレードやソフトウェア更新中の上位の問題の 1 つです。 ファームのカスタマイズ内容を識別し、更新による影響を受ける可能性があるかどうかを判別します。 よくわからなければ、慎重を期して、カスタマイズを管理する方法を決めます。 ソフトウェアの更新後にカスタマイズの動作を確認する必要があります。 Stsadm ExportIPFSAdminObjects コマンドを使って、InfoPath 管理者が展開したフォームのみ収集してエクスポートできます。
更新戦略の計画
更新サイクルの学習フェーズで、更新戦略と最低限必要なダウンタイム時間を特定しました。 ハードウェア、スペース、およびソフトウェアの要件を決めるだけでなく、更新戦略に次の内容を含める必要があります。
ファーム サーバーの更新手順
操作の順序
ダウンタイムの制限およびダウンタイムを減らすよう計画する方法
ロールバック プロセス (大きな問題が発生した場合)
更新戦略の最後の要件は、コミュニケーション計画と更新スケジュールの 2 つです。
アップグレード中に予測される事態について、サイトの所有者とユーザーが話し合うことは重要です。 管理者はユーザーに、アップグレードの時間が予測より長くなる可能性があることや、一部のサイトではアップグレード後に作業のやり直しが必要になる可能性があることについて知らせ、そのダウンタイムとリスクを通知する必要があります。
更新プログラムの展開に関連した操作の開始時間を含む、更新操作のベンチマーク スケジュールを作成します。 少なくとも、次の操作を計画に含める必要があります。
ファームをバックアップします。
ファームのサーバーの更新を開始します。
ファーム データベースのアップグレードを開始します。
アップグレードを停止し、アップグレードされていないファームで操作を再開します。
必要な場合は、アップグレードを再開します。
ロール バックした場合は元のバージョン、アップグレードが完了した場合は新しいバージョンの環境が完全に作動することを確認します。
ファーム アイテムを更新に備えて準備する
ファーム アイテムが更新に備えて準備されていることを確認します。 ファーム アイテムがバックアップされたり、文書化されたり、更新されたりしており、更新プログラムをインストールできるようになっていると、そのファーム アイテムは準備されていることになります。 ファームの以下のアイテムが更新に備えて準備されていることを確認します。
ソリューション
機能
サイト定義
Web パーツ
手順 3:ソフトウェア更新プログラムの展開のテスト
ソフトウェア更新プログラムの展開の成否を決める要素として、テストの厳格さ、完全性、詳細性があります。 運用コンピューター環境では、安全な近道はありませんし、テストが不十分になる場合があります。
テスト ファームの構築
運用環境を表すテスト ファームを構築します。 運用データのコピーを使って、問題が発生する可能性がある分野を判別し、アップグレード中のシステム パフォーマンスの概要を監視することをお勧めします。 主要な指標は、展開プロセスの初めから終わりまでの所要時間の長さです。 この時間にはバックアップと検証を含める必要があります。 更新スケジュールにこの情報を組み込むことができます。
可能であれば、運用サーバーと同等のパフォーマンス能力を持つハードウェアをテスト環境で使用します。
ヒント
仮想環境でテスト ファームを使うことを検討してください。 テストが完了したら、仮想ファームをシャットダウンし、将来更新するときに使用できます。
技術の評価
テスト ファームを使用して、運用環境の更新に使用するよう計画している技術を評価することもできます。 ダウンタイムを減らす戦略をテストして査定するだけでなく、更新の監視を調整できます。 この作業は、ソフトウェアの更新の検証とトラブルシューティングの分野で特に重要です。
手順 4:ソフトウェア更新プログラムの実装
新しいファームを構築する必要があるか、それとも現在のファーム サーバーに更新プログラムを展開するかによって、使用する更新戦略が決まります。
ファームのビルドまたは更新
新しいファームを構築するか、それとも一括更新を行うか決める際に検討する必要がある重要なファーム要素は以下のとおりです。
コンテンツ
サービス
サービス アプリケーション
カスタマイズの展開
可能な限り、個々のファイルやコンポーネントを展開できるソリューションを使用してください。
ダウンタイムの短縮
読み取り専用データベースや更新の並列処理などの技術を使用することにより、ダウンタイムを減らします。
進行状況の監視
テスト環境でソフトウェア更新の監視に使用して調整した技術を、運用環境で更新プログラムを展開するときに適用します。 利用できる状況表示を監視するには、サーバーの全体管理 の [ アップグレードと移行 ] ページを使用します。 この機能は、ライブで監視できるようにして、すべてのファーム サーバーのパッチの状態を単一の場所に表示します。 また、[ アップグレードと移行 ] ページを使って個々のサーバーの更新状態やファーム データベースの状態と種類を表示できます。 最後に、サーバーの全体管理 を使用して更新を監視すると、更新する必要があるファーム サーバーを識別できます。
次の表は、サーバーの全体管理 で利用できる状態情報を説明しています。
| 状態の値 | 説明 | ハイパーリンク |
|---|---|---|
| 操作不要 |
現在ファーム サーバーで管理者が操作を行う必要はありません。 |
ハイパーリンクなし |
| インストールが必要 |
このファーム サーバーに、すべてのファーム サーバーで必須に設定されている .msi ファイルがないか、または個々のファームのレベルで有効なパッチ バージョンより下のパッチ レベルがあります。 |
[ パッチ展開状態 ] ページへのハイパーリンク |
| アップグレードが進行中 |
ファーム サーバーで、現在アップグレード操作を実行中です。 |
[ アップグレードの状態 ] ページへのハイパーリンク |
| アップグレードを利用可能 |
ファーム サーバーが下位互換性モードで実行されています。 |
[ アップグレードと移行 ] ページへのハイパーリンク |
| アップグレードが必要です |
ファーム サーバーが、1 つ以上のデータベースとの下位互換性モードの範囲外です。 |
[ アップグレードと移行 ] ページへのハイパーリンク |
| アップグレードがブロックされた |
アップグレードを利用でき、特定のファーム サーバーでインストールの必要がある場合に、インストールの必要がなく、現在アップグレードが実行中でない残りのサーバーはこの状態に設定されます。 |
[ パッチ展開状態 ] ページへのハイパーリンク |
| インストール済み |
操作が不要であることを示します。 |
該当しない |
| 未インストール/インストール必須 |
各サーバー上で製品が必須の場合か、1 つのサーバー上に特定の .msi ファイルのパッチがあるがこの状態の表示対象のサーバー上にはない場合に表示されます。 |
該当しない |
| 見つからない/オプション |
各サーバー上で製品が必須でない場合に表示されます。 |
該当しない |
| 置き換え |
新しいパッチが優先されるため、サーバーで更新が不要になった場合に表示されます。 |
該当なし |
更新プロセスを監視する他のツールとして、ログ ファイルと PowerShell コマンドがあります。
重要
更新を実行している時間の長さを監視することを忘れないでください。 現在の更新プロセスをベンチマーク スケジュールと比較して、この更新がダウンタイム内に収まるかどうか判別します。 収まらない場合は、この情報をファームのユーザーに通信します。
手順 5:ソフトウェア更新プログラムが正常に実行されたことの検証
実装段階中に更新が正常に行われたかどうかの検証を開始し、更新の実装後も検証を続行できます。
イベントの失敗の記録
イベント ログを確認して、展開中に発生した問題を見つけます。 問題を解決したら、必要に応じて更新プログラムを再開または再起動します。
ユーザー インターフェイスまたは操作性の問題
ユーザー インターフェイスの問題やユーザーの操作性の問題は、サイトのページに現れます。 これらの問題は、主にバージョンからバージョンへのアップグレード中に発生します。 次の問題を調べてください。
ユーザーがサイト コレクション内で変更し、最近サーバー上でアップグレードしたために予測と違う動作になったか表示上の問題が生じた、ASP.NET (.aspx) ページとして実体化されたファイル
ユーザー インターフェイス バージョンの不一致
HTML および XHTML 準拠
他に、テンプレートがないという問題、ユーザー ID の問題、一覧が大きいなどのコンテンツの問題が含まれる可能性があります。
データの問題
データの問題は、ファーム データベースの状態が原因で、次の一部またはすべてが含まれる可能性があります。
データ ソースへの接続に関する問題
データベースの破損
孤立したアイテム
非表示の列データ
軽微な問題のトラブルシューティングを行ってから、更新を再開するか再始動することができる場合もあります。 問題を解決できない場合は、更新プログラムのロールバックを準備してください。