ConfigMgr 2012-アップデートをインストールせずに、コンピューターが自動的にアップデートを利用できるようにする方法
System Center Configuration Manager 2012とソフトウェアの更新ポイント機能を使用しています。ただし、この環境では、サーバーの再起動をさまざまな人が承認してスケジュールする必要があるため、パッチは厳密に手動で行う必要があります。したがって、自動承認で手動インストールのプレーンWSUSサーバーを使用するように、ConfigMgrのSUPを使用する必要があります。
重要な更新を自動的にダウンロードして展開し、インストールを「できるだけ早く」行うように、自動展開ルールをいくつか作成しました。ただし、期限に達したときにanythingを実行せず、必要な場合でもシステムの再起動を実行しないように、これらのルールも構成しました。
また、これらのルールが更新を展開する場所にデバイスコレクションを構成しましたnotには有効なメンテナンスウィンドウがあります。
しかし、私は期待していたのとは正反対の体験をしています。新しい更新がADRによって処理されるとすぐに、ソフトウェアセンターによってすべてのシステムに自動的にインストールされ、その後コンピューターが再起動されます。
なぜこうなった？問題が発生しているのですか、それともConfigMgr 2012が正常に動作していないのですか？
私はこの質問が少し古いことを知っていますが、ここにいくつかの真実が投稿されています。 SCCM 2012の機能には何の問題もありません。問題は、ソフトウェアとアップデートの展開方法の誤解です。Microsoftが「仕様による」動作であると言ったときに、Microsoftを引用するのは不公平です。あなたは何もできず、将来の期限を設定しなければなりません。これは実際にはIS設計によるものですが、あなたの設計に基づいています。メンテナンスウィンドウを設定しなかったので、もちろん更新が適用されます締め切りに近づくとすぐにそれがデフォルトで行われます。このタイプの設計では、インストールが開始されないように、締め切りを遠くまで設定する必要があります。しかし、それが望みどおりの唯一の方法ではありません。それは最も簡単です。
SCCMのデフォルトの動作、「特に指示がない限り、何でも実行する」を元に戻すことができることをご存知でしたか？
これを行うには、新しいコレクション（「手動で展開」など、わかりやすい名前を付けます）を作成し、そのメンバーシップに「すべてのシステム」コレクションを含めます。次に、プロパティを取得し、2013年1月1日の午前12:00から午前12:05のような過去の有効日を使用してメンテナンスウィンドウを設定し、繰り返しスケジュールを[なし]に設定します。繰り返しが設定されていないという警告が表示されますが、とにかく[OK]をクリックします。それ以降は、SCCM環境内のすべてのデバイスに、有効期限が切れたメンテナンスウィンドウが自動的に設定され、新しいメンテナンスウィンドウがないと何もインストールできません。これは、明示的に指示されるまでインストールや更新を実行しないため、以前の動作とは逆になります。
これは非常に強力ですが、注意が必要なのは、インストールを実行できるタイミングと再起動を実行できるタイミングを完全に手動で制御できることです。これらのチェックボックスには意味があります。たとえば、Endpoint Protection定義などの自動デプロイメントルールがある場合、それらを適用するために毎日サーバーにログインすることを楽しんでいない限り、メンテナンスウィンドウの外にそれらをインストールできることを確認する必要があります。インストールがメンテナンスウィンドウの外で実行できる場合でも、再起動を抑制するオプションがあります。 1つの利点は、何でも簡単に展開でき、手動インストールの割り当てと期限を選択するときに「できるだけ早く」を使用できることです。また、メンテナンスウィンドウのセットアップが賢明な場合は、パッチを1度展開できますが、実際のインストールと新しいメンテナンスウィンドウで他のコレクションを使用して再起動します。メンテナンスウィンドウはすべてのコレクションにわたって累積されるため、それに応じて環境を設計してください。
途方もなく長い将来に期限を設定してみましたか？
SCCM 2008でサーバーへの広告を処理する方法です。広告をサーバーにロールアウトした日から1年間の期限を設定します。パッチ適用ウィンドウがロールすると、便利で便利ですすべてのアップデートはそこにあり、インストールされるのを待っていますが、手動の介入なしではキックオフしません。また、期待どおりに動作しようとしている設定をいじくり回すよりも、私の側で必要な作業は少なくて済みます。
デプロイメントを「必須」ではなく「利用可能」にしないのはなぜですか？これにより、更新プログラムがソフトウェアセンターに表示されますが、自動的にはインストールされません。
また、メンテナンスウィンドウは、コレクションではなくクライアントに適用されます。
「追加の問題点は、マシンがデプロイメントを対象とする複数のコレクションのメンバーであり、それらのコレクションの1つにメンテナンスウィンドウが定義されていない場合、他のコレクションのメンテナンスウィンドウは事実上無視されることです。」
実際には、クライアントのメンテナンスウィンドウは、それに適用されるメンテナンスウィンドウの合計になります。したがって、1つのコレクションのメンバーシップを通じて適用される1時間のメンテナンスウィンドウがあり、クライアントがメンテナンスウィンドウが定義されていないコレクションのメンバーでもある場合、有効なメンテナンスウィンドウは1時間です。
間違った答えが選択されているようです。グラフィックで丸で囲んだチェックボックスは、メンテナンスウィンドウが定義されているマシンにのみ適用されます。チェックボックスの上のテキスト行に、同じくらいはっきりと書かれています。 SCCMでは、メンテナンスウィンドウが割り当てられていない場合、そのサーバーを古いまま維持しても問題がないと見なされます。これは完全に理にかなっています。これらのチェックボックスをデプロイメントに適用する場合は、メンテナンスウィンドウを設定する必要があります。過去に1つ設定し、繰り返しを指定しない場合、そのコレクション内のすべてのメンテナンスウィンドウが期限切れになり、そのための別のメンテナンスウィンドウはありません。このシナリオでは、現在インストールできる唯一の方法は、手動でインストールする場合です。
警告：これは、これらのマシンが定期的なメンテナンスウィンドウを持つ他のコレクションにない場合にのみ当てはまります。そのシナリオでは、このメンテナンスウィンドウは期限切れであるため無視され、他のウィンドウは累積されるため監視されます。
私にはかなりまっすぐに思えます。そして、はい、動作は設計によるものです。デプロイメントを誤って設計しただけです。 :)
あなたの間違いは、メンテナンスウィンドウが定義されていないため、これらのパッチをインストールすることは絶対に反対であると想定していることです。これは、メンテナンスウィンドウが定義されているかどうかに関係なく、人々がパッチやソフトウェアをインストールし、システムに変更を加えることができる必要があるためです。 （ワークステーションなどの再起動耐性の高いマシンを考えてください。）これらのシステムでは、メンテナンスウィンドウを定義する追加の手順が面倒であり、ポリシーの重複などにより、ソフトウェアの配布などで問題が発生する可能性があります。これにより、数を維持できます。メンテナンスウィンドウを最小限に抑えることができるため、展開の動作を簡単に管理および予測できます。
イメージで設定したとおりです。過去にメンテナンスウィンドウが設定されていて、再発がない場合は、希望どおりの動作になります。 :)
このすべてが言われています。自動更新を制御するさまざまなグループポリシー設定を混在させると、非常に混乱する可能性があります。マイクロソフトは、ソフトウェア更新プログラムのインターフェイスをかなり簡略化したり、既存の設定に説明を追加したりできます。 SCCM 2007も同様です。
SCCM 2012がSCCM 2007のように動作することを前提とすると、メンテナンスウィンドウがないため、そのコレクション内のマシンは、必要に応じて（または締め切り後）、あなたが見つけたように。
個人的には、ADセキュリティグループのメンバーシップに基づいてコレクションを作成することです。たとえば、Tuesday Maintenanceグループのメンバーであるサーバーは、Tuesday Maintenanceコレクションのメンバーになり、（驚いたことに）火曜日の夜に更新されます。
毎週再起動できないサーバーは、対象となる更新の展開がないコレクションに保持されるため、定義の更新以外の更新をダウンロードまたは適用することはありません。
これらの重要なサーバーを更新できる場合は、適切なメンテナンスウィンドウを持つコレクションの対象となるADセキュリティグループに一時的に追加するか、事前に新しいサーバーを作成します。
このアプローチがあなたが探しているものになるかどうかはわかりませんが、おそらくあなたにいくつかのアイデアを与えるかもしれません。
悪くなる。コンプライアンスの適用を試みるパッチの継続的な展開に関する私の経験では、それは本当の問題になる可能性があります。これが理由です。通常、ポリシーはクライアントのコレクションによってクライアントに割り当てられます。コレクションは定期的に更新されますが、すべてが同時に更新されるわけではありません。ここで、クライアントをサーバーにインストールするシナリオを想像してください。クライアントのインストールでは再起動は必要ありません。
サーバーは、最終的にはメンテナンスウィンドウのあるコレクション、および重要なパッチの継続的な展開があるコレクションに配置されます。しかし、たまたま展開するタイムラインはこれであり、展開を含むコレクションが最初に更新され、その後、クライアントは、メンテナンスウィンドウが割り当てられているコレクションが更新される前に、ポリシーの取得評価サイクルの間隔に到達します。 。その結果、サーバーがパッチを適用し、不適切なタイミングで再起動する可能性があります。
残念ながら、「すべてのシステム」のコレクションにメンテナンスウィンドウを割り当てて、デフォルトのメンテナンスウィンドウを作成することはできません。これまでに考えられたこの問題に対する私の解決策の1つは、「すべてのシステム」のコレクションをミラーリングし、それをインクルードコレクションとして持つコレクションとミラーリングし、そのコレクションに頻繁に更新を設定し、それにメンテナンスウィンドウを割り当てることです。また、デスクトップ用の重要なパッチを継続的に展開したい場合もありますが、サーバーの場合はパッチを期限切れにするか、少なくともメインメンテナンスプッシュの後でそれらを必須から使用可能に変更する必要があります。
また、過去に定期的なメンテナンスウィンドウを適用するというアイデアも気に入っています。
ここでは、わかりにくい半正解がたくさんあります。円で囲んだ設定は、マシンにメンテナンスウィンドウが適用されている場合にのみ適用されます。開始しない限りシステムを再起動しないようにする場合は、メンテナンスウィンドウを遠いものにするか、遠いものにする必要があります。
メンテナンスウィンドウがない場合、SCCMを使用すると、アップデートのインストール後にシステムを再起動できます。この動作をブロックする方法は、[管理]にあるSCCMクライアント設定- >クライアント設定。
[〜＃〜] sccm [〜＃〜] の既知のバグである可能性があります。ただし、MSのドキュメントは見つかりませんが、少なくともOPは問題が彼のセットアップにないことを認識しています。
私は実際にSCCMを使用して初めてサーバーを更新している最中です。
SCCM 2012がSCCM 2007のように動作することを想定すると、メンテナンスウィンドウがないため、そのコレクション内のマシンは、必要に応じて（または締め切り後）、あなたが見つけたように。
私もそうだと思いました。メンテナンスウィンドウを割り当てる必要があります。そうしないと、更新が適用されます。
サーバーの更新については、更新をavailableとしてサーバーに展開していますが、ログインして手動で適用しています（VMの場合はマシンのスナップショットを取得した後）。
ただし、「次のメンテナンスウィンドウ中にすべての更新プログラムをインストールし、必要に応じて再起動する」ボタンを使用すると、日中にこのプロセスを開始し、早起きして、スナップショットをロールバックする必要がないことを確認できます。