Configuration Manager (現在のブランチ) に適用
クライアントは、境界グループを使用して新しいソフトウェアの更新ポイントを見つけます。 クライアントが検索できるサーバーを制御するには、個別の境界グループに個々のソフトウェアの更新ポイントを追加します。
既存のすべてのソフトウェア更新ポイントを既定のサイト境界グループに追加する場合、クライアントは利用可能なサーバーのプールからソフトウェアの更新ポイントを選択します。 この動作は、以前のバージョンの Configuration Manager 現在のブランチと似ています。 選択とフォールバック動作を制御するには、個々のソフトウェアの更新ポイントを別の境界グループに追加します。
新しいサイトをインストールする場合、ソフトウェアの更新ポイントは既定のサイト境界グループには追加されません。 クライアントがソフトウェアの更新ポイントを見つけて使用できるように、境界グループに割り当てます。
Fallback
他のサイト システムの役割と同様にソフトウェアの更新ポイントのフォールバックを構成します。ただし、次の点に注意してください。
新しいクライアントは、境界グループを使用してソフトウェアの更新ポイントを選択します
新しいクライアントをインストールすると、構成した境界グループに関連付けられているサーバーからソフトウェア更新ポイントが選択されます。 この動作は、クライアントがクライアントのフォレストを共有するサーバーの一覧からソフトウェアの更新ポイントをランダムに選択する以前の動作に置き換わるものです。
クライアントは、新しい更新ポイントを見つけるためにフォールバックするまで、前回正常であることが判明したソフトウェアの更新ポイントを引き続き使用します
ソフトウェアの更新ポイントが既にあるクライアントは、到達できなくなるまで引き続き使用されます。 この動作には、クライアントの現在の境界グループに関連付けられていないソフトウェア更新ポイントの継続使用が含まれます。
この動作は意図的です。 クライアントの現在の境界グループにない場合でも、クライアントは既存のソフトウェア更新ポイントを引き続き使用します。 ソフトウェアの更新ポイントが変更されると、クライアントは新しいサーバーとデータを同期するため、大量のネットワーク使用率が発生します。 すべてのクライアントが同時に新しいサーバーに切り替える場合、移行の遅延はネットワークの飽和状態を回避するのに役立ちます。
クライアントは常に、フォールバックを開始する前に 120 分間、最後の正常なソフトウェア更新ポイントに到達しようとします
120 分後に、クライアントが接続を確立していない場合、フォールバックが開始されます。 フォールバックが開始されると、クライアントは現在の境界グループ内のすべてのソフトウェア更新ポイントの一覧を受け取ります。 近隣およびサイトの既定の境界グループ内の他のソフトウェア更新ポイントは、フォールバック構成に基づいて使用できます。
フォールバックの構成
ソフトウェアの更新ポイントの フォールバック時間 (分単位) を 120 分未満に構成できます。 ただし、クライアントは引き続き、元のソフトウェアの更新ポイントに 120 分間到達しようとします。 次に、検索を他のサーバーに展開します。 境界グループのフォールバック時間は、クライアントが最初に元のサーバーに到達できなかったときに開始されます。 クライアントが検索を展開すると、サイトは 120 分未満に構成された境界グループを提供します。
ソフトウェア更新ポイントの隣接境界グループへのフォールバックをブロックするには、設定を [フォールバックしない] に構成します。
元のサーバーに 2 時間到達できなかった後、クライアントはより短いサイクルを使用して新しいソフトウェア更新ポイントへの接続を確立します。 この動作により、クライアントは、潜在的なソフトウェア更新ポイントの一覧をすばやく検索できます。
例
10 分後にフォールバックするように、境界グループ A のソフトウェア更新ポイントを構成します。 境界グループ B に対して同じ設定を 130 分に構成します。 境界グループ Z のクライアントが、前回の正常なソフトウェアの更新ポイントに到達できません。
次の 120 分間、クライアントは境界グループ Z にある元のサーバにのみ到達しようとします。10 分後、Configuration Manager はソフトウェア更新ポイントを境界グループ A から使用可能なサーバーのプールに追加します。 ただし、クライアントは最初の 120 分が経過するまで、クライアントまたは他のサーバーに接続しようとしません。
元のソフトウェアの更新ポイントに 120 分間接続を試みた後、クライアントは検索を展開します。 現在のソフトウェア更新ポイントと 120 分以内に構成された近隣の境界グループの使用可能なプールにサーバーを追加します。 このプールには、使用可能なサーバーのプールに以前に追加された境界グループ A のサーバーが含まれます。
さらに 10 分後、クライアントは境界グループ B のソフトウェア更新ポイントが含まれるように検索を拡張します。この期間は、クライアントが最初に最後の既知の正常なソフトウェア更新ポイントに到達できなかった後の合計時間の 130 分です。
新しいソフトウェアの更新ポイントに手動で切り替える
フォールバックと共に、クライアント通知を使用して、デバイスを新しいソフトウェア更新ポイントに手動で強制的に切り替えます。
新しいサーバーに切り替えると、デバイスはフォールバックを使用してその新しいサーバーを検索します。 クライアントは、次のソフトウェア更新プログラムのスキャン サイクル中に新しいソフトウェアの更新ポイントに切り替わります。
境界グループの構成を確認します。 この変更を開始する前に、ソフトウェアの更新ポイントが正しい境界グループ内にあることを確認してください。
詳細については、「 クライアントを新しいソフトウェアの更新ポイントに手動で切り替える」を参照してください。
イントラネットのクライアントは CMG ソフトウェアの更新ポイントを使用できます
イントラネット クライアントは、クラウド管理ゲートウェイ (CMG) を介してソフトウェアの更新ポイントにアクセスできます。 CMG を境界グループに割り当て、ソフトウェアの更新ポイントを有効にして、Configuration Manager クラウド管理ゲートウェイ トラフィックを許可します。
この動作は、次のシナリオで役立ちます。
インターネット コンピューターが VPN に接続すると、インターネット経由で CMG ソフトウェア更新ポイントのスキャンが続行されます。
境界グループの唯一のソフトウェア更新ポイントが CMG ソフトウェア更新ポイントである場合、すべてのイントラネットおよびインターネット デバイスがこのポイントをスキャンします。
クラウドベースのソフトウェア更新ポイントを優先する
(バージョン 2203 で導入)
バージョン 2203 以降、境界グループが [ オンプレミス ソースよりもクラウド ベースのソースを優先 する] オプションを使用する場合、クライアントはオンプレミスの SUP 経由でクラウド管理ゲートウェイ (CMG) ソフトウェア更新ポイント (SUP) に対してスキャンすることを優先します。 この変更によるパフォーマンスへの影響を軽減するために、クライアント は SUP をクラウドベースの SUP に自動的に切り替えません 。 クライアントは、現在の SUP にエラーが発生するか、クライアントが新しい SUP に手動で切り替わらない限り、現在の SUP に割り当てられたままになります。 境界グループ オプションを設定した後は、環境に追加された新しいクライアントの SUP を手動で切り替える必要はありません。
クライアントがクラウドベースのソフトウェア更新ポイントを優先するように設定するには、次の概要を参照してください。
- クラウド管理ゲートウェイが構成され、機能していることを確認する
- ソフトウェアの更新ポイントが機能し、同期されていることを確認します。
- CMG で使用する任意の SUP に対して、[Configuration Manager クラウド管理ゲートウェイ トラフィックを許可する] オプションを有効にします。
- [オンプレミス ソースよりもクラウド ベースのソースを優先する] オプションを有効にし、CMG SUP サーバーをサイト システム サーバーの一覧に追加して、この動作の境界グループを構成します。
- クライアントを新しい SUP に手動で切り替えるには、デバイスまたはコレクションの [次のソフトウェア更新ポイントに切り替える] クライアント通知アクションを使用します。
- バウンダリーグループ内のクライアントは、現在のSUPに対するスキャンが2時間で4回失敗しない限り、 新しいSUP*9に自動的に切り替わりません。
- 境界グループ オプションを設定した後は、環境に追加された新しいクライアントの SUP を手動で切り替える必要はありません。
- クライアントが CMG SUP を優先することを確認するには、切り替えた一部のクライアントでソフトウェア更新プログラムのスキャン サイクルを開始します。
- 多数のクライアントが同時に新しい SUP に対してスキャンすることによって引き起こされる潜在的なパフォーマンスの問題を制限するために、多数のクライアントですぐにスキャン サイクルを呼び出す場合は、10 〜 15 分ごとに 100 個以下のクライアントから始めることをお勧めします。 環境のパフォーマンスへの影響を測定したら、クライアントの数と頻度を増減します。