Microsoft Intune 用の Microsoft Tunnel をアップグレードする
Microsoft Intune 用の VPN ゲートウェイ ソリューションである Microsoft Tunnel に対しては、定期的にソフトウェアのアップグレードが行われます。サポートを維持するには、それを Tunnel サーバーにインストールする必要があります。 サポートを維持するには、最新のリリースまたは最大でも 1 つ前のバージョンが、サーバーで実行されている必要があります。 この記事の情報では、次について説明します。
- アップグレード プロセス
- アップグレードコントロール
- トンネル サーバーのソフトウェア バージョンを理解するために使用できる状態レポート
- アップグレードが利用可能な場合
- アップグレードがいつ行われるかを制御する方法。
各トンネル サイトに割り当てられているサーバーのアップグレードは、Intune によって自動的に処理されます。 サイトのアップグレードが開始されると、サイト内のすべてのサーバーが一度に 1 つずつアップグレードされます。これはアップグレード サイクルと呼ばれます。 サーバーのアップグレード中は、サーバー上の Microsoft Tunnel を使用できません。 一度に 1 台のサーバーをアップグレードすると、サイトに複数のサーバーが含まれている場合に、ユーザーの中断を最小限に抑えることができます。
アップグレード サイクルの間:
- Intune により、サイト内の 1 つのサーバーのアップグレードが開始されます。 アップグレードは、リリースが使用可能になってから最短で 10 分後に開始できます。
- サーバーがオフの場合、アップグレードはサーバーの電源がオンになった後で開始されます。
- サイトの 1 台のサーバーのアップグレードが正常に完了した後、短時間待機した後、Intune によって次のサーバーのアップグレードが開始されます。
アップグレードの制御を使用する
Intune によってアップグレード サイクルが開始されるタイミングを制御するには、各サイトで次の設定を構成します。 新しいサイトを作成するときに、または既存のサイトのプロパティを編集して、設定を構成できます。
- このサイトのサーバーを自動的にアップグレードする
- サーバーのアップグレードをメンテナンス期間に制限する
このサイトのサーバーを自動的にアップグレードする
この設定を使用すると、サイトのアップグレード サイクルを自動的に開始できるかどうか、またはサイクルを開始する前に管理者が明示的にアップグレードを承認する必要があるかどうかが決定されます。
Yes(default) – [はい] に設定すると、新しいトンネル バージョンが使用可能になると、サイトはできるだけ早くサーバーを自動的にアップグレードします。 アップグレードは、管理者の介入なしで開始されます。
サイトのメンテナンス期間を設定してある場合は、期間の開始から終了までの間にアップグレード サイクルが開始されます。 メンテナンス期間を設定してない場合は、可能な限り早くアップグレード サイクルが開始されます。
[いいえ] – [いいえ] に設定すると、管理者がアップグレード サイクルの開始を明示的に選択するまで、Intuneはサーバーをアップグレードしません。
メンテナンス期間でサイトのアップグレードが承認され後、期間の開始から終了までの間に、アップグレード サイクルが開始されます。 メンテナンス期間がない場合は、可能な限り早くアップグレード サイクルが開始されます。
重要
サイトで手動アップグレードを構成する場合は、[正常性チェック] タブを定期的に確認して、新しいバージョンの Microsoft Tunnel をいつインストールできるかを把握します。 また、レポートには、サイトの現在のトンネル バージョンがサポートされなくなる時期も示されています。
サーバーのアップグレードをメンテナンス期間に制限する
サイトのメンテナンス期間を定義するには、この設定を使用します。
サイトで構成するとき、サーバーのアップグレード サイクルは、構成された期間中にのみ開始できます。 ただし、いったん開始されると、サイトに割り当てられているすべてのサーバーのアップグレードが完了するまで、サーバーの更新が 1 つずつ続けられます。
いいえ(既定値) – メンテナンス期間は設定されていません。 アップグレードするように構成されたサイトは、できるだけ早く自動的にアップグレードされます。 アップグレードの開始に明示的な操作を必要とするように構成されたサイトは、アップグレードが承認された "後で"、直ちに実行されます。
はい – メンテナンス期間が設定されます。 期間により、サイトでサーバーのアップグレード サイクルを開始できるときが制限されます。 メンテナンス期間では、サイトに割り当てられた個々のサーバーのアップグレードが開始されるタイミングは定義されません。
アップグレードするように構成されているサイトは、構成された期間中にのみアップグレード サイクルを自動的に開始します。 開始前に管理者がアップグレードを承認するように構成されたサイトは、アップグレードが承認された "後の"、次回のメンテナンス期間中に実行されます。
[はい] に設定したら、次のオプションを構成します。
- [タイム ゾーン] – 選択したタイム ゾーンによって、サイト内のすべてのサーバーでメンテナンス期間が開始および終了する時間が決まります。 個々のサーバーのタイム ゾーンは使用されません。
- [開始時刻] – 選択したタイム ゾーンに基づいて、アップグレード サイクルを開始できる最も早い時刻を指定します。
- [終了時刻] - 選択したタイム ゾーンに基づいて、アップグレード サイクルを開始できる最も遅い時刻を指定します。 この時刻より前に開始されたアップグレード サイクルは引き続き実行され、この時刻より後で完了してもかまいません。
Tunnel サーバーの状態を表示する
サーバー上の Microsoft Tunnel バージョンなど、Microsoft Tunnel サーバーの状態に関する情報を表示できます。
自動アップグレードがサポートされていないサイトでは、新しいバージョンへのアップグレードがいつ使用可能になるかも確認できます。
管理センター>のテナント管理>Microsoft Tunnel Gateway>の正常性状態Microsoft Intuneサインインします。 サーバーを選択し、[正常性チェック] タブを開いて、それに関する次の情報を表示します。
サーバーのバージョン - 使用可能な最新のバージョンのコンテキストでの、Tunnel ゲートウェイ サーバー ソフトウェアの状態。
- 正常 - 最新のソフトウェア バージョンでの最新の状態。
- 警告 - 1 つ前のバージョン。
- 異常 - 2 つ以上前のバージョン、およびサポート対象外。
サーバーで最新のソフトウェア バージョンが実行されていない場合は、Microsoft Tunnel のサポートを維持するため、利用可能なアップグレードのインストールを計画します。
アップグレードを承認する
[ このサイトのサーバーを自動的にアップグレード する] が [いいえ ] に設定されているサイトでは、サーバーは自動的にアップグレードされません。 代わりに、アップグレード サイクルが開始される前に、管理者がそのサイトのサーバーのアップグレードを承認する必要があります。
サーバーでアップグレードをいつ利用できるかを把握するには、[正常性チェック] タブを使用してサーバーの状態を確認します。
アップグレードを承認するには
管理センター>のテナント管理>Microsoft Tunnel Gateway> サイトMicrosoft Intuneサインインします。
[アップグレードの種類]が [手動] のサイトを選択します。
サイトのプロパティで、[Upgrade servers]\(サーバーのアップグレード\) を選択します。
サーバーのアップグレードを選択した後、Intuneはプロセスを開始します。これは取り消すことはできません。 サイトでのアップグレードがいつ開始するかは、サイトのメンテナンス期間の構成によって異なります。
Microsoft Tunnel の更新履歴
Microsoft Tunnel の更新プログラムは、定期的にリリースされます。 新しいバージョンが利用可能になったら、ここで変更について確認してください。
更新プログラムがリリースされた後、数日間にわたってテナントにロールアウトされます。 このロールアウト時間は、Tunnel サーバーで新しい更新プログラムを数日間利用できない可能性があることを意味します。
現時点では、サーバーの Microsoft Tunnel バージョンを Intune UI で使用することはできません。 代わりに、トンネルをホストする Linux サーバーで次のコマンドを実行して 、agentImageDigest と serverImageDiegest のハッシュ値を識別します。 cat /etc/mstunnel/images_configured
重要
コンテナー のリリースは段階的に行われます。 コンテナー イメージが最新ではない場合は、次の週に更新されて配信されることをご確認ください。
2024 年 4 月 22 日
イメージ ハッシュ値:
agentImageDigest: sha256:987028e043434cabf9a85a8be232a35cb10d6499ab9fa2b0ac33bd214455cdf6
serverImageDigest: sha256:95106796faa4648ffe877c1ae4635037fd8bd630498bb3caea366e3c832f84cc
このリリースの変更点:
- ルートレス Podman コンテナーのサポートを追加しました
- "mst-cli サーバー キャプチャ" コマンドを修正しました
- 一部の TLS 証明書失効チェックエラーを修正しました
2024 年 3 月 14 日
イメージ ハッシュ値:
agentImageDigest: sha256:a0fa473b477c051445548f9e024cd58b3f87b0a87da7bafdf0d71ad6bb49a7c5
serverImageDigest: sha256:5f3f34f3f11a4d45efdd369e86d183cae0fafdd78c9c1d0a9275f26ce64e5510
このリリースの変更点:
- バグ修正: アップグレード中に /tmp/mstunnel フォルダーが存在しない場合は再作成します。
- OpenConnect VPN Server をバージョン 1.2.3 に更新します。
- 診断ツールの機能強化。
- 基本イメージのセキュリティ更新プログラム。
2024 年 2 月 1 日
イメージ ハッシュ値:
agentImageDigest: sha256:845aee9cbe3e4c9bd70b1b8108cd5108e454aff38237b236f75092164c885023
serverImageDigest: sha256:6f444d251b56e467b8791201f554b22d1431a135a5f66bc45638cec453e22b47
このリリースの変更点:
- バグ修正: "docker network reload" コマンドを発行してネットワークをリセットしないでください。 コマンドは Docker ではサポートされていません。
- 基本イメージのセキュリティ更新プログラム。
2024 年 1 月 4 日
イメージ ハッシュ値:
agentImageDigest: sha256:9cd55c3f4ea4b4ff8212db46a81a0ceda29c3e9c534226ee4d0ce896bcc32596
serverImageDigest: sha256:0389d8c16794cf2f982a955a528b0bbba79b7c7180fd5706f44bb691ca61734d
このリリースの変更点:
- バグ修正: ルートレス コンテナーの修正
- HB 応答での診断およびログ アップロード要求の MTG 処理
2023 年 11 月 14 日
イメージ ハッシュ値:
agentImageDigest: sha256:fd64c2f2ae3c2f411188a35da65e23385c9124c8f98b3614e0fb6500f59cf485
serverImageDigest: sha256:7385c838ed95f3f5fea48a3e277223e4faa502d64205f182cf43740ad4ddd9573
このリリースの変更点:
- バグ修正: MSTunnel サーバー コンテナーが不適切な状態でスタックする問題を解決しました
- エージェントと mstunnel アプリでの TLS 1.2 の使用を強制する
2023 年 10 月 4 日
イメージ ハッシュ値:
agentImageDigest: sha256:6c19b0aa077692b0d70ede9928f02b135122951708f83655041d0a40e8448039
serverImageDigest: sha256:9b477e6bc029d2ebadcafd4db3f516e87f0209b50d44fa2a5933aa7f17e9203b
このリリースの変更点:
- バグ修正: Cent OS 7 および Red Hat 7 ホスト上の mstunnel-server コンテナーのレガシ NAT テーブルを追加する
- バグ修正: SELinux ポリシーを追加して、Red Hat ホスト上のコンテナーの TCP DNS トラフィックを許可する
- mstunnel-server コンテナーの pid の制限を 10000 に増やす
次の手順
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示