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 のハードウェア要件およびソフトウェア要件

この記事の情報は、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 サブスクリプション エディション言語パック

Microsoft では、毎月公開更新プログラムをリリースしています。 最初の更新プログラムは、言語に依存しない更新プログラムと呼ばれます。 この更新プログラムには、多くの場合、機能とセキュリティの両方の修正プログラムが含まれます。 "sts-x-none" パッチとも呼ばれます。

2 番目の種類のパッチは、言語に依存するパッチです。 このパッチは、英語のインストールを含むすべての言語パックを対象とします。 このパッチは、ファームを完全に更新するために必要ですが、毎月リリースされるわけではありません。 このパッチは、"wssloc" パッチとも呼ばれます。

ソフトウェア更新に関する用語

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 アプリケーションが正しいバージョンのバイナリ ファイルを実行し、正しく機能することが保証されます。 バイナリ ファイルを展開する手順が終わると、更新の段階は完了です。

ソフトウェア更新プログラムを展開する次の段階はビルドからビルドへのアップグレードの段階で、これは最後の段階です。 この段階では、データベースのスキーマを変更し、ファーム内のオブジェクトを更新し、サイト コレクションを更新します。

ビルドからビルドへのアップグレードの段階

ビルドからビルドへのアップグレード フェーズでは、管理者が構成ウィザードを実行するか、SharePoint 管理シェルから psconfig する必要があります。

パッチの段階が終わったら、ビルドからビルドへのアップグレードの段階を開始して更新プログラムのインストールを終わらせる必要があります。 ビルドからビルドへのアップグレードの段階は負荷の高いタスクなので、終わるまで非常に時間がかかります。 最初の操作は、実行中のすべての SharePoint プロセスをアップグレードすることです。 これらのプロセスをアップグレードした後に、データベースがクロールされてアップグレードされます。 1 つのサーバー上でファームのアップグレードを終えた後、他のすべてのサーバー上でこのプロセスをすべて行い、互換性を維持する必要があります。

ソフトウェアの更新戦略

主に次の要因の 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:ソフトウェア更新プログラムの実装

新しいファームを構築する必要があるか、それとも現在のファーム サーバーに更新プログラムを展開するかによって、使用する更新戦略が決まります。

ファームのビルドまたは更新

新しいファームを構築するか、それとも一括更新を行うか決める際に検討する必要がある重要なファーム要素は以下のとおりです。

• コンテンツ

• サービス

• サービス アプリケーション

カスタマイズの展開

可能な限り、個々のファイルやコンポーネントを展開できるソリューションを使用してください。

ダウンタイムの短縮

読み取り専用データベースや更新の並列処理などの技術を使用することにより、ダウンタイムを減らします。

進行状況の監視

テスト環境でソフトウェア更新の監視に使用して調整した技術を、運用環境で更新プログラムを展開するときに適用します。 利用できる状況表示を監視するには、サーバーの全体管理 の [ アップグレードと移行 ] ページを使用します。 この機能は、ライブで監視できるようにして、すべてのファーム サーバーのパッチの状態を単一の場所に表示します。 また、[ アップグレードと移行 ] ページを使って個々のサーバーの更新状態やファーム データベースの状態と種類を表示できます。 最後に、サーバーの全体管理 を使用して更新を監視すると、更新する必要があるファーム サーバーを識別できます。

次の表は、サーバーの全体管理 で利用できる状態情報を説明しています。

更新プロセスを監視する他のツールとして、ログ ファイルと PowerShell コマンドがあります。

手順 5:ソフトウェア更新プログラムが正常に実行されたことの検証

実装段階中に更新が正常に行われたかどうかの検証を開始し、更新の実装後も検証を続行できます。

イベントの失敗の記録

イベント ログを確認して、展開中に発生した問題を見つけます。 問題を解決したら、必要に応じて更新プログラムを再開または再起動します。

ユーザー インターフェイスまたは操作性の問題

ユーザー インターフェイスの問題やユーザーの操作性の問題は、サイトのページに現れます。 これらの問題は、主にバージョンからバージョンへのアップグレード中に発生します。 次の問題を調べてください。

• ユーザーがサイト コレクション内で変更し、最近サーバー上でアップグレードしたために予測と違う動作になったか表示上の問題が生じた、ASP.NET (.aspx) ページとして実体化されたファイル

• ユーザー インターフェイス バージョンの不一致

• HTML および XHTML 準拠

他に、テンプレートがないという問題、ユーザー ID の問題、一覧が大きいなどのコンテンツの問題が含まれる可能性があります。

データの問題

データの問題は、ファーム データベースの状態が原因で、次の一部またはすべてが含まれる可能性があります。

• データ ソースへの接続に関する問題

• データベースの破損

• 孤立したアイテム

• 非表示の列データ

軽微な問題のトラブルシューティングを行ってから、更新を再開するか再始動することができる場合もあります。 問題を解決できない場合は、更新プログラムのロールバックを準備してください。